Hacker News Reader

There is an assumption here--one that Bryan Cantrill mentions in that toxin vs cancer talk--that management and leadership are the same.

In my experience, they have nothing to do with one another. This is especially true with technical leadership. Having people whose primary concern is organizational stability leading technical decisions is a recipe for resentment and dysfunction.

I would go even further and say if a person is concerned with making technical leadership decisions as opposed to people management decisions, they shouldn't be in "management". This includes being a CTO. Most CTOs are not as natural people managers as their VP Eng brethren, and CTOs are not best described as managers of other managers: they're entirely different roles.

This is a very good point! I'm trying become a better leader and reading this list was actually not motivating. I felt I had to be perfect all the time. I thought if I was this good I would start my own company instead of being a corporate cog.

In your first paragraph you’re asking for more respect:

> Software Engineering Middle Management is a toxin or a cancer.

In your second it seems that you don’t respect those lower on the ladder:

> Programmers are like cats and their opinions are more important and refined than anyone else's.

As a leader it’s important to distill good ideas from bad and be able to bring those lower on the ladder along. Give them the respect they deserve and you’ll get it in return.

>> Programmers are like cats and their opinions are more important and refined than anyone else's. And I don't think it's sustainable to work in an environment where your every mistake or bad day will make you seem like a dipshit to your team.

> In your second it seems that you don’t respect those lower on the ladder:

That's a good point. I didn't intend any disrespect. Speaking as a programmer I was making a self-deprecating generalization. Not everyone has had the same experience as I have and I can see how that has weakened my comment.

I think I could have made my writing stronger if I had avoided the generalization and went straight to the point instead.

Thanks for pointing that out.

> As a leader it’s important to distill good ideas from bad

In a way I believe you're right.

> be able to bring those lower on the ladder along

However I don't think it's our job to deem which ideas are good. If we believe the source of goodness stems from our own personal experience and opinions then we may favor a team that merely agrees with us.

A good leader, in my opinion, must embody some of the qualities in TFA to make those determinations: being focused on the customer, the business, and their team. They need to look to the current context of all of these things and find the good ideas. They often come from unexpected places.

> Give them the respect they deserve and you’ll get it in return.

I believe this is a universal truth: give people respect, ownership, and accountability. It's important!

> their opinions are more important and refined than anyone else's

I inferred that they do respect the programmers - more than anyone else even.

That's a really interesting final point that I've been trying for a long time to ingrain in myself. If someone is grouchy or irritable, it might not be that they're a bad person, it could be simply a bad time, day, week. The best bit for me about being in a software team for the first time has been learning to work with people. Consistently tough but rewarding.

Why exactly are programmers' opinions more important and refined than anyone elses?

Part of becoming a great engineer, in my limited experience, is developing a sense of taste for what problems are worth solving and which approaches to consider.

The software we build ends up baking in those opinions: into the frameworks and libraries, into our philosophies, into the algorithms themselves, and ultimately into our culture. We end up with Rails whose claim to fame is being based, unabashedly, on its strong opinions. We end up with the LKML being what it is. We end up with ML algorithms with our biases built in. That's why our opinions are rather important.

Our opinions signal our status to other groups. If you're an opinionated statically-typed functional programming aficionado it's quite likely you're not going to fit in with people who are serious adherents to object oriented programming. And you will find many people without any opinions or whose opinions lie somewhere in between.

We can't avoid having them and it's important to be able to work with other programmers and so being able to set those things aside to focus on the customers' needs, the business context, and the well-being of your team takes precedence!

Not OP either, but I think what OP means here is that programmers feel that their own opinions are more important and refined than anyone else's, even other programmers. This means that they are likely to judge someone who operates in a way that differs from their opinion more harshly.

A bit of that too.

Because they're building it, it's more important. If you want to build along vector X and they believe in Y, you'll only get the projection of Y on X in business value. So if you can convince the people making things to make something closer to X and you can articulate that value and excite people about it you'll get a bigger projection.

The refining part I don't get.

Not OP, but my stab: programmers are the ones actually building something. A technical leader can craft a vision for the technical future of a product, but the engineers need to buy into that vision and will, by necessity, quickly form refined opinions on the implementation details as they build things.

I've wondered this as well. Are there equivalents in other industries? Some human trait that shows up in some circumstance?

Thank you for this post - it's something I needed really badly to hear this week!

About "Humility and Empathy"... why not to try Whiplash(2014) movie teaching method?