15 ms·

How I ship projects at big tech companies

• philipwhiuk 2y ago
  > I often get tapped to lead new ones when it’s important to get it right, because I’m good at it. The ego is just bleeding out of this sentence. He's a SSE at GitHub.
• 0xB31B1B 2y ago
  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.
  • abhpro 2y ago
    The author just shipped the post
    • dpkirchner 2y ago
      We can't be sure of that -- what did their boss say? That's all that matters.
  • dpe82 2y ago
    If they aren't paying attention then move to a project they /do/ signal interest in with their attention, and ship that.
  • sbarre 2y ago
    > Yes ok great, how do you get their attention 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.
  • gfysfm 2y ago
    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.
  • drc500free 2y ago
    Internal Marketing is the primary role of the Product Manager at a lot of big companies.
    • whstl 2y ago
      And this is why it sucks so much to work as an engineer on big companies. 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.
• thefourthchime 2y ago
  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.
• jeffrallen 2y ago
  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.
  • dr_kiszonka 2y ago
    I love the example with pigs haha!
• deleted 2y ago
  [deleted]
• simonw 2y ago
  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!
  • NBJack 2y ago
    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.
  • didibus 2y ago
    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.
    • bigiain 2y ago
      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...)
      • OnlyMortal 2y ago
• louwrentius 2y ago
  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..
• Scubabear68 2y ago
  Ugh. 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.
  • jawns 2y ago
    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.
    • Scubabear68 2y ago
      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.
      • shalmanese 2y ago
        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.
• therealdkz 2y ago
  [dead]
• mtnGoat 2y ago
  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.
  • didibus 2y ago
    Resume is here: https://docs.google.com/document/d/17Ql6AydCJ7-XhjrwEqzmRAaAaooARTS5vjEhBZGfrbE/edit?tab=t.0#heading=h.e1j1tsz3xru9 https://docs.google.com/document/d/17Ql6AydCJ7-XhjrwEqzmRAaA... 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
    • mtnGoat 2y ago
      Thank you for looking that up, I was on mobile and being lazy. So it looks like he’s done some decent sized stuff.
      • tonyedgecombe 2y ago
        Or claims to have done so ...
• shalmanese 2y ago
  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.
  • strken 2y ago
    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.
    • 392 2y ago
      Why don't you fix it?
• decasia 2y ago
  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.)
• pm90 2y ago
  > 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.
  • nine_zeros 2y ago
    > 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.
• efortis 2y ago
  > If you ship something users hate and makes no money, but your leadership team is happy, you still shipped. True, but that doesn't mean you have a good leader. They are hard to find, but not impossible.
• GPerson 2y ago
  It sucks that this is what life is all about.
• xyst 2y ago
  > 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
  • johnnyanmac 2y ago
    >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.
• cynicalpeace 2y ago
  My Indie Hacker version of this: Deploy often. Every day. Keep momentum. Ensure you have a chat box to talk with users so they can complain. Profit.
• AdieuToLogic 2y ago
  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. EDIT: clarified the ethical question.
  • sbarre 2y ago
    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?
    • ozgrakkurt 2y ago
      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.
    • 2y ago
• nine_zeros 2y ago
  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.
  • a_bonobo 2y ago
    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.
  • swiftcoder 2y ago
    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.
    • nine_zeros 2y ago
      > 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.
• roland35 2y ago
  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!
• deleted 2y ago
  [deleted]
• zeroonetwothree 2y ago
  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.
• TwoNineFive 2y ago
  It's a self promotional advert blogspam.
• abc-1 2y ago
  > 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?
  • lytedev 2y ago
    It's more work, NDAs, and probably not particularly relevant to the article. Why list some of them?
  • rovr138 2y ago
    Go to their resume from the home page, https://docs.google.com/document/d/17Ql6AydCJ7-XhjrwEqzmRAaAaooARTS5vjEhBZGfrbE https://docs.google.com/document/d/17Ql6AydCJ7-XhjrwEqzmRAaA...
    • abc-1 2y ago
      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.
      • swiftcoder 2y ago
        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.
• oneturkmen 2y ago
  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.
• gjs4786 2y ago
  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.
  • eurleif 2y ago
    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. [0] https://quoteinvestigator.com/2018/10/13/ship/ https://quoteinvestigator.com/2018/10/13/ship/
• blinded 2y ago
  This aligns with what I've seen and the issues I've had shipping high leverage things at an enterprise. Its way more communication, selling and documenting more that it is a technical issue. Nice post.
• aorloff 2y ago
  > If you ship something users hate and makes no money, but your leadership team is happy, you still shipped. Well now, hold on a second. You didn't tell me this was about consulting. If we're being paid like pirates and fightin' like pirates thats one thing.
  • mihaichiorean 2y ago
    I shipped something users (internal) loved and the users were pushing adoption across the company. My leaders didn't consider it shipped. They never talked to the users. Didn't care. It needed perfect alignment with the org and needed to help the org's plans. Not the company or users across the company.
    • deleted 2y ago
      [deleted]
    • high_priest 2y ago
      The users were happy, but you didn't get paid, or got fired for using company time out of assigned scope.
    • Aachen 2y ago
      I'm not sure this demonstrates the issue without more context. If the people meant to use it were happy, what problem did the "leaders" have with it? Was it a huge moneysink whereas it was supposed to be an extra income source or like what kind of issue even
• gorgoiler 2y ago
  The idea of “shipping” as being an emergent state of mind is a great one. A project grows the same way an embryo grows into a full animal: it does so in millions of tiny parts that overlap in discrete ways to produce a continuous spectrum of development. I think some good additional milestones to measure that kind of development might be as follows: * Your first bug report that you file against yourself which you fix yourself. Your project is stable enough to be usable with a known bug, but you go back and fix that bug when you have time to dedicate to it. Contrast with nothing working until everything works. * Your first time seeing someone find a flaw that lies so far out of your own mental model of the project that it causes a very jarring feeling, hopefully followed by excitement that the project is now taking on a life of its own outside you / your team as the sole developers and users. An example of this might be someone filing a bug that image rendering is missing from a git visualisation tool where you’d never even considered using it for projects with version controlled image assets. I feel like there’s an analogy here to a baby’s first detectable heartbeat and a child’s first original that-never-occurred-to-me thought. There must be a lot more in between too, with the social acceptance of a project becoming shipped as the child entering the adult world as its own person.
• deleted 2y ago
  [deleted]
• bjackman 2y ago
  The practical advice in here resonates very strongly with my experience, I like the analysis a lot. The philosophy about what "shipping" is... Presupposes that your motivation for working in big tech is to get to L9 and make 7 figures or whatever. Dunno about that. (Also I suspect there's a ceiling on where you can get by being really good at shipping). I like to think I do this shit on my own terms, I have my own goals. Pleasing leadership and getting good ratings is very often instrumental to those goals (and money is great) but I think I still get to decide what shipping means to me.
• nitwit005 2y ago
  Learning how to cancel, or quietly bury projects, can be just as important. You're quite likely to be handed projects that make no sense. Bad ideas are created every day. Even if you ship them, you may be associated with their failure.
• makerdiety 2y ago
  [flagged]
  • defrost 2y ago
    > What are your thoughts of this stance of mine? As you asked and in the spirit of an honest response: * Overly performative, * self indulgent, * attention seeking, ... are literally the first and foremost thoughts that spring to mind. Your stylistic accoutrements are obscuring your message, perhaps you might want to simplify your delivery.
  • Gigablah 2y ago
    “You really enjoy hearing yourself speak”.
• mirekrusin 2y ago
  Great to hear somebody on the internet actually gets it.
• benreesman 2y ago
  This is a reasonably good if somewhat depressing blog post about how to do well in the performance cycle at a big company. Now part of that is shipping product, but that’s pretty clearly of secondary concern for the author. It sounds to me like this person is good at getting paid no matter how it goes for the shareholders or the rest of the team.
  • baxtr 2y ago
    I think you’re describing any person’s life within a larger social construct. I don’t see how you can achieve any meaningful goal without collaborating with people in power.
    • 0xpgm 2y ago
      > I don’t see how you can achieve any meaningful goal without collaborating with people in power. Depends on how you define meaningful. Raising happy & healthy kids, helping someone in need etc, can be meaningful to many people, but don't require 'collaborating with people in power'.
      • idra 2y ago
        But it does. At the very least, you need to keep paying off the people in power and do everything within the framework of their rules, otherwise you’re in trouble
        • Aeolun 2y ago
          I’m fairly certain you can go live somewhere off-grid and do everything however you want. It’s only a tradeoff if you also want all the convenience of modern society.
          • xenocratus 2y ago
            I'm fairly certain statistically you can't, because you need a place to go do that, the skills to pull it off, and have a family that's not only willing but actively supporting it, otherwise when the reality kicks in everything _will_ fall apart. Either that or some of you die. But hey, technically you'd be correct in that case. Or maybe I just have a gloomy view of what "living off the grid" looks like :] I'll just leave this [1] here, regarding that. [1] https://www.smithsonianmag.com/history/this-russian-family-lived-alone-in-the-siberian-wilderness-for-40-years-unaware-of-world-war-ii-or-the-moon-landing-7354256/ https://www.smithsonianmag.com/history/this-russian-family-l...
• jedberg 2y ago
  I figured the web page would just say, "I don't".
• 0xbadcafebee 2y ago
  This is amazing satire. It's like the CEO of Hooli had a Senior-Senior-Senior-Senior-Engineer blog. (more amazing: 54 ships, but not a single leader-ship joke. that takes nerve.)
  • ctenb 2y ago
    I don't think it was meant as satire. I didn't like to read it, but it resonates with my experience working at big companies, like many others here.
• kqr 2y ago
  Excellent article. I'm going to pull out one point out of many that made me think: > Project competence. You want to aim for something like a NASA mission control vibe Having read a little about early Apollo-era (and earlier) mission control this was a fun comparison. The astronauts and flight controllers had no idea what they were doing! There was no textbook – they were performing a human first. They were generally young and very cocky people hired out of university, but were successful anyway, for some reasons, including: 1. They were further culled through harsh adversarial simulation training. This made sure only those that could cut it came out the other end. 2. They approached each new mission phase with a trial mission, each time extending the envelope in a controlled manner. (The cowboy moon touchdown on Apollo 11? It's often described as the first moon landing, but it really wasn't. It was just a test to see if they could reach the surface and get back up. The real first precision landing came on Apollo 12. Oh, but that was also just a rehearsal for the first scientific mission on Apollo 14, etc.) 3. They were fluid in how they organised themselves, and allowed mission needs to dictate which positions existed, rather than trying to impose a hierarchy onto a mission. Going back to shipping, we can squint and look at this as: 1. Fake it, either until you make it or get tossed out. 2. Prefer to ship many smaller things than one big thing. This builds confidence in your abilities, gets you experience shipping things, and allows you more feedback to adjust to what the real project is. 3. Build coalitions across department boundaries, and draw on their support to ship. Analogies are like scissors: more fun when you run with them.
  • cadamsdotcom 2y ago
    Agree strongly with your entire comment, but am _definitely_ stealing that last sentence, it was quite a sharp take.
• dkga 2y ago
  Excellent piece. My observation in less technically-oriented but still innovative companies: shipping also occurs when you post about it on LinkedIn and can show with a concrete example (a graph or a small video)
• bluSCALE4 2y ago
  Articles like these really speak to me. In a lot of ways, developers that claim to take ownership might be a few small cognitive steps from actual ownership aka have shipping in mind. Lots of take aways to prevent headaches and pain points.
• kookamamie 2y ago
  Hear hear, I share these observations almost as-is.
• desaiguddu 2y ago
  100% relate to this! Some of my observations: - Often it is about taking a leadership & ownership of fixing if it fails in the production - Often it is about, guiding team not to overengineer for the future scenarios This becomes 500% difficult when you are building for someone else: In our current scenario, we are working with a semi-government organisation who goes by the RFP fine print then an actual project needs.
• meditativeape 2y ago
  This is so true. Now I know how to describe the work I'm doing!
• shalmanese 2y ago
  If you want a different but equally opinionated perspective of how to ship at scale, I really like Herb Sutter's FAQ on why the C++ standard ships every 3 years (from 2019): https://herbsutter.com/2019/07/13/draft-faq-why-does-the-c-standard-ship-every-three-years/ https://herbsutter.com/2019/07/13/draft-faq-why-does-the-c-s...
• fergie 2y ago
  This article is an expert-level primer on office politics in big tech masquerading as a primer on delivering software.
  • rk06 2y ago
    Yes, and because of it alone, I consider it one of the best articles of this year read by me.
    • user_7832 2y ago
      Agreed, as a green/still inexperienced employee it was quite a good read.
• ThinkBeat 2y ago
  A constant focus on keeping the architecture,infrastructure and codebase quick/ease to ship is to "Keep It Simple Stupid". Be critical about adding new services or complexity. Ask yourself can this be solved in a way that does not require changes to the shipping process. If no, evaluate possible alternate approaches. A fanatical dedication to monitoring the production system is beneficial. The faster you can catch that the last deploy screwed something up, the less stress and down time there will be. The shipping process should also include the ability a rollback the latest deployment. Again less stress and possible downtime there will be. Achieving these goals is the best way to win the trust and influence on the people up the chain.
• PeterStuer 2y ago
  Oh boy. I've been around these trenches long enough to have seen the dark side of 'shipping' strategies. Rarely in large enterprise environments are projects greenfields. The new system is often there to replace some existing Line of Business system. Inthese cases the pervers but common shipping strategy is: 1. freeze all maintainance and evolution of the existing system. Seems reasonable until you realize that these enterprise projects are multi year calendar endeavours and the business will not stop changing during that time. The idea is not realy to halt all development, just to inctease the friction of getting anything done on the now declared 'legacy' system above an administrative pain threshold. 2. Commandeer all the IT staff to serve on the 'new' system's project team and overwhelm them with tasks. Make sure they remember any time spend on the 'legacy' (keep hammering in that term) codebase is basically waisting time assuring you'll end up at the bottom of the corporate dinosaur tar pit at best. 3. Force they 'new' system into production long before it is ready. Use all the leverage you build from point 1 to promise 'going forward'. When essential gaps to support the business are pointed out en mass week1, reverse the tables and intigate a very heavy administrative process demanding proof that the lacking functionality is actually required with a full ROI breakdown coutering your handwoven 3 minute overinflated guestimate for implementation. Again, you know essentials are missing, you are just trying to gain time as the longer you can stay deployed the higher the chance you will. This process is very destructive to not just the business, but also moral of most involved. Most projects taking this scorched earth shipping strategy fail regardless. This is no small contribution to the cynicism oftem found in veteran battle hardened corporate IT shops.
  • kridsdale1 2y ago
    Eventually someone important gets a call from a more important client on the golf course about how his company fucked up on his watch, the new thing is cancelled, the old one is reinstated (to much rejoicing) and the 15% of the huge new effort that actually worked is distilled in to a plugin feature and bolted on to the old product and everyone moves on. The original PM responsible for all this gets an L+1 diagonal promotion at a new company and pulls this shit again.
    • PeterStuer 2y ago
• tmarice 2y ago
  This is what purgatory looks like for software engineers.
• ben_w 2y ago
  > Sometimes it’s just an influential VP or CEO’s pet project, and you need to align with their vision. My biggest career mistake was a project that I had no way to know was the CEO's pet project. Can't say where (non-disparagement agreement), but oh boy was that a lot of messy fallout — QA awarded me a prize for least bugs on launch, yet at the same time line manger also immediately went from giving me bonuses to putting me on a PIP for having too many bugs in launch.
  • sethammons 2y ago
    optics. If the CEO is reporting bugs they find or those bug numbers appear "concerning," the apparent lack of quality calls for corrective action. Obviously things were not the healthiest there. The CEO should be similarly interested in other projects and their quality. Your manager should be aware of the relative quality and your award and tell his manager that "it has been / will be dealt with" and then to either never file the pip or speed run you through it (while letting you in on why: optics). And then the manager should be working towards producing better reporting metrics that executives can use that expose quality issues at large
  • sumedh 2y ago
    > went from giving me bonuses to putting me on a PIP for having too many bugs in launch. Dont you have some kind of tracking to show the bugs were not in your code?
    • ben_w 2y ago
      Least bugs, not no bugs. I'd like to say I can code perfectly, but I'm a mere mortal not Donald Knuth and I can't get away with saying "Beware of bugs in the above code; I have only proved it correct, not tried it." We had tracking of launch bugs, the manager ignored the evidence — that didn't make any sense at the time, then I developed a better understanding of office politics and suddenly it became easy to understand.
• up2isomorphism 2y ago
  Even what he said is valid for most big tech today, it is still a reflection of how messed up today’s tech jobs are.
  • salviati 2y ago
    Yes! And the most interesting thing here, to me, is how the crowd splits in two groups: one group basically saying "That's how it goes, if you wan to get paid (and you're not intelligent if you don't) you need to play this game, even if you don't like it" and the other saying "This is unacceptable. We need to first recognize that the state of things is not good, so that we can then act and change them. So let's start by stating that this should not be accepted. It's wrong to accept it". I belong to the latter group.
    • up2isomorphism 2y ago
      Agreed. What I am a little surprised is that some engineers seem to trying to defend something that is knowingly bad just because it is the status quo. BTW, I don’t think catering the upper management as described is the only way to get paid. I ignored many upper management’s preferences because they are plainly stupid and in some situations get fired. But I still made good career growth and so do many of my friends. In fact being in a conflict and holding position tends to give me higher rate of returns, even in case not being able to “ship” as defined in the op.
    • sethammons 2y ago
      I wonder, given the year is divisible by four so it is on the mind, I wonder if that divide of "acceptance of what is and working with that" vs "we can be better if we make it so" is also the divide that manifests between the two political party system in the US.
    • user_7832 2y ago
      I think the first group is more of “this is how it is” rather than “you’re not intelligent if you don’t play the game”. I personally don’t find this status quo good or healthy either, but I(or anybody) have little control beyond formulating policies at a company at best, and changing their job realistically. (Fortunately my current place seems quite decent in this regard so I’m good/lucky.)
• ozim 2y ago
  *In my experience, projects almost always ship because one single person makes them ship. To be clear, that person doesn’t write all the code or do all the work, and I’m not saying the project could ship without an entire team behind it. But it’s really important that one person on the project has an end-to-end understanding of the whole thing: how it hangs together technically, and what product or business purpose it serves.* Yes that is pretty much what I see as well, I see how things go to nothing with wrong people who think they can make bunch of requirements and dump them on dev/qa - then be surprised nothing works - and also how much stuff I try to hand over ends up not happening despite people claiming that they are very motivated to pick up a project. If they are motivated and I see nothing happens in 3 weeks I just take it over again and don't even talk to the guy anymore. I am also quite often seen as an asshole because I don't ask "everyone" for permission and mostly care about my actual boss.
  • 123sereusername 2y ago
    [dead]
  • DrBazza 2y ago
    The "one single person", should be qualified with 'is senior enough or with enough authority' which allows them to set aside a lot of squabbling, bureaucracy and bikeshedding.
  • vasco 2y ago
    > If they are motivated and I see nothing happens in 3 weeks I just take it over again and don't even talk to the guy anymore. I like this sort of no bullshit attitude but at least tell the guy "I'm taking this back". Hard for your boss to have your back if you don't even say anything.
    • ozim 2y ago
      I actually meant "I am never talking with him about handing anything over" and "I am not going to ask 10x if there was no visible progress after they were swearing to pick it up" but other than that I will update the person that I am picking up tasks on my own and making progress on the thing they were "taking over".
• antonvs 2y ago
  > But it’s really important that one person on the project has an end-to-end understanding of the whole thing: how it hangs together technically, and what product or business purpose it serves. In the before times, we called this an architect. We're too agile for that now, apparently.
  • moffkalast 2y ago
    Architect? That sounds like a lot of money. We're just gonna stick some rando as the product owner and call it a day.
    • ozim 2y ago
      Let's one up by getting a rando on board as "business analyst" but expect him to do product owner stuff.
      • moffkalast 2y ago
        You look like a straight shooter with upper management written all over you.
        • shnock 2y ago
          I like the cut of your jib. Let’s let the sails loose on this venture and see if we can’t move the needle.
          • nshunter 2y ago
            Can we circle back on this in 6 months to validate our strategy with leadership?
      • HPsquared 2y ago
        Learn on the job, sink or swim, YOLO! (you only learn on-the-job)
  • Lucasoato 2y ago
• glenjamin 2y ago
  This is called project management, and in my experience seems to be a practice/discipline that's often overlooked or ignored at startups and scaling tech companies. Generally in my book projects should only be assigned to teams, and managing that project to completion should be part of that team's way of working. Doing this in an agile manner generally means smaller projects, one at a time.
  • steveBK123 2y ago
    The last "agile" shop I worked at instead did 10+ small projects in parallel (1-2 devs per project) and then wondered why we never got to where we wanted to go.
    • beretguy 2y ago
      One place I worked at did that + only 1 person per project and all projects got rotated between developers at the start of every week on Monday. And when we did stand up meeting every morning nobody cared what anybody else had to say cause we all worked in different projects. Go figure.
      • steveBK123 2y ago
        Yes, exactly the same with the rotation. It was almost like they were optimizing for bus factor. It was completely brain scrambling and unsatisfactory work as it was constant musical chairs.
      • linhns 2y ago
        If I were you I would have left immediately.
        • beretguy 2y ago
          My contract got cancelled after 1 month.
      • cruffle_duffle 2y ago
• mrowland 2y ago
  > no matter the project goal, your leadership team (the people in your reporting chain who care about the project) will always have basically zero technical context about the project compared to you. This is not universally the case, and I've been much happier when I find teams and orgs where this is not true. Good leaders understand the details. Find them. Be one.
• renegade-otter 2y ago
  It's all about the last 10% - it's what makes a project of any size see the light of day. Some thrive on that last 10% (like I do). It's the work of grinding through the final loose ends and the finishes touches, fixing the issues in the live environment vs development, etc. It's hard and boring, but it's also rewarding. And then there are most people - who just check out when it's sort of done. I don't like those people.
• EliRivers 2y ago
  a project is shipped when the important people at your company believe it is shipped Definitely. This can work very much to your favour. There have been times when I have happily shipped a product containing issues and bugs that would be catastrophic for any customer using it, because I know that no customer actually ever will. The product is shipped and released, everyone is happy. The catastrophic issues won't ever come up because that shipped product will never be used by anyone. Big people are happy because the product is shipped. Team are happy because big people have stopped causing so much friction in their desire to ship. When the measurement becomes "have we slapped the label shipped on it", then that's what you get. A label.
  • fmbb 2y ago
    It will become the headache of future team members that have to debug it when it inevitably crashes four years in the future, or needs to be rebuilt or the deployment moved. Now personally I am fine with this, being that person. I will cause friction however. Unfortunately it is the new big people that take the hit from the previous big people. But such is the way of the world, this is what we are paid for. Sometimes you get lucky and can shut things down. Then you get to celebrate that as well, shutting down the thing nobody ever used but everyone celebrated “shipping”. At least I get my celebratory cake!
• sharas- 2y ago
  In corporations, sure, nobody is concerned about the end goal. That is by design. Design by managers who simplistify everything into a manufacturing process in their "factory" Those same simplistifiers managers would love "facilitators" who are now concerned with a function of shipping in their "factory".
• praveen9920 2y ago
  I think the whole idea of shipping, at least within big tech, should follow slow rollouts starting with 0%. For example: Deploy an empty service in production with 0% rollout. Increment the rollout with each version deployed, including fixes of previous releases. This may not be great for user experience but great for getting things up and running. Although, upper management will not be happy to see slow rollouts.
• ChrisMarshallNY 2y ago
  I remember a manager that we worked with, once stating that "Shipping is the #1 feature of this software." I have been shipping (as opposed to "writing") software, for pretty much my entire adult life. A lot of it has involved holding my nose, and gingerly handing it off, dangling between my thumb and index finger, while wearing rubber gloves. This chap has a point. "Ship" is in the eye of the managers. Which is why good management is so important.
  • remify 2y ago
    I kid you not, I've seen managers claim that v1 is shipped while no software was deployed at all (it was just the production environment). All this just to say the project is on schedule (it wasn't !). I've also seen in the same company rushed QA (like ignore the guys) in order to ship faster to meet the managers' KPIs and bonuses. So yeah, shipping a project probably means something different than most developers think.
• Sandworm5639 2y ago
  As any worthwhile piece of advice, this post is not saying "Do good things, don't do bad things" but instead "Prioritize one good thing over another". Hence lots of comments. I wish there were more submissions like this.
  • ivanjermakov 2y ago
    The post is not about engineering, hacking or programming, but pleasing management. I wish there were less submissions like this.
    • user_7832 2y ago
      The reality is that it’s just the way life/“the game” is. I think it’s good to know about such things, it’s still very much up to the individual to use it/not get fired etc. Unless someone lives alone on a farm, they’ll likely need to know how to handle such things at some point (or be very lucky, or possibly suffer).
    • Attrecomet 2y ago
      It's a post about getting your software recognized and used. For that, you actually need to get other people on board, yes. If you don't care about that, why are you even working in software development? It sounds tedious to just build things nobody cares about.
• whiplash451 2y ago
  A key point of this post is here: > you have to get clear on what the company is looking to get out of the project. Regardless of politics, starting with why we are doing this project at the first place is often overlooked.
• deleted 2y ago
  [deleted]
• deleted 2y ago
  [deleted]
• krony 2y ago
  Every project has a role of Release Manager. Some teams are small enough that this role is filled by a team lead, project manager, architect, etc. some teams rotate this role to spread the pain and knowledge. Large teams have a defined employed role with title of Release Manager that could even include a team (think shipping large DoD contractual projects) There’s whole books on this subject. I think this blogpost does a great job of summarizing the goals for large tech company shipping — well written — nicely done
• deleted 2y ago
  [deleted]
• jamaicanindian 2y ago
  [dead]
• cdrini 2y ago
  I effectively agree with the "destination", so to speak, of this post, but disagree with the path taken to get there. In general when I ship projects in the context of the org I with for, I _do_ meet the requirements of higher-ups/stakeholders, but not because that's my goal -- but because we're aligned on those requirements. Shipping to make management happy feels kind of incestuous, you should be shipping because you and management both agree on what the end goals of the project are. This might seem like a subtle distinction, but it can create issues. If you're using your management as your metre-stick without truly understanding and believing in what they want, you'll likely over-optimize for the project's goals that they've stated, but miss the target of actually making the project successful. This approach is fine if you're primary goal is to get paid, get promoted, please your managers, etc. But if your goal is to create great things, I think you need set your metre-stick based on the project not on the management. From the outside these approaches look very similar -- which is why I largely agree with the "destination" and a lot of the tips in this post, otherwise.
• jgalt212 2y ago
  In large orgs, I've often felt the most important skill is convincing your boss's boss that your opinion / course of action / etc is the right one.
• jcmontx 2y ago
  This reflects my personal experience as "CTO" of a software factory. I put CTO between quotes because my role definitely shifted away from technology itself more to a delivery role. I have to delegate responsibilities to the right people, act fast when a team member is pulling its weight, allocate resources to solve problems a team can't, and even jump in and work along the team if shit hits the fan. Delivery is the hardest thing; something that works for me is trying to have a plan and not only consider features but a checklist to reach Prod. What I mean is adding all those tiny things that add up to the planning (who's in charge of the DNS? who's setting up the Twilio account? etc etc etc)
• eichi 2y ago
  The CEO is addicted to the product and fires people who are not aligned. This is the best strategy to ship the product: Elon's strategy
• jhwhite 2y ago
  I see so much backlash against Project Managers and they're just Outlook Calendars with legs, but this post is basically a love letter to good Project Managers/Release Train Engineers/Delivery Leads, whatever you want to call it.
  • econnors 2y ago
    I think the problem with those is that they lack understanding author mentions: > But it’s really important that one person on the project has an end-to-end understanding of the whole thing: how it hangs together technically, and what product or business purpose it serves. The reason people hate specialized roles of scrum masters/delivery leads is that they often lack the E2E understanding and therefor are inadequate owners.
    • jhwhite 2y ago
      Yeah but a good technical PM / whatever will have that understanding. Not a role that just checks milestones and statuses.
• agentultra 2y ago
  It’s a great post and often what I see folks doing. Hot take though: why do we need so many people and processes and mysticism around software these days? It seems to me the reason why it’s so difficult to ship anything, let alone anything good and useful, is because there are so many people involved who don’t actually participate in engineering. They manage time lines and meetings and emails and talking to customers. And somehow they’ve made themselves essential to the process so that developers can’t ship code anymore. Like… I know my users on a first name basis. I know how their business works. We’ve talked about the button and we want to run an experiment. As a developer I might want to just try it out with them. Maybe the change will be a good fit for the product as a whole, maybe it will be a solution that only works for this one customer, maybe it means we need to be able to configure which workflow is used. If I can’t just ship that and get the feedback I need without involving a handful of other people and being completely fearful that I could take down our service… what is wrong here? Is it that there aren’t enough “shippers” on the team or is it because the organization has made it difficult to ship anything? That being said, this is the world we live in, and the article has a lot of great advice. I’m definitely used to/conditioned to think this way.
  • kingnothing 2y ago
    It sounds like you are part of a pretty small business given that you're an engineer who knows his customers by name. It may very well be completely acceptable to your customers to have extended downtime, or a button that disappears during a deployment leading to a broken feature for a couple of days until you, or they, realize something is wrong. Many other companies do not work this way. If you're a huge company like Apple that makes $40M per hour, that type of downtime isn't acceptable. If you're in finance, that downtime doesn't work. If you're in healthcare, defense, aerospace, etc... that downtime doesn't cut it. Yes, you'll still have downtime in those industries from a bad deploy, but you put more checks and balances in place to reduce the odds it will happen.
    • agentultra 2y ago
      I'm not actually at a company where I know folks by name at this point. I was for a time. I currently work at a much larger company where I ship platform-related stuff that integrates a bunch of systems (card payment processing... so fintech) for other developers so that they can ship features and products to customers. I've done a lot of the work mentioned in the article. The hot-take is just a suspicion that we make things more difficult for ourselves by involving more people than is necessary to get work done, not trusting developers, etc. Update: and is more a reflection about how the industry operates in general than how things operate where i work in particular
• Ensorceled 2y ago
  This is why I'm a big fan of MVPs and quick iterations after ward. Launching a significantly complex product is HARD, even if it is an MVP. Nobody understands how hard, even if they've done it before. It works in staging, must be ready! Then users start trying to signup and actually use the product and the wheels come off. I've usually been the person that understands it all and launch week is always hell. Or depressingly boring because you have no users.
• yhoots 2y ago
  most of this makes sense but I think what would make it more useful is more focus on topics that mainly fall under project management: building relationships with key stakeholders, establishing early+clear communication channels, building in timeline slack, how to navigate management politics etc. i dont think shipping in big tech cos is significantly different to shipping a large construction project in terms of project management, but rather there is a tendency for managers in big tech to be significantly less tenured and hence ignorant of basic management priniciples that lead to easily avoidable blunders.
• bob1029 2y ago
  > Can we ship right now? Feature flags are the best way I’ve seen to do this, but staging environments also work, and so on. Feature flags are a super weapon if you are trying to keep the path to production clear, especially if you have a diverse deployment or customer base. They don't have to be a constant binary value either. I've set up "flags" that were SQL queries which produced the actual boolean fact based upon customer-specific data and requirements. These things do tend to accumulate, but cleaning them up is easy as long as you have a way to report on the current configuration across all deployments. If two or more instances have different settings but their users seem happy with this arrangement, then you go the other way and promote the flag into some kind of official configuration abstraction. Customer and environment specific branches quickly become a death spiral if you are trying to grow a B2B/SaaS product. I'd much rather fight a spreadsheet of flags & config than rebase branches and resolve conflicts that have silently piled up for the last several months.
  • recursive 2y ago
    > as long as you have a way to report on the current configuration across all deployments This seems to be the hard part. Some of our deployments are not generally accessible to us.
• hemloc_io 2y ago
  I've also "shipped" projects at big tech companies and this level of bootlicking really doesn't deserve to be called "shipping" it's just delivering for your management. Using the term "shipping" is a great scissor statement because it muddies the water. The mentality from the article is another symptom of the many issues Software Engineering faces as profession. Namely that a significant portion of us think of ourselves not as engineers, who need to tell management to get fucked occasionally, but as optimizers for accolades from whatever group can dole out rewards. This starts off in academia and continues into the professional world. Certain folks just want to build a technical fiefdom for themselves, or get headpats from people who are above them in any given hierarchy. Yeah this is "how the game is played". Playing this game eventually leads to the death of your organization and is why we have a corporate life cycle in the first place. Eventually people like this eat an organization from the inside, pushing out anyone with an actual opinion or who optimizing for actually getting things done. Instead it's just pure mercenary behavior for your managements attention.
• arminiusreturns 2y ago
  Reality: the ops team and crusty BOFH sysadmin do their magick regardless of the dumb politics of articles like this = shipping
• computerdork 2y ago
  Think a lot of comments here (in my humble opinion) have taken the wrong interpretation of this article. Don't think this is a project-manager role, but is, as stated, typically a "tech lead or a DRI role." This means this person is still technical - would like to think this is how I approach my projects at a company and it is super effective. Specifically then, as a technical person, this means you don't ignore the requirements and just think about the code. Instead, you need to communicate with both your higher-ups and your end-users, in order to make sure the code you're writing matches their needs - in my opinion, requirements is the part that most developers are weakest in, but if they strengthen would make the biggest difference. Get it as close as possible to being right on the first time (it's very rare that this happens but focusing on doing really good requirements increases your chances that you don't create the wrong system).
• mmcnl 2y ago
  This is a great and insightful article. Very helpful. Thanks a lot, author.
• jhallenworld 2y ago
  There should be a hardware product version of this, you software people have no idea. - Have endless arguments about what to name the product - Have industrial design team enforce the latest design language - Create product variant SKU numbers, get them loaded into ordering system. Get buy-in from sales on these variants. - Create part numbers for the FRUs and CRUs. - Create multi-level BOM for all the variants. - Buy replacement parts and push them into parts depots - Calculate reliability so that warranty department knows how much to charge you - Get agency approvals - Create packaging - Test packaging - Translate any words on the package into french (for Canada) - Get vendors to sign your big company environmental requirements document - Write legal notices and get it translated into many languages - Work with documentation team to get printed (usually short) manual translated into many languages - Get safety engineer to sign off on products, usually means you need to make a bunch of stickers and include them in the BoM. - Figure out the part numbers for the power cords needed for each country - Figure out the part numbers for the rack mount rail kits for various types of racks that you support - Write announcement letter - Create videos and documents for sales team training - Write troubleshooting guide - Train repair center etc..
• dxs 2y ago
  Several more items along these lines. Two books and one recent blog post... > "Ship It! A Practical Guide to Successful Software Projects", by Jared Richardson, Will Gwaltney, Jr > "The Pragmatic Programmer, 20th Anniversary Edition, your journey to mastery", by David Thomas, Andrew Hunt > "The Libertarian Coder", by Adam Ard, at https://rethinkingsoftware.substack.com/p/the-libertarian-coder https://rethinkingsoftware.substack.com/p/the-libertarian-co... Me myself, I joined a project that shipped on time. The lead developer, a contractor, begged for just three more months to make it all actually work properly. Nope. We shipped, and then it took two more years to finally get it functional. And the contractor was banned from ever working there again (a WA state agency). Yippee!
• forrestthewoods 2y ago
  Just leaving a comment so I can find and read this thread later…
• tecoholic 2y ago
  Great article. That bit about having 20% free at the start to 90-100% free time towards the end of a project, to address issues, is very insightful. I stumbled a lot in a project recently because I suspect I had it the other way round.
• 1penny42cents 2y ago
  Regarding the “realism” proposed here, that leadership defines what shipping means: there’s a good faith and bad faith interpretation. The bad faith interpretation is that this is corrupt and misaligned. The good faith interpretation is that each leader has context and motivations that are important. The right interpretation depends on the exact circumstance. Getting leaders aligned on the right definition of “shipped” is a separate problem to the one described here, and it’s not the project lead’s direct responsibility. It’s the responsibility of the leadership team, the CEO, and the board. But the realism proposed in the post is useful for project leads. Meeting leadership’s expectation is not necessarily corrupt, and if it is corrupt, it can be improved by directly discussing and negotiating what it means to ship a project.
• yogrish 2y ago
  this is a reality in organisation: " 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." Its ironic in many areas. A leader (Project or Political) who ran projects and shipped smoothly is less valued than a leader who created a mess and got them fixed ...who is more celebrated. :(
• tobyhinloopen 2y ago
  A piece of text written by someone with actual experience, how nice :)
• Prateekcloud 2y ago
  [flagged]
• Prateekcloud 2y ago
  [flagged]
• imadtassaoui 2y ago
  Shipping is a social construct, not a technical milestone
• petetnt 2y ago
  Shipping for your leadership instead of users is so very American and explains how serial blunderers fail from one big project to another while the employees get the short end of stick. Happy if you makes you happy that some big wig on the leadership like you, but is that really all you want to achieve in life?
• unhappy_meaning 2y ago
  This is a really great and informative article, inspiring actually.
• mrazomor 2y ago
  The summary in this article is golden!