Hello everybody, happy Friday! Hope all is well.
In the last 12 months, I’ve written over 500 commits and probably way above 100k lines of code. In this document, I will share with you my secrets of being highly productive at software engineering. Specifically one area of software engineering – and that is coding. If you are a software engineer, and you want to print code faster than a Xerox machine, keep reading.
Heads up though! This post is totally opinionated. The rules here need not apply to everybody. It’s just what has worked for me and it’s just one of many ways to become a highly productive coder. I wrote this document in an imperative language, as if I’m talking directly to a less experienced version of myself. Don’t take it the wrong way š If you are that someone at the start of your career, you should also understand that Software Engineering != Coding. It’s much more than that. Coding is just a part of it. Do not underestimate other parts of the job, as the matter of fact, consider them just as critical.
1. Muscle-memory VIM
Once upon a time I joined a Big Tech Company, where there were no internal IDEs. The codebase there was a huge mono-repo. Millions of lines of code. No IDE at that time could meaningfully handle that volume of code. Like, if you tried to open it in Eclipse, it would take something like 1-2 hours for it to boot up. So, I did what a lot of other engineers did – I learned VIM. This is by far the best thing I did for myself. Writing code happens on a keyboard, and even the most rudimentary VIM knowledge makes one a beast at it.
You will need to learn VIM. Own it. Use it whenever you can, especially initially while you’re getting adjusted to the keyboard layout and shortcuts. It’s like learning how to walk again. The key thing about VIM is to be able to do almost all code editing things most efficiently and without using your mouse! Learn how to move around the page using a keyboard. How to select, copy, cut and paste things. How to reformat the code. How to jump paragraphs, words and letters. How to split windows. Jump in and out of methods. Search and replace.
Remember, using your mouse is a waste of time. To be a hyper productive engineer, you must optimize for keyboard use over the mouse. Be it through VIM, or through something else.
Finally, you don’t have to use the actual command line VIM. That’s not what I’m talking about. Feel free to use an IDE like IntelliJ or VSCode, but make sure you install a VIM plugin in it, such that you can still do all the awesome Keyboard things, without using the mouse. That’s the key – eliminate all mice!
2. Muscle-memory Git
This is the same whether you are using Git, Mercurial or something else. Fast commits, branching, squashing, resetting, rebasing, cherry-picking, pushing upstream, pulling downstream etc. In my .gitconfig file, I have about 20 different shortcuts. Things such as pull from the main branch, commit all modified files instantly with a default title, check out to another branch, delete all branches that are already pushed, show me a one line summary of the history log, etc. For anything that you repeat on a daily or weekly basis – you need to have in a two-three letter shortcut inside of the .gitconfig file. You don’t want to spend time typing “git checkout -b hello” when you can say “g cob hello”. These things accumulate over time, cause frustration, etc. Worth optimizing for.
3. Muscle-memory Shell
Regardless of whether you are going to be a Windows, GNU/Linux or Mac developer, you have to grok the Command Line. Learn how to write shell scripts. Automate all repetitive work using those scripts. This saves tons of energy and time.
4. Muscle-memory IDE
Modern (and even not so modern) IDEs are full of tricks that can help you save time. Things such as Organizing import statements in Java. Formatting the code. Introducing a new property. Running a test method. Searching across the whole project or workspace. Finding references (who is calling some method). Browsing the Type Hierarchy. Opening a terminal window. Selecting the current file in the Project Tree View, etc. You need to know that these tools exist and you need to know what their keyboard shortcut is at any time of the day and night. If some shortcuts are too hard to remember – reconfigure them. Save your mapping somewhere online so that you can reuse it if your computer crashes and such.
5. Speak the Language
A fluent natural language speaker rarely needs to stop and look up a word in a dictionary. Same is true for a fluent coder. To a fluent coder, code reads like a poem. All the syntax and built in essential libraries must be well known and understood. Things such as Async-Await in Python and Javascript, Executors in Java, or the C++ standard template library. You need to be able to read code fast. Granted, some code is complex and there is no way on earth that it can be understood without stopping and thinking about it for a while. That’s okay. I’m talking about the 99% of the rest of the code, which is basically converting one state object to another. You need to be able to breeze through those. It’s not possible to do this efficiently if you read through code and aren’t sure what it does.
Bottom line is – if you read through code, and aren’t sure what the syntax is – stop right there and invest in your future self and learn the syntax first, to a degree that you deem is necessary for the job.
6. Work the Framework
There are many abstractions and frameworks used in coding, which a lot of engineers avoid learning at all costs. Things such as Dependency Injection, Code Generation, Reflection, Immutables frameworks for various imperative languages, etc. Don’t skimp on those. I know it’s possible to understand how the thing works without understanding the framework – but if you are working on this thing – make sure you know the frameworks used well. A highly productive engineer must have a clear picture of not just the code they are reading, but also of the framework in which that code runs, the bigger picture.
7. X-Ray Code Vision
You will most likely get thrown into a new code base every few months or so. We change teams, or companies. A colleague goes MIA and you need to take over their project. Due to a reorg, your team inherits another team’s project and you’re the new lucky owner. A third party product is acquired and you are the point of contact for integration. A legacy system that you never paid attention to is getting deprecated and someone needs to go understand the damned thing and figure out how to shut it down safely while it’s processing terabytes of data every hour. “We are not in Kansas any more” kind of a situation there.
In all these situations, it helps to know how to quickly assess the new code base. And while it is intimidating no matter what, it’s absolutely doable and enjoyable. The trick which I recommend to you is two fold. One is to learn how to search the codebase. Oftentimes, we are dealing with hundreds of services and libraries and frameworks and there is simply no way to know them all. But you need to be comfortable to do an internal or external search for some method or class name and quickly understand what it does. The second thing is the Alice in Wonderland method that I use. Similar to an X-Ray, which goes through things, you need to be comfortable to dive deep into the uncharted territory – the code that’s unknown to you. Pick a random high level entry point, and then jump in. Look around, see something interesting, then jump into that. See how deep the rabbit hole goes. And then get out. Take some fresh air, do a breathing exercise, and repeat. Do a few of these “x-rays” and the idea of how the rest of the thing works will start to form.
8. Think like an Architect
Learn the architecture you are using. Learn about the services which your service depends on. Have a wider scope of understanding, go as far away as you can. If you are an AWS engineer, make sure you learn the essential services, such as SQS, SNS, DynamoDB, CloudFormation, Step Functions and also the domain specific ones such as Lambda, API Gateway, VPC, etc. You need to be able to recreate your service from scratch if it were to magically disappear. If you can’t do this, you have blind spots and that will impair you when you’re coding. Not understanding the big picture and how your piece of the puzzle fits in is detrimental to your productivity. Finally, become the architect.
Wrap up
That’s it. If you haven’t practiced these things before, adopting the habits will make you 10X more productive. I guarantee.
Srecko Toroman 