The Difficulties of Senior Engineer …. are not Engineering

Well, I hate to break the news to you. I was the same when I first started, writing code that is. I was a zealot. I was zealous for every new thing I learned, every new language, every new approach, I would find the preacher who was preaching the message I wanted to hear … OOP, functional, Kimball, this, that, the other thing.

You’re young and full of life. You think that your Software career revolves around … software. The pinnacle of your mountain seems to be becoming that “perfect programmer” who can write anything without any bugs.

Yet, when you get to the top of the mountain you find you’ve been deceived. Not all that glitters is gold.

What Senior+ Engineerings really do.

I decided I wanted to write code for a living so I didn’t have to talk and deal with other people much. Let my work speak for itself. Write perfect code, let the rest of the world worship at my feet, all for the wonderful and fantastical abstractions and problems I solved.

Yet something changed.

I had some experiences that changed everything for me. The way I wrote code, interacted with people, and how I thought about my future and my code.

What were those?

  • I worked with some Staff+ Engineer(s) who were terrible people and leaders.
    • they destroyed culture and teams, not build it.
  • I saw lots of failed projects
  • I saw the smartest engineers and programmers never “go anywhere.”

I realized what I thought was true was not. I found out that being an effective Engineer or software Developer, whatever, person writing code, could simply not be measured by the “neatness,” “cleanness,” “complexity,” “blah,” “blah,” “blah,” of simply their code.

Questions worth thinking about.

It took me a long time to get over this. It’s just something we believe because we are human. We measure developers based on our “viewpoint” of “the code” they write. Forget context or anything else. Do I like their code or not? Are they considered “smart.”

In defense of that standpoint, I still think clean, modular, and well thought out code is a prerequisite to be a Senior+ Engineering. It’s the ground zero. Get past Go. If you can’t write “good” code you probably shouldn’t be a Senior+ Engineer.

But that simply gets you in the door. And, it’s arguably the least important part of what you do.

What the hard parts are of being a Senior+ Engineer.

It isn’t rocket science. You’ve probably heard this stuff before. But, it’s true. Straight and to the point, this is what the hard parts are, the things you should spend most of your time doing.

  • Building consensus among others.
  • Seeing the big picture.
  • Thinking and designing before coding.
  • Being good at Project Planning.
  • Being good at Project Implementations.
  • Working through conflicts.
  • Being a kind and understanding person.
  • Learning to lead others.
  • Learning the business context.
  • Learning how to make tradeoffs.
  • Continually learning and growing.
  • Mentoring others.
  • Delivering on time and on budget.
  • Good architecture and design skills.
  • Doing research and reading documentation.

All of that stuff surrounds code and happens in a “coding” context … but isn’t about writing code in itself. The hardest part is setting aside coding and preconceived ideas about what makes a good programmer. Sure, someone can write perfect code, but are they horrible to work with? Are they a lone wolf? Do they cause problems with bad attitudes?

So what if you can write good code? Can you deliver a project on time because you don’t get caught up in the weeds and don’t know how to make tradeoffs? Are you willing to set aside some “perfectness” in the name of having your company actually turn a profit?

So what if you can write good code? Can you upskill other team members? Can you inspire them to slowly and gradually improve their code and processes? Can you work well with the business to understand and balance their needs with Engineering?

So what if you can write good code? Can you plan a project before you actually try to write any code? Can you understand the big picture, look at the architecture, and try to see the potential pros and cons of each solution BEFORE they are implemented and you make up your mind?

What I’m not saying.

I’m not saying you should not be an “awesome” programmer in whatever context you are in. I’m actually saying you SHOULD BE AT THE TOP OF YOUR GAME. But, that’s just a prerequisite to get into the door. You should have better software solutions than most people. You should have cleaner code. You should have more modular code that is tested. You should understand best practices and follow them as much as possible.

If you’re a “bad” programmer it’s hard to make the argument that you should be in a Senior+ position leading others. You should lead by example.

Be good at software. Be better at everything else.