You can certainly acquire the skills to become a great manager, but it takes effort, and you'll feel miserable if that's not what you want to do with your career. Worse: the experience of folks who report to you will be a mess.
If you're not sure what entails to be a manager, a good introduction is "Radical Candor", by Kim Scott . Another one is is "Resilient Management", by Lara Hogan . Lara was a senior engineering leader at Kickstarter and Etsy, so her examples are a bit more focused on tech people managers.
Kim Scott wrote extensively about this in her book "Radical Candor" . Do yourself a favor and skip the video snippets and TED talks, and go straight to the book (so you don't get caught up on the click-baity "radical candor quadrant"). This is particularly true if you manage teams - or ever aspire to.
The author is a former Googler and used to report to Sheryl Sandberg during the early days, before going to Apple and working with Jobs and Tim Cook, and more recently with Dick Costolo on Twitter.
This is one of those books I wish I had read when I started my career. It would have saved me from so much pain and mistakes learned the hard way.
Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity, by Kim Scott
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:
> - 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 :)
Fresh book recommendations delivered straight to your inbox every Thursday.