Notices by Marco Rogers (polotek@social.polotek.net), page 6

Can anybody point me to a good deep dive on the mastodon database schema? Preferably with explanations where necessary? Yes I know how to go look at the mastodon docs and code. I’m doing that. I’m also looking for more of a guide to wrap my head around things.

I've been thinking a lot about what what it would look like to have a mastodon-compatible architecture that was designed for a single admin/single user experience.

I think what I want is an architecture that is designed with an eye towards maintainability and also preserving the data long term. So for example, I don't think I want a traditional database to be the primary store of record. I want things in text files. They can be loaded into a store for performance and efficiency. But the store of record is just text that can still easily be read many years from now.

That part.
https://hachyderm.io/@evacide/112452473407557731

At least the ai boom is gonna force everybody to renegade with security and privacy practices?
https://tweesecake.social/@weirdwriter/112441889190313713

What does "community-led" mean in this context?
https://toot.cafe/@baldur/112428431536118693

The subtweet (or whatever we're calling it over here) at the top of this thread was referring to a brief exchange about frontend web technology. I'm already on record with my opinion that we've lost our way in the frontend. Most of the conversations are about how to add more complexity in order to make things slightly more convenient for devs. Very few conversations have anything to do with what we hope to create for people.

I don't think I'll ever understand the kind of person who says "you MUST fight with me about technology minutia. And if you choose not to, I will block you forever." Like it's such a weird combination of principles.

There are lots of different reasons that my career in tech has been effectively derailed. But first and foremost, I definitely failed to make talking about tech into my entire personality. That has been working against me for a long time. 😂

That's not meant to be a judgment towards people who talk about tech a lot. I used to enjoy talking about it too. Even the minutia. I think what changed for me is that I started to ask where it was leading to. And I couldn't form a coherent answer that mattered to me.

I believe in the promise that tech is meant to enhance human potential and improve human experience. I want to be able to talk about tech in the context of what we are hoping to achieve.

That's as practical as I can make it. And I know I'm glossing over and simplifying a lot of things. But I would appreciate it if folks would tell me if these descriptions are helpful to them.

What I'm reacting to most strongly is how many engineers still say they don't really understand why things are happening around them. I want to help improve on that.

Youcan still be mad about it. You can still disagree and wish it was different. But we should at least work on a shared view of reality.

Here's the thread from yesterday.

And to be clear. When I ask how you evaluate your engineers, I'm asking explicitly about performance reviews and ultimately promotions/raises.

I know that's a difficult topic to talk about in public. I hope we can get some candid discussion going. I'll share my own thoughts a bit later just like I did yesterday.
https://social.polotek.net/@polotek/112367263499188111

Generally fewer takes on the management side of estimates. I think that's mostly due to my reach on mastodon being still pretty nascent. I appreciate the people who shared their thoughts in the replies.

FWIW, I expected to hear answers on how managers thinks about receiving estimates from engineers. And I did. What I didn't hear about yet is "here's what I do with the estimates once I get them."

I asked that question explicitly to try to create a bridge for engineers to understand the why.

I'll give some my own answers. The reason I need estimates from engineers is so we can do planning. It seems simple. But engineers sometimes don't often have an understanding of where their work is situated amongst other business activities.

In the case of B2B SaaS products, when engineering is close to shipping something new, other departments gear up to receive the handoff and make it turn into revenue. That usually means marketing pushes, sales calls, customer success follow-ups, etc.

If we say something is going to be done around this time, and it's not, that impacts other people's real work. This is a core truth that I often struggle to get engineers to engage with. When we say that dates matter, they picture mustache-twisting managers inventing arbitrary deadlines. That does happen sometimes. But it's not at all the norm. The norm is running a business where your work isn't the only work that matters. Coordinating all these activities requires people to commit to dates.

So when I receive estimates from engineers, I work with PMs or go-to-market teams to sketch out agreed upon timelines for them to be ready for handoff. Those teams usually have goals driven quarterly KPIs or OKRs.

So for example, "We're on the hook for $2MM in new revenue next quarter. If we can get this new thing from engineering, I can tell my team to push it in sales calls."

Just to remind you of context, my experience is B2B SaaS at tech startups. These are relatively short turnaround cycles. Other types of businesses can have much longer cycles between engineers delivering a thing and other departments picking it up. But the core tension is the same.

If we don't know when the thing will ship, we don't know when other people's work kicks off. And we can't project what will happen with business metrics. That's why estimates matter.

Confidence intervals are great. The important thing is that they should get refined and narrowed over time. As you get further along, you should become more confident about the delivery timeframe.

I think this practical execution piece is often lacking in estimation processes. If you only deliver a confidence interval once or twice over the course of the project, that's not useful. If the interval never changes, that's not useful.
https://tech.lgbt/@risottobias/112373995567079983

Number one is debatable. But I don't care to debate it today. It tends to make people angry. 😂

Number 2 I will absolutely agree with. I think it is part of the management role to help teams organize their work and to manage distractions. However, I don't think that is a solo management task. Engineers need to collaborate on how to be effective at manage distractions.

I am very opposed to the popular "shit umbrella" philosophy of engineering management.
https://im-in.space/@Chip_Unicorn/112374023229088372

I'm really trying to improve the way we discuss these issues so that engineers can hear the message. So let me push myself to unpack this statement even further.

What do I mean by "project business metrics"? In the case of tech starts, what that means is we are not profitable. If we run out of money, you don't get a paycheck. So we need to have a forward-looking projection for how much revenue the business will make. Next quarter, and the one after that, and the one after that.