Hacker News Reader

Comment by serve_yay | Hacker News Reader

> The casualty of my being a slow programmer among fast programmers was a form of dysrhythmia – whereby my coding rhythm got aliased out of existence by the pummeling of other coders’ machine gun iterations. My programming style is defined by organic arcs of different sizes and timescales...

Boy oh boy. Look, I'm all for coding slow, taking time and understanding what you're doing. But there is something to be said for "playing well with others". We're all trying to make things, not be the backdrop for your exquisitely-crafted sense of craft.

To me that reads a lot like "I would have done something really good if I weren't surrounded by those philistines". Well, maybe so, but you are surrounded by them. So choosing a method of working that does not result in "dysrhythmia" or whatever strikes me as rather prudent.

View on HN

"Everyone around you is building this bridge in clay.... what are you doing fooling around with this 'steel' crap for?"

Of course you can spin it the other way too, which just goes to show this isn't a useful comment. Don't do what everybody else is doing just because they're doing it, do the right thing. If that does happen to be clay, great, but there's a great deal more people using inappropriately sloppy engineering than people using inappropriately careful engineering, so I'd expect to hear a lot more about the former.

The only people in real life that I've met that I would consider saying were being inappropriately careful were really just masking fundamental incompetence under a veneer of concern about process. I'm not sure I've ever seen anybody correctly apply massive overengineering to a programming task in real life. I'm absolutely sure it has happened, but it is not common enough to be worth talking about.

Don't do what everyone else does if you can do something better that leads to better results. The last part matters -- otherwise you're just crapping on everyone who can go faster than you and attributing the difference to "quality" (conveniently left nebulously defined).

Put another way, how do you know what you're working with is steel, and others clay? What if your "steel" is really just clay that is slower to produce and more brittle? How do you reassure yourself that this isn't the case? The answer is, make a big deal about going slower and drink tea and stroke your beard and say "hmmmm." and lots of other things that connote wisdom but do not actually bring it to bear.

I am extremely skeptical of all this, not because I am unsympathetic but rather the contrary. We can get extremely wrapped up in our signifiers of skill and wisdom, to the point that we mistake the map for the territory. Instead of cursing the punk kids, try to learn from them and beat them at their own game.

Thank you for repeating my own point back at me and making it sound like disagreement.

I find this sort of thing fascinating. I think it nicely showcases how perspective matters on this sort of thing. I almost feel like the whole fast/slow dichotomy is missing the point, since you can have two polar opposite views agree. What the point it... well, I guess that's why there's hundreds of replys in this thread.

If everyone in the business is using clay, you should either be using clay yourself, or you should convince everyone to use steel.

One of the things I have had to learn is how to code slowly in a fast code organization. This means understanding where I am going and doing lots of small iterations to get there.

One of the reasons for small iterations of a working system is that it gives you a limited QA footprint. This is far underrated. But it means that over the course of many iterations, my code ends up coming out, well designed and elegant, and playing well with others.

Short iterations and fast releases of a production web site, for example, are not the enemies of slow coding. In fact they have a role to play as well. What is the enemy is trying to do everything at once within a fast release cycle.

> But there is something to be said for "playing well with others". We're all trying to make things, not be the backdrop for your exquisitely-crafted sense of craft.

I had the same reaction here. Everybody wants good design. This article seems to walk the line between providing valuable insight and just complaining about how other people work.

The problem is clean code is only a net gain when it sticks around. So, some teams are toxic to clean code. Let's refactor to use library X, no wait, libarary Y. There is a conflict with foo unless you use bar version 0.37c. Or the classic: "Works on my machine."

I used to think it had to stick around for some time. In practice you start paying for bad code after about a month and you pay back many times over. If a bunch of people are throwing poor code in, the payback becomes exponential before you know it.

Most of my work at the moment is done for a client which had exactly this problem, and it nearly destroyed their business. I came in about two years into the cleanup and things were still a mess. With a lot of work all around (and some pushing by me to focus on code contracts more), things have continued to steadily improve.

But the problem you mention is real and it can sink businesses.

Reply on news.ycombinator.com