This post will be the first in a series in which I try to distill knowledge gleaned from a year working as a software engineer.
There are lots of books out there about how to design software and how to write good software, but I learned the most from reading other people’s code, and understanding the system we worked with every day*. A good system is an excellent use case to keep in mind should you ever encounter the same problem. A bad system is a counterexample, and a challenge to do better.
In no specific order, some concrete principles:
Write code from the top down:
If method D calls method A, B, and C. Write D first so you know the best interface for A, B, and C.
Use an interactive debugger:
Or at least map your editor to a) step line by line through functions b) step function by function through code. Debugging is an exercise is practical skepticism. Doubt all of your beliefs about the api, and work through examples.
Learn version control and undo:
Sometimes the best way to debug is to test all of your changes incrementally. If that sounds tedious to you, version control will help. For vim users, gundo.vim is a beautiful piece of work.
Write descriptive method names, even really long ones.
Every time you use a function, you will look at its name. This is not true for doc strings. The caveat, of course, is that a long, descriptive name that is clear to you may not be so clear to someone else. I’ve found that the best way to avoid this is to choose active, precise verbs.
Know your language:
Everybody should read GOF**, if only because the patterns enumerated are important metaphors for software development. But those patterns don’t apply to every language or every use case. E.g. in a dynamic language such as python, __new__ and __metaclass__ often remove the need for traditional heavy hitters like factories, and descriptors/decorators provide convenient ways to deliver side effects for otherwise pure functions.
Generalize:
Think of it as preemptive copy & pasting.
Be ruthless about refactoring
Touch large chunks of code. It’s better to refactor than to hack. For this, it’ll help to have either an IDE that has good refactoring support, or a masterful command of regular expressions. There’s quite a bit of fixed cost for getting all the tools setup, but it’s worth it.
* Examples of great python code:
- http://code.activestate.com/recipes/users/178123/ Recipes by Raymond Hettinger
- http://hg.python.org/cpython/file/2.7/Lib/ast.py (ast in the standard library)
- http://norvig.com/lispy.html (Peter norvig on writing a lisp interpreter in python)
- http://wiki.python.org/moin/PythonDecoratorLibrary (Python Decorator Library)
** GOF Book. Design Patterns: Elements of Reusable Object-Oriented Software
No Comments