,

Senior Engineer – The Number One Skill

Do you think I’m just trying to get you to click? Maybe. Maybe not. After working in and around Data Teams for well over a decade, with both the smartest people to touch the keyboard, and the others, it’s become quite clear to me what the number one skill that identifies a Senior level Engineering from the peons rummaging around in the StackOverflow garbage can for snippets, is.

I’m sure there will be hand-wringing, curses, tears, and generally weeping and moaning in the land, like some medieval plague that has swept away everything we hold dear. So just calm yourselves, sit down, and get your angry little fingers off that keyboard. Hear me out.

The number one Senior Level Engineering skill.

I’m not going to keep you in suspense, make you scroll to the end to read it. It is what it is, and just because you don’t like it doesn’t mean it isn’t true. You’re allowed to be wrong.

“Complexity reduction is the number one indicator that someone has moved from mid to Senior Level Engineer.” – me.

That’s it. Most Juniors I run into think that simply being a good to great programmer or coder is what is needed. Sure, that’s part of the package but far from being a top skill, it’s just a nice to have.

Being a Senior level Engineer is just as much about knowing how and when to NOT write code or go down a path, as it is about pumping out pretty-looking code. If you really think the amount and quality of code you output is the reason you will be a Senior+ Engineer, then truly CoPilot and ChatGPT have become your doom.

Trust me, I know and have worked with many an Engineer who will take exception to what I’m saying. Typically they are not that fun to work with. If you think coding abilities are the primary thing that sets a Senior Engineer apart from everyone else, well, that’s just toxic.

I’m not saying that coding abilities don’t matter.

I’m not saying Senior Engineers shouldn’t be excellent programmers, they probably should.

It just isn’t the primary factor, in the age of AI, or prior to this age we are living in for that matter.

Expanding on Complexity Reduction.

This is going to be part science and part art. Oh well. What can we say concretely about complexity reduction and how it helps make a Senior Engineer … well … Senior.

Also, side note, I understand some things are inherently complex, and that we can encapsulate complexity into readable, testable, and maintainable code. I reject at face value what some people like to argue, that code is complex and that’s just the way it is.

When you’re an Engineer who looks no farther down the road than your own nose, and are enthralled with your own abilities to obvuscate and do syntatic summersaults, this is what happens.

  • The business suffers
  • The development cycles become longer and more drawn out
  • The Engineering culture starts to deteriorate
  • “Difficult” bugs will happen more often.
  • Tech debt starts to pile up very quickly.
  • Onboarding becomes a nightmare
  • Tribal and knowledge centered on a single person(s) becomes rampant.
  • Refactors, migrations, and feature development and improvement become bogged down.
  • Testing becomes a nightmare.

These are all very real problems that can destroy Engineering teams, especially Data Teams that are especially always under pressure to iterate and produce results.

I feel like I have to say this again. Complexity exists, it’s inherit in some of the things we do. But, what does a Senior Engineer do? They work to mitigate that complexity from a variety of angles.

Senior Engineer will …

  • Reduce and identify unnecessary complexity
  • Document things effectively
  • Diagram and chart out hard-to-understand concepts and designs for future consumption
  • Make tech debt reduction, unused code, and deleting code a part of everyday life.

Practical Example from my own life.

I also think being able to write uncomplex code and come up with not over-engineered solutions is a skill that happens over time. It’s easy to pick on ourselves, so let’s do that, pick on me.

Back in 2019 I wrote some Python code to download project Gutenberg text files (books). 

Let’s take a look and be picky about it. Sure, perspective is everything, some people think it’s crap because they are Python Software Engineers, and others think maybe it’s ok.

What do I see when I see this? Unnecessary complexity.

I see OOP and a Class that should probably never exist. Does simply downloading some txt files over the wire require a Class … yeah .. probably not, unless you have nothing better to do with your time.

I personally always simply do the smell test. Let’s take for example this run function. Does it pass the smell test?

I think not.

At least for me now, a few years later … looking at this code … it’s a little overwhelming, It could be better. If there was a bug somewhere in this function, most likely if you were new to the codebase you wouldn’t figure that out in 3 minutes.

Complexity is the silent killer in both codebases and architectures.

A Senior Engineer can look at a problem and break it down into manageable bits. Their designs in both architecture and code are maintainable, testable, debuggable, and simply approachable. They aren’t enraptured by over-engineered and complex solutions just because they are complex, in fact, the opposite, they would so a smell test and ask why something is that way, and what could be done to simplify things.