Submit captions for this cartoon of “The Moverick” in this post’s comments. And don’t forget to submit captions for the other Software Engineer Types as well…
The Maverick
The Maverick will do your feature IF he can do it in Ruby on Rails. Or Haskell. Or Python. Or <other hot new language that his peers don’t know and therefore can’t evolve or maintain>.
And, NO, this type of Maverick has nothing to do with John McCain or Sarah Palin. Well, probably not.
Distinguishing Characteristics:
- Smart. Creative.
- Doesn’t want to build on or maintain the existing codebase (because it’s a spaghetti nightmare AND because it’s written in Java, which is sooo passe), so he’ll roll his own. This will include the creation of an exotic protocol and adapter layer so that the old code can call his code.
- Dependable — if you let him do it his way.
- Magically finds his way off the project if he is not permitted to build in his preferred language.
Project Pitfalls:
Oh, you’ll get your feature all right, and you’ll get it on time and it’ll probably be done well and it may even delight you and your users, but once that guy leaves someone is going to have to refactor it in order to evolve it. And we all know there are few words a PM likes less than “refactor”.
Achilles Heel:
Back in my hometown, we used to say “That dog won’t hunt” when referring to someone who simply and inexplicably will not do the obvious, such as build on the tech stack into which he was hired.
Do you need this engineer?
Maybe you could aim this smart engineer at a custom one-off or a stand alone widget that doesn’t need to be evolved or maintained. No.
Best Bet:
Be prepared to make your perfectly reasonable case for building the feature in the existing language in a public forum. Make said case without emotion, and in front of his peers & manager because, trust me, they don’t want to support his alien creation any more than you want to.
Submit captions for this cartoon of “Offshore” in this post’s comments. And don’t forget to submit captions for the other Software Engineer Types as well…
Offshore
Where are these guys, anyway, and what time is it there? Who knows; you always have to count the time difference on your fingers.
But anyway, they seem very nice, and they do try to read the documentation. They just don’t always understand it and it’s not their fault that they were home sleeping when those critical changes were decided last week.
Distinguishing Characteristics:
- Located in Malaysia, China, or a former Eastern Bloc country. (Ukraine is the new India).
- Their proper English is downright charming.
- Sometimes they say they understand when you know they don’t.
- They make a lot more work for you, including having to attend 9PM meetings. On the upside, it is nice to have a glass of wine in your PJs while discussing the desired behavior of wildly far-flung corner cases for no other benefit than that of QA.
- Will often do the needful.
- Sometimes their code isn’t great. But, as I have mentioned, they are generally quite polite.
- ARE ULTIMATELY NOT CHEAPER. But we’ll let CPM cover that topic separately.
Project Pitfalls:
Too many to count on your hands.
Achilles heel:
Communications.
Best Bet:
- Document the hell out of your requirements and functional specs.
- Provide completed mock sets,including exception scenarios.
- Keep up with change requests.
- Meet with them often, and for God’s sake speak slowly (but not louder, because duh) and speak clearly
- Stop the meeting conversation often to see if they have any questions.
- Also, I know you don’t want to hear this, but for best results, you really should just go there for a week or so.
Submit captions for this cartoon of “The Great One” in this post’s comments. And don’t forget to submit captions for the other Software Engineer Types as well…
The Great One
Where did this engineer come from, and can you have five more of him?
Distinguishing Characteristics:
- Always delivers on schedule, even when unforeseen code bottlenecks require more time that initially estimated.
- If unforeseen bottlenecks arise, you don’t hear about it from this engineer. Instead, you hear about how this engineer worked all weekend from one of his peers.
- Respected by engineering peers. Professional in meetings.
- Honest with estimates.
- May have a Star Trek accent or a superhero fetish. Loves watching “How It’s Made”.
- Solid code, sometimes delivers more than what was requested.
- After the feature is launched, asks whether it met the users’ needs.
- Keeps up with his bug queue.
Do you need this engineer?
Um, duh.
Project Pitfalls:
Try not to hug this engineer in public. He gets embarrassed and human contact is sometimes confusing.
Achilles Heel:
This engineer is so dependable that his manager tends to put him on every project. He sometimes has trouble saying “no”, so can become overstretched. Also he tends to be optimistic in his estimates.
Best Bet:
- Give lots of public credit to this engineer, even if he doesn’t care about that — because his peers might.
- Send nice notes to his management.
- Don’t ask him to attend time-waster meetings, but if he must, publicly change the agenda to accommodate his part first so he can leave quickly.
- Add time to his initial estimates to buy him some wiggle room.
- Play Halo with him
- Bring him food.
- Ask how you can help him, and ask often.
- Encourage this engineer to breed.
