

No matter how much "karate" you know, someone else will always know more. - macco
http://www.codinghorror.com/blog/2006/05/the-ten-commandments-of-egoless-programming.html

======
marcusf
> Don't rewrite code without consultation.

This is linked to a pet peeve of mine, especially with restless, young
developers. There's a significant difference between the two statements "I
don't get this code, it's crap, let's rewrite it." and "I understand this
code, it's crap, let's rewrite it". I don't know how many times I've seen
someone go down the path of seing battle-tested code, not understanding it,
thinking they can rewrite it better only to spend a month falling in to all
the same pitfalls that lead to the original code. The middle road is of course
refactoring. Cleaning up the code in small, discrete steps to something you
can understand and work with is many times better than just tearing stuff out
and restarting.

~~~
romaniv
_There's a significant difference between the two statements "I don't get this
code, it's crap, let's rewrite it." and "I understand this code, it's crap,
let's rewrite it"._

There are cases when the code is a convoluted, buggy, unintelligible,
undocumented, untested and untestable mess. In those cases re-analyzing what
it _should_ do and re-implementing it from scratch is often both faster and
more reliable way of dealing with required changes. Especially if you consider
resources spent on maintenance over a significant period of time.

At this point, I get the nasty feeling that many people who preach "don't ever
rewrite" mantra are the people who have produced large volumes of code in the
past, but consider themselves too "senior" to maintain it now. The common
rhetoric regarding "young/junior programmers" only confirms that notion.

~~~
tedunangst
Analyzing what the code _should_ do is insufficient. You must also know what
it _does_ do. Somewhere, someone is depending on that and they will be angry
when your rewrite, perfectly spec conforming though it may be, doesn't work
the way it used to work.

~~~
romaniv
Any change to a badly written application can break some obscure functionality
or integration. I repeat, _any_ change. Assuming that you're still working on
the codebase in question (and why else someone would care to rewrite it?)
there is a constant threat of breaking changes. Heck, with certain types of
code regular issues after updates are nearly inevitable.

If you rewrite something, you will at least have understanding of how things
work _right now_ , which allows you to quickly and reliably deal with
surfacing compatibility issues. On the other hand, updating legacy code to
deal with those issue is a) much slower b) likely to introduce other issues.

And no, you cannot always slowly refactor old code. That is, in many cases it
will take several orders of magnitude more time that a complete rewrite with
new features plus all the rewrite issue mitigation.

Been there, seen that. Many times. So far I haven't regretted a single rewrite
I've done in my professional life. If your experience is different, than
maybe, just maybe, you should look at how you approach rewrites, rather than
dismissing the whole concept as "wrong".

~~~
tedunangst
Geeze, I offer a little advice to anyone considering a rewrite and now I'm a
professional failure.

------
alexkearns
I hate this list. It should really be called the Ten Commandments of Good
Little Worker Programmers. The 'commandments' are all about creating nice
friendly programmer cogs that work smoothly together, minimising hassle for
their employers.

There's nothing there about programming as an art. There is nothing there
about pushing the boundaries of what is possible through determination, vision
and, yes, ego. There is nothing about solving complex technical problems
through sheer force of will.

To hell with 'egolessness'. Why shouldn't programmers have an ego. And,
indeed, doesn't it take an ego to do anything great, to think that
preposterous thought that you can do something no-one has done before.

~~~
memset
For the vast majority of us, technology is one component of the business. The
rest of the business is about figuring out how to lower shipping costs so that
we make more money per item shipped. Or how to deliver food more efficiently.
Or accounts receivable software.

And none of those problems are, well, are particularly hard or complex, at
least not enough in my mind to justify ego as you've portrayed it.

There are plenty of professions where people work just as hard (harder, even,
including people in the knowledge-working industry) and do not complain nearly
as much as developers.

There is a lawyer in our office who works very hard to ensure that we are
selling wine in a compliant way across multiple states with different
regulations. That person's job is at least as difficult, if not more, than my
job writing python. But you'll never hear them complaining because we only
have apple juice, rather than orange juice, in the vending machine.

~~~
alexkearns
You are kind of making my point for me. This is a list drawn up from the
perspective of a business owner who obviously would prefer all his employees
to be egoless automatons who work smoothly together in the most cost-effective
and efficient manner. Yes, from the business perspective (or the project
management perspective or the agile coach perspective or the countless other
professions that have infiltrated software development), this list is
absolutely great. Couldn't be better. Five-star perfection.

However, from the programmer's point of view - and that is the view I was
arguing from - the list is pretty detestable, at least in my view. People get
into programming usually because they want to make things, because they want
to be creative. But - in the vast majority of cases - they end up working on
legacy projects that require absolutely no creativity, where, indeed,
creativity is frowned upon - see Commandment 4. You are saying they should
shut-up and deal with it. I am saying, fuck that, they can complain as much as
they like.

Having said that, even better than complaining would be for the programmer to
ditch the job and start creating their own software, under their own terms.
But, of course, you would need a bit of an ego to have the guts to do that.

~~~
memset
Haha, I am all for people squeezing out from under The Man and creating their
own software.

I read Commandment 4 ("Don't rewrite code without consultation") differently.
My opinion is that if you are working on a team with developers, you have to
be judicious about making big changes.

It is possible (likely!) that some of that code was written because of some
weird Python behavior or to handle an edge case from a buggy external API or
some odd behavior from another internal system.

I do advocate "if you want a change, write some code and make the change." But
a wikipedia-style edit war between programmers' egos is also not productive.

In the context of a business, "creativity" can and should mean "creative ideas
that have the potential make more money." It is unfair to ask someone to pay
you a salary for unbridled side-project creativity; that is what your
disposable income is for!

Even when you are running your own business, well, it isn't a business unless
you ask the question "how can I create software that my customers will pay
for?" rather than "what shall I make which sates my creativity?"

I'd suggest, then, that this list is relevant for anyone trying to make money,
because that always entails working with some other person (fellow programmer,
business partner, customer) and that can only happen when you have a
harmonious relationship with - and are willing to bend a little - for these
people.

~~~
CodeMage
_It is possible (likely!) that some of that code was written because of some
weird Python behavior or to handle an edge case from a buggy external API or
some odd behavior from another internal system._

If that code is in there without at least a comment mentioning that, then you
have bigger problems than handling people's egos. This kind of thing is
precisely what comments are for.

 _I do advocate "if you want a change, write some code and make the change."
But a wikipedia-style edit war between programmers' egos is also not
productive._

False dichotomy.

 _In the context of a business, "creativity" can and should mean "creative
ideas that have the potential make more money." It is unfair to ask someone to
pay you a salary for unbridled side-project creativity; that is what your
disposable income is for!_

Tell that to people who came up with 15% "innovation time" at 3M and 20% at
Google. Of course, Google's 20% got subverted as far as I've heard, but that's
a completely different topic.

The point is that creativity should be exercised at the right time, in the
right place and in a right degree.

 _I'd suggest, then, that this list is relevant for anyone trying to make
money, because that always entails working with some other person (fellow
programmer, business partner, customer) and that can only happen when you have
a harmonious relationship with - and are willing to bend a little - for these
people._

This has nothing to do with making money. It has to do with your project being
successful or not. It has to do with people on your team being reasonable most
of the time and having a good manager (or something equivalent) the rest of
the time.

Having said all that, "Don't rewrite code without consultation" should be a
no-brainer. Not necessarily for Jeff's reason, but because if it's someone
else's code, chances are that there might be something you don't understand
about it; on the other hand, if it's your code, there might be someone using
it and your rewrite could break it for them. Checking this stuff is usually a
good idea.

~~~
wpietri
> If that code is in there without at least a comment mentioning that, then
> you have bigger problems than handling people's egos. This kind of thing is
> precisely what comments are for.

Comments are a poor substitute for collaboration.

> Tell that to people who came up with 15% "innovation time" at 3M and 20% at
> Google.

As far as I'm told, 20% projects always had to be approved by your manager. So
I suspect that they are not quite as open as you are thinking.

~~~
CodeMage
_Comments are a poor substitute for collaboration._

Of course they are, seeing as how they're only one form of collaboration. I
wouldn't think that writing a comment to draw people's attention to some non-
obvious aspect of code would count as anything but a form of collaboration.

 _As far as I'm told, 20% projects always had to be approved by your manager.
So I suspect that they are not quite as open as you are thinking._

Which is why I did say, in continuation, that the 20% has been subverted at
Google. From what I've heard, it hasn't _always_ been that way.

------
barefoot
> The only true authority stems from knowledge, not from position.

That's certainly not the full story. In many organizations, having a lot of
knowledge about something that someone else is supposed to know more about is
a good way to make them feel uncomfortable or in extreme cases dislike you.

From a practical vantage, knowing how to apply what knowledge you do have (and
having the will to follow through) is a lot more valuable.

It doesn't help to have a broad and deep understanding of software development
and business but be socially awkward and suffer from severe akrasia.

~~~
bdunbar
_In many organizations, having a lot of knowledge about something that someone
else is supposed to know more about is a good way to make them feel
uncomfortable or in extreme cases dislike you._

This. I worked for one org (USMC) where I was a young(er) worker, with more
knowledge about our job (micro-computers, LANs) than most of my superiors. And
this was okay. Encouraged, even. My lieutenant's job was to lead a team, not
be a know-it-all.

Then I stepped into the civilian world and found a majority of managers were
freaked out when their juniors knew more than they did.

~~~
iron_ball
On the other hand, in the armed forces, rank commands respect (or at least all
outward forms). In the civilian world, those with rank may be more insecure.

~~~
bdunbar
I think it's more about culture, not respect for rank.

A guy is supposed to learn at least the basics of the next higher-up job,
sometimes two. Team leaders are supposed to reach down two levels, ensure
juniors are properly schooled to step up.

Obviously this is so if one's leader is zapped, juniors can step up and carry
out the mission.

But this works out well in nominal peace-time and non-combat jobs, too. And
the better trained and schooled one's juniors are, the better the unit can
carry out the mission.

Example: one week into a three-week field exercise I was given 20 minutes to
pack and report to a new, temporary, job, far away from my parent unit.

We could do this because everyone under me (all of three guys, but still) knew
what I did and could do the job. The only problem it caused was that they
suddenly had one fewer person to stand watch in the server CONEX.

------
memset
It is interesting that all of us are getting a different takeaway from this
list; something different resonates with different people.

It also surprises me that these lessons originated in 1971 (though I had not
heard of this text until just now.)

Back then, IBM was hiring English majors and training them in assembly to work
on OS/360 etc. It would not have occurred to me that developers back then
would have cultivated a stereotype of a "prima donna."

Because to me, and perhaps this is a reflection of my age, it has only been
recently that the popularity of joelonsoftware-esque "pamper your developers!"
has led to a culture in small companies where we demand free beer and 36" Macs
as a condition for employment.

Or has it always been that way for developers (of young tech companies; none
of this really applies if you work at Fidelity Investments) modulo the
greatest tech of the day?

~~~
robfig
I think this is just supply-demand of the current labor market. There are
enough lawyers to go around, but not even close to enough good developers. I
think it will continue to be that way for a long time

~~~
memset
Interestingly, you have compared apples and oranges: "lawyers" and "good
developers" (as opposed to "good lawyers".)

What I mean to say is - and, of course, this is all unsubstantiated - there
are plenty of coders and lawyers to go around, but fewer good lawyers (with
relevant experience in a field of business, for me it is the wine biz) and
good developers (can you follow the instructions on our code test?)

Possibly good lawyers simply get paid more than good developers, and so that -
combined with a different culture between the two professions - engenders a
different sense of professionalism.

What is the essential quality about dev which causes our culture to be
different than other professionals (lawyers?)

~~~
arethuza
Well, as someone married to a lawyer I one thing that is completely different
is that they have to worry about their professional license - if they screw up
badly enough then it can be taken away and then they can't work as a lawyer
anymore.

There is no sanction that can be applied to a developer that will mean that
they can never get employed as a developer again.

------
Akram
* Be kind to the coder, not to the code. ^ * Treat people who know less than you with respect, deference, and patience. - My friend/cofounder has been inspired by the codeyear thing and have been bringing to me a lot of silly code issues... guess i was being a bit rude with him lately.

~~~
defrost
I'm frequently in a room with people that know less about mathematics and
programming than I do (and let's be clear, I don't regard myself as
exceptionally talented in either field). It's not surprising, that's usually
the reason I've been asked in to consult.

The great joy is discovering what these people know more about than I do:
electronics, cartography, avionics, wet film processing, fire fighting, violin
making, linguistics, ... it's always a surprise finding out just how much some
people know about their particular interest and how well they can make you
appreciate it.

I'm get a little tired of hearing "the IT Crowd" cackle on about how stupid
their users are, maybe that is true for them but it is possible to go out and
find end users that stretch and challenge you as a programmer to meet their
needs.

~~~
Akram
being the only tech guy in the room sometime sucks. But you are right.. there
is more to just math and programing.. You are right^

~~~
hessenwolf
Meh. I've done the rounds as a statistician, and it would be pretty unusual to
meet somebody who knew as much as me about what I do - in fact, even if I meet
another statistician, there is almost surely no chance they know everything I
know. I am always the expert, at what I do. And then I have to try really hard
to get any idea of what everybody else is doing.

~~~
davidw
> it would be pretty unusual to meet somebody who knew as much as me about
> what I do

What do you think the odds are?

------
seclorum
The corollary: All human knowledge can be known.

------
leon_
Sad times when Atwood is giving coding advice ...

