, ,

What is a “Good” Data or Software Engineer?

Recently, for some unknown reason, I was pursuing the new Stackoverflow … called Reddit, for Data Engineering … and I ran across an interesting question … more or less it was related to “what makes a good Software Engineer … in a Data Engineering context.”

This isn’t the first time this idea has come up over the years, in fact, it comes up a lot, and is probably one of the greatest misconceptions about writing code, and how to get promoted. But, admittedly it is a complicated subject whose answer changes based on the audience or person asking the questions.

Context is key with this one.

What makes a “good” programmer/developer/engineer?

Again, this is a hard one to answer, but I will just give you my take … it’s probably worth what you’re paying for it, but I have worked the gamut of companies from the corporate slack-wearing Microsoft C# junkie office to the ping-pong playing startups at the other end.

  • Beginning of Career (1-3 years in)
    • “good” developers at this stage are …
      • veracious learnings
      • self-starters
      • continually improve programming skills
  • Mid-Career (4-6 years in)
    • “good” developers at this stage are …
      • better than average programmers
      • growing and working on written and verbal communication skills
      • able to lead and plan sizeable projects
      • able to get promoted to “senior” engineer
      • needs zero hand-holding
      • good planning and architecture skills
  • Old Timer (7+ years in)
    • “good” developers at this stage are …
      • consistently operating at a senior+ level
      • known as a go-to person to solve any problem (code, high-level, or team-related)
      • are close the business
      • are coding no more than 50-60% of their “time”
      • can plan and execute large-scale projects successfully
      • mentor and upskill all others around them
      • make difficult decisions

What you will note about this list this that it changes over time, as you move down the list. In the beginning, if you are new, in the first few years of writing code, then yes, most of your time is simply spent learning and writing code … and you have to be good, or be progressing upwards in both those areas.

You want new Engineers to spend a lot of time writing code and struggling, that is how they will gain experience and grow.

  • newer engineers need the chance to fail.
  • newer engineers need to write as much code as possible.
  • newer engineers need to read and learn voraciously

This is what makes a “new” Engineer good. Notice I didn’t say that need to be good programmers, they might … or might not be at that point. But if they can start to be independent, write code without much help, and continually improve and learn … that makes them a “good” engineer.

“Mid” career programmers have a different criteria. Yeah, that probably need to be good programmers. They have been programming for years at this point.

By now they should be able to lead reasonable-sized projects, deliver them, make decisions, and be pretty much autonomous in their work. Aka they should be a “Senior” or close to it at this point. Also, they should have moved on from coding skills and acquired …

  • awesome written skills
  • awesome verbal communication skills
  • be good at the big picture

Let me put this in a contrasting light so you don’t miss it.

If you have been programming for 4-6 years and you are not trusted to be put in charge of fairly sizeable projects, because you are known to be obsessed with your own code and have an inability to work in teams, deliver on time, and you are unable to work with the business well … I would have a hard time calling you a “good” programmer.

Sure, you might be really good at writing code, but at this point, there are a lot of people who can write good code. You have to do more than that.

The Old Timers on the other hand who’ve been writing code for a decade plus, should have found the Stairway to Heaven and ascended it.

At this point it’s not really about the code anymore, it’s about …

  • mentoring and upskilling others
  • solving all sorts of coding and non-coding people problems
  • deliver impact
  • top-tier teamwork and business impact
  • unparalleled communication skills
  • building anything from scratch and delivering it.

The value of these folk is most often not their code, although it can be at times. They are probably spending at most %50 of their time writing code. The other time is spent planning, checking in, unblocking people, answering questions, and working with the business units.

I’ve run into a fair number of well-tenured engineers who’ve been writing code for 15+ years … they are way smarter than most people, they know it, and they can write the most beautiful code you’ve ever seen. Yet there is one problem.

That’s all they do.

They can’t communicate well. They tear down others instead of building teams. They would rather be right and do it “the right way (aka their way)” over-delivering and making hard decisions. They’ve forgotten that part of producing software for downstream use … is the people and business downstream.

And that’s Ok I guess, if that is what someone wants. If they want to simply write code in a Hobbit Hole for the entirety of their life, that is their prerogative to do so. But if I’m building a Team that I want to build a thing, sure I want “good” Engineers … but I also need team players, good communicators, mentors etc. 

I’m not saying “good” Engineers don’t write good code. Of course they do, but it is a law of diminishing returns. The world needs good engineers who can write code better than anyone else and love problems, but you know what the world needs more?

Good Engineers that can do MORE than just write good code.