Practicing Software Engineering
Home : Writing : by Trevis Rothwell, May 2012
In his book
Outliers
As software engineers, how much are we practicing?
My 10,000 Hours
I have been working as a professional software engineer for about eight years now. Assuming working 46 weeks out of the year at 30 hours a week (subtracting hours for non-technical staff meetings and dental appointments and what-not), that puts me at having accomplished a little over 11,000 hours of software engineering work.
Wow! I must be a pretty accomplished software engineer. But what exactly have I been practicing? My work has been all over the map. I've written and edited documentation. I've done research and writeups for product certifications. I've written automated tests. I've performed manual tests. I've supported users. Only a fraction of my time (maybe in the vicinity of 1/3) has been spent really, actually writing software. That's okay, though, because all of these tasks are part of the software engineering experience. Typing C code into Emacs is only one aspect of the work.
But for all of that, too often when I say to myself, "I'm going to build such-and-such software application from scratch," I feel as if my mind has turned to mush, and get easily distracted by shiny new links to click on the internet. I may be well-practiced at sundry tasks as part of working on a software engineering team, but when it comes to developing applications outside of my routine, I feel woefully out of touch.
Last year, I wrote a little iPhone application that implements the borda count voting algorithm. After spending a while with family trying to decide which movie to watch, I thought this might make a useful program to carry around on my phone.
It took me approximately ten hours across less than a week of part-time evenings to build this application. Yet several times I nearly gave up and quit because I felt too mentally mushy. In theory, I knew what to do, but I was having difficulty harnessing the focus and motivation to make myself do it. For a ten-hour project.
While I may have 10,000+ hours of practice time as a software engineer in general, software development is a huge field. I do not yet have 10,000 hours of practice building iPhone applications. I have done a fair bit of consulting hours on iPhone work, but that was mostly adding to existing software, not creating new applications from scratch all the time.
If I want to excel at whipping out new iPhone applications, then I need to practice creating iPhone applications. As many as possible. One or two a year is probably not going to be sufficient. That may well put me ahead in expertise of programmers who have never written iPhone code at all, but in order to become proficient to the point where a small ten-hours project doesn't seem forboding, I need to have created lots of projects, and to have engrained the process into my thinking.
What to Practice?
What other areas of software engineering would be useful to practice? Anything that we want to be able to do better! Here are some examples of general tasks that practice could make us more profiecient at:
- Writing end-user documentation
- Designing front-end user interfaces
- Creating data models
- Writing Makefiles (or whatever build system you use)
- Various tasks in your versioning software (Git, SVN, etc... how much deep thought do you need to put into reverting a file? Merging a branch?)
- Using your text editor
How about more grandiose ideas? You could practice building an entire web application. Or a desktop application. Or a command-line utility. You could practice writing a reference manual for a programming language.
How about things that are more removed from software per se? You could practice marketing and sales. You could practice coming up with application ideas and seeing how well they are received by potential customers / users. (In these cases, you could build the product yourself, or just practice marketing an existing product, obtain feedback before writing any code, etc.)
The First Take Might Be Good
Sometimes when recording a music track, the player might feel like running through a practice take first, before recording. There's no pressure to do it right, it's simply a rehearsal. If mistakes are made, it's no big deal, because it's not for real.
But that practice run-through might turn out great! Sometimes better than any subsequent attempt. The recording engineer would be wise, especially with today's digital recorders, to go ahead and capture that first practice take, just in case.
When software developers are working on their own, coming up with their own products and trying to market them, the fear of failure can be debilitating. "What if the idea isn't any good? What if I'm not proficient at some technology and I make mistakes? What if my solution doesn't scale well enough? Maybe I'd better spend more time planning before I actually try to do anything..."
Planning is good, but excessive planning out of fear can lead to never accomplishing anything. You might be able to mitigate the fear of failure by commencing your project as a practice run-through. If indeed the project does fail in some respect, you can confidently tell yourself that you were practicing, and more readily learn from your mistakes, in order to improve for next time.
On the other hand, your practice project might turn out great! You might surprise yourself with what you can accomplish.
But regardless of the results, success or failure, the very act of doing the project will help you become more proficient as a software engineer. And in some sense, no finished project is truly a failure; you succeeded in completing it.
tjr@acm.org