The following is a guest post by Stefan Lance and originally appeared on his blog. Stefan is currently a summer intern at The Flatiron School and will be starting his freshman year at the University of Chicago in September. You can follow him on Twitter here.
Since I’ve been intimately using Rails for a few weeks, now’s a good time to reflect on what I’ve learned from and about it, as well as about programming in general.
1. Read the log files. If something’s broken, the logs can give you a pretty good clue as to why, or at least push you in the right direction. Yesterday, just as I was about to take a break from a problem I’d been Googling for a while, I glanced at the logs and quickly discovered exactly what was wrong. Since Rails applications can be so specific, Google won’t always be the best help, but the logs always give you information relevant to your application. Make good use of them.
2. Spend some time deliberately learning every day. This is crucial if you’re new to your language or framework. True, you’ll learn a lot just by working on projects, but to confirm your ideas and correct your misunderstandings of what’s going on behind the scenes, some extra learning is essential. You can do this by asking more experienced colleagues to explain concepts to you, creating small pieces of test code, and reading sections of books or Internet tutorials. Focus primarily on what you don’t know and on topics upon which many other areas are dependent.
3. Pair program. Before starting at the Flatiron School, I’d done most of my programming at home. While my dad’s a retired programmer, we’d done little pair programming together, though I recall all of our sessions being helpful. Now that Isaac and I are closely collaborating, the benefits of talking out problems together, simultaneously working on the same bug or feature, and combining our different perspectives and skills are becoming apparent. You’ll learn faster and accomplish more if you program with a partner. Also, in my experience, pair programming is more fun than solo programming — that’s an important benefit.
4. Use test-taking advice from school: if you’re spending too much time on a single problem, move on and return to it later. Facing the same problem for too long without a break can be discouraging and mentally fatiguing. Tackle a different bug or add a new feature and come back to the troubling one later; it can wait, and fresh eyes tend to help. (Also, you might just need to get up, stretch, walk around for a bit. Increasing blood circulation and engaging different parts of your brain are quite helpful.)
5. Examine problems holistically. That is, keep the project’s structure in mind while solving problems. Yesterday, Isaac and I were implementing image uploading, though we ran into trouble, solely because we hadn’t been aware of the project’s structure: we were trying to add an avatar attribute into the user class, but the application’s structure permitted avatars and images to easily work only in the profile class, one we’d overlooked. In Rails, there are a number of directories that could be related to the same abstract idea, such as a user. There could also be other abstract ideas, like a post, a message, or a user group, that might be related to the first one. So keep them in mind, and think about them before deciding how implement a new feature, or when considering the repercussions of a change to the existing structure.
6. Comment out one line of code, see what happens, and repeat with a different line. Doing this line by line can be a great way to debug a problem, because you’re limiting changes to a tiny section of your code, and often, a single change is all that’s needed for a fix. Of course, this could also break something, but in doing so, you’ll have an opportunity to learn: why is this code needed? What other piece of code requires this one? Etc.
7. Organize ideas on paper before tackling a (difficult) problem. In particular, try using mind maps – they allow you to easily connect seemingly disparate ideas about a single subject and discover new ways of approaching a problem. Plus, they’re a great learning aid. If you don’t use mind maps, thinking about your code by outlining or diagramming before racing to the keyboard can still help. You get the tactile benefit of using a pen and a piece of paper (or a marker and a whiteboard, or whatever), and you allow your ideas to gestate a bit, which can help prevent using mistaken or undeveloped approaches when you do get to the computer.
If you don’t already, try using some of these the next time you code. It’d be hard to say that any one is my favorite, because they’ve all pleasantly aided me throughout my work. Pair programming slightly stands out, because I hadn’t used it much before starting at the School, and, as I’ve mentioned, it makes working not just more productive, but more enjoyable. If one or more of the techniques are completely foreign to you, then I’d recommending trying those first. It’s also helpful to try each in isolation before combining them, because you get to see how each affects your attitude and productivity.
I look forward to sharing more of my programming lessons as I discover them. Happy coding!
Make yourself useful.