Experience Is Knowing What Not to Do

Sometimes the most valuable thing experience gives you isn’t knowing what to do, but knowing what not to do.

I’ve been writing software for a long time, long enough to have used technologies that no longer exist, languages that people have never heard of. Development practices that would probably get you laughed out of a modern development team.

And I’ve made a lot of mistakes.That’s probably the most valuable part of all that experience.

Because experience isn’t necessarily knowing exactly what to do. Quite often, it’s knowing what not to do.

I’ve learned not to overcomplicate things

When you’re starting out, there’s a temptation to use everything.

• You’ve discovered a new framework, so obviously the next project needs it.
• You’ve found a clever design pattern, so now everything needs to be a clever design pattern.
• You’ve discovered dependency injection, so suddenly you’re injecting everything into everything else.

Eventually you realise that sometimes you just need a function that does a thing.

The older I get, the more suspicious I become of solutions that require 14 files, three configuration systems and a 40-minute YouTube video before you can make “Hello World” appear.

I’ve learned not to write code just because I can

(This one took a while.)

When you’re learning, writing code feels like progress. More code must mean more functionality. It doesn’t. Sometimes the best code you can write is the code you don’t need to write.

I’ve deleted entire chunks of software over the years and ended up with something that worked better than it did before. That’s a slightly uncomfortable lesson for a developer. We like writing code. Deleting it feels like admitting defeat.

I’ve learned not to fix things that aren’t broken

There’s always something that could be improved. That doesn’t mean it needs improving.

I’ve learned that there’s a big difference between: “This isn’t perfect.” and “This is actually causing a problem.”

Trying to make everything perfect is a fantastic way of spending three days solving a problem nobody actually had.

I’ve learned not to trust the first solution

The first solution is often the exciting one. You’ve figured it out. It works. Fantastic. Then you look at it the next morning and wonder what on earth you were thinking.

Experience has taught me to leave things alone for a little while. If a solution still looks sensible after I’ve had a cup of tea and some sleep, there’s a reasonable chance it might actually be sensible.

I’ve learned not to blindly follow fashion

Technology has always had fashions. There was always a “new way” of doing things.

Sometimes it genuinely was better. Sometimes it was just new.

I’ve reached the point where I don’t particularly care whether something is fashionable, I care whether it solves the problem.

If it does, I’ll use it. If it doesn’t, I won’t.

And if the thing everyone is currently excited about disappears in 18 months, I won’t be particularly surprised.

I’ve learned that debugging is mostly asking stupid questions

• Is it switched on?
• Is the cable plugged in?
• Is that the right database?
• Did I save the file?
• Am I looking at the right server?
• Did I actually deploy the change?
• Have I tried refreshing the page?  (Yes, even after all these years.)

Especially after all these years. The more experienced you become, the less embarrassed you are about checking the obvious things first.

Because sometimes the incredibly complicated problem genuinely turns out to be…. …you were looking at the wrong file.

I’ve learned not to be afraid of starting again

There’s a point where fixing something becomes harder than replacing it. Recognising that point is experience. Sometimes you can spend hours trying to rescue a bad solution simply because you’ve already spent hours on it. That’s the sunk-cost trap.

Sometimes you have to admit: “This was a terrible idea.”  Delete it.  Start again.  And pretend nobody saw.

Perhaps that’s what experience really is?

But I do know a few things.

• I know that simple is usually better than complicated.
• I know that working code is worth more than fashionable code.
• I know that not every problem needs a framework.
• I know that debugging the obvious things first isn’t beneath you.
• And I know that when someone says: “It’ll only take five minutes.” …it absolutely will not take five minutes.

That’s experience.

Not knowing all the answers.

Just having made enough mistakes to recognise some of the wrong ones before you make them again.