My post on the nature of programming seems to have struck a nerve. Many commenters pondered what makes a developer great. “Ka” thought that:
“You [are] not born [a] good or great programmer, you become one with time and study and hard work. At the beginning, everybody is a bad programmer.”
I disagree. Developers are not born “great,” but greatness does not automatically come with experience. Conversely, lack of experience does not make a developer “bad.” The difference between a great developer and a bad developer is not in their domain knowledge, but their methodology. The distinguishing mark of a great developer is that he codes consciously. Put another way, a good developer always knows why he is doing something. From the perspective of personal ethics, this requires intellectual courage and integrity.
Let me give an illustration of what I mean from personal experience:
When I got into Objective-C development, I was a “bad” developer. Most of my experience is with .Net code. Jumping into the iPhone dev world was intimidating. As as a result, I lacked the courage to learn the architecture. I tried to manipulate blocks of code found on the web without understanding what they were doing. I would copy and paste blocks of code and just change variable names. When things didn’t work, I would look for another block of code to substitute for the failing one, or enter “debugging hell” – running code over and over, making random changes and seeing if they worked. This is the hallmark of a bad developer – imitating without understanding. I kept this up for over a year. It’s not that I didn’t try to learn the language. I got several books and watched iTunes U classes. But the way I used the learning materials was to memorize blocks of code and look for places to stuff them into my code. I wasn’t actually learning the platform, just collecting samples. Some developers spend their entire careers this way. They carry collections of old code everywhere they go, and just grab chunks to insert into new programs. They may never select File => New File or File => New Project in their whole career.
After writing a lot of bad, buggy code, I drifted back to the comfort of .Net. Recently however, I decided to change my attitude. I started by downloading some iPhone code samples and open-source applications. I started in main.m and went through each line of code. If I didn’t understand exactly why a certain symbol was used or what it did, I looked it up. I spent a lot of time on Cocoa Dev Central, Developer.Apple.com, and Stack Overflow looking up things like the reasons why you would assign, retain, or copy a property, or when exactly you need to release an object (for alloc, new, copy or retain) or what you can do with respondsToSelector. There’s really not that much complexity to programming languages – but if you don’t take the time to learn how things work, they will always seem difficult and mysterious. If I had just looked this stuff up to begin with, I would have been far more productive. But, I was intimidated by the environment and tried to shortcut the learning process by imitating without understanding.
Understanding anything complex requires the courage and integrity to engage in difficult, exhausting mental effort. It’s tempting to cheat yourself. It’s easier spend more time in endless copying and debugging that take the effort to understand and create. In the short run, it saves time. But in the long run, developers who understand their craft are magnitudes more productive than the monkey see-monkey do coders. This is the difference between the unprincipled kind of laziness that trades understanding for time and the principled kind of laziness which saves time by understanding.
There’s no happy ending to my story — yet. The proof of a developer is in his work, not his book smarts, and I have yet to produce something to brag about.
For more on the traits of great developers, read these posts by Dave Child and micahel.
It is so important to take some time and get to understand the basics, more complex things pretty much build on top of that. If there is no foundation in understanding the language and what is going on behind the scenes, coding will be simply hacking…
David,
You are “spot on target”. You echo’ed my experience. You have had the “courage” to be honest with yourself and then with the rest of the world.
Hoping to see your “braggable” work soon ….
Cheers …
/rk
(yet another programmer learning to scale the mountain … )
This is fantastically true. Understanding the mathematical foundations of set theory make you a better SQL programmer. Understanding how HTTP works makes you a better web application developer. The elegance and finesse of programming is greatly enhanced by understanding the medium in which you work.
The worst programmers are those that use tools without understanding what the tool is doing for them, or copy and paste code without understanding how it works.
Great post.
I agree with every single word you said. =]
(yet, another programmer learning to scale the mountain)[2]
Great insight! It explains why VB produces horrible programmers: the emphasis on making it “easy” to get things done without understanding what’s going on, cultivates a culture where you think it’s not important to know what’s going on. The only way yo break free is to un-learn VB by forcing yourself to program in C or Python for a while, even if it seems that VB is way easier and that C is torture.
This also explains why Linux and Unix platform are better for doing serious web development: the average developer working on Linux knows a lot more about how the system works, than the average developer working mainly on Windows. Developing a serious product and managing it requires a great deal of system work, and if you don’t know how your system/platform works, you’re doomed to fail.
Windows can of course be used to build and manage serious web-apps. Stackoverflow is made possible by Windows and the .Net platform (pun intended :P), but that’s partly because Jeff Atwood and Joel Spolsky are not just your average developers.
I believe that your term “bad programmer” causes a lot of the confusion. It conflates “programmer with poor practices and attitudes” with “programmer who produces poor quality work”.
Even making that distinction, I know very few “good programmers” who were not “bad programmers” in both senses at the beginning of their careers. Your experience is not at all uncommon. To be precise, all of the good programmers whom I both know now and also knew earlier in their careers had worse practices early in their careers. Your experiences may differ.
The difference is that people who become “good programmers” exercise self-awareness at some point, and start actively improving themselves for the sake of improving themselves. That the quality of the work also improves is a side-effect.
Your mentality and insight shows your promise of becoming a great anything really. This reminds me of something I was told by a music teacher: The learning process has three parts, imitation, integration, and finally understanding.
I think this applies to any skill. I think theres no such thing as a “bad” programmer, just a beginner who refuses to put in the effort to go through the learning process and advance his skills. You can acquire knowledge and become a human encyclopedia without learning the meaning of any of it, and this will show when you try to apply that immense knowledge of yours. Some people just never learn, they don’t want to – I know because I myself am often guilty of this.
I’ve noticed that great programmers have 2 attributes:
1. They are brilliant (I.Q. 130+)
2. They are disciplined (constantly self-training, constantly trying to increase simplicity and clarity)
Awesome,it takes a lot of guts to tell this.Appreciate your honesty.
It also helped me to realize what is a good developer . I am sure you have a lot of braggable work ,but you don’t prefer to brag ,since you keep raising your bar everytime you accomplish something. awesome.
I totally agree with you on this! I’ve just started a new job as a PHP developer and I am struggling big time, due to years of taking short cuts and not actually taking the time to understand the fundamentals of what I was actually doing. I am considering going back to the drawing board.