Working in a team is a superpower.
In a team you can leverage the collective hive mind of your peers. You see new ways of working, correct bad habits and have confidence that you shipping quality code.
When I started working on my solo projects I saw my code quality drop off a cliff. I've built Coderbuds to help share these good team practices to all developers.
What I've learnt working in a team.
You put on your best behaviour around others. You cross the t's and dot the i's.
Whenever I do solo projects, my standards slip. We only have ourselves to hold ourselves account and that can be a problem.
We'll skip writing tests.
We'll rush the code.
We'll do cowboy fixes in production.
I guess at least there is no-one to judge us! But it's not good for our codebase and not good for our career.
Senior developers who work in teams have hit the jackpot, from the get-go they can draw on their collective power.
They learn more and quicker.
Mistakes get spotted before they're on prod.
That's all very well but I don't have a team!
Dev's don't magically produce better results by being in a team. It's all about the processes they have in place.
I'm currently working in a team implementing the practices outlined in the DevOps Handbook.
It looks at what it makes to have a high performing, or elite team. It's transformational but has some simple practices at heart.
One powerful approach we take from this is to break up the work into digestible bites. Here the humble pull request is your friend.
Pull Request Best Practices
Magic happens when you break your code down into discrete units.
A good Pull Request is the epitome of this. Have it so it is self-contained and self-describing. Don't add the whole Kitchen Sink, just the taps.
Use the PR description to provide context to the code so when someone is looking at the diff's they can make sense of the code.
Each PR will ideally include tests (where possible). If you are adding functionality and it should be testable. Tests are a great way for others to make sense of what your code should be doing.
This all makes it much easier to get a good code review. We want to make it as easy as possible for our team mate to context switch, quickly understand what's going on and provide some feedback.
Bloated PRs stay stale! Create something small and descriptive and you'll go far, get feedback to improve the code and a quick merge.
This all helps with getting multiple small merges into your default branch, with multiple and ongoing deployments to production.
Avoid big breaking changes and embrace multiple small, discreet and testable PRs of code.
Using Coderbuds when you don't have a team
Coderbuds integrates with Github so you can easily publish your Pull Requests and get Code Reviews.
It works for Private and Public teams, so you can still work on your personal projects and get all the benefits a team mentality can provide.
If the above sounds great in theory but you are lacking the team to make it happen - Coderbuds can help you.
Here's my final advice:
- Break down your code in discreet units
- Make sure to add tests where possible
- Publish into Pull Requests with clear descriptions
- Get team mates to review (or find reviewers on Coderbuds)
- Deploy to production regularly!
You can use Coderbuds for free to post your Pull Requests.
Just want to learn from others?
Then head over to Coderbuds and find some PRs to review. Be kind with your reviews and always help with guidance when you find a problem.
Top comments (0)