anchochilis

Yes, totally agreed in theory, and it sounds like y'all built a great solution for your use case. But it takes substantial effort and discipline to do something like that at scale.

At some point, you develop complex interdependencies with other systems. You need sophisticated caching for optimum build performance. Techniques like GitOps are unsustainable at a certain number of engineers/commits per hour.

What you're missing is maintenance, security, scaling, and protection from data loss.

Bespoke CI is easy to build but no one wants to be in charge of rolling out a critical security patch to that on-prem box no one's touched since that consultant from 2 years ago.

What I don't understand is why they don't have a canary update process. Server side deployments do this all the time. You would think Windows would offer that to their institutional customers, for all types of updates including (especially) 3rd party.

We routinely implement phased / canary deployments in server-side systems to prevent faults from rolling out globally. How is it possible that CrowdStrike and/or Windows does not have a similar system built in for large, institutional customers? This is outrageous.

> In other words, the founder doesn't have the qualifications or characteristics that the underlings assume they need to be in a leadership position.

I find this to be an odd take, given context in the article. It sounds like the writer is simply contrasting her own leadership style with her boss's, as an example of how they complement each other.

Hierarchies make us uncomfortable because they challenge our egos. I've noticed this particularly in classic programmer personalities: smart, introverted, highly skilled. Many of us spend our entire careers as ICs, as leaves on the corporate tree. It's easy to become cynical.

"The VP sits around chatting people up all day and droning about OKRs while I just shipped a million dollar feature / resolved an expensive outage / built a tool that will dramatically increase engineering efficiency. What value does _he_ bring to the table?"

Unfortunately this is an enormously unproductive attitude that will kneecap your career. No org is a meritocracy -- but what does meritocracy even mean? We sort everyone by IQ? Or "performance", measured by lines of code committed per week?

On a final note I'll add that hierarchies get things done. Imagine working for a company that functioned as a democracy, with all the attendant discourse, campaigning, checks and balances. I would personally find the inefficiency intolerable. Better to work for a single idiot than a committee of a dozen geniuses.

This was my great frustration with Twitter the last time I tried it. Even when I carefully curated my followers, random crap would constantly sneak into my feed. It was annoying enough that I started just manually navigating to a few bookmarked profiles periodically to read their latest tweets.

This blog post reads like it's written by someone using Subversion back in 2015. Most of the justification for committing on mainline can be addressed by following other best practices:

1. Run the same suite tests additional quality checks (linters, etc) on PR branches that you run on mainline

2. Run branch CI against the merge commit for your PR branch (i.e. include your changes as well as latest mainline)

3. Avoid long-lived branches.

If you run into frequent merge conflicts and incompatible changes in an area of your codebase such that your team needs to integrate individual commits every half-hour instead of keeping 1-4 day feature branches around... That sounds like a code and/or organizational smell.

However!

> Using pull requests for code changes by your own team members is like having your family members go through an airport security checkpoint to enter your home. It’s a costly solution to a different problem.

I actually do like this analogy -- but it's not PRs that are the problem, it's mandatory reviews. And the cost/benefit of mandatory reviews varies widely depending on how senior the engineers on the team are, how much their work overlaps, and what their average tenure on the team is.

> I think we ought to consider a system where the Government or Fed provides the core functionality of “let me put $X in an account so I can use $X in the future” for free and banks compete based on value added.

Don't credit unions already provide this service?

One major draw of Lego is their licensing of expensive creative IP. Look at the Harry Potter, Star Wars, DC, Lord of the Rings themed sets. Smaller competitors likely can not afford the same offerings. And Lego probably has deep enough pockets to ensure exclusive deals.

There's also something to be said for having such a dominant, established brand. Lego is a cultural icon, beloved by multiple generations. Picking up a knockoff kit is sort of like taking your kid to a random local theme park instead Disney World. While in theory the two options have similar features (rides! characters running around in costume!) they are of course not the same.

You know the old saying "familiarity breeds contempt"? I believe the opposite is true as well. People who don't code think coding is typing. People who don't manage think it is as simple as forwarding emails from executives to subordinates.

I myself have often wondered if what doctors do couldn't be automated. You have the primary care physicians who seem to run on a loop of "listen to symptoms" - "order tests" - "prescribe medication" - "refer to specialist". And the specialists themselves seem to follow their own loops. Many surgeons for example, perform the exact same procedure day in/day out for decades. Surely well-trained robots, not prone to fatigue or loss of dexterity as they age, could produce superior outcomes.

But they haven't been replaced yet, just like I haven't, so I assume there is more going on there than what looks from the outside like repetitive manual labor.

I do think a future where AI can generate convincing-but-subtly-flawed blog posts like this one is closer than one where chatgpt generates correct, on-spec production code. Maybe influences and hustlers will be the first to go.

Someone should make an AI-generated crypto-influencer persona. Virtual YouTube, Twitter presence. Mint a new coin once per week, hawk it to the masses. I bet they could make decent money.

I am afraid that as long as humans are writing code there will be other humans in charge of ensuring their work is profitable. We won't be able to do away with executives just yet, unfortunately.

This was funny. But I've seen too much clean code written by people smarter than me to agree.

I actually think how "clean" your code is depends on lots of factors. Eg.

(a) Do you care if your coworkers find it easy to modify your code?

(b) Do you feel a sense of ownership over the code you're touching?

(c) Does your organization reward delivery speed without any checks for code quality? (eg. no culture of code review)

(d) Is the code a proof-of-concept that needs validation from users before further investment?

The key point is that someone else is watching the baby while you work.

WFH is indeed wonderful for parents and families, but if you try to do it without childcare, you're not going to be working much.

I think the author has a point here. In an ideal world, we would of course spin up a new microservice every time a PR in the foobar-widget-generator service begins to deviate from generating foobar widgets. In practice, we make delivery tradeoffs all the time. It's not at all uncommon for service scope to creep while a new, urgent feature is being experimented with. And launching a new service is never, ever going to be as cheap as updating an existing, well-maintained one.

My own hard-line requirement when it comes to naming services is that they should be a single word with some relationship to the service's purpose. Ideally a common English word, but proper nouns are permitted if they improve clarity. Brevity must ALWAYS take precedence over clarity. There's only so much you can express in a name anyway; a detailed explanation of exactly what a service does should exist in documentation.

Otherwise you end up with long names like "horizon-blob-profile-server" or "batch-process-execution-engine". Multiple words lead to ambiguity. Inevitably you end up using dashes, camel case, underscores, or no differentiation at all in order to represent word boundaries in different systems, because VCS, filesytems, domain names, and cloud systems all have different sets of permitted characters. This makes automating your infrastructure painful.

And of course people resort to acronyms when discussing the services, which means everyone is forever getting the dfkg service confused with dkfg. "Whoops, I deleted the wrong database!"