Although this may very well explain the author's major motivations and source of job satisfaction, can two categories really explain software developer job satisfaction for everyone?<p>It makes sense that someone would be more satisfied working on their own ideas than someone else's. The problems being solved are more personally relevant, and they have more control over the execution, for better or worse. The business end of things may be why proportionally few developers go this route.<p>In this article, an idea or project's success seems to be equated with its profitability and applies to business ventures in general. What about other measures of success: meeting performance and reliability requirements, being widely used, fixing some societal ill, or scratching the itch of curiosity?<p>How the idea is executed too may greatly affect job satisfaction. Many developers prefer working on greenfield projects over maintaining legacy systems. What is the pace of work like? The quality of the coworkers?<p>There are numerous variables at play.
I would put 'my own idea, miserable failure' under 'someone else's idea, huge success'.<p>And it's not all black and white. You can build a product for someone else and still have a lot of say in the product. Maybe a feeling of ownership is good enough.
"The hierarchy of satisfying jobs for me, and I suspect for legions of creative, entrepreneurial software developer everywhere looks something like this:"<p>Is this Scientific?<p>When you take into consideration, risk, stress, anxiety, loss of direct revenues, loss of freebies, loss of nice brand on your resume etc?<p>I think we all want to work on something <i>we</i> find passionate, but there's also something about working on a team of people that <i>other</i> people, i.e. <i>customers</i> find valuable.<p>Would be nice to see some data points because this is incredibly interesting.
This is a good concept for anyone who has to manage people. I don't think it only applies to a binary split between 100% ownership and none. Letting developers guide the project to some degree, instead of slogging through sprint after sprint based purely on sales team goals, will get you a happier team and hopefully higher quality product.
this is pretty close to understanding a marxist criticism of the alienation of people from the fruits of their labor under capitalism - which most people can’t opt out of