Developing 101

Git usage

Use Git! (or any other version control system)

Git gud 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

Use it as "Quick save" and "Quick load" in games 😋

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
• Temporary commits make your life a lot easier. Use them when "switching between ideas" when prototyping
• Keep temp commits out of stable branches by rebasing. git rebase -i allows to do interactive rebase. Fixing commit messages, merging several commits together to single one, dropping commits etc

Commit example:

• Write clean and short commit title. Title should not be over 50 characters. There's technically nothing blocking you writing longer titles. It's just good general practise to have it under 50 chars. This way titles will be fully visible in all terminal environments, UIs, logs etc
• 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. It's the same as with title. Lines can technically be longer, but that means they might not be fully visible in some places, like git logs, smaller terminals etc
• You can use -m multiple times to add commit body. First -m adds title, extra -m's add body or just add newlines
• git commit -m "Fix randomness of number generator" -m "Random number generator was using Math.random" -m "since it's not cryptographically safe, replaced it with crypto.random"

git commit -m "Fix randomness of number generator

Random number generator was using Math.random
since it's not cryptographically safe, replaced it with crypto.random"

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, gifs, videos etc

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 works for you but not rest of the team

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

Most common workflows to check out:

• 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

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

Me checking that post years after writing:
There's so many points in here that could end up as separate blog posts. Most of those are good to Google or ChatGPT. I might write some more posts about them or make this one super log post extending every point