The saddest "Just Ship It" story ever (2020)(kitze.io)
kitze.io
The saddest "Just Ship It" story ever (2020)
https://www.kitze.io/posts/saddest-just-ship-it-story-ever
315 comments
> 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.
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.
> 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.
Developers aren't compensated for any extraordinary achievement, though. Unless they own a notable share of the company. So, why should they give everything and get nothing back? How is that fair?
Salespeople and managers usually consider technical guys pariah. They can always be outsourced or otherwise replaced, and they can be blamed, for example for failing to meet impossible targets. If there's success, it always is a manager's achievement.
Developers also get roughly the same pay for both working minimum and for screwing their lives and healths on powerpoint-driven death marches. The compensation for extraordinary success goes to shareholders, and maybe managers or even salespeople.
Developers aren't compensated for any extraordinary achievement, though. Unless they own a notable share of the company. So, why should they give everything and get nothing back? How is that fair?
Salespeople and managers usually consider technical guys pariah. They can always be outsourced or otherwise replaced, and they can be blamed, for example for failing to meet impossible targets. If there's success, it always is a manager's achievement.
Developers also get roughly the same pay for both working minimum and for screwing their lives and healths on powerpoint-driven death marches. The compensation for extraordinary success goes to shareholders, and maybe managers or even salespeople.
> why should they give everything and get nothing back
They aren't giving everything they're there to do a job and that job is make the company profit.
The person you are replying to isn't saying "you need to go the extra mile to make profits" they're saying "you should be focused on making money for the company, not on personal preferences in your code".
They aren't giving everything they're there to do a job and that job is make the company profit.
The person you are replying to isn't saying "you need to go the extra mile to make profits" they're saying "you should be focused on making money for the company, not on personal preferences in your code".
> They aren't giving everything they're there to do a job and that job is make the company profit.
But GP is saying everyone except the devs is there for status and fat bonuses. You’re talking like a defector.
But GP is saying everyone except the devs is there for status and fat bonuses. You’re talking like a defector.
My experience working in this industry is very different and devs do get recognition and sometimes bonuses (if certain goals are hit).
Devs are paid a premium, have generally much more relaxed work schedules than managers or any customer facing role.
If you screw over your health working in a toxic environment that’s on you IMO - as tech worker you probably have more opportunities to improve your working conditions than the vast majority of humans
Devs are paid a premium, have generally much more relaxed work schedules than managers or any customer facing role.
If you screw over your health working in a toxic environment that’s on you IMO - as tech worker you probably have more opportunities to improve your working conditions than the vast majority of humans
I have never known a software developer who got a bonus. Rarely even recognition.
I get two bonuses every year - one for individual achievement and one for profit sharing.
You and every other programmer on the planet then?
Or, what is your comment meant to claim exactly, beyond the extremely obvious "there are exceptions to the rule" trope?
Or, what is your comment meant to claim exactly, beyond the extremely obvious "there are exceptions to the rule" trope?
Well the original notion here was
> Developers aren't compensated for any extraordinary achievement
That as a blanket statement is just not true. Of course it does not apply to every single developer, I would even say it doesn’t apply to the majority.
> Developers aren't compensated for any extraordinary achievement
That as a blanket statement is just not true. Of course it does not apply to every single developer, I would even say it doesn’t apply to the majority.
It is true when it applies to the majority (and nobody said something is only true when it applies to 100% of a group because then absolutely nothing would ever be true when it comes to people). If you think otherwise and are convinced of it then you are very privileged -- and I actually envy you. You have no idea what contractor programmers go through out there, apparently.
This is too angry of a reply to someone adding their personal experience onto your comment about how the world is. I appreciate their anecdote refuting the claim; I think it makes a better discussion than just superlatives so I think you should get back to your point (which I mostly align with) instead of attack them on "just because you showed an example where my rule isn't true doesn't make my rule not true".
So are you saying my point was so obvious that it was unnecessary to be made?
I get recognition plenty. We all get bonuses according to how well our division does, which is developers certainly have a hand in. If you do good work, you also tend to get promotions and raises well beyond the usual 5% per year.
I came to work over a vacation to fix a critical customer issue. The company rewarded me with a $50 gift card.
Companies have internal processes and typically can’t say “here’s an extra 5k for saving our butts!” unless there’s an existing program and money set aside for such spot bonuses. It’s a huge audit risk.
If your management is good, it absolutely is remembered and impacts future performance and promotion cycles.
If your management is good, it absolutely is remembered and impacts future performance and promotion cycles.
I worked with a guy who got a sizable bonus (rumored $200k). The reason? An old college buddy called and asked if our technology could help their social media company with a problem they had.
So, if you want a bonus as a software developer, be a sales rep by happenstance. Probably helps if you went to a prestigious university where you met people who went on to prestigious roles...
So, if you want a bonus as a software developer, be a sales rep by happenstance. Probably helps if you went to a prestigious university where you met people who went on to prestigious roles...
know plenty that get bonuses, yearly. individual performance + company (stock) performance + other variables = some percentage of salary, handed out as RSUs or cash or both.
never seen any one-off bounties or extra bonus for shipping one specific thing. usually it just gets rolled up in the "your yearly performance discussion".
obviously founders / owners / folks holding a lot of stock are playing by different rules
never seen any one-off bounties or extra bonus for shipping one specific thing. usually it just gets rolled up in the "your yearly performance discussion".
obviously founders / owners / folks holding a lot of stock are playing by different rules
Merchant banking. I miss those bonuses
Maybe this is a US vs Europe thing? I'm in the latter region, where I am there's a ceiling for dev salaries, virtually the only way to break through is to become a manager. It's also very uncommon to share the companies success.
Only twice have I worked for a manager who thought it was unethical to ask the devs to work hours they themselves would not work.
The notion that devs have better hours than managers is either a fiction or conflating managers with founders. Who do often work ridiculous hours and expect everyone else to do it too - and enthusiastically - even though they’re the only ones with a stake in the outcome.
The notion that devs have better hours than managers is either a fiction or conflating managers with founders. Who do often work ridiculous hours and expect everyone else to do it too - and enthusiastically - even though they’re the only ones with a stake in the outcome.
Make the company 100 millions and you are lucky to see more than 10k of it.
If you believe otherwise I would question your real life experience.
If you believe otherwise I would question your real life experience.
I’m not saying it’s perfectly proportional to the value created, I was challenging the notion that devs are these wages slaves chained to their desks who never get anything extra while their managers swim in money
While ad hominem is a fallacious way to handle a debate, it is a great way to determine motive for and if debate is even worthwhile.
Maybe that depends on the job market you're working on. In some countries salaries are more affected by personal performance than in others.
My first job as a developer made me work around the clock, day and night, for a below average (nationwide compared) salary. And I got yelled at.
Since I didn't have enough work experience, my applications weren't responded to. There were no ways to improve conditions without changing jobs.
My first job as a developer made me work around the clock, day and night, for a below average (nationwide compared) salary. And I got yelled at.
Since I didn't have enough work experience, my applications weren't responded to. There were no ways to improve conditions without changing jobs.
It sounds like a toxic workplace, but you should do yourself a big favor and try to put that behind you. If you keep that mindset in your new job, your perspective will be negative and you risk burning out.
If you work at a traditional workplace, think of yourself as a professional. Do the best work you can during business hours, without ruining your health. The company is paying you to make decisions that are best for them, and you may not like it but that is what you agreed to. At the same time, they only pay for your work and not your soul. You need to keep a balance between work and you as a person.
Unfortunately there are many toxic workplaces out there, and if I ended up "trapped" with no escape, I would probably consider things differently. But when you finally escape, keep an open mind and try to put your bad experiences behind you.
If you work at a traditional workplace, think of yourself as a professional. Do the best work you can during business hours, without ruining your health. The company is paying you to make decisions that are best for them, and you may not like it but that is what you agreed to. At the same time, they only pay for your work and not your soul. You need to keep a balance between work and you as a person.
Unfortunately there are many toxic workplaces out there, and if I ended up "trapped" with no escape, I would probably consider things differently. But when you finally escape, keep an open mind and try to put your bad experiences behind you.
I'm sorry to say but I'm very much burned out already. It all went well for a while after switching jobs, but the lockdowns and remote work ruined what was left of my life. My friends noted that they don't miss me, my company switched to completely remote etc. I can now only sleep and work, I can't even think of anything else anymore.
I did put that behind me after switching jobs.
My initial outlook and attitude on professional life was that I need to try hard and stay positive and help everyone. I expected other people to work for common goals, put their own goals aside, and be friendly. As in school, that mostly lead to abuse. I'm only advocating against trying too hard because I've hurt myself with it.
As a child, I was taught to go the extra mile, work in a sustainable manner and never blame anyone. At work, I have never refused to work on a problem because it's not my fault or someone else would be a better fit for it - and that makes me a very good scapegoat and a fine target for impossible requests.
Guess what happened? I'm right now stuck with a person who is asking daily for something I have explained to be impossible, and does not accept my answer. So he asks again. I have no idea what to do.
I can't set boundaries or take care of myself, so I'm a bad employee and a bad person who doesn't try enough. Great.
I did put that behind me after switching jobs.
My initial outlook and attitude on professional life was that I need to try hard and stay positive and help everyone. I expected other people to work for common goals, put their own goals aside, and be friendly. As in school, that mostly lead to abuse. I'm only advocating against trying too hard because I've hurt myself with it.
As a child, I was taught to go the extra mile, work in a sustainable manner and never blame anyone. At work, I have never refused to work on a problem because it's not my fault or someone else would be a better fit for it - and that makes me a very good scapegoat and a fine target for impossible requests.
Guess what happened? I'm right now stuck with a person who is asking daily for something I have explained to be impossible, and does not accept my answer. So he asks again. I have no idea what to do.
I can't set boundaries or take care of myself, so I'm a bad employee and a bad person who doesn't try enough. Great.
It sounds like you have ended up in a bad situation. There's no real suggestion I can provide for how you can improve your situation, other than to try to find a way to disconnect. (Meetups, walking, museums, hobbies).
Maybe that means talking to a professional therapist to find out how you can handle the situation. They get paid to help you, and there is no shame in that
Maybe that means talking to a professional therapist to find out how you can handle the situation. They get paid to help you, and there is no shame in that
They usually get paid by the hour so they have a vested interest to talk BS and prolong the session as much as they can.
If they ask for the impossible then perhaps things are not looking good for the company. I think you better figure out somewhere else to go soon because that tends to mean they won't last much longer. It's a tough market but there is always hope, try and build out some side projects and get out before your company starts to fold or you are let go. Sometimes just a change of view is nice so maybe try something different.
A good therapist can help you with this.
> It sounds like a toxic workplace
Like most workplaces on the planet. Check your bubble.
I agree with your advice but you have to understand that many people start families and that tilts the table in favor of the employer; people become very risk-averse and dare not refuse anything. This is a fact and it's happening every second to dozens, if not hundreds, of millions of people out there.
> Unfortunately there are many toxic workplaces out there, and if I ended up "trapped" with no escape, I would probably consider things differently.
Please do. Living paycheck to paycheck is the reality of most working people.
Like most workplaces on the planet. Check your bubble.
I agree with your advice but you have to understand that many people start families and that tilts the table in favor of the employer; people become very risk-averse and dare not refuse anything. This is a fact and it's happening every second to dozens, if not hundreds, of millions of people out there.
> Unfortunately there are many toxic workplaces out there, and if I ended up "trapped" with no escape, I would probably consider things differently.
Please do. Living paycheck to paycheck is the reality of most working people.
You just sound like you're venting and depressed tbh, if you're in STEM and working "paycheck to paycheck" then either there is a skills mismatch or you refuse to improve in some critical way that has been addressed to you already.
this reply goes for everyone complaining about jobs really, everyone has strengths and areas where they can grow- so focusing on these can lead to greater job satisfaction.
this reply goes for everyone complaining about jobs really, everyone has strengths and areas where they can grow- so focusing on these can lead to greater job satisfaction.
Thanks for your assumptions.
> So, why should they give everything and get nothing back? How is that fair?
Ofcourse it is fair. How can you say you get nothing back? They pay you salary you agreed on when signed contract.
> My first job as a developer made me work around the clock
Bad employer. Maybe doesn't obey the contract on their side and doesn't pay for overtime. Tough one until you level up your experience for sure.
But I'd expect salary to be below average in your first job. You still don't have the necessary experience. And when you do, you CAN find another job.
Just don't have bad attitude towards your job. You will be rewarded one day for being a honest and productive worker.
Ofcourse it is fair. How can you say you get nothing back? They pay you salary you agreed on when signed contract.
> My first job as a developer made me work around the clock
Bad employer. Maybe doesn't obey the contract on their side and doesn't pay for overtime. Tough one until you level up your experience for sure.
But I'd expect salary to be below average in your first job. You still don't have the necessary experience. And when you do, you CAN find another job.
Just don't have bad attitude towards your job. You will be rewarded one day for being a honest and productive worker.
> You will be rewarded one day for being a honest and productive worker.
22.5 years later I can confidently say you are living in a comfortable bubble and have no idea what do most programmers go through every day.
22.5 years later I can confidently say you are living in a comfortable bubble and have no idea what do most programmers go through every day.
I would say that their view is akin to religion. Any religion really.
And religion is not always bad. It can help us stay focused, and selfless for some unknown greater good.
That greater good does not have to exist. But decreasing the focus on self can still be good for your soul.
And religion is not always bad. It can help us stay focused, and selfless for some unknown greater good.
That greater good does not have to exist. But decreasing the focus on self can still be good for your soul.
> But decreasing the focus on self can still be good for your soul.
Only applies to people who mostly focused on themselves.
I'd argue that most working people have the opposite problem: they have to focus on everybody else's problems but not theirs.
I'm only working towards tangible greater goods. Including my own inner peace.
Only applies to people who mostly focused on themselves.
I'd argue that most working people have the opposite problem: they have to focus on everybody else's problems but not theirs.
I'm only working towards tangible greater goods. Including my own inner peace.
i think whether it is fair isnt the right question (which is subjective and I disagree anyway) but whether it is rational and advantageous for you. What benefit do you get for rushing a job and shipping shitty code? I think the downsides vastly outweigh the upside.
If a company is that pressed for time, theyre not going to fire you. Take your time and do things right, dont Boeing it up.
If a company is that pressed for time, theyre not going to fire you. Take your time and do things right, dont Boeing it up.
I'm sorry to hear that.
I had a similarly shitty first job, although I was lucky to be in France, which was very strict worker protection laws, so "working day and night" was 'only' 10 hour days. However, after like 8 months there I was able to get another job - it doesn't take much experience for recruiters to start reaching out on LinkedIn aparantly.
I had a similarly shitty first job, although I was lucky to be in France, which was very strict worker protection laws, so "working day and night" was 'only' 10 hour days. However, after like 8 months there I was able to get another job - it doesn't take much experience for recruiters to start reaching out on LinkedIn aparantly.
We have the laws in place in Finland, too, but they aren't enforced in practice. So, people who refuse to obey them get an advantage against people with integrity.
The workers protection authorities are not resourced to do any individual checkups, and going to court against a company would take years and possibly leads to lifetime in debt. So the practical way to resolve this is to change companies.
The workers protection authorities are not resourced to do any individual checkups, and going to court against a company would take years and possibly leads to lifetime in debt. So the practical way to resolve this is to change companies.
Developers aren't compensated for any extraordinary achievement, though. Unless they own a notable share of the company. So, why should they give everything and get nothing back? How is that fair
Get nothing?! What a strange way to view a paycheque.
"Hi, you're only paying me, but that's not enough to expect a solid work ethic. Instead, I'll make sure my work is just passable. Want more, and now you have to pay me more!"
Where I come from, "extraordinary achievement" is just "doing your job".
(Are you advocating something else? I'm not suggesting free overtime, just doing the best job you can.)
Get nothing?! What a strange way to view a paycheque.
"Hi, you're only paying me, but that's not enough to expect a solid work ethic. Instead, I'll make sure my work is just passable. Want more, and now you have to pay me more!"
Where I come from, "extraordinary achievement" is just "doing your job".
(Are you advocating something else? I'm not suggesting free overtime, just doing the best job you can.)
that scene from Office Space where he talks about "I do just enough not to get fired" may be relevant here.
There is something to be said for 'if you're going to be a rational economic actor and you have a salaried job, the optimal strategy is finish your job's tasks as fast as possible and work on a personal project which you control the upside to with all your extra energy'.
From a purely economic point of view, spending any effort beyond the minimum at a salaried job is a waste of effort - the expected value of that extra effort is nil, unless you own significant stock. This may be why many tech companies offer equity as part of their compensation.
There is something to be said for 'if you're going to be a rational economic actor and you have a salaried job, the optimal strategy is finish your job's tasks as fast as possible and work on a personal project which you control the upside to with all your extra energy'.
From a purely economic point of view, spending any effort beyond the minimum at a salaried job is a waste of effort - the expected value of that extra effort is nil, unless you own significant stock. This may be why many tech companies offer equity as part of their compensation.
If you're going to sandbag you should aim for slightly below average. Minimum leaves you no room for error.
I call it (doing the bare minimum required) "organizational laziness" and I hate it. It might be rational, but it leads to mediocrity.
OK, hire me, and if I over-perform and help you achieve a business target, I want a triple salary next month. Or better still, 20% of the extra profit.
No? Then you'll keep seeing what you call "mediocrity".
I am a pretty good programmer and have literally saved businesses, several times over the course of my career.
Never again though. A pat on the back is not enough of a reward.
No? Then you'll keep seeing what you call "mediocrity".
I am a pretty good programmer and have literally saved businesses, several times over the course of my career.
Never again though. A pat on the back is not enough of a reward.
Sorry to disappoint, but.. I don't want to hire you. I am a socialist, I find labor markets morally objectionable. The above is one reason, putting pursuit of profit above human excellence leads to mediocrity.
What benefit does excellence derive for the excellent then, other than feel-good bubbly feelings? If labor cannot differentiate itself then collectively it will do the minimum acceptable and everybody will be mediocre (unless autism).
> What benefit does excellence derive for the excellent then, other than feel-good bubbly feelings?
Ultimately anything can only give you feelings. I don't understand what else would you expect from (pursuing) being excellent (just to clarify, I define "being excellent" here as being extremely skilled at some ex ante selected task or creative process; both individuals and organizations can have that property).
But I get what you're saying. You feel like being excellent should give you money, fame and ladies. But you can get these things without being excellent. At some point, being excellent is a burden, and it's irrational to pursue it if you have those goals (of money, fame, etc.). (Someone else said in this thread that they want "a credit" for the excellence. Well if you want that, you don't need to be excellent, you just need to be good at pretending that you're, in front of people who you ask for the credit.)
Now, corporations (and private companies in general) are setup to pursuit profit, not excellency. If excellency gets in the way of profit, and mediocrity is sufficient, they won't pursue excellency, regardless what the individuals in those companies want. That's organizational laziness. Note that organizational laziness is rational (and we teach it to MBAs), because rationality only ever makes sense with respect to your goals (which here is pursuit of profit, not of excellency). But that also means, rationality is never gonna tell you which goals you should pursue. Therefore, to decide to want excellency will always be an inherently irrational act (therefore, you only do it for good feelings).
The point of the second comment I made was that yes, some people choose to build mediocre (capitalist) organizations (based on profit maximization and labor market) in pursuit of organizational excellency. To me as a socialist, this is a foolish mistake. If you're interested in excellency, you should build organizations of peers (like cooperatives) who intrinsically share that goal, not subordinates who have to be motivated extrinsically. I should also note, every organization will get parasites who have different goals, like work for less effort. Unless these people are somehow a burden on the goal of excellency, they are less problematic in organizations that pursue excellency than in capitalist organizations that pursue profit. Therefore, the organizations where the excellency maximization is a goal may seem to be collectively less efficient (more wasteful) than those where profit maximization is a goal. Again, this comes from the fact that being excellent is not necessarily the optimal way to pursue an extrinsic goal, such as profit.
Ultimately anything can only give you feelings. I don't understand what else would you expect from (pursuing) being excellent (just to clarify, I define "being excellent" here as being extremely skilled at some ex ante selected task or creative process; both individuals and organizations can have that property).
But I get what you're saying. You feel like being excellent should give you money, fame and ladies. But you can get these things without being excellent. At some point, being excellent is a burden, and it's irrational to pursue it if you have those goals (of money, fame, etc.). (Someone else said in this thread that they want "a credit" for the excellence. Well if you want that, you don't need to be excellent, you just need to be good at pretending that you're, in front of people who you ask for the credit.)
Now, corporations (and private companies in general) are setup to pursuit profit, not excellency. If excellency gets in the way of profit, and mediocrity is sufficient, they won't pursue excellency, regardless what the individuals in those companies want. That's organizational laziness. Note that organizational laziness is rational (and we teach it to MBAs), because rationality only ever makes sense with respect to your goals (which here is pursuit of profit, not of excellency). But that also means, rationality is never gonna tell you which goals you should pursue. Therefore, to decide to want excellency will always be an inherently irrational act (therefore, you only do it for good feelings).
The point of the second comment I made was that yes, some people choose to build mediocre (capitalist) organizations (based on profit maximization and labor market) in pursuit of organizational excellency. To me as a socialist, this is a foolish mistake. If you're interested in excellency, you should build organizations of peers (like cooperatives) who intrinsically share that goal, not subordinates who have to be motivated extrinsically. I should also note, every organization will get parasites who have different goals, like work for less effort. Unless these people are somehow a burden on the goal of excellency, they are less problematic in organizations that pursue excellency than in capitalist organizations that pursue profit. Therefore, the organizations where the excellency maximization is a goal may seem to be collectively less efficient (more wasteful) than those where profit maximization is a goal. Again, this comes from the fact that being excellent is not necessarily the optimal way to pursue an extrinsic goal, such as profit.
> Ultimately anything can only give you feelings.
Hand-wavy dismissals are not a discussion argument. I don't accept this as a rebuttal.
> You feel like being excellent should give you money, fame and ladies.
And that's called "tearing down a straw man". Why are you arguing in such a bad faith?
The only thing most of us who finally smartened up about the labor market is this: profit must correspond with reward.
You and others seem to conflate this pragmatic view with the suggestion that we do sloppy work. No, we do our work just fine and we do it well, reliably, and on schedule. What we do NOT do is to go above and beyond.
But you and others seem to get triggered on other topics (mostly about human excellence and "we as a society must all help") that have almost nothing to do with the discussed topic and give your takes not on it, but on these other things.
Finally, profit being an "extrinsic goal" is a needless philosophization and does not advance any discussion.
Hand-wavy dismissals are not a discussion argument. I don't accept this as a rebuttal.
> You feel like being excellent should give you money, fame and ladies.
And that's called "tearing down a straw man". Why are you arguing in such a bad faith?
The only thing most of us who finally smartened up about the labor market is this: profit must correspond with reward.
You and others seem to conflate this pragmatic view with the suggestion that we do sloppy work. No, we do our work just fine and we do it well, reliably, and on schedule. What we do NOT do is to go above and beyond.
But you and others seem to get triggered on other topics (mostly about human excellence and "we as a society must all help") that have almost nothing to do with the discussed topic and give your takes not on it, but on these other things.
Finally, profit being an "extrinsic goal" is a needless philosophization and does not advance any discussion.
I too strive to be humanly excellent. I don't strive to make my boss' bonus bigger.
Start your thought process by making the extremely obvious distinction between these two.
Start your thought process by making the extremely obvious distinction between these two.
Starts at the top.
Lazy pay, lazy perks -> lazy workers.
Lazy pay, lazy perks -> lazy workers.
This. From worker's point of view it's irrational to work hard if the pay sucks. Good management should realize that, and demand less from underpaid workers. Embrace the culture of laziness, or pay a fair wage.
Not just at the top, you have to go higher than that. It starts with the idea that the market success always leads to excellency.
whats mediocre is willingly being a cog, in my opinion. Cogs dont get any credit.
No, Office Space depicted a horrible office environment, most are not such. And minimalist work ethic is a poor one, regardless of hand wavy, trumped up, rationalizations.
> And minimalist work ethic is a poor one, regardless of hand wavy, trumped up, rationalizations.
That's a very protestant work ethic worldview. Doing what is expected from what you're being paid in the best way possible is not a poor work ethic, it's a pretty rational one.
The other side of it where one always strive to do more, to go above and beyond what you're being compensated for, and so forth can also be a quite poor one. God is not going to give you extra points, for some people doing their best work at current expectations is good enough, no need to spend more energy than required on a job, there's more to life than working and accumulating.
That's a very protestant work ethic worldview. Doing what is expected from what you're being paid in the best way possible is not a poor work ethic, it's a pretty rational one.
The other side of it where one always strive to do more, to go above and beyond what you're being compensated for, and so forth can also be a quite poor one. God is not going to give you extra points, for some people doing their best work at current expectations is good enough, no need to spend more energy than required on a job, there's more to life than working and accumulating.
Trying to bring religion into this is beyond amusing. I guess the Japanese are all protestants? Hardly. And rationalizing poor behaviour by saying it's rational is another good one. Lastly, you're trying to shift the discussion by claiming "best way possible" as opposed to others saying "do the bare minimum". These are very often not the same.
The problem is, people don't "get it". There are people in this thread protesting about "doing poor quality work", eg, "racking up tech debt". Why?
Because it eats at them. Because they are in this to build, and build that which holds, which has value.
They have pride in their work! Yet the response some have here is simply don't do the best you can do. These two things are counter to one another!
I am advocating that yes, do the best you can do. Take joy, deep internal joy in doing your job correctly, because of what you build. This indeed does not mean doing the bare minimum, by some broken, made up rationalized excuse.
As I said, a good work ethic is not a protestant thing, it is a human thing.
We can expand this to everything. What are you being compensated for? Are your ethics formed around what's profitable?! Madness!
The problem is, people don't "get it". There are people in this thread protesting about "doing poor quality work", eg, "racking up tech debt". Why?
Because it eats at them. Because they are in this to build, and build that which holds, which has value.
They have pride in their work! Yet the response some have here is simply don't do the best you can do. These two things are counter to one another!
I am advocating that yes, do the best you can do. Take joy, deep internal joy in doing your job correctly, because of what you build. This indeed does not mean doing the bare minimum, by some broken, made up rationalized excuse.
As I said, a good work ethic is not a protestant thing, it is a human thing.
We can expand this to everything. What are you being compensated for? Are your ethics formed around what's profitable?! Madness!
That's actually a very interesting point of view.
It's also interesting that you bring the Japanese into this. While they certainly to care a lot about producing high quality work, they also have one of the world's highest suicide rates.
I understand taking pride in what you build.
However:
1) it's important to not let that destroy the rest of your life
2) it's a lot easier to take pride in what you build when you're working on something you own[0]. As I believe I alluded to in other comments on this thread, and was kind of insinuating with the original comment that you replied to, deciding that extra effort spent on a dysfunctional enterprise project micro-managed by 3 competing orgs who spend their time changing requirements in order to win minor political victories (yes, this is an extreme example, please bear with me) is better spent on a personal open-source project, or even building something like a sport club or happy family seems to be the logical course of action when you care about what you build.
Which isn't to say don't do the best you can at work - ship the code they ask you to ship, write it well, add unit tests, all that jazz. But then once that's done, you can either focus on being the best employee for Megacorp, which is likely to be soul-crushing, because you'll have extremely little reward for your effort, or you can be the best employee of You, LLC, where you natural human desire to make something beautiful can express itself in a way that is much more rewarding for you, both financially and emotionally.
[0] https://paulgraham.com/own.html
It's also interesting that you bring the Japanese into this. While they certainly to care a lot about producing high quality work, they also have one of the world's highest suicide rates.
I understand taking pride in what you build.
However:
1) it's important to not let that destroy the rest of your life
2) it's a lot easier to take pride in what you build when you're working on something you own[0]. As I believe I alluded to in other comments on this thread, and was kind of insinuating with the original comment that you replied to, deciding that extra effort spent on a dysfunctional enterprise project micro-managed by 3 competing orgs who spend their time changing requirements in order to win minor political victories (yes, this is an extreme example, please bear with me) is better spent on a personal open-source project, or even building something like a sport club or happy family seems to be the logical course of action when you care about what you build.
Which isn't to say don't do the best you can at work - ship the code they ask you to ship, write it well, add unit tests, all that jazz. But then once that's done, you can either focus on being the best employee for Megacorp, which is likely to be soul-crushing, because you'll have extremely little reward for your effort, or you can be the best employee of You, LLC, where you natural human desire to make something beautiful can express itself in a way that is much more rewarding for you, both financially and emotionally.
[0] https://paulgraham.com/own.html
What is seen as "good work ethic" is absolutely a cultural thing, and at least partially explains economic success (or lack of) in many countries. The Japanese aren't protestant, but they have other elements in their culture that encourage hard work as a virtue.
I take joy in projects that I actually find meaningful. Being an underpaid cog in the machine, working on JIRA tasks visioned by someone else isn't meaningful. Lack of adequate pay makes me feel underappreciated, and frankly destroys any motivation I could otherwise have. So no, I'm doing the bare minimum and don't feel bad about it. I treat my employer like it treats me, that's called justice.
I take joy in projects that I actually find meaningful. Being an underpaid cog in the machine, working on JIRA tasks visioned by someone else isn't meaningful. Lack of adequate pay makes me feel underappreciated, and frankly destroys any motivation I could otherwise have. So no, I'm doing the bare minimum and don't feel bad about it. I treat my employer like it treats me, that's called justice.
It's not beyond amusing, the protestant work ethic is the tradition from where a lot of nations have derived their work ethic from. Just like the Japanese derived their work ethic from their traditions, bringing it up is just clearing the way that yes, it's a religion-originated way of thinking about work, there's nothing wrong about that and you getting hung up on it is what's truly beyond amusing.
> Lastly, you're trying to shift the discussion by claiming "best way possible" as opposed to others saying "do the bare minimum". These are very often not the same.
Because the discussion gets murky exactly at this point. Doing the bare minimum means not going out of the way to solve issues for others, like Americans working outside of their working hours and bosses expecting that should be done. I have many work colleagues in the USA who are beyond annoying by trying to prove themselves by working outside of what they are paid for, with the thought they should go "above and beyond" instilled in their minds. It just creates issues for other cultures who do not prize themselves in sacrificing their lives for the job.
The other side of it is doing the best work you are willing to do, with the limitations you currently have (skill, health [physical or mental], time, etc.), that's what I call "bare minimum" for myself. I won't be wasting my time trying to come up with new products, new paths of generating revenue, simply because I'm not paid for that, when I am in that spot I definitely offer the best help I can but I won't be fighting political infights, depriving myself of a life to work another 2h/day to setup a new project for some higher ups, and so on.
> I am advocating that yes, do the best you can do. Take joy, deep internal joy in doing your job correctly, because of what you build. This indeed does not mean doing the bare minimum, by some broken, made up rationalized excuse.
You don't need to take deep internal joy of doing your job correctly, at all, one just need to have a work ethic that doing your job correctly is the right thing to do, it's what I'm being paid for, and that's the bare minimum. If that means I can slack off a little bit because I'm aware I can deliver what's expected so be it.
Perhaps we are talking past each other here because I do not disagree mostly with you, I probably just disagree with your approach to it (and hence what I called a derivative of the protestant work ethic).
> As I said, a good work ethic is not a protestant thing, it is a human thing.
Not necessarily, if your work is bullshit and you are not paid enough for it without much chance to do something else because of life's circumstances there's absolutely no inner motivation to have good work ethic.
> We can expand this to everything. What are you being compensated for? Are your ethics formed around what's profitable?! Madness!
Much the opposite, what's profitable is usually the least of my concerns ethically-wise, I would even say it is most times detrimental to ethical behaviour.
> Lastly, you're trying to shift the discussion by claiming "best way possible" as opposed to others saying "do the bare minimum". These are very often not the same.
Because the discussion gets murky exactly at this point. Doing the bare minimum means not going out of the way to solve issues for others, like Americans working outside of their working hours and bosses expecting that should be done. I have many work colleagues in the USA who are beyond annoying by trying to prove themselves by working outside of what they are paid for, with the thought they should go "above and beyond" instilled in their minds. It just creates issues for other cultures who do not prize themselves in sacrificing their lives for the job.
The other side of it is doing the best work you are willing to do, with the limitations you currently have (skill, health [physical or mental], time, etc.), that's what I call "bare minimum" for myself. I won't be wasting my time trying to come up with new products, new paths of generating revenue, simply because I'm not paid for that, when I am in that spot I definitely offer the best help I can but I won't be fighting political infights, depriving myself of a life to work another 2h/day to setup a new project for some higher ups, and so on.
> I am advocating that yes, do the best you can do. Take joy, deep internal joy in doing your job correctly, because of what you build. This indeed does not mean doing the bare minimum, by some broken, made up rationalized excuse.
You don't need to take deep internal joy of doing your job correctly, at all, one just need to have a work ethic that doing your job correctly is the right thing to do, it's what I'm being paid for, and that's the bare minimum. If that means I can slack off a little bit because I'm aware I can deliver what's expected so be it.
Perhaps we are talking past each other here because I do not disagree mostly with you, I probably just disagree with your approach to it (and hence what I called a derivative of the protestant work ethic).
> As I said, a good work ethic is not a protestant thing, it is a human thing.
Not necessarily, if your work is bullshit and you are not paid enough for it without much chance to do something else because of life's circumstances there's absolutely no inner motivation to have good work ethic.
> We can expand this to everything. What are you being compensated for? Are your ethics formed around what's profitable?! Madness!
Much the opposite, what's profitable is usually the least of my concerns ethically-wise, I would even say it is most times detrimental to ethical behaviour.
you can be very hard working on things that aren't your day job.
As I'm writing these words, an aspiring musician is probably sleepwalking through his day job because he was up all night practicing his music.
Or Paul Graham, when he talks about writing the book On Lisp during his time at Interleaf [0]
[0] https://paulgraham.com/worked.html
As I'm writing these words, an aspiring musician is probably sleepwalking through his day job because he was up all night practicing his music.
Or Paul Graham, when he talks about writing the book On Lisp during his time at Interleaf [0]
[0] https://paulgraham.com/worked.html
> No, Office Space depicted a horrible office environment, most are not such.
You are right.
...Most are much worse. :D
You are right.
...Most are much worse. :D
"I'll make sure my work is just passable" is a very strange interpretation of the original statement, which was "if more time makes your work more professional, then take more time."
You are not being paid enough to rack up tech debt during 80 hour weeks constantly moving from one sales-driven project to the next, because that's a stupid way to develop software and it'll burn you out after a year of back-to-back "why isn't XYZ done?"/"why didn't you make XYZ not buggy?" meetings, at which point you'd better have made enough money to retire to the Bahamas.
You are not being paid enough to rack up tech debt during 80 hour weeks constantly moving from one sales-driven project to the next, because that's a stupid way to develop software and it'll burn you out after a year of back-to-back "why isn't XYZ done?"/"why didn't you make XYZ not buggy?" meetings, at which point you'd better have made enough money to retire to the Bahamas.
You get a salary for doing the expected work, not extraordinary work.
Exactly. Do the expected work well, but don't sacrifice yourself so that other people can use, abuse and eventually desert you.
Having the interests of the bottom line of the business in mind does not equate to sacrificing yourself.
Do what's expected in the interests of the business, not in pursuit of some "great software" ideal.
Do what's expected in the interests of the business, not in pursuit of some "great software" ideal.
> Having the interests of the bottom line of the business in mind does not equate to sacrificing yourself.
Only in theory. In practice, the incompetent leadership leads to those naturally being identical, as in "we have to deliver project 17 for this year, please do your best!!!" and ad infinitum.
> Do what's expected in the interests of the business, not in pursuit of some "great software" ideal.
Who mentioned this? Only you. A projection on your part, it seems.
Only in theory. In practice, the incompetent leadership leads to those naturally being identical, as in "we have to deliver project 17 for this year, please do your best!!!" and ad infinitum.
> Do what's expected in the interests of the business, not in pursuit of some "great software" ideal.
Who mentioned this? Only you. A projection on your part, it seems.
The original poster of the thread mentioned it.
>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.
>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.
Thought we were talking about the sub thread but okay, I'll give you that.
You did omit the first part of my comment however.
You did omit the first part of my comment however.
What is this "extraordinary work" we are talking about here exactly?
If that is your experience with companies and managers, you have to choose your jobs more wisely. In good companies managers were engineers at some point as well and know what is important technically and motivationally.
Its rare in any field to be compensated for any extraordinary achievement. But these are the people I like to work with.
Surgeons save lives which they may find important and motivating per se.
Grinding meaningless Javascript to deliver more advertisements and conflict to people is neither motivating nor important, or at least it shouldn't be to a responsive person.
Grinding meaningless Javascript to deliver more advertisements and conflict to people is neither motivating nor important, or at least it shouldn't be to a responsive person.
1) Not all surgeons save lives
2) Not everyone can be a doctor
We can all find meaning in our own work.
2) Not everyone can be a doctor
We can all find meaning in our own work.
The best paid ones work on vanity projects.
> get roughly the same pay
where?
where?
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.
Look: job 1 is making safe software, job 2 is making money and job 3 is perfecting the architecture.
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.
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.
> It is absolutely everybody's job in the company to make sure it is profitable, unless you work for a non-profit.
Common misconception, but a non-profit needs to make a profit, too. It just gets invested back into the business instead of distributed to shareholders, or in fact to any individuals.
Common misconception, but a non-profit needs to make a profit, too. It just gets invested back into the business instead of distributed to shareholders, or in fact to any individuals.
Personally, I’ve never seen good developers who cared at all about profitability. All of them cared about the products and customers, but no one was driven by profit at all. Whom I met and cared about profit, they were mediocre the best.
>It is absolutely everybody's job in the company to make sure it is profitable, unless you work for a non-profit.
To generalise this, it's everyone's job to create value. This may or may not result in profit, but ultimately aligns with the goals of the organisation.
To generalise this, it's everyone's job to create value. This may or may not result in profit, but ultimately aligns with the goals of the organisation.
It's more contextual than that.
In some cases, ship vs not ship, profit vs not profit, is the difference between a company thriving and failing to thrive.
In others, there are second- or third-order effects that render marginal profitability kind of irrelevant to the trajectory. This usually applies to either very large / institutional orgs, or situations where the business is leveraged by investors (VC or PE) such that the kind of honest profit earned by shipping an update or a new product won't meaningfully impact on the company's fate. In those situations, doing good engineering and cleaning up tech debt might make more difference to yours and your colleagues' lives, and maybe even your customers', than shipping.
In some cases, ship vs not ship, profit vs not profit, is the difference between a company thriving and failing to thrive.
In others, there are second- or third-order effects that render marginal profitability kind of irrelevant to the trajectory. This usually applies to either very large / institutional orgs, or situations where the business is leveraged by investors (VC or PE) such that the kind of honest profit earned by shipping an update or a new product won't meaningfully impact on the company's fate. In those situations, doing good engineering and cleaning up tech debt might make more difference to yours and your colleagues' lives, and maybe even your customers', than shipping.
> In some cases, ship vs not ship, profit vs not profit, is the difference between a company thriving and failing to thrive.
That's their problem, not mine. I get paid a fixed amount. If I get paid the same + a percentage of outcome then I'll change how I work.
Easy to understand, I believe.
That's their problem, not mine. I get paid a fixed amount. If I get paid the same + a percentage of outcome then I'll change how I work.
Easy to understand, I believe.
The problem is then you’re not being paid enough.
That is also true.
It becomes a nasty chicken and the egg problem though -- many companies pay less as a risk management strategy, and that leads to the employee not having enough motivation. Of course from then on he/she does not want to excel and the employer concludes they made the right decision which is of course super wrong.
It's quite tragic on a human level but I stopped caring about that aspect as well. At my age and experience I just shrug and say "You get what you pay for" and I am not interested in trying to school people who would never change anyway.
It becomes a nasty chicken and the egg problem though -- many companies pay less as a risk management strategy, and that leads to the employee not having enough motivation. Of course from then on he/she does not want to excel and the employer concludes they made the right decision which is of course super wrong.
It's quite tragic on a human level but I stopped caring about that aspect as well. At my age and experience I just shrug and say "You get what you pay for" and I am not interested in trying to school people who would never change anyway.
Making a great product and maximizing profitability are often at odds. E.g. see all those dark patterns.
> It is absolutely everybody's job in the company to make sure it is profitable, unless you work for a non-profit.
This attitude is more likely to get you fired than rewarded in most companies.
If you step outside your role, or even lift your head up and peek around and offer your thoughts about what you see, you'll be at greater risk for no reward.
Again, in most companies, not all.
This attitude is more likely to get you fired than rewarded in most companies.
If you step outside your role, or even lift your head up and peek around and offer your thoughts about what you see, you'll be at greater risk for no reward.
Again, in most companies, not all.
>> 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.
I believe that depends on the role you have. If you're a software engineer I think you should try to create great software. If you're responsible for the product you can decide it might be better for the product to ship earlier or with the current state of software but I think you should not keep your software engineers from trying to make the software great. You can try to shift their focus on a different (software) topic that you think is more important if you don't like what they are currently trying to improve.
>It really isn't, your job is to make a great product. Making a great product often, but not always, requires great software.
I believe that depends on the role you have. If you're a software engineer I think you should try to create great software. If you're responsible for the product you can decide it might be better for the product to ship earlier or with the current state of software but I think you should not keep your software engineers from trying to make the software great. You can try to shift their focus on a different (software) topic that you think is more important if you don't like what they are currently trying to improve.
Depends on what you mean with great software of course, but a developer should work together with the product team to come to a specific realization of the product vision. That vision may not always require great software, and it may actually specifically call for hacky software, but the product people cannot make that judgement call (and if you are in a healthy company, they don't).
This is different from always making great software but shifting priorities.
This is different from always making great software but shifting priorities.
> absolutely everybody's job in the company to make sure it is profitable
Absolutely and categorically it is not. That is complete nonsense. Why should an employee care? Unless there's some profit sharing scheme in place that would benefit the said employee and they took advantage of that scheme. And even then, employees typically (and I'd even say in the vast majority of cases) have very few and tiny levers to pull to affect company profitability. So you typically you get nothing if the profit is x and nothing if the profit is x+n and even if you get some of that n you can't really affect the absolute value of n. Why should you care about n again? Oh, right, so the company doesn't go under and/or lays you off. That shit may have worked 20-30 years ago when company loyalty and upwards mobility was a thing.
> It really isn't, your job is to make a great product.
Nope, that's the product manager's job. Here, a Wikipedia link, just for you: https://en.wikipedia.org/wiki/Product_manager
Absolutely and categorically it is not. That is complete nonsense. Why should an employee care? Unless there's some profit sharing scheme in place that would benefit the said employee and they took advantage of that scheme. And even then, employees typically (and I'd even say in the vast majority of cases) have very few and tiny levers to pull to affect company profitability. So you typically you get nothing if the profit is x and nothing if the profit is x+n and even if you get some of that n you can't really affect the absolute value of n. Why should you care about n again? Oh, right, so the company doesn't go under and/or lays you off. That shit may have worked 20-30 years ago when company loyalty and upwards mobility was a thing.
> It really isn't, your job is to make a great product.
Nope, that's the product manager's job. Here, a Wikipedia link, just for you: https://en.wikipedia.org/wiki/Product_manager
You're conflating work with responsibility. Let me ask you this: How many product managers does it take to make a product?
Its interesting that a lot of the replies here are railing against the idea that software devs are used as cogs in a machine, yet at the same time all replies are arguing that a dev should only be a cog in the machine, and any further context/awareness/action outside of being a cog should either not be expected or make the dev eligible for an outsized reward.
So to zoom in on your reply:
> Why should an employee care
Because they are paid to make the company profitable, and if they fail to do so they may not continue to be employed. I'm not sure why this is controversial. This requires no profit sharing to be in place, because it is simply the job that is required of the employee. It is probably by far the most general description of a job that is not: "the thing you do for money".
It may very well appear that the employee has no direct influence on company profitability, but since this is nearly impossible to measure objectively the next best thing is to try to make sure that he or she does by listening to signals coming down the hierarchy of management. Your PO telling you to hack a thing together is such a signal, and should be listened to. You warning about a giant pile of tech debt is a signal you should send to your PO, that he/she should listen to.
This is all absolutely trivial.
Its interesting that a lot of the replies here are railing against the idea that software devs are used as cogs in a machine, yet at the same time all replies are arguing that a dev should only be a cog in the machine, and any further context/awareness/action outside of being a cog should either not be expected or make the dev eligible for an outsized reward.
So to zoom in on your reply:
> Why should an employee care
Because they are paid to make the company profitable, and if they fail to do so they may not continue to be employed. I'm not sure why this is controversial. This requires no profit sharing to be in place, because it is simply the job that is required of the employee. It is probably by far the most general description of a job that is not: "the thing you do for money".
It may very well appear that the employee has no direct influence on company profitability, but since this is nearly impossible to measure objectively the next best thing is to try to make sure that he or she does by listening to signals coming down the hierarchy of management. Your PO telling you to hack a thing together is such a signal, and should be listened to. You warning about a giant pile of tech debt is a signal you should send to your PO, that he/she should listen to.
This is all absolutely trivial.
The OP's scenario has a product manager telling you that what they need is for you to finish feature X quickly so the company can be profitable.
In a well-working organization, that absolutely means that you, as an engineer should look into how to do X with the least amount of effort, hush things up, and ship it. The PM is the one that has to decide into hushing or not things, you are the one to decide how.
The problem is, every single organization where the PM insists on you to hush isn't well-working. It's easier to win the lottery than it's to find exceptions here. On those problematic organizations the PM will use your results to improve their curriculum and will absolutely throw you under the bus when the hushed product behaves like a hushed product. And everybody will be happy with kicking you down.
Also, if the product has any kind of safety impact, it's not the PM's job to decide about it anymore. It's yours.
In a well-working organization, that absolutely means that you, as an engineer should look into how to do X with the least amount of effort, hush things up, and ship it. The PM is the one that has to decide into hushing or not things, you are the one to decide how.
The problem is, every single organization where the PM insists on you to hush isn't well-working. It's easier to win the lottery than it's to find exceptions here. On those problematic organizations the PM will use your results to improve their curriculum and will absolutely throw you under the bus when the hushed product behaves like a hushed product. And everybody will be happy with kicking you down.
Also, if the product has any kind of safety impact, it's not the PM's job to decide about it anymore. It's yours.
> Absolutely and categorically it is not. That is complete nonsense. Why should an employee care?
They don't have to care, they are just there to do a job. If your company values a release now more than a more stable one later, it's not on you to refuse to do that.
They don't have to care, they are just there to do a job. If your company values a release now more than a more stable one later, it's not on you to refuse to do that.
Many great products have terrible software behind them.
Please give some examples of great products created by software developers that have terrible software behind them.
Please give some examples of great products created by software developers that have terrible software behind them.
Early Facebook was written in PHP, and regardless of what you think of them as a company, just look at their market cap. WordPress has a huge userbase these days and had similar roots.
How is that terrible software? PHP isn't the new hotness, but it's everywhere, fairly easy to pick up, and reasonably fast.
> 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.
There's a third and even more common option: seniors who really could care less about either
Who do you think is more likely to be lying? The person who claims to care about the bottom line or the person who claims to care about code quality? From my experience the former is almost always a bullshitter
There's a third and even more common option: seniors who really could care less about either
Who do you think is more likely to be lying? The person who claims to care about the bottom line or the person who claims to care about code quality? From my experience the former is almost always a bullshitter
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.
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.
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
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).
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).
It applies. I did a debloated Windows 10 IoT Enterprise install for a friend (who's giving this laptop to his future wife) and iconcache in Explorer is still broken and giving me the occasional white page icon, and nt authority\system gets access denied when trying to delete %localappdata%\microsoft\windows\explorer\iconcache* while explorer is kill.
Bad forever!
Bad forever!
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."
Or Duke Ellington: "I don't need time. What I need is a deadline."
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.
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.
[0] Games like Minecraft, Stardew Valley, Terraria and online games being a minority.
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.
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.
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.
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.
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.
[deleted]
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.
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.
nah fam he is right. And he didnt google shit, its literally in the profile.
I don't see any blame assigned in the previous comment.
no it was more passive aggressive - suggesting there was blame but not actually coming out and assigning it.
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.
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.
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.
Swe should inform about consequences, and executives should inform about business priorities, but they don't have to all disagree on the way forwards.
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?
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?
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.
> 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.
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.
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.
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.
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.
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.
That said it was quite a cynical interpretation of my comment and aggressive reply, so I'll leave it with that.
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.
Or with the employer/owners? Owners and workers have a fundamentally adversarial relationship.
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.
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]
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.
"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.
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.
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".
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".
I understood that you were referring to the prisoners dilemma, but I dont understand or agree with your idea of living in a quadrant. Everyone lives with the same game theory, difference arises from individual incentives and indivdual intelligence/rationality. But ultimately everyone seeks the nash.
Donating money? Volunteering? Even donating a kidney can all categorically be understood in terms of individual gain.
Donating money? Volunteering? Even donating a kidney can all categorically be understood in terms of individual gain.
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
[0]: https://www.astralcodexten.com/p/my-left-kidney
Last i researched, donating a kidney affects your quality of life extra-ordinarily.
for eg you can't eat the same way, can't exercise/move around the same way and also you might have permanent complications from the surgery.
i MIGHT consider it for a close relative but for a stranger? that would require some real mental gymnastics.
From what I know, this isn't true. Nutritionally, the only thing you need to avoid is high-protein diets. You can exercise just fine after a 6 week recovery period.
Of course, it's impossible to predict complications. Some donors have died on the operating table. The risk of complication is very low, though.
If you have any other questions I'm happy to answer.
Sources
* https://www.livingdonorgames.org/
* https://www.kidneyregistry.org/for-donors/kidney-donation-bl...
* https://www.kidneyregistry.org/for-donors/i-want-to-learn-mo...
Of course, it's impossible to predict complications. Some donors have died on the operating table. The risk of complication is very low, though.
If you have any other questions I'm happy to answer.
Sources
* https://www.livingdonorgames.org/
* https://www.kidneyregistry.org/for-donors/kidney-donation-bl...
* https://www.kidneyregistry.org/for-donors/i-want-to-learn-mo...
yeah id rather not cut out my literal organs for some random person thousands of miles away.
come the f on u for real?
come the f on u for real?
In the US there are ~20,000 live kidney donations every year. ~200 of those are to stranger (the rest going to somebody the person knows).
There's more information about living kidney donation here: http://waitlistzero.org/living-donation/risks/
There's more information about living kidney donation here: http://waitlistzero.org/living-donation/risks/
cool story
Which part of his comment was satire exactly?
He mentioned that your job as Software Engineer is to focus on Software quality and push against on unreasonable deadlines. It is NOT your job to make sure the company is hitting its sales targets, that's the management's job.
If you think this is satire, you are in the wrong profession and frankly I'm amazed that on a website called Hacker news, people are attacking parent for this advise. Then again, perhaps not since most people here are focused on startups churning out products with unreasonable deadlines.
No wonder no one takes Software seriously if _this_ is the attitude from the self proclaimed "Engineers" themselves..
He mentioned that your job as Software Engineer is to focus on Software quality and push against on unreasonable deadlines. It is NOT your job to make sure the company is hitting its sales targets, that's the management's job.
If you think this is satire, you are in the wrong profession and frankly I'm amazed that on a website called Hacker news, people are attacking parent for this advise. Then again, perhaps not since most people here are focused on startups churning out products with unreasonable deadlines.
No wonder no one takes Software seriously if _this_ is the attitude from the self proclaimed "Engineers" themselves..
it's just written in such an over the top, office-space, Dilbert-esque, somebody's-got-a-case-of-the-Mondays style that it's hard to take seriously. Yeah, don't write absolute trash code, but also don't spend three years architecting the most beautiful, most modular code and run out of money before you ship; you ain't gonna need it. If you're programming from a place that's so far removed from customers that you don't care about sales, what are you even doing? Just writing code for the sake of writing code? If the only person you're writing code for is yourself, that's fine. this is the Internet age and there are a ton of unbelievably awesome passion projects out there,
like that engine noise one. But the rest of us are writing code for some sort of purpose which involves other people using the product that the code is being written for, and sometimes money changes hands.
There's software quality, and there's that one guy who over-engineer's everything and just loves writing frameworks and never ships actual product. Without seeing actual demands and code, it's impossible to know which of the two categories they fit into, but it reads like the latter of the two.
There's software quality, and there's that one guy who over-engineer's everything and just loves writing frameworks and never ships actual product. Without seeing actual demands and code, it's impossible to know which of the two categories they fit into, but it reads like the latter of the two.
[deleted]
[deleted]
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.
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.
> 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.
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.
> Your job is to do what the company pays you for.
The problem with this mindset is the most companies are short-sighted and when the problems inevitably start coming in it is the developers who are placed under pressure.
It is the developer being paged at 2am on a Sunday. It is the developer working overtime to get the feature out because the codebase is a giant mess. Etc.
Having a minimum quality bar is a must. The OP was suggesting a professional level of quality - not gold plating everything.
The problem with this mindset is the most companies are short-sighted and when the problems inevitably start coming in it is the developers who are placed under pressure.
It is the developer being paged at 2am on a Sunday. It is the developer working overtime to get the feature out because the codebase is a giant mess. Etc.
Having a minimum quality bar is a must. The OP was suggesting a professional level of quality - not gold plating everything.
> most companies are short-sighted
The best course if you find yourself employed by such a company is to change employers. A company that is genuinely short-sighted is dysfunctional and no amount of professionalism on your part as an individual contributor is going to fix that. Now if you could get yourself promoted to management, then maybe you could have an impact--but then you wouldn't be doing actual software engineering any more, you'd be doing corporate management fixing, which is a different job.
> and when the problems inevitably start coming in it is the developers who are placed under pressure.
Yes, this is true. And as above, if it's genuinely dysfunctional, your best course, unless you are willing and able to become a manager yourself, is to change employers.
> Having a minimum quality bar is a must. The OP was suggesting a professional level of quality - not gold plating everything.
That's not what "write great software" means to me. "Great" is not the same as "minimum quality bar".
The best course if you find yourself employed by such a company is to change employers. A company that is genuinely short-sighted is dysfunctional and no amount of professionalism on your part as an individual contributor is going to fix that. Now if you could get yourself promoted to management, then maybe you could have an impact--but then you wouldn't be doing actual software engineering any more, you'd be doing corporate management fixing, which is a different job.
> and when the problems inevitably start coming in it is the developers who are placed under pressure.
Yes, this is true. And as above, if it's genuinely dysfunctional, your best course, unless you are willing and able to become a manager yourself, is to change employers.
> Having a minimum quality bar is a must. The OP was suggesting a professional level of quality - not gold plating everything.
That's not what "write great software" means to me. "Great" is not the same as "minimum quality bar".
> 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?
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?
> The company pays me because of my knowledge and expertise, that is needed to create and maintain the porduct as best as possible.
Yes, but that does not always mean writing great software. Sometimes it means writing mediocre software because that's all that's needed. Sometimes it might mean writing no software at all because software isn't the best way to solve a particular problem.
You recognize this because you say there is a quality/time spectrum, and the company wants you to use your expertise to help find the optimal point on that spectrum for a particular need. But "write great software" implies that there is no such spectrum--everything you do is always at the extreme high end. You are agreeing with me that that's not the case.
Yes, but that does not always mean writing great software. Sometimes it means writing mediocre software because that's all that's needed. Sometimes it might mean writing no software at all because software isn't the best way to solve a particular problem.
You recognize this because you say there is a quality/time spectrum, and the company wants you to use your expertise to help find the optimal point on that spectrum for a particular need. But "write great software" implies that there is no such spectrum--everything you do is always at the extreme high end. You are agreeing with me that that's not the case.
> But "write great software" implies that there is no such spectrum--everything you do is always at the extreme high end. You are agreeing with me that that's not the case.
Yes I guess I just read the parent comment more charitably. Like always push for maximizing the quality as that's your job and your expertise. And sometimes when quality really matters you have to stick your neck out and push back aggressively, even if it will cost the company more than expected. That's what we learn in engineering ethics courses in school after all.
Yes I guess I just read the parent comment more charitably. Like always push for maximizing the quality as that's your job and your expertise. And sometimes when quality really matters you have to stick your neck out and push back aggressively, even if it will cost the company more than expected. That's what we learn in engineering ethics courses in school after all.
> sometimes when quality really matters you have to stick your neck out and push back aggressively
Yes, that's certainly true. But not all cases are cases where "quality really matters". In many cases you reach a point where adding more quality has rapidly diminishing returns in terms of business value--often because it takes time and effort away from other projects where quality matters a lot more. Ultimately that's the company's decision to make. And as I pointed out in another response upthread, if you genuinely believe the company is dysfunctional in this regard (and many companies are), your only real choices at that point are to try to become a manager so you can fix the company's culture, or change employers.
Yes, that's certainly true. But not all cases are cases where "quality really matters". In many cases you reach a point where adding more quality has rapidly diminishing returns in terms of business value--often because it takes time and effort away from other projects where quality matters a lot more. Ultimately that's the company's decision to make. And as I pointed out in another response upthread, if you genuinely believe the company is dysfunctional in this regard (and many companies are), your only real choices at that point are to try to become a manager so you can fix the company's culture, or change employers.
Should we not find out what the company are paying you for? They might be surprised that you think they hired to you do to be a no-man and believe a course correction is in order? :)
>No. Your job is to do what the company pays you for.
Yes and no. Ultimately, your solution will live on after you. Even if theres no way for it to backfire publicly, your coworkers and future employees have to deal with it. It can absolutely ruin your reputation and cost you future employment. Admittedly its much easier for a contractor to draw a red line, but I had done this as far back as my first full time IT job, setting boundaries with the owner of that business as to what is and is not practical and achievable.
Yes and no. Ultimately, your solution will live on after you. Even if theres no way for it to backfire publicly, your coworkers and future employees have to deal with it. It can absolutely ruin your reputation and cost you future employment. Admittedly its much easier for a contractor to draw a red line, but I had done this as far back as my first full time IT job, setting boundaries with the owner of that business as to what is and is not practical and achievable.
> It can absolutely ruin your reputation and cost you future employment.
If your solution does not meet the company's needs, yes, this is certainly true. But I never said you should do something that does not meet the company's needs. I just pointed out that meeting the company's needs, even if you add the qualifier that you are going to do that in a way that is professional and does not create unnecessary burdens for others, still does not always mean "write great software". It means finding the optimal solution for the particular problem.
> setting boundaries with the owner of that business as to what is and is not practical and achievable.
And in cases where "write great software" is not practical and achievable (and yes, there will be plenty of such cases), that would mean telling the owner that it is not practical and achievable to write great software to meet this particular requirement, and recommending a different solution. Which is what I said.
If your solution does not meet the company's needs, yes, this is certainly true. But I never said you should do something that does not meet the company's needs. I just pointed out that meeting the company's needs, even if you add the qualifier that you are going to do that in a way that is professional and does not create unnecessary burdens for others, still does not always mean "write great software". It means finding the optimal solution for the particular problem.
> setting boundaries with the owner of that business as to what is and is not practical and achievable.
And in cases where "write great software" is not practical and achievable (and yes, there will be plenty of such cases), that would mean telling the owner that it is not practical and achievable to write great software to meet this particular requirement, and recommending a different solution. Which is what I said.
> Hey I wrote that software, you know, from last years massive security breach.
Like company policies can be wrong. They are often wrong. It wont matter to your reputation that some CEO accepted the risk and asked you to ship before code review.
Like company policies can be wrong. They are often wrong. It wont matter to your reputation that some CEO accepted the risk and asked you to ship before code review.
Sort of missed the point. It’s about writing the optimal amount and standard of software.
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".
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.
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.
What do you mean by “not shipping on the choice you made to ship”? Do you have an example?
Really fascinating thoughts.
Really fascinating thoughts.
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.
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.
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.
> 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
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
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.
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.
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.
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.
> Yeah its nice to adopt the "code my problem, business not" position. It seems like the moral high ground.
What? No.
It's the economically and humanly well-balanced position. I got a wife whom I love to spend time with and I don't want to live on the computer. 8 hours is already way too much. I do what is expected of me and maybe a little more, for the rest they'll have to pay extra or give me parts of the profit.
If not, they'll get baseline performance.
It is always so mind-bendingly odd to watch people claim that you can go above and beyond as if that has zero side effects on any other aspects of your life.
What? No.
It's the economically and humanly well-balanced position. I got a wife whom I love to spend time with and I don't want to live on the computer. 8 hours is already way too much. I do what is expected of me and maybe a little more, for the rest they'll have to pay extra or give me parts of the profit.
If not, they'll get baseline performance.
It is always so mind-bendingly odd to watch people claim that you can go above and beyond as if that has zero side effects on any other aspects of your life.
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.
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.
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.
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.
[deleted]
> 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.
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.
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?
You do know that the point of a company is to make money, right?
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.
> 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.
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.
What a weird screed.
> 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.
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.
Good News: Dr Sapolsky has recently updated his intro video on depression.
it's here: https://youtu.be/fzUXcBTQXKM?si=JU-iOaP9SeFdB5qy
it's here: https://youtu.be/fzUXcBTQXKM?si=JU-iOaP9SeFdB5qy
> so I started getting suspicious if someone actually shared the video of my app with these people because they were solving literally the same problem
I once met a guy who had a good idea about an app, something that became fairly mainstream two years later. He asked me to code the app for free and we'd share revenues. When asked what his contribution would be, he offered to "run" the company and otherwise his 50% was "having the idea". I thanked him and told him that he has a head-start of 6 months, if his app hasn't hit the market by then, I'd write the thing myself.
I once met a guy who had a good idea about an app, something that became fairly mainstream two years later. He asked me to code the app for free and we'd share revenues. When asked what his contribution would be, he offered to "run" the company and otherwise his 50% was "having the idea". I thanked him and told him that he has a head-start of 6 months, if his app hasn't hit the market by then, I'd write the thing myself.
I was once involved in an indie game project. We had a middling idea for a crappy game but we were all hankering for software development experience in that field.
Of the 3 of us who set about coding it, 2 of us just sat down and started blocking the thing out. The third, pushed faulty code to the SVN, created a design document crediting the entire idea to himself, and then called a meeting telling us he is the game designer and he would sue us if we made the game elsewhere. The 2 of us actually contributing just looked at each other and dropped the whole thing. He basically played his cards face up and we got to see he was a pissant.
Later I did see someone with the same general idea on steam. Good for them honestly. If they came up with the idea separately, great. If they stole it from the loser, also great. If they managed to persevere under him they deserve some coin.
Of the 3 of us who set about coding it, 2 of us just sat down and started blocking the thing out. The third, pushed faulty code to the SVN, created a design document crediting the entire idea to himself, and then called a meeting telling us he is the game designer and he would sue us if we made the game elsewhere. The 2 of us actually contributing just looked at each other and dropped the whole thing. He basically played his cards face up and we got to see he was a pissant.
Later I did see someone with the same general idea on steam. Good for them honestly. If they came up with the idea separately, great. If they stole it from the loser, also great. If they managed to persevere under him they deserve some coin.
As someone extremely logic and programming oriented, I -wish- I'd met someone like that. I'm just not an idea guy, apparently.
If the idea was truly good so much so you believed in it, it was a heck of an offer tbh.
If the idea was truly good so much so you believed in it, it was a heck of an offer tbh.
I'll give you any one of 3 or 4 ideas right now, if you want them. They're ideas I'd develop if I had the time, energy and brainpower. I've got personal connections for you too, if you want them, people who need the product. I won't even ask 50%, heck, 5% sounds fine by me.
My experience has been that, while that is useful, it's by no means sufficient to lead to a complete and useful tool. But I'd absolutely take that deal any day of the week, from the "idea" side of the fence. Imagine if you did it 20 times - quite a nice portfolio.
My experience has been that, while that is useful, it's by no means sufficient to lead to a complete and useful tool. But I'd absolutely take that deal any day of the week, from the "idea" side of the fence. Imagine if you did it 20 times - quite a nice portfolio.
The ideas are important, but remember the idea guy also was to run the company. That's a ton of work, too.
In any event, while I appreciate the offer, I'm now too old and domesticated to work on it. I guess my comment should have said I'd have loved to met someone like that in my early 20s, when I had more free time and my brain worked better :).
In any event, while I appreciate the offer, I'm now too old and domesticated to work on it. I guess my comment should have said I'd have loved to met someone like that in my early 20s, when I had more free time and my brain worked better :).
> but remember the idea guy also was to run the company
Company of 2 where neither receives a salary.
> That's a ton of work, too.
In this case, I really, really don't think so.
Company of 2 where neither receives a salary.
> That's a ton of work, too.
In this case, I really, really don't think so.
Well, in an honest sense, that's kind of what YC's matching program does. I'm working for a company I found on there right now. It's a much different experience from job searching but it's full of people with ideas. Half or more of them are complete nonsense but any decent engineer should be able to sift the gold from the dross.
Do you have some tips for getting started on there? I poked on a few months ago, but wasn't able to make enough sense of it to get started. I think I just didn't find the right entry points?
Book meetings with people who seem interesting, don't judge a book by its cover. Fill out your profile in a pretty detailed way, you'll get better matches if you specify what you're looking for. If you're a technical person, you're going to have your choice, I gather many of the people on there are not technical.
> The ideas are important, but remember the idea guy also was to run the company. That's a ton of work, too.
Someone who thinks of themselves as “an idea guy” and that that is worth 50% is delusional to a level I wouldn’t trust them to run the company.
Someone who thinks of themselves as “an idea guy” and that that is worth 50% is delusional to a level I wouldn’t trust them to run the company.
Can I hit you up for one those in September if my current thing doesn't work out? Completely serious.
Sure thing, goes for folks reading this too.
The problem with this setup is that having the idea is only the starting point. You will need to iterate, talk to customers, improve the solution for years while you learn more about the market.
Even if the idea is truly good all the value is in the execution and acting on non obvious information from your customers. Anyone who isn’t committed to this long and uncertain process probably shouldn’t be a co-founder.
Even if the idea is truly good all the value is in the execution and acting on non obvious information from your customers. Anyone who isn’t committed to this long and uncertain process probably shouldn’t be a co-founder.
> If the idea was truly good so much so you believed in it, it was a heck of an offer tbh.
Perhaps. But in the past 15 years I've never seen such a good idea.
If one is going to take 50% I'd expect them to be a really good salesman at least.
Perhaps. But in the past 15 years I've never seen such a good idea.
If one is going to take 50% I'd expect them to be a really good salesman at least.
I mean handling sales + marketing + accounting and everything else required to run a company is worth 50% (maybe more). But of course while you were probably competent enough to "code it up", odds are he wasn't competent to "run the company".
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 tried.
In that meeting, there are times i wanted to interject to add some context, they very skillfully pulled me away from talking too much and qualifying everything.
We got our first sale. Big client, big company, very important sale.
Came out of that meeting daze because that’s when i internalized it - im worth no more than half the company. It was truly revelatory. I’m writing all the code, all the “hard” work is on me. I dont care.
Before that, i spent two years on my own project with zero traction because i didn’t even want to sell it, i just wanted to make it better. by the end i was gasping for air.
If you can find a good decent person who has a great network and a knack for sales (and is fine doing administrative work) by god, let go of your ego and give them room to cook and have faith in yourself to ship.
I spent the first half of my career deriding and diminishing the effort of salespeople. Never again.
In that meeting, there are times i wanted to interject to add some context, they very skillfully pulled me away from talking too much and qualifying everything.
We got our first sale. Big client, big company, very important sale.
Came out of that meeting daze because that’s when i internalized it - im worth no more than half the company. It was truly revelatory. I’m writing all the code, all the “hard” work is on me. I dont care.
Before that, i spent two years on my own project with zero traction because i didn’t even want to sell it, i just wanted to make it better. by the end i was gasping for air.
If you can find a good decent person who has a great network and a knack for sales (and is fine doing administrative work) by god, let go of your ego and give them room to cook and have faith in yourself to ship.
I spent the first half of my career deriding and diminishing the effort of salespeople. Never again.
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.
They chose the right words that converted to motions of neurons in your counterparty that caused action by them to give you money. Crazy.
> When you watch a great salesperson in action it’s like magic.
That, a hundred times. It's otherworldly, transcends laws of reality. That's why I dislike most salespeople I met, who don't tire of iterating how important sales are, but never come even close to what a great salesperson can deliver.
That, a hundred times. It's otherworldly, transcends laws of reality. That's why I dislike most salespeople I met, who don't tire of iterating how important sales are, but never come even close to what a great salesperson can deliver.
In my history the best sales people I've met wouldn't have me believe they were in sales at all. They are just great at relationships and solving problems for clients. You want to give them your money to solve your problem.
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.
Yes my former business partner is a rare hybrid of super competant salesperson and super competant engineer. I sometimes just enjoyed reading his contracts.
Administrative work should probably not exceed 10% of the budget, especially in a small company, where the advantage is to have less requirements in that area.
Marketing and sales, it depends on what you sell to whom. Let’s say 10-20%.
Then there’s a grey area. Obviously there needs to be a feedback loop between clients, development and business. If the business/idea guy facilitates a lot of this and is mostly responsible to maintain the relationships, then he is part of development. So another 10-20% give or take.
That 50% number seems kind of fair. Ultimately it implies that both are putting in the same time and effort.
If the business guy is getting overwhelmed, the developer guy can automate things, talk to clients, write pretty documents for clients or take on some admin tasks.
If the developer guy is overwhelmed then the business guy can simplify requirements negotiate deadlines, do manual testing and feedback, organize tasks and so on.
What I‘m trying to say is that 50% might be more of a social contract rather than an a priori, objective assessment of value.
Marketing and sales, it depends on what you sell to whom. Let’s say 10-20%.
Then there’s a grey area. Obviously there needs to be a feedback loop between clients, development and business. If the business/idea guy facilitates a lot of this and is mostly responsible to maintain the relationships, then he is part of development. So another 10-20% give or take.
That 50% number seems kind of fair. Ultimately it implies that both are putting in the same time and effort.
If the business guy is getting overwhelmed, the developer guy can automate things, talk to clients, write pretty documents for clients or take on some admin tasks.
If the developer guy is overwhelmed then the business guy can simplify requirements negotiate deadlines, do manual testing and feedback, organize tasks and so on.
What I‘m trying to say is that 50% might be more of a social contract rather than an a priori, objective assessment of value.
I second your analysis, that's how things normally work. It's just that in these and similar scenarios, there isn't much product development happening before the MVP, so the developer fronts all the work and the risk.
> odds are he wasn't competent to "run the company"
A 2 people company where neither gets paid and "product development" consists of me coding the MPV, fronting all the work and the risk.
A 2 people company where neither gets paid and "product development" consists of me coding the MPV, fronting all the work and the risk.
Not sure if it’s smart to do that if you aren’t entirely sure about what mental state a person could be in.
Edit: okay I don’t know why I’m getting downvoted for this but if you think you can just tell someone you’re going to steal their awesome idea in 6 months you better hope their not the type of “crazy” entrepreneur who will cause problems for you or in extreme cases even end up shooting you in the back of the head.
Edit: okay I don’t know why I’m getting downvoted for this but if you think you can just tell someone you’re going to steal their awesome idea in 6 months you better hope their not the type of “crazy” entrepreneur who will cause problems for you or in extreme cases even end up shooting you in the back of the head.
You never know when you're going to get hit by a car either. Or a meteorite.
It's a tempting trap to make decisions - or even worse, paralyze decisions - around the rare outcomes, rather than the common ones.
It's a tempting trap to make decisions - or even worse, paralyze decisions - around the rare outcomes, rather than the common ones.
> okay I don’t know why I’m getting downvoted
Because saying "don't do something because an irrational player might irrationally punish you for that" isn't particularly insightful. To expand on your argument, I could find out your real identity (this is hacker news, so I might be a hacker) and pay you a visit (I won't, I'm too lazy & incompetent for that). Just saying that your argument doesn't make sense to me.
> you’re going to steal their awesome idea
I paid for it by listening to a bad sales pitch, that's 40 minutes of my life I'm never getting back. Also, there was no confidentiality or non-compete agreement.
> end up shooting you in the back of the head
Only a semi-related tangent, I live in Europe, people here usually don't carry guns which shifts the entire risk/reward calculation significantly.
Because saying "don't do something because an irrational player might irrationally punish you for that" isn't particularly insightful. To expand on your argument, I could find out your real identity (this is hacker news, so I might be a hacker) and pay you a visit (I won't, I'm too lazy & incompetent for that). Just saying that your argument doesn't make sense to me.
> you’re going to steal their awesome idea
I paid for it by listening to a bad sales pitch, that's 40 minutes of my life I'm never getting back. Also, there was no confidentiality or non-compete agreement.
> end up shooting you in the back of the head
Only a semi-related tangent, I live in Europe, people here usually don't carry guns which shifts the entire risk/reward calculation significantly.
[deleted]
I wish someone would solve my problem for me. I'm working on the problem because there are no solutions that I can just go and buy. Someone else putting their blood, sweat, and tears into solving my problem, they're the ones who have to deal with being on-call for it, they're the ones who have to maintain it, would be a joy.
Why is it so important for you to be the one to solve this problem? Why is it so important for your solution to the problem to be a business? Running a business is about creating value for yourself and for your customer - if you're obsessed about the problem, be thankful that someone else is putting so much effort into solving it; if you're obsessed about the customer, then you would've shipped something to the customer a long time ago to get feedback.
Why is it so important for you to be the one to solve this problem? Why is it so important for your solution to the problem to be a business? Running a business is about creating value for yourself and for your customer - if you're obsessed about the problem, be thankful that someone else is putting so much effort into solving it; if you're obsessed about the customer, then you would've shipped something to the customer a long time ago to get feedback.
I guess some solo dev engineers hope to implement a novel idea, curate the implementation into a somewhat successful business (have a firm grip on the market) and then sell it all off to a bigger fish and make bank.
I don't think many people actually want to run a business (long term), but most of us wouldn't mind suddenly being paid a good chunk of money for having solved or worked on an interesting problem.
I don't think many people actually want to run a business (long term), but most of us wouldn't mind suddenly being paid a good chunk of money for having solved or worked on an interesting problem.
in my case, I would never sell Benji to anyone else because my life literally depends on it. The business part is hard tho.
author here: for me it was important because after a while the app I was using was stale and wasn't shipping updates anymore. Also, as I was learning more about productivity, I reached the limits of the app. I wanted more features and I was coming up with tons of ideas that I could implement into my app, and other devs wouldn't care about implementing these ideas. I wanted control. So I finally shipped Benji (https://benji.so)
Author here! I need to update this article. Years later, I actually got motivated by the comments on HN (whenever this gets posted). P
People are always like "why don't you just ship your app?" ... so I did!
I'm happy I went through with and it's way WAY better than any competitor in this category
Check it out at https://benji.so (landing page is still w.i.p)
People are always like "why don't you just ship your app?" ... so I did!
I'm happy I went through with and it's way WAY better than any competitor in this category
Check it out at https://benji.so (landing page is still w.i.p)
The landing page lags my browser. How is that even possible - it's a splash screen with a few images. What on earth are you doing on that page.
The author complains about the bloated web and then proceeds to do the exact same thing with his landing page
Rotating an image and moving some text apparently
OK Steve.
I went through an unshipped app dev cycle that was fairly similar in many ways. Started on React, then RN, then Flutter, and eventually migrated away from graphql into sqlite.
My app had some similar aspirations -- to bridge the gap between habit motivation, goal adherence measurement, task scheduling & rescheduling. I worked on it for a few years, and my identity was very much wrapped up in eventually bootstrapping a company.
For me, the decision to let go of the project came in multiple phases, but one big closer was that I simply didn't want to be an app dev in the long run. While difficult to let go of, I currently feel good about the decision. Also, as evidenced by the resurrection part of the story, "nothing is ever fully lost" anyhow, though I doubt I'll ever return to this particular project.
One key idea I had for expanding beyond the "high cognitive load" nature of most productivity apps was to implement a "life module" marketplace of sorts that would let, say, a fitness influencer sell a workout routine + meal plan + journal template one could "install" into their life.
LLMs will also make detecting fall-off and attempting to attribute causes, or respond to "non-actions" much more feasible, which I think is important for anyone not type-A enough to use a productivity app consistently every day on their own.
My app had some similar aspirations -- to bridge the gap between habit motivation, goal adherence measurement, task scheduling & rescheduling. I worked on it for a few years, and my identity was very much wrapped up in eventually bootstrapping a company.
For me, the decision to let go of the project came in multiple phases, but one big closer was that I simply didn't want to be an app dev in the long run. While difficult to let go of, I currently feel good about the decision. Also, as evidenced by the resurrection part of the story, "nothing is ever fully lost" anyhow, though I doubt I'll ever return to this particular project.
One key idea I had for expanding beyond the "high cognitive load" nature of most productivity apps was to implement a "life module" marketplace of sorts that would let, say, a fitness influencer sell a workout routine + meal plan + journal template one could "install" into their life.
LLMs will also make detecting fall-off and attempting to attribute causes, or respond to "non-actions" much more feasible, which I think is important for anyone not type-A enough to use a productivity app consistently every day on their own.
I just tried it and the detected timezone for me is called:
"Africa/Ceuta (Romance Standard Time) (UTC+01:00) Brussels, Copenhagen, Madrid, Paris"
While the assigned delta with GMT is correct, this is confusing as hell because neither Brussels, Copenhaguen, Madrid or Paris are in Africa. You may want to take a look at the TZ info you are using.
EDIT: See comment below, this is not an issue.
"Africa/Ceuta (Romance Standard Time) (UTC+01:00) Brussels, Copenhagen, Madrid, Paris"
While the assigned delta with GMT is correct, this is confusing as hell because neither Brussels, Copenhaguen, Madrid or Paris are in Africa. You may want to take a look at the TZ info you are using.
EDIT: See comment below, this is not an issue.
But Africa/Ceuta time aligns with CE(S)T for longstanding national administrative reasons, I believe. That’s why those other cities are listed, since Africa/Ceuta time is not linked by policy, regulation or legislation with any African time zones…
Time is one of those human constructs that isn’t strongly bound to geographic or perhaps even physical reality. Look at the International Date Line or Chinese timezone maps for examples that are “bigger” than Africa/Melila and Africa/Ceuta.
We should all be glad that people are thanklessly doing the hard work to keep the TZ databases updated.
Time is one of those human constructs that isn’t strongly bound to geographic or perhaps even physical reality. Look at the International Date Line or Chinese timezone maps for examples that are “bigger” than Africa/Melila and Africa/Ceuta.
We should all be glad that people are thanklessly doing the hard work to keep the TZ databases updated.
I stand corrected, I had skipped the "Europe/Paris" and "Europe/Madrid" options that are present in the long listbox. I had assumed that someone from Paris would be confused by having to select the timezone "Africa/Ceuta".
Hi there, I can't see your white menu links on the white background, thought you'd like to know - https://i.imgur.com/Yd1hniV.png
Hi! Looks great, maybe I'll give it a try... Is it named after this guy https://en.wikipedia.org/wiki/Benji ? I was a huge fan of him (them?) when I was about 6-8 years old!
...and sorry about expressing my frustration (and suspicion) about you not mentioning the name of your "competitor"! I guess now that you have released your own app, the chances of you mentioning it are even smaller (if it's still around at all)?
...and sorry about expressing my frustration (and suspicion) about you not mentioning the name of your "competitor"! I guess now that you have released your own app, the chances of you mentioning it are even smaller (if it's still around at all)?
It's named after my dog Benji haha. Yes you're right, I'm not gonna mention any competitors, especially on a viral HN article :) There's a chance I might make a /comparison page in the future though.
I found that becoming an actual user of your own system changes the perspective entirely. I had this thing that I was making for myself, and it was not ready, not usable at all, or so I thought.
After giving up on the project I decided to try and actually started using it as if I was a user. I realised that as users, we are used to countless minor issues, and we automatically find ways around that. When you are the creator of something, you sometimes forget that a lot of sloppyness will not be a dealbreaker, and the user will effortlessly work around many of the shortcomings. Obtaining perfection is more about ego at that point.
So trying to actually use it, ignoring that you are the one who made it, and forbidding yourself to make any modifications for a while, can change everything!
After giving up on the project I decided to try and actually started using it as if I was a user. I realised that as users, we are used to countless minor issues, and we automatically find ways around that. When you are the creator of something, you sometimes forget that a lot of sloppyness will not be a dealbreaker, and the user will effortlessly work around many of the shortcomings. Obtaining perfection is more about ego at that point.
So trying to actually use it, ignoring that you are the one who made it, and forbidding yourself to make any modifications for a while, can change everything!
I think this is why ship it and iterate fast is often the best path. There will be deal breaking bugs in any software project. If your accounting package doesn’t account correctly, you probably shouldn’t just ship it. But if one of the reports displays twice for some reason, users can probably deal with it until the next iteration as long as that next iteration isn’t months to years away. But the reality is you wont even find what most of the “bugs” your users will encounter until it’s out in the wild with real users. And unless you ship it, you’ll not get to work on the bugs your users are actually impacted by.
Interesting point. An app I just used had an embedded ios web browser that didn't work properly.
I opened the web page directly and used it like that. The username/password were iCloud-synced, of course. Took me all of 5 seconds to resume the user flow in Safari (which only took another 30 seconds to finish.)
I opened the web page directly and used it like that. The username/password were iCloud-synced, of course. Took me all of 5 seconds to resume the user flow in Safari (which only took another 30 seconds to finish.)
That's a cool take, thank you!
I think it's something that I already knew in my heart, but I think by putting it like this you killed some shipping anxiety and perfectionism tendency in me. Thanks :)
I think it's something that I already knew in my heart, but I think by putting it like this you killed some shipping anxiety and perfectionism tendency in me. Thanks :)
I 100% agree with you.
Not the best example of "just ship it". The thing about these productivity apps (TODO, habit tracking, spending tracking, journaling, workout planning etc.) is that lots of people have these ideas independently. You can't imagine how clever I felt when I thought of the idea of an app that helps you keep track of your expenses. Then I checked the Play Store. KRAZAM even made fun of it the "The Hustle" video 5 years ago.
Yeah, this is probably the most overdone app category in the history of overdone app categories.
That's not to say that a new twist on it can't be successful (most successful things aren't entirely original), but if you're worrying about someone releasing their version earlier and beating you, just take a look around.
That's not to say that a new twist on it can't be successful (most successful things aren't entirely original), but if you're worrying about someone releasing their version earlier and beating you, just take a look around.
> Then I checked the Play Store
I think you missed the point of the article, which is to ship it despite competitors; in fact, competitors validate your idea, it is a good sign, not a bad one.
I think you missed the point of the article, which is to ship it despite competitors; in fact, competitors validate your idea, it is a good sign, not a bad one.
Perhaps it's just me, but I can't stand the "I'm trying so hard to be funny" writing style.
Agreed. It’s very exhausting to read. A few well timed digs are ok but you need to not overdo it.
Okay I gave up reading because it’s written by a man-baby. So cringe.
So you made a proof of concept and rested on your laurels. Too bad, that’s life. They did the work and reaped the rewards.
Lesson learnt. You can’t claim ideas
So you made a proof of concept and rested on your laurels. Too bad, that’s life. They did the work and reaped the rewards.
Lesson learnt. You can’t claim ideas
I wholeheartedly agree with this, when I started working on Kviklet we were a team of 3 and one of us was a lot more perfectionist than the others. It took a lot of convincing to even put our (tbf shitty) first website version up. Much more to release our repo.
We lost that "co-founder" early on, but man I'm glad we released early and tried to sell.
It didn't work and we found no buyers but imagine we still were working on a product without knowing if anyone would ever want to pay for it, keeping our hopes up in the dark.
By now we went with the backup plan and open sourced and have a few cool users. Could maybe even say it's a small community: https://github.com/kviklet/kviklet
It's not the startup success story that I hoped for a year ago. But it's a lot better than still hoping for it and not being a bit more grounded. Also open-source doesn't mean I can never sell support or a premium version and still make a few bucks right? For now it's just a fun side project though.
It didn't work and we found no buyers but imagine we still were working on a product without knowing if anyone would ever want to pay for it, keeping our hopes up in the dark.
By now we went with the backup plan and open sourced and have a few cool users. Could maybe even say it's a small community: https://github.com/kviklet/kviklet
It's not the startup success story that I hoped for a year ago. But it's a lot better than still hoping for it and not being a bit more grounded. Also open-source doesn't mean I can never sell support or a premium version and still make a few bucks right? For now it's just a fun side project though.
> Pull Request-like Review/Approval flow for database queries
Terrible description IMO. a query should not need approval. Should use mutation or edit or update or modification. Even if query is technically correct it just sounds wrong and confusing.
Terrible description IMO. a query should not need approval. Should use mutation or edit or update or modification. Even if query is technically correct it just sounds wrong and confusing.
I'm not quite sure what you mean. Maybe statement instead of query would be more accurate but I think people get the gist of it just fine.
Also, I disagree a manual query like: "select * from credit_cards;" should probably go through an approval flow if you have a table like that in your prod env.
Also, I disagree a manual query like: "select * from credit_cards;" should probably go through an approval flow if you have a table like that in your prod env.
A guy I used to work with said he worked for a company where all queries had to get approved by one of two full time DBAs - apparently with good reason as someone tried to modify a query that would have joined with half the rows in some gigantic table.
I worked at a place where only certain teams with a dedicated DBA were trusted to write direct queries (based on past incidents). All other teams had to ask a central DBA team to build stored procedures for any interaction with the database. If you think that this would create a huge backlog, you are correct... Non critical updates also needed to be coordinated with a "release train" where the code had to be ready 2 weeks before deployment due to the amount of testing it required. It was one of the major drivers behind an initiative to create micro services with separate databases that each team could do what they wanted with.
We ended up with a huge number of micro services and special orchestrator services to handle distributed transactions. But I guess that in a company of that scale, there are no perfect solution. At least we were able to make changes within minutes/hours instead of weeks.
Paradoxically we also got more pressure to deliver. In the past it was acceptable to leave a healthy buffer at the end of the scrum, to avoid missing the release train. This meant that we often spent the remaining buffer on refactoring, fixing small bugs that we felt we had time for or experimenting with POCs.
We ended up with a huge number of micro services and special orchestrator services to handle distributed transactions. But I guess that in a company of that scale, there are no perfect solution. At least we were able to make changes within minutes/hours instead of weeks.
Paradoxically we also got more pressure to deliver. In the past it was acceptable to leave a healthy buffer at the end of the scrum, to avoid missing the release train. This meant that we often spent the remaining buffer on refactoring, fixing small bugs that we felt we had time for or experimenting with POCs.
Yeah I guess I was too inexperienced at the time to ask how well it worked... but I guess like your experience, there would have been a fair backlog.
No, that's just what everyone calls SQL statements. It's fine.
I like this idea. It sits between "developers have access to prod" (no! bad idea!) and requiring everything to be signed in triplicate. It provides a low-friction way to make reviewable changes to prod.
I like this idea. It sits between "developers have access to prod" (no! bad idea!) and requiring everything to be signed in triplicate. It provides a low-friction way to make reviewable changes to prod.
Big difference between getting rows and changing rows
You say it's confusing, but it's exactly what I expected it to be based on the description
If I was writing something for myself, I'd not be sad that someone had beat me to it: it just proves that the idea was a good one!
Then again, none of the many personal projects I've got in my head and on paper (few of them even actually started) are ones that I would release to sell. They are things that I want or that friends/family/other might find useful. Heck, if I had something Alpha quality maybe I'd release that in the hopes someone would see it and think “this idea is useful, but the implementation is shite, I'll write a better one”.
Then again, none of the many personal projects I've got in my head and on paper (few of them even actually started) are ones that I would release to sell. They are things that I want or that friends/family/other might find useful. Heck, if I had something Alpha quality maybe I'd release that in the hopes someone would see it and think “this idea is useful, but the implementation is shite, I'll write a better one”.
> If I was writing something for myself, I'd not be sad that someone had beat me to it
The reality is that you’ve already been beaten to the punch by something in almost every situation. If you’re automating something for the first time in history then the preexisting manual method is your initial competitor. In the case of the app in the article they’re competing against that other app but also every other possible patchwork of partial solutions that their target customers are already using.
Additionally, if you are the first mover then you’ll quickly have competitors rise up and eat away at your advantage without your effort to stay ahead competitively.
So, since you’re always scooped then don’t worry about being scooped and since competition now or later is a certainty then instead focus on your competitive advantage. The author came to this realization in the end, bravo and good luck!
The reality is that you’ve already been beaten to the punch by something in almost every situation. If you’re automating something for the first time in history then the preexisting manual method is your initial competitor. In the case of the app in the article they’re competing against that other app but also every other possible patchwork of partial solutions that their target customers are already using.
Additionally, if you are the first mover then you’ll quickly have competitors rise up and eat away at your advantage without your effort to stay ahead competitively.
So, since you’re always scooped then don’t worry about being scooped and since competition now or later is a certainty then instead focus on your competitive advantage. The author came to this realization in the end, bravo and good luck!
On the other hand, there is no second try, to make a first impression. And the first impression lasts a while. So at least get some feedback before "just shipping". Otherwise reactions might be "doesn't work" - because what was obviously a start button for you making it, was not so obvious for someone just stumbling over it.
It doesn’t need to be shipped to the public. He shared videos with people, and those same people can be the first users of the MVP.
The point of an MVP is to elicit feedback, know you’re on the right track to build something useful, and iterate.
The point of an MVP is to elicit feedback, know you’re on the right track to build something useful, and iterate.
"It doesn’t need to be shipped to the public"
Ok, I took it by the usual meaning of ship it to the market. Not having people test it.
Ok, I took it by the usual meaning of ship it to the market. Not having people test it.
I think also, it’s not just “people”, but “people that you hypothesise have a problem that you’re aiming to solve”, and perhaps even “… and have money that they can and want to spend on solving it”
When I read this I was like "Oh, that sounds like my family calendar / collaborative productivty app I am working on for months ". And in the last sentence he mentions
> I wanted an app that combines Todos, Habits, Planner, Goals, Pomodoros, Meal tracking, Fasting, Hydration, Packing, Trips, and many many more features.
Surprised Pikachu face.
> I wanted an app that combines Todos, Habits, Planner, Goals, Pomodoros, Meal tracking, Fasting, Hydration, Packing, Trips, and many many more features.
Surprised Pikachu face.
Why not ship now? Well not now in 2024, but when this article was written?
Most apps and services you use were not first to market.
Most apps and services you use were not first to market.
I did! 2 years ago I launched Benji (https://benji.so) (but rewrote it from scratch this time)
Nice! Thanks for the update!
What was your purpose in developing this app? It sounds like you were trying to solve a problem you had for which there were no other good solutions. If this was the primary purpose, then it's only meant for you and not for anyone else, so why "ship it"? For personal use, shipping it simply means using it.
If you want to produce a product to sell, then yes, for the most part you want to ship as soon as you have a minimum viable product - something that at least accomplishes something valuable, even if it could be better.
But if you're working on something for fun and you consider open sourcing it, don't rush into shipping it. As soon as you release it to the public, people will start hounding you to fix bugs and add features. If you try to please them, you'll quickly find yourself working a part time job for no pay - your hobby will turn into a burden.
Releasing anything to the public - whether for profit or not - opens you up to a lot of pressure and judgement. You are making a commitment, whether you intend to or not.
Before shipping it, think carefully about whether you want to commit to supporting it. If not, then just keep it to yourself.
Giving up on a project - even one that works - isn't a bad thing. People change. Just because you wanted to work on it 6 months ago doesn't mean you want to do it now. Don't feel obligated to keep doing something you no longer enjoy. Often the important thing is that you went through the process - you learned a lot and you overcame a challenge. You can leave it at that and still be a success.
If you want to produce a product to sell, then yes, for the most part you want to ship as soon as you have a minimum viable product - something that at least accomplishes something valuable, even if it could be better.
But if you're working on something for fun and you consider open sourcing it, don't rush into shipping it. As soon as you release it to the public, people will start hounding you to fix bugs and add features. If you try to please them, you'll quickly find yourself working a part time job for no pay - your hobby will turn into a burden.
Releasing anything to the public - whether for profit or not - opens you up to a lot of pressure and judgement. You are making a commitment, whether you intend to or not.
Before shipping it, think carefully about whether you want to commit to supporting it. If not, then just keep it to yourself.
Giving up on a project - even one that works - isn't a bad thing. People change. Just because you wanted to work on it 6 months ago doesn't mean you want to do it now. Don't feel obligated to keep doing something you no longer enjoy. Often the important thing is that you went through the process - you learned a lot and you overcame a challenge. You can leave it at that and still be a success.
I am a bit snarky but it is yet another todo app.
Author is a bit high on his own supply - he thinks someone copied his great ideas where I see it as generic silly widgets. So of course he thinks it is great so much that people will love it … but just reading the thread I see the other app he was paying for stopped implementing features, because no todo app is „super great idea”.
Well good job implementing, good effort, but that’s just „yet another todo app”.
Author is a bit high on his own supply - he thinks someone copied his great ideas where I see it as generic silly widgets. So of course he thinks it is great so much that people will love it … but just reading the thread I see the other app he was paying for stopped implementing features, because no todo app is „super great idea”.
Well good job implementing, good effort, but that’s just „yet another todo app”.
Depends on your target audience.
I have a side project that's just an internal tool for my music visualizer/ lyric video generator.
It has no functional sign up for new users and is very difficult to use. It's "shipped" as in I use it for my projects.
Another is a simple web app a friend requested. He uses it occasionally. I'm sure y'all on HN could probably find half a dozen issues with it. But it's what my friend wanted and I learned a lot.
The moral of the story is use Flutter from the start, don't worry about shipping apps( do you really want to struggle with the various app stores for what's just a web app anyway), and ship early and often.
I have a side project that's just an internal tool for my music visualizer/ lyric video generator.
It has no functional sign up for new users and is very difficult to use. It's "shipped" as in I use it for my projects.
Another is a simple web app a friend requested. He uses it occasionally. I'm sure y'all on HN could probably find half a dozen issues with it. But it's what my friend wanted and I learned a lot.
The moral of the story is use Flutter from the start, don't worry about shipping apps( do you really want to struggle with the various app stores for what's just a web app anyway), and ship early and often.
I feel this deep in my bones. I worked on <some project> 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 waste their time, we can just <do the drop box thing and wire up ninety five things and make it shamble along>, definitely no need to waste time trying to implement something new from scratch.
Then I dropped it, because, hey, the glitterati of hacker news and all of the others must be right, huh? I let it wither, while working on other things, working for other people, making them wealthier, while all in the back of my mind I keep thinking: "maybe I should keep working on it."
Services doing the same exact thing started popping up. They get traction. Users are mostly happy with what they were doing, but they didn't have half of the features that I had already implemented in the code that hadn't seen any use outside of my testing environment. Some take off so well they have a now-publicly traded company doing the same thing. Ten years after I started my little project.
Fuck.
Lesson learned. The naivete of youth is a harsh teacher. Work on it. Put more effort into it. Ship it. Go with your gut--you probably have a better sense than you think you do of what will work and what won't. Ignore the hivemind. Don't leave room for the regret you will inevitably feel when you're scooped.
Then I dropped it, because, hey, the glitterati of hacker news and all of the others must be right, huh? I let it wither, while working on other things, working for other people, making them wealthier, while all in the back of my mind I keep thinking: "maybe I should keep working on it."
Services doing the same exact thing started popping up. They get traction. Users are mostly happy with what they were doing, but they didn't have half of the features that I had already implemented in the code that hadn't seen any use outside of my testing environment. Some take off so well they have a now-publicly traded company doing the same thing. Ten years after I started my little project.
Fuck.
Lesson learned. The naivete of youth is a harsh teacher. Work on it. Put more effort into it. Ship it. Go with your gut--you probably have a better sense than you think you do of what will work and what won't. Ignore the hivemind. Don't leave room for the regret you will inevitably feel when you're scooped.
Actually it is not that bad. New ideas often require a significant push so people not only get comfortable with it but also start to demand it. Having someone else bigger to do this hard work opens an actual market for it that you can now enter.
You don't need to be first or second, esp. if you're a small player. You can still win some market share over time (and it doesn't need to be small compared to what you would achieve if you would be first as the market is now bigger). Make it helpful to people who find the established solutions lacking on features or workflows that could be better.
In other words, when is it the right time to ship? With a good product, at any time. Does it matter that there are already multiple established players? Not really, you can always come up with a better version.
You don't need to be first or second, esp. if you're a small player. You can still win some market share over time (and it doesn't need to be small compared to what you would achieve if you would be first as the market is now bigger). Make it helpful to people who find the established solutions lacking on features or workflows that could be better.
In other words, when is it the right time to ship? With a good product, at any time. Does it matter that there are already multiple established players? Not really, you can always come up with a better version.
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.
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.
In my case, I was talking about technical things like data structures and IMGUI/RMGUI, which I don't think anyone feels motivated to trick others about. :)
Ah, i see, apologies I misread the concept.
I've got three separate applications all "close to finished" and I've been working on them for years (along with many other things).
Just as I'm getting real close to being finished enough to release - something changes - life changes - or some other thing changes - or I don't believe in the product any more - then I do believe in the product again - then blah blah blah. Always "legitimate" reasons - outcome always the same - haven't shipped anything in years except a bunch of open source projects.
Just as I'm getting real close to being finished enough to release - something changes - life changes - or some other thing changes - or I don't believe in the product any more - then I do believe in the product again - then blah blah blah. Always "legitimate" reasons - outcome always the same - haven't shipped anything in years except a bunch of open source projects.
Sorry to hear that. As someone who actually shipped a lot of things, i'm still going through the "I believe in it" and "don't believe in it" cycle almost daily. Don't let that stop you.
It sucks to realize that someone else beat you to a proper release. Happened in my last job, we went though the stages of grief just as the author here.
In the end you learned a lot about new technology, about your pace of development, about you thinking, about aspects you like and don't like. The lessons learned "ship it" prepares for next time.
In the end you learned a lot about new technology, about your pace of development, about you thinking, about aspects you like and don't like. The lessons learned "ship it" prepares for next time.
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 author posted a comment here about that, and that this article is about https://benji.so/ . Sounds like HN comments were persuasive in releasing the app that triggered the article.
Comment: https://news.ycombinator.com/item?id=40872817
Comment: https://news.ycombinator.com/item?id=40872817
"If you have an idea, statistically 1500 other people are also having that same idea" Execution trumps ideas. It also does not need to be fast! I have seen it go all ways at this point, and I still stand by another stupid quote, "slow and steady wins the race". The real problem lies in whether you mature your idea into something with long term value. If you ask me, fast ideas, fast execution = garbage in, garbage out.
I started mine in 2017, after I left the start up i co-founded. 2 months later, the app was. I still haven't posted a show hn.
In fact, after 2 years, someone approached me saying he is building the exact same product, but in Germany. We had several zoom calls. He shipped it, failed and iterated. I'm just watching him and hoping someday I get some time to actually do something with mine.
In fact, after 2 years, someone approached me saying he is building the exact same product, but in Germany. We had several zoom calls. He shipped it, failed and iterated. I'm just watching him and hoping someday I get some time to actually do something with mine.
Shipping 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
Its your first devops product, and how well you do that is going to affect your actual product
A few years ago I built a payment system for Google Forms as a side business (made about $3k from it before eventually turning it off to focus on other things). I'd found a problem nobody was actually solving and wanted to see if they'd be willing to pay to solve it. Like many of us I also had a bunch of partly finished projects that were never released, so I knew it could be a struggle to ship things.
What I ended up doing was writing a list of all the features that I wasn't going to work on, and all the compromises I was going to make to get something out there. Some of those compromises really hurt when I was writing them down, but didn't end up mattering enough to change them for over a year. Once I had them on the list, it gave me permission not to thing about them while I implemented the rest.
I also staged the development to avoid anything unnecessary if it flopped. For revenue, the idea was that I'd get a card on file from you, then bill it each month. But I launched the thing with no integration at all for the card on file. My plan was to give people a 14 day free trial, and if anyone actually used it in that time I'd use the time to build a card acceptance flow using Square (their API is like Stripe's). It turns out people did find and use it, and I had to extend the trial a bit, but eventually built the form. Then I had until the first of the next month to build the system to total up their bill (based on usage) and charge the card on file using the rest of Square's API.
I also didn't build anything at all for scheduling account lifecycle events. I used varmail.me (a little thing I wrote forever ago) to have my app email me when someone signed up, and check my inbox a couple times daily and send a canned welcome message to any new users. Then I'd write an email reminding me user X's trial expired, set myself as the recipient, and use Gmail scheduled messages to schedule it 14 days in the future. When I got that email I'd check if they're still using the product, send them a reminder to put in their card on file, and manually mark their account as inactive until they enter a form of payment. Billing jobs were run manually by me on my laptop for a while. Over time I got more users and it was worth the effort to replace these manual processes with automated ones. If nobody had used my product, it wouldn't have been worth the effort to automate any of this.
Testing was another thing I experimented with doing differently. At first I tested everything manually. Automating tests was difficult anyway because the key flow redirects through PayPal, and there were parts written in Google Apps Script. Eventually I built an end-to-end selenium test. Then I started adding unit tests where appropriate. Basically my principle was that I added automated tests to any area where I felt uneasy about making changes for fear of breaking something. Since I'm fairly risk-averse, the product was small, and I worked on it solo, this worked well for me.
What I ended up doing was writing a list of all the features that I wasn't going to work on, and all the compromises I was going to make to get something out there. Some of those compromises really hurt when I was writing them down, but didn't end up mattering enough to change them for over a year. Once I had them on the list, it gave me permission not to thing about them while I implemented the rest.
I also staged the development to avoid anything unnecessary if it flopped. For revenue, the idea was that I'd get a card on file from you, then bill it each month. But I launched the thing with no integration at all for the card on file. My plan was to give people a 14 day free trial, and if anyone actually used it in that time I'd use the time to build a card acceptance flow using Square (their API is like Stripe's). It turns out people did find and use it, and I had to extend the trial a bit, but eventually built the form. Then I had until the first of the next month to build the system to total up their bill (based on usage) and charge the card on file using the rest of Square's API.
I also didn't build anything at all for scheduling account lifecycle events. I used varmail.me (a little thing I wrote forever ago) to have my app email me when someone signed up, and check my inbox a couple times daily and send a canned welcome message to any new users. Then I'd write an email reminding me user X's trial expired, set myself as the recipient, and use Gmail scheduled messages to schedule it 14 days in the future. When I got that email I'd check if they're still using the product, send them a reminder to put in their card on file, and manually mark their account as inactive until they enter a form of payment. Billing jobs were run manually by me on my laptop for a while. Over time I got more users and it was worth the effort to replace these manual processes with automated ones. If nobody had used my product, it wouldn't have been worth the effort to automate any of this.
Testing was another thing I experimented with doing differently. At first I tested everything manually. Automating tests was difficult anyway because the key flow redirects through PayPal, and there were parts written in Google Apps Script. Eventually I built an end-to-end selenium test. Then I started adding unit tests where appropriate. Basically my principle was that I added automated tests to any area where I felt uneasy about making changes for fear of breaking something. Since I'm fairly risk-averse, the product was small, and I worked on it solo, this worked well for me.
Thanks for sharing! I'm going through the same thing at the moment, and it's nice to read that this pragmatic approach has worked well for you
I have a loose product idea. I guess the difference between some ideas and others is in prototyping. My prototype works. The issue is that the market for the product is like maybe 600 people global. And its not just code thats required, but plastic injection moulding, hardware manufacturing etc.
How do you know it's 600? what would be the sale price? Sometimes with a little modification, a hw product can work in multiple b2b verticals ;)
Ive done a few products myself with injection molding, production pcbs, etc. and it's amazing how different customers look at it and ask for different features.
Ive done a few products myself with injection molding, production pcbs, etc. and it's amazing how different customers look at it and ask for different features.
Super niche, combines 2-3 other products that are individually expensive and dont have any real reason to be together.
[deleted]
But what's the problem that is being solved with a productivity app ? I actually use a spreadsheet program for this and it does a better job than most apps. I don't it matters what "the vision" is really.
What do I feel like I just read an advertisement article for a productivity app?
Isn't this more a lesson of keeping your cards close to your chest?
There's a very good reason why people are on guard with pitch decks. Cause those very people you pitched could just take the idea and throw money at it.
There's a very good reason why people are on guard with pitch decks. Cause those very people you pitched could just take the idea and throw money at it.
No, almost certainly the other people didn't start the project because they saw his video and were so inspired by the idea they rushed off to build it. Almost certainly, it was a case of parallel evolution where they faced a similar problem and there are only so many parameters in the design space so they figured out a similar solution.
People who focus on ideas think their ideas are so inspirational and unique that they must be protected. In reality, anyone who has tried to go out actively and convince anyone else to build their "brilliant" idea quickly realizes the level of indifference and lack of engagement anyone else has to your baby.
People who focus on ideas think their ideas are so inspirational and unique that they must be protected. In reality, anyone who has tried to go out actively and convince anyone else to build their "brilliant" idea quickly realizes the level of indifference and lack of engagement anyone else has to your baby.
That "those guys" may have seen the video he posted was just an unsubstantiated suspicion of his though. The sad part about having brilliant ideas for apps (as I have also found out, fortunately before putting a lot of effort into the idea) is that there are millions of other developers in the world, and one of them is almost guaranteed to have had the same idea a bit earlier than you. Unless it's a super niche thing, but then the market for it is also super tiny...
After years of building in public, I'm scared that you're right. But the problem is, my app is now live (benji.so), and it's publicly out there for people with VC money to start copying features from it ...
I highly disagree. 99.99% of peoples SaaS ideas aren’t innovative.
It’s more about the people, their resources, their experience.
I’d say this is a misinformed opinion, maybe from lack of experience.
It’s more about the people, their resources, their experience.
I’d say this is a misinformed opinion, maybe from lack of experience.
There’s usually room for more than one implementation of an idea, most of the target audience haven’t committed yet?
I'm expecting to experience this any day now. I've experienced it before, seeing people make hundreds of millions of dollars on an idea I'd already built (and my employer had fumbled the marketing of) and was actively working to resurrect... but couldn't figure out how to "monetize."
Currently my problem is being a one-man band. I've realized I can't "just ship" a product that relies on a hand-rolled user-authorization scheme that I create with very little experience. So now I've interrupted my whole project to learn Supabase and oh yeah, containers... because I've never used those either and as far as I can tell I'd better use those for deployment and scalability.
And oh yeah, I had to learn SwiftUI (already knew Swift & iOS pretty well) to write the app... and also JavaScript/TypeScript and Deno for the back end. So now I'm entering year two and still trying to vacuum up knowledge fast enough to get this thing out the door before someone else announces it.
I've been thinking that I'd have to hire someone to consult on security and scaling as I finish up actual functionality. But the days go by...
Currently my problem is being a one-man band. I've realized I can't "just ship" a product that relies on a hand-rolled user-authorization scheme that I create with very little experience. So now I've interrupted my whole project to learn Supabase and oh yeah, containers... because I've never used those either and as far as I can tell I'd better use those for deployment and scalability.
And oh yeah, I had to learn SwiftUI (already knew Swift & iOS pretty well) to write the app... and also JavaScript/TypeScript and Deno for the back end. So now I'm entering year two and still trying to vacuum up knowledge fast enough to get this thing out the door before someone else announces it.
I've been thinking that I'd have to hire someone to consult on security and scaling as I finish up actual functionality. But the days go by...
> I've realized I can't "just ship" a product that relies on a hand-rolled user-authorization scheme that I create with very little experience.
Time to ship and get the experience :) It is probably not that bad as you think it is. You can also ask others if they see any obvious security/cryptography fails and you would do better than most including big companies...
> So now I've interrupted my whole project to learn Supabase and oh yeah, containers... because I've never used those either and as far as I can tell I'd better use those for deployment and scalability.
Please don't. Leave it for later if it is truly needed. You can ship without. Don't be lured to the clouds, they're too expensive and you will need to learn and change a lot.
Instead use VPSes and/or dedicated servers from cheap providers such as OVH/Hetzner. Just running your server app on a normal Linux VM is a way simpler than any cloud solution. It can also handle quite a lot, it might surprise you. And you wouldn't get insane invoices for 10-100x overpriced traffic that the clouds have and that kills many ideas even when it would make sense to do them in the cloud otherwise.
Time to ship and get the experience :) It is probably not that bad as you think it is. You can also ask others if they see any obvious security/cryptography fails and you would do better than most including big companies...
> So now I've interrupted my whole project to learn Supabase and oh yeah, containers... because I've never used those either and as far as I can tell I'd better use those for deployment and scalability.
Please don't. Leave it for later if it is truly needed. You can ship without. Don't be lured to the clouds, they're too expensive and you will need to learn and change a lot.
Instead use VPSes and/or dedicated servers from cheap providers such as OVH/Hetzner. Just running your server app on a normal Linux VM is a way simpler than any cloud solution. It can also handle quite a lot, it might surprise you. And you wouldn't get insane invoices for 10-100x overpriced traffic that the clouds have and that kills many ideas even when it would make sense to do them in the cloud otherwise.
Thanks for the advice! I did run a somewhat similar app with essentially no API security on a cheap-ass Linode VPS around 2011. But we only had 10-20K users and those extremely sporadic. But, although users controlled their content, it was totally anonymous. I didn't require a single credential, not even an E-mail address.
One thing about Supabase is that it's supposed to offer user verification through E-mail out of the box, which saves me the time of hand-rolling that.
The reason I want containers is to spin up multiple instances if the thing blows up. Isn't it easier to do that with containerized services?
One thing about Supabase is that it's supposed to offer user verification through E-mail out of the box, which saves me the time of hand-rolling that.
The reason I want containers is to spin up multiple instances if the thing blows up. Isn't it easier to do that with containerized services?
Depends on the application. I tend to have a single binary, you just need a language runtime and/or database, rarely some other software. You can script installation of this. I don't see how the containers add a value when you can do the same directly.
The last time I've tried Docker to run some application it tried to overtake my testing VM and it failed miserably. Apparently it is not compatible with chroot and it doesn't check for it so it fails somewhere in the middle with various processes and stuff left behind. Doesn't give me a good impression of such software, it lacks both an awareness of a standard feature and an inability to handle failed states gracefully.
The last time I've tried Docker to run some application it tried to overtake my testing VM and it failed miserably. Apparently it is not compatible with chroot and it doesn't check for it so it fails somewhere in the middle with various processes and stuff left behind. Doesn't give me a good impression of such software, it lacks both an awareness of a standard feature and an inability to handle failed states gracefully.
If you create a single image you're supposed to be able to spin up new instances at will, on separate VPSes or on cloud providers.
I will depend on Deno, MariaDB, and probably S3 at the least. I was able to make an image with Deno and my code on it and get it working on my machine locally pretty quickly, which was exciting.
I will depend on Deno, MariaDB, and probably S3 at the least. I was able to make an image with Deno and my code on it and get it working on my machine locally pretty quickly, which was exciting.
I hand-rolled my authn scheme in half a day (backend endpoints only; f/end HTML took a longer). In addition to sign-in with email/password combo, it also does passwordless (i.e. if a user set their profile to password-less, anytime they attempt to sign in it sends a password to their email that is valid for 15m).
It's better (i.e. more secure) than at least two currently-in-use corporate systems I have seen.
And no, I don't store plaintext passwords, and I do use a generated random salt when a password is set, and the crypto functions I use are well-regarded and well-used, not something I wrote myself.
In summary, I don't think it should take two days for a minimal authn/sign-up/sign-in implementation.
It's better (i.e. more secure) than at least two currently-in-use corporate systems I have seen.
And no, I don't store plaintext passwords, and I do use a generated random salt when a password is set, and the crypto functions I use are well-regarded and well-used, not something I wrote myself.
In summary, I don't think it should take two days for a minimal authn/sign-up/sign-in implementation.
[deleted]
an added benefit of shipping early is you get a feeling for whether people are interested, before you spend a year developing a toaster that eats its own toast.
> Even though they were working on it for the past few years it's still slow, buggy, and super unpolished, it doesn't matter, because they shipped.
> Their mobile app is terrible and it needs 10 seconds to sync. It doesn't matter, they shipped. And I'm looking forward to every single update they release.
> Their backlog of things to do is huge, but it doesn't matter, they ship every single week, and the app is growing along with the community.
Sigh. I agree, and I can empathize, but as a user I am so sick and tired of half-finished crap being shoved out the door just to beat the competition to the starting line. Every day the software we use becomes slower, more bloated, and less stable, and part of it is exactly this attitude of throwing crap at the wall and hoping it sticks. And the sad part is, since everyone is doing it, you can't really not do it, otherwise--as the author discovered--you get left in the dust.
> Their mobile app is terrible and it needs 10 seconds to sync. It doesn't matter, they shipped. And I'm looking forward to every single update they release.
> Their backlog of things to do is huge, but it doesn't matter, they ship every single week, and the app is growing along with the community.
Sigh. I agree, and I can empathize, but as a user I am so sick and tired of half-finished crap being shoved out the door just to beat the competition to the starting line. Every day the software we use becomes slower, more bloated, and less stable, and part of it is exactly this attitude of throwing crap at the wall and hoping it sticks. And the sad part is, since everyone is doing it, you can't really not do it, otherwise--as the author discovered--you get left in the dust.
I've always thought that hanging a "beta" on a logo isn't an excuse to ship junk, but as you allude to, sometimes product and service quality isn't the priority.
I'm also reminded of Dave McClure's talk [0]: "Don't do your viral marketing campaign until your product doesn't suck! Because what will happen is people will tell other people that your product sucks! ...So don't do that!"
[0] https://www.youtube.com/watch?v=irjgfW0BIrw
I'm also reminded of Dave McClure's talk [0]: "Don't do your viral marketing campaign until your product doesn't suck! Because what will happen is people will tell other people that your product sucks! ...So don't do that!"
[0] https://www.youtube.com/watch?v=irjgfW0BIrw
Yeah I so agree.
Specially post the AI boom, there's just this intrinsic itch I see of taking a product that queries chatGPT and slaps an AI label on it to make it a product.
(I'm look at you Rabbit R1).
I do understand that it does foster some air of competition and hence there's a the capitalistic push of doing better than the other person. But then, a lot of sub standard software leaks through which shifts the whole benchmark for acceptable user experience.
I do understand that it does foster some air of competition and hence there's a the capitalistic push of doing better than the other person. But then, a lot of sub standard software leaks through which shifts the whole benchmark for acceptable user experience.
Hahaha, laughed my ass off.
Can you name the largest factor to why you did not ship it? Is it fear? shyness? Thinking that you only have 1 chance with your clients?
Can you name the largest factor to why you did not ship it? Is it fear? shyness? Thinking that you only have 1 chance with your clients?
So, he's a fan (and paying subscriber) of his "competitor" app now, but still not enough of a fan to actually mention what app it is. Which is kind of frustrating, I read until the end of the post to see if it's mentioned, but it isn't. And it also leaves me with a nagging suspicion that the whole story may just be completely made up (or at least grossly exaggerated)...
It's not made up, I'm not using the competitor app for years, and I didn't want to give them more attention because this space is super competitive.
[deleted]
In order to be able to spy on someone’s phone entirely having access to their WhatsApp and seeing every incoming/outgoing calls and messages, I will recommend the service of professional hacker ( : ( TECHSPYMAX AT GM A1L C O M ) to successfully help you spy on the target’s phone just like he did for me when I was so desperate to look into my cheating spouse’s phone to find the truth.
I was lucky to come across them and they got me full access to my spouse’s phone without her knowing and I was able to monitor the phone remotely, I saw all the text messages, WhatsApp messages, social media accounts including pictures and her locations. They are legit and reliable. Relay all your problems to them and you will be assisted good. You can reach them via the MA I L provided contact information above;
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.