What was the hardest lesson you learned as a developer?

Write your answer…

20 answers

"It's never about the code. It's always about the people".

To be honest, I'm still trying to learn this lesson. Most developers get sucked into the code, the language, the framework or the design so much that they actually ignore the people around them. Let me colour this with a few examples. Most developers talk about how productive they are in a particular language or framework. Instead, we should be looking at how productive was it to work with "this" team of developers. In another example, lots of developers even look for jobs that match a language that they know. Instead they should be looking for people they want to work with. The code figures itself out. Bad code is easy to change to good code within a few weeks/days. Bad teams don't become good teams in a few weeks/days. That takes years (if at all).

I'll re-iterate because I think this is important and needs to be said: "It's never about the code. It's always about the people"

Show all replies

human debugger not found

Reply to this…

Hashnode is a friendly and inclusive dev community.
Come jump on the bandwagon!

  • 💬 Ask programming questions without being judged

  • 🧠 Stay in the loop and grow your knowledge

  • 🍕 More than 500K developers share programming wisdom here

  • ❤️ Support the growing dev community!

Create my profile

Be pragmatic.

It is easy to get caught up in the idea of writing elegant/brilliant/perfect code. You can golf code down to a high performing, low footprint ball of random symbols that no one else can decipher and that's fun ... for a novelty site.

As developers, I think we often forget that at the end of the day this isn't about pleasing us or making our code look the best, but rather solving a problem and creating an enduring solution. We want software that works, that doesn't have defects, and is easy to maintain.

This means trade-offs. Optimizing a routine to shave off 9 milliseconds when it is part of a UI and the average user takes hundreds of milliseconds even to process and respond is probably a waste of time. Often we'll see a framework touted as "100 times" faster and switch even though it's 10x harder to work with. What do you gain? An imperceptible change in performance for higher cost and longer production cycles.

I was on another thread when someone made the blanket declaration "if statements are always a design flaw." Of course, instead of actually explaining why, they continue to maintain they didn't have to explain because it's just a fundamental rule of pure design and using them is wrong.

I know it may sound rude, but my hard lesson to learn was "so what."

Personally, I know no matter what level of developer is touching my code, this:

if (a > b) {
   x = 'yes';
else {
   x = 'no';

Is far more readable and easier to debug and maintain than this:

x = a > b ? 'yes' : 'no';

I may revel in the conciseness of my brilliant code, but what happens when I also have to set y? You could do this:

x = a > b ? (y = 1, 'yes') : 'no';

But what are you really gaining? I would posit not much. You don't need to compact your code, there are tools that do that for you. Why not make it easier to read and add space to add other logic in the branch?

The same goes with frameworks. I'll hear "that framework adds so much overhead." But if the overhead isn't visible to the end user and gives my developers the ability to generate stable code 4x faster, why wouldn't I use it?

That was a hard lesson to learn because I focused early on my career on being elegant, perfect, and "right." And I produced code that I could brag about and, guess what, a lot of people came along and struggled to maintain. I could get on a soapbox and call them "novices" or I could admit that I was programming for the wrong person: me, instead of the business.

Please, learn to be pragmatic.

Reply to this…

I can't do everything.

I often start on one project, then quickly get sucked into another project because I've gotten bored of the first or want to learn something new. As a result, I have like 40 unfinished projects lying around in Github repos or folders on my computer.

I should clarify: I haven't learned this lesson yet, but I'm trying to. I'm trying to be a finisher of projects and not just a starter, so I can actually be a productive human being!

Wilferd Peterson calls successful people those with their heads in the clouds and their feet on the ground. I've got my head in the cloud... now I'm trying to reach my feet to the ground.

Show all replies

Think of it, not as a waste of time, but a 'sketch'. As an illustrator, I've started many pieces of art, eventually putting them aside or throwing them away.

This process is ignored in development, but is equally important because - something is "just not right".

When we work on projects, it requires motivation to see them to the end, and de-motivation is caused by, most often, realizing that - no matter how much work is put into it at this point, it won't be as good as it could be.

So, we 'clean slate' something else that could fill that need instead of refactoring what we already have.

Much like tearing a incomplete drawing from your sketchbook, crumbling it up, and throwing it away.

The process is to start over and make sure that personal skill-related improvements are achieved.

Reply to this…

How a 1-hour job can wind up taking 6 hours....you all know what I'm talking about!

Reply to this…

The only thing constant is change

Today its technology x, tomorrow it will be y.

First - Learn how to learn

Reply to this…

Load more responses