3 ms·

Programming in a team and accepting that it is not 'my' code but 'our' code. Not feeling slightly pissed when someone else changes the (not my) code. For me,

Programming in a team and accepting that it is not 'my' code but 'our' code. Not feeling slightly pissed when someone else changes the (not my) code. For me, this was a total game changer and a complete change in programming style. The focus changed to using the most common idioms, the clearest and cleanest and most concise way of writing stuff down, and avoiding smart hacks or, if necessary, encapsulating and documenting smart hacks. Not being shy of writing stuff multiple times until it really is clean and inviting to be read and understood. Using a very strict style (including when/where to put white space and line breaks) that everyone else also uses so that code is easy to read for everyone. It improved my programming enormously and the bugs/line ratio went down. It also gave a much better intuition to smell fishy code. It also took quite a while to internalise, but I now always code like that, also in private projects and in quick hacks scripts in, say, Perl. My second most important change was to learn how to use contract based programming, or, if the language has poor support, at least to use a ton of asserts. This, for me, feels like stabilising the code very quickly and, again, improved my bug/line ratio. It forces me to encode what I expect and the code will relentlessly and instantly tell me when my assumptions are wrong so I can go back and fix that before continuing to base the next steps on broken assumptions.

woutr_be 7y ago
I agree with the first bit; however it's hard to find a balance between accepting that your code can be improved, and standing by your solution. What I see in my team is that someone else has another solution, and whatever that is, should be implemented, if you argue against it, then it's often "I'm just trying to improve your code". However his solution might not necessary be better, it's just a different approach. We also follow very strict style guides, but this is all defined in formatters and linters, so there's no arguing against it. Even for my personal projects, the first thing I do is usually set up .editorconfig and TSLint (if I use Typescript).

woutr_be 7y ago

I agree with the first bit; however it's hard to find a balance between accepting that your code can be improved, and standing by your solution. What I see in my team is that someone else has another solution, and whatever that is, should be implemented, if you argue against it, then it's often "I'm just trying to improve your code". However his solution might not necessary be better, it's just a different approach. We also follow very strict style guides, but this is all defined in formatters and linters, so there's no arguing against it. Even for my personal projects, the first thing I do is usually set up .editorconfig and TSLint (if I use Typescript).