I've joined a team of around five developers building a microservice-based website, in a shop that emphasises autonomy and learning. However, it turns out one of the developers is writing "his" parts in his favourite new language, X.
I won't name X to avoid religious arguments, but instead list why I'm concerned:
- X is new, relatively obscure, and seems more aimed at writing command line utilities, not web service APIs
- it's evolving fast - apparently on going to document some older code, some base functionality had been removed, wouldn't compile in newer versions, so took a couple of days to re-implement it.
- there seems little prior art for how to approach a given task in X. An upcoming request is to add searching to API endpoints. He has no idea how to go about this, happily admitted each endpoint is implemented differently and "might re-write the whole thing". I like his can-do attitude, but is this really how to approach production code?
- the other developers are clearly uncomfortable with X despite some months of exposure. I've seen live site issues from deploying broken code when he was out. Yes, a conversation is needed around testing, but them not being able to spot showstopper errors in X is a red flag
- He's started adding plugins to other services, "to make them more X-like". Not sure yet what that means.
- etc. etc.
He's a pleasant and approachable person. He's not arrogant or argumentative or anything like that. He's just really, really into X, dropping it into every conversation, including to non-technical people. It's nice to see he's passionate, yet it's bordering on obsession.
I'm his new line manager, concerned about both the low bus number and the clear day-to-day risk from brittle, hard-to-understand bags of X.
While I could ask him to stop using X, it clearly wouldn't go well, and anyway I want my team to be autonomous and happy, building them up, not shutting them down. And yes, I am setting time aside to learn what X I can. Perhaps I'll see the light and I can help him that way.
How can I handle the risk to the project presented by X? Is X itself even really the problem?