Asking this question on your favorite forum about software development will most likely return a ton of advice. Most of this advice, however, will try to persuade you into wasting your youth by learning whatever dark corners of computer science somebody on the internet thinks are important. But what about all those people who aren’t the kind of overachievers that spend their evenings reading about computer science arcana? If famous programmers claim that laziness is a virtue, then I see no reason why one couldn’t become the best while being lazy and invest as little time as possible into this journey.
Before we dive into the strategy of becoming the very best of our field, I think we should spend some time ruminating on reasons that are the cause of this journey.
Why would anyone want to become the best?
Along with a fancy job title and the people of your organization looking up to you as a role model and occasionally asking you for an autograph, you also attain power. The more power you obtain, the easier it is for you to organize the work the way you like it. You get the freedom to pick the kind of tasks that you find interesting and delegate the boring nonsense to the people below your pay grade.
Together with increased autonomy, you also get a higher salary as you are finally seen as one of the most important members of your organization who can “handle the responsibility.” Whether you are actually held responsible for the messes that you have caused is up for debate, but the larger the organization the less likely it is that you will suffer the consequences of your actions.
What does being the best even mean?
Upon hearing this term, a lot of people would first think of someone that is the best in the world. But how does one even define who is the best programmer in the world? Is it the one who knows the entire specification of their programming language? Is it the one who can debug an ungodly mess that is the payment processing code? Is it the one who can handle all your calendar and timezone related issues?
The term “the best” is a relative term as it depends on who you know and the kind of work you do in your day to day job. There are no official specifications or rankings that would determine what makes the best programmer, but whenever there is a debate on this topic you will probably remember someone with whom you worked with in the past.
Becoming the best programmer in the world that consists of 7 billion people might be close to impossible to achieve, but you can still attain this title on a slightly smaller scale. You can become the best programmer of your company, the best programmer of your department or the best programmer of your group. For becoming the best, you basically have two choices:
- Get better at your craft.
- Drive better engineers out of your organization.
Most of the advice that the greybeards give to whippersnappers is about following the first option and becoming better at your craft. It’s an admirable choice for sure, but unfortunately it’s a very time consuming decision since you will have to spend years of your life on learning about the finer points of your domain. On the other hand, if you decide to drive better engineers out of your organization, you can become the very best in a matter of a few productive months.
Since most of the advice is already covering the first option, this guide will strictly focus on the second option or getting rid of the people that are better than you. This plan, however, will only work if you are perceived as a skilled worker. That doesn’t mean you have to be actually skilled, it’s just that your coworkers will have to perceive you as one.
To make this perception concept a bit clearer, let me give you an example. If you are known to be a hard worker, you could easily skip a couple of days at work and nobody will bat an eye. Everyone will think that you are solving a really hard problem, since you have already proven in the past that you are not a slacker. Coasting is especially easy in software development, since nobody knows exactly what you are doing or how long a certain task should take. Sometimes the most simple things take days and sometimes you are done with them in half an hour. Even very experienced developers are often wrong when it comes to task estimation, so you have a lot of leeway here.
On the other hand, if you are perceived as a lazy worker, someone will most likely pay attention to your movements and interpret your actions based on your past attitude. You could change your attitude and work really hard for the past couple of months, but the stigma of your past laziness will stick for a very long time and consequently you will have to be careful when presenting your output.
Due to the aforementioned problem of perception you also won’t be able to follow this guide as someone who is fresh in the industry, just because you will be perceived as someone who doesn’t know much. While this may be very likely so, occasionally you will meet some dedicated people who are way better at their craft than their much older “mentors.” Even if you are one of those dedicated people it will take quite some time before people will start to trust your decisions and perceive you as someone who knows their stuff.
Now that I was hopefully able to convince you of the benefits of being the best, we can take a look at the actual actions you can take to attain the status of the very best programmer. The ideas here are listed in no particular order and they may or may not apply to you, since every organization is different and the strategy that works in one company might not work in another.
Master plan
Copyright headers
Insist on adding a copyright headers to every file. When asked why internally used code needs a copyright headers, argue that if someone finds your code printed on the street they will know who is the rightful owner and chicken out of reading it due to the fear of potential consequences. If one of the job candidates happens to “find” it in the lobby before their interview, it will also help you establish your dominance in your organization since nobody competent will be willing to join a company that produces such a ball of mud.
Besides, adding copyright into every file increases the number of additions within your version control. When a week goes by and you haven’t accomplished anything, you can split the existing code into a few new files with their respective copyright headers and report the great progress to your boss.
Comments and formatting
Insist on adding a comment for every method, even for getters and setters, since you never know when “get the thing” comment will come handy. Setup a code linter on your continuous integration server that automatically rejects your coworker’s commits that don’t comply with your arbitrary code formatting rules. You score extra points if developers can’t run the linter on their machines and have to keep pushing new commits just to test their code for compliance.
If you get asked why developers can’t get the access to the code linter’s configuration file, make sure to sigh and start talking about irrelevant security problems in a really monotonous voice while throwing in a couple “cybersecurity” keywords every now and then. If the asker is experienced enough to question what this long list of irrelevant things has to do with code formatting, simply answer that it’s a company’s policy and there is nothing you can do about it.
Build system
Insist on using a non-standard build system. When your coworkers complain how the autocomplete in their IDEs no longer work and how they can’t even start a debugger in a sane way, just say you don’t understand what’s the issue and how everything works for you in your text editor of choice. Then go on an hour long off-topic rant about the bloat of modern IDEs and how if they were decent developers they would just memorize the APIs by heart instead of relying on autocomplete, because “real” developers with chest hair don’t need autocomplete.
If your coworkers want to argue back, make a loud sigh and say: “That’s what you get for programming in Java!”
Bug tracking
Insist on tracking all software related issues in a separate issue tracking software and enforce that every little change has to be tracked in it. Want to change a typo? You better open up a new ticket. When you discover that somebody made a small change outside the scope that was mentioned in the issue tracking software, make sure to have a lecture on the importance of properly tracking your changes and the effect it has on task estimation. You score bonus points if the chosen issue tracking software is extra slow and takes 10 seconds to open up one sentence long bug description.
Progress meetings
Insist on having daily progress meetings and schedule them very early in the morning. You should invite as many people as possible, even the ones that have nothing to do with what your team is working on. If someone is late to your meeting make sure to remind them in public that they are late and go on a rant about how being late to meetings is against your company’s culture.
The more time these progress meetings take, the better. You want to know what your “competitors” are working on, so you can prepare a better plan on how to throw more obstacles their way.
Code reviews
Have a lecture on the importance of code reviews and demand from everyone to have another set of eyes to look at their work. When someone, who is considered better than you, sends you their changes for a review make sure to take a few days before looking at their work. You score bonus points if you manage to merge your changes in the meantime that cause a merge conflict in their yet unreviewed patch.
At the beginning of your next progress meeting, make sure to remind the developers of how they should always make sure their code has no merge conflicts before demanding a code review, for your time is too valuable to keep having to resolve other developer’s problems.
When you are reviewing other developer’s changes, don’t forget to point out irrelevant issues they could fix even though these changes have nothing to do with the problem they were trying to fix. You should strive to stall the merge request as much as possible, so they will have to keep context switching between their current task, fixing the discovered issues of the review and resolving merge conflicts of their open merge requests.
Since firing someone who knows what they are doing might be a real hassle, you can instead convince them to leave on their own. If the projects are moving at a snail’s pace due to all the obstacles thrown their way, that may plant a seed into their brain that it may be the time to move to a more productive company.
Hiring
Once you have climbed to the top of the food chain, it becomes critically important to maintain this status quo. Large companies usually have way more work to do than they have capable engineers, thus there is a constant need to hire more talent. Since you are considered one of the more experienced engineers, you will probably have a relatively big role when it comes to hiring new people. For this reason you should pay a lot of attention to all the things that make experienced engineers not willing to join your company, such as:
Long interviewing process: the more rounds of lengthy on-site interviews, the better. Great engineers are not going to put up with hours of interviews just to prove they know their fundamentals, which is exactly what you want. If one of the higher-ups starts asking why you are struggling to fill the roles, the answer is obvious: lazy workers don’t even know their fundamentals and just expect to be handed a well paying jobs; back in my day…
Unbearable bureaucracy: when the candidate asks you about internal processes, like replacing their old laptop, make sure to mention every nook and cranny of the lengthy bureaucracy that is necessary to stick to. The more convoluted the story you provide, the better it is. With time you will learn to recognize the horror on the candidate’s face and save a few minutes of your time by wrapping up your story early.
Below market rate salary: nothing makes you get the bottom of the barrel faster than offering considerably less than the company across the street. You know you found the right person for the job (the one who is not going to undermine your position anytime soon), when they are happy accepting whatever offer you throw at them.
If all the above fails to convince a knowledgeable engineer to avoid your company, you can always dismiss them for their “obvious lack” of soft skills. Come up with whatever choice of words or question they have asked during the interview and narrate a story how their behavior is inappropriate and over the line with your company values. As the famous saying goes: give me 5 minutes of time with the most experienced engineer, and I will find a way to reject them.
Legacy
Once you get into the driver’s seat as one of the most experienced developers in the company, you can finally start thinking about your legacy and make the kind of changes that will ensure you can sit and command from your throne till the end of time.
For starters insist on splitting up the functionality into as many services as possible. If someone questions why multiplying two numbers have to live in the multiplication service, educate them about modularity and reusability. What if it ever happens that another team would like to multiply two numbers together? They shouldn’t be wasting their time reinventing the wheel, should they? Besides at some point you will need a bunch of multiplication services and by splitting this task in another service you can spin up as many multiplication services as necessary for your scale.
The more services you manage to extract from your software, the better. You score extra points if you manage to have your newly extracted services depend on a bunch of other services. When something breaks in that lasagna of services, even the smartest brains won’t be able to keep up with that mess of broken things and you will be crowned as the greatest developer that walked the earth just for having a slight idea of what kind of services exist out there.
Appendix
Office of Strategic Services (predecessor of CIA) published a thorough document on sabotaging organizations already back in 1944, which is surprisingly still applicable. For office workers the most interesting section is probably “General Interference with Organizations and Production”, see Simple Sabotage Field Manual (PDF), page 32.