Software development, or “programming” if you like, is plain weird to your average person. While we live in a digital age, giving a detailed description of what I do still feels something akin to describing an elaborate Santería healing ritual to a farmer from Lima, Ohio (no offense to any farmers from Lima, Ohio who read my blog, it’s just the first illustration that came to mind).
Really, though, a great deal of the “best practices” in software development apply to building or making anything. Good programming is not some sort of voodoo, it’s really just good engineering applied to software. I think software development has some great tie-ins to general life principles that are highly transferable to other areas.
Which leads me to want to think about distilling some lessons I’ve learned so far in my career. Quite frankly, a number of books that I’ve read lately which have been totally unrelated to software development appropriate some of these same principles to some degree. I’m not sure I’ve come anywhere close to fulling applying these principles, but I do feel that spending time developing software has helped me to pay attention to them. Here are some that come to mind:
- Win small victories. Find small units of whatever it is you are working on and make as many small victories as you can. A big victory may feel better, but it’s also easier to fail or lose motivation when you are tackling a big unit of work. If you work incrementally through small units you are more likely to succeed. It is amazing how much you can get done by finishing little snippets of a task here and there! One huge advantage to this approach is that it will be much easier to “turn back the clock” and start over if the unit of work gets messed up. Another advantage is that smaller chunks of work are easier to delegate if necessary. And it’s easier to verify the correctness of a small chunk of work.
- Fail early. This goes hand-in-hand with the previous point. Part of the reason why we often fail miserably at things is because we delay failing until the failure gets really escalated. It might be because we are perfectionists, self-conscious, or perhaps because we believe we are not going to fail. However, the simple fact is that we will fail. So do it ASAP, so you can start learning from it. Experience shows that people who made a failure quickly and learned from it tend to do much better than those who agonize forever to make a fully polish product, but simply make their failure more costly and time-consuming.
- Don’t be afraid to fail. This builds on the previous point. Don’t be afraid to fail, but manage your failures. Don’t try to avoid failing, but rather try to be in control of when you fail. As has already been said, fail early. And fail in safe environments. Isolate your failures by failing in small segments of your task.
- Don’t sweat the details initially. Make educated guesses about what will be needed, but don’t let the specifics bog you down. Get to a working rough draft as soon as you can. People who start to refine their work before a draft has been finished tend to ether get nowhere or spend inordinate amount of time. You can’t anticipate where this will go fully, so make educated guesses about what is best and plod away to the first draft! If you polish as you go, you may spend time on polish that is not necessary. You’ll have a much better vantage point as to what is necessary if you just plod away and leave the polish for later. Most beautiful work has been done by assembling what immediately comes to mind in a rapid fashion and then fussing about the details afterwards.
- Don’t trust your memory. Forget the fact if you can. And if you must recall it, write it down, because you won’t remember it in a month. I make writing it down the second rate option, because having to remember or write down tons of stuff is a red flag in many cases. Life is not a fact gobbling exercise. You should be prepared to forget most of what comes to your attention. That is healthy. Any task that requires you to do a large amount of recalling tends to be either inefficient or bogged down by unnecessary details. High school anyone? Couldn’t you just automate it somehow and focus on better stuff?
- Laziness is a vice, but efficiency isn’t and sometimes efficiency can seem like laziness. People who repeat mundane tasks a lot sure seem like “hard workers”. However, a *good* worker would rather be “lazy” and find a good way to eliminate that repetition so he can focus on more stimulating and important things. People who plod away at something with little or no understanding of the tasks at hand may sometimes seem to be “hard workers”, but the person who pauses and deliberately slows down to understand the task is usually a better worker. Hard work is not an end in and of itself, it always must accomplish a purpose. And sometimes something that seems lazy actually accomplishes the purpose better than the “hard work” option.
- Keep things simple as you can. Avoid unnecessary complexity. I say “unnecessary” because in some cases complexity is justified. For example, don’t simplify one thing if it means making 20 other things more complex.That said, simple things are almost always better, more elegant, easier to maintain, and more efficient, than complicated things. Be more hesitant in adding something than taking something away. Your instinctive way of doing something is more often than not a bit too complicated.
- Don’t be afraid to start over again. Sometimes the worst thing you can do is keep on plugging away at a sinking ship. Sometimes starting over again is the jolt you need to actually make some headway on the thing. Don’t let fear keep of scrapping your work keep you working in an direction that is most likely futile. Throw it away, take a deep breath, and take a fresh look at the problem or task at hand.
These aren’t meant to be unthinking mantras, but they are helpful guides in software development and probably other areas of life. I hope they are of assistance!