Zen 3.1

Read this post on 5 Easy Ways to be a Better Developer today.

Agree with most of what it says. Though I wouldn’t call these “easy ways.” None of them is easy unless you are willing to spend time working on them.

My comments on the points…

1) Learn Ruby and Ruby on Rails.

So I call BS on this one. I know the author says these are examples of how to write clean code, but you don’t need to learn a specific language just to learn how to write clean code. What happens now if you have to work in a C or Java or C# environment?

The latest language and coolest technology is just fad. It will come and go. However, basic fundamentals of good programming is always necessary. I’ve always said that once you understand the semantics of programming, syntax will come to you. There’s really no difference in how you program in C, PHP, Java, Python, Ruby or whatever the latest language is. Once you understand WHAT you want to do, you can pick up the language syntax fairly easily.

2) Read The Daily WTF?

This actually is a pretty interesting site to read, if you have the time. Every once in a while it gives examples of good and bad pieces of code.

3) Learn something new every week.

Couldn’t agree more. I’ve always told people that the best programmers are lazy programmers. Lazy programmers will try very hard to make things simple for themselves and avoid doing as much work as possible but still finishes the job. By that, I mean most lazy/good programmers will find existing code/libraries that fit their needs and use them. Obviously there’s certain amount of due diligence you have to do here to ensure the code you are copying is legal and “good.” For example, using Apache Foundation’s libraries is generally legal and “good.” Learning something new every week, e.g., find a intersting library and learn how to use it, will allow the programmer to be lazy when needed.

However, being lazy doesn’t remove the need for programmers to understand the fundamentals. I know I always have arguments with some folks on whether to develop everything from scratch or reuse other’s library. I am always on the side of reuse/copying other people’s code. Some folks tend to want to write his own to fit his exact needs.

Even though we are on the extreme opposite of each other, we generally agree that programmers do need to understand the fundamentals of algorithms and data structures, etc.

4) Understand customer wants != customer needs.

Again, agreed! To add to this point, I believe programmers need to understand the general market they are developing for as well. You need to make sure you understand the general market trend and why customers are buying your solution.

If you are just a programmer that always just take the “spec” from the architects and write the code to meet the “spec,” then you will never become a good programmer. A good programmer should be able to

• Understand what the customers need
• Anticipate the customer needs based on the understanding of the product and market. This is perhaps the MOST difficult step for most programmers as many are so used to just coding from spec.
• Spec a solution that meeds the needs as well as being able to critique others’ specs. Again, some programmers can spec a solution based on the requirements, but a good programmer with understanding of the market and product and customer requirements can critique others’ specs.

5) Find some passion!

This is a bit general but it’s somewhat true. If you don’t like what you are doing, you most likely won’t spend the time on doing the best job.

I also want to add a couple things to the list:

6) Communication is king!

One of the the things I find most lacking in most programmers is the ability to communicate, both written and oral. Just because one can code (even if he’s a clever coder), doesn’t make one a good programmer.

I believe communication is what separates a average programmer from a good or great programmer. In a rapid development environment, it’s critical that everyone understands

• What problem you are trying to solve
• Do you understand the customer use case
• What are the proposed solutions
• What are the pros and cons of the proposed solutions, essentially what’s the thought process behind these solutions
• Which proposed solution you chose and why
• What are the caveats with the chosen solution
• If there are any caveats, are there workarounds
• What is the workflow of the solution, e.g., how is the customer going to use the solution?
• Have you tested the workflow on others and convinced them that’s a viable solution
• Can you prototype it and show it to others for feedback

A good or great programmer would have gone through this process and covered every angle to ensure a successful solution. As you can see, most steps in this process is about communicating to others what your proposed solution is. Communication should happen way before any code is written (unless you are prototyping.)

If I were to hire programmers, regardless of how good the programmer’s coding skill is, if he cannot communicate effectively with the team, then he’s not a good fit for the team.

This article on Engineer Interview Triage? also emphasizes the importance of communication.

7) Be able to do mock ups and prototypes.

This again has to do with communicating your solutions to others. One of the best way I’ve found/seen to communicate your ideas, however brilliant, is to show people what it looks like and how it works. Prototypes are just that, examples and models of the real thing. It doesn’t have to be perfect or covered all cases. But it should be able to demostrate

• The solution. Does this idea really solve the customer issue?
• The workflow. How the customer (customer in this case maybe your fellow team members) will use it from start to finish?

The prototype should convey enough of your solution to get people talking and discussing.

Anyways, these are my thoughts. Love to hear what your thoughts are…