Things Software Developers Say at Work – Making Them Stay Mediocre

I’m just going to enumerate a bunch of things I sometimes hear or read developers say, that I believe, make them stay mediocre.

If you like this article, you’ll likely also find “how to piss off a developer” entertaining.

“Make it as simple as possible.”

I honestly don’t think simple solutions are always the best. You’ll often set yourself up for failure following this advice. More often than not, you’ll need to write code that others will depend on or have to maintain, and “simple” solutions often resort to awful implementations using if-else statements, providing minimal extensibility.

Your solution should match the task’s complexity level. If it’s a difficult problem, then it’s fine that you didn’t go ahead with the simplest approach.

When discussing user stories with the Product Owner: “I only care about the technical parts.”

Or the other famous variation of this: “I don’t care about the business aspects.”

I’ve heard this repeatedly, and it’s dumb to say it for obvious reasons.

The absolutely only reason you’re working as a software developer is that there are business issues to be solved or ideas to be developed. If you only care about technical aspects then you probably belong in academia and not the business world.

“I don’t need to learn domain knowledge.”

You’ll stay wildly ineffective if you take this to heart.

The most effective developer on any team isn’t necessarily the most skilled developer — in terms of hardcore technical abilities. The most effective is the one who knows the industry, business, and domain problems.

If you’re in meetings and people use domain-specific terminology or you have a hard time understanding a feature’s purpose, then you definitely need to start asking questions.

Good questions I personally use to gauge if I’ve understood something well enough are:

• “So, what question haven’t I asked you, to show that I understand this,” or
• “What would you ask me to assess if my understanding is correct?”

When reviewing a pull request: “don’t use comments. Your code should be self-documenting.”

What a joke. Self-documenting code is the naive developer’s wet dream. I don’t believe you can ever make code self-documenting after a certain complexity level.

Sure, you should use sensible names, named conditionals, etc, but you’ll for sure have a hard time capturing the complete context and why a piece of code exists. No matter how well-named your variables, methods, classes, etc are.

“You shouldn’t use Design Patterns”

Only those who cannot wrap their head around design patterns utter this garbage.

So, tell me again how you create web apps in aspnetcore, django, laravel, etc. without using e.g. strategy pattern, factories, Model-View-Controller, and so on.

Common objections to applying design patterns are:

• It’s over-engineering; unwarranted complexity.
• They’re hard to understand; difficult to use and modify.
• No one uses design patterns (you can’t tell arse from elbow).

If this is you, then I guess you’re also fine with hard-coding everything and never have to swap one implementation for another. And, in all honesty, this can be fine, if you’re basement curly braces solo app developer who doesn’t need to think about collaborative scalability.