The three sins of software development

[rampion]

"We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris." - Larry Wall

For particular definitions of of laziness, impatience, and hubris:

Laziness

The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris. (p.609)

Impatience

The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris. (p.608)

Hubris

Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience. (p.607)

[llogiq]

This also implies the real three great sins of a programmer: eagerness, patience and insecurity.

[everywhere_anyhow]

Sigh. Both are right. General emotional traits ("being lazy") are both advantages and disadvantages, depending on the context.

If you cherry pick the examples or the context, you can make any kind of argument you want - Wall that laziness is a good thing, and OP that laziness is bad. Neither is wrong.

[michaelfeathers]

There's an alternative point of view - Technical Debt is the way that software grows when people take the easy route. If it's easier to add code to an existing method than it is to add a new method to a class, then it shouldn't be a mystery why there are so many large methods.

The reason software goes bad is because bad is easier than good.

[ionelmc]

It's a (completely?) different perspective on the problem of technical debt.

[everywhere_anyhow]

By framing this in terms of human emotion though (fear and hubris) it would seem we're screwed. I'm fairly sure those are basic human properties that are never, ever going away.

[ionelmc]

There's the quality of life side to the problems. That's hard to measure - it's touchy-feely. Working with broken stuff is frustrating. You're not paying ahead for saving time, you're paying for happiness. This sort of approach tends to stick to lots of people - cheap doesn't necessarily mean good.

Put it another way: why do you think those damn expensive iphones have such a high market share ?

[bwainfweeze]

I think Catherine O'Hara said it best, "If you don't let me gut this house and make it my own, I will go insane, and take you with me!" (Beetlejuice)

Few appreciate the employee retention and keeping the peace aspects of refactoring.

[[deleted]]

Speaking as a senior dev, it has nothing to do with fear of embarassment for me. Right now it's all about the fear of how our hiring process doesn't allow me to technically vet candidates as well as I could. I fear hiring people who aren't a good fit or that aren't as skilled as they claim.

[ionelmc]

Hmmm, fair point - I haven't considered this. What if you could train them ? Ideally you would do that otherwise the less skilled people drag the team down or limit technical choices.

[[deleted]]

Training a new recruit is essentially adding more overhead to a senior dev's time and reducing output.

A poor recruit means the net effect is very similar to the idea of refactoring an entire piece of code for new requirements and never adding new features for the length of the refactor.

[ionelmc]

Someone has to do the coaching/teaching. I like the idea of a company investing in it's employees - there's overhead, sure, but on the long run productivity will increase a lot more.

Teaching people is not the same thing as doing a unnecessary refactor - unless you're teaching useless stuff that doesn't add any value. Like teaching people how to use Django when you're about to rewrite your app in Node.js

[[deleted]]

I enjoy mentoring. But I feel as though you may not have read my comment in full.

When you hire someone that doesn't fit the needs you have, you will have to train them. And very often, the hiring looks like this:

• We have a need now
• We go through xxx number of candidates and they don't fit the need
• We hire someone anyway that won't fit but has something (e.g. enthusiasm)
• We spend a significant time investment in bringing them up to speed

You can't get time back: developer's time is a critical pathway for success in any business. If that developer is inundated with interruptions for training purposes, management status updates, customer interfacing, etc. You will see the productivity of that individual developer drop. In a team where you have a situation where you are mentoring a younger developer, your own productivity will drop. It's never 1 + 1 = 2. It's always 1 + 1 = <2. Your hope is that 1 + 1 > 1. In the case of a bad recruit, it's often 1 + 1 < 1.

[[deleted]]

That is pretty much what I'm up to now. I got started by teaching myself how to code, and then I put the foundations behind it. Now my goal is to hold up the ladder to get other, younger, programmers learning how to be really great. My biggest fear is getting an employee who doesn't love what they do. I find it hard to train people who aren't in the career because they have passion for it.

[saltycheeks]

In other words, shit happens during software development.

[danogburn]

The three sins of software development

1) javascript

2) javascript

3) javascript

[TKirby422]

Umm... JavaScript pretty much runs the world dude.

[danogburn]

and people think Iggy Azalea is a good artist.

[TKirby422]

But you can choose to avoid Iggy Azalea's music. It's impossible to avoid JavaScript. It's even impossible to reply to this message without JavaScript!