This post will be updated from time to time and on one good day I will write more about each bullet point / topic listed in here

Git usage

Do use Git! (or any other version control system)

Git good and commit

Using Git and learning basics with it how to use it will save you a lot of time. At the beginning it might slow you down, but it will pay back greatly in future.

The more you use Git the more you learn how to use it. Not even a single project should be without Git / version control.

Make use of Git add and commit like you make use of CTRL + S

Git has multiple workflows to follow. Pick one with your team and stick with it.

Commits

  • Commit often and learn to jump between commits, it keeps you from 100s of CTRL + Z’s and CTRL + Y’s in the future

  • Keep temp commits out of stable branches with git rebase -i

  • Write clean and short commit title. Title should not be over 50 characters

  • Commit title should complete sentence: “This commit will Fix randomness of number generator”

  • Use commit body to explain commit in greater details

  • Wrap lines in commit body at 72 characters

  • Add on empty line between commit title and body

Pull requests

  • Keep pull requests small and digestible, perfect PR is under 250 lines of code

  • Break big features into smaller pieces to create smaller PRs

  • It is easier to overlook issues in big PR than in small

  • Solve one issue in one PR

  • Write self-explanatory PR title

  • PR body should explain what, why and how was changed. If needed use images

  • Pull Request size Twitter

Git workflows

Whole point of workflow is to enhance effectiveness and team performance, not limit productivity and slow team down.

Some teams might be ultra effective with one flow and super slow with other. Don’t push on some flow that whole team fights against.

Workflow should scale with team, be easy to use and reduce all unnecessary cognitive overhead from the team.

Most common workflows:

  • Centralized workflow

  • Feature branching

  • Gitflow workflow

  • Forking workflow

Coding

Coding consists of multiple parts, not just sitting behind computer and writing some cryptographic code that only one person in team will understand.

Only way to get good at programming is to program and keep learning. A lot.

Planning

  • Think before writing, in most cases planning takes longer than actual coding but it will save a lot of time in long run

  • Write design doc per project to reduce spaghetti code. It may be personal

  • Write down issues that needs to be addressed, so you don’t forget them

Writing code

  • Pick coding style and stay with it throughout the project, linters will help

  • Write clean and readable code, most of time is spent reading code. Make it pleasant

  • Keep your eye on the goal (i.e shipping code / product)

  • Your code does not have to be perfect, there is no such thing as perfect code

  • Take time to code. 1x3h coding is far more productive than 10x20min

  • Don’t try to write clever and unintelligible code

  • Don’t overengineer Over-engineered house

Learning

  • Don’t try to learn everything, time and lifespan are limited

  • Keep learning and have strong self teaching culture

  • Don’t be afraid to learn, usually mental barrier is harder than learning tech itself

  • Create personal projects to learn

Testing

  • Test your code or end users will test it in production

  • 100% test coverage does not mean that your code has no bugs

Communication

Good communications skills are usually thing that developers lack the most.

Having chat with other developers will generate all kinds of new and cool ideas. It will also broaden the horizon that comes handy in future.

  • Don’t be afraid to ask questions

  • Don’t be full of ego and arrogance

  • Have healthy, not toxic, comments and discussions

  • Learn from feedback and criticism