Things I Learned the Hard Way: Engineering and Computer Science in the Real World
part of Writings
Aug 29 2001


This essay is a summary of points made by David Parmenter during a talk given at ArsDigita University. The university lost its funding and no longer exists but wonderful lectures and colloquia are still on-line. I’ve you’re learning Computer Sciences, I highly recommend to watch them. You can watch them on-line (part 1part 2) or download for offline viewing.

Summary of what does David says

Software is complex and hard. The big issue is trying to get the complexity under control. “Code like hell” is not a good way to do it. No process is necessarily better than other, but a process is much better than no process. Extreme Programming: especially the testing perspective (develop tests first).
Talk to the costumer, even if you’re just a programmer. Be costumer focused.
Ask questions, you might learn something. Network with your peers. Don’t work for or with bozos. Interview is a both-way: they evaluate you, you evaluate them.
Make use out of down-time. Don’t play solitaire, go grab the source code you haven’t seen and start reading it. Learn new stuff. Read open-source stuff.
Build the debugging into the system - otherwise it’ll be hell to figure out why it doesn’t work. Instrument the code. Use the google to find for solutions to problems (compiler warnings etc.)
Keep it simple and work in small chunks.
Get into the habit of writing programs from scratch.
Don’t put things off. When asked to do something, just do it.
Read the manual (for tools, for library functions).
Be grateful to people finding bugs in your software (i.e., don’t let your hurt ego interfere).
Don’t program by experimentation.
Automate the workflow (always when you repeat the same keystrokes). You can use Python, Ruby, Perl, Lisp.
Use regexps to grep through the source in Emacs. (I would add: use SourceInsight instead, much more powerful (especially for C/C++ code).
Refactor the code - take the code apart and put it together again. It’s scary to refactor - fear that change will break the stuff. Another reason to have automated tests.
Learn the tools - they are productivity gains.
Use version control. Use bug database (defect tracking).
Quality analyzer (purify) and code coverage tools. Profilers. Expensive.
Learn to estimate. Be pessimistic. Make trade-offs, prioritize.
Business people matter. Business stuff matters. Technology is secondary.
Installation script for your software is important - this is the first thing that a custmore sees. Make it good.
Don’t work with primadonnas.

Feedback about page:

Optional: your email if you want me to get back to you: