Every Monday I’ll try and post links to articles or videos I’ve found interesting and useful. Today’s post is mostly about explaining things.

Dave Farley reviews Team Topologies.

Team Topologies is important, and adds a significant piece to the jigsaw puzzle of how to build great software.

Simon Willison asks GTP-3 to explain code and finds it to be “shockingly effective”. Willison’s examples include Python, Javascript, creating tables and querying them with SQL, a config file, and mathematical equations. If you’ve ever looked at your own code and wondered “what was I thinking?”, AI might be able to tell you.

That said, Willison notes that GPT-3 doesn’t actually “know” anything, it’s just really good at looking like it does, and we should keep that in mind before asking GPT-3 something like “which is better?”

Once again, I’m reminded that tools like GPT-3 should be classified in the “bicycles for the mind” category. You still have to know how to pedal!

They’re fantastic tools for thinking, but to actually use their output effectively requires VERY deep knowledge—both of the subject matter in question, and of the way that the AI tools themselves work.

Also Simon Willison in the b3ta newsletter:

Using these AIs feels more like spellcasting than programming: no-one, not even the creators, fully understands how they work or what they can do and you get better at them by accumulating weird new incantations that might lead to better results. Or unleash demons if you type something wrong.

And speaking of explaining things, Julia Evans has some excellent advice on how to avoid confusing folks when you’re trying to explain technical things.

[…]knowing that I’m likely to accidentally do these things makes it easier for me to avoid them, and it makes me more receptive to critique when people point out issues with my writing (“Julia, this is assuming a lot of knowledge that I don’t have!“).

Being aware of these patterns also helps me when reading a confusing explanation: “oh, I’m not confused by this explanation because I’m stupid, I’m confused because it’s introduced 6 new-to-me concepts and it hasn’t explained what any of them is yet!“.

Every Friday I post a video related to one of the themes of this site. This week it’s a talk by Daniel Na about pushing through organisational friction to get important work done.

What is organisational friction? Daniel’s description says it best:

As a senior-level engineering leader, experience tells you things could be better. You see the gaps. If only the company adopted policy A or dumped technology B, everyone would benefit. But there’s so much inertia. The company has always used B. You are frustrated. Can you actually make a difference? Yes. You are encountering organizational friction, and learning to identify, accept and push through friction is a key skill of engineering leaders.

The slides for the talk are on Daniel Na’s website.

This collection of books has helped me understand how to be a software engineering manager. They cover the complexity and nuance of middle management in the software development space. There are technical books, people management books, books on planning and strategy. I have found value in all of them and recommend them to anyone who is or wants to be an engineering manager.

Continue reading →

Every Friday I post a video related to one of the themes of this site. This week it’s a dive into the how the first edition of the legendary Civilization series of games was made.

Sid Meier and Bruce Shelley talk about how they made Civilization, including design decisions, technical trade-offs, and why the game’s version of Ghandi had such a bad temper.

Scott Hanselman’s guest on episode 847 of the Hanselminutes podcast was Roberta Arcoverde, the Director of Engineering at Stack Overflow.

Their discussion covered a lot topics, and, to my mind, was a perfect illustration of the complexity and nuances of the engineering manager role. At one point Roberta summed up her role like this:

“So now I manage the people, right? I manage their careers, I help them grow. And I also have a strategic vision of where we need to be. So it’s more of a position it’s very similar to what engineering managers and other companies do. But it’s a little bit more technical than that too, because I do need to keep my eyes on where the software architecture is, is moving towards what are our strategy in terms of scale and where we want to be and not in the next PR, but in the next three years.”

Every company does engineering management differently, but that mix of technical detail and strategic focus is common, especially when you get a the manager of managers position.

Anyone curious about the management side swing of the engineering/management pendlum would get a lot out of the things Roberta talked about.

Continue reading →