Change and growth are faster than ever in software these days. There’s Silverlight, LINQ and WPF from Microsoft. There’s AJAX, REST and Rails 2.0 in the web development world. Java has JavaFX. There used to be a time when you had to pick one language and run with it because it was just too overwhelming to master more than one. Now it’s impossible to keep up with new developments within even a single language. This has many developers scrambling to figure out what to learn next. No one wants to invest countless hours in a losing technology… you want to learn something that will be useful in the long run. I have just the skill for you, and it doesn’t matter what language you work with.

Learn to write well. [*]

“But that’s not a programming skill!” you’re probably saying. Or maybe you’re disappointed because you thought I was going to be talking about the very latest cutting-edge API you can’t live without. Good writing skill is probably one of the most useful talents you can develop as a software engineer, and ignoring it is one of the biggest mistakes most programmers make.

Working in a cave

I used to work with a programmer who we jokingly referred to as a “walking MSDN”. He knew all the Win32 APIs, he could tell you the int values of const definitions and could enumerate the parameter lists to functions overloaded 30 times over. As a programmer, when given an assignment, he would go into his cave, hammer out a solution and would re-emerge from his cave with something that worked. I mean that in the most serious way… he would hammer his code into submission until it worked. There was no such thing as elegant code to him; it worked or it didn’t.

His manager both loved and feared him because he would do everything required on time, but he had no idea what happened in that cave. There was no visibility at all into what he was doing, and his manager had to blindly rely on the fact that he had a history of getting stuff done on time.

Programmers loved and feared him because he was incredibly knowledgeable and could answer any question about how this or that API worked. But whenever someone had to get inside his code, it was a pure mystery. There was no documentation, no models, no code comments… nothing but the raw code itself. For mister MSDN, this was no problem, because it was all in his head. For everyone else, it was like being lost in a big city with no map.

Was he a good programmer? Most people that worked with him would say yes… he was technically proficient and met his deadlines. But most of those same people would also say that they had a very difficult time working with him. That element of fear that he generated was a direct result of not being able, or willing, to communicate. He couldn’t communicate his plans or designs to other programmers. He couldn’t communicate his status with his managers. He couldn’t communicate his interfaces with other teams. Eventually when he left, his code left a wake of terror felt by those that had to pick up where he left off.

The lifespan of a tech skill

Technologies come and go. Seven or so years ago, I felt like I was completely on top of my game when it came to programming technology, at least in the Microsoft world. I had a very deep understanding of COM and ATL, thanks to Chris Sells, Brent Rector and Richard Grimes, and I coupled that with VB6 on the front end. This was a really potent combination and I thought I’d be working with that for years and years. But, as with most technical skills, it didn’t last long… .Net came along a year later, ATL became outdated and VB6 just disappeared into the sunset. Now that I’ve mastered C#, I find that I haven’t even touched the new stuff in .Net 3.5. The point is, no matter what technology you learn, with very few exceptions, it will disappear or be overshadowed by newer technologies (and probably sooner than later).

Writing skills will last you a lifetime, though. You will always benefit from it, regardless of what language or technology your use, or whether you’re even a programmer or not. Good writing skills are universal and will never be replaced.

The golden rule of documenting software design

Try to document whatever you are working on. It doesn’t have to be the worlds most perfect UML and you don’t need an expensive tool to do it. In fact, Wordpad and Paint are sufficient, and don’t tell me you don’t have those. Write in a way that best expresses your intent and your thought process in coming to the design decisions you did. I have a golden rule of documenting software design:

Describe your design to others as you would have others describe their design to you.

When you spend the time to do this, you’ll find that many benefits will follow. You’ll get feedback from others that may have tried to solve a similar problem and have insight you may not have thought of. You’ll leave a clear trail to follow for those that work on the code after you. Most importantly, you’ll shed light on your work, which everyone who depends on your work will appreciate. Even if no one else reads what you write, you’ll still have worked through problems in your head that can only lead to better design in the long run. There is no downside to documenting your designs.

If that wasn’t enough, consider the fact that someday you may be looking for another programming job. You’ll sit down with other developers and managers in an interview and try to describe how great your technical abilities are. You are now one of the vast sea of programmers trying to get that job. With your resume alone, a company has only your answers during the interview to base their decision on. With your documentation in hand, though, you can show them in full detail the type of work you’ve done and give them deeper insight into your thought process than they could ever get from interview questions alone. Your documentation serves as a body of work that travels with you, long after you’ve stopped working on this or that code, and speaks for your experience.

Of course, these skills won’t write code for you. But think about how much time you’ve devoted to learning programming based skills. Think about how many books you’ve purchased and read about programming. It’s a huge investment in time and money to keep up with. The next time you have some free cycles to sit down and pick up something new, consider skipping the software development section of the bookstore and pick up a book about technical writing. Here are some good books on this subject: