this mirrors my experience, but it doesn't give much actionable advice and probably only rings true to those who have experienced the same motions. "You only know your project shipped if your leadership acknowledges it". Yes ok great, how do you get their attention. I think this piece could be more easy to understand and influential if the author included a specific IRL project as a case study instead of having a bit of memoir about the vibes of their experience.
I'll tell you my own personal experience here: Go talk about it!
Depending on the culture and rituals at your company:
- Ask for a spot at an all-hands meeting so your team can showcase what you shipped
- Record a demo video of the team's work and share it in Slack/Teams/Yammer
- Write a post-mortem or internal blog post about the impact that your "ship" had on the business.
- Etc...
I'm a firm believer in the concept of "internal marketing" in big companies. I've had leaders and mentors repeatedly tell me "no one will recognize you in a big company if you just sit around waiting for the recognition"...
You have to put it out there and talk about it and show it off...
And yeah, I know a lot of tech folks hate doing this.. But in my experience that's how you play the game in an honest way... Find the right time and place to be proud of your work and show it off.
Yeah, I agree this post would have been better with a concrete example. It's hard to talk about a specific project though, since it comes down to describing in detail facts about a company's internal workings (often embarrassing facts). I couldn't figure out how to anonymize it sufficiently.
This mirrors my views. In sports, winning fixes all problems; in software, shipping solves all problems. You need wins, and you need to ship. It’s like in Glengarry Glen Ross: instead of “ABC—Always Be Closing,” it’s “ABS—Always Be Shipping.”
You’ll never ship a perfect product; no such thing exists. But if you ship early (and incomplete), users will be delighted—and often change their minds about what they want. That’s great, because you didn’t spend forever on their initial (flawed) requirements.
When I'm shipping on a deadline, one of my favorite things to say is, "there is no future". When someone says they want to do X because they will do Y in the future, I say, "There is no future, there is only shipping. Give me what I need to ship and then we can talk about the future."
Pigs can fly. I know this because if it's got to ship and it's a pig, then sufficient thrust will be brought to bear to achieve flight.
Shipping is some liminal space between sheer will, recklessness, and tautology. It ships because it has to ship, because to not ship is to fall, and failure is not an option.
This is great. I particularly liked this observation:
> Shipping is a social construct within a company. Concretely, that means that a project is shipped when the important people at your company believe it is shipped.
A lot of the ideas in here resonated with me a lot. This is the kind of article I wish I'd read before I spent a few years leading an engineering team at a medium-sized tech company!
This is the reality. And if you happen to be in an environment with less cooperative folks, get your requirements to ship in writing, agreed upon, and as up front as possible. Hold them to it. Otherwise, it just opens you up for nitpicking, and in some cases goalkeeping, by folks whom end up delaying your shipping.
Ya, I think this is a great insight. In today's world, code is not released as a versioned artifact sold on a disc or downloaded. The idea of "shipping" is fuzzy. You might be 100% in production with some change and it could still leave edge case, deficiencies, etc. You can decide to address them now or later. And it's all just perception. You can say it's good enough, we shipped, let's forget about this whole thing and move to another. Or you can keep ironing out the quirks.
I've "shipped" things in the past that were turned on to less than 1% of the time, and we left it at that, and moved on to other things. It was considered "shipped". Everyone was worried to increase it to beyond 1%, so we all patted ourselves in the back for the great launch and went to work on other things.
There was always something intensely satisfying about walking into some retail store and seeing boxes on the shelf containing CDs with software I'd written.
(On the flip side, there was that one time we had to destroy 5,000 CDs because they had a Quicktime Autostart virus on them...)
Sometimes it’s odd to realize there’s people that can say this while simultaneously not being my grandfather. There’s a whole period of computer history I skipped.
Yes but otoh that might be more of a “I refuse to accept a culture of optics on principle” kinda situation, rather than not understanding it. I liked the post because it’s honest and doesn’t put a value judgment on things, just explains how it works. It’s up to each and everyone to act accordingly, and one of those actions is to not participate in the lunacy that often arises in the higher echelons. Many people are fine keeping their integrity, mostly left alone to code, avoiding social deception games at the expense of not being promoted out of what they fell in love with in the first place. People are just different.
Refusing to accept a culture of optics is tantamount to not understanding optics though. The reality is that if you work on any kind of product, optics do matter - the perception of something working is often just as important as it actually working.
It can't possibly be "just as important" - in some cases, I will accept "almost as important", but any situation where the optics are "it works" and the reality is "it doesn't work" is eventually going to come crashing down on someone's head.
If it doesn't need to work, then it doesn't matter and the optics also don't matter. Of course, it might be more important for your promotion that the optics are correct, no matter what the ground reality is, and the crash could come down on someone else's head instead of yours, but in this scenario someone who is against a culture of optics rather has a point.
If you shipped and nobody important enough knows, then you haven't shipped in the eyes of the most important people.
I'm the first person to agree with you that it sucks that optics are important. But they are. You can definitely ship shit with great optics and get a promotion and be far away before that shit hits the fan.
But if you ship the greatest thing since sliced bread and nobody notices, then you might as well not have shipped at all.
Lots of things are popularity contests. It’s very difficult to escape when you’re in it, but they always fizzle out, leaving remarkably little behind. Your promotion at Enron has no meaning today, but at least the little string parsing library you wrote may still be in use and someone is happy about it, decades later.
The point is that your impact isn’t defined by a McKinsey trained head of HR who gamified a career ladder for you, or the opinion of “important people”. In fact, what impact means depends on where and (crucially) when you measure it.
Some professions have longer reward cycles than a human lifetime. Great writers, artists and thinkers are often recognized posthumously. Doesn’t mean everyone should write poems, but we shouldn’t exacerbate a culture where you’re useless if you can’t charm your closest mediocre middle manager. Life is more.
Oh absolutely agreed on lots of things being popularity contests. And I don't like that fact either.
It's still important unfortunately.
Your promotion at Enron still has meaning today because it bumped you up the career ladder early on in your career and your next job after that was a step up from that etc. 20 years of elevated salary because you climbed the career ladder early adds up to real dollars in your investment accounts.
Do I like it? Absolutely not and I am trying to stay at the level I'm at right now for as long as I possibly can, because my job is not entirely a popularity contest and still has real good software engineering and actually building software that real people use and love in it. If I "climbed" any further all day every day would be a popularity contest. But I do recognize that being allowed to continue building that software requires (as in "it's important") to take part in some of these popularity contests.
(talking paid work wise here - if you're OK to live in a basement doing meaningful open source work that will outlive you for the rest of your life and it makes you happy, then power to you - not most people's reality)
I see your point, and I agree. I think it comes down to weighing strategy, tactics and values. Values can really only have impact once you have some form of influence. And tactics can be necessary to establish yourself, even more so in a world increasingly governed by micro-algorithmic engagement and short termism. But it can also be dangerous in the sense of perpetuating values you don’t agree with, not least within yourself - a tactical win but a strategic failure. Some people pull it off - like Dave Chappelle, getting “fuck you money” early and staying real.
"Appreciate" is a weird word. At least for me (not an English speaker) it has a positive connotation so with that in mind I sure hope nobody appreciates the importance of optics. The concept is dumb but it is important and we have to play the game to achieve anything.
Why did you read that as 2 though? Is there a context clue I'm missing or is there some grammar rule I don't know of? Honest question, I'm Polish.
For me there's a huge gap between 1 and 2 so it might cause misunderstandings when used in a sentence. I despise a lot of things I fully understand and if I said I "appreciate" them - sounds weird.
It's heuristics, not grammar. You usually appreciate a noun or noun phrase in a transitive sentence (X appreciates Y).
Case 1: If it's something useful (e.g. 'your help', 'what you did') then it's more likely about being thankful.
This use of 'appreciate' is also a social action. You say it to make someone feel good for helping.
Case 2: If it's an abstract thing (e.g. 'the importance of', 'the difficulty of') then it's more likely you're talking about understanding.
Usually when you talk about this usage it's because the _fact_ of understanding is important to the speech act. If someone explains the law of gravity you don't say "I appreciate that", you say "I understand that". But if you fell from a height and hurt yourself you can say "I didn't appreciate the law of gravity".
Case 3: If it's intransitive and it's about money ('the car appreciated in value', 'the house appreciated in value').
It's a pity that heuristics are not mentioned in most language books or dictionaries. At least I wasn't taught any in school (10+ years ago). This should be next to the word definition.
Optics are not dumb. Corporates are very noisy. It is difficult to extract the signal from the noise if you're not working on a project full-time (as most people are, except for you, the tech lead), and it will definitely not happen by accident. That's why you need to manage optics.
I agree that they are very important but I still call it dumb in a "it's stupid that we have to do this because we suck as a human species" kind of way.
I think that's what the word "appreciate" is hinting at in the phrase: "most engineers..don't appreciate the importance of optics."
Optics is subjective and often superficial, a performative illusion for the sake of whoever is looking at you. But that doesn't mean it's not valuable or useful in a social context.
Here, I read the word "appreciate" to mean, to recognize the value of a thing even if you disagree with it.
For example, someone could be a pacifist and still appreciate the need for weapons for national defense. They may not agree with the means but still admit it has value and effect.
Similar is "enjoy", which is almost always possible but sometimes can be used in a more... detached sense? "Perspectives in nature we rarely enjoy" as seen in The Far Side here, for instance.
Weirdly, optics have never mattered at all in small or startup companies. And they manage to do pretty well, ship a lot of product and become large companies.
Maybe the problem isn’t the engineers, but the need for optics…
It definitely gets worse as the organisation grows. There isn't much room to hide in a five person company whereas it's hard to be seen in a 5000 person organisation.
It's a matter of scale. "Optics" (as a separate concern) don't matter at orgs that are small enough that everyone can see everything (and/or has full trust in the people who do). Visibility and trust don't scale, hence the necessary evil of pageantry
The emotional perception of the quality of you, the worker, in the eyes of the leadership who pays you. It is distinct from your true value and contributions. It is maximized by you optimizing the visibility of things that boost reputation and minimizing the visibility of embarrassing things.
It's a term that has been adopted to sound more professional than "keeping up appearances" which is an age-old concept. It is about how things are/will be perceived by others, rather than the truth of the matter.
Note that it can get trickier than it sounds. (Well, I don't know about big tech, but at least for medium and smaller.)
You need to figure out who the "important people" are, and somehow make sure that they understand and buy into the product definition, delivery dates, etc.
Even if they're 3 levels up from you, and you can't normally interface directly with them, try to find a way to double-check that all the "important people" are on the same page.
Organizational dysfunction happens, and you have to succeed despite that possibility.
Yes. Unfortunately, it comes with a side effect, you will see leadership use this to kill projects they don't like by not never mentioning them until people think it's a failure.
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.
In my experience, most things in large companies are social constructs. Good things are good because they were decided to be good, bad things are bad because they were decided to be bad. Very rarely are they driven by actual metrics.
There is a tendency here to pattern match the advice in this article with frustrating experiences about office politics. But I dont see this as a post about politics.
Rather, what I got was that the spec is an incomplete description and there needs to be more inquiry into how the software is going to be used. This can require a little bit of 'going up the stack' to see how business need relates to the software requirement(single enterprise customer with a precise requirement, acquisition of new customer, software for some internal vision of CEO etc). Compare with a startup where one doesn't even have a spec and one is trying to find a product-market fit or when developers take sales calls and find new insights on how the software is actually being used.
A completely broken spec is indeed a failure in management process. But, in general, it helps a library developer to think beyond a library spec and see how it is being used.
They ship because they do project management right:
1. Focus on stakeholder management
2. Know and understand what you build end-to-end
3. Because of 2. you can quickly assess the impact of various options to resolve a problem and communicating this back to stakeholders, generating trust
I like the example of 3. In the blog post.
So many people run projects like they just coast around. Never a moment to pause, reflect and proactively thinking about potential risks and possible mitigations.
Oh my, we never saw this road block coming, how could we have known? Well..
It’s about pleasing upper management. Those are not the same things. The article even says it explicitly - if your users hate it and the market laughs, but executives like it, you’ve shipped. If you’ve given users the best software ever but your executive management doesn’t know, or even actively hates it, you haven’t shipped.
I think this falls under the category of "Don't hate the player, hate the game."
I agree with you: It totally sucks that this is the way the business world works.
But if you want to work within the confines of this flawed system, you need to know how to navigate it well, and I think this post does a good job of giving you the guided tour.
There is a failsafe, however. The post points out that if the project launches and users love it and it makes the company a ton of money, then upper management is going to find out about it even if you don't tell them, and they will be pleased that you have made the company a ton of money.
There’s a hero element here that so think is what irks me.
The reality is, most of the time when you “ship” your software, executive management neither notices nor cares. Even if you get the “attaboy” from a manager, they will forget it 10 minutes later.
You ship your software because you care about work, and maybe because you care about your users. In a big software company, shipping is not going to get you noticed unless you are literally the guy delivering gmail or google maps.
If a ship happens in the forest and nobody at company notices, did the ship really happen?
To be clear, the pathway to management noticing is not you going around the building loudly blaring that you did a thing, it's that churn went down, or ARPU went up or CAC went down or uptime went up or something management cares about.
But the essential thing to also understand is that this doesn't just happen for free. Figure out what metric your ship is meant to affect, put monitoring in place and proactively notify those above you about how your ship impacted that metric. If you don't do this last step, you didn't ship.
> The reality is, most of the time when you “ship” your software, executive management neither notices nor cares
your reality might be different than mine, but things that got shipped definitely get noticed because they are used as a bargaining chip for promotions, funding and for visibility of the entire team, that's one of the main concerns of a manager (unless they've checked out and are searching for another job)
Generally the game is created by external forces, not the players. If you’re an independently wealthy individual you can afford to work for pleasure. The rest of us? We like to eat and live in comfortable dwellings and take care of our families, so we play the game of pleasing our superiors in return for the money to live a comfortable existence.
I see your reply as strawman levels of uncharitable. They never said any such thing for either of your claims and the only reason I see for your statement is that you are playing.
Then you would expect to see inversion of behavior at the higher levels, especially at big tech, when one does become independently wealthy, but that's pretty obviously not the case.
Not necessarily. You can have upper management chieftains, who view the rise of a "new" one- as a threat and will actively try to prevent "upstart" new sources of income, to protect the dependency on "whoever" pays the bills for decision making.
You will not get a product thats not search off the ground at google.
You will not launch something else then windows / now cloud at microsoft.
Even if it makes money. The old chieftains domain has to wither and be in retreat first, before something new can be started with all the resources available.
Its really exotic, if cross domain success is achieved. Amazon logistics and then AWS is such a example. If you look under the hood, the companies that allowed for that- are often more conglomerates, basically smallerish independent companies within a brand-trenchcoat pretending to be one large company. Youtube is also such a thing.
My pet theory is, that its company internal value chains, the chieftains depend upon that allow for such things to form. Like search is advertising and needs data. And data comes from the engagement guys down the hall in the other building.
There was a time, upto 10-15 years ago when tech company culture was largely anti-corporate.
Now corporate-y things like playing office politics is order of the day in medium to large tech companies.
My (maybe uninformed) hypothesis is that tech made so much money that it brought in the MBA and HR types who brought their corporate culture with them.
Even the smaller tech companies are now mimicking big tech culture as the standard.
>My (maybe uninformed) hypothesis is that tech made so much money that it brought in the MBA and HR types who brought their corporate culture with them.
This is some strange engineer's fantasy, that every company was ruined by "MBA types". Meanwhile, as evidenced in places in this thread, "software types" don't even understand basic business principles. They like to believe that if they were just left alone they'd churn out brilliant product, as if a large business isn't far more complex than that. Someone needs to count the beans (MBAs) and someone needs to deal with the people (HR).
I have seen the opposite happen a lot though, even if a project is successful you will get numerous people coming to you asking “who approved this? Why was I not involved in the decision?” And the ballooning aftereffects are why it takes months to push a simple button.
Big companies are like government bureaucracies now.
> Big companies are like government bureaucracies now
Large organizations are, by definition, bureaucracies regardless of being public or private. Big companies were bureaucracies 100 years, and they will be bureaucracies in 100 years. I never understand why people expect private enterprises to be free from the inefficiencies inherent to coordinating lots of people and things
I think the article does a very good job of defining the term "shipping" in the context of large organizations, where it you genuinely do need to please upper management - if you want further career advancement, in any case.
It's a bit cynical, but that doesn't mean it's not true.
If you want to ship software without worrying about upper management opinions, go work somewhere smaller.
You can still please end-users AND upper management at the same time. That's what I would aspire to do in that situation.
Job advancement rather. Career advancement is possible by making users happy and telling executives at other companies "I did that". It's a better story if you had to fight for it.
If end-users do like it upper managment notices it but it will take time, generally you iterate faster against upper managnent. Same kinda applies when end users dont like that stuff so you cannot lean too heavily to opticks game.
It's much easier when 'upper management' is 3 individuals you can have a normal conversation with, than a hierarchical hivemind above you that does inexplicable things for random reasons.
People are also usually suddenly much more reasonable and cooperative when you're discussing something face to face with them and not through third parties :).
It's also like this in small companies, like the one I work for, and I think rightfully so. One of the mobile app projects I was involved in got bogged down for months due to the lead engineer's need to refine and polish the perfect UX and architecture which kept breaking features we'd already completed. This cost us a lot of money and the product didn't look or function to an end user that much different. Management had enough and pulled the guy off the project because it just wasn't getting shipped and what he was doing didn't align to their goals. After he left i was able to tie up the loose ends and ship it live within two weeks. The only way i was able to do that is I knew every component of that system, our deployment infrastructure, our support staff, the real goals of our management team, etc.
Almost all of us here has worked on a ticket that made us say "The fuck is this shit im working on, who will use this? Who the fuck came up with this?"
And we just work on it, take the paycheck, and move on to the next one lol.
Just the use of the word "shipped" implies that software is an interchangeable commodity that rolls off a conveyor belt in a factory.
That's not the reality with any software that actually matters, no matter how hard M.B.A.s try to abstract the human factor out of it.
Good software isn't manufactured. It's created. It takes thinking, and planning, and crafting, and all those things that are the opposite of a plastic widget factory that "ships" products to its customers.
Don't let then dehumanize the profession any more than it already is.
I don't know why this post is getting down voted but the MBAization is truly it.
MBA practices cannot deal with uncontrollable production. But software engineering is utter chaos. So they try to come up with bullshit units that can be easily managed in their opinion. But it never works - aka, a nimble competitor always eats the giant in software.
The MBA style practice does work in factories and warehouses. But in software, a nimble startup with own the incumbent just be providing higher quality value.
Most commercially written software is closer to manufacturing than art. That doesn't satisfy everyone, I know, and I'm not here to judge people who don't want to work on integration #5 for widget #3 in order to unblock a million dollar contract from Foobar Inc. But that's where a substantial majority of the market demand for software development lies. The MBAs are paid precisely for their ability to channel the creative process of software development into the manufacturing slots where it's needed.
(Even art, of course, is in practice pretty close to this. MBAs are paying you to sublimate your creative energies into a snappy video on how to sign up for Robinhood or whatever, and there are substantial business constraints on both its content and delivery date.)
It's closer to engineering than either art or working on an assembly line. Software tasks just aren't fungible in most companies, and neither are they open-ended interpretable works designed to please or strike fear into the human soul. The average codebase is pleasing to me in the way an engine block or an oil refinery is pleasing. Q_rsqrt is pleasing in the way a mathematical proof is pleasing.
I’ve worked in engineering businesses, and SaaS scale ups and the “engineering” that gets done by SWEs had little to nothing in common with any of the engineering disciplines I’ve worked in apart from the E in the title.
Little comprehension about cost engineering, maintenance, safety, durability and resilience. Half-baked bodies of knowledge. CV driven development. Fads and critical production systems held together with spit, tape and hope. It’s like Aristotle’s Cave in our field.
When you ship it is arts and crafts which usually leans heavily to a small group of people Then if you want it to be commercial succesfully it needs some manufacturing practices because otherwise, you end up with legacy software.
You can love it or hate it all you want, the important thing to internalize is that this is a feature, not a bug of doing things at scale.
There's no way to engineer it such that you don't get to live in this reality. Be it tech companies, marketplaces, politics, revolutionary movements; once you reach a critical mass of people, all meaningful change looks like this.
That is before a smaller and nimbler movement, company or entity surpasses the now large, slow-moving and fossilized incumbent, which then starts the gradual process into irrelevance.
It's about the customer recognizing the product as something they are ready to buy, which is associated with the dictionary definition for shipped "(of a product) be made available for purchase."
It falls apart slightly in that the customer technically starts buying the product on day one, while it is still just a glimmer in someone's eye, but "shipping" referring to the point where the customer says "Yes, that is what I wanted" is close enough to stay within the intent of recognizing something available for purchase methinks.
> If you’ve given users the best software ever
Of course, in context, the users aren't your customer. They may be someone else's customer, but that wouldn't be shipped by your hand. Your delivery is limited to your customer.
People get hung up on this stuff. Getting things done in different environments is about understanding the constraints. The objective isn't to religiously follow some "ship" cult. The objective is to get things done. Or at least that's my cult. I have a friend in Amazon's logistics department. One day he told me how he was planning something that involved buying up the entire capacity of a local airfield. The thing with a long enough lever and a fulcrum is that these guys are moving the world.
Love it or not (mostly not), shipping software in large organizations requires navigating what the business and its leaders demand. You can try while ignoring leaders, but you'd be unlikely to ship anything.
You'd be in good company.
In my experience, there are plenty of people at BigCos who are more interested in covering their ass to ship nothing or the wrong things.
There used to be something called beta testers. You could actually see if users hated your software before releasing. For a small subset of users, of course.
There also used to be alpha testers, i.e. your own staff. There's another subset of users and one that probably still can tell you if they hate your software today.
Yeah, if you spent your life like this you kind of wasted it. I’ve noticed that HN has fewer and fewer hackers day after day. Not sure when they will change the name.
The number of "hackers" who think it's better for devices to be locked down by Apple because that keeps them secure (and freedom to install unvetted software is dangerous), and who think AI will replace us because we are all "statistical parrots" and just regurgitate what we read somewhere anyway is really astounding.
Also lots of "hackers" who measure success by how much money has been made, be it by a company or person.
I mean it may not be impossible to be a hacker and believe those things, but it should at least be a rare thing.
> First, you have to get clear on what the company is looking to get out of the project.
You are not just pleasing the executives. Assuming the company described in the article is a good company. Executives are not idiot that making impulsive decisions.
You need to be able to sense the company direction, communicate clearly, manage the risk, build the trust. This is not an easy task in a big company.
Such an awesome article IMO that explains the art of shipping in a big firm. I believe if any engs can master the skills described in the article, you will get promoted to a leadership role very fast. Of course, this might not be the path everyone loves.
There’s a really interesting article that I’d like to read about the “first” - ongoing stakeholder management through the lifecycle of the project, the product and your time there all allow you to ship effectively (as far as the org sees it at least).
Focusing on the tech and even product UX minutiae doesn’t typically get the headspace you need from senior management for rolling down tech debt, the headcountb you need to really ship useful and market leading software.
It's funny because this is the absolutely tell of someone who spent their entire careers in large organizations. I alternated between large and small, and it's incredible how resigned and compliant people who have been in larger orgs can be. At some point the absence of actual survival pressure creates a dichotomy between internal and external success, and only the former is important, as this article relates. It's so hard to fight the flow, that either you go with it, or you get jaded and desperate, and just leave for better pastures.
To go and call that "shipping" is a stretch in my opinion, it is only correct as far as your cynicism, semantic tolerance, or resignation to mediocrity can stretch. But with reduced perspective and a slight ego, it's hard to tell that things can be different.
how can it be any different? Someone else is paying you to do something; you either do it (aka, you please them), or you don't (aka, don't ship, and you stop getting paid).
If you dont want this, you'd need to become your own boss - in which case, you ship when you feel you've shipped! You can argue that this makes you more aligned with your customers. And i'd agree - you've made the customers your boss directly. So now, they determine if you've shipped or not.
So the only situation in which this is different (or still the same tbh), is if you're your own customer.
> how can it be any different? Someone else is paying you to do something; you either do it (aka, you please them), or you don't (aka, don't ship, and you stop getting paid).
The good situation is when you get paid to do the thing, because you're getting paid by someone who cares about whether the thing is done. The bad situation is where you get paid to make a Potemkin version of the thing because the person paying with you cares more about the appearance than the reality, consciously or otherwise. You can redefine words and say well obviously when they told you to do X they were just doing an elaborate LARP and there's no deception in doing Y and telling them it's X, but that's just sophistry.
Working for arms-length counterparties helps, as that naturally forces communication to be more explicit and honest. Working in small businesses where reality tends to intrude more quickly helps. Of course neither approach is perfect.
The article actually presents strategies for shipping, not changing the hearts and minds of management, or making great products. Shipping implies neither of those things.
> If you ship something users hate and makes no money, but your leadership team is happy, you still shipped. You can feel any way you like about that, but it’s true. If you don’t like it, you should probably go work for companies that really care how happy their users are.
Yet, that's how you sustain your job, get promoted and have more responsibility over time – large number of people don't seem to get this simple fact that your customer is whoever pays your salary and it's your job to make them happy.
It could be as well called “doing your job”. “Shipping” your job/work doesn’t seem like a stretch - especially that definition is clearly stated in the article. It’s also nice play of words that emphasises the fact that many people seem to get the rules of this game wrong.
Maybe the author didn't feel the need to state the obvious - that once the executives like and understand what's being shipped, then they can confidently pull the trigger on expensive processes like marketing. Otherwise the feature or product could sit hidden and forgotten.
If the customer isn't using the software, it hasn't been shipped to them.
Even worse, it misses the point.
Shipping means you realize benefits for a target audience.
Enable someone to hit a revenue target, compliance measure, etc. if leadership doesn't care about that or can't work to that kind of framework; they deserve to go the fuck out of business.
Treating it as "please management" is incredibly self serving. You please management by often making them money; sometimes despite themselves.
The article also made it abundantly clear that if you find yourself in that situation, and you don't like it, you should find another job.
The article isn't about the ethics of the situation, career choices, ect. The rest of the article focuses on more important details about shipping software.
Give the article another chance. I skimmed it twice yesterday and now that I'm not reading my phone on the throne, I gave it the attention it deserved.
---
I should also point out that I've had a lot of career success in situations like this by disagreeing and committing. Turns out that a mild degree of patience in situations like this often means I get to focus on very clear customer pain points and build industry-leading software. (I just don't get to focus on them the exact moment I want to.)
I once tried to ship a product and nobody else was ready. Marketing assumed the product would be late and wasn't geared up to market it. The CEO couldn't point to a marketing campaign so didn't want to mention it at the conference. Support hadn't bothered to ramp up on it since marketing had told them it wasn't actually going to ship until next quarter.
It's not about "pleasing upper management" is about understanding that a product isn't "shipping" just because you can launch it the software. The entire company needs to be on board.
I think a better definition of shipping is ensuring your project meets the definition of done. At big companies, for many projects, I think there's an implicit requirement in the definition of done that management is aware of and somewhat happy with what you shipped. The resources used to ship a project (the time, money, and people) are, after all, their resources.
I feel like you're getting at the fact that you can build a crappy product that management loves and build something customers love that management hates. I don't disagree with that at all, but to me that's kind of tangential to whether you've shipped a project or not. To me at least, shipping isn't about it being good or bad, it's just about it being done. I think what the article is getting at is that if management doesn't agree that it's done, then it's not really done.
Well, of course. Because you can only ship the software your management wants. If you want to ship a software users like, go to a company that cares about it's users. (Or turn your company into one, but you cannot do that by shipping software your management doesn't like).
Articles like this are off to me… you’re going to need to quantify and qualify your claims of things otherwise I don’t know how much credence to throw ya.
“I ship at big tech” is a broad statement… as a reader, I need elaboration or I tend to question the rest of the article. Is this just a guy bloviating or does he really know his stuff? And bold claims need to be back up.
Looks like: ZenDesk and GitHub are the "big tech".
Projects shipped look like:
* Documentation portal
* Refactor of some monolith into micro-services
* Markdown rendering
* Copilot onboarding flows
* Varied Copilot anti-abuse related things
The way I've used to describe this to people is, most people's mental model is:
<doing a poor job> --- <doing a average job> --- <doing a good job>
Whereas the more accurate mental model is:
<doing nothing> --------------------------------------- <doing a thing> -- <doing the best thing>
The former mental model is intellectually satisfying because you get to infinitely yak shave over every little tradeoff and doing nothing isn't even on your mental radar.
The latter is deeply humblingly mundane and doesn't get to center us as masters of the universe which is why we all initially resist it. Even for the people who become great at it, they become great against their inclinations, and still have to fight the urge at every step.
This doesn't just apply to tech, look at it in politics. How much time do we spend in politics debating policy? Which of our different political philosophies lead to different tradeoffs that are a deep expression of our values? How much time in politics do we spend debating state capacity? A state that can do none of the things, it's irrelevant which of the things we want the state to do. A state that can do more things, almost always just the sheer option of things they can do means they can find a better policy.
And yet policy arguments are just so fun while state capacity arguments are incredibly wonky and depressing.
But I've drawn that same diagram on 100 different whiteboards in front of 100 different juniors and said the same words of "before we figure out how to do the best thing, let's just see if we can even do a thing first" and it seems to have gotten through to an appreciable number of them enough that it feels like a high converting meme.
I think this train of thought is why I now have to deal with four UI libraries in the same small-feature-set product, including three different ways of styling a React component.
I think that a more accurate mental model would accept that a team sometimes has no idea whether a change will get them 80% of the way there with 20% of the effort, get them 20% of the way there with 80% of the effort, do something somewhere in the middle, have zero impact, or even make the product worse.
Yeah, I think TFA gets a lot right about doing software engineering in large orgs.
We call this role something like "lead developer" and it's as much about people, relationships, logistics, and documentation as it is about technical systems — but like TFA says, it's also your job to have the best holistic understanding of the technical system. A lot of more junior engineers are likely to work on a large project, and they will inevitably need guidance to satisfy the constraints of other parts of the system. You are responsible for knowing those constraints and, as much as possible, preventing mismatches when different components come together.
Meanwhile, the non technical staff (whether it's a manager or someone from the sales team, documentation team, customer support team, etc) are going to need someone who can explain the technical system to them in plain language. "Can it do this? How fast? Why can't it do this?" You tend to become their main interlocutor.
It's kind of your job to anticipate problems before they happen, to look into the future so you see what's coming and solve it in advance, and then to show up all the time when something needs help around launch, which it always does. It's very undefined but there's always something that needs doing.
This role doesn't sit well with some engineers who think their job is basically about coding and staying within their lane — those engineers don't get to be lead dev too much, because they don't do well with the organizational side of things. (It depends, of course, whether there is a hands-on project manager who can pick up a lot of that slack, but where I work, we don't always have that.)
(Context: I have worked in a large tech company a little more than 3 years and shipped some things. And before that I shipped a lot more things in smaller places – I like to think that shipping in small shops was a good prerequisite for shipping in large ones.)
> fact, it’s paradoxically often better for you if there is some kind of problem that forces a delay, for the same reason that the heroic on-call engineer who hotfixes an incident gets more credit than the careful engineer who prevents one.
I could really relate to this. Having been part of incidents, I fucking hate them and try to anticipate them with various safe deployment strategies. To leaders though it apparently seems like Im not doing anything because “nothing ever goes wrong” lol.
> Shipping is really hard and you have to make it your main priority if you want to ship
This feels like it’s written by AI by a junior level “prompt engineer”
> Shipping doesn’t mean deploying code, it means making your leadership team happy
Aka, corporate glazing. Gotcha. Over sell your corporate accomplishments and polish your turd with a clean deck. Gotta make sure the font is just barely legible and explain it quickly before they ask follow up questions
> You need your leadership team to trust you in order to ship
yea that’s why I get _paid_ to do work, not glaze c-level executives and appeal to their fragile egos
> Most of the essential technical work is in anticipating problems and creating fallback plans
Falling back is a loser mentality.
> You should asking yourself “can I ship right this second?”
no, I should be asking myself, “why am I still at this dead end job that asks me to constantly ‘ship’ a broken product. Leadership doesn’t want to encourage delivering value to the customer”
> Have courage!
You don’t need courage at a “big TeCh” job. Just be slightly competent and you are already light years ahead of your colleagues
>Aka, corporate glazing. Gotcha. Over sell your corporate accomplishments and polish your turd with a clean deck
Is it wrong, though? This is a pretty much universal phenomenon. It's less about real goal X and more about making sure the boss feels good when you're around.
That usually correlates with being a good worker, but not always.
> why am I still at this dead end job that asks me to constantly ‘ship’ a broken product.
Because the economy is broken right now and my country is gaslighting me into think it's perfectly fine for rent to go up 50% in 2-3 years and groceries to double.
There's definitely a storm coming, I can worry about my passions again when it passes.
This post is about corporate politics, not "shipping projects." To wit:
If you ship something users hate and makes no money, but
your leadership team is happy, you still shipped. You can
feel any way you like about that, but it’s true. If you
don’t like it, you should probably go work for companies
that really care how happy their users are.
When the stated goal is to make leadership happy and not solving customer problems such that customers are "happy", that is pretty much the definition of politics. As subsequently identified therein:
Engineers who think shipping means delivering a spec or
deploying code will repeatedly engineer their way into
failed ships.
I would question the ethics of engineers whom employ a strategy of preferring politics over delivering solutions.
Like everything else, writing code doesn't exist in a vacuum.. There will always be interconnected constraints and requirements, and you simply cannot "deliver a spec" and think that's all there is to it.
And that has nothing to do with ethics.. The spec is outdated by the time it makes its way to you, and odds are it was flawed from the start in some way.
And again this isn't because someone is bad at their job, it's because the business reality and conditions are constantly changing.
And so someone needs to be keeping an eye on both of those things and steering the code delivery parts of the work to stay aligned with those changing business conditions.
To your comment about politics: I would say that from a high enough viewpoint "happy customers" should converge with "happy leadership" even if it doesn't happen every single time you ship something..
If those two things don't converge, the company won't be around for long and then politics won't matter much, will they?
It is not always a yes or no. “Executive high leadership” can approve of 60% customer friendly stuff and 40% bs. And if some engineer is pouring his heart and soul to make a x% good thing that would be a benefit then it might still be rejected or worse, if engineer is in bad terms with managers he has pretty much no chance.
> If those two things don't converge, the company won't be around for long and then politics won't matter much, will they?
Have you ever worked at a big company? The level of dysfunction that can be sustained over years or decades at a place with decent market foothold is staggering.
Sure, take a worse-case interpretation of my words, this is the Internet after all.
We're all posting short messages here, not essays.. There is so much room for choosing to interpret each other in different ways.. So it's inevitable that we'll be misinterpreted sometimes.
And yes, I did try to reframe to better make my point, because I do think I'm right.
Welcome to HN, but a word of advice, this kind of snipey low-value shitpost is typically not welcome here.
> To your comment about politics: I would say that from a high enough viewpoint "happy customers" should converge with "happy leadership" even if it doesn't happen every single time you ship something..
To look at a concrete example, with the quality issues Boeing has been having in the recent years, we can claim "happy leaders" diverged from "happy customers".
Yet Boeing will still be around for a long time, and failures can be catastrophic. Whistle blowers who came out since can be said to have advocated for "happy customers" against "happy leaders" but were suppressed.
When the stated goal is to make leadership happy and not
solving customer problems such that customers are "happy",
that is pretty much the definition of politics.
This has nothing to do with "writing code", "outdated specs", "people being bad at their job", or changing market conditions.
It is a decision each engineer makes when performing their job.
Ethics are not situational. An individual either values and adheres to them or does not. Specifically excluded from this position are mistakes people make and then strive to not repeat, as no one is perfect.
Fair enough! I see your point.. But then I would submit that this is too narrow of a view to take in a complex interconnected enterprise, and that anyone who works this way will end up more behind than ahead.
I'll stand by my first line that nothing exists in a vacuum.
If you only make decisions in isolation or without broader context, whether based on ethics or otherwise, then you will inevitably make the wrong decision, I would argue, more often than not.
Context matters, and the same decision made at different times and in different situations can have completely different outcomes or impacts.
What if "making the customer happy" costs so much money that it puts the company out of business? Do you still focus on only making the customer happy?
What if you have to piss off your customers, for a period of time, to save the business so you can get back to making the customer happy eventually?
Or a less dramatic scenario, what if making the customer happy makes your co-workers' jobs hell, for reasons outside your, or their, control? Is customer happiness then still your singular focus at all cost? Because then you're a shit co-worker in my view.
Is your only responsibility to the customer, or do you feel any responsibility towards your co-workers and/or their jobs & livelihoods?
Life and work are messy and complicated, and everything is a series of trade-offs.
I’m still not seeing your ethical problem for MAJORITY of software deliverables.
You literally cannot always deliver things to make customers happy in software and if you aren’t in agreement with your leadership and product teams of what you deliver you are going to have a bad time.
Companies from startups to large enterprises deliver solutions that 0 to some customers use that was mainly to appease whatever vision your leadership has. AI chatbots in websites are a big one that I can think of.
100% agreed.. But I still believe that over a long enough time horizon, enshittification will take those companies down. Value extraction is by nature a limited time strategy.
Most companies who choose to do this are taking advantage of a period of market or segment domination where they know users don't have good alternative options, and will tolerate some level of garbage because they still want the service or product.
Note that highly competitive industries or market segments typically don't see as much enshittification...
you work for the company, not for your abstract imagination of what users want. if you genuinely feel the company isn't aligned with users, then try to change that.
it's not unethical (per se, obviously don't build bombs for them) to please your employer.
I've been in a really stressful position for the past 6 months. Things that I would've walked out over a few years ago are now things that, for various reasons, I kinda have to choke down.
My entire concept of "what is ethical?" has undergone a transformation. It's not about my ideals any longer, or about feelings, or about how gentle or aggressive management acts in negotiations. It's about much deeper things-- like when I'm asked to support something I find distasteful, I need to really investigate whether, in context, it's actually something which violates my conscience. You know what? It almost never does.
These are the two questions that matter most in my view: 1) Am I honestly being required to do something that harms someone worse than the status quo, and 2) Is anyone around me having a medical emergency - including certain serious psychological issues - that I can help with? Aside from those two things, there's a lot of ugly crap that you can still keep trucking through.
Many people, particularly (but not only) younger ones, are oversensitive to things they simply don't like but that aren't actually wrong in any major way. You've got to choose your battles.
That seems like a very narrow-minded view of the role of engineers in society. At the end of the day we aspire to solve problems that make the world better—I'm certainly not going to fault individuals for following the money, but to dismiss the ethical dimension completely is unreasonable in my opinion.
In the Military, soldiers have an ethical duty not to follow an order that is illegal. It is called duty to disobey.
In civilian life, you have a duty to disobey if what your employer asks of you will unnecessarily harm people. For example, shipping a broken insecure product that handles PII/PHI/etc is absolutely unethical, and possibly illegal (though often the legal consequences are minor, if not irrelevant). Your bosses will absolutely ask you to do illegal and/or unethical shit, so you always need to be aware of where the line is, both legally and ethically.
It's not always clear where the line is. With AI work, the line has already been crossed several times (things like discrimination in output resulting in innocent people being hurt). Do not do whatever your company asks for. Do push back when you see a problem. Don't ship something that could hurt someone. If you're not sure, ask or find out.
Ethical is not the same as legal. Legal actions can be unethical and ethical actions can be illegal.
The Nuremberg trials established this after WW2: just obeying orders is not sufficient [0]. This is why modern militaries have a duty to disobey.
It's the same in civilian life: you have a personal duty to disobey an instruction that you personally consider to be unethical. You cannot hide behind "I was just obeying the law". You absolutely should break the law if you consider that law to be unethical. It is your personal responsibility to decide this.
So yes, you should do illegal stuff if not doing said illegal stuff would be unethical.
And, putting it that way, a legal duty not to follow an order that is unethical.
My point is that us Software Engineers have the same duty, in my opinion. If some pointy-haired boss tells us to build something that will cause misery for our users, I think we have an ethical duty to refuse to do it.
The Company is an imaginary construct. The reality is that there is a group of people with common goals who work together towards those goals. Very often those goals are simply making money by any means possible. Working with them doesn't absolve anyone from responsibility.
Exactly. This is basically "enshittification" [1] in its truest form.
Look at Boeing for example, I bet leadership was very happy with the fat stock bonuses and I also bet a lot of engineers "shipped" products following the author definition of shipping.
So much so that the "if it's not Boeing I'm not going" became "if it's Boeing I'm not going".
Personal take, but if you are only playing politics you are a politician and not an engineer.
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.
> I would question the ethics of engineers whom employ a strategy of preferring politics over delivering solutions.
This too harsh. There's nothing unethical about delivering what your manager tells you instead of what you believe the customers need. Going rogue — as opposed to doing what you're told — is not necessarily the ethical choice.
IMO there are enough "not particularly ethical" tech companies are out there that we shouldn't be giving awards for blindly doing whatever your corporate overlords say. You have a choice every day what you contribute to the world.
Politics is the set of activities that are associated with making decisions in groups.
All the bad connotations we get from the word are because humans are humans. There is no better model that works in any kind of society/ organization/ group other than "politics".
Somebody "ethics" may not be the same as others. (Is it ethic to spend a lot of money and deliver something that does not fit the expectations of the ones that provided the money? It may be easy to make users happy - just give them free movies, etc.)
If you work at a company like this where leadership does not understand the engineering, the value, or the consequences of their reports but only want to talk about it at review-time, you are not in a healthy environment with an actual leadership.
And you will feel the toxicity created by this kind of poor leadership by way of constant blame games, misalignments, and unnecessary stress over garbage.
Feels like my current place. To use OP's language: if you have shipped and leadership knows about it, but also does not care, you have not shipped. Unfortunately it turns out there's no way to make them care, in my case.
That is, however, true of almost all of the big players. If you want the security of the big paycheque every month, you do the deal with the devil, so the speak.
> That is, however, true of almost all of the big players. If you want the security of the big paycheque every month, you do the deal with the devil, so the speak.
And you will pay the cost of it with time, physical and mental health, and career longevity.
Ultimately you are signing up to be servants and servants are not valued within or outside the organization.
I agree that every project needs one person who has a laser focus on getting the project across the finish line. There are always dozens of slightly annoying and unrelated blockers.
I call it my volleyball theory, after playing on a mid team back in college. If the ball is coming down near a large group, no one gets it. If you're the only one there, you'll get that ball one way or another!
This hasn’t been my experience at Big Tech (in ~20 years). There’s plenty of projects I’ve shipped that didn’t have upper management support but after the user feedback or metrics were positive they got counted as a win. There’s also many smaller projects that you can ship without anyone paying much attention but they can still be valuable either to some subset of users or in aggregate. For example, +1% on some metric isn’t going to get you a call out from the VP but do that every month and now you’re talking about big aggregate gains.
> I have shipped a lot of different projects over the last ~10 years in tech. I often get tapped to lead new ones when it’s important to get it right, because I’m good at it.
Why not list some of them that I can actually try out? How should I give this any credence if I cannot evaluate them?
None of that looks like stuff I can try. I guess the GitHub copilot onboarding was pretty good. Gists are pretty good, but I don’t think he made those originally.
Thus the discussion in the article around stakeholders and what constitutes "shipping". A lot of what one will work on at a big company does not directly translate into features that regular users will see.
Great article. It's not "shipping" as in making some feature a reality, but more contextualized within big tech and perhaps larger sized companies. Understandably, some people might call this "unethical", but it's kind of a "game" that you play (or don't) being in a large, hierarchical org.
Is it just me. Or has the term "ship", "shipped", only become a (specific to software production) industry-used term asn of relatively recent times? Specifically as Sam Altman has been using it a lot I have also noticed. Ever since his increased use of the term, I've seen it used more and more. This could be one of those times where I am noticing it because I am thinking about it, but it really doesn't feel like that.
I have always associated new software versions with with my the word "release", "released". While shipped is not an incorrect term to use for software. Release just feels more appropriate.
Has anyone else noticed this?
All of that said, I am not condemning the practice in the least. Just interested in the etymnology of one of my favorite areas of interest. Hopefully draw some more knowledgeable folks on the question.
It's not a new term. Steve Jobs coined (or at least popularized) the saying "real artists ship" in 1983[0], and using the word "ship" this way is probably even older than that.
403 comments
[ 1108 ms ] story [ 934 ms ] threadI'll tell you my own personal experience here: Go talk about it!
Depending on the culture and rituals at your company:
- Ask for a spot at an all-hands meeting so your team can showcase what you shipped
- Record a demo video of the team's work and share it in Slack/Teams/Yammer
- Write a post-mortem or internal blog post about the impact that your "ship" had on the business.
- Etc...
I'm a firm believer in the concept of "internal marketing" in big companies. I've had leaders and mentors repeatedly tell me "no one will recognize you in a big company if you just sit around waiting for the recognition"...
You have to put it out there and talk about it and show it off...
And yeah, I know a lot of tech folks hate doing this.. But in my experience that's how you play the game in an honest way... Find the right time and place to be proud of your work and show it off.
You're not even able to do your politics effectively without a middleman that can easily undermine you.
The only path to career advancement to this is to job hop as much as possible.
You’ll never ship a perfect product; no such thing exists. But if you ship early (and incomplete), users will be delighted—and often change their minds about what they want. That’s great, because you didn’t spend forever on their initial (flawed) requirements.
Pigs can fly. I know this because if it's got to ship and it's a pig, then sufficient thrust will be brought to bear to achieve flight.
Shipping is some liminal space between sheer will, recklessness, and tautology. It ships because it has to ship, because to not ship is to fall, and failure is not an option.
> Shipping is a social construct within a company. Concretely, that means that a project is shipped when the important people at your company believe it is shipped.
A lot of the ideas in here resonated with me a lot. This is the kind of article I wish I'd read before I spent a few years leading an engineering team at a medium-sized tech company!
I've "shipped" things in the past that were turned on to less than 1% of the time, and we left it at that, and moved on to other things. It was considered "shipped". Everyone was worried to increase it to beyond 1%, so we all patted ourselves in the back for the great launch and went to work on other things.
(On the flip side, there was that one time we had to destroy 5,000 CDs because they had a Quicktime Autostart virus on them...)
I recall seeing IBM ViaVoice X on shelves a Circuit City. It was rather an ego trip.
It came with a UK language model as the US model didn’t recognise my accent.
If it doesn't need to work, then it doesn't matter and the optics also don't matter. Of course, it might be more important for your promotion that the optics are correct, no matter what the ground reality is, and the crash could come down on someone else's head instead of yours, but in this scenario someone who is against a culture of optics rather has a point.
If you shipped and nobody important enough knows, then you haven't shipped in the eyes of the most important people.
I'm the first person to agree with you that it sucks that optics are important. But they are. You can definitely ship shit with great optics and get a promotion and be far away before that shit hits the fan.
But if you ship the greatest thing since sliced bread and nobody notices, then you might as well not have shipped at all.
The point is that your impact isn’t defined by a McKinsey trained head of HR who gamified a career ladder for you, or the opinion of “important people”. In fact, what impact means depends on where and (crucially) when you measure it.
Some professions have longer reward cycles than a human lifetime. Great writers, artists and thinkers are often recognized posthumously. Doesn’t mean everyone should write poems, but we shouldn’t exacerbate a culture where you’re useless if you can’t charm your closest mediocre middle manager. Life is more.
It's still important unfortunately.
Your promotion at Enron still has meaning today because it bumped you up the career ladder early on in your career and your next job after that was a step up from that etc. 20 years of elevated salary because you climbed the career ladder early adds up to real dollars in your investment accounts.
Do I like it? Absolutely not and I am trying to stay at the level I'm at right now for as long as I possibly can, because my job is not entirely a popularity contest and still has real good software engineering and actually building software that real people use and love in it. If I "climbed" any further all day every day would be a popularity contest. But I do recognize that being allowed to continue building that software requires (as in "it's important") to take part in some of these popularity contests.
(talking paid work wise here - if you're OK to live in a basement doing meaningful open source work that will outlive you for the rest of your life and it makes you happy, then power to you - not most people's reality)
1. To be grateful for something.
2. To fully understand something.
3. To increase in value
I’m sure there are more.
I read this as option 2.
For me there's a huge gap between 1 and 2 so it might cause misunderstandings when used in a sentence. I despise a lot of things I fully understand and if I said I "appreciate" them - sounds weird.
Case 1: If it's something useful (e.g. 'your help', 'what you did') then it's more likely about being thankful.
This use of 'appreciate' is also a social action. You say it to make someone feel good for helping.
Case 2: If it's an abstract thing (e.g. 'the importance of', 'the difficulty of') then it's more likely you're talking about understanding.
Usually when you talk about this usage it's because the _fact_ of understanding is important to the speech act. If someone explains the law of gravity you don't say "I appreciate that", you say "I understand that". But if you fell from a height and hurt yourself you can say "I didn't appreciate the law of gravity".
Case 3: If it's intransitive and it's about money ('the car appreciated in value', 'the house appreciated in value').
Finding people that can explain these types of examples to new language learners can be quite difficult, even on language focused platforms/forums.
Optics is subjective and often superficial, a performative illusion for the sake of whoever is looking at you. But that doesn't mean it's not valuable or useful in a social context.
Here, I read the word "appreciate" to mean, to recognize the value of a thing even if you disagree with it.
For example, someone could be a pacifist and still appreciate the need for weapons for national defense. They may not agree with the means but still admit it has value and effect.
https://i.pinimg.com/originals/89/b2/2b/89b22b4b18dd3ed630a0...
Maybe the problem isn’t the engineers, but the need for optics…
Which can be more rewarding to satisfy than the optics of just management. But still needs to be managed appropriately.
You need to figure out who the "important people" are, and somehow make sure that they understand and buy into the product definition, delivery dates, etc.
Even if they're 3 levels up from you, and you can't normally interface directly with them, try to find a way to double-check that all the "important people" are on the same page.
Organizational dysfunction happens, and you have to succeed despite that possibility.
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.
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.
Rather, what I got was that the spec is an incomplete description and there needs to be more inquiry into how the software is going to be used. This can require a little bit of 'going up the stack' to see how business need relates to the software requirement(single enterprise customer with a precise requirement, acquisition of new customer, software for some internal vision of CEO etc). Compare with a startup where one doesn't even have a spec and one is trying to find a product-market fit or when developers take sales calls and find new insights on how the software is actually being used.
A completely broken spec is indeed a failure in management process. But, in general, it helps a library developer to think beyond a library spec and see how it is being used.
1. Focus on stakeholder management
2. Know and understand what you build end-to-end
3. Because of 2. you can quickly assess the impact of various options to resolve a problem and communicating this back to stakeholders, generating trust
I like the example of 3. In the blog post.
So many people run projects like they just coast around. Never a moment to pause, reflect and proactively thinking about potential risks and possible mitigations.
Oh my, we never saw this road block coming, how could we have known? Well..
This article is not about “shipping”software.
It’s about pleasing upper management. Those are not the same things. The article even says it explicitly - if your users hate it and the market laughs, but executives like it, you’ve shipped. If you’ve given users the best software ever but your executive management doesn’t know, or even actively hates it, you haven’t shipped.
Blech.
I agree with you: It totally sucks that this is the way the business world works.
But if you want to work within the confines of this flawed system, you need to know how to navigate it well, and I think this post does a good job of giving you the guided tour.
There is a failsafe, however. The post points out that if the project launches and users love it and it makes the company a ton of money, then upper management is going to find out about it even if you don't tell them, and they will be pleased that you have made the company a ton of money.
The reality is, most of the time when you “ship” your software, executive management neither notices nor cares. Even if you get the “attaboy” from a manager, they will forget it 10 minutes later.
You ship your software because you care about work, and maybe because you care about your users. In a big software company, shipping is not going to get you noticed unless you are literally the guy delivering gmail or google maps.
To be clear, the pathway to management noticing is not you going around the building loudly blaring that you did a thing, it's that churn went down, or ARPU went up or CAC went down or uptime went up or something management cares about.
But the essential thing to also understand is that this doesn't just happen for free. Figure out what metric your ship is meant to affect, put monitoring in place and proactively notify those above you about how your ship impacted that metric. If you don't do this last step, you didn't ship.
your reality might be different than mine, but things that got shipped definitely get noticed because they are used as a bargaining chip for promotions, funding and for visibility of the entire team, that's one of the main concerns of a manager (unless they've checked out and are searching for another job)
The game wouldn't be happening without players.
I think it's fair to let them vent that.
You will not get a product thats not search off the ground at google.
You will not launch something else then windows / now cloud at microsoft.
Even if it makes money. The old chieftains domain has to wither and be in retreat first, before something new can be started with all the resources available.
Its really exotic, if cross domain success is achieved. Amazon logistics and then AWS is such a example. If you look under the hood, the companies that allowed for that- are often more conglomerates, basically smallerish independent companies within a brand-trenchcoat pretending to be one large company. Youtube is also such a thing.
My pet theory is, that its company internal value chains, the chieftains depend upon that allow for such things to form. Like search is advertising and needs data. And data comes from the engagement guys down the hall in the other building.
Now corporate-y things like playing office politics is order of the day in medium to large tech companies.
My (maybe uninformed) hypothesis is that tech made so much money that it brought in the MBA and HR types who brought their corporate culture with them.
Even the smaller tech companies are now mimicking big tech culture as the standard.
This is some strange engineer's fantasy, that every company was ruined by "MBA types". Meanwhile, as evidenced in places in this thread, "software types" don't even understand basic business principles. They like to believe that if they were just left alone they'd churn out brilliant product, as if a large business isn't far more complex than that. Someone needs to count the beans (MBAs) and someone needs to deal with the people (HR).
That's when all the people like the article's author crawl out of the woodwork and start claiming responsibility for your work.
Big companies are like government bureaucracies now.
Large organizations are, by definition, bureaucracies regardless of being public or private. Big companies were bureaucracies 100 years, and they will be bureaucracies in 100 years. I never understand why people expect private enterprises to be free from the inefficiencies inherent to coordinating lots of people and things
It's a bit cynical, but that doesn't mean it's not true.
If you want to ship software without worrying about upper management opinions, go work somewhere smaller.
You can still please end-users AND upper management at the same time. That's what I would aspire to do in that situation.
If you're a smallco you don't have that tolerance on margin of error, small fuckups directly reflect on your pnl.
Job advancement rather. Career advancement is possible by making users happy and telling executives at other companies "I did that". It's a better story if you had to fight for it.
Really your option is to work for yourself. There is no company of any size > 1 where you don't have to worry about owner/manager/executive opinions.
Or education, where it's possibly a politician or a government beancounter and a student.
Almost all of us here has worked on a ticket that made us say "The fuck is this shit im working on, who will use this? Who the fuck came up with this?"
And we just work on it, take the paycheck, and move on to the next one lol.
That's not the reality with any software that actually matters, no matter how hard M.B.A.s try to abstract the human factor out of it.
Good software isn't manufactured. It's created. It takes thinking, and planning, and crafting, and all those things that are the opposite of a plastic widget factory that "ships" products to its customers.
Don't let then dehumanize the profession any more than it already is.
MBA practices cannot deal with uncontrollable production. But software engineering is utter chaos. So they try to come up with bullshit units that can be easily managed in their opinion. But it never works - aka, a nimble competitor always eats the giant in software.
The MBA style practice does work in factories and warehouses. But in software, a nimble startup with own the incumbent just be providing higher quality value.
(Even art, of course, is in practice pretty close to this. MBAs are paying you to sublimate your creative energies into a snappy video on how to sign up for Robinhood or whatever, and there are substantial business constraints on both its content and delivery date.)
Little comprehension about cost engineering, maintenance, safety, durability and resilience. Half-baked bodies of knowledge. CV driven development. Fads and critical production systems held together with spit, tape and hope. It’s like Aristotle’s Cave in our field.
There's no way to engineer it such that you don't get to live in this reality. Be it tech companies, marketplaces, politics, revolutionary movements; once you reach a critical mass of people, all meaningful change looks like this.
It's about the customer recognizing the product as something they are ready to buy, which is associated with the dictionary definition for shipped "(of a product) be made available for purchase."
It falls apart slightly in that the customer technically starts buying the product on day one, while it is still just a glimmer in someone's eye, but "shipping" referring to the point where the customer says "Yes, that is what I wanted" is close enough to stay within the intent of recognizing something available for purchase methinks.
> If you’ve given users the best software ever
Of course, in context, the users aren't your customer. They may be someone else's customer, but that wouldn't be shipped by your hand. Your delivery is limited to your customer.
You'd be in good company.
In my experience, there are plenty of people at BigCos who are more interested in covering their ass to ship nothing or the wrong things.
There also used to be alpha testers, i.e. your own staff. There's another subset of users and one that probably still can tell you if they hate your software today.
Also lots of "hackers" who measure success by how much money has been made, be it by a company or person.
I mean it may not be impossible to be a hacker and believe those things, but it should at least be a rare thing.
As an engineer, you can try to explain your perspective once or twice, but then you just go with what will please executives.
You need to be able to sense the company direction, communicate clearly, manage the risk, build the trust. This is not an easy task in a big company.
Such an awesome article IMO that explains the art of shipping in a big firm. I believe if any engs can master the skills described in the article, you will get promoted to a leadership role very fast. Of course, this might not be the path everyone loves.
Focusing on the tech and even product UX minutiae doesn’t typically get the headspace you need from senior management for rolling down tech debt, the headcountb you need to really ship useful and market leading software.
To go and call that "shipping" is a stretch in my opinion, it is only correct as far as your cynicism, semantic tolerance, or resignation to mediocrity can stretch. But with reduced perspective and a slight ego, it's hard to tell that things can be different.
If you dont want this, you'd need to become your own boss - in which case, you ship when you feel you've shipped! You can argue that this makes you more aligned with your customers. And i'd agree - you've made the customers your boss directly. So now, they determine if you've shipped or not.
So the only situation in which this is different (or still the same tbh), is if you're your own customer.
The good situation is when you get paid to do the thing, because you're getting paid by someone who cares about whether the thing is done. The bad situation is where you get paid to make a Potemkin version of the thing because the person paying with you cares more about the appearance than the reality, consciously or otherwise. You can redefine words and say well obviously when they told you to do X they were just doing an elaborate LARP and there's no deception in doing Y and telling them it's X, but that's just sophistry.
Working for arms-length counterparties helps, as that naturally forces communication to be more explicit and honest. Working in small businesses where reality tends to intrude more quickly helps. Of course neither approach is perfect.
> If you ship something users hate and makes no money, but your leadership team is happy, you still shipped. You can feel any way you like about that, but it’s true. If you don’t like it, you should probably go work for companies that really care how happy their users are.
It could be as well called “doing your job”. “Shipping” your job/work doesn’t seem like a stretch - especially that definition is clearly stated in the article. It’s also nice play of words that emphasises the fact that many people seem to get the rules of this game wrong.
Title would've been better fit "How I climb the ladder at big tech companies"
If the customer isn't using the software, it hasn't been shipped to them.
Enable someone to hit a revenue target, compliance measure, etc. if leadership doesn't care about that or can't work to that kind of framework; they deserve to go the fuck out of business.
Treating it as "please management" is incredibly self serving. You please management by often making them money; sometimes despite themselves.
The article also made it abundantly clear that if you find yourself in that situation, and you don't like it, you should find another job.
The article isn't about the ethics of the situation, career choices, ect. The rest of the article focuses on more important details about shipping software.
Give the article another chance. I skimmed it twice yesterday and now that I'm not reading my phone on the throne, I gave it the attention it deserved.
---
I should also point out that I've had a lot of career success in situations like this by disagreeing and committing. Turns out that a mild degree of patience in situations like this often means I get to focus on very clear customer pain points and build industry-leading software. (I just don't get to focus on them the exact moment I want to.)
It's not about "pleasing upper management" is about understanding that a product isn't "shipping" just because you can launch it the software. The entire company needs to be on board.
I think a better definition of shipping is ensuring your project meets the definition of done. At big companies, for many projects, I think there's an implicit requirement in the definition of done that management is aware of and somewhat happy with what you shipped. The resources used to ship a project (the time, money, and people) are, after all, their resources.
I feel like you're getting at the fact that you can build a crappy product that management loves and build something customers love that management hates. I don't disagree with that at all, but to me that's kind of tangential to whether you've shipped a project or not. To me at least, shipping isn't about it being good or bad, it's just about it being done. I think what the article is getting at is that if management doesn't agree that it's done, then it's not really done.
you think you've given users the best software...
people overestimate their ability to know what's best, and everyone thinks they are the exception.
“I ship at big tech” is a broad statement… as a reader, I need elaboration or I tend to question the rest of the article. Is this just a guy bloviating or does he really know his stuff? And bold claims need to be back up.
Looks like: ZenDesk and GitHub are the "big tech".
Projects shipped look like:
<doing a poor job> --- <doing a average job> --- <doing a good job>
Whereas the more accurate mental model is:
<doing nothing> --------------------------------------- <doing a thing> -- <doing the best thing>
The former mental model is intellectually satisfying because you get to infinitely yak shave over every little tradeoff and doing nothing isn't even on your mental radar.
The latter is deeply humblingly mundane and doesn't get to center us as masters of the universe which is why we all initially resist it. Even for the people who become great at it, they become great against their inclinations, and still have to fight the urge at every step.
This doesn't just apply to tech, look at it in politics. How much time do we spend in politics debating policy? Which of our different political philosophies lead to different tradeoffs that are a deep expression of our values? How much time in politics do we spend debating state capacity? A state that can do none of the things, it's irrelevant which of the things we want the state to do. A state that can do more things, almost always just the sheer option of things they can do means they can find a better policy.
And yet policy arguments are just so fun while state capacity arguments are incredibly wonky and depressing.
But I've drawn that same diagram on 100 different whiteboards in front of 100 different juniors and said the same words of "before we figure out how to do the best thing, let's just see if we can even do a thing first" and it seems to have gotten through to an appreciable number of them enough that it feels like a high converting meme.
I think that a more accurate mental model would accept that a team sometimes has no idea whether a change will get them 80% of the way there with 20% of the effort, get them 20% of the way there with 80% of the effort, do something somewhere in the middle, have zero impact, or even make the product worse.
We call this role something like "lead developer" and it's as much about people, relationships, logistics, and documentation as it is about technical systems — but like TFA says, it's also your job to have the best holistic understanding of the technical system. A lot of more junior engineers are likely to work on a large project, and they will inevitably need guidance to satisfy the constraints of other parts of the system. You are responsible for knowing those constraints and, as much as possible, preventing mismatches when different components come together.
Meanwhile, the non technical staff (whether it's a manager or someone from the sales team, documentation team, customer support team, etc) are going to need someone who can explain the technical system to them in plain language. "Can it do this? How fast? Why can't it do this?" You tend to become their main interlocutor.
It's kind of your job to anticipate problems before they happen, to look into the future so you see what's coming and solve it in advance, and then to show up all the time when something needs help around launch, which it always does. It's very undefined but there's always something that needs doing.
This role doesn't sit well with some engineers who think their job is basically about coding and staying within their lane — those engineers don't get to be lead dev too much, because they don't do well with the organizational side of things. (It depends, of course, whether there is a hands-on project manager who can pick up a lot of that slack, but where I work, we don't always have that.)
(Context: I have worked in a large tech company a little more than 3 years and shipped some things. And before that I shipped a lot more things in smaller places – I like to think that shipping in small shops was a good prerequisite for shipping in large ones.)
I could really relate to this. Having been part of incidents, I fucking hate them and try to anticipate them with various safe deployment strategies. To leaders though it apparently seems like Im not doing anything because “nothing ever goes wrong” lol.
They are not leaders. They are managers more akin to administration or HR.
True, but that doesn't mean you have a good leader. They are hard to find, but not impossible.
This feels like it’s written by AI by a junior level “prompt engineer”
> Shipping doesn’t mean deploying code, it means making your leadership team happy
Aka, corporate glazing. Gotcha. Over sell your corporate accomplishments and polish your turd with a clean deck. Gotta make sure the font is just barely legible and explain it quickly before they ask follow up questions
> You need your leadership team to trust you in order to ship
yea that’s why I get _paid_ to do work, not glaze c-level executives and appeal to their fragile egos
> Most of the essential technical work is in anticipating problems and creating fallback plans
Falling back is a loser mentality.
> You should asking yourself “can I ship right this second?”
no, I should be asking myself, “why am I still at this dead end job that asks me to constantly ‘ship’ a broken product. Leadership doesn’t want to encourage delivering value to the customer”
> Have courage!
You don’t need courage at a “big TeCh” job. Just be slightly competent and you are already light years ahead of your colleagues
Is it wrong, though? This is a pretty much universal phenomenon. It's less about real goal X and more about making sure the boss feels good when you're around.
That usually correlates with being a good worker, but not always.
> why am I still at this dead end job that asks me to constantly ‘ship’ a broken product.
Because the economy is broken right now and my country is gaslighting me into think it's perfectly fine for rent to go up 50% in 2-3 years and groceries to double.
There's definitely a storm coming, I can worry about my passions again when it passes.
Deploy often. Every day. Keep momentum. Ensure you have a chat box to talk with users so they can complain. Profit.
EDIT: clarified the ethical question.
And that has nothing to do with ethics.. The spec is outdated by the time it makes its way to you, and odds are it was flawed from the start in some way.
And again this isn't because someone is bad at their job, it's because the business reality and conditions are constantly changing.
And so someone needs to be keeping an eye on both of those things and steering the code delivery parts of the work to stay aligned with those changing business conditions.
To your comment about politics: I would say that from a high enough viewpoint "happy customers" should converge with "happy leadership" even if it doesn't happen every single time you ship something..
If those two things don't converge, the company won't be around for long and then politics won't matter much, will they?
Have you ever worked at a big company? The level of dysfunction that can be sustained over years or decades at a place with decent market foothold is staggering.
Of course there are exceptions to the rule..
Let's reframe as "trending up" and "trending down" based on customer happiness then..
Over a long enough time horizon, and generally speaking, I still believe I am correct.
We're all posting short messages here, not essays.. There is so much room for choosing to interpret each other in different ways.. So it's inevitable that we'll be misinterpreted sometimes.
And yes, I did try to reframe to better make my point, because I do think I'm right.
Welcome to HN, but a word of advice, this kind of snipey low-value shitpost is typically not welcome here.
To look at a concrete example, with the quality issues Boeing has been having in the recent years, we can claim "happy leaders" diverged from "happy customers".
Yet Boeing will still be around for a long time, and failures can be catastrophic. Whistle blowers who came out since can be said to have advocated for "happy customers" against "happy leaders" but were suppressed.
It is a decision each engineer makes when performing their job.
Ethics are not situational. An individual either values and adheres to them or does not. Specifically excluded from this position are mistakes people make and then strive to not repeat, as no one is perfect.
I'll stand by my first line that nothing exists in a vacuum.
If you only make decisions in isolation or without broader context, whether based on ethics or otherwise, then you will inevitably make the wrong decision, I would argue, more often than not.
Context matters, and the same decision made at different times and in different situations can have completely different outcomes or impacts.
What if "making the customer happy" costs so much money that it puts the company out of business? Do you still focus on only making the customer happy?
What if you have to piss off your customers, for a period of time, to save the business so you can get back to making the customer happy eventually?
Or a less dramatic scenario, what if making the customer happy makes your co-workers' jobs hell, for reasons outside your, or their, control? Is customer happiness then still your singular focus at all cost? Because then you're a shit co-worker in my view.
Is your only responsibility to the customer, or do you feel any responsibility towards your co-workers and/or their jobs & livelihoods?
Life and work are messy and complicated, and everything is a series of trade-offs.
Companies from startups to large enterprises deliver solutions that 0 to some customers use that was mainly to appease whatever vision your leadership has. AI chatbots in websites are a big one that I can think of.
This is the exact opposite of what we're seeing with Enshittification at the moment.
Customers are locked in to a platform and then made completely miserable by management who have goals utterly unaligned with customer happiness.
Most companies who choose to do this are taking advantage of a period of market or segment domination where they know users don't have good alternative options, and will tolerate some level of garbage because they still want the service or product.
Note that highly competitive industries or market segments typically don't see as much enshittification...
you work for the company, not for your abstract imagination of what users want. if you genuinely feel the company isn't aligned with users, then try to change that.
it's not unethical (per se, obviously don't build bombs for them) to please your employer.
What are the ethics of pleasing your managers and/or executives at the expense of your employer?
My entire concept of "what is ethical?" has undergone a transformation. It's not about my ideals any longer, or about feelings, or about how gentle or aggressive management acts in negotiations. It's about much deeper things-- like when I'm asked to support something I find distasteful, I need to really investigate whether, in context, it's actually something which violates my conscience. You know what? It almost never does.
These are the two questions that matter most in my view: 1) Am I honestly being required to do something that harms someone worse than the status quo, and 2) Is anyone around me having a medical emergency - including certain serious psychological issues - that I can help with? Aside from those two things, there's a lot of ugly crap that you can still keep trucking through.
Many people, particularly (but not only) younger ones, are oversensitive to things they simply don't like but that aren't actually wrong in any major way. You've got to choose your battles.
In civilian life, you have a duty to disobey if what your employer asks of you will unnecessarily harm people. For example, shipping a broken insecure product that handles PII/PHI/etc is absolutely unethical, and possibly illegal (though often the legal consequences are minor, if not irrelevant). Your bosses will absolutely ask you to do illegal and/or unethical shit, so you always need to be aware of where the line is, both legally and ethically.
It's not always clear where the line is. With AI work, the line has already been crossed several times (things like discrimination in output resulting in innocent people being hurt). Do not do whatever your company asks for. Do push back when you see a problem. Don't ship something that could hurt someone. If you're not sure, ask or find out.
I'm not sure that has to be said, but yes, don't do illegal stuff.
You then push this question further outside the legal/illegal bounds.
The Nuremberg trials established this after WW2: just obeying orders is not sufficient [0]. This is why modern militaries have a duty to disobey.
It's the same in civilian life: you have a personal duty to disobey an instruction that you personally consider to be unethical. You cannot hide behind "I was just obeying the law". You absolutely should break the law if you consider that law to be unethical. It is your personal responsibility to decide this.
So yes, you should do illegal stuff if not doing said illegal stuff would be unethical.
[0] https://en.wikipedia.org/wiki/Nuremberg_principles
"soldiers have an ethical duty not to follow an order that is illegal"
My point is that us Software Engineers have the same duty, in my opinion. If some pointy-haired boss tells us to build something that will cause misery for our users, I think we have an ethical duty to refuse to do it.
Look at Boeing for example, I bet leadership was very happy with the fat stock bonuses and I also bet a lot of engineers "shipped" products following the author definition of shipping.
So much so that the "if it's not Boeing I'm not going" became "if it's Boeing I'm not going".
Personal take, but if you are only playing politics you are a politician and not an engineer.
[1] https://en.wikipedia.org/wiki/Enshittification
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.
Hopefully there is not misalignment between satisfying leadership goals and delivering end-user solutions.
But if there is, I hardly classify that as an "ethical" dilemma for the team members.
> Hopefully there is not misalignment between satisfying leadership goals and delivering end-user solutions.
This is precisely the situation I identified. Reproducing a quote from the article:
> But if there is, I hardly classify that as an "ethical" dilemma for the team members.If not having to choose between corporate politics and delivering solutions, then what would qualify as an ethical dilemma for an engineer?
This too harsh. There's nothing unethical about delivering what your manager tells you instead of what you believe the customers need. Going rogue — as opposed to doing what you're told — is not necessarily the ethical choice.
All the bad connotations we get from the word are because humans are humans. There is no better model that works in any kind of society/ organization/ group other than "politics".
Somebody "ethics" may not be the same as others. (Is it ethic to spend a lot of money and deliver something that does not fit the expectations of the ones that provided the money? It may be easy to make users happy - just give them free movies, etc.)
And you will feel the toxicity created by this kind of poor leadership by way of constant blame games, misalignments, and unnecessary stress over garbage.
And you will pay the cost of it with time, physical and mental health, and career longevity.
Ultimately you are signing up to be servants and servants are not valued within or outside the organization.
I call it my volleyball theory, after playing on a mid team back in college. If the ball is coming down near a large group, no one gets it. If you're the only one there, you'll get that ball one way or another!
Why not list some of them that I can actually try out? How should I give this any credence if I cannot evaluate them?
I have always associated new software versions with with my the word "release", "released". While shipped is not an incorrect term to use for software. Release just feels more appropriate.
Has anyone else noticed this?
All of that said, I am not condemning the practice in the least. Just interested in the etymnology of one of my favorite areas of interest. Hopefully draw some more knowledgeable folks on the question.
[0] https://quoteinvestigator.com/2018/10/13/ship/