| > - 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: http://johannesbrodwall.com/2013/09/25/offensive-programming... > - be nice and never argumentative 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 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. > - 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 :) |