Why You Should Make the Worst Parts of Web Development Even Worse

Being a developer can be a nightmare...

... if you're in the wrong environment. For many developers, it's a constant source of stress, frustration and anxiety. As a web developer, you love writing code.

[author_more]

The other headaches? They're things you can do without.

If you're experienced, you've dealt with the same headaches over and over. At times it feels as if someone's playing a cruel joke on you or that everyone you work with is crazy. And the worst part?

These headaches aren't going away.

When they're ignored, these mistakes typically leave developers feeling miserable, jaded and downright unhappy.

That doesn't have to be you.

Savvy Developers Use These Headaches to Their Advantage

They turn these everyday disasters into opportunities they can use. Average developers complain about these headaches, hoping to avoid the inevitable. All-stars use these everyday disasters to make themselves and others better.

What's their secret?

It's a simple secret most aren't willing to accept. It sounds obvious to most people when they hear it, when in reality, it's anything but. Here's the secret.

Do what others won't.

That's it.

Do this, and your value as a developer skyrockets. Master it, and you become irreplaceable.

Experience is Great, Vaccination is Priceless

For many developers, these headaches are crippling. Most developers hate dealing with these problems. At a certain point they begin to feel trapped. They've got a full blown case of learned helplessness. On an emotional level, they're afraid they'll be blamed if something goes wrong. And to a certain extent they're right.

But avoiding the problem isn't the answer.

Facing the problem gives you freedom and control. When you face the problem the despair, anger and fear loses its sting. As great as experience is, it can't hold a candle to vaccination.

Dominate these problems and you vaccinate yourself, emotionally and psychologically, against them.

Which problems are we talking about?

Headache #1: Fixing Someone Else's Broken Code

You've just been hired at a new job. Your first to-do item? Fixing a poorly made application the previous developer left behind. Which either has no documentation (he didn't believe in that) or too much documentation.

But the complications don't end there.

Developers, like writers, are unique. They all have their own style, their own way of doing things. The code you happen to be working with is long, complicated and filled with bugs. Tossing the whole thing out and starting over would be best.

Only you can't.

Because this code is live and in use.

Make it worse:

So you put a stop gap in place. You make the temporary fix you need to keep things going. But you don't stop there.

You take the time to map things out. What does the undocumented code do? Which libraries are being used where? Where are the conflicts? What are the dependencies? Learn absolutely everything you can about the poorly made system you're fixing.

It's tedious and miserable, at first. But it's something the vast majority of developers do their best to avoid. Here's why you should do it.

Thorough understanding gives you the ability to create change that sticks. You'll know the system better than anyone else on your team. That makes you indispensable.

Do this well and you're able to survive mass layoffs, company politics, and disasters. They can't afford to lose you, you're one of the few developers that knows things inside and out.

Headache #2: Fixed One Bug, Created Ten

After three hours of searching, you've finally found it. The fix is easy enough, so you push the update out. Only now, instead of that one original bug, there are ten.

Maybe the library you're using has lots of bugs. Maybe your update created a conflict with something else. Or maybe the bugs are unknown — as in you'll never find the problem. If you're lucky these bugs will magically go away on their own.

Make it worse:

First things first: get up and walk away. There may be a lot of pressure to find a solution, but your conscious mind needs a break. So you do the smart thing and you walk away.

Doing this moves the problem to your subconscious mind where you'll continue to work on it. Had a solution pop into your head while you were in the shower? Come up with a brilliant idea while you're falling asleep? That's your subconscious at work.

But there's another reason you should walk away.

Fear, stress and anxiety affects your mind negatively. A research study by the NIMH showed that cognition, memory, decision making, even spatial navigation were impaired by negative emotion.

Deal with your negative emotions first, then come back.

Start asking questions, focusing your attention on isolating the problems. Revert to a previous revision.

• Are the bugs still there?
• Are they the same bugs or slightly different ones?
• Were any of the bugs resolved when I reverted to a previous version?
• When are these bugs present?
• Are these bugs superficial, non-critical, critical or showstoppers?

Asking lots of questions trains your mind to search for answers. The answer tells you something about the problem. Keep asking questions to find the problems faster.

Headache #3: This Thing I Need, It Is the Problem

You've been assigned to a new project — integrating a client's website with a new provider's API. They provide you with the keys and credentials you need. Seems like everything's good.

Until you run some tests.

Everything looks right but you can't get things to work. You reach out to your point of contact and you ask for some help. They can't make heads or tails of it either. Your API calls aren't working.

You're already behind schedule. At this rate, you won't hit the deadline if things aren't resolved in the next day or so. But no one seems to know what the problem is.

Make it worse:

Here's a habit we used in our agency. We made it a habit to find an alternative provider, solution or option. If a client wanted A, we gave them A but we had B ready to go, just in case.

• If clients want Netsuite, you'd have Tracmor and TradeGecko on the backburner, ready if something went wrong.
• If they're using a particular library, we'd find (or in some cases, create) a new library. This is tricky to do and depends on your ability to spot serious red flags ahead of time.
• If they wanted things developed in Java, we'd have a secondary language with code samples, libraries, API documentation, etc. ready, just in case.

In the beginning, it feels tedious. If you're on a development team you already have a lot to do. It feels like you're running from one fire to the next, doing all you can to keep up.

Know what I mean?

We felt the same way. But here's what we found. Doing this extra work forced us to be efficient. We were prepared for the unexpected and our process improved as a result.

You'll quickly get a sense of who is good at what, and you'll rely on each other to get things done. You'll begin to gel as a team and at a certain point, the work is being done — without words.

This doesn't mean you stop talking. It means your discussions and conversations become more efficient. These kinds of teams dramatically outperform groups that simply work together.

Continue reading %Why You Should Make the Worst Parts of Web Development Even Worse%

by Andrew McDermott via SitePoint