Bad Behavior Loop
Being in a technology field, the advice I’m about to give makes me feel kind of dirty, but it’s one of the easiest ways for developers to stop wasting time. Stop changing technologies! Or more to the real point, changing technologies is expensive – both in dollars spent and in developer time. Unfortunately, in my experience, often the developers with the most potential fall into the new tech cycle the fastest with every project (probably every decent size task if they could) just because it got a mention on Twitter from a big name.
Nothing To Brag About
Here are a few reasons to consider putting the brakes on bleeding edge:
- Paradigm shift – Everything from language specifics like short circuiting to specialized rules such as whether a user control is html encoded by default will cause either frequent Google searches on the front end of the dev cycle or bug fixes on the tail end.
- Move as a team – The bigger the team, the harder it is to change anything. Even with the brightest and best developers, there will still be a lot of information that has to be communicated and failures before lessons will be learned.
- Loss of developer magic – One of my favorite developers I’ve every worked with talked about the magic that happened every time his fingers hit the keyboard. In unfamiliar territory, that magic disappears for a while. It only returns after developer dues have been paid in terms of dedicated time with the tool.
- Bad news for end users – Newer technologies tend to be buggy at first. Not only that, with the latest-and-greatest, there may not have been time before product roll-out to make sure everything ran efficiently. If it’s bad for the user, it’s probably not worth the change.
- Decision for / decision against – Spending time on something new means not getting even better at something you already know. Honestly, it’s unlikely that a developer will ever exhaust all resources on one technology. Picking an in-demand technology and doing a deep dive is a solid strategy.
I’m probably as guilty as the next programmer when it comes to wanting to change. So why do we do it? Because there’s not much difference between the average developer and a kid in a candy store with handfuls of cash. Actually, now that I think about it, a dev shop is more like a bunch of kids in a candy store. The only thing that distracts us from candy is…more candy. Doing new stuff is why we got into programming in the first place, right? Maybe, but for any developer looking to really make an impression, my philosophy is that making a ridiculously happy customer is a better career move than getting more play time at work. Re-prioritize. Career candy > tech candy.
When To Change
When is it time to make a move to a different technology? Probably no big surprise, but there’s not a universally great answer to that question. What I’d encourage is making an intentional effort to decide when is right for your organization knowing that there will be a significant cost involved. Slower is probably smarter.
Any additional insight from fellow 20xers? Big successes or big fails when making a switch?