The people who work on the James Webb telescope or on some planetary missions will definitely have lost their life's work if something goes wrong. I am not sure I could take the pressure.
Having other people actually use the stuff is the best part for me.
You finish your part, the web site is done (other team members get their stuff done), you ship to production, it goes live, the client loves it and uses it. Users love it and use it. All is great.
Over a year (or more) updates and additions are done to the site and code. Some mods here, a few CSS tweaks there, a whole new module or some new tool for users or the back end. All is going well.
Then one day, your team isn't needed any longer - either the customer is completely satisfied with the work, and no longer needs or wants any further updates (and what updates they do need, your back-end you developed can handle it for them). You or your employer never hear from them again, or if you call, they just say "we're all good - the site is running great".
Eventually, you note it in your CV and your portfolio and move on.
Then, one day, you turn to look for another position elsewhere (maybe years later and an employer or two in the future), and decide to go back thru your old portfolio, both to catch up on what you did, and what it looks like, and also so you can show a future employer or recruiter what you worked on (at least from a user perspective - because you likely don't have back-end access any longer).
...and it's gone. All gone. The client decided to do a complete system update, using a completely different design firm, etc - and the site looks nothing like what it used to. Your work might as well not exist at all, and you no longer work at the old employer, and you don't have a backup of the code or site (because it was a work for hire or such - legally you can't have a copy). Gone.
As far as anyone is concerned, you have little to no proof you actually worked on anything.
It's a very frustrating thing to see, which is why it is so important to have a portfolio of personal projects and other things to fall back on (and best in a github or other repo).
Still - that only softens the blow somewhat; I know that out there have been a couple of small things I worked on that I would love to be able to show in the future, but which are completely lost (my old employer went out of business not long after I left - then again, we didn't part on the greatest of terms, either).
At one employer (whom I still use as a reference - they were good to me when I worked for them, but let me go in a downsizing prior to the sale of the company) my software is still in use; don't ask me how - it was written in VB6 and used an Access 2003 MDB backend to serve about 50 users on a daily basis; when they let me go they said they were looking into other options, but they never found one - it has had no updates since 2004, yet still runs and works fine, according to my former supervisor (who's now a VP there). I can't do much more than say what it is to a future employer, though, because it was an internal-use only "product" that was never sold outside of the company. It was basically a custom CRM/issue tracker/billing/reporting/file-packaging and distribution solution that grew in an ad-hoc manner - tightly integrated with the company's business rules; when I left, I was working on transitioning the back-end to a PostgreSQL database (via an ODBC connector), reporting used the Actuate reporting suite (the company was a VAR for them), and the file management stuff used Visual Studio as the back-end. On top of that, I built a small scripting language interpreter (today, I would do something different) to handle online updates and installation (for a time we handled updates by going around with a CD to each user, with the new system, we could target updates per user, per update - we could also roll back things - all from within the application). There was also a similar install system for the file updates sent to clients (their main product was written in DB/C - a COBOL variant - and the file updates were packaged based on the repo in VS - turned into a ZIP file that could be installed using a custom installer I wrote that was similar to InstallShield of the time).
Anyhow - I would love to be able to demo it to potential employers, but since it was an internal project, I have nothing to point to in order to even prove I worked on such a system (all I can tell them is to call my former supervisor as a reference - fortunately he still works there, and they still use the software). I was let go in 2004 from that position - so I have one product out there that is still running for 13 years now (fairly amazing to me - I keep expecting a call from them to port it to another platform - but since Windows 10 still supports the VB6 runtime, probably not anytime soon).
[1] http://www.keysight.com/en/pdx-x202266-pn-N9020A/mxa-signal-...
That's right. It's why I rarely invest the time writing a program just for my own amusement. To me that's like building a model train layout in the basement, that nobody but me will see, and when I sell the house the next owner will rip it all out.
Plus, I'll just generally disagree with you, sitting there making stuff that falls right into the garbage can is incredibly depressing. What's the point?
The point is that I get still acquire new technical skills and parts of (failed) projects might be challenging and interesting, even though complete project don't result in success (in business meaning). For other points see my response to a sibling comment.
Coincidentally, I was also an embedded dev.
That's actually a very important part and many projects don't even make it that far. This is an extremely valuable skill to have, the actual running of a company beyond that point is a lot simpler and interesting. Don't underestimate this capability you have.
I respectfully disagree. I think that the problem of maintaining a project in the field, providing support, taking feedback and making improvements, and managing a pipeline of new developments alongside sustaining efforts is just as difficult of a problem as getting to an MVP. Both sides take vastly different skillsets, and require people with very different backgrounds to compromise and shift in leadership.
That said, I completely agree with your point that the skills of getting an MVP out the door is significant and worthwhile. I know I am on that side of things myself - I enjoy the initial development, brainstorming, hard work, and hard choices that come along with that piece of a project. I jus think that the other side of the coin deserves equal representation.
A very journey vs destination thought. If the journey is your goal, then you already have the "point" you're looking for. If, however, the destination is the goal, then you are forever reaching out for your next "point", and the moment you reach one, you'll be reaching for another. Always looking for your next point that will never satisfy you.
The preeminent philosopher Jake the Dog had an interesting comment about this sort of thing:
To torture a metaphor, I like hiking, my wife and I have a goal of hiking the whole SHT [1] in bits and pieces over the course of 5 years. We've found parts of the trail that are absolutely amazing to hike, we could just hike those sames bits over and over again because we know that they're amazing and not risk having to hike the bits that are just a mowed bit of grassland (which is uninteresting to hike), but then we'd be missing out on the whole experiance and not only that we might be missing out on even better sections that we haven't encountered yet.
I feel the same way about how I'm progressing in my career. I could keep doing the same bit over and over again and I'd probably be pretty damn good at it, but I just can't let myself. I'd rather keep exploring, keep experiencing not only what's new, but what's old-hat to others but new to me, and see if there's something out there that I'm even better at that I enjoy even more than what I already know.
[1] https://shta.org
The sad thing is when you get old enough you start seeing even the successful projects you worked on show up in the 25-cent bin at Goodwill. (Maybe not so literally anymore, since software isn't bought in boxes, but you get the picture.)
Earning a paycheck. Getting passionate about coding at a company is setting yourself up for disappointment. Save the passion for your personal stuff, or start your own company.
I guess that's why we have so many poorly designed products, because their creators don't truly care.
There is a 2%-5% catastrophic failure rate in unmanned rocket, so they will have a ~50% chance that one of their satellites just explode. As the article says, "it sucks", but no one launch only one satellite.
To somewhat confirm my estimation, yesterday someone posted the photos of two of the members of the teams of the JPL that build the Pathfinder, Spirit+Opportunity, and Curiosity. This is a 20 years timespan, I'm not sure that everyone worked in all of them, but my estimation is not too wrong.
This is also why critical missions like spy satellites are often built in pairs. One to launch, and if blown up, the mission gets a second chance with another rocket at a later date. Science missions don't often have this luxury. You get one shot and if it fails, too bad.
edit: note I wrote 'often' not always. You don't know if your mission will get a second chance and that's the stressful part. If this was a mission to study Earth's climate change would it have gotten a second chance under the current administration? Probably not.
> Lindbergh and her team rebuilt their experiment—again—and put it on another rocket last April, a Falcon 9 launching from Cape Canaveral. She watched as the engines ignited, the smoke billowed out, and the rocket rose.
Due to the same launch vehicle problem, in a separate launch attempt, the Glory satellite failed to reach orbit. But I don't believe it was replaced in the same way.
Some missions are highly successful, and they tend to have successor missions. I suppose most mission teams aspire to this status. The JPL Mars program is an example. A succession of more-capable solar monitoring satellites has been launched by a team including Stanford and Lockheed, which has remained stable over 2 decades now.
It's not like there's any backup plan, either. There's no market for Olympic skills.
But they had constructed that spare time-machine in secret using the fact that most of the cost was sunk in R&D.
There's a Hubble Telescope hanging on the wall in the Smithsonian in DC, fwiw..
But outside the military and certain high-risk areas such as offshore oil that appears to have declined as a contingency sometime in the 1970s.