One of the most nonsensical things I have read on here in a long time.
Software is not like a tv show or a stand up comedy set or an album. It is not a cultural artifact. It is machinery.
We don’t really get bored of a bread slicer. A school bus does not become tiresome. “My french press, it lacks its initial spark!”
Machines break, or fall behind evolving requirements (e.g. the bus only takes leaded gas). These are functional shortcomings. The idea of somehow withdrawing a functional useful piece of software from society does not make much sense. There are copies out there, first of all. What are you going to do, hunt them all down? You can stop maintaining it but in many cases, you can’t even prevent other people from working on it. Do you think even Larry Ellison could kill the Oracle database?
> “ One of the most nonsensical things I have read on here in a long time.”
at risk of sounding arrogant, maybe you missing important experience so this not resonate with you.
me time in big tech had many teams or even orgs focused on adding features to some legacy product or service.
product managers pitched doing X or Y as big wins for customer experience. managers, directors, and vps all got onboard.
so you have service that does X. it do it very well. you can put two people to support it and have rest of people focus on next innovation. instead, you take team of 9 people including 2-3 managers and engineers do some marginal improvement.
you add layers of new abstraction or helper services. you operational footprint and cost goes up. you do some tiny marginal improvement. it like you have steak house and with this 1 year effort, imagine chefs can save 50 millisecond on time to season a steak. do it really help you make more money or improve customer experience? no. honestly it fake work.
software not have to end like tv show. but you reach maturity level where now people doing things for political reason, to justify headcount, because they need complexity to demonstrate promotion requirement. all the wrong reasons. root causes many: over hiring.. obsession with growth..empire building..promotion. instead of next true innovation just adding duct tape and doing work with no value for you real customer.
knowing when to stop and refocus is key skill and having focus to do in large organization very hard. need founder like entrepreneur business person mindset and strong influence or top down leadership mandate to stop the nonsense.
> "so you have service that does X. it do it very well. you can put two people to support it and have rest of people focus on next innovation. instead, you take team of 9 people including 2-3 managers and engineers do some marginal improvement.
you add layers of new abstraction or helper services. you operational footprint and cost goes up. you do some tiny marginal improvement. it like you have steak house and with this 1 year effort, imagine chefs can save 50 millisecond on time to season a steak. do it really help you make more money or improve customer experience? no. honestly it fake work."
I think you are mixing up three things:
- 1. A feature being done "X works very well".
- 2. Scope of software "When is Product Y that does X finished?"
- 3. Politics/Software mistakes "Does this software suck because it was written by monkeys or because our pointy haired boss gave us some expensive crapware"
1. Is a matter of philosophy. Unix one is that a tool does one job, does it well, then it is finished. I think this is the real "being done", the OP's post is so much nonsense. It works, it keeps working, in absence of a better tool, it doesn't make sense to re-invent the wheel. Even if you do (invent flight, e.g.), not all use cases make sense for flight (delivering goods by rail is much more efficient and less error prone than any drone fleet could ever hope for, at least over distance).
You do lose some convenience, if you want a hole borer you could either use a screwdriver (or similar) and a hammer, or you could buy or build some fancy pneumatic tool, but really, how many hole borers do you want to buy (concrete vs wood vs acrylic)? The urge to put everything into one product is the mistake - it saves some time up front, but it really only makes sense when you have the persistent and constant need at scale - in my example, maybe if you are building houses, but not for someone who just wanted to do a repair or make some wood furniture.
2. The scope of the software, is defined in part by its philosophy, but in the end it ends up having one, and generally being better at a couple things versus terrible at a bunch of things is the difference between a successful product and dead product. Think of Windows, or Mac OS - the former is good at video games (for a variety of reasons), otherwise besides momentum it doesn't have much going for it. The latter too - its good at video/photos and great at creating iOS apps. Otherwise it too doesn't have a whole lot going for it. Not to leave out the third, Linux, its good at configurability, and great at being a server/embedded OS, otherwise there's a whole lot of reasons its not so great.
What is the scope of the scope? Well that's called having a feature set, being able to release. If you engineered well, there is little long term support. Or if there are technology changes/upgrades, then support is required as well. This affects large and small apps, regardless of philosophy - OFC large apps seem to change frequently, but even small ones get security upgrades, bug-fixes, even occasionally new features if the use is common enough.
3. Deciding what goes where and who does what, that's politics, not software. Even the act of a team of engineers working on a project, is cause for politics. But that's still just what some humans did, and it doesn't necessarily reflect reality. Sure, some product probably gets bloated some busy work happens, but if you can still use the (old) software, that doesn't matter. At least until it stops become possible to safely use, the software is fine.
Besides, for open source projects at least, when this time (inevitably) comes, the point of the license is to allow for forking, restarting with something that still works or recently did work.
I think the only time I can justify this sort of "just throw it away" behavior, is for when you have a closed source, decades old piece of software which cannot be modified. Even with proprietary software, you can re-use source or binary components. Even for non-modular monolithic code-bases, you can extract business logic, utilities, etc, pretty much the only time this is not possible is in case of direct or indirect obfuscation, and even then it is usually not of possibility but of practical cost.
When you attempt to re-build the project from scratch, you may attempt to start from simpler principles, usually to either run into the same bugs, (re) discover your set of principles is incomplete, or simply find yourself rebuilding the same solution, maybe with a face lift, or running on the latest and greatest platform.
> Software is not like a tv show or a stand up comedy set or an album. It is not a cultural artifact. It is machinery.
You get two things wrong here imo, though I'm not saying the article is great.
1. A lot of software is a cultural artifact. For instance, anything with a user interface we can become nostalgic for. See: pretty much all pop art like Warhol. Video games are another example.
2. It's the humans quitting, not the machinery. If a school bus driver gets tired of driving the bus, the bus has to stop until another driver is found. The same is true of a lot of software, especially open source.
Is not as true as you think, the common reasons for software to "die":
1. The platform is not made anymore - we use different processors, hard-drives. A hard drive fails and a replacement can't be bought, or a PSU blows and the motherboard/processor are irrevocably damaged.
2. The software production infrastructure disappears - some core library updates, some set of dependent dependencies cannot be (easily) rebuilt.
Software (MMOs in particular) can also die for social reasons, or manufactured ones (Windows discontinuing Pinball in newer OS versions). I would argue though, although some humans are doing some quitting (not supporting, trashing something early), for those downstream, it is as if the machinery had started quitting.
Humans abandoning useful tools is fairly rare, evidenced even in recent memory with users of Adobe CS2/CS3 still running their (legally purchased) software even as Adobe sends out unlawful and libelous letters/emails...
> Machines break, or fall behind evolving requirements
Requirements now evolve so fast that a "functional useful piece of software" without a maintainer will become useless in about 5 years. Imagine trying to compile a project you haven't touched in 5 years. I know for a fact that even Go, which offers arguably the strongest backward compatibility guarantees out there, wouldn't compile my employer's codebase from 5 years ago.
That's why I've basically quit software. The vast (vast) majority of the code I've written over the past three decades is useless. It is no longer used, and it could not be used even if someone wanted to use it. It's obsolete, because all the underpinnings have moved on. It's sort of depressing to be in the final years of my career and be able to point to nothing that I've created. I'm still working but I've quit learning new frameworks or languages. It used to be fun, now it's just tiring and seems pointless.
Highly misleading. I've compiled plenty of older Go code. It just seems like you don't know how to deal with Go code, unless it's been nicely packaged as a module with go.mod
You and I may have read the article somewhat differently. I felt his concluding example was out of harmony with the article, and much more similar to what you're saying. But his early argument was largely that it's OK for a French press to be done. That it's okay, and even good, for a French press to just be a French press. It doesn't mean you can't go buy Seinfeld on blu-ray, it just means that Seinfeld is done.
Instead many commercial ventures that make a metaphorical French press instead insist on trying "expand" that French press. Next thing you know it has self insulation, then a new fancy self-plunging pneumatic plunger, and then it becomes an online service, and why not connect your new French process to your friends' French presses, and now your French press has streaming video, now in 4k!, and so on endlessly.
At some point you just want your French press back. The examples of this in software are endless especially with endless efforts to turn everything into a service to try to extract rent. And the exact same is also happening in the machine world. Note the recent big news about farmers now being "granted" the right to repair their own tractors - just like they had 20 years ago. Things often become worse over time when companies refuse to just let them be done, but our economic system poses a major deterrence to ever finishing anything.
I think you missed the unspoken point of the article. The Seinfeld interview in particular is excellent, and maybe the best example of the last twenty years of "leaving on top". King honestly thought they were cancelled, because even then "ending early" was unheard of.
The point is that people get tired, they lose motivation, or they just feel that it's good enough. They lay down the gauntlet for the next programmers. Not in earnest, but in resignation.
And I disagree that Seinfeld ended early. I think what happened is exactly what he was trying to avoid, "‘It was good but then it started to kinda run out of gas…‘" The last season was not great.
It easily could have been worse though. They had enough momentum for another season or two at least if they had wanted to milk it.
Highly agree here! Software is more or less a service albeit it being an high automated one or software leveraged service. I call it a service not a product because it takes man power to keep it running and would stop if we stop paying the monthly server and domain fees. Furthermore, because web technology and evergreen browsers are a thing we constantly need to be vigilant for changing standards and interpretations of the same output.
I stop telling my clients that they pay us to build and buy, but it’s build and maintain afterwards.
That always raises a few questions as building in one way versus the other can lead to higher or lower levels of costs in that maintenance phase.
And, it can’t be cost effectively decoupled. Some governmental agencies think that these are separate services and should be acquired through two different bidding processes, that seems to be a bad idea as small updates will be cheap for those that know the underlying mechanics of the project but expensive for a third party.
Renato Carosone (singer of Tu vuò fà l'americano) quit at his peak:
> At the height of his career, Carosone announced his retirement from music in 1960. He felt that the advent of Rock and roll had the consequence of making his swing, big-band sound no longer popular: "I'd rather retire now on the crest of the wave, than being tormented later by the idea of rock and roll wiping away all that I have achieved in so many years of hard work".
>Who cares how popular your art is, as long as it pays the bills?
every artist, ever?
it's a pretty common idea that artists should embrace the passion for the art rather than 'mundane and earthly reason'. That isn't to say that represents practical reality, but 'artistry' is one of the few categories of human endeavor where passion is encouraged by society to be followed almost to the detriment of the artist themselves.
we remember the stories of half-starved artists, stuck & starving on the streets and patroned by kings for one last hurrah ; we tend not to remember the artists stuck in corporate buildings that churn out cartoon cels in order to meet deadlines and quotas.
> It feels like our culture’s impulse is to wring every last cent possible out of any creative endeavor — or at least leave open the possibility for more from the outset.
It's easy to criticize other people for wanting to ride their success after they've peaked
But I can't really blame them. We only get so many big wins in our lifetime. When someone hits on something successful, riding it as far as they possibly can makes a lot of sense.
Some people get lucky and hit success with different ventures throughout their lives, but I suspect most successful people may only get a small number of opportunities to capitalize on. Seize them while you can. Ignore the critics.
It's also about what is "success" at different scaling. People can enjoy different levels of success at different stages and not always chase the same big targets. I remember seeing an interview with a band that had some major hits in the 80s (the Fixx) whose members effectively have day jobs now, but they still successfully tour smaller clubs every year or other year, and do things at a scale they can manage, still make money at, and thoroughly enjoy.
They get to be what they enjoy, and make a living at. The fact that they arent playing arenas/on MTVs equivalent/etc is orthogonal to that.
I think there's a big difference between "quitting" and "finishing up / wrapping up" in terms of walking away from something.
"Quitting" to me implies "abandonment" or leaving before you're mentally ready to leave. For example closing a startup or product because of a lack of product market fit, or stopping a knitting project because you don't have time for it, but really want to finish it.
"Wrapping up" to me means the thing has reached its natural end, and you're happy to leave. For the startup or product, it could mean you've hit your "one year anniversary" of trying to see if you could make it while giving your best shot. For the knitting project, it might mean you've found more fun projects (or hobbies) and you don't have time/effort/energy to pour into the project anymore.
In the end though there's just a subtle mental shift to how you think about the thing you're working on, and really it comes down to your mental model, incentive, and amount of "closure" you've given it.
There might mixes of “quitting” and “wrapping up” when as a contributor to something, you feel you earnestly committed to it, and there’s not much more you can do to bring it further in the direction you wish it goes.
You might not be moving away on your terms, but you won’t have regrets either.
The OP is in part a reflection on the sunset of the Go Gorilla package. The blog post about that which it links to at the end is very much worth a read (I didn't know about it, or the fate of the Gorilla package, before getting linked to it here), and I'd actually love to see an HN thread about THAT one!
Looks like that's been submitted to HN, but never got traction.
It has the somewhat misleading title "There is no secure software supply-chain," which probably didn't help it's HN votes on previous submissions. It's really about the maintainers deciding to sunset Gorilla, in the context of that being a good idea to prevent it from becoming an insecure untrustworthy dependency, but more than that too. I found it a very thought-provoking read, and would love to hear others responses to it, including folks from Go community but also on the general issues.
I would love to continue the conversation: I think it's a really important topic in the world of increasingly deep dependencies. I too hadn't heard of the Gorilla maintainers reaching out for new contributors or sun-setting the project until after the fact.
> That movie was pretty good, but it would’ve been great if it had been thirty minutes shorter.
For me the canonical example of a movie that didn't know when to quit was A.I. Artificial Intelligence. There were at least four points in the movie when I firmly thought to myself, this would be a good point to end the movie. And then the movie just ... kept on going. On and on and on. I understand that Spielberg took it upon himself to remain faithful to the original Kubrick/Watson treatment, but you can just hear him screaming in the background "can't we just end here?" as well.
You know, I used to agree; I watched the movie again recently though and I've come around on the future-robots stuff at the end.
The movie should definitely have been edited down, but I think the point of the movie is that David was determined to become a "real boy" the entire movie, and fundamentally the way that that could happen is that he does the most human thing of all: die. He's given one perfect day with his mother, and ends knowing that he truly is a "real boy".
For me it's The Simpsons. I made the mistake of looking at a few episodes lately. It had the barest of wit, no whimsy, little inventiveness. Made me sad.
And every time I think of the latest watery Avatar -- AARGH. It was ... nothing but some nice scenes and some shoot em up.
I stopped watching The Simpsons around season 15, and I feel like I held on a lot longer than I should have. The jokes became a lot less clever, usually devolving into "LOL RANDOM HAHA HOMER DUMB!", which to be fair seemed to be popular with most cartoons of the mid 2000's.
I thought maybe I just outgrew it, but recently I watched a lot of the earlier seasons, and no, they still hold up.
Same for the 100 endings of LOTR that were completely unnecessary. You cant fake being faithful to the books if you dont even include the scouring of the Shire. Worst endings ever.
I can't agree. Even viewed as a single film (Tolkien viewed LotR more as one big book, and the movies reflect that), in the 3:20 movie (3:10 before the "The End" screen) there's only 20 minutes between Frodo getting grabbed by the Eagle and that "The End" screen. I think the movie needed all of that 20 minutes of catharsis. I absolutely think the 9-10 hour trilogy as a whole needed that 20 minutes.
The math looks even better with the extended editions, where that 20 minute ending is only about 22 minutes, where the single movie is an hour longer, and the trilogy is ~3 longer.
Lord of the Rings was great in general. However, the actual ending was in an appendix and the scouring of the shire was an unnecessary epilogue in the actual book. It was a great fantasy series but it was also a bit of a mess at the end. Faithful to the books should never be a primary goal of film.
A really good book on this topic I recently read: Quit, by Annie Duke.
The book boils down to "Calculate EV of your decision, try not to fall prey to sunk cost fallacy". But it makes the lesson really sink in which is nice.
My favorite bit was her sharing the research that you cannot avoid sunk cost fallacy. Humans don't work that way it seems. What you can do instead is to pre-commit to quitting when certain conditions are met.
She argues for including emotional factors in the EV calculation.
"Will this make me feel good" is a question of value.
An example she uses is a person who's miserable at their job and is trying to decide whether to take a job offer. They know they'll be miserable without changing jobs, but taking the new job might feel better. Therefore you should change jobs because the expected value of changing is higher than the expected value of staying.
I've told some young people in mentor/mentee situations before: Knowing when to quit is a useful skill ONLY IF you also possess superior judgement about what you might stand to gain by remaining, and data to support the decision either way. If you know you can land the better job, or even have a better offer, THAT is the situation where you need to know when to quit. If you have no leads and you're trying to break into a competitive space but could probably climb the ladder where you are up a few rungs in 2-5yrs, then sometimes it just pays to stay and grind it out a little.
I think sometimes uncertainty is misrepresented a little bit. I've been blessed to be able to make my own prices and so I don't really have to job-hop, but any moron with a brain can see that it's better over a long period of time to change jobs more often rather than less. It's just good sense at this point. Still, with that being said, when you're facing incomplete data, it's easy to let anxiety overrule the fact that your present employment, shitty as it may seem, shitty as it may feel to punch in and see the smug, passive, whatever it is you hate about your coworkers' faces, it's a steady job.
I've made mistakes where I jumped too soon, and where I've jumped too late or not at all. Personally, I regret the ones where I jumped too soon a lot more because I associate those decisions with low resilience to frustration I had, and low discipline to exert my patience further. Maybe I'm wrong, but looking back on several decades of fucking things up in professional environments, that's the way I feel.
If anybody is reading this and thinking about how much they hate their jobs, I could not more strongly advise you to hold the course for now unless you have an absolute certainty in hand, if you're in the United States especially. I've lived in DC for many years now, and it feels more tense and nervous now than 2002 and 2008-9 put together.
Free your mind, do what you have to do, but don't jump ship with clouds like these on the horizon. Just wait a little bit, and see what happens first.
> because I associate those decisions with low resilience to frustration I had, and low discipline to exert my patience further
Absolutely this. You’re always going to end up in testing environments somewhere so it’s good to practice both patience and resilience. The more you train that muscle the easier it becomes to work in those situations.
Great post, thanks for the perspective. Retrospectively I also regret one of my job changes due to that low resilience to frustration.
TBF i still believe i had little promising future there independent on how good the place was, but i should have waited a little bit more to confirm it.
Readit News
Software is not like a tv show or a stand up comedy set or an album. It is not a cultural artifact. It is machinery.
We don’t really get bored of a bread slicer. A school bus does not become tiresome. “My french press, it lacks its initial spark!”
Machines break, or fall behind evolving requirements (e.g. the bus only takes leaded gas). These are functional shortcomings. The idea of somehow withdrawing a functional useful piece of software from society does not make much sense. There are copies out there, first of all. What are you going to do, hunt them all down? You can stop maintaining it but in many cases, you can’t even prevent other people from working on it. Do you think even Larry Ellison could kill the Oracle database?
at risk of sounding arrogant, maybe you missing important experience so this not resonate with you.
me time in big tech had many teams or even orgs focused on adding features to some legacy product or service.
product managers pitched doing X or Y as big wins for customer experience. managers, directors, and vps all got onboard.
so you have service that does X. it do it very well. you can put two people to support it and have rest of people focus on next innovation. instead, you take team of 9 people including 2-3 managers and engineers do some marginal improvement.
you add layers of new abstraction or helper services. you operational footprint and cost goes up. you do some tiny marginal improvement. it like you have steak house and with this 1 year effort, imagine chefs can save 50 millisecond on time to season a steak. do it really help you make more money or improve customer experience? no. honestly it fake work.
software not have to end like tv show. but you reach maturity level where now people doing things for political reason, to justify headcount, because they need complexity to demonstrate promotion requirement. all the wrong reasons. root causes many: over hiring.. obsession with growth..empire building..promotion. instead of next true innovation just adding duct tape and doing work with no value for you real customer.
knowing when to stop and refocus is key skill and having focus to do in large organization very hard. need founder like entrepreneur business person mindset and strong influence or top down leadership mandate to stop the nonsense.
you add layers of new abstraction or helper services. you operational footprint and cost goes up. you do some tiny marginal improvement. it like you have steak house and with this 1 year effort, imagine chefs can save 50 millisecond on time to season a steak. do it really help you make more money or improve customer experience? no. honestly it fake work."
I think you are mixing up three things:
- 1. A feature being done "X works very well". - 2. Scope of software "When is Product Y that does X finished?" - 3. Politics/Software mistakes "Does this software suck because it was written by monkeys or because our pointy haired boss gave us some expensive crapware"
1. Is a matter of philosophy. Unix one is that a tool does one job, does it well, then it is finished. I think this is the real "being done", the OP's post is so much nonsense. It works, it keeps working, in absence of a better tool, it doesn't make sense to re-invent the wheel. Even if you do (invent flight, e.g.), not all use cases make sense for flight (delivering goods by rail is much more efficient and less error prone than any drone fleet could ever hope for, at least over distance).
You do lose some convenience, if you want a hole borer you could either use a screwdriver (or similar) and a hammer, or you could buy or build some fancy pneumatic tool, but really, how many hole borers do you want to buy (concrete vs wood vs acrylic)? The urge to put everything into one product is the mistake - it saves some time up front, but it really only makes sense when you have the persistent and constant need at scale - in my example, maybe if you are building houses, but not for someone who just wanted to do a repair or make some wood furniture.
2. The scope of the software, is defined in part by its philosophy, but in the end it ends up having one, and generally being better at a couple things versus terrible at a bunch of things is the difference between a successful product and dead product. Think of Windows, or Mac OS - the former is good at video games (for a variety of reasons), otherwise besides momentum it doesn't have much going for it. The latter too - its good at video/photos and great at creating iOS apps. Otherwise it too doesn't have a whole lot going for it. Not to leave out the third, Linux, its good at configurability, and great at being a server/embedded OS, otherwise there's a whole lot of reasons its not so great.
What is the scope of the scope? Well that's called having a feature set, being able to release. If you engineered well, there is little long term support. Or if there are technology changes/upgrades, then support is required as well. This affects large and small apps, regardless of philosophy - OFC large apps seem to change frequently, but even small ones get security upgrades, bug-fixes, even occasionally new features if the use is common enough.
3. Deciding what goes where and who does what, that's politics, not software. Even the act of a team of engineers working on a project, is cause for politics. But that's still just what some humans did, and it doesn't necessarily reflect reality. Sure, some product probably gets bloated some busy work happens, but if you can still use the (old) software, that doesn't matter. At least until it stops become possible to safely use, the software is fine.
Besides, for open source projects at least, when this time (inevitably) comes, the point of the license is to allow for forking, restarting with something that still works or recently did work.
I think the only time I can justify this sort of "just throw it away" behavior, is for when you have a closed source, decades old piece of software which cannot be modified. Even with proprietary software, you can re-use source or binary components. Even for non-modular monolithic code-bases, you can extract business logic, utilities, etc, pretty much the only time this is not possible is in case of direct or indirect obfuscation, and even then it is usually not of possibility but of practical cost.
When you attempt to re-build the project from scratch, you may attempt to start from simpler principles, usually to either run into the same bugs, (re) discover your set of principles is incomplete, or simply find yourself rebuilding the same solution, maybe with a face lift, or running on the latest and greatest platform.
You get two things wrong here imo, though I'm not saying the article is great.
1. A lot of software is a cultural artifact. For instance, anything with a user interface we can become nostalgic for. See: pretty much all pop art like Warhol. Video games are another example.
2. It's the humans quitting, not the machinery. If a school bus driver gets tired of driving the bus, the bus has to stop until another driver is found. The same is true of a lot of software, especially open source.
Is not as true as you think, the common reasons for software to "die":
1. The platform is not made anymore - we use different processors, hard-drives. A hard drive fails and a replacement can't be bought, or a PSU blows and the motherboard/processor are irrevocably damaged.
2. The software production infrastructure disappears - some core library updates, some set of dependent dependencies cannot be (easily) rebuilt.
Software (MMOs in particular) can also die for social reasons, or manufactured ones (Windows discontinuing Pinball in newer OS versions). I would argue though, although some humans are doing some quitting (not supporting, trashing something early), for those downstream, it is as if the machinery had started quitting.
Humans abandoning useful tools is fairly rare, evidenced even in recent memory with users of Adobe CS2/CS3 still running their (legally purchased) software even as Adobe sends out unlawful and libelous letters/emails...
Requirements now evolve so fast that a "functional useful piece of software" without a maintainer will become useless in about 5 years. Imagine trying to compile a project you haven't touched in 5 years. I know for a fact that even Go, which offers arguably the strongest backward compatibility guarantees out there, wouldn't compile my employer's codebase from 5 years ago.
Instead many commercial ventures that make a metaphorical French press instead insist on trying "expand" that French press. Next thing you know it has self insulation, then a new fancy self-plunging pneumatic plunger, and then it becomes an online service, and why not connect your new French process to your friends' French presses, and now your French press has streaming video, now in 4k!, and so on endlessly.
At some point you just want your French press back. The examples of this in software are endless especially with endless efforts to turn everything into a service to try to extract rent. And the exact same is also happening in the machine world. Note the recent big news about farmers now being "granted" the right to repair their own tractors - just like they had 20 years ago. Things often become worse over time when companies refuse to just let them be done, but our economic system poses a major deterrence to ever finishing anything.
The point is that people get tired, they lose motivation, or they just feel that it's good enough. They lay down the gauntlet for the next programmers. Not in earnest, but in resignation.
It easily could have been worse though. They had enough momentum for another season or two at least if they had wanted to milk it.
I stop telling my clients that they pay us to build and buy, but it’s build and maintain afterwards.
That always raises a few questions as building in one way versus the other can lead to higher or lower levels of costs in that maintenance phase.
And, it can’t be cost effectively decoupled. Some governmental agencies think that these are separate services and should be acquired through two different bidding processes, that seems to be a bad idea as small updates will be cheap for those that know the underlying mechanics of the project but expensive for a third party.
> At the height of his career, Carosone announced his retirement from music in 1960. He felt that the advent of Rock and roll had the consequence of making his swing, big-band sound no longer popular: "I'd rather retire now on the crest of the wave, than being tormented later by the idea of rock and roll wiping away all that I have achieved in so many years of hard work".
(https://en.m.wikipedia.org/wiki/Renato_Carosone#Retirement)
That quote has stuck with me.
every artist, ever?
it's a pretty common idea that artists should embrace the passion for the art rather than 'mundane and earthly reason'. That isn't to say that represents practical reality, but 'artistry' is one of the few categories of human endeavor where passion is encouraged by society to be followed almost to the detriment of the artist themselves.
we remember the stories of half-starved artists, stuck & starving on the streets and patroned by kings for one last hurrah ; we tend not to remember the artists stuck in corporate buildings that churn out cartoon cels in order to meet deadlines and quotas.
It's easy to criticize other people for wanting to ride their success after they've peaked
But I can't really blame them. We only get so many big wins in our lifetime. When someone hits on something successful, riding it as far as they possibly can makes a lot of sense.
Some people get lucky and hit success with different ventures throughout their lives, but I suspect most successful people may only get a small number of opportunities to capitalize on. Seize them while you can. Ignore the critics.
However, riding something to failure taints that legacy. As the saying goes, always leave them wanting something more.
They get to be what they enjoy, and make a living at. The fact that they arent playing arenas/on MTVs equivalent/etc is orthogonal to that.
"Quitting" to me implies "abandonment" or leaving before you're mentally ready to leave. For example closing a startup or product because of a lack of product market fit, or stopping a knitting project because you don't have time for it, but really want to finish it.
"Wrapping up" to me means the thing has reached its natural end, and you're happy to leave. For the startup or product, it could mean you've hit your "one year anniversary" of trying to see if you could make it while giving your best shot. For the knitting project, it might mean you've found more fun projects (or hobbies) and you don't have time/effort/energy to pour into the project anymore.
In the end though there's just a subtle mental shift to how you think about the thing you're working on, and really it comes down to your mental model, incentive, and amount of "closure" you've given it.
There might mixes of “quitting” and “wrapping up” when as a contributor to something, you feel you earnestly committed to it, and there’s not much more you can do to bring it further in the direction you wish it goes.
You might not be moving away on your terms, but you won’t have regrets either.
https://onengineering.substack.com/p/there-is-no-secure-soft...
Looks like that's been submitted to HN, but never got traction.
It has the somewhat misleading title "There is no secure software supply-chain," which probably didn't help it's HN votes on previous submissions. It's really about the maintainers deciding to sunset Gorilla, in the context of that being a good idea to prevent it from becoming an insecure untrustworthy dependency, but more than that too. I found it a very thought-provoking read, and would love to hear others responses to it, including folks from Go community but also on the general issues.
There was some good discussion on the /r/programming subreddit: https://www.reddit.com/r/programming/comments/zyf9rb/there_i...
I would love to continue the conversation: I think it's a really important topic in the world of increasingly deep dependencies. I too hadn't heard of the Gorilla maintainers reaching out for new contributors or sun-setting the project until after the fact.
For me the canonical example of a movie that didn't know when to quit was A.I. Artificial Intelligence. There were at least four points in the movie when I firmly thought to myself, this would be a good point to end the movie. And then the movie just ... kept on going. On and on and on. I understand that Spielberg took it upon himself to remain faithful to the original Kubrick/Watson treatment, but you can just hear him screaming in the background "can't we just end here?" as well.
The movie should definitely have been edited down, but I think the point of the movie is that David was determined to become a "real boy" the entire movie, and fundamentally the way that that could happen is that he does the most human thing of all: die. He's given one perfect day with his mother, and ends knowing that he truly is a "real boy".
And every time I think of the latest watery Avatar -- AARGH. It was ... nothing but some nice scenes and some shoot em up.
I thought maybe I just outgrew it, but recently I watched a lot of the earlier seasons, and no, they still hold up.
Deleted Comment
The math looks even better with the extended editions, where that 20 minute ending is only about 22 minutes, where the single movie is an hour longer, and the trilogy is ~3 longer.
The book boils down to "Calculate EV of your decision, try not to fall prey to sunk cost fallacy". But it makes the lesson really sink in which is nice.
My favorite bit was her sharing the research that you cannot avoid sunk cost fallacy. Humans don't work that way it seems. What you can do instead is to pre-commit to quitting when certain conditions are met.
https://overcast.fm/+k1HEhCB1U
the point of life is whatever you make it
for most a focus on rigid logical thinking is a recipe for doom
"Will this make me feel good" is a question of value.
An example she uses is a person who's miserable at their job and is trying to decide whether to take a job offer. They know they'll be miserable without changing jobs, but taking the new job might feel better. Therefore you should change jobs because the expected value of changing is higher than the expected value of staying.
I think sometimes uncertainty is misrepresented a little bit. I've been blessed to be able to make my own prices and so I don't really have to job-hop, but any moron with a brain can see that it's better over a long period of time to change jobs more often rather than less. It's just good sense at this point. Still, with that being said, when you're facing incomplete data, it's easy to let anxiety overrule the fact that your present employment, shitty as it may seem, shitty as it may feel to punch in and see the smug, passive, whatever it is you hate about your coworkers' faces, it's a steady job.
I've made mistakes where I jumped too soon, and where I've jumped too late or not at all. Personally, I regret the ones where I jumped too soon a lot more because I associate those decisions with low resilience to frustration I had, and low discipline to exert my patience further. Maybe I'm wrong, but looking back on several decades of fucking things up in professional environments, that's the way I feel.
If anybody is reading this and thinking about how much they hate their jobs, I could not more strongly advise you to hold the course for now unless you have an absolute certainty in hand, if you're in the United States especially. I've lived in DC for many years now, and it feels more tense and nervous now than 2002 and 2008-9 put together.
Free your mind, do what you have to do, but don't jump ship with clouds like these on the horizon. Just wait a little bit, and see what happens first.
Absolutely this. You’re always going to end up in testing environments somewhere so it’s good to practice both patience and resilience. The more you train that muscle the easier it becomes to work in those situations.