16 ms·

There's massive caveat with all of these "and then the story ends because we didn't just ship it :(" stories: sometimes the value of the "app" you're working on

There's massive caveat with all of these "and then the story ends because we didn't just ship it :(" stories: sometimes the value of the "app" you're working on is in the technical details that cannot really be "hastened" and you can't "just ship it". Also, and this is something a lot of the managerial class people don't want to hear: Your job as a sw engineer/architect is to resist the "just ship it" pressure from the management as much as possible. So unless you own what you're coding and you really need it out of the door for your own benefit, if more time makes your work more professional, then take more time. Anyone telling you otherwise is a 100% hack. You are not an automaton that takes in JIRA tickets and spits out hacky code as soon as possible. Or at least you shouldn't be. Not to mention that not taking time (doing things properly) is incredibly taxing on your psyche and you WILL burn out. There are only so much garbage tasks you can take. It's worth repeating: Unless you have a stake in the company, it is NOT your job to make sure the company is the most profitable it can be. Your job is to create great software. What's great software? The kind you'd be willing to put on your resume without feeling bad. This is the thing that will ultimately make you feel good about the work you're doing. Hitting that arbitrary deadline for a 1425474th time may feel like a relief but it's short term and a form of negative motivation - and in the workplace, those NEVER work over a long period of time. So RESIST that pressure from the top and do your work properly. If they fire you, then who cares, the only way up these days is job hopping anyways.

treve 2y ago
This entire comment reads as someone who has a purely adversarial relationship with their coworkers with little trust. Sounds exhausting!
- manmal 2y ago
  Seeing you‘re a CTO, I‘m a bit concerned for your staff (if any) if your first reflex is blaming the developer for not trusting their boss.
  - Huggernaut 2y ago
    I don't see any blame assigned in the previous comment.
    - exe34 2y ago
      no it was more passive aggressive - suggesting there was blame but not actually coming out and assigning it.
  - vasco 2y ago
    The person is adversarial, that is clear in their comment. There's literal adversarial quotes like "only do X if good for you, otherwise do the opposite". On the other hand you went straight to googling a random commenters job and attacked that.
    - aydyn 2y ago
      nah fam he is right. And he didnt google shit, its literally in the profile.
    - deleted 2y ago
      [deleted]
    - manmal 2y ago
      Every one of your sentences is an assertion presented as fact. That could also be considered adversarial. GP has replied in a constructive manner in the meantime btw. And yeah, no googling involved. I often look in HN profiles to find more context to why people are writing what they write. I don’t stalk them, tbh I find it creepy when people from HN find me on X and DM me.
  - treve 2y ago
    Not my intent to assign blame, it just sounds like a toxic workplace. I've been there! The better places I've worked were more focused on compromise, experimentation and taking shared responsibility for risk.
    - 2y ago
- zogrodea 2y ago
  It reminded me of that quote wrongly attributed to Shigeru Miyamoto (who created Mario and Zelda and other classic games). "A rushed game is bad forever, but a delayed one may eventually be good." Of course it may not apply to software today (except to the extent first impressions count) because modern software tends to be continuously maintained (and modern games often are too, to a much lesser degree, with post-release patches).
  - shalmanese 2y ago
    Games and software operate from a different set of first principles, games are more akin to movies in that we consume them for the experience and that final level of polish often does make or break it.
  - vasco 2y ago
    Games were not updatable at the time of the quote, which makes an incredibly huge difference from products that can be regularly updated to fix issues.
    - zogrodea 2y ago
      I do mention that in the second paragraph. My understanding is that most [0] games don't get super-substantial updates making the game leaps and bounds better than it was in its initial state, the way continuously-developed software does. Am I wrong? [0] Games like Minecraft, Stardew Valley, Terraria and online games being a minority.
    - Viliam1234 2y ago
      Even if a game (or any other software) can be updated later, improving things and fixing bugs is not necessarily a business priority, because you could be adding new features or working on a new product instead. The profit-maximizing strategy is to keep the level of crappiness that frustrates your customers, but not enough to make them switch to a competing product.
  - achenet 2y ago
    the counter quote to that is John Carmack, who was originally a fan of the "it'll ship when ready philosophy", saying he 'largely recanted from that now' when discussing Rage on the Joe Rogan podcast. Or Duke Ellington: "I don't need time. What I need is a deadline."
- aprilthird2021 2y ago
  I can see some of the tone being too adversarial, but I think the gist, that we are after all professional engineers, who studied and spent time and money to understand how to build such systems to high standards. And since we are that and are paid for that knowledge, we should strive to improve software / system quality as much as possible. Isn't the job of executives, managers, etc. to figure out the constraints we have and strive to improve profit and shipping speed as much as possible? Together, with our combined expertise we can get the practical best of all three. But if eng just nod along knowing they are sacrificing quality, security, scalability, etc. then they are doing a disservice to the team, no?
  - pertymcpert 2y ago
    Those kinds of orgs eventually get eaten alive by orgs who had better alignment because they’re inefficient. Executives are human and they need the help of engineering teams to make some decisions. If every question about “can be ship this faster?” is answered with “no because we’re professional engineers who’ve studied a long time to build systems to high standards”, then that company will lose vs another competitor who had a more collaborative approach.
    - aprilthird2021 2y ago
      > Executives are human and they need the help of engineering teams to make some decisions. If every question about “can be ship this faster?” is answered with “no because we’re professional engineers who’ve studied a long time to build systems to high standards”, then that company will lose vs another competitor who had a more collaborative approach. It's the executives' job to synthesize info from other orgs and understand the business. In social media apps for example, delaying a feature launch for better quality may not be worth it. In commercial aeronautics software, it matters a lot better.
      - pertymcpert 2y ago
        You can go on all you want about which job is who's but in the end I'm still right. Those organizations who work better together will out-compete those which don't, all other things being equal. I'm sure the engineers looking for work after their employer files chapter 7 will feel smug that at least they didn't have to take responsibility for anything outside of engineering.
- yamumsahoe 2y ago
  no, to me it doesnt. to me he's right about how devs should deliver it as engineeringly sound as possible, and executives should deliver it as timely as possible. its a balance between having a usable product and a product they need at the right time. it's not adversarial. its a conflict yes, but a healthy one.
  - IanCal 2y ago
    They should all be aligned in what they're trying to achieve. Misalignment here is not healthy. Swe should inform about consequences, and executives should inform about business priorities, but they don't have to all disagree on the way forwards.
- Culonavirus 2y ago
  Sounds exhausting? Sounds like gaslighting a wee bit... Oh nooo... the poor managers, how will they manage if you don't TRUST them blindly and completely (and bend over backwards to fulfill all their whims)? What kind of a cult is this? I'm not a sheep that needs to be herded. Besides, trust is earned. So no, it's not exhausting, it's the exact opposite. It's refreshing and freeing. Anyways, I get along with my coworkers very well. In fact most of my friends began as my coworkers. Then again I do not consider managers to be my coworkers. And generally speaking, yes, you could say I don't trust them. But that just comes from working in 5 for-profit companies for over 15 years. The only exception was an energy company, probably because the "just ship it" mentality wasn't as strong.
  - treve 2y ago
    You've hit the nail on the head about trust needing to be earned. I didn't assume that this was on you or it was your fault. It just sounded like a bad situation. Also based on what you're saying manager also doesn't trust you or at the very least you don't share the same values. That said it was quite a cynical interpretation of my comment and aggressive reply, so I'll leave it with that.
  - pertymcpert 2y ago
    Honestly that sucks. I worked for a small-ish company before living to a FAANG, and both times in every role I had I had a great team and manager with super high trust. Makes me appreciate my experience more to read about others.
- jampekka 2y ago
  Or with the employer/owners? Owners and workers have a fundamentally adversarial relationship.
eastbound 2y ago
> Your job as a sw engineer/architect is to resist the "just ship it" pressure from the management as much as possible. Wow. That reminds me of what the guy who was fired said. I’ll never understand him. He lives in a house that’s below sea level, with one kid and one wife, and it gets flooded every 4 years. He was raised 30% during Covid, job was quite comfortable, he was competent for it, then stopped pulling his weight. Wouldn’t it be easier to keep pulling weight and try to build something that works, rather than deploying energy for union tactics, and then live in a twice-more expensive above-sea-level house? Yes it would. Sometimes people get stuck in a victimization loop.
- polotics 2y ago
  Good News: Dr Sapolsky has recently updated his intro video on depression. it's here: https://youtu.be/fzUXcBTQXKM?si=JU-iOaP9SeFdB5qy https://youtu.be/fzUXcBTQXKM?si=JU-iOaP9SeFdB5qy
pdonis 2y ago
> Unless you have a stake in the company, it is NOT your job to make sure the company is the most profitable it can be. Maybe. But... > Your job is to create great software. No. Your job is to do what the company pays you for. The company is not paying you to create great software. It's paying you to solve some kind of business problem or provide some kind of business service. Some of those problems or services do indeed require great software. But many do not; mediocre software will do the job just fine. And if that's the case, and you insist on creating great software anyway, you are spending time and effort that is not adding anything to the company's bottom line. And while you personally might not care about that, the company does, and they're paying you. > What's great software? The kind you'd be willing to put on your resume without feeling bad. You used the term "software engineer". A software engineer's job is not to always write great software. It's to write the optimal amount and quality of software for meeting the particular requirement it's supposed to meet. More generally, an engineer's job is to produce optimal solutions to problems. That does not always mean building the highest quality product possible. Sometimes it means doing just enough to get the job done, even if it's not very pretty, and stopping there because doing more would add no business value. And you should not at all feel bad about putting that on your resume. Refusing the temptation to gold plate everything when it's not necessary is a good thing for an engineer.
- aprilthird2021 2y ago
  > No. Your job is to do what the company pays you for. The company is not paying you to create great software. It's paying you to solve some kind of business problem or provide some kind of business service. The company pays me because of my knowledge and expertise, that is needed to create and maintain the porduct as best as possible. If I am just a yes man, the company isn't getting what they paid for. If I honestly assess and say what is being sacrificed re: security, scalability, future flexibility, etc. in the software, then the company is getting what they paid for, and they can choose how far they want to go in the quality / time spectrum. And if they pick somewhere my expertise says is too far on one or the other side, it's my job to say so. No?
  - pdonis 2y ago
bruce511 2y ago
I started writing a reply about how the context is very different between indie side projects and your work environment, but then your post morphed into a comment about the role of a programmer in an organisation, and so did my reply. Firstly, I sense you are frustrated in your current post and I sense you are not in step with your management or perhaps not even in step with your coworkers. I sympathize with your predicament. If I had any advice it's that you cast around for a position that's more in line with your principles and goals (don't quit your current job till you find that.) Personally I've been on all sides in the myself. I've been the principled programmer. I've been the one dedicated to quality. I've been the manager. I've been the person responsible for the business staying in business. Yeah its nice to adopt the "code my problem, business not" position. It seems like the moral high ground. But businesses are all about balance. They have to balance things like income, and happy customers with tech debt and so on. Having programmers (or anyone for that matter) working -against- the big picture is not ultimately useful and can do more harm than good. I don't always agree with my team and they often don't agree with me. But ultimately I'm responsible so (sometimes tough) decisions have to be made. The most successful employees are those who acknowledge that this isn't necessarily the best way to do something, but strive anyway to make it a success. I wish I had the time and money to let programmers just spend forever building stuff and never shipping. They most definitely wish that. But we live in a real world with constraints and the reality is we need a lot more than perfect code. Of course some places are just impossible to work at, where everything is rushed and there is no balance either. And then it sucks to be you.
- eastbound 2y ago
  If we waste resources overengineering everything, it takes resources away from other parts of society that require them.
  - pdimitar 2y ago
    Good thing that 100% of all programmers go out there and volunteer all the time they saved at work. Oh wait, no they don't.
- pdimitar 2y ago
shalmanese 2y ago
This is the wrong framing of it, shipping is an internal mental battle, not an external one. We are not perfectly rational automatons that always work towards our rational best interests. Shipping is hard so we create mental battles inside ourselves to avoid it and use post-hoc justifications to feel morally ok with that decision. The choice of when to ship isn't nearly as important as the answer to why you aren't shipping on the choice you said you would ship. Yes, shipping at different points of maturity represent different sets of tradeoffs in a complex multi-dimensional matrix and it's an intellectually fascinating challenge but often, the choice is far less important than the debate that sucks it in and engineers end up bikeshedding the decision. Whenever you find yourself bikeshedding, it's important to realize you don't solve it by looking at the decision but by looking at why people feel the need to bikeshed in the first place. You talk about how "Your job is to create great software. What's great software? The kind you'd be willing to put on your resume without feeling bad.", what is the "job to be done" by that belief for you? Is this a true, genuine held belief by you or is that here as a cover to some deeper belief that is uncomfortable to surface? The answer is something ultimately only you can answer and no internet comment can force that deep degree of introspection, only those close to you who have a requisite degree of insight and therapeutic practice can reliably help with that. But the larger point I want to make is that the shape of the conversation around shipping is all around exploring where we feel different mental resistance around shipping at any point in time and uncovering where that resistance truly comes from vs the reasons we make up to dress it up.
- Fr0styMatt88 2y ago
  What do you mean by “not shipping on the choice you made to ship”? Do you have an example? Really fascinating thoughts.
  - shalmanese 2y ago
    Like what the article stated. “I should ship this week but I really feel we need a mobile app to ship.” You build the mobile app and you still don’t ship because the mobile app was not the problem, it just hid the problem. Until you understand and confront the true problem (emotional discomfort at the consequences of shipping), there will always be another reason not to ship.
mirsadm 2y ago
Most deadlines are made up anyway. If it doesn't happen usually nothing happens.
- achenet 2y ago
  “I love deadlines. I love the whooshing noise they make as they go by.” - Douglas Adams
riwsky 2y ago
Engineering is tradeoffs; the whole concept of quality only makes sense in the context of a certain budget. If an engineer takes two weeks hand-crafting some one-off charts in d3 and react that could’ve been done uglier in some BI dashboard in a day, it might look good on a résumé—but it’s shitty engineering.
deleted 2y ago
[deleted]
rkuodys 2y ago
I think it's very different when you're one-man-show vs a cogwheel in organisation. In former case, just like the author mentioned, your struggle is more with yourself. You need to make yourself move forward. And "Just ship it" approach gives you that - you get external push to carry on. External user(s), external comments and demands give you that bit of energy to carry on. In corporation setup, you always have a manager and peers that push you. You have periodic meetings with team/manager whatever to show what you have done, and then, depending on company setup, it's quality vs speed discussion. But that's very different from being all alone with your code and computer trying to build something from the grou up.
vouwfietsman 2y ago
> It's worth repeating: Unless you have a stake in the company, it is NOT your job to make sure the company is the most profitable it can be. Your job is to create great software This is a terrible take, and one I generally see as a signal of lack of seniority in a software dev. It is absolutely everybody's job in the company to make sure it is profitable, unless you work for a non-profit. The thing is though, that profitable is not the same as "just ship it". If you're in a company where those things are conflated frequently, that's a sign of lack of seniority in management. > Your job is to create great software It really isn't, your job is to make a great product. Making a great product often, but not always, requires great software. Many great products have terrible software behind them. The tension between product, sales and development should result in a compromise that creates the most value short, middle and long term. It is 100% your job as a developer to understand what can and cannot be hacked, what priorities the company has beside delivering great software, and finally: when great software must be made, because compromise is unwise. Just like the boy who cried wolf, the developer who can never compromise on software quality is powerless when there is an actual reason to not compromise on software quality, and rightfully so.
- dclowd9901 2y ago
  I 100% agree with you. I’m in a situation at the moment when I’m nearly constantly having to check myself against other devs. I don’t do hacky work and nothing I do isn’t extensible or easily refactorable. But I constantly get feedback from another dev on my team wanting me to polish out a change to perfection against every feasible possibility. I try to employ YAGNI reasoning to them, but they just have a perfectionist standard. Look: job 1 is making safe software, job 2 is making money and job 3 is perfecting the architecture.
  - another2another 2y ago
    Ask them to write the tests that will trigger the failure condition - i.e. make them prove that it's a possible thing that can easily occur. If it is, then at least you have a simple test case to work with so they've done a chunk of the work for you. If it's not, then they'll spend ages trying to craft a test case for a scenario that's extremely unlikely. People very often leave you alone when challenged to put in the work to prove their point.
antupis 2y ago
> The kind you'd be willing to put on your resume without feeling bad. Usually when you are doing "just ship it" often enough you achieve this, especially at larger firms too often I see situations where engineers are doing their 3th refactoring without any customer feedback.
vasco 2y ago
This has to be satire. "Do the wrong thing unless it's for you, in which case ship it earlier", "your job is to make you feel good about what you put in your CV", and other amazing quotes. The only thing of value in the whole comment is saying to not get too attached to any job or worry too much if you get fired, but even the reason given for it is wrong. Incredible to realize I probably work alongside a few people with the same adversarial attitude. Some people do like to live life in the wrong game theory quadrant.
- aydyn 2y ago
  No, everyone lives life in the same "game theory quadrant" whatever that means. People primarily play for themselves including you, some people are just more aware of this fact than others. And also its still always rational to defect.
  - vasco 2y ago
    That's not true, I have many examples I've seen of people putting themselves second. Of course everyone has these thoughts and actions and needs to reflect and be self aware, but it's not true that everyone is just always out for themselves, in fact that's the type of world view that leads people into the wrong quadrant and it's a bit of a depressing world view. I think you understood exactly what I meant by wrong quadrant, from your reply. Don't you know anyone that donates money? Or that volunteers their time? Or that doesn't use all their deductions when doing taxes? Haven't you read stories about people who anonymously donate kidneys? There's so many examples - and the only way for your world view to "work" is if all of them only do these things for selfish reasons. At some point one has to acknowledge and believe in good and cooperation and decide if they mostly want to try and operate in coop mode or in selfish mode, but the more you believe others are likely to choose coop, the more like you are to do the same. So you need to start from the belief that good and coop are things other people will also choose. Your world view prevents this "from the start".
    - shepherdjerred 2y ago
      I'll drop in here and say that donating a kidney is an excellent relatively low risk thing you can do that has the power to transform someone's life. Here [0] is an excellent article telling one persons' story. [0]: https://www.astralcodexten.com/p/my-left-kidney https://www.astralcodexten.com/p/my-left-kidney
mrfumier 2y ago
Why are you developping? Is it a hobby for passing time? For pleasure? For the beauty of the code? Could be. But most of the time, you develop in order for the software to perfom a task someone needs. And that should be your first focus: to develop something that brings value for its user, and develop it as efficiently as possible. After all, what's the point of a software if nobody uses it? So no, your job is not to create great software, your job is to bring value to users. In my career, I've mostly seen the developers pleasuring themselves with overengineering, bloating code with features nobody needs, and writing lines to anticipate future developments that never came. Rather than the opposite. So I think the challenge is to remain minimalistic, that's hard, and that's what the original post is about.
- katrotz 2y ago
  Unfortunately there is no correct approach since both sloppy and overengineered codebases backfire. What helps me find balance is following the philosophy of 1. Make it work 2. Make it right 3. Make it fast
achenet 2y ago
https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html If you want to write good software, get it in front of someone who will actually use it as soon as possible. Get it in front of many people who use it as soon as possible. No matter how smart you are, you can't anticipate every user need. Let the users tell you what they need. To do that, you need to ship.
lazyasciiart 2y ago
Good news - once you work at a large enough company, this flips to "your job is to finagle your way through a million different safety and security checks at every step in order to write a few lines of code and get them shipped before a pivot and/or re-org makes them irrelevant to your new managers goals".
throwaway84751 2y ago
I was one of the first employees in a startup, and if I hadn't made compromises the company would probably not exist today. Your approach only works for big established companies where your team has limited impact on the results. For small and medium sized companies you definitely need to make compromises. It is part of your job as a professional to make choices that leads to the best business outcome. Unfortunately a lot of developers don't have a connection to the business side, because they are "protected" by several layers of management, PMs and designers that interact with the business on their behalf. Getting a product out quickly means that you also get feedback earlier. This is not only good for business, but it is also an opportunity to evaluate your implementation to see if it matches your assumptions. In my experience this causes less stress compared to rolling out a "perfect" solution that has to be rewritten while under pressure. My job as a developer at my current workplace is to reduce complexity and get the PM and designers to cut down their initial plans to a minimum. It makes arbitrary deadlines less stressful and any delays will not have the same impact.
- deleted 2y ago
  [deleted]
sisve 2y ago
> Your job as a sw engineer/architect is to resist the "just ship it" pressure from the management as much as possible. So unless you own what you're coding and you really need it out of the door for your own benefit, if more time makes your work more professional, then take more time. Anyone telling you otherwise is a 100% hack. You are not an automaton that takes in JIRA tickets and spits out hacky code as soon as possible. Or at least you shouldn't be. Not to mention that not taking time (doing things properly) is incredibly taxing on your psyche and you WILL burn out. There are only so much garbage tasks you can take. Any job, In any industry at any level should be working together with your manager to understand what the company goal and how to achive that. Its always going to be time/price vs quality if you work on creating software or clothing or whatever. There are properly companies and managers that do not care.. but imbany healthy organisation this should be the case. There is not garbage tasks. Its tasks that needs to be done. Any understanding that not all tasks that needs to be done in an organisation is fun but needs to be done is a sign of maturity that you want from your employees
- therouwboat 2y ago
  My boss says our goal is to make quality products, but often we don't even have time to check the parts. Once there was a problem that machine didn't make good enough surface finish, but boss just said it's fine, let it run. Turns out it wasn't fine and we had to fix 3000 parts with hand sander. That's why I don't like to cut corners.
danparsonson 2y ago
There's usually an entire pipeline of people waiting on your work - sales & marketing, ops, support - and every delay you induce risks knock-on effects for them, not to mention that depending on the product, customers can be planning their own workloads around your release schedules, so you'll mess them up too. Not all deadlines are arbitrary.
potsandpans 2y ago
What a weird screed.
snozolli 2y ago
if more time makes your work more professional, then take more time. Anyone telling you otherwise is a 100% hack. It sounds like you're a fan of Total Quality Control, as am I. However, it also sounds like you're susceptible to feature drift and undermining yourself with ideas thought up late in the development cycle, as am I. I've seen it from both sides. Software people who want to get just one more feature in, or who want to hold up release to fix an inconsequential bug. Similarly, the CEO who ruminates all weekend and decides we have to revamp something for no objective reason and on a ridiculous deadline.
IanCal 2y ago
> it is NOT your job to make sure the company is the most profitable it can be. Your job is to create great software. Your job is to create great software for the company and your definition of great software is therefore defined by the company. > . What's great software? The kind you'd be willing to put on your resume without feeling bad. If your idea of a good CV is one where you can say "I deliberately made the following companies less money than I could have: ..." then I'm not sure who you're applying to with confidence.
Sammi 2y ago
I would not hire you. I would worry that you would take my money, and not ship anything that makes my company money. I could just as well burn my money for all the good it would do my company. You do know that the point of a company is to make money, right?

treve 2y ago

This entire comment reads as someone who has a purely adversarial relationship with their coworkers with little trust. Sounds exhausting!

manmal 2y ago
Seeing you‘re a CTO, I‘m a bit concerned for your staff (if any) if your first reflex is blaming the developer for not trusting their boss.
- Huggernaut 2y ago
  I don't see any blame assigned in the previous comment.
  - exe34 2y ago
    no it was more passive aggressive - suggesting there was blame but not actually coming out and assigning it.
- vasco 2y ago
  The person is adversarial, that is clear in their comment. There's literal adversarial quotes like "only do X if good for you, otherwise do the opposite". On the other hand you went straight to googling a random commenters job and attacked that.
  - aydyn 2y ago
    nah fam he is right. And he didnt google shit, its literally in the profile.
  - deleted 2y ago
    [deleted]
  - manmal 2y ago
    Every one of your sentences is an assertion presented as fact. That could also be considered adversarial. GP has replied in a constructive manner in the meantime btw. And yeah, no googling involved. I often look in HN profiles to find more context to why people are writing what they write. I don’t stalk them, tbh I find it creepy when people from HN find me on X and DM me.
- treve 2y ago
  Not my intent to assign blame, it just sounds like a toxic workplace. I've been there! The better places I've worked were more focused on compromise, experimentation and taking shared responsibility for risk.
  - 2y ago
zogrodea 2y ago
It reminded me of that quote wrongly attributed to Shigeru Miyamoto (who created Mario and Zelda and other classic games). "A rushed game is bad forever, but a delayed one may eventually be good." Of course it may not apply to software today (except to the extent first impressions count) because modern software tends to be continuously maintained (and modern games often are too, to a much lesser degree, with post-release patches).
- shalmanese 2y ago
  Games and software operate from a different set of first principles, games are more akin to movies in that we consume them for the experience and that final level of polish often does make or break it.
- vasco 2y ago
  Games were not updatable at the time of the quote, which makes an incredibly huge difference from products that can be regularly updated to fix issues.
  - zogrodea 2y ago
    I do mention that in the second paragraph. My understanding is that most [0] games don't get super-substantial updates making the game leaps and bounds better than it was in its initial state, the way continuously-developed software does. Am I wrong? [0] Games like Minecraft, Stardew Valley, Terraria and online games being a minority.
  - Viliam1234 2y ago
    Even if a game (or any other software) can be updated later, improving things and fixing bugs is not necessarily a business priority, because you could be adding new features or working on a new product instead. The profit-maximizing strategy is to keep the level of crappiness that frustrates your customers, but not enough to make them switch to a competing product.
- achenet 2y ago
  the counter quote to that is John Carmack, who was originally a fan of the "it'll ship when ready philosophy", saying he 'largely recanted from that now' when discussing Rage on the Joe Rogan podcast. Or Duke Ellington: "I don't need time. What I need is a deadline."
aprilthird2021 2y ago
I can see some of the tone being too adversarial, but I think the gist, that we are after all professional engineers, who studied and spent time and money to understand how to build such systems to high standards. And since we are that and are paid for that knowledge, we should strive to improve software / system quality as much as possible. Isn't the job of executives, managers, etc. to figure out the constraints we have and strive to improve profit and shipping speed as much as possible? Together, with our combined expertise we can get the practical best of all three. But if eng just nod along knowing they are sacrificing quality, security, scalability, etc. then they are doing a disservice to the team, no?
- pertymcpert 2y ago
  Those kinds of orgs eventually get eaten alive by orgs who had better alignment because they’re inefficient. Executives are human and they need the help of engineering teams to make some decisions. If every question about “can be ship this faster?” is answered with “no because we’re professional engineers who’ve studied a long time to build systems to high standards”, then that company will lose vs another competitor who had a more collaborative approach.
  - aprilthird2021 2y ago
    > Executives are human and they need the help of engineering teams to make some decisions. If every question about “can be ship this faster?” is answered with “no because we’re professional engineers who’ve studied a long time to build systems to high standards”, then that company will lose vs another competitor who had a more collaborative approach. It's the executives' job to synthesize info from other orgs and understand the business. In social media apps for example, delaying a feature launch for better quality may not be worth it. In commercial aeronautics software, it matters a lot better.
    - pertymcpert 2y ago
      You can go on all you want about which job is who's but in the end I'm still right. Those organizations who work better together will out-compete those which don't, all other things being equal. I'm sure the engineers looking for work after their employer files chapter 7 will feel smug that at least they didn't have to take responsibility for anything outside of engineering.
yamumsahoe 2y ago
no, to me it doesnt. to me he's right about how devs should deliver it as engineeringly sound as possible, and executives should deliver it as timely as possible. its a balance between having a usable product and a product they need at the right time. it's not adversarial. its a conflict yes, but a healthy one.
- IanCal 2y ago
  They should all be aligned in what they're trying to achieve. Misalignment here is not healthy. Swe should inform about consequences, and executives should inform about business priorities, but they don't have to all disagree on the way forwards.
Culonavirus 2y ago
Sounds exhausting? Sounds like gaslighting a wee bit... Oh nooo... the poor managers, how will they manage if you don't TRUST them blindly and completely (and bend over backwards to fulfill all their whims)? What kind of a cult is this? I'm not a sheep that needs to be herded. Besides, trust is earned. So no, it's not exhausting, it's the exact opposite. It's refreshing and freeing. Anyways, I get along with my coworkers very well. In fact most of my friends began as my coworkers. Then again I do not consider managers to be my coworkers. And generally speaking, yes, you could say I don't trust them. But that just comes from working in 5 for-profit companies for over 15 years. The only exception was an energy company, probably because the "just ship it" mentality wasn't as strong.
- treve 2y ago
  You've hit the nail on the head about trust needing to be earned. I didn't assume that this was on you or it was your fault. It just sounded like a bad situation. Also based on what you're saying manager also doesn't trust you or at the very least you don't share the same values. That said it was quite a cynical interpretation of my comment and aggressive reply, so I'll leave it with that.
- pertymcpert 2y ago
  Honestly that sucks. I worked for a small-ish company before living to a FAANG, and both times in every role I had I had a great team and manager with super high trust. Makes me appreciate my experience more to read about others.
jampekka 2y ago
Or with the employer/owners? Owners and workers have a fundamentally adversarial relationship.

eastbound 2y ago

> Your job as a sw engineer/architect is to resist the "just ship it" pressure from the management as much as possible. Wow. That reminds me of what the guy who was fired said. I’ll never understand him. He lives in a house that’s below sea level, with one kid and one wife, and it gets flooded every 4 years. He was raised 30% during Covid, job was quite comfortable, he was competent for it, then stopped pulling his weight. Wouldn’t it be easier to keep pulling weight and try to build something that works, rather than deploying energy for union tactics, and then live in a twice-more expensive above-sea-level house? Yes it would. Sometimes people get stuck in a victimization loop.

polotics 2y ago
Good News: Dr Sapolsky has recently updated his intro video on depression. it's here: https://youtu.be/fzUXcBTQXKM?si=JU-iOaP9SeFdB5qy https://youtu.be/fzUXcBTQXKM?si=JU-iOaP9SeFdB5qy

pdonis 2y ago

> Unless you have a stake in the company, it is NOT your job to make sure the company is the most profitable it can be. Maybe. But... > Your job is to create great software. No. Your job is to do what the company pays you for. The company is not paying you to create great software. It's paying you to solve some kind of business problem or provide some kind of business service. Some of those problems or services do indeed require great software. But many do not; mediocre software will do the job just fine. And if that's the case, and you insist on creating great software anyway, you are spending time and effort that is not adding anything to the company's bottom line. And while you personally might not care about that, the company does, and they're paying you. > What's great software? The kind you'd be willing to put on your resume without feeling bad. You used the term "software engineer". A software engineer's job is not to always write great software. It's to write the optimal amount and quality of software for meeting the particular requirement it's supposed to meet. More generally, an engineer's job is to produce optimal solutions to problems. That does not always mean building the highest quality product possible. Sometimes it means doing just enough to get the job done, even if it's not very pretty, and stopping there because doing more would add no business value. And you should not at all feel bad about putting that on your resume. Refusing the temptation to gold plate everything when it's not necessary is a good thing for an engineer.

aprilthird2021 2y ago
> No. Your job is to do what the company pays you for. The company is not paying you to create great software. It's paying you to solve some kind of business problem or provide some kind of business service. The company pays me because of my knowledge and expertise, that is needed to create and maintain the porduct as best as possible. If I am just a yes man, the company isn't getting what they paid for. If I honestly assess and say what is being sacrificed re: security, scalability, future flexibility, etc. in the software, then the company is getting what they paid for, and they can choose how far they want to go in the quality / time spectrum. And if they pick somewhere my expertise says is too far on one or the other side, it's my job to say so. No?
- pdonis 2y ago

bruce511 2y ago

I started writing a reply about how the context is very different between indie side projects and your work environment, but then your post morphed into a comment about the role of a programmer in an organisation, and so did my reply. Firstly, I sense you are frustrated in your current post and I sense you are not in step with your management or perhaps not even in step with your coworkers. I sympathize with your predicament. If I had any advice it's that you cast around for a position that's more in line with your principles and goals (don't quit your current job till you find that.) Personally I've been on all sides in the myself. I've been the principled programmer. I've been the one dedicated to quality. I've been the manager. I've been the person responsible for the business staying in business. Yeah its nice to adopt the "code my problem, business not" position. It seems like the moral high ground. But businesses are all about balance. They have to balance things like income, and happy customers with tech debt and so on. Having programmers (or anyone for that matter) working -against- the big picture is not ultimately useful and can do more harm than good. I don't always agree with my team and they often don't agree with me. But ultimately I'm responsible so (sometimes tough) decisions have to be made. The most successful employees are those who acknowledge that this isn't necessarily the best way to do something, but strive anyway to make it a success. I wish I had the time and money to let programmers just spend forever building stuff and never shipping. They most definitely wish that. But we live in a real world with constraints and the reality is we need a lot more than perfect code. Of course some places are just impossible to work at, where everything is rushed and there is no balance either. And then it sucks to be you.

eastbound 2y ago
If we waste resources overengineering everything, it takes resources away from other parts of society that require them.
- pdimitar 2y ago
  Good thing that 100% of all programmers go out there and volunteer all the time they saved at work. Oh wait, no they don't.
pdimitar 2y ago

shalmanese 2y ago

This is the wrong framing of it, shipping is an internal mental battle, not an external one. We are not perfectly rational automatons that always work towards our rational best interests. Shipping is hard so we create mental battles inside ourselves to avoid it and use post-hoc justifications to feel morally ok with that decision. The choice of when to ship isn't nearly as important as the answer to why you aren't shipping on the choice you said you would ship. Yes, shipping at different points of maturity represent different sets of tradeoffs in a complex multi-dimensional matrix and it's an intellectually fascinating challenge but often, the choice is far less important than the debate that sucks it in and engineers end up bikeshedding the decision. Whenever you find yourself bikeshedding, it's important to realize you don't solve it by looking at the decision but by looking at why people feel the need to bikeshed in the first place. You talk about how "Your job is to create great software. What's great software? The kind you'd be willing to put on your resume without feeling bad.", what is the "job to be done" by that belief for you? Is this a true, genuine held belief by you or is that here as a cover to some deeper belief that is uncomfortable to surface? The answer is something ultimately only you can answer and no internet comment can force that deep degree of introspection, only those close to you who have a requisite degree of insight and therapeutic practice can reliably help with that. But the larger point I want to make is that the shape of the conversation around shipping is all around exploring where we feel different mental resistance around shipping at any point in time and uncovering where that resistance truly comes from vs the reasons we make up to dress it up.

Fr0styMatt88 2y ago
What do you mean by “not shipping on the choice you made to ship”? Do you have an example? Really fascinating thoughts.
- shalmanese 2y ago
  Like what the article stated. “I should ship this week but I really feel we need a mobile app to ship.” You build the mobile app and you still don’t ship because the mobile app was not the problem, it just hid the problem. Until you understand and confront the true problem (emotional discomfort at the consequences of shipping), there will always be another reason not to ship.

mirsadm 2y ago

Most deadlines are made up anyway. If it doesn't happen usually nothing happens.

achenet 2y ago
“I love deadlines. I love the whooshing noise they make as they go by.” - Douglas Adams

riwsky 2y ago

Engineering is tradeoffs; the whole concept of quality only makes sense in the context of a certain budget. If an engineer takes two weeks hand-crafting some one-off charts in d3 and react that could’ve been done uglier in some BI dashboard in a day, it might look good on a résumé—but it’s shitty engineering.

deleted 2y ago

[deleted]

rkuodys 2y ago

I think it's very different when you're one-man-show vs a cogwheel in organisation. In former case, just like the author mentioned, your struggle is more with yourself. You need to make yourself move forward. And "Just ship it" approach gives you that - you get external push to carry on. External user(s), external comments and demands give you that bit of energy to carry on. In corporation setup, you always have a manager and peers that push you. You have periodic meetings with team/manager whatever to show what you have done, and then, depending on company setup, it's quality vs speed discussion. But that's very different from being all alone with your code and computer trying to build something from the grou up.

vouwfietsman 2y ago

> It's worth repeating: Unless you have a stake in the company, it is NOT your job to make sure the company is the most profitable it can be. Your job is to create great software This is a terrible take, and one I generally see as a signal of lack of seniority in a software dev. It is absolutely everybody's job in the company to make sure it is profitable, unless you work for a non-profit. The thing is though, that profitable is not the same as "just ship it". If you're in a company where those things are conflated frequently, that's a sign of lack of seniority in management. > Your job is to create great software It really isn't, your job is to make a great product. Making a great product often, but not always, requires great software. Many great products have terrible software behind them. The tension between product, sales and development should result in a compromise that creates the most value short, middle and long term. It is 100% your job as a developer to understand what can and cannot be hacked, what priorities the company has beside delivering great software, and finally: when great software must be made, because compromise is unwise. Just like the boy who cried wolf, the developer who can never compromise on software quality is powerless when there is an actual reason to not compromise on software quality, and rightfully so.

dclowd9901 2y ago
I 100% agree with you. I’m in a situation at the moment when I’m nearly constantly having to check myself against other devs. I don’t do hacky work and nothing I do isn’t extensible or easily refactorable. But I constantly get feedback from another dev on my team wanting me to polish out a change to perfection against every feasible possibility. I try to employ YAGNI reasoning to them, but they just have a perfectionist standard. Look: job 1 is making safe software, job 2 is making money and job 3 is perfecting the architecture.
- another2another 2y ago
  Ask them to write the tests that will trigger the failure condition - i.e. make them prove that it's a possible thing that can easily occur. If it is, then at least you have a simple test case to work with so they've done a chunk of the work for you. If it's not, then they'll spend ages trying to craft a test case for a scenario that's extremely unlikely. People very often leave you alone when challenged to put in the work to prove their point.

antupis 2y ago

> The kind you'd be willing to put on your resume without feeling bad. Usually when you are doing "just ship it" often enough you achieve this, especially at larger firms too often I see situations where engineers are doing their 3th refactoring without any customer feedback.

vasco 2y ago

This has to be satire. "Do the wrong thing unless it's for you, in which case ship it earlier", "your job is to make you feel good about what you put in your CV", and other amazing quotes. The only thing of value in the whole comment is saying to not get too attached to any job or worry too much if you get fired, but even the reason given for it is wrong. Incredible to realize I probably work alongside a few people with the same adversarial attitude. Some people do like to live life in the wrong game theory quadrant.

aydyn 2y ago
No, everyone lives life in the same "game theory quadrant" whatever that means. People primarily play for themselves including you, some people are just more aware of this fact than others. And also its still always rational to defect.
- vasco 2y ago
  That's not true, I have many examples I've seen of people putting themselves second. Of course everyone has these thoughts and actions and needs to reflect and be self aware, but it's not true that everyone is just always out for themselves, in fact that's the type of world view that leads people into the wrong quadrant and it's a bit of a depressing world view. I think you understood exactly what I meant by wrong quadrant, from your reply. Don't you know anyone that donates money? Or that volunteers their time? Or that doesn't use all their deductions when doing taxes? Haven't you read stories about people who anonymously donate kidneys? There's so many examples - and the only way for your world view to "work" is if all of them only do these things for selfish reasons. At some point one has to acknowledge and believe in good and cooperation and decide if they mostly want to try and operate in coop mode or in selfish mode, but the more you believe others are likely to choose coop, the more like you are to do the same. So you need to start from the belief that good and coop are things other people will also choose. Your world view prevents this "from the start".
  - shepherdjerred 2y ago
    I'll drop in here and say that donating a kidney is an excellent relatively low risk thing you can do that has the power to transform someone's life. Here [0] is an excellent article telling one persons' story. [0]: https://www.astralcodexten.com/p/my-left-kidney https://www.astralcodexten.com/p/my-left-kidney

mrfumier 2y ago

Why are you developping? Is it a hobby for passing time? For pleasure? For the beauty of the code? Could be. But most of the time, you develop in order for the software to perfom a task someone needs. And that should be your first focus: to develop something that brings value for its user, and develop it as efficiently as possible. After all, what's the point of a software if nobody uses it? So no, your job is not to create great software, your job is to bring value to users. In my career, I've mostly seen the developers pleasuring themselves with overengineering, bloating code with features nobody needs, and writing lines to anticipate future developments that never came. Rather than the opposite. So I think the challenge is to remain minimalistic, that's hard, and that's what the original post is about.

katrotz 2y ago
Unfortunately there is no correct approach since both sloppy and overengineered codebases backfire. What helps me find balance is following the philosophy of 1. Make it work 2. Make it right 3. Make it fast

achenet 2y ago

https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html If you want to write good software, get it in front of someone who will actually use it as soon as possible. Get it in front of many people who use it as soon as possible. No matter how smart you are, you can't anticipate every user need. Let the users tell you what they need. To do that, you need to ship.

lazyasciiart 2y ago

Good news - once you work at a large enough company, this flips to "your job is to finagle your way through a million different safety and security checks at every step in order to write a few lines of code and get them shipped before a pivot and/or re-org makes them irrelevant to your new managers goals".

throwaway84751 2y ago

I was one of the first employees in a startup, and if I hadn't made compromises the company would probably not exist today. Your approach only works for big established companies where your team has limited impact on the results. For small and medium sized companies you definitely need to make compromises. It is part of your job as a professional to make choices that leads to the best business outcome. Unfortunately a lot of developers don't have a connection to the business side, because they are "protected" by several layers of management, PMs and designers that interact with the business on their behalf. Getting a product out quickly means that you also get feedback earlier. This is not only good for business, but it is also an opportunity to evaluate your implementation to see if it matches your assumptions. In my experience this causes less stress compared to rolling out a "perfect" solution that has to be rewritten while under pressure. My job as a developer at my current workplace is to reduce complexity and get the PM and designers to cut down their initial plans to a minimum. It makes arbitrary deadlines less stressful and any delays will not have the same impact.

deleted 2y ago
[deleted]

sisve 2y ago

> Your job as a sw engineer/architect is to resist the "just ship it" pressure from the management as much as possible. So unless you own what you're coding and you really need it out of the door for your own benefit, if more time makes your work more professional, then take more time. Anyone telling you otherwise is a 100% hack. You are not an automaton that takes in JIRA tickets and spits out hacky code as soon as possible. Or at least you shouldn't be. Not to mention that not taking time (doing things properly) is incredibly taxing on your psyche and you WILL burn out. There are only so much garbage tasks you can take. Any job, In any industry at any level should be working together with your manager to understand what the company goal and how to achive that. Its always going to be time/price vs quality if you work on creating software or clothing or whatever. There are properly companies and managers that do not care.. but imbany healthy organisation this should be the case. There is not garbage tasks. Its tasks that needs to be done. Any understanding that not all tasks that needs to be done in an organisation is fun but needs to be done is a sign of maturity that you want from your employees

therouwboat 2y ago
My boss says our goal is to make quality products, but often we don't even have time to check the parts. Once there was a problem that machine didn't make good enough surface finish, but boss just said it's fine, let it run. Turns out it wasn't fine and we had to fix 3000 parts with hand sander. That's why I don't like to cut corners.

danparsonson 2y ago

There's usually an entire pipeline of people waiting on your work - sales & marketing, ops, support - and every delay you induce risks knock-on effects for them, not to mention that depending on the product, customers can be planning their own workloads around your release schedules, so you'll mess them up too. Not all deadlines are arbitrary.

potsandpans 2y ago

What a weird screed.

snozolli 2y ago

if more time makes your work more professional, then take more time. Anyone telling you otherwise is a 100% hack. It sounds like you're a fan of Total Quality Control, as am I. However, it also sounds like you're susceptible to feature drift and undermining yourself with ideas thought up late in the development cycle, as am I. I've seen it from both sides. Software people who want to get just one more feature in, or who want to hold up release to fix an inconsequential bug. Similarly, the CEO who ruminates all weekend and decides we have to revamp something for no objective reason and on a ridiculous deadline.

IanCal 2y ago

> it is NOT your job to make sure the company is the most profitable it can be. Your job is to create great software. Your job is to create great software for the company and your definition of great software is therefore defined by the company. > . What's great software? The kind you'd be willing to put on your resume without feeling bad. If your idea of a good CV is one where you can say "I deliberately made the following companies less money than I could have: ..." then I'm not sure who you're applying to with confidence.

Sammi 2y ago

I would not hire you. I would worry that you would take my money, and not ship anything that makes my company money. I could just as well burn my money for all the good it would do my company. You do know that the point of a company is to make money, right?