3 ms·

I am not a Ruby programmer, so this is the first I've heard of _why. I don't think it's fair to comment on the person based on one letter - although I will say

I am not a Ruby programmer, so this is the first I've heard of _why. I don't think it's fair to comment on the person based on one letter - although I will say the tone is reminiscent of some folk in my community who have their own demons. I can see that as advice to a new programmer, a call to experiment, play around, stretch skills, share small scripts etc is useful. Once you start building more meaningful, long term, things in a team context, then things like consistency, tests, comments and do on become a lot more important. I've been lucky enough to work with very bright people over the years. But for some of them, their code is hard to read, somewhat prone to bugs, and generally working with it is "disliked." It is slowly being replaced. I include some of my early code in this. Over the years personally I've tried to change from writing "clever" code to "clear" code. The latter seems less impressive but ultimately lasts longer. Wherever _why is, I wish him well.

deanCommie 4y ago
I think it's still good advice for programmers of all experiences. I have worked with too many programmers that know everything about engineering and process but can't actually DO THE WORK or solving problems, applying data structures, innovating their way out of a corner. They can go a long way with senior management because they speak all the right lingo. But when push comes to shove, and a new system needs to be built, or a bug needs to be solved quickly and safely in production without backwards incompatible changes, or business requirements collide against technology options...they are lost.
- bruce511 4y ago
  You are describing "bad" programmers, and clearly there are no shortage of those. But the advice in the post doesn't make bad programmers into good programmers - it just makes bad programmers "try to be clever" - which frankly doesn't end well. Do some of these techniques help bad programmers _become_ good programmers? Sometimes yes. But then it should come with the caveat never to do it in "real" code. It might be a good learning tool, but it's a terrible production tool.
  - tjrDL6MjB2Zwwa 4y ago
    They're describing former programmers who stopped when their role changed.

deanCommie 4y ago

I think it's still good advice for programmers of all experiences. I have worked with too many programmers that know everything about engineering and process but can't actually DO THE WORK or solving problems, applying data structures, innovating their way out of a corner. They can go a long way with senior management because they speak all the right lingo. But when push comes to shove, and a new system needs to be built, or a bug needs to be solved quickly and safely in production without backwards incompatible changes, or business requirements collide against technology options...they are lost.

bruce511 4y ago
You are describing "bad" programmers, and clearly there are no shortage of those. But the advice in the post doesn't make bad programmers into good programmers - it just makes bad programmers "try to be clever" - which frankly doesn't end well. Do some of these techniques help bad programmers _become_ good programmers? Sometimes yes. But then it should come with the caveat never to do it in "real" code. It might be a good learning tool, but it's a terrible production tool.
- tjrDL6MjB2Zwwa 4y ago
  They're describing former programmers who stopped when their role changed.