Becoming a Great Programmer Through Extreme Ownership
Jocko Willink, a retired Navy SEAL officer, spoke about the concept of extreme ownership in his TEDx talk, which has since gone viral. The idea is very simple, although I certainly wouldn't call it easy. It is all about taking responsibility for any situation that you find yourself in, regardless of the circumstances.
In his talk, Willink provides an example where he took full responsibility for a friendly fire incident, even though he had several opportunities to shift the blame to somebody else. He took a risk by doing so, and it didn't feel good at the time, as he had to sacrifice his ego and swallow his pride. However, it has earned him the respect of both the men under his command and his superiors.
Although it is easy to describe what extreme ownership is by using a military example, the concept itself is applicable to any other career and any other part of life outside of work. If you are a programmer, you can certainly improve all aspects of your career by applying this idea to accepting responsibility, even in those situations where it seems obvious that the responsibility belongs to somebody else.
In the context of programming, extreme ownership is especially applicable in those situations programmers often complain about—the ones many find to be their “pet peeves.” Those include dealing with non-technical managers, junior developers, senior developers, recruiters, and corporate red tape.
So let's examine how the concept of extreme ownership can be applied to mitigate, or even completely eliminate, those specific annoyances.
Dealing With Non-Technical Project Stakeholders
Programmers often complain about non-technical managers and, to a lesser extent, other project stakeholders who don't come from a technical background, such as sales people and analysts. There are certain complaints that are repeated by developers about their non-technical coworkers time and time again on various web forums.
As someone who doesn't understand the code or software architecture, a non-technical manager often applies wrong performance metrics to assess the competence of software developers. For example, this type of manager wouldn't have a grasp of best practices for software building.
Therefore, instead of promoting and praising those programmers who write solid code, they promote and praise those who are the quickest at building software. Managers don’t realize the quickest developers are often that way because they take shortcuts, introduce technical debt, and tend to release code that hasn't been properly tested.
Another issue that is often found in a team run by a non-technical manager is that it's the people with the best communication skills who get promoted faster, rather than the most knowledgeable ones. This is not an issue in and of itself; however, it does become a problem when programmers with the best communication skills happen to be bad at programming. When everyone else sees there is no incentive to actually become better at building software, the company-wide quality of the software inevitably goes down.
These are some of the biggest issues encountered while working with non-technical project stakeholders, yet they are far from the only ones. As a developer, one can be forgiven for denying any personal responsibility for being in an environment that has these issues. After all, you cannot change the way your boss thinks. You may just be unlucky.
Looking from the perspective of the extreme ownership principle means you must acknowledge that the situation actually is your responsibility, and there is quite a lot you can do to change it.
So, you find it annoying that your manager doesn't understand the best practices in coding. However, if you step back a little bit, you'll realize that the reason is because nobody ever bothered to properly explain and emphasize the importance of those practices to them.
After all, the fact that the manager doesn't know much about certain technical concepts does not mean they are stupid. To get where they are, the managers had to do their share of studying to grasp some challenging mental concepts. Those concepts just don't happen to be directly related to programming. As these managers are not coders, their specific job does not make the best practices of coding relevant for them to know.
People don't know what they don't know. This is why communication is crucial. You are the one who knows how important certain coding practices are, so one thing you can do is explain them to your project stakeholders. Provide some examples of what happens when technical debts are introduced.
Explain to them that the risk of missing the initial deadline may not be as high as the risk of having an excessively complex and unmaintainable software with a lot of “spaghetti code.” Emphasize to them how skipping on proper testing processes can land the company in trouble when the app crashes in production while performing some business-critical activity.
This is why, no matter what your job is and how much you dislike working with people, you should learn how to sell and promote your ideas. I hate to break it to you, but soft skills are as important in a programming career as they are anywhere else. It is a well-established fact that soft skills affect your career progress more than the technical skills, even when technical skills form the core part of your job.
As well as being a master programmer, why don't you also become someone who is good at communicating what you do?
And if your current communication skills are not great, the principle of extreme ownership still doesn't leave you off the hook. Communication skills, just like any other skills, get better with practice. Even if you don't feel like you can communicate your concerns well at the moment, try it anyway. Get out of your comfort zone.
At worst, your current situation will not change, but you will be fully prepared to deal with such situations in the future. At best, you will find out that your communication skills are nowhere near as bad as you thought. In any case, you will gain a lot of confidence.
Dealing With Incompetent Newbies
Those junior developers who don't know what they are doing are a major source of headaches for experienced developers. They don't know SOLID principles. They don't know how to implement proper design patterns or use source control. They make changes to the code that runs in the production environment. They waste your time by asking you questions that they could have easily googled.
It is easy to see how frustrating it can be to work with junior developers, especially when you have deadlines to meet. Instead of adding new features to the software, you end up fighting fires they created, refactoring their code, or explaining to them how the generic base technology works.
However, one crucial factor applies in managing junior developers just as much as it does in managing non-technical managers: People don't know what they don't know. When junior developers are perceived as incompetent, it is not always because they don't care about what they do. They just haven’t had a chance to learn certain things yet.
There is only so much that computer science courses or online tutorials can teach you. Without knowing the subtleties of a corporate environment and experiencing a proper software development process, mistakes are bound to happen. The only way to learn proper processes is to have someone with experience explain those things to you.
So if you, as a senior developer, get annoyed by what junior developers do—don't. You are the one with the knowledge, and you failed to share this knowledge with those who don't have it. Therefore, you should take ownership of those unintentional mistakes that they made.
The reason why junior developers don't follow the design patterns is because they aren't yet aware of what those are. The reason why junior developers check their broken code into the main branch is due to a combination of not being aware of why this is a bad practice and failure on the part of senior developers to implement a process that will prevent them from doing so.
For example, nobody would be able to merge bad code into the main branch if the source control system would only allow those kinds of merges via a code review tool. The reason why novice programmers modify the code in production is, again, because they don't know any better, and because proper security procedures haven't been applied in the production environment.
This would never happen if access to the production environment was restricted to only a small number of authorized people who know what to do.
If you look at things from this perspective, you will see that almost anything you can think of that junior programmers do wrong is actually the fault of senior programmers. Therefore, instead of getting angry when junior developers do something wrong, think about what you, as a knowledgeable expert, can do to prevent this from happening in the future.
Of course, there are situations when the programmers you work with are genuinely bad. In any profession, there are people who are lazy. There are also developers who never complete any tasks, claiming to lack knowledge, even though obtaining that knowledge is an important part of their job.
However, even with those people, you can still take full ownership of the situation. For example, you can spell out to them what the expectations are. You can also come up with metrics to measure their performance and get them fired if their performance remains below par for a specific period of time, despite a number of clear warnings.
Dealing With Arrogant Senior Developers
If you are someone who is only starting out in a software career, the treatment you may receive from your senior colleagues could be less than pleasant. After all, you may be trying your absolute best, and any mistake you make comes from a genuine lack of knowledge in a certain area, rather than the desire to take shortcuts. Yet people get angry at you for making those mistakes.
This is where you have a choice. You can tell yourself that you are not responsible for any of these honest mistakes. You can then complain to your friends about how unreasonable some of your colleagues are and how the company you work for doesn't provide adequate training. Or instead of doing this, you can accept responsibility for your mistakes and turn them into fuel for growth.
Remember that nobody owes you respect. You have to earn it, especially since you are in a junior position and haven’t had a chance to build your reputation just yet. Considering this, you should not expect yourself to be left off the hook easily, claiming ignorance in specific areas.
Remember that your senior colleagues are the ones through whom you learn how to do your job correctly. And there are things you can do to earn their respect.
For example, instead of merely listening to your colleagues when they explain things to you, take notes and ask questions when certain details don't fully make sense.
Another thing you can do to save yourself some disagreements later is to think about whether it is absolutely necessary to distract a senior software developer with your question, potentially breaking their state of flow. You should only do so if you are absolutely sure this is something you can't google and you need to know the answer immediately.
Perhaps the most effective, but hardest, way to practice extreme ownership as a junior developer is to ask yourself whether you genuinely are trying your best and not taking shortcuts while telling yourself a different story. It is hard to be conscientious in your work, yet it is much harder to admit that you aren't.
This practice is bound to be never-ending, as perfection is impossible to achieve. Yet, practicing this self-examination is bound to push your career forward.
Dealing With Hard-Selling Recruiters
Recruitment consultants are great, and life would be harder for programmers if they didn't exist. With the recruitment industry as active as it is, you don't even need to apply for jobs if you have any in-demand skills. All you have to do is post your resume online and make it searchable. Headhunters will then find you.
The vast majority of recruiters are great at what they do. However, just like any other sales position that comes with personal, performance-based commissions, the roles in recruitment often attract some bad apples who are pushy and persistent at best, and dishonest at worst.
This is why developers sometimes end up in jobs that are very different from what they thought they were signing up for, or they waste a lot of time in the recruitment process only to find out that the job they were evaluated for is not suitable for them.
However, once you take full responsibility for your job requirements, getting inconvenienced by a recruiter becomes hard. After all, the hiring process is not only there for the companies to evaluate the suitability of candidates: Candidates should use it to ensure that a given job is fully suitable for them.
The best place to start is to have certain job requirements that you would not be willing to make a compromise for under any circumstances. You could, for example, choose to have a maximum commute distance that you would not be willing to exceed, or have a minimum salary requirement that you would not agree to go under.
Alternatively, you could have slightly more complex rules, where, for example, you could agree to take a job with a longer commute distance, but only if your salary increases by a certain percentage.
If you have job specification rules that are set in stone, you can be direct with any recruiter that calls you and instantly reject any job propositions that don't meet these requirements. Yes, this may be hard at first. Being salespeople, the recruiters will probably try to persuade you in the nicest way possible.
However, remembering that it's their commission and not your personal well-being they are primarily concerned about makes saying “no” to them easier when you know that doing so will save you a lot of time and nerves.
Being aware of tricks that some recruiters use also helps. For example, you may not want to give any references from your current employer until you receive a solid job offer from elsewhere. Otherwise, your superiors may be contacted when they don't even know you are looking for a job, which may ruin your relationships with them and force you to accept an offer at another company that may not be an ideal match for you.
Likewise, you may choose to disregard the advice given by a recruiter and discuss the salary directly with the recruiting manager. This is how you will know that the recruiter hasn't been lying to you and the salary you are looking for is realistically achievable in this particular position.
Knowing that recruitment consultants have been trained to be persuasive and would personally benefit from getting you a job, regardless of whether it meets your expectations or not, puts you in full control when dealing with them, especially when you have set-in-stone job requirements.
Dealing With Corporate Red Tape
Nobody likes restrictive corporate rules that don't seem to make any sense. Those can range from an excessively strict dress code to not being paid a market rate because it happens to lay outside of a company's “salary bands.” The dreaded corporate red tape.
The paradox of corporate red tape is that when you talk to anyone within a company about it, regardless of how high up they are, nobody seems to agree with it. Yet, these rules still exist, despite being made by the people who you have been joking about these rules with.
It is easy to complain about those restrictive rules and try to adhere to them until you can't take it anymore. However, the fact that those rules are made by people within the company means you can provide feedback about them to people who have the power to change them.
When you do speak to those who have a say in how the company runs, you will, at the very least, understand why certain rules exist. Therefore, following those rules will not be as painful.
For example, you may dislike that you are not allowed to leave your laptop plugged in and running overnight. What if you want to complete some long-running, hardware-intensive operation? However, when you find out that the reason for this is because one of the admin accounts was once hacked and every single computer left running was infected with a ransomware, you will probably change your mind about this rule.
In the best-case scenario, you can actually influence people at the top of the organization to remove the restrictive rules. Perhaps they introduced certain rules when they were not sure whether those rules would serve the company well or not.
They expected to get feedback, but none came, as the rest of the employees decided to complain about the rules to each other in private instead. Now, because of your feedback, they see why those rules are faulty, and you will gain their respect in the process.
Finally, you may find out that certain rules exist purely because somebody in the HR department was bored or wanted to play some power games. Unfortunately, this happens in the corporate world, too. In this case, if the red tape affects important parts of your career, you may consider leaving the company. However, as you have done your investigation and are completely sure that there is nothing you can do, you will do so with a clear conscience.
Own Your Responsibility
Extreme ownership is all about taking personal responsibility in situations where most people would shift the blame onto somebody or something else. It may seem difficult at first, but you will eventually realize how much control you will gain over your life if you practice this principle.
The idea of extreme ownership came from the military. However, it can be applied to any career and any other aspect of one's life. Even though the concept may seem scary at first, it is not usually risky when practiced outside of the armed forces. You will definitely not get court-martialed for taking ownership for a bad situation.
As the above examples demonstrate, the worst-case scenario is usually mild, while the best-case scenario is likely to make things significantly better for you, improving both your career and your life.