Often teachers only have a very limited amount of time, just enough to grade the work they give out. They can’t be giving the type of instantaneous feedback that students need to be able to rapidly iterate on problems and test out new solutions or theories they might have, and that’s absolutely not the fault of teachers, but it is an artifact of our educational system’s past that persists into today. When our educational system was created nearly 200 years ago, this sort of drill was the only option, and schooling itself was preparing young people to enter careers that were much more dependent than learning things by rote, factory work, basic shopkeeping. It was preparing them for a world where you couldn’t just look up something on the Internet or pop onto Wikipedia. Today on the other hand, we need to prepare students to find innovative solutions. We need to prepare them to apply the limitless data we have in front of us to solve whatever problem is at hand. It doesn’t matter if it’s a job in IT or the most esoteric medical research, almost all of our decent jobs today require innovation. They require you to find answers to problems you’ve never seen before and for that, you need to see failure as an opportunity to learn rather than something to be afraid of.

Today with computers and especially with games, we provide the opportunity to take a lot of the workload off teachers to free them up to actually teach instead of being tied up in the busy work of grading homework that could be done by a machine, a machine that could respond instantly and tell the students the moment they try something whether or not they’re correct. With games, especially digital ones, we provide the opportunity to create that rapid feedback cycle that allows students to focus on iterating on their mistakes and learning through their failures. We don’t simply present them with assessments but rather use our assessment time not only to assess but to provide learning opportunities. When somebody asks you why we should consider using games in schools, absolutely tell them how much more engaging we can make the classroom, but that’s something they probably already know.

Also tell them that we can finally do away with a classroom that instills in students a fear of failure, that we can finally be done with a classroom environment that discourages students from taking risks that lead to discovery and instead prepare them to innovate for the future, that we can free teachers of the burden of creating rote homework and instead let them focus on their real job, teaching, that through games, we can get kids experimenting, exploring and discovering freely and perhaps through doing so, get them to love learning rather than fear it.

How do you get better at communication. First, treat it like any other problem and examine the tools at your disposal: meetings, phone calls, Skype, chat, email, passive-aggressive check-in comments. These are ways to stay coordinated with the rest of the team, so don’t neglect them. You don’t wan to treat it just like any other problem, because now you’re dealing with people. That means listening to their ideas, giving the benefit of the doubt. Not assuming your way is always the right way. This is especially true when working with non-programmers, since your tendency will always be to assume that the programmer mindset’s right and the artist is just insane.

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 1: math, at least through algebra and geometry. You don’t have to be great at math to be a programmer, but you will need to use it. Most developers won’t do a lot of advanced math, but you’ll definitely use algebra, trigonometry, geometry and basic probability in the course of your career. If you’re going into game development to finance, higher math is even more important.

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.

If that’s what being a developer is, what makes someone really great at this? First, a great developer is someone who is exceptionally good at analytical and abstract thinking. You need to be able to take a system apart, analyze each piece and figure out how it all fits together. If you’re the kind of person who even thinks about being a developer, you’ve probably done this from an early age. Growing up, David here would spend hours in his best friend’s garage taking things apart, computers, vacuum cleaners, TVs, whatever they could get their hands on. If analytical thinking is at the core of being a developer, how do you get better at it? Simple, by finding ways to feed the analytical side of your brain. Study math, science, logic, proofs, even puzzles, anything that emphasizes understanding and applying concepts rather than just memorizing facts and figures. Dive into existing systems and figure out how they work. Ask yourself what problems the designers were trying to solve here and why they solved it the way they did. Take things apart and put them back together, literally and metaphorically.

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.

Now, all of a sudden that’s changed. All of a sudden we have hundreds of thousands of young people being introduced to gaming with a low fidelity game about building. The ripples from that are going to be enormous. Think about the patience that Minecraft takes to start. You can’t really just button mash, you can’t just slam on the controls and watch things explode. This is a wholly different expectation than most of the games for youth have had in the past. In fact an entire generation are perhaps for the first time being trained not to expect instant gratification from their games.

Imagine what that does to design, especially mass market design, 10 years down the road. Imagine if we could expect a little more patience from the player before they hop into the action. Imagine if we could count on the player being willing to do a little more work before the game really opens up. This creates an incredible breadth of new play opportunities. It doesn’t mean we’ll have to fundamentally change the genres of games we produce, but it lets us do more with them. Games like the old Thief or Mech Warrior or games in the vein or Rainbow Six become much more viable for the first person shooter designers working at triple A companies if we can expect players to come into games with a willingness and maybe even an expectation to have to put in a little bit of work up front to really get the most out of their games.

It also potentially changes what genres we build. Look at the triple A space today. It’s filled with games that are an evolution on what that audience played when they were a little bit younger, games which can bring the existing audience from one title to the next because they’re already familiar with it, already comfortable with the genre and the mechanics. Now look at the indie space. For every wildly innovative indie game we see a dozen games playing to our nostalgia, our fond recollections of earlier days.

Imagine what happens when that audience’s nostalgia, when the genre and the mechanics they are comfortable with, centers around a building/crafting game. It may well become a lot more viable for genres that haven’t seen triple A budgets for 20 years to return to the triple A spotlight. It may become reasonable for companies to branch into genres that we haven’t seen big teams work on since the original heyday of the PC. Of course this doesn’t mean we’ll lose our first person shooters or our racing games, but it does probably change the percentage of the industry that’s going to be focused on strictly action oriented play, and in 15 years when many of the people who are entering the industry are the people who grew up putting in their 10,000 hours on Minecraft, you better believe it’s going to change what they create. Will it radically alter how we fundamentally understand games? No, probably not, but can you perhaps expect to see more crafting systems in your shooters, can you expect to see more digging and mining and building in your RPGs? Almost certainly. We are an industry of human beings, human beings influenced by what we grew up with and what we grew up loving, and today’s generation has grown up with Minecraft, so can we expect this Minecraft generation to change the industry? Absolutely. As the creators and consumers of the future, their voice will weigh in on what games get made and how they’re crafted.

When looking at the Minecraft phenomena, it pays to stop and take a moment to look at the broad view and think about how the games of tomorrow might be influenced by the wild success of one game with the children of today.