If I had to choose the most common trait among software developers, it’s probably the tendency to be amusingly irrational when choosing the tools for a task. The decision always seems to be heavily skewed in favor of personal preferences, a desire to try out a new shiny hammer or, slightly more rarely, to hold on to the old trusty at almost any cost.
Many are the times I have seen developers grab an entirely new toolkit, framework, or language and dive head first into a non-trivial task. In a world where technologies appear and are discarded at rather breakneck pace, one can almost forgive giving in to temptation. But when it happens without properly considering the alternatives, it is unprofessional, risky, and not something that belongs outside of private one-man projects.
But alas, the result is usually that a lot time is spent on trial-and-error and the result is usually ripe for consolidation, refactoring or even reimplementation. Most developers when nearing the end of a project really wish they could send back the wisdom and knowledge they’ve gained to their past selves. Some programmers even wish they could start over, while others cannot wait to attack the next problem with their new found wisdom.
Unfortunately very often, the programmer will decide the solution to the problems faced during development is to switch out the hammer for a new much shinier one, that will definitely get the next job done with much less hassle. And more fun!
The excitement and sheer joy of using new hammer is what keeps many programmers happy and productive. It’s not all bad, and sometimes the gains from adding something new or using a new technology can really make a project. But there is a risk, and not managing that risk responsibly is a problem.
Forcing someone to use yesterday’s tool is difficult, and I don’t think it works if the person hasn’t accepted that picking up new hammers might not always be a good idea. Not to mention that hype, a shiny demo and the lure of a silver bullet is often an easy sell to the stakeholders of a project. But I would advise anyone on the client side of a software development project to be extremely skeptical of the technological choices made by the development side. Do not trust developers to have the same priorities as you, and don’t expect them to be aware of their bias.
To an experienced developer should come the realization that new tools, technologies, frameworks and platforms need to be approached with caution and respect. Learn them in your spare time, use them in small projects before the big ones, learn from the mistakes of others. Don’t trust those who wish to sell your their successes. And if you need to bring in consultants to use a new technology, it’s probably too early, and you risk paying someone else to learn from your mistakes.
I didn’t really touch upon the grumps who really hate using a new tool or who fervently reject certain types of technology or platform due to personal bias or past experience. The advice is really the same. Use small projects and your spare time to learn the pros and cons of new hammers. Someone who knows how to appreciate a good tool, should appreciate the value of a well-stocked toolbox even more. Be skeptical of your own technological preferences, and re-evaluate them at regular intervals. Learn new things even if you don’t trust them to better than the old things. Acquire new tools.
That’s what we should aim at: Growing our toolbox. No matter where in the spectrum we are when it comes to adopting new technologies or tools, we should approach them as tools to add to our collection. Do not expect a silver bullet. Do not expect that you can throw away your existing tools. Accept that sometimes the best tool isn’t the one you’d like to use.
Last but not least, to those who want to turn everything into a tool or technology-building exercise, and I think every programmer has been there at some point, please exercise some restraint as well. Programmers often try to morph the task at hand into something they would rather do, or they become so enamored of their ability to craft generic and flexible solutions, that they spend too much time on crafting an amazing technological foundation – forgetting the actual product and not delivering on that. That’s a potentially much more damaging variation of the shiny hammer syndrome.
Codergaard 
learning in your spare time especially if you’re using the tool for your job is called unpaid overtime. This should not be condoned. It’s bad enough that the majority of companies don’t have *any* training budget, this just gives them another reason to avoid funding training.
Other professionals are paid to get trained or they learn new tools for *fun* and not for their job.
Professions that have a union also fight for a training time/budget.
LikeLike
Yeah, the writer comes off more as a pissed off manager, than a wise old developer.
LikeLike
Sorry to hear that – I am neither wise, old, pissed-off, or a manager.
I am just saddened by the way even very experienced programmers fail to be rational about their choices. I fully expect someone young and inexperienced to go by gut feeling and personal preference.
But I really think we as an industry, and that’s not just developers, but architects, stakeholders and business owners, need to be better at making the right technological choices.
The news are full of massive IT-projects that way over budget, poorly performing, not on time, scandals in every way. I think the lack of ability to be rational about technological choice plays a big part in this.
A lot of people, from the freshest coder to very senior stakeholders, have an almost obsessive focus on using the latest and greatest. And sometimes it is a good idea! But not every time, and we need to be better at telling the difference.
LikeLike
It depends really, a good employer will provide both organized training and work-related avenues with learning potential. Luckily almost all employers I have worked for, have been quite good at providing if not always the former, then almost always the latter. But even when it comes to the stuff, I do think every good developer should do on his or her own time, it’s only paid overtime if you don’t enjoy it. Of course, an employer should not have expectations on how you manage your spare time.
However, as you point out yourself there is a difference between learning for fun and out of necessity. The latter should be provided by the employer, but the employee also has an obligation to not abuse the trust placed in them to choose frameworks and tools mainly out of personal preference, for the fun factor. Even worse are developer who seek to better their future career opportunities by making technological choices with little regard for what is the actual best choice, or even considering other choices.
You have a point that a good employer should provide training in relevant technologies, and should also give developer some room for experimentation and trying out new things. But in return we as developers should always make sure that we are honest, to ourselves, to our colleagues and to our employers, about our technological choices, and sometimes bite the bullet and pick the tool that might not be our favorite right now, but has the best chance of getting the job done.
And I haven’t touched upon independent consultants who bill by the hour, but are every bit as guilty of picking the technologies that benefit their portfolios, resumes and accounts, rather than what is actually a good fit. I once had the pleasure of having a consultant tell me and my boss that the technology we bringing him in to assist with was a completely wrong choice. Even though it was his specialty, and he would lose out on a good opportunity by admitting this. We hired him anyway to help with the alternative, as that kind of honesty and integrity is refreshing and unfortunately not as common as it should be.
Programmers have had a union for many years in Denmark, and it hasn’t really made much of a difference when it comes to training. Good employers will provide it, bad ones will not. Most will provide it when asked directly, and given a good reason. If you feel it is reasonable and they refuse without a good reason, quit. Life is too short to waste on dead ends. You don’t need a union to take a stand on this. Unions are to me about making sure there is a proper agreement on available vacation, security in case of sickness, reasonable opportunities for maternity/paternity leave, a proper physical and psychological work environment, and the odd and unfortunate legal clash. Collective agreements on training don’t give good results from what I have seen. The age of unions fighting the employers is a thing of the past to me, at least in my part of the world. It should be about cooperation, not conflict.
LikeLike
Personally, I’m a big fan of “don’t use a hammer when what you need is a wrench.”
LikeLike