Cover image for Top Signs of an Over-Experienced Programmer #humor #satire

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

seattledataguy profile image SeattleDataGuy Updated on ・6 min read

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

Posted on by:

seattledataguy profile



Software Engineer | Consultant | Data Scientist


markdown guide

I am often baffled by how hard it is for people (online) to understand irony.

Good read! Thanks for posting. And, I might clarify: This is not meant to be ironic :)


You have being lucky, I've heard some of the articles arguments in some workplaces and in a non-ironic tone. The non opinion and losing time refactoring are common, getting stuck with old tech too. Big picture too, is not unusual to see marketing people making promises without taking advice from IT and then IT trying to cram messy code, refactoring is not even in the horizon. And the boss/leader difference is not as universally understood as we would like. Many programmers living in captivity in closets near the boiler room.


Its hard without visual and audio cues!


after 10min of news is really hard to know if something said is ironic, we'll have to develope some kind of irony flag system, maybe a beacon.


I completely disagree to this thought "good programmers shouldn't question what they are doing. Instead, they should just put their heads down and code no matter the request"

In order to create a great product, every members in the team need to know what they're building and why they're building it. Developers might have different takes on things and possibly lead to better features. We can't just be a monkey coder and do what needs to be done.


You must have missed the #satire :) and the final p.s.


It is useful in another 50 percent cases to leave tldr; because I also was wondering what the stupid things were written until I read the last part of the post


[edit]: The person who think in that way must be some hipster business analyst and data scientist mix personality who thinks who knows the code because of some data science that he/she does on some framework and he/she thinks knows business.
I want to ask that person have you ever tried to maintain software for 20 years? Have you ever tried to send patches to your 10 years older code and fix something or add feature on it?
This design docs, clean coding matter a lot at that point. If your goal only deliver little small tiny project, just keep going what you are doing but this software industry needs more well written, robust products not the apps which crash all the time and cannot be supported in 2 years


I will add it here :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.


Did you happen to get to the end ;)


I didn’t, I did right now. I found it stupid beginning and cut reading in the middle sorry for that. You were not serious and my comment will goes to somebody who is seriously think in that way😂

Hahaha, I wrote from the perspective a more jr. developer who might lack the experience to understand why things are the way they are in the software. I did know it would cause a little bit of anger but hoped it would bring some humor as well :).


Wow.. you really know me.. :P

Nice article. Enjoyed reading it. I have to rethink few of my behaviour. specially about documentation part. Being a freelancer for so long, When I finally got a job, It is hard for me to work with team not because of people, but because I have to work with outdated technology, There are red tapes if you want to upgrade a library, and when I use ES6, rest of guys think I am showing off. Most irritating thing was that while rest of team completed their code before time, I am stuck with mental loop of micro-optimization. I was hired because of my broad programming knowledge, from Mobile, to web, to desktop, But my team are better at doing a "job".


That is a common struggle. Getting things done, vs constantly optimizing and improving. I think most programmers mentality is if it isn't broke, don't fix it or improve it.


I think the "Complexity" comic strip is the reason many of us work late at night, we are not night owls, we are "don't f·(#ing interrupt me owls". I'm pretty chill about almost anything but when I'm just about to solve all worlds problems and you can almost see the answer and someone interrupts me just to tell me that I seem space out. Then murder doesn't seem such a bad idea. I think it should be allowed in court. "But judge, I was about to have the greatest idea ever, in the zone, and he interrupted me to tell me I seem spaced out", "ohh, ok, that's fine then, you can go home"


Thanks, this put a smile on my face. Sadly, not everyone understands satire.

Dear reader, if you don't know what a satire is, please search for a definition. We, humans, are not yet walking encyclopedias. But we're getting close thanks to always being online, always connected to internet, capable of quickly finding shallow layer of information on anything. The sad part is we've lost the ability to appreciate the complexity of a topic by digging deeper. At least this is what I find missing rather frequently in myself. As I dig deeper and learn more on a topic, and then review an old movie, for example, I find just how much I've missed, and most of it is good, deep stuff, lots of food for thought. Sadly, we only live do long, so learning the full depth of even a single topic is frequently out of question even if you dedicate your entire life to it (and I'm a type of person who loves to dig a little deeper, and wider, and around, and then I dig into psychology and philosophy of the author whose works I'm studying... It's a never ending process).

If you read the entire comment - thanks! Hopefully it gives you something to think about :)

Have a nice day!


Haha,this is funny! You have me fool up until the end. Thanks, this is entertaining.


Thank you for your kind words!


Managers that didn't come from the developer's pool all think like that, even if they say they don't. And if you're an ex developer made manager you spend all too much time convincing your business clients they are not hiring a virtual code for money electric screwdriver.

Believe me. I'm an engineer, made manager. Gave up humanity after some four years. Won't have children for fear they won't come out as engineers.


I liked this post when I began reading it. I disliked this post, midway. And liked it again after reading the PS.

I must admit I wasn't getting the irony until I read the PS. 😁


"I must admit I wasn't getting the irony until I read the PS" me too, I guess that's a sign of the state of things :D it would be almost a rulebook in many workplaces


Haha, glad you enjoyed it!


This almost got me. I had to say "Software cleaning is software engineering of course" out loud before I figured the humour


I tried to put in some lines like that, that I hoped would make the humor stand out a little more.


Wow, I was really taking this seriously until I read the p.s....Moreover, I don't have experience in a professional environment so I can't tell (ノ﹏ヽ)


Many people tend not to read the tags apparently :D
Great post, thanks!


I wish there was an official humor tag!


Thanks for the final clarification, saved me from having diabetes haha


I wanted to avoid too much anger XP


I'm glad you explained at the end that this is satire


Didn't want too many angry responses


Nice article! Parts of the article actually reminded of some a product owner types as well i.e "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"


I think this was boring because over-engineering does happen so I was expecting to read a satire about that


// Why?
// What was wrong with
// isset($_GET['restClient'])

// Answer: This Omelet is the result of broken and heated egg.