Few things seem as institutional to the programming world as what I call the experience tuple. A company needs to hire someone to automate something, so, naturally, it asks the software development group to make alphabet soup for dice.com. “We need someone with (C#, XML, HTML, JS, ASP, MVC, REST, Angular, AJAX) with (React, MSTest, Moq, CSS) as plus.” Presumably then, polyglot applicants stand a better chance. But I’d argue that they also face something I’ll call the polyglot’s dilemma.
Hold on to your hats, programmers, because this will get counter-intuitive before it makes sense. With that in mind… where to start?
Problem Solvers and Problem Transformers
Well, perhaps categorizing hired software developers as problems makes for a good start. I don’t mean problems in a negative sense, but rather in the same vein as puzzles. A business hires software developers for some broader purpose. Maybe they work on internal automation that reduces operating expenses. Or perhaps they produce software sold as a good or service and add to top line revenue.
In either case, the business implicitly says “I need help increasing our profitability.” And you show up saying the following.
I have (8, 10, 10, 4, 6, 3, 1, 1, 0) years of (C#, XML, HTML, JS, ASP, MVC, REST, Angular, AJAX). Now while the rest of you figure out how to make use of me, I’ll be over here sharpening the saw with some code katas.
Whenever I’ve had management responsibility, I’ve subconsciously put people into two buckets. Problem solvers take a problem I have and make it go away. Problem transformers take a problem I have and solve it by bringing me the next problem. (I’m omitting non-performers who don’t solve problems at all as beyond the scope of this post.)
For instance, take the problem of a malfunctioning production server. A problem solver would go off and come back with a functioning production server, somehow. A problem transformer would come back, report that the problem was caused by a faulty power supply and ask what I wanted to do about that new problem.
As programmers, we behave as problem transformers. We present ourselves and our skill sets as problems in need of management solutions.