The new year is nearly upon us, and you know what that means - New Year's resolutions. I didn't used to put much stock in resolutions, but for 2013 I resolved to start this blog and write a post every week. So far so good. Over that time I've talked a lot about the benefits of learning new things and practicing them to become a better programmer. I've realized that I spend much more time on the former than the latter, so this year I want to remedy that by spending a little less time studying and devoting that time to dedicated practice.
How will I actually do this practice? Software engineering is such a vast and complex field. Deciding what to practice can be paralyzing in and of itself, much less how to do it. When in doubt, head back to the fundamentals. I'll either be pulling out my old college algorithms book, or doing practice problems on different websites. As for how to do dedicated practice, there are a few guidelines that I think will help to get the most out of these practice sessions.
Stick to a routine. Practice won't be too useful if it's done haphazardly or inconsistently, and it certainly won't be dedicated without a routine. Like in weight lifting or playing a musical instrument, practicing consistently is probably the most important way to improve rapidly. Having a routine is a commitment, and with it, the practice is more likely to happen. It has served me well for these blog posts, and I expect it will do the same for programming practice. I'll start with a couple practice sessions a week to see what I can handle, and then see how things settle out.
Pick one thing. The purpose of practice is to learn something so well that it becomes second nature. To do that, you have to focus. That means picking one thing to focus on and practicing that one thing until you don't have to think about it anymore. Practice until you can do it while carrying on a conversation. Practice until you can think a few steps ahead of the code you're writing while doing it. Practice until it becomes harder not to do it. So what is 'it'? 'It' can be anything from a new language feature that you want to learn to a keyboard shortcut in your editor that you're trying to add to your repertoire. Whatever it is, make sure to focus on it exclusively to learn it faster. And exclusively doesn't mean for inordinate amounts of time, either. You can focus for short amounts of time before moving on to something else, but don't try to practice more than one thing at once or you'll slow yourself down.
Get rid of bad habits. We all have them. We should be aware of them. The trick is to get rid of them. The best way to get rid of a bad habit is to realize when you're doing it and stop it right then and there. Don't allow yourself to do it wrong just this time with the excuse that you'll do it better next time. Do it right this time. Check in your code right now before doing that refactoring. Write the test first this time. Take the time to write smaller functions with good names now, not later. These are only examples, but they are probably common examples. The point is to identify your bad habits and fix them right away. Above all, do not practice bad habits. You play like you practice, so practice how you want to play and do it well.
Practice in bursts. This advice is probably not what you think it is. I'm not talking about practicing for ten minutes, then taking a break, and then practicing for another ten minutes. I'm talking about practicing a very small, discrete skill over and over again, and then using it within a larger exercise. I learned this technique from my guitar teacher as 'bursting', and it is used a lot when learning musical instruments, typing, or any skill that requires developing a lot of muscle memory.
When learning to play a new guitar piece, I would practice a difficult measure or even a single chord transition a number of times, maybe ten or even twenty times in a row, and then play through the whole piece without stopping. If the difficult part came out easily, I would move on to practice another part of the piece. If it was still hard, or I hesitated, I would do another burst. You'd be surprised how quickly you can smooth out rough sections of a song with this technique. The same goes for learning difficult skills in programming, and like the principle of picking one thing, it could be any distinct, well-defined skill that needs practicing.
Make it harder to make it easier. Do you remember how hard it was to understand scoping rules for function parameters the first time you were learning them? I remember that being the first thing that really confused me when learning to program. It was all a big muddle at first. I also remember thinking function parameters were so easy by the time I was learning about class member scoping rules and method overloading in C++. Then templates made those things look easy by comparison as well. Doing something harder and pushing yourself beyond your previous limits makes things that used to seem hard now look easy.
Many sports have ways to intentionally make practice harder than the real game to take advantage of this principle. Have you ever tried to downhill ski on one ski? I mean physically remove one ski and then go down, leaving it at the top of the run. Yes, you still have to turn. You can't just bomb the run and hope for the best. This was a standard drill when I was on the ski team in high school, and we did it through slalom gates. Once you could ski on one ski, doing it with two was a piece of cake.
How about swinging a golf club with only your left hand? How about only your right hand? How about playing soccer or tennis with ankle weights? How about swimming laps with three suits on? These are all ways to make these sports more difficult so that real play is easier, and you are subsequently better. So the next time you think the problem you're working on is hard, try making it harder. The real problem might suddenly seem easy by comparison.
So that's the plan for the coming year - real practice to improve at programming faster. This set of principles is a nice, easy to manage regimen that should help make the most of that practice. You don't want to complicate things too much because you need to keep your mind on what you're practicing. Stick to a routine and pick one thing to focus on at a time. Sometimes that one thing will be a bad habit to break. Other times it will be a difficult concept or skill that needs to be practiced with bursting. And if something is not making sense, try moving past it to something harder. Trying to understand things at the next skill level may help everything fall into place.
What You Should Learn In College, But Will Have To (Probably) Do Yourself
Final exams are over, the semester has come to a close, and all of those lucky college students now get a month of R&R during winter break. I remember those times well, and I especially remember the relief after finishing out another set of challenging courses. I loved my college experience, both the mind-expanding scholastic activities and the exciting extracurricular activities. There is no doubt in my mind that I gained an incredible amount of knowledge and understanding from the time I spent in college, but in looking back over that time, I notice that there was one gaping hole in all of the engineering and computer science coursework I completed. Almost none of the courses even came close to teaching us how to effectively manage and execute real projects.
Now, you may be saying to yourself, "Well, duh! College isn't about doing real projects. It's about learning theory and how to apply that theory to contrived textbook problems." And I would agree, to a point. There is certainly a vast quantity of knowledge surrounding software engineering, a significant portion of which a good Computer Science curriculum should teach. But I also think college students should learn how to use that knowledge in the context of actual software projects, because let's face it, most college grads are going to go work for a company where they will be contributing to projects for the rest of their careers. Only a small subset of them will go through PhD programs and cycle back into academia as professors.
Come to think of it, professors spend most of their time on projects, too. They may be research projects instead of commercial projects, but that doesn't mean they wouldn't benefit from learning how to run projects before they need to do it on the job. Not adequately teaching students how to do software development is kind of like building a car without windows or a steering wheel. The car may have lots of nice features. It could have a good, powerful engine. It might be luxuriously comfortable. But without windows you won't be able to see where you're going, and without a steering wheel you'll have no control over how to get there, anyway.
I can't think of any good reason why colleges couldn't teach good software development practices along with all of the theory they cover on relational databases, algorithms, networks, compilers, and everything else. Development practices are at least as important for efficiently producing high-quality software, and they're certainly not hard concepts to learn. Although they are difficult to master. Maybe it's because the concepts are perceived as easy that colleges don't feel the need to teach them, but that is a terrible disservice to these future programmers.
If students were introduced to good software development practices early in their coursework, they would have a much better chance of developing good habits that will serve them well throughout their professional careers... and their college careers for that matter. From my own experience, university programs don't spend much, if any, time going over the practical aspects of developing software. Even those courses that have you do projects that take more than a couple of days to complete don't introduce good programming practices properly.
Those courses that also expect you to do more significant projects with a group of students aren't any better because the professors still don't give any instruction on how to manage a project within the context of a group. It's as if they expect everyone to either already know how it should be done from high school group work, or they think we'll all pick it up easily on the fly because it's so obvious. And let's face it, your grade depends on it, so that should be incentive enough to spontaneously learn it.
I must admit that I did have one excellent course that involved an extensive project with a team. It was an electrical engineering course, not a computer science course, but it was cross-listed with the computer science department. I don't know of a similar CS-only course for software development. Anyway, this course had the unassuming title of "Digital Engineering Laboratory" and it had the most credits of any lab course, weighing in at a hefty four credits. Most labs were only one or two credits. The goal of this lab was to implement a microprocessor from scratch of the team's own design. The processor could do whatever you wanted it to, but it had to work on a real FPGA for a demo at the end of the semester.
Let me tell you, four credits was not enough for this course. I spent more time on this course than my other three courses that semester, combined. I'm sure my four teammates did the same. Yet, this course was different from all of the other project-based courses. Even though it was a lab, there was a small classroom component to the course, and the professor spent most of the time going over practical design, development, and project management principles. The rest of the classroom time was spent going over progress reports and addressing any logistical issues we came up against.
All around, it was an excellent learning experience that came closer to real-world project execution than any other college course I took, and they had the right idea in how they structured the course. Integrating some instruction on managing projects with the execution of a full-scale project provided enough motivation to really pay attention to the design and development practices. If you didn't, it would be much harder to succeed. But there were still problems even with this exceptional course. For one, there wasn't enough time to properly cover everything you need to know to run a project well. For another, since it was a hardware design course, there was no mention of some of the best software design and development practices.
A few weeks ago I wrote out a list of the best software development practices that I keep in mind as I'm writing code. The practices I'm talking about now are not the same as the ones from that list. While those practices were rules of thumb that I picked up over time and use to help guide the process of developing software in a general sense, the practices I'm talking about here are four concrete methods of developing software. They happen to be agile methods, but I'm not advocating them because they're agile. I'm advocating them because they are some of the best practical methods of developing software that I've found. I wish that I had learned them in at least one of my CS courses in college, or at least had been made aware of their existence and encouraged to look into them on my own.
The first method is to define requirements for your software project with user stories. No matter what size project you're working on, user stories provide an exceptionally powerful way to organize the requirements of the software, and they are flexible enough to be useful in an ad-hoc way for more informal single-developer projects or to be extended to meet the more stringent requirements of enterprise or safety-critical projects. If I had known about user stories in college, I would have been using them all the time as an organizational tool, even though most of the time college project requirements are handed to you instead of you coming up with them on your own.
The other three methods are intimately related, and when used together they become an extremely powerful way to develop software. The first is to use version control. Always. You are using version control, right? I don't think I need to justify its use here, what with the wide adoption of Git through GitHub and the general acceptance over the last decade of version control's crucial importance in nearly everything you read about software development. Yet I never heard so much as a whisper about it in college. I can't believe I didn't become aware of it until a couple years after I graduated. Don't make the same mistake. You need to learn this stuff.
The second method is test-driven development (TDD). Writing tests first and then writing the code to make those tests pass results in much cleaner, more well-designed code that has a much better chance of working quickly. Plus, it turns out that it's much easier to write the tests for the code you need to implement and then write the code. It was only recently that I really started to appreciate this benefit of TDD because it's so counter-intuitive. It does work, though. I find myself spending a lot less time staring at the screen contemplating how I'm going to implement the next feature, and more time making good progress because the problem I'm trying to solve is so much more well-defined when the tests are written first.
The combination of version control and TDD allows for the third method, refactoring, to be used with impunity. When you have tests to back up the functionality of your project when making functionally equivalent changes, and you have version control in place to back up every change made to the code base so that you can easily turn back time, cleaning up and optimizing your code becomes so much easier and more likely to actually get done. This trifecta of software development gives you the freedom and confidence to take your programming skills to a whole new level.
During my university program, I missed out on learning these critical software development practices. It took years after graduating to learn and appreciate the importance of user stories, version control, TDD, and refactoring, and I'll continue learning and improving. I can only speak from my own experience. Other computer science programs, or even my own if taken today, could do a much better job covering these things, but if you are not learning them in college, you should take it upon yourself to learn them on your own.
Two good ways to do this would be to participate in an open source project (or start one) or do an internship at a company that practices them. Working on a project that practices good software development is an invaluable experience, and it will teach you things that college courses will overlook or do a poor job teaching you. Sometimes doing it is the only way to learn, but you also have to be conscious of what you're learning. It's entirely possible to work on a real-world project and not fully appreciate the software practices the rest of the team is using, so don't write off studying those practices, too. There are all kinds of great books, blogs, and online resources out there for learning good development practices. Supplement real-world experience with studying to get the most out of both, and don't assume that college will teach you everything. Take the initiative and make sure you learn what you need to know.
Now, you may be saying to yourself, "Well, duh! College isn't about doing real projects. It's about learning theory and how to apply that theory to contrived textbook problems." And I would agree, to a point. There is certainly a vast quantity of knowledge surrounding software engineering, a significant portion of which a good Computer Science curriculum should teach. But I also think college students should learn how to use that knowledge in the context of actual software projects, because let's face it, most college grads are going to go work for a company where they will be contributing to projects for the rest of their careers. Only a small subset of them will go through PhD programs and cycle back into academia as professors.
Come to think of it, professors spend most of their time on projects, too. They may be research projects instead of commercial projects, but that doesn't mean they wouldn't benefit from learning how to run projects before they need to do it on the job. Not adequately teaching students how to do software development is kind of like building a car without windows or a steering wheel. The car may have lots of nice features. It could have a good, powerful engine. It might be luxuriously comfortable. But without windows you won't be able to see where you're going, and without a steering wheel you'll have no control over how to get there, anyway.
How College Misses The Mark
I can't think of any good reason why colleges couldn't teach good software development practices along with all of the theory they cover on relational databases, algorithms, networks, compilers, and everything else. Development practices are at least as important for efficiently producing high-quality software, and they're certainly not hard concepts to learn. Although they are difficult to master. Maybe it's because the concepts are perceived as easy that colleges don't feel the need to teach them, but that is a terrible disservice to these future programmers.
If students were introduced to good software development practices early in their coursework, they would have a much better chance of developing good habits that will serve them well throughout their professional careers... and their college careers for that matter. From my own experience, university programs don't spend much, if any, time going over the practical aspects of developing software. Even those courses that have you do projects that take more than a couple of days to complete don't introduce good programming practices properly.
Those courses that also expect you to do more significant projects with a group of students aren't any better because the professors still don't give any instruction on how to manage a project within the context of a group. It's as if they expect everyone to either already know how it should be done from high school group work, or they think we'll all pick it up easily on the fly because it's so obvious. And let's face it, your grade depends on it, so that should be incentive enough to spontaneously learn it.
I must admit that I did have one excellent course that involved an extensive project with a team. It was an electrical engineering course, not a computer science course, but it was cross-listed with the computer science department. I don't know of a similar CS-only course for software development. Anyway, this course had the unassuming title of "Digital Engineering Laboratory" and it had the most credits of any lab course, weighing in at a hefty four credits. Most labs were only one or two credits. The goal of this lab was to implement a microprocessor from scratch of the team's own design. The processor could do whatever you wanted it to, but it had to work on a real FPGA for a demo at the end of the semester.
Let me tell you, four credits was not enough for this course. I spent more time on this course than my other three courses that semester, combined. I'm sure my four teammates did the same. Yet, this course was different from all of the other project-based courses. Even though it was a lab, there was a small classroom component to the course, and the professor spent most of the time going over practical design, development, and project management principles. The rest of the classroom time was spent going over progress reports and addressing any logistical issues we came up against.
All around, it was an excellent learning experience that came closer to real-world project execution than any other college course I took, and they had the right idea in how they structured the course. Integrating some instruction on managing projects with the execution of a full-scale project provided enough motivation to really pay attention to the design and development practices. If you didn't, it would be much harder to succeed. But there were still problems even with this exceptional course. For one, there wasn't enough time to properly cover everything you need to know to run a project well. For another, since it was a hardware design course, there was no mention of some of the best software design and development practices.
Critical Best Practices
A few weeks ago I wrote out a list of the best software development practices that I keep in mind as I'm writing code. The practices I'm talking about now are not the same as the ones from that list. While those practices were rules of thumb that I picked up over time and use to help guide the process of developing software in a general sense, the practices I'm talking about here are four concrete methods of developing software. They happen to be agile methods, but I'm not advocating them because they're agile. I'm advocating them because they are some of the best practical methods of developing software that I've found. I wish that I had learned them in at least one of my CS courses in college, or at least had been made aware of their existence and encouraged to look into them on my own.
The first method is to define requirements for your software project with user stories. No matter what size project you're working on, user stories provide an exceptionally powerful way to organize the requirements of the software, and they are flexible enough to be useful in an ad-hoc way for more informal single-developer projects or to be extended to meet the more stringent requirements of enterprise or safety-critical projects. If I had known about user stories in college, I would have been using them all the time as an organizational tool, even though most of the time college project requirements are handed to you instead of you coming up with them on your own.
The other three methods are intimately related, and when used together they become an extremely powerful way to develop software. The first is to use version control. Always. You are using version control, right? I don't think I need to justify its use here, what with the wide adoption of Git through GitHub and the general acceptance over the last decade of version control's crucial importance in nearly everything you read about software development. Yet I never heard so much as a whisper about it in college. I can't believe I didn't become aware of it until a couple years after I graduated. Don't make the same mistake. You need to learn this stuff.
The second method is test-driven development (TDD). Writing tests first and then writing the code to make those tests pass results in much cleaner, more well-designed code that has a much better chance of working quickly. Plus, it turns out that it's much easier to write the tests for the code you need to implement and then write the code. It was only recently that I really started to appreciate this benefit of TDD because it's so counter-intuitive. It does work, though. I find myself spending a lot less time staring at the screen contemplating how I'm going to implement the next feature, and more time making good progress because the problem I'm trying to solve is so much more well-defined when the tests are written first.
The combination of version control and TDD allows for the third method, refactoring, to be used with impunity. When you have tests to back up the functionality of your project when making functionally equivalent changes, and you have version control in place to back up every change made to the code base so that you can easily turn back time, cleaning up and optimizing your code becomes so much easier and more likely to actually get done. This trifecta of software development gives you the freedom and confidence to take your programming skills to a whole new level.
Hitting The Mark Yourself
During my university program, I missed out on learning these critical software development practices. It took years after graduating to learn and appreciate the importance of user stories, version control, TDD, and refactoring, and I'll continue learning and improving. I can only speak from my own experience. Other computer science programs, or even my own if taken today, could do a much better job covering these things, but if you are not learning them in college, you should take it upon yourself to learn them on your own.
Two good ways to do this would be to participate in an open source project (or start one) or do an internship at a company that practices them. Working on a project that practices good software development is an invaluable experience, and it will teach you things that college courses will overlook or do a poor job teaching you. Sometimes doing it is the only way to learn, but you also have to be conscious of what you're learning. It's entirely possible to work on a real-world project and not fully appreciate the software practices the rest of the team is using, so don't write off studying those practices, too. There are all kinds of great books, blogs, and online resources out there for learning good development practices. Supplement real-world experience with studying to get the most out of both, and don't assume that college will teach you everything. Take the initiative and make sure you learn what you need to know.
What Can Chess Teach Us About Programming?
Similar to how it seems that many programmers play a musical instrument, particularly the guitar, it seems that many programmers love to play chess. Now that may be the case only because people in general like to play the guitar and play chess. But I think programmers especially like playing the guitar because it allows them to express their creativity, and they like playing chess because of their proclivity toward analytical problem solving.
There aren't many problems out there that are more complex and difficult than a game of chess (with Go possibly being one of them). Yet, programming is full of mind-bending problems that we have to overcome everyday, and so there are many parallels between chess and programming. We could certainly learn some things about programming from the strategies involved in playing and getting better at chess.
Phases
For starters, chess has three phases of the game: the opening, the middle game, and the ending. In the opening, both players follow a series of moves that have been played time and time again in thousands of previous games throughout history. Most of the advantages or disadvantages of each move have been studied extensively, and there are accepted lines of play for each side that will lead to slight advantages to one player or the other. If the players have studied openings extensively, the opening may last for twenty moves or more. Similarly in programming, when you start a new project, you will go through a known set of steps to setup the environment and lay the foundation for the rest of the project. Much of the initial setup will build a skeleton for the rest of the code to hang from. It gives the project structure, much like the opening moves in chess will build up a pawn structure to use as the pieces are developed and put into motion.
At some point one of the players will introduce a novelty - a move that takes the game out of established opening play - so that the players now have to rely on their own chess playing skills. This phase is the middle game, where strategy and tactics take over as each player grapples for advantages and attempts to maintain them through the rest of the game for a win. The middle game can be fraught with uncertainty, with countless options available on each move and few certain paths to victory. Tactical strikes can change the balance of the game quickly. The advantage can quickly change hands as attacks succeed or fail and pieces are exchanged.
The long middle game of a software project can have its fair share of uncertainty as well. Every design decision entails tradeoffs and compromises, and the final success of the project is largely unknown, much less what it will actually look like once all is said and done. There will be days where everything seems to be going great, other days where nothing seems to work at all, and that momentum can change in an instant. This is the time to celebrate small victories, attempt to keep morale up, and strive to maintain momentum and positive progress.
Back in the chess game: at some point enough pieces will have been removed from the board, and the position becomes more clear. The transition from the middle game to the ending is not as well defined as from the opening to the middle game, but at some point it becomes obvious that the end of the game is imminent. In this phase every move becomes critical, and the game can be won or lost because of a single pawn move at the wrong time or the precise path that the king takes across the board. Precision of execution is paramount. The same goes for software projects. At some point most of the planned features will have been added, and the bugs are getting progressively cleaned out of the system. It becomes clear that this software will actually ship, but the execution from here on out is critical. Everything has to line up precisely for the best possible outcome on release day, and the slightest mistake could make a huge difference in the success of the product.
Pattern Matching
Okay, the phases of the game showed some similarities to software projects in broad strokes, but there are a number of other more specific things that we can learn from the game of chess. At its heart, chess is a game of pattern matching, and that is how the masters are so good at playing. When they look at a chess board, they don't see two sets of sixteen separate pieces on individual black and white squares. They see combinations of interacting pieces controlling space on the board. They see a pawn structure that defines the game and shows which strategies will be appropriate to pursue. They can instantly memorize any given position and assess the strengths and weaknesses by recognizing common configurations of pieces so that they can spend their mental energy analyzing the best course of action.
If you've ever watched an expert programmer at work, you may be amazed at how quickly he (or she) can determine how a piece of code works and make necessary changes. This ability comes from the same pattern matching skills as the chess master, but the patterns are in the code. I'm not talking only about design patterns here. An expert programmer stops seeing individual keywords, variables, and operators, and instead he sees the structure of the code itself. He can recognize similar blocks of code that he's seen in the past and work with it at a higher level than just reading and manipulating individual symbols.
For the chess master, this pattern matching ability is useful beyond merely assessing a position. Being able to recognize more chess patterns will give you a better ability to calculate the best lines of play, and it will improve your horizon - how many moves ahead you can see. Strengthening this ability to concentrate on the position and calculate deeply in spite of what pressures the player is under is known in chess as developing mental toughness. That concept is perfectly appropriate to programming. As you gain more experience and expand your ability to see software patterns, you will be able to see larger and more complex transformations of code with less mental effort. You will be able to anticipate more potential problems and envision more promising solutions when writing code, all by improving your mental toughness.
To develop this skill in chess, you should do lots and lots of practice drills. There are entire books filled with positions where one player has an immediate tactical advantage over the other, and you are supposed to see the correct lines of play that capitalize on that advantage. You can also do all kinds of different drills with a few pieces to practice essential tactics like pinning, forking, skewering, and discovered attacks. Seeing these tactics will become more automatic as your pattern matching skills improve. There are also all kinds of ways to improve your pattern matching skills in programming. In particular, studying algorithms and data structures, and practicing on programming puzzle websites like Project Euler or Programming Praxis will greatly improve these skills.
Strategy And Tactics
Much of master level chess revolves around the tension between strategy and tactics. Strategy involves the long term advantage you can leverage from things like the pawn structure and the control of space and critical squares on the board. Tactics instead consist of the short term execution of maneuvers that result in a decisive material advantage. Skewering your opponent's king to trade a rook for a queen or forking the king and bishop with your knight could lead to an overwhelming advantage of force, if you can hold on to it.
The opening is where strategies are first put into place, and most of the opening theory is based on gaining a strategic advantage, assuming the opening lines are played correctly by both players. The middle game is the land of tactics, and this is partly why the balance of the game can change so quickly during this phase. Most novice players make the mistake of focusing too heavily on memorizing different openings, when they should really be studying tactics. Even though strategy depends on deep chess knowledge, most games at the amateur and even the master level are primarily determined by tactics.
When amateurs look at grandmaster games, they will read an awful lot of discussion about subtle positional advantages and strategic play. What amateurs seem to forget is that to reach that level of play, grandmasters had to be absolutely excellent at tactics. They have gotten so good at tactics that for the most part, they have taken tactics out of the game. At least, that's what it looks like on the surface. If you look at the alternate lines of play in a grandmaster game, they are littered with devastating tactics narrowly avoided on both sides. The point is that grandmasters are exceptionally skilled in both strategy and tactics, no matter whether they are described as positional players or tacticians.
In programming creating new code can be thought of as strategic play and working with legacy code can be equated with tactical play. When writing new code, you must think longer term about all of the implications of the design you implement. How you structure the code could have an impact on the project for years down the road because it establishes a way of doing something that can become hard to change as more code is added to the original architecture. On the other hand, working with legacy code entails making surgical changes to existing code, and small changes can be decisive in fixing broken code or adding new features. Refactoring in particular can be thought of as a known set of tactics that can improve legacy code with small, well-defined code changes.
As with strategic or tactical grandmasters, expert programmers may have a preference of creating new code or working with legacy code, but they are excellent at both tasks. The defining characteristic of experts is not whether they are better at building something new or fixing something old, but that they have exceedingly good judgement about programming in general. Just as a grandmaster will have a better idea of when to develop her position and when to go on the attack, an expert programmer will know when it is better to write their own code or use a library and what the best way to debug a particular piece of code would be. Experts have a general sense of good judgement that comes from years of practice, experience, and hard work developing all of their skills. Their preferences for one particular way of doing things tend to show only when the trade-offs of choosing one way or the other are insignificant.
Beauty
It only takes a short time learning chess before you begin to realize that the game is filled with beauty. You can hardly find any book on chess that doesn't mention it in one way or another, and commentary on famous chess games is filled with acknowledgements of beautiful positions or exchanges or checkmates. The more you learn about the game, the more you can appreciate the beauty that unfolds from the interaction of the pieces and how they can work together when the game is played well. One of my favorite types of checkmates is the pure mate, where every square around the mated king is either attacked or occupied only once. Being able to achieve something so perfect in the course of a game with nearly endless possibilities certainly elevates the game to a work of art in the hands of the masters.
The best programmers strive for beauty in code as well. For them it is not enough to merely create functional, productive software. They strive to transcend normal, everyday code to create masterpieces that solve complex problems in clear and elegant ways. For them programming is not a job or a hobby, but a labor of love that they pursue with a deep passion. Of all the things chess can teach us about programming, this one becomes the most obvious with time. Bringing order to complexity is a thing of beauty that is deeply satisfying to achieve.
Oh, How To Learn The Things A Software Engineer Can Know
Last week I wrote up a list of an overwhelming number of things that a software engineer could learn to become more effective at designing and developing software. Some things were more important than others, and you don't have to learn everything to be good at what you do. It was a buffet of choices where every new thing you tried had the potential to expand your tastes and satisfy your hunger for helpful skills.
With such a huge array of potential knowledge, how do we go about capturing it, becoming proficient in it, and putting it to good use? Every programmer has their own preferred method of gaining new programming knowledge, and different things work better for different people, so I'm not going to push one particular method. Well, not too much anyway. Instead, I'm going to attempt to show the plethora of options available for improving your 1337 programming skillz. Once again, this is probably not a complete list.
You could start off learning a broad spectrum of software engineering knowledge by going to college. Coupling a Computer Science degree with a Mathematics degree will cover a lot of ground in four or five years. You can also continue on for a Masters or PhD to go deeper and deeper into the fields that you're interested in. College can be great for providing direction and focus in learning, if you have the motivation and don't let too much partying go to your head. Being surrounded by a large group of other smart, motivated people can be encouraging and stimulating. College courses also have the advantage of a fairly well-packaged set of resources and a discernible learning path for the subject areas you decide to pursue.
There are trade-offs, though. College programs are often short on experience, and unless you go for internships, (recommended) you won't have a very good idea of how software engineering is done in the real world. It's also expensive, both in time and money, and it isn't for everyone. Even for those that do go to college, and go on to Master's and PhD programs, it will (or at least should) eventually end. Then staying up on current technology becomes an individual enterprise. Even right out of college, grads don't know everything, so what else can we do to keep learning?
There's always books ... lots of books. If you haven't noticed, this is my currently preferred and primary method of learning more about pretty much anything. I love books. They give an in depth treatment of any given subject in a nice, manageable package that can be easily reviewed, referenced, and now with ebooks, searched for vast quantities of information. There are books on nearly any subject you can think of, and I've had good luck finding high quality books ever since Amazon reviews became ubiquitous.
Even in college I quite often relied on the textbooks as much or more than the professors, but books can't teach you everything. They are an individual pastime that is distinctly lacking in connections to the programming community as well as being short on giving you real-world experience. Beyond that, most programming books can quickly become obsolete as the software they cover continues its eternal progression, so books at least need to be supplemented with more up-to-date and connected ways of learning.
To get connected with a programming community and learn new things at the same time, you can participate in online communities like Hacker News, reddit.com/r/programming, IRC, and LinkedIn groups. You'll be aware of current trends, see new developments as they happen, and be able to join discussions and debates with other programmers. You'll also get a better idea of who's who in the programming world and be able to see first hand how trends are developed and promoted.
You can also participate in communities that focus on teaching and learning in a more permanent format, like Stackoverflow.com or Quora.com. Like most other online communities, they have a gamification aspect where you gain reputation as you ask good questions and provide good answers. But unlike HN, reddit, etc., the questions and answers are easily searchable and available to newcomers so that your contributions will potentially have a larger impact over time, and you can find information on specific topics that was already covered months or years in the past.
Once you've spent some time in some of these communities, you'll likely find some interesting blogs to follow. That's another great way to learn more about different areas of programming, and if you read some blogs from their early beginnings to the present, you'll be able to see how other programmers have developed throughout their careers.
You may even get the urge to start your own blog, and put your own experiences online. Then, instead of only receiving new knowledge, you can develop an ability to teach others what you know. In addition to contributing more to the community, you also gain a much deeper understanding of the topics you're trying to write about. Knowing something is one thing, doing it is another, and teaching it is still another. To effectively teach anything, you have to organize your thoughts in new ways and spend more time wringing out the misconceptions and uncertainty that you may have on the subject. It's harder than you think, and you'd be surprised how much you don't know about things that you thought you could do in your sleep.
However, reading and writing about software engineering can only get you so far. At some point you're going to want to get your hands dirty and do some real programming. Well, there's plenty of resources for that, too.
To get some real programming practice in, you could go to some of the excellent programming puzzle sites for ideas. There's sites like Project Euler, Programming Praxis, Prolog Problems, Code Golf on StackExchange, Python Challenge, and Ruby Quiz to name just a few. Solving programming puzzles is a great way to practice and get better at the fundamentals of programming, or to get ideas for small exercises that you can do to get more familiar with a new language you're learning.
Speaking of new languages, learning another language is an excellent way to learn a lot about new areas of software engineering, especially if that language lives primarily in an environment that you're not familiar with. To learn C#, you'll have to learn a lot about the Windows programming environment. Learning Objective-C will lead you into MacOS and iOS programming. Learning Prolog would be a useless undertaking without also learning a lot about AI. Erlang will provide the impetus to learn more about concurrency and parallel computing. And Lisp will most likely bring you up close and personal with Emacs.
If you're starting out with a new language, there are also a number of online resources out there to help you with the basics, especially if you're fairly new to programming and it's a popular language. Sites like RubyMonk.com, Scratch.mit.edu, and W3Schools.com can get you up and running with a new language through a fun, interactive experience.
While solving puzzles and learning new languages will help you a lot, we still haven't covered great ways to get real-world experience doing larger projects. For that experience, one of the best ways to learn outside of having a job in software engineering, is to contribute to an open source project. Joining an open source project will not only help you learn how to work within a larger software team on a more significant project, but you will also be making a meaningful contribution to the community by helping out on a software project that may be used by thousands of people.
Working on open source software will also give you a better idea of how to write good, high quality code, at least if you happen to be reading good, high quality code. But there's a good chance that you will be, especially if you're looking at the standard libraries for your favorite language or the more popular frameworks and projects on GitHub - the go-to site for finding good open source projects to contribute to.
If you don't want to join an already active project, you can always start one of your own. Coming up with an idea for a new software project and following it through design, development, and release is a great way to develop your programming knowledge, and there are plenty of important problems out there yet to be solved with a good piece of software. You're guaranteed to learn a lot, and the project may even take on a life of its own and take you to places you never imagined you could go.
These projects can range from web design to mobile apps, games, and even embedded products. No matter what kind of programming you want to learn, there's an affordable way to do what you want to do. The barriers to entry have never been lower. Whether its free web hosting at sites like Heroku, or inexpensive embedded kits like Arduino, Raspberry Pi, and Tiva Launchpads, There are all kinds of interesting options for pursuing your DIY urges. I'm especially interested in checking out Make: magazine for all kinds of embedded software project ideas, although I'm afraid I wouldn't be able to resist overdoing it and it would consume all of my time. Maybe I need to wait until my kids are old enough to enjoy those projects with me, and we can learn together. It shouldn't be long now.
With so many options available, how does one choose what to do? Like the options for what to learn to improve as a software engineer, the options for how to learn it can be overwhelming. It is largely a personal choice, and what works well for some people will be tedious or ineffective for others. For example, I am quite happy reading books and working out programming puzzles, but I can't stand watching instructional videos or screen casts. Another programmer may have trouble concentrating on a book but gets a lot out of video lectures or debating in online forums. The point is to figure out how you are most effective at learning and focus on that. Make the most of the time you have.
I have one piece of advice, though. Try to find a good balance between studying, practicing, and participating. If you spend too much time on any one of those things, it can start to become an end unto itself. That's okay if your goal is to read tons of books or build up a lot of reputation on Hacker News or solve as many puzzles as you can. If you enjoy what you're doing, that's great, but be honest with yourself about what your goals are. If your end goal is to improve as a programmer, or more specifically, learn what you need to learn to accomplish whatever it is you want to do with programming, you're going to make faster progress if you strike the right balance. I'd love to tell you what that is, but you're going to have to discover it on your own.
With such a huge array of potential knowledge, how do we go about capturing it, becoming proficient in it, and putting it to good use? Every programmer has their own preferred method of gaining new programming knowledge, and different things work better for different people, so I'm not going to push one particular method. Well, not too much anyway. Instead, I'm going to attempt to show the plethora of options available for improving your 1337 programming skillz. Once again, this is probably not a complete list.
The Old Fashioned Way
You could start off learning a broad spectrum of software engineering knowledge by going to college. Coupling a Computer Science degree with a Mathematics degree will cover a lot of ground in four or five years. You can also continue on for a Masters or PhD to go deeper and deeper into the fields that you're interested in. College can be great for providing direction and focus in learning, if you have the motivation and don't let too much partying go to your head. Being surrounded by a large group of other smart, motivated people can be encouraging and stimulating. College courses also have the advantage of a fairly well-packaged set of resources and a discernible learning path for the subject areas you decide to pursue.
There are trade-offs, though. College programs are often short on experience, and unless you go for internships, (recommended) you won't have a very good idea of how software engineering is done in the real world. It's also expensive, both in time and money, and it isn't for everyone. Even for those that do go to college, and go on to Master's and PhD programs, it will (or at least should) eventually end. Then staying up on current technology becomes an individual enterprise. Even right out of college, grads don't know everything, so what else can we do to keep learning?
There's always books ... lots of books. If you haven't noticed, this is my currently preferred and primary method of learning more about pretty much anything. I love books. They give an in depth treatment of any given subject in a nice, manageable package that can be easily reviewed, referenced, and now with ebooks, searched for vast quantities of information. There are books on nearly any subject you can think of, and I've had good luck finding high quality books ever since Amazon reviews became ubiquitous.
Even in college I quite often relied on the textbooks as much or more than the professors, but books can't teach you everything. They are an individual pastime that is distinctly lacking in connections to the programming community as well as being short on giving you real-world experience. Beyond that, most programming books can quickly become obsolete as the software they cover continues its eternal progression, so books at least need to be supplemented with more up-to-date and connected ways of learning.
The Newfangled Way
To get connected with a programming community and learn new things at the same time, you can participate in online communities like Hacker News, reddit.com/r/programming, IRC, and LinkedIn groups. You'll be aware of current trends, see new developments as they happen, and be able to join discussions and debates with other programmers. You'll also get a better idea of who's who in the programming world and be able to see first hand how trends are developed and promoted.
You can also participate in communities that focus on teaching and learning in a more permanent format, like Stackoverflow.com or Quora.com. Like most other online communities, they have a gamification aspect where you gain reputation as you ask good questions and provide good answers. But unlike HN, reddit, etc., the questions and answers are easily searchable and available to newcomers so that your contributions will potentially have a larger impact over time, and you can find information on specific topics that was already covered months or years in the past.
Once you've spent some time in some of these communities, you'll likely find some interesting blogs to follow. That's another great way to learn more about different areas of programming, and if you read some blogs from their early beginnings to the present, you'll be able to see how other programmers have developed throughout their careers.
You may even get the urge to start your own blog, and put your own experiences online. Then, instead of only receiving new knowledge, you can develop an ability to teach others what you know. In addition to contributing more to the community, you also gain a much deeper understanding of the topics you're trying to write about. Knowing something is one thing, doing it is another, and teaching it is still another. To effectively teach anything, you have to organize your thoughts in new ways and spend more time wringing out the misconceptions and uncertainty that you may have on the subject. It's harder than you think, and you'd be surprised how much you don't know about things that you thought you could do in your sleep.
However, reading and writing about software engineering can only get you so far. At some point you're going to want to get your hands dirty and do some real programming. Well, there's plenty of resources for that, too.
The Hands-On Way
To get some real programming practice in, you could go to some of the excellent programming puzzle sites for ideas. There's sites like Project Euler, Programming Praxis, Prolog Problems, Code Golf on StackExchange, Python Challenge, and Ruby Quiz to name just a few. Solving programming puzzles is a great way to practice and get better at the fundamentals of programming, or to get ideas for small exercises that you can do to get more familiar with a new language you're learning.
Speaking of new languages, learning another language is an excellent way to learn a lot about new areas of software engineering, especially if that language lives primarily in an environment that you're not familiar with. To learn C#, you'll have to learn a lot about the Windows programming environment. Learning Objective-C will lead you into MacOS and iOS programming. Learning Prolog would be a useless undertaking without also learning a lot about AI. Erlang will provide the impetus to learn more about concurrency and parallel computing. And Lisp will most likely bring you up close and personal with Emacs.
If you're starting out with a new language, there are also a number of online resources out there to help you with the basics, especially if you're fairly new to programming and it's a popular language. Sites like RubyMonk.com, Scratch.mit.edu, and W3Schools.com can get you up and running with a new language through a fun, interactive experience.
While solving puzzles and learning new languages will help you a lot, we still haven't covered great ways to get real-world experience doing larger projects. For that experience, one of the best ways to learn outside of having a job in software engineering, is to contribute to an open source project. Joining an open source project will not only help you learn how to work within a larger software team on a more significant project, but you will also be making a meaningful contribution to the community by helping out on a software project that may be used by thousands of people.
Working on open source software will also give you a better idea of how to write good, high quality code, at least if you happen to be reading good, high quality code. But there's a good chance that you will be, especially if you're looking at the standard libraries for your favorite language or the more popular frameworks and projects on GitHub - the go-to site for finding good open source projects to contribute to.
If you don't want to join an already active project, you can always start one of your own. Coming up with an idea for a new software project and following it through design, development, and release is a great way to develop your programming knowledge, and there are plenty of important problems out there yet to be solved with a good piece of software. You're guaranteed to learn a lot, and the project may even take on a life of its own and take you to places you never imagined you could go.
These projects can range from web design to mobile apps, games, and even embedded products. No matter what kind of programming you want to learn, there's an affordable way to do what you want to do. The barriers to entry have never been lower. Whether its free web hosting at sites like Heroku, or inexpensive embedded kits like Arduino, Raspberry Pi, and Tiva Launchpads, There are all kinds of interesting options for pursuing your DIY urges. I'm especially interested in checking out Make: magazine for all kinds of embedded software project ideas, although I'm afraid I wouldn't be able to resist overdoing it and it would consume all of my time. Maybe I need to wait until my kids are old enough to enjoy those projects with me, and we can learn together. It shouldn't be long now.
Oh, Is That All?
With so many options available, how does one choose what to do? Like the options for what to learn to improve as a software engineer, the options for how to learn it can be overwhelming. It is largely a personal choice, and what works well for some people will be tedious or ineffective for others. For example, I am quite happy reading books and working out programming puzzles, but I can't stand watching instructional videos or screen casts. Another programmer may have trouble concentrating on a book but gets a lot out of video lectures or debating in online forums. The point is to figure out how you are most effective at learning and focus on that. Make the most of the time you have.
I have one piece of advice, though. Try to find a good balance between studying, practicing, and participating. If you spend too much time on any one of those things, it can start to become an end unto itself. That's okay if your goal is to read tons of books or build up a lot of reputation on Hacker News or solve as many puzzles as you can. If you enjoy what you're doing, that's great, but be honest with yourself about what your goals are. If your end goal is to improve as a programmer, or more specifically, learn what you need to learn to accomplish whatever it is you want to do with programming, you're going to make faster progress if you strike the right balance. I'd love to tell you what that is, but you're going to have to discover it on your own.
Oh, The Things You'll Learn As A Software Engineer
The field of software engineering is vast. The amount of knowledge that can prove useful for any given problem is immense. And the paths to attaining enlightenment are numerous. Looking up at this towering mountain of knowledge and deciding how to scale it can be more than a little bit overwhelming. Whether you've recently begun the journey with only the basics behind you, or you've been trekking along for decades with a deep store of accumulated knowledge, you still have an incredible amount of stuff that you could learn ahead of you.
That is the beauty of software engineering. There is never a shortage of new and challenging things to learn, and that new-found knowledge can be applied to interesting problems. Sometimes you won't even know that a particular field of study holds the solution to your problem until you've cracked it open and explored its depths.
It can be useful to have a broad overview of all of the subjects that contribute to software engineering, to have some idea of what could be beneficial to study next. I'll attempt to split things up into coherent categories, but the progression of these categories does not imply a sequential order in which these subjects should be learned. In fact, I don't even claim that all of these things must be learned to be a successful programmer, or that this set of topics is complete. Such is the nature of the constantly changing field of software engineering. This set of topics couldn't possibly be either necessary or sufficient, but it should give a good idea of overall scope. With that in mind, let's survey the landscape of this mountain of knowledge we call software engineering, starting with the foundation.
The Foundation
Surprisingly, the basic knowledge for learning to program well does not come from learning programming languages or theory. It comes, like so many things, from the fundamentals of reading, writing, and mathematics that we all learn as children. They provide the foundation on which to build all the other programming knowledge, both directly and indirectly.
Reading is an integral part of learning everything about programming, from textbooks to technical manuals to documentation, but learning to read well provides deeper and more valuable skills. Knowing how to understand and follow instructions, how to analyze and think critically, and how to research topics that you don't understand are all important skills in programming that improve as your reading ability increases.
Writing is also an invaluable skill for programming. You will not only be writing code, but also documentation, requirements in one form or another, and more informal reports and explanations of software features, bugs, static, planning, etc. Writing is crucial because a lot of communication is done through the written word, and the better you can write, the better you will be understood. You will also be better able to express your ideas in writing, and at a deeper level, that is exactly what you are doing when writing code that will be executed by a compiler or interpreter, but read and understood by fellow programmers.
Mathematics is most directly applicable to programming in the form of algebra, and for certain types of programming, geometry. I think a lot of people mistakenly leave the connection between programming and mathematics at this shallow level and either enthusiastically agree with it or vehemently oppose it, depending on how good they feel they are at math. But the connection runs much deeper than whether programs tend to look like algebraic equations. Learning mathematics will teach you logic, reasoning, abstract thinking, and problem solving skills that will be incredibly useful in programming. After all, a large part of programming is solving problems in a logical way as efficiently as possible.
More Mathematics
Beyond the basic mathematics of algebra and geometry, many other fields of mathematics can prove quite useful for programmers. Probability and Statistics play an important role in all kinds of data analysis as well as helping you understand your users in the aggregate. Numerical Methods will provide plenty of ways to do complex calculations, approximations, and estimations on a computer with attention to both accuracy and efficiency. Graph Theory is probably the most important higher level mathematics field because so many problems in programming can be understood and solved with graphs. And Discrete Mathematics encompasses a whole set of topics that are directly applicable to programming, including Logic Theory, Number Theory, Set Theory, Algorithmic Complexity Analysis, and Finite-State Automata.
Then we start transitioning from more Mathematics-centric topics to more Computer Science-centric topics. DSP (Digital Signal Processing) deals with the handling and analysis of time-domain and frequency-domain data. Control Systems deals with how to provide stimulus to some target based on feedback measured from that target in order to make it do something useful. Neural Networks deals with how to setup a system of small interconnected memory units that you can then train to respond in a certain way to different kinds of stimuli.
Now we're getting firmly into Computer Science territory, and that means I should bring up Data Structures and Algorithms - the basic programming tools that every programmer should know. You won't get far as a programmer without knowing about arrays and hashes, or understanding sorting and searching. Even though the basics are required knowledge, these topics go way beyond that, and there is a wealth of knowledge for programmers of every level here.
The more advanced topics of Artificial Intelligence and Machine Learning round out the set of Mathematics and Computer Science topics that are useful for a programmer to know, but are not directly about writing programs. Before we do get to programming itself, there is one more area to examine.
Under The Hood
Every good craftsman understands his tools, and programming is no different. A great programmer will have a deep knowledge of the central tool of his trade - the processor executing the code. Having a working knowledge of computer architecture will give you great insights into how code is actually executed on the metal. Microprocessor designers have all kinds of tricks that they use in a valiant attempt to make your code run faster: pipelining, branch prediction, out-of-order execution, register renaming, caching, trace buffers, prefetching, virtual memory, and many others.
You could also go even deeper into digital logic design and semiconductor devices, but that would be purely to satisfy your own curiosity. At that depth, you'll be pretty far removed from code execution. However, you should learn the language of the processor, or at least the closest reasonable thing to it - assembly language. Knowing some assembly language will give you a greater appreciation for what code actually looks like when it's executed by a processor, and it might even help you fix some especially elusive bugs if you find yourself in a situation where you don't have the source code and have to step through assembly instead.
While the processor is critically important, it doesn't live in a vacuum. The surrounding system is also important to understand. The memory hierarchy, disk subsystems, and peripheral buses all play a role in programming, and even though programming languages do their best to abstract these things away, knowing that they exist and how they impact performance will help you become a better programmer.
Now that multi-core processors are pretty much standard, it is also becoming more important than ever to understand parallel processor systems and concurrency. Part of that involves learning about memory models, and even though they quickly become mind-numbingly complex, you should at least be aware of the basics for parallel programming.
Other topics that make up the infrastructure of programming include a lot of intricate software that lies between the processor and high level software applications. This software includes the operating system, compilers and interpreters, databases, and networking. These are all deep subjects, and all worth knowing better than you do.
The Core
After all of that, we finally get to actually programming. You'll need to learn at least one programming language, of course. The more languages you learn, the better you'll understand the world of programming. To become more effective, you'll also learn other libraries, especially the standard library for your programming language of choice, as well as frameworks for building applications on different platforms. You will likely also pick up knowledge on APIs (Application Programming Interfaces) for various software services available on the internet.
To be a more efficient programmer, you'll need to become proficient in a number of other tools such as a text editor or IDE (Integrated Development Environment), bug tracker, version control system, web browser, and search engine (for finding all of the information you've forgotten). Those are just the basic programmer's tools, though. There are as many programming tools as there are programmers, and you'll pick up a bunch more and maybe even build your own over time.
As you get deeper into the bowels of programming, you'll find that you need to learn more about the surrounding environment. Security quickly becomes an issue that you need to learn well. Practical operating system knowledge, not just the theory of memory management and file systems, but the actual functional knowledge of the operating system you're developing on and developing for, will become increasingly important. System administration and server maintenance will likely come into play as well.
Beyond Coding
The learning doesn't stop with programming languages and coding tools. There are all kinds of methods and processes that you can learn to assist in building software, and some are more helpful than others. There's UML (Unified Modeling Language) diagramming, unit testing, TDD (Test-Driven Development), agile methods, refactoring, code construction advice, user interface design, and various forms of requirements definition. Of those I would put unit testing and refactoring near the top of the list, but your circumstances may dictate a different ranking. And then there's project management, which is another field entirely with many philosophies and strongly held opinions.
Finally, there is the domain specific knowledge that you'll acquire for the specific type of programming that you find yourself doing. This type of knowledge is so unique and varied that it defies enumeration, but examples include web design, embedded programming, scientific programming, modeling, tool building, mobile application development, and game programming.
Stepping Back To Take It All In
Now that is certainly an incredible amount of knowledge to try to acquire. Most of these topics could take years of study in and of themselves to even begin to master. If you are feeling a bit overwhelmed, you are surely in good company. Rest assured that no one could maintain a deep and lasting knowledge of all of these things.
The good news is that you don't have to. Part of being an effective programmer is knowing what you need to learn now and what can be put off until later, sometimes indefinitely. And once you have a good foundation, a programming language or two under your belt, and productive habits in at least one programming environment, you can pick off other topics as they become necessary (or desirable) to learn. The important thing is to keep chipping away at new things. You can gain a cursory understanding of any of these topics in a matter of days or sometimes hours, and then decide whether it's worth it to plunge deeper into the topic.
That still leaves the question of how to crack into the knowledge that you decide to pursue, but I'll leave that until next week. Regardless of how the knowledge is attained, it's amazing that there is so much to be had, and it's all intertwined under the canopy of software engineering. I, for one, can't wait to learn something new. The only real problem is choosing what to do next.