It's unfair he didn't include the name of the app in the article (or it's unfair that I can't see properly, if he did). I want to see what this problem was he was trying to solve!
The saddest "Just Ship It" story ever (2020)
31–40 of 316 posts
Re: The saddest "Just Ship It" story ever (2020)
#32Earlier quoted context omitted.
This entire comment reads as someone who has a purely adversarial relationship with their coworkers with little trust. Sounds exhausting!
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.
I don't see any blame assigned in the previous comment.
Re: The saddest "Just Ship It" story ever (2020)
#33There'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 t…
> 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.
Re: The saddest "Just Ship It" story ever (2020)
#34There'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 t…
This entire comment reads as someone who has a purely adversarial relationship with their coworkers with little trust. Sounds exhausting!
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).
Re: The saddest "Just Ship It" story ever (2020)
#35There'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 t…
This entire comment reads as someone who has a purely adversarial relationship with their coworkers with little trust. Sounds exhausting!
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?
Re: The saddest "Just Ship It" story ever (2020)
#36Shipping code is a whole separate product from your product
Its your first devops product, and how well you do that is going to affect your actual product
Re: The saddest "Just Ship It" story ever (2020)
#37Earlier quoted context omitted.
i’ve recently had a revelatory experience with my cofounder, who is focused entirely on sales. we were pitching our product/services to the company execs- and he just owned the room. He definitely oversold, hallucinated a little bit, said some (many) things i never would have said, but he didn’t lie. I have a highly diminished opinion of my talents than compared to reality and i know it. And i can’t fix it, i’ve trie…
When you watch a great salesperson in action it’s like magic. It’s like watching a chess player find moves you couldn’t have found in a million years. They chose the right words that converted to motions of neurons in your counterparty that caused action by them to give you money. Crazy.
I literally couldn’t stop shaking my head on the commute home. I’ve always had the habit of underselling myself. I would have never made that pitch. But he made them believe in the product and in that process made me believe in it too.
Re: The saddest "Just Ship It" story ever (2020)
#38I feel this deep in my bones. I worked on a long while back because I wanted to scratch an itch, and I thought that some of the problems I was seeing, hey, maybe someone else was having them too. So I start kinda-sorta-half-heartedly exploring the idea, writing some pilot code, then I discovered hacker news. And oh boy did people have things to say about the general problem, it's impossible to solve, no one should wa…
I'm sorry that happened to you. The comments here are generally high quality and I've learned quite a lot from them, but there are things I've learned from experience that go against conventional wisdom here. Although not as drastic a case as yours, I think it's often worth being critical of what one reads here and keeping one's ideals until actual experience makes one incline one way or the other.
I would say if you take hacker news advice about what works, you're a bit of a fool. HN readers are in the pool of people who would be your competition.
Re: The saddest "Just Ship It" story ever (2020)
#39There'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 t…
> 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 in…
> 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?
Re: The saddest "Just Ship It" story ever (2020)
#40There'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 t…
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.