Once not too long ago, there was a software craftsman. Since he was a boy, he had enjoyed solving problems using a computer. After college, he found a job as part of a team developing a software product sold by a company. Here he thoroughly enjoyed mastering the target language and platform and applying his problem solving skills to attack thorny issues in design.
After several months had passed, though, a new kind of problem started coming up. The company’s application suite had become so successful that it needed to scale better. Several of the modules that had performed reliably at the load levels for which the system had been designed, now were beginning to exhibit quirks and anomalies, and some of the larger clients were beginning to complain.
This problem presented a great opportunity for the craftsman. He now had the opportunity to gain some valuable firsthand experience with the “-ilities” – in this case, scalability. This was his chance to leave junior-level coding far behind and begin to become a real leader.
But the craftsman didn’t see the situation that way. His view was twofold: first, applications shouldn’t need to be scalable; and second, if an application isn’t already scalable, there’s nothing you can do about it or the company that produced it. The craftsman held this view so strongly that once the need for scalability was clearly demonstrated in several applications in the company’s suite, he left the company. Thus began a pattern for him – whenever scalability became a real problem at his company, he would say “This shouldn’t be necessary, and nothing can be done!” and walk out. Throughout his career, he grew in many areas, but he studiously avoided ever growing in this one.
During a talk about estimation practies at the Indy Alt.NET meeting Thursday, our speaker touched on a few issues developers not uncommonly face at companies and spoke of the joy of being an independent contractor. I’ve thought about this topic before, but this got me thinking again. As software craftsmen, we are professional problem solvers. When a new class of technical issues comes along (because of a new platform, a new disruptive technology, etc.), we may groan and complain at first, but in the end it’s a great opportunity to apply our problem solving skills to a whole new kind of problem. It’s when we are tasked with solving a kind of problem we don’t already know how to solve that we grow the most – would you agree?
I wonder why, then, when the “kind of problem we don’t already know how to solve” is a people problem (negotating project timeline with upper management, navigating conflict with boss or co-workers, etc.), we sometimes feel free to walk away from our company without learning, without even trying to solve the problem. “Solving this type of problem shouldn’t be necessary, and anyway nothing can be done!” we say, despite much study having been done on the subject*. If it were a technical problem that drove a software craftsman away in this fashion, I would be tempted to see them as lazy for not making the effort to make use of their problem solving skills in this situation…
“But that’s different!” you say.
*For instance, William Ury et al’s excellent Getting to Yes and Getting Past No…