I hear this perspective a lot in relation to open source projects.
What it fails to recognize is the reality that life changes. Shit happens. There's no way to predict the future when you start out building an open source project.
(Coming from having contributed to and run several open source projects myself)
The only approach that genuinely works for software development is to treat it as a "bet". There are never any guarantees in software development.
1. Think about what product/system you want built.
2. Think about how much you're willing to invest to get it (time and money).
3. Cap your time and money spend based on (2).
4. Let the team start building and demo progress regularly to get a sense of whether they'll actually be able to deliver a good enough version of (1) within time/budget.
If it's not going well, kill the project (there needs to be some provision in the contract/agreement/etc. for this). If it's going well, keep it going.
The exact same way you'd treat any other investment decision.
In the real world, if you've got $100k, you could choose to invest all of it into project A, or all into project B, or perhaps start both and kill whichever one isn't looking promising.
You'd need to weigh that against the potential returns you'd get from investing all or part of that money into equities, bonds, or just keeping it in cash.
You mean… by making a forward-looking estimates of cost, time-to-value, return? (even if it's implicit, not documented, vibes-based?).
When devs refuse to estimate, it just pushes the estimating up the org chart. Execs still have to commit resources and do sequencing. They’ll just do it with less information.
In my experience, it really depends on what you're building _and_ how you prompt the LLM.
For some things, LLMs are great. For others, they're absolute dog shit.
It's still early days. Anyone who claims to know what they're talking about either doesn't or what they're saying will be out of date in a month's time (including me).
There's something both beautiful/enchanting and deeply tragic about the story.
If anyone's interested in an analysis of Saint-Exupéry's psychology via the symbolism of The Little Prince, the book "The Problem of the Puer Aeternus" by Marie-Louise von Franz [1] is absolutely fascinating.
Yes! I didn't understand why I always found the Little Prince story (and by extension "alchemist") so repulsive, until I read that book. Little prince is aimed at people who have lost their idealistic youth qualities and seek to get back in touch with that part of themselves. I had the opposite problem - I never fully left that place.
Yeah I've gone through bouts of "anything but tech" several times in my career, and each time ended up stuck in software development because it pays the bills.
I'm possibly somewhat burnt out - not entirely sure - but the reason I say so is that it's hard to tell what actually calls to me right now, whereas 5-10 years ago I felt I had a much clearer picture. Nowadays I'm skeptical of the idea that following any passions of mine would result in a better overall quality of life.
It's tough to find something that's both fulfilling _and_ pays the bills. I'm nowhere near "rich", but I'm fairly certain being poor will decrease my quality of life substantially - regardless of how fulfilling my work is. Right now I'm stuck leaning more in the direction of the thing that pays the bills.
In your experience/journey, what tech-adjacent careers have you become aware of? I'd imagine it's easier to pivot into something "tech-adjacent" than something completely different when one is in their 40s/50s.
The open social web's decentralization is just as dependent on relevant protocols and communities as it is on the hosting services on which they depend.
It's way easier to censor a decentralized social network if the majority of its nodes run on AWS, GCP and Azure, for instance.
What'd be great is if we could run these networks primarily from our personal devices (i.e. true edge computing), but the more the computing's pushed to the edge the harder it becomes to implement technically and socially.
nostr can do this. relays are lightweight enough to run on Android devices, Citrine ships one with a nice UI even. It's not p2p or anything but it works well enough to preserve your own note history and there a plans to extend its functionality beyond that.
For this to be long-term sustainable though, it needs to be implemented in such a way that non-tech-savvy folks can also participate very easily, without needing to learn anything about P2P, relays, decentralized or edge computing, etc.
For those of us who've been around for some time and still value privacy, this sort of paradigm is obvious.
The trouble isn't a lack of the right technologies - I'd argue it's a problem in the go-to-market strategy of those building these products/technologies.
Ideas flow along lines carved out by power/influence. Facebook's early strategy was to start with restricting its usage to people at Harvard University - arguably a highly influential institution - and then expand outwards to other highly influential institutions. Only once the "who's who" from those institutions were already onboard did they let down the walls to allow us plebs in, and we all rushed in head-first.
X's current strategy leverages Musk's visibility and influence (for better or worse).
Get the most prominent influencers onboard with your decentralized social network, and others will follow (dramatically easier said than done, of course). But without a significant contingent of influencers/powerful people, your network's DoA.
> prominent influencers onboard with your decentralized social network
That's sort of a contradiction, no? Or at least it assumes transplanting the same mechanisms into a new milieu -- which I argue is something to leave behind, because it's those very mechanisms that have ruined the current internet.
I think instead of tapping into the same addictive attention economy schemes, the distributed / decentralized socials could onboard people en-masse by providing what's missing there, and filling a real need.
Even if they fill a real need, their go-to-market strategy will determine whether the masses even know about them, or give a damn about trying them out in the first place.
> A lot of engineers design by trying to think of the “ideal” system: something well-factored, near-infinitely scalable, elegantly distributed, and so on.
> Instead, spend that time understanding the current system deeply, then do the simplest thing that could possibly work.
I'd argue that a fair amount of the former results in the ability to do the latter.
There's a substantial amount of wisdom that goes into designing "simple" systems (simple to understand when reading the code). Just as there's a substantial amount of wisdom that goes into making "simple" changes to those systems.
reply