Thursday Links is a new format for me to systematise what I learned for a week. I have only one rule: content should be “technology agnostic” to be useful for more people, not just me.

Good: architecture patterns, UX tips, soft skills, programming paradigms.
Good, but not for Thursday Links: Amazon Lambda, Python, themes for Gatsby

Kim Scott: How to be kick-ass boss

https://www.youtube.com/watch?v=f-Tcr0T9Tyw

This is one of the best videos I've watched about soft skills and work in the team. If you not a boss and don't want to become one – no problem, this is just a catchy title. I highly recommend this video to anyone. To talk about the title, I don't know what kind of boss she is, but she is definitely a kick-ass presenter.

Kim Scott explains the concept of "Radical Candor" – a person who cares about people but, at the same time, isn't afraid to give them honest and direct feedback. Along with examples of "Radical Candor" she describes 3 other categories, I'll just put here a picture from her site:

The Anti-Mentor: How a bad boss influences our leadership style

https://knowyourteam.com/blog/2019/02/13/the-anti-mentor-how-a-bad-boss-influences-our-leadership-style/

Claire Lew brings the opinion that bad bosses may impact you even more than good ones.
Usually, this influence is rather good – you see an example that leads to negative consequences, and learn how you should not behave

When I reflect on my own leadership style, I realize that the bad bosses I’ve had influenced me more than any good boss I’ve had. Seeing what you don’t want to be like is more powerful than what you do want to be. The push is greater than the pull.

But sometimes it leads to overcompensation:

Most commonly, I talk to many leaders who have a problem being too nice because of their “anti-mentor.” Their former boss was as asshole and they are scarred by that experience. But inadvertently, now as a leader themselves, they lean the other way too far. They can’t bring up hard conversations with their staff. They have difficulty firing people who needed to have been let go months ago.

The care and feeding of software engineers (or, why engineers are grumpy)

https://humanwhocodes.com/blog/2012/06/12/the-care-and-feeding-of-software-engineers-or-why-engineers-are-grumpy/

This is a perfect article that I recommend to anyone who works with engineers (even engineers who work with others). I'm a big fan of Nicholas C. Zakas, so it's quite a shame that I didn't read it earlier.

I usually put some notes here, but I took too many notes for that article, so it's better to read the original. It perfectly explains why we, engineers, behave as we do.

Ok, just a few quotes, only because it's brilliant:

Software engineers generally have a reputation for being arrogant, disagreeable, and moody. We also have a reputation for saying “no”, for debating pedantic details, and thinking we know how to do everyone’s job better than they can.

In the triumvirate of software, product managers, designers, and software engineers, only the engineers are expected to turn off their creative minds and just produce. <...> The engineers want to be part of that creative process and are denied. Thus you end up with the typical software engineer personality accented by grumpiness.

Here are the common reasons why engineers say no (or otherwise seem grumpy):
 1. The request is coming late during development and there’s not enough time to fit in before the deadline.
 2. The request invalidates one or more assumptions that were made early on in the process to get the project moving.
 3. The request is a reversal of previous requirements.
 4. The request otherwise increases the amount of work that has to get done before the deadline
 5.We are so burned out that any request seems like a ton of extra work and we just don’t want to deal with it.