Note: I intend to include more technical, work-related stuff in the blog now. That shouldn’t be terribly distracting to two or three of my readers, but I’d like the other two or three not to give up just because this is getting nerdy.
I was visiting a nine-month-old SpaghettiCode podcast the other day, and they were talking about the gap between an application’s users and the developers that wrote it. (They were trying to pick trends for 2009, and focusing on a Microsoft offering that will allow more business-line users to build application-like things out of developer-approved building blocks.)
The conversation turned to the topic of power users, who exist in between the business line user (who basically wants to get his work done) and the developer (who lives in the technical world, maybe to a fault). The power user writes long Excel macros to get his job done, or constructs an Access database / application that does 90% of what an enterprise app might do. 90% of his day is spent on business and working, but he’s willing to use every tool on the desktop to get that work done – he won’t wait for the IT department to put the app on his desktop to start working on it.
What I kept thinking during the conversation was that power users become developers. In fact, I’d even go so far as to say that there is a pretty sharp dichotomy between the developers that trained in school / under a mentor, and those who picked up software development through more and more advanced business problem solving methods.
I am one of the latter, even though I was introduced to object-oriented programming in college. If that doesn’t count, I was certainly introduced to professional software development by someone who came in the Access / Excel door. I feel like power users who become developers have some advantages over purebred developers, but there are disadvantages, too.
Hire That Hack…
The self-taught ex-business developer has one huge advantage, if he can take advantage of it. He is a user, so he understands the user. He has user empathy. The purebred developer can certainly learn the domain, but if she hasn’t lived and breathed it, it’s a different kind of understanding. Business logic and user experience should be his strong suits, and it’s possible that he’ll be more versatile and diplomatic in interfacing with the business user.
Self-taught developers are self-starters, and won’t necessarily lean on “their way” of doing things. They clearly remember a time when they “didn’t know”, so with any luck, they’ll be flexible about new ideas, new approaches, and even new languages. If your developer’s developer was taught C#, she might feel like she’s specialized in that area and not comfortable or confident stretching into a new area.
…But Not Just Any Hack
The self-taught developer, left to his own devices, can build some seriously complicated stuff in whatever macro language he picked up. He may have found object-oriented principles in time to prevent the whole thing from collapsing. Whatever he knows, there are things that the purebred developer does that he’ll have to learn.
First, formally educated developers are taught to work in teams. (That doesn’t mean that they necessarily learn it, but they’re at least exposed to it.) Your developer might lock herself in a Mountain Dew-fueled cave of code, but she’s an order of magnitude more transparent than your self-taught developer ever had to be. He only ever had to code anything for himself, and as the only developer, he never showed the code to anyone. Collaboration might come naturally to him, but he’ll start out behind.
His vision of requirements was “what I needed to get my job done”, and then “what I felt like was missing”. Again, that develops a strong sense of user experience, but it doesn’t practice any of the areas of the brain required to read and understand someone else’s project plan. Having only developed for himself, he probably hasn’t ever documented anything. And if he ever ran into a problem, he probably ran to Google to solve it. While those long lectures on pointers and tree structures seemed unnecessary to her at the time, she’s got a foundation in principles that he can’t pick up by copying other people’s code. (There is some seriously weird advice out there on the internet. Google helps you find it, but sometimes that’s no help at all.)
All of these skills are learnable across this divide. There are certainly productive, happy developers on both sides, and both camps count their share of woeful wrecks. But developers that operate at a high level in both the technical and business-facing sides of their jobs, no matter where they came from, are always a joy to add to the team.