4 ms·

You made something that people got a lot of value out of. That’s incredible. The actual code and commits are just the journey. They’re not the product. I’m ra

You made something that people got a lot of value out of. That’s incredible. The actual code and commits are just the journey. They’re not the product. I’m rather delighted every time someone shows a realistic journey full of all the things we all experience, but some of us pretend don’t happen. Thanks for being vulnerable and sharing this.

andremedeiros 3y ago
This is an amazing way to look at it. Thank you for your perspective <3
- LeSaucy 3y ago
  Any developer should be proud of the value that code/backend provided millions of users.
  - napsterbr 3y ago
    Amen to that. When I first started coding (some 15 years ago) I wrote the ugliest, buggiest and "owasp-ridden-est" PHP spaghetti code. Turns out that code went viral and was used by millions of users for a few years. Yet, I came to the conclusion that that's the best code I've ever written, for it's been the most used code I released so far. Real software development is far different than the ideal one.
    - gabereiser 3y ago
      Software managers take note… Your MVP isn’t necessarily your perfect code. It’s the messy, “get it out the door”, value it brings to others. This is your product, refine it from there but don’t hold it back for sake of polishing a turd. Myth busters proved you can indeed, polish a turd. Don’t waste the sprints.
      - 411111111111111 3y ago
        No, that's just wrong. It's totally fine to put scrappy code up to get a product going, but that time has long since passed if you're already at a scale to have dedicated managers. At that point you're likely going to cause more damage to the brand/corp with the half-assed implementation then the value you're providing with said code.
        TheNewsIsHere 3y ago
        I tend to agree with this. My spouse is currently entrenched in an over-budget, under-funded, mismanaged project that was recently announced by the CEO. That’s at a Fortune 500. It all started with a “well we can do an MVP and get that out the door first.” It turns out that was a massive mistake.
        gabereiser 3y ago
        You'll note I said MVP. To get the product going. I agree that once it's going it's best to refine and polish tested features but software managers are still usually hands on at launch phase. Once you have your fit then follow best practice and have a proper process in place (agile, waterfall, whatever). What scale does one have to be to have a manager? Do companies operate without management?
        ARandomerDude 3y ago
        This. A thousand times this. I work on a household-name product with millions of users. It works pretty well most of the time but also has frequent outages, bugs, and usability issues, during which times the 1-star reviews pile up. By far our biggest problems are: 1. Leadership at the time just wanted an MVP, and they wanted it yesterday. 2. Leadership now believes "You don't need more people, and rewrites are a waste of time. Look what we've built with a skeleton crew and tight timelines!" Fellow engineers, beware: if you train your leaders to believe your team can deliver with no budget and unrealistic timelines, they will continue to give you no budget and unrealistic timelines.
        gabereiser 3y ago
callumprentice 3y ago
What a completely lovely way to express what I expect many of us are thinking. Thank you.
roamerz 3y ago
What an awesome comment.

andremedeiros 3y ago

This is an amazing way to look at it. Thank you for your perspective <3

LeSaucy 3y ago
Any developer should be proud of the value that code/backend provided millions of users.
- napsterbr 3y ago
  Amen to that. When I first started coding (some 15 years ago) I wrote the ugliest, buggiest and "owasp-ridden-est" PHP spaghetti code. Turns out that code went viral and was used by millions of users for a few years. Yet, I came to the conclusion that that's the best code I've ever written, for it's been the most used code I released so far. Real software development is far different than the ideal one.
  - gabereiser 3y ago
    Software managers take note… Your MVP isn’t necessarily your perfect code. It’s the messy, “get it out the door”, value it brings to others. This is your product, refine it from there but don’t hold it back for sake of polishing a turd. Myth busters proved you can indeed, polish a turd. Don’t waste the sprints.
    - 411111111111111 3y ago
      No, that's just wrong. It's totally fine to put scrappy code up to get a product going, but that time has long since passed if you're already at a scale to have dedicated managers. At that point you're likely going to cause more damage to the brand/corp with the half-assed implementation then the value you're providing with said code.
      - TheNewsIsHere 3y ago
        I tend to agree with this. My spouse is currently entrenched in an over-budget, under-funded, mismanaged project that was recently announced by the CEO. That’s at a Fortune 500. It all started with a “well we can do an MVP and get that out the door first.” It turns out that was a massive mistake.
      - gabereiser 3y ago
        You'll note I said MVP. To get the product going. I agree that once it's going it's best to refine and polish tested features but software managers are still usually hands on at launch phase. Once you have your fit then follow best practice and have a proper process in place (agile, waterfall, whatever). What scale does one have to be to have a manager? Do companies operate without management?
      - ARandomerDude 3y ago
        This. A thousand times this. I work on a household-name product with millions of users. It works pretty well most of the time but also has frequent outages, bugs, and usability issues, during which times the 1-star reviews pile up. By far our biggest problems are: 1. Leadership at the time just wanted an MVP, and they wanted it yesterday. 2. Leadership now believes "You don't need more people, and rewrites are a waste of time. Look what we've built with a skeleton crew and tight timelines!" Fellow engineers, beware: if you train your leaders to believe your team can deliver with no budget and unrealistic timelines, they will continue to give you no budget and unrealistic timelines.
        gabereiser 3y ago

callumprentice 3y ago

What a completely lovely way to express what I expect many of us are thinking. Thank you.

roamerz 3y ago

What an awesome comment.