Good Programmers and How to Become One: Questions Five Ways

The guys behind the Ruby Best Practices Blog are my guests for this installment of Questions Five Ways. I'm a big fan of both the RBP book and the blog, so I was really excited when Gregory and I talked about doing a discussion with the team.

Robert Klemme, Gregory Brown (@seacreature), Lakshan Perera (@laktek), and James Britt (@jamesbritt) were the panel that ended up discussing my my question about good programmers.. I hope you enjoy this just as much as I have.

---

What makes a programmer a good (or great) programmer? What should Rubyists be doing to become better programmers?

James Very few of the programmers I've thought of as really good or great thought of themselves that way. They thought well of their skills, but scarcely presented themselves as "rock stars" or "gurus". Very rarely did they proclaim a solution to a problem as the only way, or the even the best way; they explained why it was good, and invited people to find flaws.

It's not a question of simple modesty. You get good by not being complacent, by not believing you've got all the answers.

Robert While I pondered the question(s) it occurred to me that "good" and "great" on their own do not mean much. Without further context there are a ton of possible answers in different directions. You picked the personality direction and I agree wholeheartedly to what you wrote. It is likely that people who are interested in their profession turn out better than those who are just doing a job.

Lakshan Yeah..I agree with this. However, I believe passion is the main driving factor for one to become a better programmer than their profession. If you treat programming as a profession, it could hinder you from expanding your skill-set or taking a paradigm shift. Professionalism is always bound to time, money and ROI. Open mindset with lot of passion is what ignites the real innovation.

Matz started working on Ruby in 1993, but it took him until 1995 to make a public release. Yet, it took at least another 5 years to catch the eye of the mainstream developers. DHH, also did worked more than 1 1/2 years on Rails behind closed doors. During this period, Matz or DHH surely wouldn't have imagined how their work would be accepted by the public or where this would end up. They could commit mainly because they found pleasure in working on it. For me a Great Programmer is the one enjoys, feels passionate about his own work. If something is fascinating enough to yourself, surely it would be fascinating for a majority of like minded people.

Robert The important word in my statement was "interested" and not "profession" - we probably wanted to convey the same but somehow my English seems to have failed me here. I wouldn't go as far as to claim people should get passionate about programming partly, because I'm from the northern parts of Europe and partly, because passion can narrow your mind too much. I do agree, that a strong motivation helps.

James It's said that the truth shall set you free; actually, doubt sets you free. Being convinced you've found The Truth keeps you from growing.

Doubt frees you from being trapped by a single methodology, a single programming paradigm, a single language, whatever it is you've decided the The One True Way. Even if you decide to stick with that methodology, paradigm, or language, routine questioning will help you determine that it's the still the right choice at the time.

Healthy doubt can be tricky; it's easy to slide from scepticism to cynicism, from being self-aware to endlessly self-critical. A key is to be able to recognize and appreciate the good points of what you have and what you know, while understanding that, odds are, you are almost certainly ignorant of much more. It's the difference between, "This is no good", and, "I bet there is better"

So, for example, a good developer is justified in appreciating and enjoying Ruby, but also considers that Haskell or Prolog may be worthwhile too; that one should make use of object-oriented programming, but not be so conceited as to think it is the One True Way and never bother to explore functional or logic-based programming.

Rubyists should foster the habit of constructively questioning what's around them. When someone says "This is the best [practice, tool, library, framework, whatever]", there should be a demand for concrete, verifiable proof, followed by an examination of the alternatives, just to be sure. Rubyists should not assume that everything some Well Known Rubyist says is true, or proper, or even sensible.

Including this.

Greg I agree with all of this, but I think doubt has too much of a negative connotation to it. I tend to think of what you're talking about as curiosity (and maybe you do too, just under a different name). But the important thing for me is that someone is able to conditionally accept something but still want to dig deeper. That drive is what separates those who copy and paste code from those who go back and learn how things work under the hood.

Curiosity leads to a lot of things, and one place curious developers may end up is reading the source of free software projects. Though it seemed like a scary and impossible task to me at one point, this is now the number one way that I learn. See how real problems get solved, and you'll learn a lot more than you could in a book. Naturally, when you see some unfamiliar technique, if you are the least bit curious, you'll try it out in your own code. You'll then learn where the holes were in your understanding, and fill the gaps in as necessary.

Over time when you repeat this process, it becomes easy to see what code is good in what contexts, and what practices are generally going to lead to pitfalls no matter what the context. If you make the effort to teach others about these things, whether through talks, blog posts, or even writing a book, you'll learn even more about what a not-so-great programmer you are, which will in turn, help you find ways to become better.

In the end, hard work pays off. You only get better by reading code, writing code, and then sharing what you've learned with others. The last part may seem like something extra, but it's really not. If you don't put your ideas out there, you're only a great developer in your own mind. What good does that do for you? Usually, while folks like this are too busy being awesome, the true hackers are out writing code and learning from one another.

Robert Unfortunately this attitude is not appreciated everywhere - which I painfully experience right now in the project I am currently involved in. I won't go into the details here but communication is a major issue. This stresses the importance of what you said because the attitude you described helps in these situations: it will keep you open for what the other tries to convey and help you understand his ideas before you even start criticizing them.

Another "direction" is the corporate perspective: from a company's point of view a good programmer is someone who produces code with minimal cost over the software's life cycle. This implies that the person is either extremely cheap (we often see this scenario in outsourcing situations) or produces code with less bugs and a more maintainable structure than equally paid colleagues.

I do believe though that in practice companies often do only apply short term math, e.g. when they cut costs in training or press developers to come up with results quickly which almost automatically produces suboptimal (performance, maintenance) code which needs to be fixed later.

Lakshan Becoming a better programmer is not something that you can achieve overnight. It is something you could attain by enjoying what you do and by doing it constantly. Patience and strong commitment will matter, more than the technology or the tools you've got.

Robert And you need to be open to pick things up and learn.

Lakshan There was a notion back in the day, programming is for people with strong analytical and mathematical skills. In the era memory was scare and data transferring speeds were painfully slow, writing efficient code would've been a must.

But since there are almost no such barriers today, programmers seems to enjoy lot more freedom in creativity and make their lives easy. It is evident from the beautiful DSLs and intuitive frameworks exist today.

Perhaps this is gone to the extent that one might tend to feel creativity is the most important aspect of programming. Yet again we have seen cases how performance and scaling nightmares could haunt us back, when the full focus has been on the beauty of the code rather than it's efficiency.

So according to your view, to be a good programmer what sort of balance one needs to have in terms of analytical and creative skills?

Robert I believe you need both — probably analytic skills a bit more than the creativity. The reason is twofold: for one, you do not always write new code — at least in the corporate world. Then, if you do not have the toolbox to analyze problems and craft (!) solutions your creativity will probably get you nowhere. Compare it with a carpenter: if he does not know his tools and how to actually put his ideas into wood, you won't see his ideas.

Click here to Tweet this

Like this article? reddit it!