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.
There are a lot of mid-sized companies identified in the book _Hidden Champions of the 21st Century_. I just started the book, but it's exactly the ethos you're talking about here: these companies just focus on a niche, tend to sell to other businesses, and just stay doing this thing profitably, absolutely dominating their niche with razor focus.
I'm reading this book because, well, that's the kind of place I'd like to work. I think it makes sense to get a feel for how these places think, in order to really identify job opportunities
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.
> At this precise moment in time, if anybody seriously thought the above was the way the process works or should work, they should be advocating for firing all the juniors and replacing them with LLMs.
Sadly, I think this is happening at some places. Like Salesforce. Sigh
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.
You do realize you linked to a discontinued product that costs over $5k?
This is what I actually expect to happen to the table saw market - they all become expensive, and the sub-$1k market (which is huge) goes away. Yes, you can find an RAS but it's about 10x the price of what they used to be.
So I stand by my statement: they're effectively non-existent, demand is gone after the 2001 recall by Craftsman, and most of the major manufacturers have stopped producing them. I expect the same thing to happen to table saws.
The cynical take is more that it's crappy blade guards that nobody uses that really should be improved, and it's not necessary to mandate SawStop-style blade breaking technology.
Bascially, mandating the more expensive blade brakes instead of standards around blade guards will eliminate cheap table saws from the market. And yes, this has happened before with radial arm saws - they are now basically non-existent in the US.
So it definitely benefits SawStop to give away this patent, as their saws will look a hell of a lot "cheaper" than competition.
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.
Location: Spokane, WA
Remote: Yes
Willing to relocate: No
Technologies: Cloud and on prem distributed services, mostly AWS, some k8, largely Java services, some big data using Kinesis, PostgreSQL, Redis, DynamoDB, Elasticsearch
Résumé/CV: https://www.linkedin.com/in/tristanjuricek/details/experienc...
Email: [email protected]
The challenge when I see posts like this is the people in charge of building this "check it all in" ecosystem usually forget about the developer experience and basically just implement a CI system. Cool, you can 're-run' an old build cleanly, which is good, but not enough.
How about commercial IDEs? Cloud environments? A lot of developer environments these days include a ton of stuff that likely doesn't make sense to check in, usually licensing config is annoying, or because you're relying on runtime services. And all this time engineers spend on their own machines is basically time wasted, which isn't really a great solution to pitch to a business.
Side note: I used to work for Perforce until the private equity sale. If there was a platform to vendor everything like this, it would be Perforce, because you could already do this kind of thing for years. AFAIK not many Perforce customers ever did this, and I don't think it was because Perforce wasn't capable. It's just a subtly wicked problem. Getting this right - just check out and go across different software development stacks - requires a lot of investment. It does look like Perforce has been acquiring many other aspects related to the application lifecycle, so in theory, they should be better positioned to be the "vendor everything on our stack" solution, but I'm not convinced this is going to work out well.
Cloud development environment vendors seem to be the best positioned as a product for solving this problem, because there is less of that "go figure out your DX" aspect left to the customer. But the right CDE would have to have a lot of enterprise-style controls. This is so new that I'm not sure who will get it right first, but my guess is that we'll get to a more "development to delivery" integrated environment, and away from a hodgepodge of tools managed per project.
I’ve noticed that video chats are great when they complement detailed asynchronous communication, e.g., RFC-style doc or a produced video. The best video conference work meetings tend to be: read a doc for 10 mins and then everyone launches into a Q&A. Discussions are usually vastly better; questions are detailed and focused, more people engage, etc.
When companies just try to take, say, a round-robin update meeting and move it online, it’s usually a waste of time. Or a 50 minute presentation where someone’s just winging it with a PowerPoint.
I wouldn’t even bother an online course where they just setup a web camera in class and follow a lecture.
It’s like videoconferencing has gotten so cheap and easy, it allows for sloppy planning and presentation. I dropped several classes in college because the lecturer didn’t bother even learning how to present with a mic, speak clearly, etc.
Companies should just ask for quick anonymous feedback after meetings just to set up an improvement loop.
I've read in multiple places about the tendency to seek out instant gratification on the phone instead of just allowing yourself to get bored, and seek out doing something with other people.
Relying on apps for finding a love connection seems like a facet of this somehow. Instead of spending the time around other people, building up a social circle, most just try to "see what the app brings" because they've just lost the ability to find connections other ways.
I see companies hiring lots of middle management during high-growth phases, as the "plan" is to have them grow their teams. And then the market changes, and headcount targets change, and all of a sudden there's a glut of managers as the headcount target is now completely different.
So, yeah, vulnerable, but mostly because we suck as an industry at understanding and managing people as well as we manage money. If we were good at it, there wouldn't be such over-hiring and layoffs that cause me to see articles like this: https://hbr.org/2022/12/what-companies-still-get-wrong-about...
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”.