How to be a developer | Part 2
Let’s review what we’ve discussed so far. Development is all about problem-solving. Breaking a problem down and finding the right solution. To do that, you need to be a great analytical thinker and a professional tinkerer who can take apart any digital system, understand how it works and put it all back together. The best problem solvers are explorers, who are constantly learning new tools and techniques on their own and from other developers.
Today, I want to start by talking about the third primary skill of an effective developer: communication. If you’re going to be working with other people, and you are. At some point, you’re going to have to talk to them. Most developers don’t really like this; they like to imagine themselves as the lone wolf hacker, tearing through code into the wee hours of the morning. Free of stupid time syncs, like meetings, but the reality is that real development almost always happens in the context of a team, because there’s a limit to what one developer can do. A well-coordinated team can tackle bigger problems, play to each person’s strengths and solve problems faster and better than if any of them had done it alone.
One developer who’s bad at communicating can wreck all of that. When people aren’t talking to each other, the various pieces don’t line up, the wrong problems get solved. Assumptions are made. Bugs creep in and projects run late. This is just as true for working with non-programmers, as with fellow developers. Somewhere on your team, there will be a manager or an artist or a marketing person who is vital to getting the project finished and out to the end users. If you weren’t communicating with them, they can’t do their jobs and the product will suffer.
Take a deep breath, listen to what they’re saying again. Assume until proven otherwise that they’re just as good at their job as you are at yours. A team that communicates well will always get better results than a team who doesn’t. At this point, we’ve pretty much covered what it means to be a good developer. Of course, there’s much more to it than just the big picture stuff. Here are some more specific tips and skills you should pick up as a developer.
Number 2: estimation. The software industry is famous for blowing through deadlines, sometimes by months or even years. Some of the is feature creep. It’s very hard to resist adding just one more feature, but just as often it’s due to developers who are bad at realistically estimating how long something will take. Actively work on your estimation skills. Break down each piece and estimate each component. Record your estimate and see how long it actually took you and figure out where you went wrong. If you’re not evaluating yourself, you’re not going go to get any better at it.
Three: microeconomics. If you can’t talk the basic languages of economics: supply, demand, opportunity cost, game theory and all that, you and the suits are just going to be talking past each other. Most of the real decisions on a project will be influenced by money. A lot of the programmers make themselves irrelevant in the decision making process by insisting on only thinking about making the software perfect instead of what’s best for the business.
Four: basic user interface design. It’s basically unavoidable. At some point in your career, you’re going to have to make something that an actual person will use and most bad interfaces come from programmers. Understand common UI metaphors and when to use them. Accordions, modal dialogs, buttons, icons, tabs, folders, all that. Learning to see it from the user’s perspective can make all the difference. You may not be enough of a designer to make it beautiful, but every programmer should be able to make something usable.
Number 5: low-level languages, like C and Assembly. You may not use them everyday. In fact, you may never use them, but the abstractions of all the higher level languages are built on the same basics of pointers, branching and arithmetic. At some point in almost every industry, performance becomes an issue. Understanding how the code works at a low level is the only way to get high-performing code.
Six: understand how computers work. This means understanding computing hardware, networking and operating systems. Most of the details of these things are nicely abstracted for you 99% of the time. Some day your team’s going to have to deal with packet loss or page faulting or hardware failures. You don’t want to be playing catch-up then. Having a solid understanding of how all these systems work will make you a better developer.
Seven: just start programming. If all of this seems like too much to figure out right now, it’ll never hurt to just get more programming experience under your belt. If you’re watching this on a computer or over the internet, you already got everything you need to start programming so get to it.
That’s about it. Once again, very big thank you to our friends at gamedev.stackexchange.com for their insights into game development. Again, if you’re interested in becoming a programmer, definitely make some time to check them out. Even if you don’t want to be a programmer, StackExchange has opened up a pretty neat site to ask and answer more general questions about games, which you can find at gaming.stackexchange.com. Thanks again fellows. I think you may have helped at least a few people better understand how to pursue this career. We’ll be back next week to kick off another multi-part series.