Links - 29^th October 2023

One of the very first lessons we teach new managers is to be wary of micromanagement. This lesson is so strong for some leaders, that it remains an important leadership principle for them even as they become an executive. When I push such executives to proactively inspect their team’s work, they’ll often earnestly reply that they’ve actively decided not to inspect their team’s work because they don’t want to be a micromanager.

It’s not micromanagement to know what a team is doing. Nor to question the thinking behind a decision they’re making. It’s reasonable to review their goals, and their progress against those goals. It’s OK to talk to their internal and external customers and hear feedback on how it’s going. Those are all activities that empower your team to do meaningful work. If you ever have someone imply that those activities are micromanagement, then it’s far more likely that the individual is misaligned with you than that you are too deep in the details. Don’t let accusations of micromanagement steer you away from doing your job.

• The boundary between architectural and other significant decisions is often ill-defined.

• All architectural decisions are significant (using the cost of change to measure significance) but not all significant decisions are architectural.

• Just because something is time-consuming to change does not make it architectural.

• Architectural decisions involve the fundamental concepts the system uses because the code implications of the choices are scattered throughout the software rather than being localized.

• Teams who need to record significant decisions should create a separate Significant Decision Record to avoid overburdening their ADR with other decisions.

Many teams, lacking a place to record any sort of significant decision, put any decision they consider significant into an ADR, diluting the architectural aspects and turning an ADR into an “Any Decision Record”.

To illustrate, a decision to select a database management system is usually regarded as architectural because many systems will use it for their lifetime, but if this decision is easily reversed without having to change code throughout the system, it’s generally not architecturally significant. Modern RDBMS technology is quite stable and relatively interchangeable between vendor products, so replacing a commercial product with an open-source product, and vice versa, is relatively easy so long as the interfaces with the database have been isolated. The architectural decision is the one to localize database dependencies and abstract vendor-specific interfaces, not the choice of the database itself.

“How do I solve this problem?”

“You do not. You avoid having that problem in the first place.”

“That isn’t helpful.”

“In fact, it could be.”

One of the challenges of experience is navigating communications of this general shape. The experience that tells you it’s true doesn’t necessarily give you a way to communicate how obviously true it is to people who haven’t gone through the same.

When I first started learning about compilers, there was something important which I didn’t understand: Designing a programming language and writing a compiler are two almost entirely different skills. There is obviously some overlap between them, but less than you might think at first!

I think it’s important to know this because they are both very challenging problems! It’s easier to learn these skills if you take them one at a time. Your first solution to a hard problem is likely to be… well, not as good as your tenth! However, it’s pretty common for developers to build out a toy language as they write their first compiler, which means they are making mistakes and learning stuff on two hard problems at once. Worse, those two problems are correlated: A mistake on one will make your life harder on the other. Also, as we will see, although compilers are challenging at first they’re essentially a solved problem, whereas PL design is, let’s say, an area of ongoing research.

I think it’s easier to learn to write a compiler first, and then (if you want) learn to design programming languages. It will be harder to learn to design a good programming language if you don’t have experience with compiler design challenges (amongst other things), so if you want to learn both skills I recommend doing it in that order: Compiler, then PLs. Compiler construction is useful to nearly all software engineers, even (especially?) those who will not build compilers as part of their daytime job. Knowing the challenges of PL design is also useful, but I think in a more abstract way.

Public social networks force us to use a different facet of our identities. In a private space with your friends, nobody really cares about your job, and nobody’s hustling to promote whatever it is they’re working on. Twitter nudged social networking into becoming a space for marketing and brands, which is a ball the new Twitter-a-likes have picked up and carried. Much like the characters from The Breakfast Club, each of the new Twitters has its own stereotypical niche: the nerds, the brands, the rich people, the journalists. But they all feel a little bit like people are trying to sell ideas to you all of the time.

It actually takes surprisingly little software to transform Mastodon streams into e-mail and RSS feeds, if you can resist temptations of overengineering.

The hopefully generalizable lesson from this project is that it is possible to improve one’s personal computing environment with reasonable effort, under the condition of accepting an initial learning curve for some technologies. The important question then is how to identify technologies that are worth learning, which I interpret as technologies that are likely to be useful again for other software personalization efforts.

I don’t have numbers to back this up, but from observing people there are basically two kinds of tab users:

• People who have 1-3 tabs open and get confused (or annoyed) if they have to deal with five. These people probably don’t need tabs and would probably be happier with some sort of multipane workspace.

• People who way too fucking many tabs open. Like hundreds. Maybe organised into topic windows, but sometimes not. Many folks in this group will tell you that they "love tabs" but that’s the kind of love you might legitimately worry could too easily end up involving dismembered body parts in the freezer. These people really don’t need tabs, they need a way to organise the information they are trying to keep track of, and they need that to work offline. (If you just said “bookmarks” I would like you to leave. Now.)