Wednesday, June 03, 2009

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!

9 comments:

Parag said...

Nice article. I agree with the personality traits required to become good programmers.

Besides the personality traits, is there a set of steps (maybe a path) which developers can take to improve their programming skills?

Given that a developer has a certain number of hours every week (after work hours), what can they do in those hours that will help them improve their programming skills.

I know this question has been asked several times and answered justas many times. I wanted to know if there were any more thoughts (especially since the discussion on code reading dojos).

Some thoughts that come to mind (much of this stuff comes from what I have read elsewhere)

-- Actual coding on hobby projects
-- Performing code katas
-- Attending conferences and talks
-- Teaching
-- Code reading
-- Refreshing old core skills which have been forgotten

An observation: With so many things to do to stay current and get better, when does one actually work. Or is there a process that developers can follow while working which leads to continuous learning and improvement? Something that will remove the boundaries of working and practicing or working and learning.

--
Regards
Parag

Anonymous said...

All this blather, and no talk of the importance of process, documentation, testing, or any of the mundane elements that define work habits necessary to be the BEST...

Creativity? Analytical Skills? Do what you enjoy? I ask, is this the love boat? Is this is how you truly measure the best?

hmmm....

I think not....

Read about how the BEST programmers on the planet actually work.

http://www.fastcompany.com/node/28121/print

Then hold this up to the comments made in the blog....

All life is vanity it seems...

pate said...

Parag,
good list, and I love your closing question. It's probably worthy of a discussion on it's own.

Anonymous,
process, testing, documentation, etc. are all important, and are (or will be) covered in other articles in the series. Are you really suggesting that the 'soft skills' covered in this article don't matter? or just wanting to see more about the other bits as well?

James Britt said...

"All this blather, and no talk of the importance of process, documentation, testing, or any of the mundane elements that define work habits necessary to be the BEST..."

Blather? What remarkable vanity you display.

Without real heart-felt motivation and passion people do not move on to correctly acquiring those "mundane elements."

More important, those "mundane elements" were created by people searching and questioning and always on the lookout for better ways to apply their craft.

Dear Anonymous, too afraid to back your opinion with a real name, you are seriously missing the forest for the trees.

Perhaps a ride on the Love Boat would give you a better perspective of the big picture.

Suresh said...

Very nice post (and comments).
It is not only passion that is required but also the right direction of learning (may be reading some classic computer science books).
For example, I don't consider a person to be a good programmer if he don't know the difference between Unicode and Ascii, difference between a text file and binary file, profiling (and then improving the preformance) of an existing program - here the use of tools are very important like debugger, profiler, code analysis.
Understanding the system (and the implications of changing/refactoring it - which requires lot of analytical skills), knowledge (i mean working knowledge) of design patterns.

Guoliang Cao said...

Great post. I really enjoyed reading it. I especially like this part:

...Usually, while folks like this are too busy being awesome, the true hackers are out writing code and learning from one another.

Want to add one more thing though. Good programmers try to understand the problem domain as much as possible, and thus can look at it from different perspective, like a end user, a business owner etc. This does not only apply to professional projects, but also applies to hobby projects. As it will help to improve user experience.

Just my 2 cents.

pate said...

Good insight Guoliang, thanks for taking the time to comment.

Piet Hadermann said...

Guoliang: You don't necessary need this skill to be a good programmer. You need it to be a 'software engineer' though, when you want to be able to deliver a fully finished product where you do everything A-Z yourself.

I've met programmers who are excellent at bashing out optimized, bugless code fast, but don't let them design a UI because it will take ages and be completely unworkable. I wouldn't dare to say they aren't good programmers though (maybe: disinterested in the product).
But you can't expect someone whose primary work environment is an IDE and the command-line to be able to design a good UI. Also, people who primary use ms-office products shouldn't be allowed to design a UI either.

I guess part of being a good software designer is realizing that it's not about the code, but about the user-interface interaction and solving the user's problem or making his/her life easier. The user doesn't see the code you know, and for the user, the UI IS the program.

But: someone on a software dev team needs to have this skill (and closely related: UI/UX design skills) to make a successful product.

I'd say: good software needs someone that tries to understand the problem domain as good as possible and look at it from different perspectives. This isn't necessary a programmer though.
It might even be better when this isn't. On the other hand, when it is, that's one less communication path where things can go wrong.

btw: I think the best way to become a better programmer is by doing it, which is what you'll do anyway if you love it. For me I think it's an addiction, I don't think I've spent 1 month in the last 25-ish yrs not typing at least a few lines of code, and I worked as a pro (day-time job) programmer only about 10 yrs out of those 25.

I'll stop rambling now - can't help it though, it's one of my favorite subjects.

Geber22 said...

http://www.fastcompany.com/node/28121/print

The best programmers in the world? Give me a break, I'm sure this company has some good programmers, but there are many programmers that will not give this company a second look. Why?

1. The SEI CMMI process is flawed, I've worked in this process and know first hand that many people work to satisfy the process not the requirement or the software.

2. The CMMI process and the rigid requirements of this project are far too constraining, some people, myself included, don't want to have to justify every single thing they do.

I could go on and on ... but there are many other reasons, govt bureaucracy, corporate bureaucracy ... on and on and on ...