Saw this gem in my Twitter feed a little while ago and had to save it so that I could comment on it.
Because to some people, in order to be a senior software engineer it’s about politics and org building (perhaps you’ll hear euphemisms communication and collaboration)
There is a constant theme in Programming that the good developers are anti-social, can’t be bothered to collaborate and should be left alone so that they can create a perfect product. The so called 10x developer. This is emphasized by movie stories about the genius developer creating something awesome sitting in their basement. Unfortunately that is not how real life works as this 10x developer is a myth. In real life you need to be able to communicate, collaborate and work in a team in order to be successful as a programmer. No single person can create an enterprise level software alone and even if you could it needs to be something that people want/need, so guess what you will have to talk to your users to understand what problems they are facing and then work on software that will fix them or make their lives easier.
In one of my previous company, my role was to look at new software/systems and bring them into the company. So we went to expos, talked to startups and explored the market and found a really cool software that we thought would be extremely useful for the business so we went back and pitched it to the business. To our shock no one was interested in adopting the software because it didn’t address any of the pain points that the business was facing. We thought it would be useful for them because we were looking at it from the outside and hadn’t bothered talking to them about what their pain points were. Then we sat down with the business and their development teams to understand the setup and find out what are the most urgent/painful problems that we should fix. After multiple discussions we went out and found a software that addressed a significant pain point for the business and as soon as we demo’d it, we were asked to expedite getting it validated/approved for installed in their org.
Similarly, one of the startups I was working with during the same time were creating tech to help blind people and I happened to mention that to the founder of a NGO (Non-Government Organization) that works with blind people and his response was that what they are creating is cool but I wish they would actually talk to some blind people before they start working on tech to help them, as the blind people don’t want systems that will give them sight but rather assist them in doing things without trying to recreate sight.
Coming back to the original point about Senior Software Engineer, it is not their job to work on every part of the project themselves. Their job is to look at the high level goal, design the architecture and work with other developers in their team to create the software. Another major task of the senior Software Engineer is to mentor their juniors, teach them the tricks of the trade and help them grow in their skills and role. I personally believe that I should always be training the people under me so that they can one day replace me so that I can move on to more interesting projects. If you make yourselves indispensable in your current role and no one can replace you then you will always be doing the same thing and can never move on. Yes, there is a risk that you might be replaced with a junior and get fired but that can even happen to the 10x developer as well. Personally, I would rather have 10 regular developers than a single 10x developer as they are a pain to work with. They will insist on having full control of the entire dev process will refuse to share information that other developers/database/network folks need and basically become a bottle-neck for the entire project.
The way I look at being a senior engineer/architect is that I get to work on the really interesting problems, write code for PoC’s (Proof of Concept) that fix the problem. Then I can handoff the code to others who can productionalize it with me providing guidance and support. Its not to say that I wouldn’t get my hands dirty productionalizing the system but I rather solve interesting problems.
Another myth is that the only person who knows the system will never get fired. I have taken over multiple systems over the years (at least 4 that I can recall for sure) where they were originally managed by a single person who refused to collaborate/communicate with the rest of the team. In some cases they were fired and I was asked to take over, in others they were moved to other non-critical projects so they stopped being a road block. It each case took us a lot of time to reverse engineer/understand the system but it was worth the effort to do that so that we could make future changes without fighting with someone for every change or having to call the person for information everytime the system gave problems.
Long story short: communications doesn’t equate politics and collaboration doesn’t equate org building. If you think that they do then you will be miserable in any mid to large size company. You might get away with it in a startup initially but not for long as the team grows you will be expected to work together with other developers/admins (collaborate) to create systems that others want and for that you will need to communicate with others to ensure what you are making is actually useful.
Well this is all for now. Will write more later.
– Suramya