mr_tristan

I wonder if at a certain point, someone learns about compounding, and just sticks with it, building generational wealth. And poof, the wealth just keeps growing as long as the descendants don’t make errors.

We seem to love creating stories about why so-and-so is rich, but, I suspect the most common answer is “time, patience, and no major bad luck”.

Yeah, I think there's a lot more "good, focused" companies out there than what are covered in this hidden champions book. The book is just interesting to me. It highlights a lot of the economic export strength of Germany isn't due to the large corporations that people know, but a bunch of mid-sized companies people don't.

In some sense, what seems important is a business culture that has a mission or meaning to exist other than make shareholders money. I'd wager their employees will absolutely geek out about what the companies do throughout the organization. A lot of corporations these days, once you get above a couple of layers of management, is all fluff. I can't think of the last time I talked to a mid-level or above "engineering" manager in a tech company about any nuanced or interesting discussion about technology.

Ultimately, the first line is really resonated with me:

"When I get to write or read on a screen that’s reflecting the sun back at me instead of needing to be shielded from it, I get a dose of this feeling that this is what all computing could feel like. I want so much more of this in my life."

I have the DC-1, and where I've used it in direct sunlight, it's a great feeling. However... it's rare that this matters. But... it's winter. And so I'm inside because it's f*king cold out. I'm holding onto hope that this will bring me outside to read and note take a bit more eventually.

My iPad is still king for my "tablet computing". Especially note taking, drawing, design tasks (like CAD), casual gaming and entertainment consumption. I don't see the DC-1 replacing my iPad use any time soon. The app ecosystem, screen, sound, etc, are just not good enough to replace my iPad. Frankly, I just don't see anything that can really compete with the iPad, which sucks, because I feel like Apple continues to underestimate what the iPad could be. (It should be more like a mac and not like a phone. The hardware can do this, the software can not.)

... but anyhow, the DC-1 makes me excited to be able to, say, go to the park and read and note a design doc. Etc. Like, this device could be a lifestyle changer... when it's nice out. Or it might be a device I read documents on and take notes on the iPad. This is a second use case I'm just starting to figure out.

So I'm going to keep onto mine, and I'm optimistic and excited. But it's early.

Not that I know of.

I do think you could do some analysis to associate code with implementers and create graphs, where you account for additional things like time. I could see LLMs being helpful in maybe doing part of that analysis. But I would use that to see where the biggest "bus factor" is, i.e., finding subsystems where there's really only one active contributor.

For planning or task assignment, it might just help to say "ask X for more detail" when there's no other docs or your LLM is spewing jibberish about a topic

This list does resonate, but I’d make some tweaks to express things slightly better. For example:

> Most programming should be done long before a single line of code is written

I would say “most engineering should be done before a single line of production code is written”.

Formalizing a “draft process” is something I’m really trying to sell to my team. We work in an old codebase - like, it’s now older than most of the new hires. Needless to say, there’s a whole world of complexity in just navigating the system. My take: don’t try to predict when the production code will be done, focus on the next draft, and iterate until we can define and measure what the right impact will be.

The problem is that there’s a ton of neanderthal software engineering management thinking that we’re just ticket machines. They think the process is “senior make ticket, anyone implement ticket, unga bunga”. What usually happens here is that we write a bunch of crappy code learning the system, then we’re supposed to just throw that in a PR. Then management is like “it’s done, right” and now there’s a ton of implicit pressure to ship crap. And the technical debt grows.

I haven’t quite codified a draft process, but I think it’s kind of in line with what Chris here is talking about: you shouldn’t worry about starting with writing production code until you’re very confident you know exactly what to do.

Ah well, it’s a fun list of opinions to read. Chris’ WIP book is an interesting read as well

Software problems almost never seem to actually impact brands, but this was so egregious it actually managed to. Even Crowdstrike increased revenue over the last year.

So… I’m not shocked at the timing. Sales have tanked, and proved the CEO couldn’t be relied on to right the ship.

It’s just one example of how long serious problems can fester in an organization. There’s likely deep cultural problems throughout the company’s decision making apparatus. We’ll see, but I don’t see Sonos capable of being a trusted brand again.

Right now, I’d say the “AI IDEs” like Cursor or Zed are ready to replace less Java-centric environments. I’d put VSCode in this “not really Java centric” bucket. I see VSCode as a “fancy text editor” for Java, i.e., better than an editor like Neovim, but, not by much. So, an AI IDE is more likely going to gain traction on people who have been using VSCode or Neovim than anyone using Eclipse or IntelliJ.

Recently, my company has tried to introduce a “cloud IDE” (the development environment runs in the cloud somewhere). Initially, it only supported VSCode. The only engineers that bothered using it were junior; once people had about 5+ years of experience, they just found it tedious. Once the company included IntelliJ for that cloud IDE, usage spiked massively. (To the point they are restricting usage due to cost.)

These “classic Java IDEs” just launch with features useful for understanding large systems, like, fast navigation and debugging capabilities. Things like “where is method used” or “what implements this interface method” is fast and accurate - i.e., not based on text search. Or the interactive debugger that lets you inspect stream state, track objects, etc.

JetBrains probably won’t be focusing on using AI simply for writing code, but for enhancing all of these other capabilities. This is where I’m not sold on Cursor or Zed replacing these truly language-specific IDEs… yet.

These new upstarts need to improve the ability to navigate and understand. Right now, they only seem to focus on writing, which I don’t think is what’s going to gain traction. I also don’t see any of them doing much other than just fancy autocomplete, which can be awful on a large legacy codebase. So… we’ll see.

This could be generational, I’ve definitely seen poorer DevEx win simply because they gained the attention of younger engineers and lasted long enough.

I don’t use an LLM largely because my current codebase has a massive amount of bespoke internal APIs. So LLMs are just useless and wrong for almost any task I use.

But this has led me to wonder if there will be gradual pressure to build on top of LLMs, which, in turn, will really only be useful with the tried and true. Like, we’re going to be heading towards an era where innovation means “we can ask the LLM about it”. Given the high capital costs required to train, I wouldn’t be shocked to see LLMs ignoring new unique approaches and biasing to whatever the big corps want you to do. For “accuracy”.

I just sense were about to hit an era of software causing massive problems and costs, because LLMs are rapidly accelerating the pace of accidental complexity, and nobody knows really how to make money off them yet.

The “great recession” didn’t seem to impact tech like the dotcom bust did. So millenials and younger really hadn’t lived through a lean era in tech like we’re living in now. This is easily the worst jobs market since that dotcom bust. So it’s been a while.

Nothing like seeing how arbitrary layoffs are to seeing how shallow leadership decisions can be.

This is the period that actually defines good leadership. A good leader, at least to me, won’t be led by investors to making largely short term decisions. They will define how their organization needs to evolve and challenge them to make it happen. But what I mostly see, are leaders doing stupid things like RTO then layoffs (goodbye, loyalty!), and then shrug and whine about having to maintain margins while cutting money losing projects that shouldn’t have been started in the first place. And then turn around and say “the future is AI” without really having much of a plan.

The leadership BS really stinks during these times, and it’s something that the younger generations haven’t really experienced.

I find that architecture should benefit the social structure of the engineering team, and there are limits. I work on one of these “simple architectures” at large scale… and it’s absolute hell. But then, the contributor count to this massive monorepo + “simple architecture” hell numbers in the thousands.

Wave financial is only 350 people according to wikipedia - I doubt that’s 350 engineers. I know only of Google and Meta that can even operate with a massive monorepo, but I wouldn’t call their architecture “simple”. And even they do massive internal tooling investments - I mean, Google wrote their own version control system.

So I tend to think “keep it simple until you push past Dunbar’s number, then reorganize around that”. Once stable social relationships break down, managing change at this scale becomes a weird combination of incredible rigidity and absolute chaos.

You might make some stopgap utility and then a month later 15 other teams are using it. Or some other team wants to change something for their product and just submits a bunch of changes to your product with unforseen breakage. Or some “cost reduction effort” halves memory and available threads slowing down background processes.

Keeping up with all this means managing hundreds of different threads of communication happening. It’s just too much and nobody can ever ask the question “what’s changed in the last week” because it would be a novel.

This isn’t an argument for monoliths vs microservices, because I think that’s just the wrong perspective. It’s an argument to think about your social structure first, and I rarely see this discussed well. Most companies just spin up teams to make a thing and then don’t think about how these teams collaborate, and technical leadership never really questions how the architecture can supplement or block that collaboration until it’s a massive problem, at which point any change is incredibly expensive.