How to be a developer | Part 1
Hi, everyone. We’ve been wanting to do one of these episodes for programmers and developers forever, but none of us have ever worked as one, so that made writing this episode a little tricky. Fortunately for us the guys down at StackExchange have heroically stepped in and offered to make this episode happen. In fact, they offered up so much great information that we’re going to make this a two part-er. For those of you who’ve never heard of them, StackExchange is a great resource for developers. Pretty much everyone I know goes there when they have questions. Especially if you’re starting out, put it on your list of places to visit. All right, onward, programmers, or as many of them prefer to be called, developers. What do they actually do? Most people have a vague image of a guy sitting in a basement in front of a computer typing arcane commands into a terminal and chugging Mountain Dew. Of course, there’s much more to it than that. What does it mean to be a developer?
Like most jobs, developing software takes on a lot of different forms, but the heart of it comes down to problem solving, designing a new system architecture, implementing a feature, finding and fixing bugs, all of these come down to analyzing a problem, breaking it down into its essential pieces and coming up with a solution. As a developer on a team, you can pretty much consider yourself chief problem solver. What does that kind of problem solving look like? David here had a pretty helpful anecdote. The third class he took in his computer science program was designed to introduce students to real world software development, and he thought that sounded great. They’d get to work on some real world problems that people have, so he was a bit surprised when they got their big group assignment that counted for most of their grade. He and his partner were told to build an M&M sorting robotic arm using Legos, a pair of servo motors and a webcam. This was very different from other classes he’d taken up to that point. Those were pretty straightforward, here’s a loop, now go write a bunch of stuff using loops.
This class was asking him to do things they had no idea how to do. There was no chapter in the textbook on sorting M&Ms. There was no website they could go to with a tutorial on how to build a robotic arm out of servos and Legos, at least there wasn’t then, there probably is now. They just had to figure it out. Now one way to look at this would be to say that he spent four weeks learning some truly useless skills and since that class he’s never worked with servo motors, webcams, path finding algorithms or M&Ms but in reality this turned out to be exactly what real world development is like. The next summer he got an internship at a real software company, and the first day he showed up, he was given an assignment working with technologies he’d never heard of, solving problems that nobody at the company had solved before. Real development is about solving problems whether you’re a game developer working on a physics system, a web developer working on a user interface or a quantitative finance developer working on a new financial model, it all comes down to breaking down the problem and finding a solution.
Analyze the games you play and the software you use to figure out what makes them work, why did the designers did it the way the did, how they could’ve done it better. All of these things will build up your analytical thinking and make you a better developer. This touches on the second most important trait of a developer. Every developer has to solve problems but what separates good ones from great ones is their ability to solve them quickly and elegantly and often what makes the different there is having a wide body of tools and experience to draw from. Think of it this way, I’m pretty sure that if you gave me the tools, I could make something resembling a tree house. Now give those same tools to a real carpenter, and he would do it much faster and end up with something much less likely to kill you. The different between me and the professional is that the professional knows what tools to use for each job, specific techniques for solving problems he’s seen before and a whole lot more about what needs to be done. The same applies to programming. What separates the experts from the novices is a wide knowledge of what tools and techniques exist and a deep knowledge of when and how to apply them.
How do you get better at this? By being an explorer. Computer programming may have been around a while, but it’s still very much in its infancy. New techniques and approaches are being developed all the time. If you want to be a great developer, you need to stay on top of these changes. When new languages, frameworks, techniques or methodologies surface, explore them and see what they can tech you. Don’t just read about them, get your hands dirty and write some code. You may find a new tool that’ll be perfect for a job someday or a new library that does exactly what you need, a language that’s tailor made for particular problems, or you may just learn a new approach to solving problems. The goal is to accumulate as many tools on your tool belt as possible so that when the time comes, you’ll know exactly what to use. Unfortunately, exploration is generally discouraged in the workplace often for good reason. Your boss doesn’t want you to be constantly trying out the latest technique or language on a critical production system, so most of your exploration will happen on side projects outside of work, and that’s just part of being a good developer.
The best developers are constantly writing code and exploring new tools and techniques in and out of work. Of course, exploration also means learning from other people. Everybody approaches problems differently so looking at how other people solve problems is essential to widening your perspective and learning to be a better developer. There are a few different ways to do this. First, read other people’s code. There’s a wealth of sample and open source code available on the Internet. Don’t be afraid to take an existing project apart and see how it works. You’ll learn how they structure the project, how they solve particular problems and probably what they could’ve done better. Second, find smart developers to work with. If you’re a student, try to get an internship at a company where you’ll be writing production code. Find an open source project that interests you and start submitting fixes and suggestions. When you’re on a team, seek out the more experienced developers. Look at their code and ask them to critique yours.
Finally, get involved in the broader community. There are a dozen places to do this online, Hacker News, GitHub, IRC, even good old Slashdot or Stack Overflow. Better yet, get involved in open source and give back to the community. If you’re in a major city, find a local developer group to meet up with. All of these will help you to explore the wide, wide world of programming. They’ll teach you new ideas, new techniques and new ways to solve problems. That’s it for part one. Next week we’ll be back to talk about the importance of communication, as well as many other skills a developer needs.