A good developer can be a real work horse. Old timers know that work horses typically have blinkers on them to prevent them from getting overwhelmed by distractions. A few developers can handle the distractions, many are either not interested or overwhelmed.
What are a few of the distractions? What may they not see?
- Developers are addicted to making something work, like a kid building with LEGOs.
What they may not see are items like:
- Does it perform well? Often a comment like “it’s fast enough” indicates a blinker
- Does it scale well? Often a comment like “Just get faster/more hardware” indicates a blinker
- Is it secure? Often a comment like “Just needs to be correctly installed (installation is not my job)” indicates a blinker. An example:
- For a web application, does it have it’s own named app pool? If not -- security risk.
- Is the identity that the app pool runs under, a built-in identity? If not, – security risk
- Is it maintainable? Often a comment like “Any competent dev can maintain it” indicates a blinker
- Is it documented? Often when a product is delivered, the documentation is stale and often contradicts the implementation. ‘Does the kid put away the LEGOs after playing with them?’
On one of my LinkedIn groups (IATA), there’s a discussion on burn-out. One important point made is that often a developer is expected to know and do everything – often things that they have had no training or experience in. This is often the source of stress that leads to burn out. They know some technology and thus it is inferred that they know all technology. This is a wrong and dangerous assumption. It’s like assuming your dog’s doctor (vet) can perform human heart surgery because he has a doctor’s degree in medicine…
There are a few family doctors that may be able to do so… I recall seeing on MD door in Montana where the doctor ran a joint practice: Mondays-Tuesdays – humans, Wednesday-Friday – animals. He has both a Vet and a MD – talk about whole family practice!
When I have managed teams, one of my first goals have always been to understand the experience of each member and where they want to go. Usually, it results in a map with some significant gaps. Then it’s a matter of mentoring or hiring to fill the gaps. In the worst case (like no $$ for hiring or training), it means that I end up having to step into the gap to get the job reasonably done…
Be aware of blinkers --- if not, your developers may walk over a cliff and pull you, the driver on the wagon behind these work horses over the edge (if you are quick, you may be able to jump off the wagon in time…).