3 ms·

Good code all looks the same. Modular, name what you meant, clear boundary, relevant stuff got grouped nearer. Bad code is each bad in its own way. There are j

by a_c 5y ago

Good code all looks the same. Modular, name what you meant, clear boundary, relevant stuff got grouped nearer. Bad code is each bad in its own way. There are just infinite combination of bad. Good luck on that. It is like telling kids what not to do. They still won't behave. It is like bring people with an "unfit culture" to your team. You might be able to work with them, you might be able to change them. But you also only got so much time

pm90 5y ago
> You might be able to work with them, you might be able to change them. But you also only got so much time Recognizing this tradeoff explicitly might go a long way in improving how we approach the issue of training engineers. On a certain level, anyone motivated to do so can learn software engineering. But the amount of mentorship required differs significantly. And personally I'm not against doing that, but when organizations don't allocate time for intensive pairing/mentorship but expect senior engineers to somehow find time for it is what doesn't really work.
- a_c 5y ago
  > but when organizations don't allocate time for intensive pairing/mentorship but expect senior engineers to somehow find time for it is what doesn't really work. All organization has their own flavor of culture. Visionary vs mercenary, waterfall vs collaborative, explicit vs implicit. One can design/shape their organization to favor explicit knowledge sharing. I agree with you that it is a trade off. Just that all else being equal, I think writing good code offer way more leverage than getting better in reading code, knowing that they are not mutually exclusive
tessierashpool 5y ago
I enjoy a good literary reference as much as the next person, but this just isn't true. It isn't even true for closely related languages. Good Clojure doesn't look anything like good Common Lisp. Good Elm looks nothing like good TypeScript. Good Python doesn't even look like good Ruby.

by a_c 5y ago

pm90 5y ago

> You might be able to work with them, you might be able to change them. But you also only got so much time Recognizing this tradeoff explicitly might go a long way in improving how we approach the issue of training engineers. On a certain level, anyone motivated to do so can learn software engineering. But the amount of mentorship required differs significantly. And personally I'm not against doing that, but when organizations don't allocate time for intensive pairing/mentorship but expect senior engineers to somehow find time for it is what doesn't really work.

a_c 5y ago
> but when organizations don't allocate time for intensive pairing/mentorship but expect senior engineers to somehow find time for it is what doesn't really work. All organization has their own flavor of culture. Visionary vs mercenary, waterfall vs collaborative, explicit vs implicit. One can design/shape their organization to favor explicit knowledge sharing. I agree with you that it is a trade off. Just that all else being equal, I think writing good code offer way more leverage than getting better in reading code, knowing that they are not mutually exclusive

tessierashpool 5y ago

I enjoy a good literary reference as much as the next person, but this just isn't true. It isn't even true for closely related languages. Good Clojure doesn't look anything like good Common Lisp. Good Elm looks nothing like good TypeScript. Good Python doesn't even look like good Ruby.