Should you try to be more of a specialist or a generalist? That was the most debated point in the discussion. At Aptera, a group of us are reading Chad Fowler's fantastic book The Passionate Programmer and were discussing the first section. There were many things that we all agreed on, like the importance of not letting a lack of perfection prevent progress, and, especially, the importance of continuous learning for the software developer.
The chapters that generated the most discussion were chapter 7, "Be a Generalist," and chapter 8 "Be a Specialist". These seem like contradictory ideas. But Fowler does a great job showing how these ideas not only coexist, but complement each other. And, as one of my teammates pointed out, to become and specialist, you gain skills in other areas as a byproduct.
At this point it is important to clarify what we mean when we use the word specialist. As Fowler points out,
"Too many of us seem to believe that specializing in something simply means you don’t know about other things."
He goes on to say that being a specialist means that you have a deep understanding of a technology. Being generalist means that you know about many technologies.
This discussion led me to ask myself how I can become a better programmer. Are there things that I need to know at a deeper level? Are there more things that I need to know at a broad level? Which of these is more important?
If I’m evaluating my skill level as a programmer, I might think that what I need to do is rate my programming mastery on a scale of 1 to 10 for my language of choice. For me, that’s C#. I might rate myself as an 8. That sounds good, right? But that’s a very one-dimensional view of things.
Eight of ten seems pretty good at first.
If I’m a C# specialist, I need to know about many other things to be effective as a developer providing value for a customer. I need to know about .Net Framework, including the base class library and the runtime. I need to know about a framework for creating applications. I need to know about development and debugging tools as well. To get a more accurate view of my skills I need to rate myself on all of these dimensions. It might come out looking something like this:
No technology stands in isolation.
I might rate myself as 8 out of 10 in C#, but I need to evaluate how I rate in the surrounding technologies if I want to know how productive I can be.
But these dimensions just represent programming skills. To be successful as a programmer, there are other layers of skills that are necessary as well. There is a whole set of skills I need to master related to the systems my applications run on. There is a whole layer of things I need to know about the software development process. Interpersonal skills and communication skills are also critical. As my fellow Software Architect Jon Fazzaro said in our discussion, "It's less about text files and more about people." When I think about all of the things I need to know, the graph starts to look like this:
Looking at all of the development skills gives a clearer picture of ability.
One of the brilliant points that Fowler makes is that there’s a whole layer related to business that most programmers overlook. You need to know how your business works. If you’re a consultant or a contractor, you also need to understand the business domain of your client. Fowler goes on to say:
"You’re not going to be able to sit back and simply master a programming language or an operating system, letting the business people take care of the business stuff. If all they needed was a code robot, it would be easy to hire someone in another country to do that kind of work. If you want to stay relevant, you’re going to have to dive into the domain of the business you’re in."
When I think about the things that I need to know in order to be an effective developer, my self-evaluation should be much less like individual values and much more like a connected landscape. It could even be described topographically. If I want to excel in a specific area, I must have a deep knowledge of the technologies, business processes, and soft skills surrounding it.
Given this multidimensional view of what my skill set needs to be, I can now think about what it means to be a generalist and specialist. I might think that being a generaliist just means that I know a little about a lot of different things. My skill chart might look like this:
It isn't a bad thing to know a little about a lot. But if I don't have a deep knowledge of any particular area, I will eventually run into a tricky problem that I simply won't be able to solve on my own. There needs to be something, or a few things, that I know deeply.
On the other hand, I might think that I’m a specialist because I only know about one thing. My skill chart might look like this:
It isn't bad to know one thing deeply. But if I don't know about the surrounding technologies, there are going to be problems that I can't quickly solve. For example, let's say that I’m a web developer who only knows about how to program C# for ASP.Net. If I’m having performance issues, I am going to try to solve them by improving the code. But this ignores a large range of potential solutions. Maybe there are ways to tune the server to get better performance. Maybe I could tweak the database so that my queries run faster. There are lots of things that could be done, but I can only implement them if I know enough about those other technologies.
Similarly, there are times when I might have a tricky bug with a corner case of the business logic. If I know enough about how my business works or who in my organization is in control of those business rules, I might be able to find a solution that improves a company process instead of trying to come up a with a purely technical solution.
Ideally, programmers will have some things they know very well and will be competent in many other things. We had a good example of this recently. At Aptera, we have provided a large number of successful products that are built on Telerik's SiteFinity platform. We have developers who know that platform extremely well. Recently, one of the teams was investigating a performance problem on the staging server. One of the teammates was able to track the issue back to an installer that had run on the server but had not finished correctly. It was consuming a large amount of memory, which was slowing down the IIS instance on the server. The programmer was able to identify the problem because he not only knew about SiteFinity, but because he knows how to do some server maintenance as well.
From a career standpoint, there are many benefits to having something that you know deeply. If you are the expert in a subject, you become very valuable to your employer and to your clients.
It is similar to how some vehicles are more valuable than others. Think about the difference between a Lamborghini Aventador and a Dodge Caravan. Both vehicles are capable of getting you from point A to point B. The Caravan is a good general-purpose vehicle. There are many things that it can do. There are some things it does much better than the Aventador. How many car seats can you fit in the Lamborghini? But the Aventador does a few things incredibly well. It does some things that few other cars can do. This means that it can charge a much higher rate. The same is true for developers. If there are things you can do that few other developers can do, you can get more money for your work.
At the beginning of this post, I asked a simple question, should I be more of a generalist or more of a specialist? I think the answer is that I need to be both. There are a few things that I need to know deeply. Deep enough that I am prepared to solve complicated problems that my teams encounter in that technology. There are many things that I know broadly. I need to know enough about them that I can leverage those technologies to solve a wide array of problems my team might encounter throughout the life cycle of a project.
So what should you do with this information? Evaluate yourself. Are there a few things that you need to learn deeply? Are there areas in which you need to learn more broadly?
Obviously, it would be impossible to know about everything in the field of software development. There is too much to know and it changes too quickly. But that doesn't mean you can't benefit from learning more broadly. If you want to understand your language better, you might want to learn a different language, especially one from a different paradigm. Learning other languages helps you understand your primary language better. Are there tools in your development process that you don't know much about? Dive into them and see how they could benefit your current project or a future project.
One important way to do this is to be willing to learn from anybody. Fowler calls this "being the worst". The most junior dev on my team might know more about some topics than the most senior dev on the team. Be willing to learn from all of your teammates.
Figure out where you are. Figure out where you want to be. Make sure that you are becoming more of a generalist and more of a specialist. Make a plan for how to get there.
Popular posts like this: