Charity Majors

I've read a lot of Charity Majors' stuff, and in some ways this opinion is typical of her, and in some ways it is not.

Obviously, she's a big proponent of engineers taking full ownership of their work. That's core to observability, which is what her day job is all about:

https://charity.wtf/2020/03/03/observability-is-a-many-splendored-thing/

Yet one of the pieces she's well known for is "The Engineer/Manager Pendulum," where she argues that some of the best managers and some of the best ICs are people who have gone back and forth between the two roles:

https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/

In one sense, that is consistent with her opinion about architects being a BS position, sort of analogous to calling out useless middle managers.

But one of my takeaways from her pendulum opinion is that those senior ICs who have pendulumed are better off precisely because they bring a management skillset to IC work and an IC skillset to management work.

And a high enough level, that manager's eye might involve recognizing that helping other engineers design their systems is imparting more engineering influence than whatever any one person can do at the code level. And in these cases, I'd argue you're still delivering engineering value rather than just project-management value.

Charity knows a lot of these senior ICs, and so it's not as if she's dismissing their potential value out of ignorance. So I'm a little surprised that she's throwing the baby out…

Dan Luu has a list of programming blogs you might like: https://danluu.com/programming-blogs/. The rest of his blog is good too!

a few of my favorite blogs:

- http://blog.acolyer.org for fantastic daily summaries of CS papers.

- http://stephaniehurlburt.com/blog/ -- she has a business creating a new compression algorithm and I love reading about it

- https://rachelbythebay.com/w/ is pure gold for weird debugging stories

- https://accidentallyquadratic.tumblr.com/ is always a fun read

- http://wingolog.org/ on building compilers

- http://composition.al/blog -- Lindsey Kuper on her programming languages research

- aphyr's blog on distributed systems, of course

- https://charity.wtf/

- http://www.pgbovine.net/writings.htm -- Philip Guo is a CS professor whose blog on his experiences in academia I really like

- http://whilefalse.blogspot.com by Camille Fournier, mostly on engineering management

- http://larahogan.me/blog/ by Lara Hogan, on engineering management

Also I think this comment from Dan's blog (https://danluu.com/about/) is very true and important:

> I view that as a sign there’s a desperate shortage of understandable explanation of technical topics. There’s nothing here that most of my co-workers don’t know (with the exception of maybe three or four posts where I propose novel ideas). It’s just that they don’t blog and I do. I’m not going to try to convince you to start writing a blog, since that has to be something you want to do, but I will point out…

The author:

> Charity Majors is cofounder and CTO at Honeycomb.io, a platform that helps engineering teams debug and improve their software applications.

> https://charity.wtf/ Blog, latest article an apologia for DEI, "The diversity of your teams over the long run rests on your ability to build an inclusive culture and equitable policies."... "Don’t underestimate what a competitive advantage diversity can be"

Hmm. Why does no one argue for equitable balance of political views, or religions, or anything to do with ideas at all? Is anyone even measuring ideational diversity? Power-sharing in most countries is principally concerned with it, for example. How many 'inclusive' teams are extremely politically, and ideologically, homogenous?

Clearly there's a apologia for a certain worldview at work here: some sunk-cost investment in a certain notion of inclusion, which is entails (if not aims for) moral and ideological uniformity. Offensive to this notion of 'inclusion' is excellence, since excellence isn't uniform nor even normal -- it's pareto distributed. An excellent runner is exponentially better than a normal one, and sampling uniformly from all groups ("inclusively") produces bad runners.

According to experience, and all evidence, the best talent arises out of healthy competition and cooperation with the best talent -- it does not arise out of uniform, nor even, normal distributions.

If you sample uniformly, then race all against all eventually a powerlaw arises --…

I've experienced this my entire professional life.

I think this is the cause: https://charity.wtf/2020/09/06/if-management-isnt-a-promotion-then-engineering-isnt-a-demotion/

tl;dr: Management should be a supporting role, but because it's closer to the business (and usually staffed by "Idealists" as described here: https://leanpub.com/developerhegemony), it's given a more powerful position, and does whatever it can to execute as needed by the business. Of course everyone (managers included) also want to keep the power they have and gain more power/money over time.

Developers' time isn't respected because managers have more power and building software is hard, so rather than building partnerships and supporting everyone as needed, then just squeeze harder, treat people lower on the org chart as lower worth as humans, and generally don't shield or abstract things away as much as they should (often not at all). From the article:

> The goal of most software projects is to deliver to deadlines and budget of the plan. The real goal of a software project is to create the right software, but instead decisions focus on the meeting the plan not creating software.

The plan is focused on instead of the software because the plan is the artifact of the more important people, the managers. They're higher up on the ladder because they're more loyal to the company. Even when this isn't the case they're still higher up because it's safer to have them in power rather than devs who can…

Great comment! My corollary would be that "Many managers have never had a great role model". In my first role as an engineering manager I thought it was the logical career progression and promotion from lead, but my preparation was more along the lines of "I've had managers, I can do what I think they do". I was very fortunate that my company at the time was supportive with follow-up training and building a peer group of newly minted managers, but it would have been more ideal to have some prior leadership & management training so I was more aware of the role and responsibilities I was signing up for. I think training provides helpful insight into intentional motions and being a competent manager, but it is hard to beat experience and learning from some great role models.

One secret I would tell any engineers considering management: "management is a career change, not a promotion". Charity Majors has some excellent blog posts on this, including the Engineer/Manager Pendulum: https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/.

This is excellent, I'm going to use this to separate production from test environments using separate accounts.

Using VPCs, security groups, IAMs, tags, etc. is great, but those are all constructs you have to take care to implement correctly yourself within your deploy scripts. One slip-up and you could accidentally expose environments to each other, or worse make a mistake that deletes or reconfigures resources in an environment you didn't intend to. Or an errant process in a test environment could unexpectedly gobble up too many resources, resulting in production being throttled.

So separate accounts is the safest isolation approach, but historically there have been drawbacks (this blog post discusses some[1]), like billing is more expensive (due how AWS charges for usage and you won't be sharing reserved instances anymore) and I wasn't sure how to handle things that need to be cross-environment, like Route53 (DNS). Looking forward to trying this out!

[1]: https://charity.wtf/2016/03/23/aws-networking-environments-and-you/