Tuesday, February 25th, 2014

I was recently asked: “What does it mean to be a developer? What are some traits that you think successful developers should have?”.

I certainly don’t have the answers for a question like that. But I do have opinions. I shared them with my friend, but I think it may also be worthwhile to share them with you as well.

Ultimately, “being a developer” comes down to one thing: a developer writes code. This, of course, is a pretty broad definition.

Because it’s so broad, there are a lot of paths to being a developer. Traditionally, you might think of analytic “mathy” people being developers. And that’s certainly true, and it’s where the roots of the industry lie. But creative “artsy” people can also be great developers. And, because the world is not easily broken up into two sets of people, there are all sorts of other kinds of people who can excel at software development.

But different people can approach the field different ways and look for different goals. It takes a hard-core mathematician to work up solid and correct encryption software, but that person may not be the most suited for building something like Facebook’s recent Paper app. Some people will like to work out their software on paper before ever opening a text editor so they know exactly what they’re building. Others like to explore and make mistakes and figure it out as they go.

Because I’m only one person, I can really only talk about what it means for me to be a developer. I’m not a representative sample by any means and your mileage may vary.

And I, without question, fall on the side of building things as I go and learning and exploring. When I was in school, I noticed that there tended to be two sorts of students in lectures (and here I will pretend that the world is, in fact, easily broken up into two sets of people): those who would raise their hand and ask “What about when you do {X}+{Y}+{Z}?” and those who would just type “{X}+{Y}+{Z}” into their laptops to see what would happen.

I was definitely in the latter set. One of the things that I love about computers so much is the way they make it so easy to just try and see. They make it so easy to just try and fail. And when you try and see and try and fail enough times, eventually you learn something. And then it’s on to the next thing. And then the next.

And sure, there’s a ton of advantage to reading and taking classes and what have you. The good part of a CS education isn’t so much that it teaches you to program (which schools do poorly and only because it’s necessary), but because it gives you a good idea for the shape of problems: so when you find a new problem that sort of looks like problem {A} but also looks a little like problem {B} when you squint, you know what to Google for.

I find that programming, at its best, is a creative endeavor: it’s taking a problem and figuring out how to solve it within a set of constraints. And a lot of that can be taking different solutions for similar problems and squishing them together. Sometimes it works, sometimes it doesn’t: but it’s almost always fun.

So when I try to come up with the things that I think make me a good developer (and again, there are so many different kinds of developers that this cannot possibly be representative), the list starts to look like:

  • Experiment. Try things. Fail. Learn. Repeat.
  • Tinker. Try new technologies, languages, techniques. It’s not about developing mastery: it’s about seeing the shape of the industry so when a new problem appears, you have a wide body of experience to be able to say “Hmm. I think if we combine technology {A} with service {B}, it might get us close to a solution.”
  • Read. Read about all the things there are to tinker with. Read about directions and new ideas and exciting people. Read all the things that the best developers are writing about their craft. Sometimes they’ll be right. Sometimes they’ll be wrong. But they’re always full of exciting ideas about the industry’s history, future, practices, failures, and so much more. There’s no substitute for experimentation and tinkering, but there’s just so much to learn and so little time that we have no choice but to follow in the footsteps of giants.
  • Always Be Coding. Developers love programming. It’s in the blood. It’s one of the most fun things you can do. Create things. Throw them away or ship them, it doesn’t matter. Then create some more.

There’s so much about programming, so many areas to focus on. And I don’t have advice about any of that, because all I know to do is to chase all of it. Like a dog chasing a car, you’ll never catch it: but that’s just not the point.

Good luck.