Live data from Hacker News

Torvalds' quote about good programmers

programmers.stackexchange.com

11–20 of 108 posts

Re: Torvalds' quote about good programmers

#11
Next week on Hacker News: Bad Programmers worry about their code. Good programmers ship.

"Bad programmers [technique A on programming KPI metric N1]. Good programmers [technique B on programming KPI metric N1]."

Responses: Someone will ask, "What about metric N2?" And someone will say, "What about technique C?" Someone will post a personal anecdote showing that people really underestimate the value of A. Someone will respond to that by posting a hyperlink to an anecdote that shows technique B really is what matters.

Re: Torvalds' quote about good programmers

#12
You can normally fix bad code - fixing bad data structures is not usually easy or even possible.

It's why I've still not fully bought in to 'release early release often'.

I prefer to defer releasing for production use until really satisfied with the structures - this way you have no barrier to ripping the foundations up.

If not 100% comfortable with the model - prototype a bare metal improved one (schemaless DBs ftw) - if it feels better start pasting what logic/tests you can salvage from the earlier version and move on.

Re: Torvalds' quote about good programmers

#13
post #12

You can normally fix bad code - fixing bad data structures is not usually easy or even possible. It's why I've still not fully bought in to 'release early release often'. I prefer to defer releasing for production use until really satisfied with the structures - this way you have no barrier to ripping the foundations up. If not 100% comfortable with the model - prototype a bare metal improved one (schemaless DBs ftw)…

I'm in the position of maintaining a legacy codebase. I feel like I've shown up half-way through a game of Jenga and management still wants me to play the game with the same speed as the guy who played the 1st half.

Meanwhile, he's been promoted to start work on a brand-new Jenga tower since he's demonstrated such remarkable success in the past.

I just want everyone to stop playing Jenga.

Re: Torvalds' quote about good programmers

#14
post #12

You can normally fix bad code - fixing bad data structures is not usually easy or even possible. It's why I've still not fully bought in to 'release early release often'. I prefer to defer releasing for production use until really satisfied with the structures - this way you have no barrier to ripping the foundations up. If not 100% comfortable with the model - prototype a bare metal improved one (schemaless DBs ftw)…

release early release option gives you chances to fix your mistakes before its too late. waterfall works great if you can manage to get your data structures perfect before production. it begins to fail when it becomes prohibitively expensive to fix mistakes after production, where not unexpectedly breaking old code has precedence over deploying new.

Re: Torvalds' quote about good programmers

#15
My only problem with this quote is it equates "new" programmers with "bad" programmers. Yes if you still have these problems after 10 years of professional work, then you're a bad programmer, but if you show these symptoms after 6 months it just means you're still learning. There's got to be a better way of stating this.

Re: Torvalds' quote about good programmers

#16

My only problem with this quote is it equates "new" programmers with "bad" programmers. Yes if you still have these problems after 10 years of professional work, then you're a bad programmer, but if you show these symptoms after 6 months it just means you're still learning. There's got to be a better way of stating this.

A new programmer is a bad programmer. There's no shame in that. In fact it's better for a new programmer to realise that; the worst programmers are those that don't even realise they are bad.

A new programmer may still be learning, but that doesn't mean they aren't bad. It just means they are bad now, and hopefully won't be bad later.

Re: Torvalds' quote about good programmers

#17
This is approximately the same reason as why I start out writing most of my programs by creating a bunch of types, and why I find dynamic programming languages uncomfortable to use.

I'm less and less a fan of the ceremony of object orientation, but I think there's a lot to be said for having a succinct formalized statement of your data structures up front. Once you understand the data structures, the code is usually easy to follow. The hardest times I've had comprehending code in my career, apart from disassembly, have been from undocumented C unions.

Re: Torvalds' quote about good programmers

#18
post #12

You can normally fix bad code - fixing bad data structures is not usually easy or even possible. It's why I've still not fully bought in to 'release early release often'. I prefer to defer releasing for production use until really satisfied with the structures - this way you have no barrier to ripping the foundations up. If not 100% comfortable with the model - prototype a bare metal improved one (schemaless DBs ftw)…

release early release option gives you chances to fix your mistakes before its too late. waterfall works great if you can manage to get your data structures perfect before production. it begins to fail when it becomes prohibitively expensive to fix mistakes after production, where not unexpectedly breaking old code has precedence over deploying new.

There's other options than "release early release often" and "waterfall".

Re: Torvalds' quote about good programmers

#19
it has a lot in common with one of the famous quotes by Alan Perlis - "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures". Good data structure ensures that the code would be comprehensible to people who have to maintain it.

Re: Torvalds' quote about good programmers

#20

Earlier quoted context omitted.

release early release option gives you chances to fix your mistakes before its too late. waterfall works great if you can manage to get your data structures perfect before production. it begins to fail when it becomes prohibitively expensive to fix mistakes after production, where not unexpectedly breaking old code has precedence over deploying new.

There's other options than "release early release often" and "waterfall".

What might those be? Honest question. My inexperience is probably showing, but I have a hard time picturing what the middle ground might look like.
Post reply on HN