LinkLog: Do What You Love

From a Non-Programmer’s Apology, Aaron produces one of the best articles I have read – “To be or not to be” a programmer.

Learning is like compound interest. A little bit of knowledge makes it easier to pick up more. Knowing what addition is and how to do it, you can then read a wide variety of things that use addition, thus knowing even more and being able to use that knowledge in a similar manner.5 And so, the growth in knowledge accelerates.6 This is why children who get started on something at a young age, as Mozart did, grow up to have such an advantage.

But there is another, more important motivator – interest.

And even if (highly implausibly) we were able to control the circumstances in which all children grew up so as to maximize their ability to perform the most important tasks, that still would not be enough, since in addition to aptitude there is also interest.

A quote in his notes, provides some clue on how to tackle such dilemmas – where you are good at one thing but would really like to do something else.

“when it comes to choosing a life path, you should do what you love — because if you don’t love it, you are unlikely to work hard enough to get very good. Most people naturally don’t like to do things they aren’t ‘good’ at. So they often give up, telling themselves they simply don’t possess the talent for math or skiing or the violin. But what they really lack is the desire to be good and to undertake the deliberate practice that would make them better.”

Related The Definition of Work (originally titled “It is hard to find work you love”)

Golden Rule of Documenting Software Design

In the Next Programming Skill You Should Learn, Scott Hackett talks about the ability to communicate well, especially in writing. I totally agree. The post is certainly worth a read.

An unexpected bonus in this post is Scott’s tips on the golden rule of documenting software design.

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.

One of the experiments I am conducting with a set of interns is to make them write a LearnLog and ProjectLog – just a few bullets or short sentences. We do this in a wiki so that every one in the project has access to it.  It is also one of the easiest and most effective ways to communicate asynchronously with the team.

In the Project Log, they are supposed to write the following:

  • Design decisions
  • Decision to use libraries/tools and why
  • Problem areas and stumbling blocks and how they solved it
  • A list of links to the resources they used

It is still an uphill battle but we are getting better gradually.

Conversational Writing

Here is a nice post on why Conversational writing kicks Formal Writing’s Ass.

What most people mean when they say “write the way you talk” is something like, “the way you talk when you’re explaining something to a friend, filtering out the ‘um’, ‘you know’, and ‘er’ parts, and editing for the way you wish you’d said it.”

It makes sense. Your writing style is influenced by what you read.  But email changed all that. Email is mostly conversational. And blogs are conversational too. A lot more of what I read, nowadays,  comes from blogs. If conversational style is good, and blogs are mostly conversational, it makes sense to increase blogs in an organization so everyone can communicate more effectively.