Be a Catalyst Developer for Good
I read the article by Zachary Forrest y Salazar on DICE titled “Be a Catalyst Developer” and shared it with a few of my coworkers. Minus the slam he made regarding C# developers and their ability with CSS/HTML/JS it overall was a decent article. The gist of the article “don’t just blindly implement features or do work assigned”. Being a “Catalyst Developer” is all well and good, but like just about everything there is a proper time and place.
Being a catalyst for change, brining in new ideas and new ways of thinking are all good things. But would you want a member of your team experimenting with changes to your build infrastructure just before a release? Hair would raise on the back of most sane developer at the prospect.
When a company is chasing features for the sake “winning the checkbox war” then yes that’s a bad thing. Features driven solely based on input from the Marketing or Sales Departments are usually incomplete, disconnected from real world workflows and at worst, completely un-utilized in the product. But that doesn’t mean as a developer you can say “Hey, this feature sucks, I’m going to spend time hacking on something they may or may not be beneficial in the future”.
Anyone that’s had experience working with other developers most likely has encountered the ADD/”Ohhh Shiney” developer. The one that can never seem to focus on the job assigned. I would consider these developers “Perpetual Catalyst’s For Changes Sake”. We all know that playing with the new technology is fun, learning and discovery are fun, but if you’re the one always doing it, always taking the ‘fun’ assignments it will breed discontent with other developers.
Take a look at it this way, we all like desert. It could be cake, ice cream, or fruit. The developer who always is experimenting, always introducing new technologies most of the time is skipping the meal and eating the teams desert. They will push whatever technology/implementation/architecture of the month that they want down the teams throat.
Teams and individuals needs to be empowered to become catalysts at all levels inside an organization. If it’s just a single developer they will turn into a cancer. That developer that’s never happy, can’t focus on the job to be done and always conducting “science experiments’.
The solution? As a team triage the friction, pain points and/or technical debt issues and come to a consensus on the right approach for the team and the company. Then rotate developers responsible for becoming catalysts for those issues. This gives everyone a chance to have some desert and have some skin in the game.
Resgrid is a SaaS product utilizing Microsoft Azure, providing logistics, management and communication tools to first responder organizations like volunteer fire departments, career fire departments, EMS, search and rescue, CERT, public safety, disaster relief organizations, etc. It was founded in late 2012 by myself and Jason Jarrett (staxmanade).
