≡ Menu

4 Things I’ve Learned as a Software Engineer

1) Begin with a clear goal.

Software developers often work from vague specifications. We’re used to it. It doesn’t surprise us. We’re also used to reworking the products of vague requirements.

In software development, ‘firming up the spec’ is one step that’s going to happen. The question is when. It can happen on purpose at the beginning of the project. This rarely happens. When it does, it usually leads to a smooth implementation with a good final product. Let’s call this scenario ‘focused execution.’

It can happen incidentally during the course of the project. This is more likely. This usually leads to some rework, some wasted effort, but an acceptable product. Often the product can be improved in the future. Let’s call this scenario ‘incremental improvement.’

It can also happen at the end of the project. This can go two ways. One is, “We should have done x. After all that effort, it’s finally clear what we should do. Great – let’s do it.” The result is lots of wasted effort, lots of rework, but often a good (but late) product. Let’s call this scenario ‘do-over.’ It’s fairly common in the software business.

The other way ‘firming up the spec’ can happen at the end of the project is, “We should have done x. Too late. Let’s just give up on the whole thing.” This is also common. It happens all the time in undisciplined software shops. After all that time and effort, it’s finally clear what everyone wants. And it’s too late. Let’s call this scenario ‘regret’.

The same is true in life. If you invest the effort to clarify your goals (focused execution), you can avoid the wasted effort of do-overs and the pain of regret. Note: this doesn’t mean you won’t make some adjustments as you learn more (i.e. incremental improvement). In life as in software development, things seldom work exactly as planned. But generally speaking, the clearer and earlier you make your goal, the better your result will be.

2) Setup your environment.

For a long time, when I began a project, my inclination was to just start with no planning or preparation. I didn’t like configuring my editor, arranging my files, setting my OS settings, etc. I would often use whatever tools were installed by default (think notepad editor).

I used to do the same thing on physical projects. Instead of taking the time to get out a ladder, I’d spend twice that time installing a light from a too-short chair. Instead of retrieving a real screwdriver, I’d labor away with my swiss army knife, jabbing my hands every few seconds. All that to avoid a few minutes to retrieve the right tools. That was foolish.

I no longer do that. Now, I’ll take the time to acquire and configure good tools and arrange my work space. The productivity gains far outweigh the time invested in setting up. Work is easier and more enjoyable that way, too.

3) Tighten your feedback loop.

Software development is heavy on experimentation. So is life. There is a lot of ‘test – observe – correct – repeat’. You need to know if what you’re doing is getting you closer to your goal. The sooner you can enter this loop, the sooner you can begin correcting course where necessary. The tighter you can get this loop, the faster your work will go.

I’ve worked on projects where (largely for security reasons, but also for bureaucracy reasons) this debug loop was painfully slow. There were many barriers that inhibited me from testing my work quickly. This created a big gap between the ‘correct’ and ‘test’ items in my loop. That gap makes it difficult to create momentum toward the goal.

That’s no way to work. Now, whenever possible I write a pushbutton script (basically a program that tests my work and tells me whether it’s correct) to test my work for me. This way, I know almost immediately whether my changes produced the desired effects. I might complete 20 debug loops per hour this way.

Life is like that also. If your goal is to improve your health, you might begin by switching your exercise from walking to swimming. Or maybe you replace your morning cereal with a protein shake. Or maybe you go to bed 1 hour earlier. Regardless, if you have to wait months between appointments for a doctor to tell you how it’s working, it’s going to be a long process of experimenting to find an optimal solution for you.

Instead of waiting for your doctor for feedback, what if you bought a fat caliper and measured your body fat percent periodically? Or maybe you could track your resting heart rate? Whatever metric you’re trying to optimize, the shorter your feedback loop, the sooner you can correct where necessary.

Note: this doesn’t mean that all feedback must be acted upon immediately. Some things take time to work. You may have to persist through a period of recalibration. That’s fine. The point is that by working in this tight loop you have the information to decide if a correction is in order.

4) Get started.

In software development, there are many distracting tasks that – while moderately productive – are not the best use of time. There’s always something else to do instead of actual work – something that gives the illusion of moving you closer to your goal. There’s another article to read about how to do whatever it is you’re trying to do. Or some email to process. Or some meeting to attend. There’s always that temptation to avoid starting.

The best engineers I know avoid this temptation. Every day they sit down and open their editors and get started.

Until you’ve begun, inertia is your enemy. If you want to achieve your goal, you must defeat that inertia every day by getting started. And every time you defeat it, it becomes easier to defeat it the next time. Soon, you’ve developed the habit of getting started. Also, after you get started inertia is working for you instead of against you. It’s easier to keep making progress than to stop. Inertia has become your ally.

Conclusion

Put all this together – clear goals, conducive working conditions, tight feedback loop, and positive inertia – and you will be a productivity machine.