In my own experience (and from everything I’ve read), LLMs as they are today don’t help us as an industry build a higher mountain of software because they don’t help us deal with complexity — they only help us build the mountain faster.
I see this response a lot but I think it's self-contradictory. Building faster, understanding faster, refactoring faster — these do allow skilled developers to work on bigger things. When it takes you one minute instead of an hour to find the answer to a question about how something works, of course that lets you build something more complex.
Could you say more about what you think it would look like for LLMs to genuinely help us deal with complexity? I can think of some things: helping us write more and better tests, fewer bugs, helping us get to the right abstractions faster, helping us write glue code so more systems can talk to each other, helping us port things to one stack so we don't have to maintain polyglot piles of stuff (or conversely helping us not worry about picking and choosing the best stuff from every language ecosystem).
- Surround yourself with friends who also aren’t playing the game.
- Get really clear about what your actual financial goals are, not what they’d need to be in order to maintain status among game-players.
- Get compensated in ways other than money. For me, working four days a week instead of five, and working remote from anywhere, is worth a whole lot of money. And working at a smaller company is a hell of a lot more fun if you like being part of product decisions.
- If you can, find ways to do things that your ladder-climbing friends can’t do. Spend a month in Europe without taking any holiday. Spend the whole winter in Thailand. Use that extra mental energy from that day off to do something amazing.
I left FAANG about 10 years ago and took a massive pay cut. I’d do it again.
I read it during a journey that ended up leading me out of religion. That book showed me so clearly how strange it is to believe in supernatural events.
This piqued my curiosity. Are you the author of the paper?
For this principle to become widely known, it needs to be communicated in a more succinct way. 400 pages is too much to ask people to invest.
Even so, as far as I understand the gist of what the paper says, the principle helps make explicit some intuition I’ve had about design for a long time.
It sounds like a retake/elaboration on the "Commonality and Variability Analysis" used in Domain Engineering and employed in "Family-Oriented Abstraction, Specification and Translation" (FAST) software engineering methodology.
I’m not one for conspiracy theories, but since SpaceX is the only launch services provider that could actually put one of these in orbit, this smells a lot like hyperloop to me — an unserious proposal that serves as a distraction and furthers Musk’s aims, and benefits anyone who can get close enough to the piles of cash that VCs will drop on this.
You know what’s easier and cheaper than putting a data center in space? Putting one literally anywhere else other than space.
> sometimes the people you are working for are incapable of reasoning about planning artefacts or understanding how the system will look or operate simply from a document
I’m wrestling with this now. Over my career I’ve seen a strong correlation between good writers and good software engineers, but not everyone fits this mold. Shorter cycles and more chances for communication and feedback are helpful here.
I’m currently fighting the “don’t use Gemini to write internal documents” war at my company. It’ll be long and hard, but I think I’ll eventually prevail.
Every time someone throws a document written by AI at me, it feels so disrespectful.
> "The single biggest problem in communication is the illusion that it has taken place."
Love this! Corollary: when you have too many meetings, that’s easy to notice. When you don’t have enough meetings, that’s harder to notice.
I’m in the process of carefully adding meetings and process to our small team of 6 (we had a PM from a large company drop in a few years ago and haphazardly add a bunch of process, and it didn’t really help).
We’re fully remote and have a daily huddle and, on average, 1 hour of meetings a week. It turns out this isn’t enough. So far, each bit of communication we’ve added has resulted in better outcomes and higher morale because we feel more like a team.
I agree that the days when “everyone” watched the same show are done. But if you can find a small group to watch a show with (better in person), then there are better shows available for that experience these last several years, even if the average quality has gone down.
What are some of your favorite shared experiences to replace tv?
We’re in the middle of this right now. Go makes this easier: there’s a go CLI command that you can use to list a package’s dependencies, which can be cross-referenced with recent git changes. (duplicating the dependency graph in another build tool is a non-starter for me) But there are corner cases that we’re currently working through.
This, and if you want build + deploy that’s faster than doing it manually from your dev machine, you pay $$$ for either something like Depot, or a beefy VM to host CI.
A bit more work on those dependency corner cases, along with an auto-sleeping VM, should let us achieve nirvana. But it’s not like we have a lot of spare time on our small team.
* In addition, you can make your life a lot easier by just making the whole repo a single Go module. Having done the alternate path - trying to keep go.mod and Bazel build files in sync - I would definitely recommend only one module per repo unless you have a very high pain tolerance or actually need to be able to import pieces of the repo with standard Go tooling.
> a beefy VM to host CI
Unless you really need to self-host, Github Actions or GCP Cloud Build can be set up to reference a shared Bazel cache server, which lets builds be quite snappy since it doesn't have to rebuild any leaves that haven't changed.
reply