Thoughts 5 — Being a good engineer; using the word We

published 2023-03-02 [ home ]

“Thoughts” are posts about what has been on my mind. Sometimes practical, sometimes not; often just things I read recently. Less thought out than regular posts.

What is a good engineer?

When I was a student at IMT Atlantique (back when it was still called Telecom Bretagne) I took an optional class about the history of telecommunication systems. It was mostly taught by retired engineers from the field.

It was a fascinating class. A recurring theme was what an engineer’s job was about. One of the teachers, who had been instrumental in the development of electronic switching in Europe, said something among those lines: “a good engineer delivers systems that are scalable, cheaper, and ship faster”.

I have been thinking about that topic lately, and even though I will not deny the “it’s all about trade-offs” line I have been using for years, it is good to remember that those trade-offs should be made only on the optimum curve.

Add to that the idea that engineers should know what systems not to build, and you have my definition of what makes a good engineer.

Using the word We

Karl wrote something interesting about using the word We to talk about a company or a team. He wrote it in French so here is a rough translation:

I often see a company’s employees use the word We (“nous” in French). For a very long time I have been trying to avoid using this turn of phrase in my mail, bugs, etc. For instance, at Mozilla, I used to say “the Webcompat team” or “Mozilla”, or to change the sentence to focus on the product itself.

Instead of “We should add feature H to solve this bug”, I would say “Product A needs feature H to solve this bug”.

When I notice myself unconsciously using “we”, I correct it immediately. But why? To preserve the emotional distance between work and pseudo-belonging to a company.

“We” has a very inclusive meaning of identity for me, and so I avoid it in contractual relationships. The company no longer has a “we” when the time to reduce its workforce for financial gain comes. It is one of my struggle techniques, a small resistance.

I understand what he is saying and it makes a lot of sense, yet I make a different choice. In fact, I cannot fathom working for a company or at least a team where I would not feel comfortable saying “we”.

It’s the same uneasy feeling I have when I see people say that small startups branding themselves as family is a red flag. I understand why they would say that. And sure, we are not family, but when you work that closely with people for years, I think there should be some sense of belonging. Maybe “friends” is a better word.

Also, I am never going to work for a company if I am not aligned with its mission. If I start trying to distance myself from it and notice it, things will have to change one way or another.

Opportunity Cost

This tweet by Jaana Dogan made me remember this blog post by Erik Bernhardsson, which I often find to be true, especially when dealing with startups.

Never attribute to stupidity that which is adequately explained by opportunity cost.

Theory of Mind

A great post by Andrew Bosworth (CTO of Meta) about how some people such as John Carmack can have an influence even after they’re gone.

Chrome, 10 years later

A long post by Evan Martin about his experience working on Chrome from 2007 to 2012. Toward the end, he turns to the state of Chrome and the Web today.

I love this kind of retrospective post, which are full of anecdotes, deeper insight, and food for thought.

By the way, Evan posts interesting things on a variety of topics. I have been subscribing to his feed for a very long time, I think for Arch-related content initially. You may want to look at his other posts as well.

Invest in things that don’t change

Here is DHH saying something I’ve been saying for a very long time as well, but it bears repeating. There is way too much stuff happening to follow it all. If you want to last in this job, especially as a generalist, you must figure out the fundamental things that will matter even more in 10 years than today, and ignore most of the rest unless it’s a deliberate strategy.

CRDTs, Automerge and Braid

Even though it’s not my main focus anymore, I am still following CRDT-based state synchronization systems attentively. Two projects have caught my attention recently. The first one is Braid which has been progressing steadily, and the second is Automerge which has announced a major 2.0 release.