The problem is if you deliver something and the people it's meant to serve don't know about it, or can't use it, or it doesn't actually solve their real problem, you didn't "ship" in the sense the article is talking about.
I suppose it's possible to pass all those thresholds and management still doesn't like it. But it's important to ask yourself if that's really the case or if you did something wrong and failed to ship something fit for purpose.
If you are working on something the people deciding on the size of your paycheck want to kill, time to find a new project or a new company. Why fight a battle you're sure to lose?
If only you could figure that out ahead of time. I've been on projects that were killed with no notice anyone could see even in hindsight. I've been on important projects that senior leaders decided to out source my job to China and my boss was forced to let me go. I've seen budgets run dry many times and important projects got killed/cut with no notice (sometimes there are signs that but you think your project is important enough to escape the cuts until it isn't). Sometimes you are doing working everyone tells you is critical the day before they show you out the door.
I've also seen people make careers out of taking over projects cut for the above reasons as customers still demand support. I've seen many downturns where my project was important enough to not be cut.
I've seen many downturns where my project had massive cuts, but I personally was not the person cut. Most often projects are not killed outright, instead they go through a long down spiral (not always, but typically) and you can make a lot of money being the expert on a product that is making money if you are able to hang on. Someone needs to leave as there isn't the budget to pay everyone, but that someone need not be you. Often these projects pay very nicely for working 9-5 with no pressure to do overtime.
> Sometimes you are doing working everyone tells you is critical the day before they show you out the door.
I know this may appear so but the signs are there. We only want this to be true so we do not see it.
I've been in a similar situation where all we were seeing was high pressure to deliver something. This made it appear that is because the project is important. But the underlying reason was that if we didn't, the project would be dropped. Which they did.
A project may be critical but even more so is to be in a certain time frame and budget, otherwise the project doesn't have a reason to exist any more. But until that moment is still very important because, at the very least because there was a lot of investment into it.
> They knew the words to those songs, but not his entire set.
This has always been true for recorded music. Originally people would buy mostly singles after hearing a song on the radio, then maybe listen to the B-side too.
Listening to complete albums was only popular for a short while before streaming brought single songs back to prominence as the main way people consume music.
Don't disagree. I'm merely commenting on the dramatic change in his audience, which IMO opinion was driven by TikTok virality. Going from a crowd of people who were singing along to people standing around waiting for the "TikTok hits" was really strange.
I had a similar experience when I went to see James Blake; the audience was bimodal in age and there was a younger crowd that only knew a few of his singles that had gotten real big (collabs w/ Travis Scott and Rosalia)
So maybe this is normal as we get older? I didn't know this had happened with Alex G but I'm happy to hear about his success -- to me that's the main thing that matters, however an artist finds their audience.
Not for alex g. He has had a cult following as the best songwriter in rock music for a decade plus. Up until he took off on tiktok everyone at his shows knew almost all his songs. I guess really the complaint here is just that he went from cult musician to a having more pop appeal.
But the most common pattern is a sequence of calls to functions that return an optional error plus the happy path value, followed by a short circuiting check of the error, followed by a call to another function with the happy path value as an argument. It's very common to have a chain of these kinds of calls making up the body of a function.
It seems like "return err" is very useful for this pattern, if I understand you correctly. A function returning the error from the first call it makes that fails, or the happy path value if all the calls succeed. Seems like it should be possible to bake that pattern into the language, but its tricky doing it a way that doesn't obfuscate the underlying semantics, which is very important to many Go developers.
I'm not sure the syntax is all that significant. There have been numerous proposals, but the syntax was never the reason for rejection. It is that the entire concept is unusable in the state that it is understood.
That's not to say the problems can't be solved, but nobody has yet.
> It's very common to have a chain of these kinds of calls making up the body of a function.
Yes, like in Rust, for example. But it also has defined traits and other features on top of the chaining to deal with the same problems Go would suffer from it had such syntax. Theoretically Go could introduce the same, but it remains unclear how to do that in a way that makes sense in the Go language.
Again, there is probably a solution out there, but nobody has come up with it yet. Surprisingly, these kind of things aren't sent down from the heavens by a magical deity. It takes human effort, which isn't there because they are busy ranting on HN.
> It seems like "return err" is very useful for this pattern
We need to create a whole new body of law for enforcing copy write protections in the age of AI.
Does the AI adequately attribute its sources? Does it paraphrase in acceptable ways or just repeat large swathes of text from its corpus with minimal changes?
The laws should force any LLMs not yet capable of complying with these requirements off the Internet until they can comply.
reply