- beware of premature optimization. Spend that time on defensive code, comments and tests. Optimize based on measurements, not feelings
In some contexts - rapid development and prototyping especially - defensive coding is not much different than premature optimisation. I fired a developer once, because he couldn't let go of his defensiveness whereas what the project needed was a buggy, proof of concept, version.
Also, offensive programming is a thing, and possibly less bug-prone in some situations:
This too depends on context and a team. Personally, I prefer argumentative people (within reason) to nice ones - the last thing I want is for a developer to do something he believes is stupid, and not tell me about it.
Having said that, being too argumentative is not good either - some devs seem to build their self esteem based on the number of arguments they won. No no no.
- take notes when getting tasks and make sure you don’t miss anything
This is super-true. Also - read a tutorial on active listening. I had a team of developers once who literally made zero notes from the meetings.
- be humble when getting criticism and be merciful when giving one
As for being humble when getting feedback - I'd add "don't afraid to ask as many questions as needed for understanding". There is a difference between being humble, and non-confrontational. The former acknowledges they may be wrong, the latter hides the fact that they think they are right.
- count to ten before sending an angry / escalation email
Or just call instead.
- don’t work yourself to death, have limits
But acknowledge that crunching - within reason - can be fun :)
Without more context, this seems very extreme: In some contexts - rapid development and prototyping especially - defensive coding is not much different than premature optimisation. I fired a developer once, because he couldn't let go of his defensiveness whereas what the project needed was a buggy, proof of concept, version.
Comments
In some contexts - rapid development and prototyping especially - defensive coding is not much different than premature optimisation. I fired a developer once, because he couldn't let go of his defensiveness whereas what the project needed was a buggy, proof of concept, version.
Also, offensive programming is a thing, and possibly less bug-prone in some situations:
http://johannesbrodwall.com/2013/09/25/offensive-programming...
This too depends on context and a team. Personally, I prefer argumentative people (within reason) to nice ones - the last thing I want is for a developer to do something he believes is stupid, and not tell me about it.
Having said that, being too argumentative is not good either - some devs seem to build their self esteem based on the number of arguments they won. No no no.
This is super-true. Also - read a tutorial on active listening. I had a team of developers once who literally made zero notes from the meetings.
Just not too merciful :) A good book on managing people, including giving feedback: https://www.amazon.com/Radical-Candor-Kim-Scott/dp/B01KTIEFE...
As for being humble when getting feedback - I'd add "don't afraid to ask as many questions as needed for understanding". There is a difference between being humble, and non-confrontational. The former acknowledges they may be wrong, the latter hides the fact that they think they are right.
Or just call instead.
But acknowledge that crunching - within reason - can be fun :)
Without more context, this seems very extreme: In some contexts - rapid development and prototyping especially - defensive coding is not much different than premature optimisation. I fired a developer once, because he couldn't let go of his defensiveness whereas what the project needed was a buggy, proof of concept, version.