The Perks of Being a Generalist

DevOps and Generalists

Once upon a time, a developer wrote a function to retrieve a list of items from a database. He wrote 40 lines of code and tossed it over the wall to the database guy. The database guy reviewed it, wrote a stored procedure, and threw it over the wall to the test guy. The test guy clicked around the application to make sure it worked and then handed the code to the deploy guy. The deploy guy put it in the queue and it went out with the monthly deploy. After all that, the sysadmin noticed something wrong in Production.

Then, everyone started pointing fingers.

That time is over. Developers are now the coder, the DBA, QA, and the sysadmin. This is a good thing. While it’s hard to expand beyond what you’re used to, the product quality is much better when developers are involved in every layer of the stack.

When every team member is informed and involved, the team can have meaningful discussions and make better decisions in more situations. On the other hand, if team members in different roles are cut off from each other, developers are forced to make uninformed guesses about the impact their code will have on the entire application stack.

Blind Spots

Code doesn’t live in a vacuum. When a developer writes code to show the user a piece of information, that code is not computing bits and pulling the data out of the air. The code will hit a database, pull something from cache, rely on front-end logic for display, and probably touch a dozen other parts of the application. And all of this uses processor, memory, and network resources.

Without knowing or thinking about how all these different systems work together, it’s likely you’ll introduce bugs. In the best case, these will be small bugs that can be corrected. In the worst case, entire chunks of code must be stripped out and rewritten. since the code was written in a way that fun­da­men­tal­ly will not work with other parts of the stack.

Simply put, your code will be a better citizen if it understands the infra­struc­ture and world it lives within.

Learning multiple languages, frameworks, design patterns, and tech­nolo­gies help make you a better developer. If you look in your toolbox and all you see is a hammer, you’ll squint until all you see is a nail. On the other hand, if you have a wide range of tools to choose from, you’ll build something better with the tool that’s perfect for the job. That new thing you just learned about may just be useful in a problem you’ll be digging into months after you learned it.

The ​“T” Model

I’m not suggesting you reject deep-diving into a specialty. At Hudl, we embrace the ​“T” model. An engineer does well by working broadly across a number of subjects (that’s the top of the ​“T”), while focusing on a specialty and becoming the authority on their specific area (that’s the deep vertical bar of the ​“T”). A developer may work comfortably in JavaScript or MongoDB, for example, but he is also the go to guy for video encoding. If an engineer is working on code that touches video encoding, she immediately talks to him for pointers on best practices or for a code review.

Getting Out Of Your Comfort Zone

A die-hard specialist shouldn’t think this is a zero-sum game. If you learn a new skill, you won’t lose your old one. I like to think that having mastery in one subject gives you freedom to start branching out. Consider your expertise a fantastic asset and start branching out hor­i­zon­tal­ly. If you’re already an expert at Ruby and thinking about diving even deeper into the language, think about the enormous benefit of learning something new compared to the marginal benefit of sharpening a saw that’s already pretty sharp.

Programmers are notoriously stubborn and impatient. If we think we know how to do something and can do it quickly, that’s the way it gets done. Developers are curious by nature, but under the constraints of time and overflowing bug trackers, we’ll inevitably fall back to our comfort zone.

How should we start finding a better way to get where we want to go?

• The obvious thought is to find a tech book you’re interested in. Books are great to give you a high level view, but your under­stand­ing will stay shallow until you have a reason to put that knowledge to use.
• Something amazing happens when you put your fingers on a keyboard and start typing code. The brain absorbs and understands what you thought you understood in a new, clear way. The best way to learn something new is to work with it in a project that you’re passionate and concerned about. Giving your brain a story for what you learned increases retention dramatically.
• Keeping up with developer blogs and twitter feeds is a good way of keeping your mind fresh. Many talented developers put their work in public places and we can benefit from reviewing it.
• Following GitHub repos­i­to­ries is another great way to watch development happen in areas that interest you.

Finally, the best thing you can do is talk to other developers. Look at their code. Ask them questions. Programmers are curious just like you, and they’ll almost always be excited to talk about what excites them.