How many repositories should i have

There's nothing wrong with building your own implementation of Pong or Asteroids. Mobile app —Professional mobile developers and those looking to enter that field are often judged by their available titles.

Those that do publish apps should focus on usability and function and not give a thought to download stats or popularity. Scripts, utilities, plug-ins —When it comes to repos, size doesn't matter. A useful automation script, scraper, or productivity tool will catch the eye of a select type of engineer, and luckily these are the ones you want to impress.

This genre of project is indicative of a hacker mentality, and the ROI for these projects is substantial. Employer-targeted code —One unique way to get an employer's attention is to write something related directly to its business.

These projects can serve to both demonstrate skills and flatter the employer with a level of interest. Examples might include projects that call the company's API or a visualization of its data sets.

Contributions to other users' projects — A contribution will show up on a GitHub public profile if it meets a list of criteria established by GitHub and depending on the user's privacy settings. In addition to showing technical chops, these contributions may also demonstrate a commitment to open source which will be valued by others sharing that commitment.

For most at the junior and intermediate level, contributions make up a tiny fraction if any of their GitHub activity. Variety —Several projects utilizing the same tech stack and tools will be less impressive than demonstrating fluency across a palette of tools.

Bootcamp graduates might typically have three or four similar projects often using Ruby on Rails. One simple way to add some diversity to a GitHub portfolio is to implement the same solution over again using different languages or paradigms. Build a game in Python, rewrite it in Java. Completeness —Many candidates have GitHub accounts strewn with several projects that were never finished. Most employers would rather see a few repos that appear polished than dozens of sketches that need lots of attention.

Readability —Those evaluating a repo are doing so under the premise that this could be the code of a future co-worker. Nobody wants to work with someone who writes unreadable code. It's a good idea to have repos reviewed for readability before sending them off, even if code compiles and performs well. Although the code is what will ultimately be judged, some minimal explanation of the repo and directions on usage will go a long way.

A portfolio of code is primarily used to demonstrate basic programming ability and an understanding of fundamental concepts. It can also serve as a catalyst during interviews that helps facilitate deep explorations into the thought process behind a technical decision. These conversations are what make for great interviews, and the opportunity to discuss familiar material your GitHub repos will be far more comfortable than fielding random technical questions.

The GitHub portfolio is certainly not the be-all and end-all when it comes to a job search, but it's clearly an advantage that helps answer the critical "Can you code? Thanks for the response, that is what I was planning to do. But then I started reading about people advocating for monorepos, however that is probably not relevant to my particular situation.

I feel like it will better if a potential employer checks out your Github and sees:. If you have time, it can help to flesh out your readmes as well to give a description of the project, how to spin it up locally, and even some screenshots.

Here are some thoughts:. Putting related services and shared libraries into the same repository and deploying them as a whole is something that can greatly simplify the development lifecycle and avoid breaking changes.

Coding tutorials and news. The developer homepage gitconnected. Sign in. Finding a trade-off between multi- and mono-repository. Sasha Mathews Follow. Multi-Repository Approach Perhaps the most obvious strategy for a microservices project is to put each microservice and each shared library into a separate repository.

Fast IDE The larger the codebase in the one solution, the more computer resources your favorite IDE will need, which will affect your performance. The most common operations developers perform in IDE are as follows: Open the solution. Build the solution. Perform automatic refactoring. Navigate between classes and methods. Fast Git Version control systems like Git and others will work faster with small repos than with large ones. Clear Separation of Responsibilities Repositories are strict and clear boundaries that separate the entire codebase of an application.

On the other hand, the multiple repository approach has several disadvantages: Complicated Development Lifecycle The development lifecycle is straightforward unless developers implement a feature that spans multiple repositories.

Code Duplication Development teams can start implementing the same or similar functionality in their repositories independently. However, managing shared libraries has its drawbacks: Developers must be very careful when updating the public API of a shared library to avoid breaking changes. Releasing a new version of the library will require a version update in all repositories that use it.

Debugging shared library code from services that use it is difficult. Hard to Enforce System Consistency When different teams work in different repositories, it is difficult to keep the entire system in a consistent state: Services use different frameworks.

Services use different versions of libraries. Services use different design patterns, approaches and best practices. When a single team is responsible for multiple services located in different repositories, they can be combined into one repository. When there are big doubts about the project future, start with a modular, monolithic application in a mono-repository.

Later it can be easily split into separate repositories if the project grows. It is best to stick to the mono-repository approach with a big number of junior developers in the team because of simplicity of the approach.