This article’s idea came up as I was working as a full time professional remote consultant with both Senior and Junior Developers of all levels, contractors and full time folks. It turns out that about 95% of developers regardless of their seniority could use below guide.
It is surprising how much friction is caused by missing knowledge of these simple things, so I decided to write up a condensed version to minimize reading time, and quickly fill the gap for those in need. If you are just starting as a software developer, definitely read this, it will save you a few years of struggle in your career. Otherwise feel free to decide for yourself.
Table of contents (click to navigate to corresponding section):
- Know Your Code Editor
- Know Your Version Control System
- Make Small Incremental Changes
- Try and See What Works
- Respect Achievement
Know Your Code Editor
Every developer should know how to navigate around their code in their editor of choice, whether it’s IntelliJ’s family, VS Code, VS Pro or otherwise. In 2020, you no longer navigate to code by remembering where to go for each issue and by opening/closing folders in the project tree. This is simply not going to work if you have 200 projects in your solution, or >200K lines of code.
Instead, you should know how to navigate to type, navigate to symbol, perform regex search, how to set up search options, file filters etc. It’s not necessary to remember anything about the codebase if you know these. It helps to know Ctrl+Tab to switch between windows, and Ctrl+left/right arrow to navigate locally in a code file. Other useful shortcuts: Shift+Home/End, Shift+Del.
Know Your Version Control System
If you are using Git, you should master git bisect, rebase and the power of local branches. Use bisect if you need to find what caused an issue in a matter of hours, without any prior knowledge of the code base. Use rebase to create one nice commit message from all your changes, before making a PR. Doing so helps reviewers and it also helps git bisect, because there are fewer changes on master to sift through when debugging.
Understand that local branches (unlike SVN) let you create any number of branches in a snap. Create a new branch before rebasing your branch changes against master, because things could go wrong, and you want to have a backup (the original branch) if they do. Only rebase on the same branch if you are ready to lose the changes and rewrite everything from scratch.
Use your IDE to move files, but know when to use git command line. In 2020, just opening command prompt or git bash is no longer cool, so if GUI can do the same action in a couple of clicks, please learn the faster way and save your time.
Make Small Incremental Changes
Aim to have less than 40 hours of development work in your PR (roughly a week). If your PR has too many changes, it is difficult to review, and might be impossible to ensure no bugs. Unless you have 100% unit test and 100% e2e coverage, which is highly unlikely on a real project.
Break down your changes into multiple pieces that can work on their own. There is a much higher chance to finish multiple chunks of work without error, than it is to do one big thing correctly. Splitting work also helps with reports to management, to give them an idea of your current status and overall progress.
Try and See What Works
Every developer must love to experiment with code. Don’t know if it’s fast or not - test it. Think it might not work - write the code and find out. Trial and error cannot be replaced with experience, sometimes even an experienced developer will need to play and see what works. However, if you are afraid, because something might happen, you will never be successful as a software developer.
With time and enough practice of breaking things, you will know what could break and if it’s worth taking the risk. Without this practice, you will be afraid to break things, but keep breaking things with even one line of change. On most of your PRs. Stop being afraid and embrace making mistakes and learning from them. No mistakes - no learning, and you become obsolete in a few years. It is no longer possible in 2020 to learn one simple thing in coding and make a career out of it.
Respect Achievement
Every developer thinks their code is the best. But some developers have 100x fewer bugs than others. Because their code is objectively better. They can write 10x more code in a day than others, every day. Because they spend less time debugging it, their code just works from the first try.
What’s the secret? They compete. Either now or in the past they probably took part in programming contents, maybe went to national or international finals, and maybe even several times. Each time competing against other top developers. This involves being able to write a working solution in minutes, rather than hours. Thinking about every possible corner case, because each failed submission means lost points and can make all the difference between a win and a loss. It also involves typing at >120 words per minute without ever looking at the keyboard. For reference, professional typists do 65-75 WPM.
Or they have a professional certificate. And they have lots of them. They might be running an online technical blog, have a Youtube channel, be a Microsoft MVP or highly ranked on Code Forces, Stack Overflow, Code Project and so on. Whichever way they chose to stand out from the crowd, it is no longer just them who think they are good, it’s also >100 other top rank developers who can back them up.
You should respect that if you have 0 certificates, 0 profiles on developer sites, never took part in any competition and do not think about code outside of your 9-5 job, which is probably true for 99 developers out of a 100. Do not argue, just accept the fact their code will always work better and learn from them.
If you consider yourself up to the challenge, try to get in 10% percentile or get top level certification from an internet authority of your choice. It could be a Microsoft certificate such as MCSD, or Oracle Level 3/Expert certificate, or Expert level skill IQ on Pluralsight, or top 10% on Stack Overflow or Code Forces. Depending on your choice of path, it will take between 100 and 1000 hours of commitment. You will not be paid for it, so make sure you can afford this endeavor. Best part is whether you achieve the goal or not - does not matter, in any case you will have a better idea of what it takes to be in the top ranks.
As a software developer, you do not have to compete intellectually. Instead, pick any sports and become top 10-20 in your city. You will get the same benefit as competing online. For example, as a kid I took part in remote control boat competition and got my first national gold medal in Ukraine at the age of 11 (among juniors), and 8 other medals in the following years (2 gold and 6 bronze/silver). I competed in RC boat classes FSR-V15 and F3E, with at least one national gold medal in each. Here is a PDF rule book for reference.
Refer to the About page for list of my programming related achievements.
