The four golden rules to be a better software developer.

http://www.makinggoodsoftware.com/2009/11/09/the-four-golden-rules-to-be-a-better-software-developer/

by wtfdeveloper • 17 years ago

30 8 17 years ago

edw5192• 17 years ago

All 4 rules are exactly the opposite of what they should be...

Rule number 1: My code is crap.

What we need is great code. Everywhere. And we need programmers to produce great code. How can we expect anyone to aspire to produce great code by thinking that their code is "crap".

We are all learning and we are all at a different place in our journey, but one thing is certain: we are all capable of doing better and aspiring to greatness. Self degradation may work for OP but not for most people.

Excellence comes from learning and inspiration. Inspiration comes from passion, excitement, and seeing the possibilities, not dwelling on crappiness.

Rule number 2: I care about my code.

Care about your code while you're writing it. Then let it go.

The moment you stop caring about your code is the moment you give yourself permission to be free of the bonds of what you already know. What worked worked. Now let's do better.

(I'm embarassed by what I wrote a year ago. But I don't care. Move on.)

Rule number 3: My opinion about my own code is wrong.

It better not be. Your code may not be perfect, but it better be ready to do the job now. And you better stand behind it.

Rule number 4: My manager doesn't care about my code, and he pays me.

Your code is all your manager does care about. When it performs, he loves you. When it doesn't, he doesn't.

Make your code do it's job. It's really that simple.

brecht• 17 years ago

Your comments reveal a person who's never worked in a sizable programming team for any length of time, be it at a large firm, a large collaborative project, or what-have-you. Which is fine; the article is not directed at the basement hacker, or the fad-du-jour startup slave, or whomever. It's toward the person who's been working long enough to prove themselves capable as a producer, and who's developed a (very common!) ego about their own abilities. Overcoming that ego can be a surprisingly difficult thing to do, if you're reasonably competent. But it's definitely a necessary step to "becoming a better software developer".

edw5192• 17 years ago

Your comments reveal a person who's never worked in a sizable programming team for any length of time, be it at a large firm, a large collaborative project, or what-have-you.

Funny, OP is 180 degrees from the truth and sadly, so are you.

OP's rules are nice (and cute) in theory, but it's my experience on large projects with many people in many environments that helps me see through OP's bullshit.

Hundreds of projects have shown me that the problem with most programmers is not ego, it's incompetence. I'd gladly take one primadonna over 10 drones into battle with me. In fact I have, and now it's the only way I'll take on major work any more.

Great work requires great competence, not pop psychology. If that competence comes with ego attached, fine, I can deal with that. What I won't deal with is crap produced by someone who cares about it but doesn't have the confidence or expertise to stand behind it.

bad_user• 17 years ago

I think you just scanned the article.

Rule 1: My code is crap ... this means exactly what you are saying ... there are always better ways to do it, and when a problem arises it's probably your fault more often than not.

Rule 2: I care about my code ... programmers definitely should care about their code, but should care even more about their current projects. There, happy?

Rule number 3: My opinion about my own code is wrong ... this happens more often than you think, and not realizing that your mental model might be wrong is dangerous.

Rule number 4: My manager doesn't care about my code, and he pays me ... this is the norm. You're arguing semantics here.

The manager cares about the project. You could argue that the manager indirectly cares about the quality of your code, and you would be right, but then again I haven't seen many managers getting upset about a project with lots of duct-tape code, as long as it does the job.

daleharvey• 17 years ago

1. if you think you code is good, you wont strive to improve if it defaults as crap and has to prove itself that its good, then you should end up with better code

2. I think your putting a different emphashis on "care"

3. same as 1.

4. no, your higherup only cares about the final product, thats very different from caring about the code, if a bunch of hacks gets the job done quicker than the elegantly carved solution, they dont care (unless your hacks part of the core and delay the next part)

iamaleksey• 17 years ago

1. Good is not perfect. Good code can still be improved, though, it doesn't have to be crap for that.

Poiesis• 17 years ago

All this disagreement! Look, both sides can probably agree:

Rule number 1: My code is crap.

The worst kind of incompetence is believing you're better than you actually are. Even the best make mistakes. Have an accurate idea of where the problem lies. Often, it is more likely that a bug is the result of your code than "a compiler bug" or some such thing. Every once in a while, you actually do run across that mythical "compiler bug", so you gotta keep your mind open. You don't solve bugs by restricting the search space before you prove the bug's not there.

Rule number 2: I care about my code.

I shouldn't have to write this--making something better is hardly arguable. Note that a shipping product is in fact the original killer feature; sometimes the best move is to stop development. But that doesn't mean you should stop finding and executing the best moves.

Rule number 3: My opinion about my own code is wrong.

This could have been written better. Your code is not right because you wrote it. It is very likely that there is an alternate approach. Sometimes, the alternate approach has enough advantages to recommend it over your approach. Sometimes it doesn't. Keep your mind open.

Rule number 4: My manager doesn't care about my code, and he pays me.

Again, a bit of hyperbole. Better said by bad_user: the manager cares about the project. That's his job.

The four golden rules to be a better software developer.

Related Stories