

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

======
edw519
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.

~~~
daleharvey
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
1\. Good is not perfect. Good code can still be improved, though, it doesn't
have to be crap for that.

------
Poiesis
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_.

