Software development is hard. The amount of information you need to know to be effective in any area of software engineering is staggering. And the amount of new information coming down the pipe can be overwhelming. Whether you're doing web services programming in the cloud or embedded software programming for micro-controllers, you should know at least one programming language well, and probably more than one to be really effective. There will be some set of libraries and frameworks to know, and the more you know, the better choices you'll be able to make regarding which ones to use for a given design.
should know a good software development process, likely something agile.
Then there's your development environment: the OS, an IDE or text
editor, compilers, build automation, bug tracking, version control, unit
testing, etc. You should have deep knowledge of all of these things.
Depending on your application domain, you'll need to know about digital
signal processing, power management, statistics, probability, user
interfaces, user experience, networking, databases, control systems,
discrete mathematics, graph theory, and the list goes on. Believe me,
that's only a very small, partial list, and don't forget the actual
domain-specific knowledge for the field in which you're writing
The set of knowledge that a software engineer
uses is vast and unique to each programmer, and if you're keeping up on
personal development, you're adding new layers to it all the time.
However, I've found that there's a short list of development practices
that stays fairly constant throughout the years, even with new languages
and frameworks and tools appearing every week. This list may be
different for you. Heck, in the future it may be different for me,
although probably not by much. Up to this point in my career these
practices have served me quite well. They're the concepts I think about
every day while I'm designing and programming, and while tools and
frameworks continue to change, these have largely stayed the same. They
are the stalwart knights of my programming days.
DRY: This principle comes from The Pragmatic Programmer,
and it stands for Don't Repeat Yourself. I'm sure I don't have to go
into too much detail here because any programmer worth his salt already
knows it. For anyone that doesn't, stop reading this right now and go
get a copy of The Pragmatic Programmer. Read it. DRY is the
essence of programming. It's deceptively simple to understand in theory,
and wickedly hard to implement in practice. I am constantly thinking up
and trying new ways to achieve the ideals of this principle.
Software engineering is hard enough as it is without us
over-complicating our designs and our code. I always aim to Keep It
Simple, Stupid. Another way to keep this idea in mind is to aim to do the simplest thing that could possibly work.
Don't try to dress up a simple solution in a big, frilly frock of
design patterns and UML diagrams that it doesn't need. Do only what is
necessary to solve the problem at hand, and no more. Over-design is a
house of cards, and if you can barely understand it when you're building
it, it will all come crashing down when you're trying to maintain it
six months from now. Do yourself, or the next programmer that has to
look at your code, a favor and write it as cleanly and concisely as possible, and keep it simple. You'll get more done, you're more likely
to get it right, and you're more likely to understand it later.
Closely related to KISS, YAGNI is the principle of You Aren't Gonna
Need It. That multi-level inheritance hierarchy for implementing
unspecified future features? You aren't gonna need it. That quadruple
redundant, auto-recovery, exponential hold-off protocol for messaging
between micro-controllers? You aren't gonna need it. That SaaS API for
your new meeting software in the cloud? Seriously, you aren't gonna need
it! At least, you don't need it yet. Get the stuff working now that
needs to be working now, and save the stuff that you could need
later for later. Sure, you can think a bit about how you would add
future features if you really think you're going to need them, so you
don't completely paint yourself into a corner from the beginning. But
there's a big difference between planning for future expansion and
actually erecting all of the scaffolding and roughing in the
architecture. Do the former, not the latter.
There are many formulations of this principle, many coming from
philosophers and scientists other than the one for whom it is attributed
to, William of Ockham. The one that I learned and prefer, but cannot
find a reference to is, "in the absence of contradiction, the simplest
explanation is best." I use this principle mostly as a guide in
troubleshooting and debugging, but also in general problem solving
during design. "Best" can mean everything from most correct to most
useful to most desirable. If you're trying to figure out why a build is
broken, it's much more likely that it was due to some recently added
code with a bug in it than a latent bug that happened to surface now.
It's still possible that it could be the latent bug, but I definitely
wouldn't start looking there. I would start with the most recently
checked in code. Occam's Razor is surprisingly versatile, and I find
myself using it constantly.
Formally, Amdahl's Law states that "the speedup of a program using
multiple processors in parallel computing is limited by the time needed
for the sequential fraction of the program." That's quite a mouthful,
but basically it means that your program can only be as fast as its
slowest component. Another way to think about it in the context of
optimizing a program for performance is that you're going to get the
greatest speedup from the part of the program that takes the longest to
execute. Sounds obvious, right? So don't spend your time optimizing
esoteric features of a program that only rarely execute or processes
that happen in parallel with long-running IO or database operations. If
your program is spending 40% of its time doing something that the user
is waiting for, focus on that instead.
"select" Isn't Broken: Here's another one from The Pragmatic Programmer.
This time the authors relate a story about "a senior engineer [who] was
convinced that the select system call was broken on Solaris." Don't
fall into this trap. Sure, it really looks like you're using that
library function correctly. You've looked over your code dozens of times
and you are positively convinced that it is doing what it's supposed to
do. It must be a bug in the library. No, the compiler is making a
mistake when optimizing this code section. No, there's a bug in the
processor that I have to work around. Stop, just stop already. Do you
really think any of those systems that have seen orders of magnitude
more use and abuse than your code are all that bug-ridden? Take another
look at your own code. The bug is almost certainly there. In a milder
form of this practice, you should always assume the bug you are seeing
is your own fault. Inspect your own code as thoroughly as you can before
trying to blame it on a coworker's code. You might save yourself some
Don't Let Standards Make You Stupid:
I don't have a link for this one because I haven't seen this idea
wrapped up into a pithy phrase, yet. Instead, I made up my own. The idea
is that while standards are generally a good thing, they should not
preclude you from thinking about the problem at hand and solving it in
the best way possible. Standards can add some uniformity and consistency
to programming and offer known solutions to common problems, but
standards can also go to far. They can become rigid structures that mask
over issues that are unique to particular problems that require their
own creative thinking. Make sure to balance out a hefty set of standards
with an eye for exceptional circumstances where those standards don't
apply. And then use your brain.
Do Not Reinvent the Wheel: A good way to avoid this problem is to watch out for its main symptom - NIH.
If you find yourself implementing basic string processing algorithms or
building your own data structures, you could be reinventing the wheel.
Try spending a few minutes looking around public code repositories or
even your language's standard library to make sure you're not wasting
your time writing code that's already been written hundreds of times
before, and will likely perform better than yours because it's already
been extensively tested and optimized. There is some need for balance
here because if your problem can be solved quickly with a few short
methods or a small class or two, it may take longer to find, adapt, and
verify someone else's code instead of rolling your own. On the other
hand, if the solution comes from a well maintained framework with a good
API and documentation, you can benefit from future updates to the
framework. And now that you know it exists, you can reuse it in other
projects. In any case, try to find the best way to solve your problems
without blindly resorting to writing more code.
Rubber Duck Debugging:
This is a method of debugging where, when you get completely stuck, you
turn to the rubber duck sitting on your desk, and ask it for help. You
have to explain your problem with enough detail that the duck will be
able to understand the problem and offer a solution. Quite often the act
of constructing a well-formulated question will reveal the solution,
all on its own, and that is the point of the exercise. If not, then
perhaps the duck will miraculously tell you the answer after all. I
wouldn't depend on that, though. For more information on this excellent
problem solving method, I'll point you to Jeff Atwood.
Here is another practice that hasn't been phrased as such, but is very
commonly recommended in various ways. It could also be called shower
debugging, or brushing-your-teeth debugging, or go-for-a-walk debugging.
The idea is to work on the problem as much as you can. Give it a good
effort, and if you get stuck, tuck it away in the back of your mind and
go do something mindless. You're subconscious will continue mulling over
the problem, and then when you least expect it, the solution will pop
into your head. When I use this technique, I normally don't immediately
turn to doing something mindless when I get stuck. I'll put my current
problem aside and work on something else. Because my mind is otherwise
occupied, those latent solutions normally don't come to me right away.
They turn up as I'm falling asleep at night. This happens so frequently
that I've learned to task switch as soon as I run out of ideas for my
current problem, instead of staring blankly at the computer screen for
hours. It can be frustrating to leave a problem unsolved, but I could
also waste a lot of time fighting for new ideas without making any
progress. I know I'll figure it out when my mind is calm and relaxed
that night, and I'll make more progress the next day.
Leave It Better Than You Found It:
My last software practice comes from many years in the Boy Scouts. My
scoutmaster was an adamant proponent of Robert Baden-Powell's advice to
"leave this world a little better than you found it." In scouts that
meant cleaning up trash when you saw it, leaving campsites in better
shape than when you arrived, and generally being a good caretaker for
mother nature. That lesson has stuck with me in software engineering,
and when I'm working on a piece of code, I try to leave it better than I
found it, too. I take the time to refactor when I'm changing code so
that variable names are more self-explanatory, methods are shorter and
more understandable, and code formatting is more consistent. I don't go
hog-wild, rewriting every file I touch, but if I see something that
looks out of place, I'll take the time to make it a little bit better
for the next programmer.
That brings my list of good software practices up to eleven.
Maybe that's not such a short list, but they are things I use everyday.
I've found them all immensely valuable, and maybe you will, too.