Top Signs of an Over-Experienced Programmer #humor #satire

SeattleDataGuy - Oct 5 '19 - - Dev Community

Photo by NESA by Makers on Unsplash

Software engineers seem to have a natural progression.

They go from inexperienced, to mid-level, to over-experienced engineers. Once software engineers hit the over-experienced stage, they become less interested in the code. Instead, they get distracted by design documents and refactoring old code.

It is strange that most over-experienced engineers will exhibit the same set of characteristics no matter what company you work for. Their lack of focus on code slows down lines of code per engineer because more time is wasted thinking through designs vs. just writing code.

This shift from a new engineer to over-experienced doesn't happen overnight. However, gradually over a few years or maybe even decades, these engineers make a shift into the over-experienced category.

They seem to be the same in every single company and it's just frustrating to constantly deal with all their demands and unnecessary busy work.

If you're a Jr. engineer or even an over-experienced engineer, this post will help point out the traits you might be exhibiting that inhibit development.


They Waste Time Refactoring

In a recent Twitter post, the @techleadhd, arguably one of the most over-experienced engineers currently alive, revealed his true thoughts about writing code.

He clearly doesn't believe in writing code. Instead, he seems to insinuate that there is value in deleting and refactoring code.

But it's not called software cleaning. It's called software engineering.

That means you need to engineer code, not maintain it.

Maintaining code is someone else's job. Maybe the intern can do it.

Software engineers should be spending their time coding around old inefficient code rather than trying to improve old infrastructure. It's OK to use duct tape code as long as things work. Some future engineer will have to code around our work. It's not like we can do anything about it. Yet, over-experienced engineers seem to believe that there is some importance in maintaining old code.


They Want to Focus on the Big Picture Not the Code

Let's be clear: the big picture and business side of things are not important, only the code!

Over-experienced software engineers have a bad habit of focusing on the big picture vs the code itself. They like to ask questions like "who will this project impact", "how will the end-user interact with the code", and "how will we maintain it?"

They waste a lot of time trying to understand the scope of the project and how it will impact the company. Sometimes they will even challenge leadership with what they believe are "superior solutions". We are not even sure how they even find time to finish all their coding when they are focused on such trivial matters, like "impact" and "prioritization".

Spending all that time in meetings, stand-ups, metrics tracking and on code-reviews cause the purity of just writing code gets lost.

We are not surprised that over-experienced engineers sometimes lose that glimmer of hope that exists in inexperienced engineers. Inexperienced engineers focus only on the code and doing what they are told, even when the scope might be overly complex.

This is because good programmers shouldn't question what they are doing. Instead, they should just put their heads down and code no matter the request. The business knows exactly what will impact the company at all times. Our job as programmers is to make it happen, not to figure out whether what we could do is worth doing or how it fits into company strategy.

We need to help over-experienced engineers remember that they are programmers, not leaders.


They Always Want a Design Doc

For some reason, over experienced software engineers always want a design document.

It would be much faster to just start programming any project no matter the size without thinking through a design document. It's OK to skip through thinking about what objects you need or what operational scenarios your code will be put through.

From our perspective, we find it is much easier just to keep track of everything in our heads. Even with thousands of lines of code, it's not so hard to manage.

It's not like we would repeat functionality with a slightly different object or anything.

We aren't going to create duplicate functionality with multiple objects.

So why do over-experience software engineers care so much?

In the end, we would write code ten times faster and be able to provide impact much more efficiently if we didn't need to spend time thinking through a design document.


They Dislike "Complexity" and "Over-Engineered Designs"

At a certain point, I think some engineers no longer want to think about other people's code.

So when you create a module that utilizes everything you learned at school all in one amalgamation of object-oriented memoization, they like to claim that the code is over-engineered.

Personally, we just think that they don't want to think through the brilliance of someone else's masterpiece.

How hard would it be to take the time to understand the how object A inherits from object B, which calls function C, which then calls function D and sometimes options F or G that pulls in information from config file E, which uses function F to parse data from database G that then stores logs in Hadoop, CouchDB, and S3.

They start to complain and say that the code is too elegant and or over-engineered. Their laziness keeps well-designed code that is really easy to maintain out of production. Instead, they attempt to push younger engineers to write code that is too simple.

Sure, it might seem like it's easy to look at and understand. But as engineers, we aren't focused on simplification. We take complicated problems and create complicated solutions.

They Are Stuck in the Future

The frameworks I know now are the only frameworks I will need to know from now until I die.

Yet, over-experienced engineers seem to spend a lot of time learning new frameworks and languages or at the very least, reading up on new design principles.

It all seems like a waste of time. As an engineer, you should be smart enough to know everything you need to know after you finish college. Anything after the fact is clearly not important. Some of them even still practice leet code problems and study, as if they might have an interview coming up. It's not like software engineers have to worry about being let go.

Doesn't everyone still program in the language they learned in college?


Over-experienced software engineers hold society back.

With their constant need for code-refactoring, design documents and learning they keep major software advancements from moving forward. We're pretty sure we would already have flying cars and robots that are smarter than us right now if it wasn't for over-experienced engineers. Instead, we're stuck with 280-character Tweets and Amazon ads that keep trying to sell me the same toilet seat cover I bought last week.

Edit: Have you finished reading the entire article! Congrats. I am adding in this piece to save some people time. For those of you that are passionate about programming, your blood is probably boiling right now. You probably read every sentence of this piece and assumed some arrogant young programmer wrote this piece...because let's be honest...we all know at least one programmer who actually thinks like this. This piece was meant to be satire. So I do hope you enjoyed it.

And to you younger software developers, please don't take this seriously!

If you want to read some more serious articles about data science and programming, check out the articles below!

Hadoop Vs Relational Database
How Algorithms Can Become Unethical and Biased
Top 10 Business Intelligence (BI) Implementation Tips​
5 Great Big Data Tools For The Future -- From Hadoop To Cassandra
Creating 3D Printed WiFi Access QR Codes with Python
The Interview Study Guide For Data Engineers

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .