9 ms·

‘Product engineers’ vs ‘Software engineers’ in startups

140 points by fagnerbrack 7y ago

onion2k 7y ago
The author believes working as a software engineer in a startup is fine so long as you have the title "product engineer" rather than "software engineer", as if your job title actually matters.
- chrisseaton 7y ago
  This is an uncharitable reading of the article. They aren’t just suggesting a different title - they’re suggesting doing a different job - shaping the product rather than just implementing it.
  - lsaferite 7y ago
    onion2k was simply pointing out that titles are mostly rubbish. What people do is frequently quite different than their title. What the article was summing up and getting to with a little bit of a click-bait title was that when working in a startup you, as a software engineer (or whatever you prefer to be called), need to prioritize the customer and how the product solves the customers needs. Obviously the article goes into more detail.
  - onion2k 7y ago
    It's not a different job though. Everyone at a startup shapes the product. That's just what it's like working at a startup. That doesn't mean developers in startups aren't software engineers.
    - deleted 7y ago
      [deleted]
    - ljf 7y ago
      OK, not a title - a different mentality then - I've seen a lot of a lot of people in general, who just want to do what is asked, and never want to ask why or actually help change things/the product for the better.
- nbevans 7y ago
  Whoosh. He is saying you aren't seeking software engineering perfection - so forget trying to be an architecture astronaut and all that that entails. You are seeking product perfection - at any given time. And product perfection can only be judged by your customer satisfaction and business growth.
  - checktheorder 7y ago
    As a Canadian with a lot of iron rings in the family, it's always so weird to see the phrase "software engineer". It just doesn't feel like it's been earned.
    - yourapostasy 7y ago
      > It just doesn't feel like it's been earned. It hasn't. On the other hand, the gravitas of the "engineer" title has significantly eroded to business titles so much that "real engineers" are rarely seen with a seat at the table where power convenes. I don't know if this is just a local minima over the span of history, or the new normal. I hope it is the former, but I have reasons to suspect it will actually get worse. The political power haloed around the "engineer" title, and thus the capacity to affect real, lasting change within organizations, is significantly less than the various equivalent-level management titles. It has eroded to the point that it is a notable anomaly when people remark, "the company is run by engineers". In some circles like some (not all) VC, they use that phrase to damn with faint praise.
    - dagw 7y ago
      Don't they have Software Engineering as an engineering degree in Canada? But I agree that I'm not a fan of using software engineer and programmer interchangeably.
    - mikekchar 7y ago
      As a fellow Canadian I avoid the title. What's wrong with software developer? I don't do engineering, from the perspective of a P.Eng. I've only worked with one P.Eng to my knowledge and he couldn't do software engineering either (he wasn't even a particularly good software developer). I've heard of people doing things that sound like real engineering wrt software, but I've never actually met anyone who did it. I don't really travel in those circles. However, I've worked with a fair number of really good software developers, who I think have earned that title. An iron ring means nothing to me in the work that I do. I don't suppose that you meant to imply that it did, but there is often some weird idea that an engineer is better than a developer. I'm not sure where that idea came from.
- chasd00 7y ago
  i didn't read the article but in my experience a title is meaningless until head count is > 50 or so. I know people who have 5 separate business cards all with different titles, they choose which one to hand out based on the audience.
halfmatthalfcat 7y ago
But what if I want to join a startup so I can build out the stack of my dreams while accomplishing whatever business goals are set? I’m assuming if you _join_ a startup, rather then creating or co-founding one, there’s already a product person on board.
- rfeather 7y ago
  Maybe, maybe not. And if there is, they may or may not have enough bandwidth/power to really flesh out the full product vision. Part of the attraction to startups for some, myself included, is the agency that technical people can gain with respect to what they ultimately work on in an environment where anyone with an idea might get "airtime".
- stuntkite 7y ago
  You are assuming a whole lot with that one. Even when I have had product people it's very rare that they are connected with the development team and a lot of times they are stacked adversely in a team under 10 people. Bridging the product to dev and back again gap is more than a full time job. More often than that situation I've found that there just isn't a product person. I would like to know where your assumptions find startups that aren't a clusterfuck because I need to check that blog or newsgroup or whatever.
- marcinzm 7y ago
  >But what if I want to join a startup so I can build out the stack of my dreams while accomplishing whatever business goals are set? The article would argue that the startup has a higher chance of failing then since you're focusing on what you personally want rather than what the business/customers need. Startups aren't big companies, the business goals are always "get as much of this done as possible as soon as possible" rather than "we need X by Y." You can't execute on the minimum needs of the business and expect success. >I’m assuming if you _join_ a startup, rather then creating or co-founding one, there’s already a product person on board. In a traditional company the product people (ie: those who define product and how product interacts with technology) includes engineering management (CTO, VP Eng, etc.). It's not just the people with product in their titles. In a startup, however, there isn't a deep hierarchy so that job falls onto everyone in engineering.
auvi 7y ago
If everyone follows this advice then who will implement the system? Outsource to external professional firms? We already outsource to accountants, lawyers, ad agencies etc.
- 9HZZRfNlpR 7y ago
  Cheap labour and automating/using what is already out there. That's how the cycle goes, eventually writing the code will be a low paying factory job. Our industry is extremely welcome to new comers and not protecting it like doctors etc do.
  - rvz 7y ago
    > Our industry is extremely welcome to new comers and not protecting it like doctors etc do. The protecting nature of professions that involve impacting the life of an individual such as the healthcare, aviation, transportation etc is indeed justified. I would need very strong qualified AND certified candidates if the requirement was to write safety-critical software that ensures the safety of humans or animals; especially in self-driving vehicles. Startups in the tech industry can easily undo mistakes or revert it, along side bootcamps training up anyone to make a career-change into the profession. Doctors cannot afford to make mistakes that risks danger to life. Thus, they require years of training/studying in medcial school to become fully qualified. So yes, eventually eveyone (including doctors, lawyers, etc) will have the perk of being able to write code and will assist in the automation of their jobs, but not exactly absorbing or replacing their skills.
mothsonasloth 7y ago
I worked at a startup as the first Dev, it was a shock for me having to now consider things like: * What company laptops to buy? * Assess the merits of AWS and GCP and make a decision. * Divine an architecture that will get the product to the customers ASAP but will last at least a year with growth before needing a major rethink. * Present to customers, board members and potential investors about the tech. Eventually I was coding around 60% and doing these other things around 40% of my time. I guess this would be what a CTO does, so it was a great taster for me however I did get burned out with it after a year (plus working in London was taking its toll as well). For any developer who is quite senior, I would recommend trying it. I learned a lot about myself.
- asah 7y ago
  Y this is exactly what a startup CTO does... and more!
- jermaustin1 7y ago
  What about London took its toll? I've been contemplating a switch from NYC to London. I know it will be a 30-50% pay cut, but I've been told by other's who have lived and worked in both that it is worth it for the better work/life balance.
  - mseidl 7y ago
    I'm German, but was working in the US, but gave up the higher pay to the better health care, and quality of life in Germany.
    - ChicagoBoy11 7y ago
      Cries in NYC with mediocre employer-provided health insurance
    - Dumblydorr 7y ago
      I'd be interested in a write up or blog post of what things specifically were you weighing, pros and cons and numbers. Too often I hear of European healthcare being cheaper but I never see case by case details. My experience as a healthy person in US is mixed. I rarely need things, but it is hard to navigate the complex insurance business when I do try to get things. I see many people, meanwhile, one accident or illness and it sets them back a long way financially.
meabed 7y ago
Last few years developers grew a weird attitude towards work and it's really strange. When you work for someone or with someone, you get paid to do your job that includes mainly _writing_code_ and maybe _product_decisions_ and _business_thinking_, etc.., but first don't hate doing your job! I will ask the author, If you started a business, what would you do? wouldn't you do everything you mentioned there? this one sided-view articles are not interesting views IMO.
jasode 7y ago
Fyi.... This type of advice has been given in many essays using different words. Probably the one that HN is most familiar with is "Don't Call Yourself A Programmer,"[0]. Another variation on the same theme "avoid being paid for code"[1]. tldr: try not to be just a "code monkey" but shift your perspective up the value hierarchy so you can provide business solutions. Try not to be an interchangeable and commoditized "cog in the wheel". IMO, what this essay leaves out is that many people self-select into "product manager" type roles because that's more interesting and fulfilling than coding all day long. On the other hand, other types of programmers prefer to stay "heads down" and just code instead of interfacing with customers. [0] https://hn.algolia.com/?query=don%27t%20call%20yourself%20a%20programmer https://hn.algolia.com/?query=don%27t%20call%20yourself%20a%... [1] https://news.ycombinator.com/item?id=18227768 https://news.ycombinator.com/item?id=18227768
thedancollins 7y ago
Take two software startups. StartupA hires nothing but the stereotypical "software engineer". StartupB hires nothing but the stereotypical "product engineer". Which startup will be more likely to have a future?
- onion2k 7y ago
  The one with the founders who are best at selling.
  - stuntkite 7y ago
    Selling alone can get me a couple years worth of runway but I've been in two where overselling before ops/process where at a stable velocity everything choked so bad it forced the biz to pivot (not in a fun or good way). What OP is calling a "product engineer" is a good perspective for people that don't quite get that we live in a cash ecosystem and love to write good code but a lot of people hired as product engineers haven't written any code in decades. Hiring for that title is as clear as mud. Even if I have one that'll make my day in my company I might still need a senior dev that understands this stuff but wouldn't bother calling himself a "product engineer" for fear of getting crushed by the wheel of chasing customer expectations without qualifying them. At the end of the day no matter what decisions the "product" team makes, as the "software developer" I need to make things happen and that takes leading the narrative enough that I don't get hung out to dry. Engineering predictability and its communication is the key to all success. Something that has helped me wildly has been the Microsoft book Software Requirements (3rd Ed) [0]. The system it lays out for planning, analysis, and risk mitigation is something everyone should read if they want to be more effective. It doesn't even have to be applied dogmatically. If I can respond with a common lexicon of a vision and scope with a well laid out requirements spec then there isn't an issue with product, c suite, and dev communicating and everyone making money. It still shocks me every time I'm in a new org how hard that is to pull off even with the instructions. If comms and velocity track then there's enough wind to fill the sales sails. [0] https://www.amazon.com/dp/0735679665 https://www.amazon.com/dp/0735679665
- Aeolun 7y ago
  Neither?
arpa 7y ago
Would people please stop shitting on php. It's no better nor worse than let's say, ruby. It gets shit done. It is a valid tool very widely used in the wild.
- sterileopinions 7y ago
  There are decades of history behind every criticism of PHP? Do you just want people to ignore them? PHP can be a bit of a punching bag, even when it's not topical. But it's not exactly unwarranted.
  - mobilemidget 7y ago
    You almost imply as if there is a scripting or programming language that is perfect and free of any criticism or disadvantage?
    - sterileopinions 7y ago
      Where do I do that?
  - taneq 7y ago
    A lot of the criticisms were perfectly valid security concerns (some of the old default behaviour was insecure by design). Fortunately the language has evolved a lot and is nowhere near as bad as it once was. Also a lot of the criticisms were based on PHP being an easy "beginner language" and so being used by a lot of people who had no idea what they were doing. If people have valid criticisms of modern PHP then by all means air them, but don't go ragging on the language in 2019 for problems with PHP written in 2004.
    - sterileopinions 7y ago
      > but don't go ragging on the language in 2019 for problems with PHP written in 2004. Reputations can be unfair. But there are many characteristics that many developers still find unsavory about PHP, a lot of them fundamental to the language. It's a bit silly to put a time cap on those characteristics that just aren't going to change. It's really silly to assume people are going to change their tune on a tech stack many actively choose to avoid and have no way of caring or seeing what's changed within the last 3 or so years.
dustinmoris 7y ago
Great article. Here are some examples of how you know if you have a software engineer or product engineer at your startup (real experiences from me): CEO: We need to add a product search to our website so customers can easier find the products which they like. SE: Ok - and walks off and builds a search box into website. PE: Ok - walks off and builds a search box into the website. Also logs all search queries with zero results into a big table to give the startup a better insight into products which customers want, but couldn't find. Another example... CEO: We need some real time messaging into our communication channel (Slack) when a customer order couldn't be fullfilled during packaging, so customer support can pro-actively reach out to the customer and notify them about whatever the problem was. SE: Goes away for a few days and builds a complex real time notifications API which needs to hold state about which notifications it has already sent and which not. Uses latest fanciest tech for that. PE: Starts asking critical questions. Why does it have to be real time? What time are most orders being packed? What time does customer support staff start actually working? Turns out after 10 minutes of asking the right questions that a real time messaging service is overkill if most CS staff only starts working after all the packaging is already done. A simple stateless daily report being sent once to the Slack channel is completely sufficient and does the job just as good if not better than a real time solution. PE walks off and implements this in a couple hours and has the majority of the week still free to do more impactful work. EDIT: Product engineers with a real "get shit done" mindset are invaluable not only to startups but even well established companies. They are the ones who really drive success through good communication, great understanding of the business, all the different parties and the tech which they have to their availability to find the best solution for any given problem.
- cryptozeus 7y ago
  So people or companies generally look for product engineers ? For job postings I normally have not seen such role defined.
  - scarface74 7y ago
    I can usually tell by the interview process. Three years ago I interviewed (and received offers) from two companies paying about the same. Company 1: First question was to do a merge sort on the board. Second question was to do some sql statements. Company 2: “We are starting a new greenfield project and all we have are two developers who have been writing PowerBuilder code, stored procedures, and they are just learning C#. What would be your 90 day plan to start the project”. The correct answer started with budget requirements, training requirements, hiring contractors, etc. Guess which job I took? Two years later my complete interview process around the job I took was around making processes more “cloud native” and more highly available as opposed to one I didn’t take where they asked me to write code on a board to generate a Fibonacci sequence. Short version: if they ask you to do coding whiteboard interviews instead of architectural interviews, you’re being hired as a software engineer.
5trokerac3 7y ago
I agree with the title, but disagree with the article. If you're at all an experienced software engineer, you should avoid working as a "software engineer" at a startup, because you'll most likely be worked to the bone for a pittance in equity. You're much better off either finding a VP or C-level position at a much smaller startup, or doing your own side project. At least when you're working at 3am, because the only client wants something by tomorrow, you'll know that all the net will go into your own bank account.
- lonelappde 7y ago
  There are good employers and bad employers. I hear software engineering at AAA game companies is no picnic either. HN is flush of people who did quite well on startup equity.
  - 5trokerac3 7y ago
    I've been around both industries and the main thing they survive on is convincing engineers to stay in crap conditions because of how "cool" everything is. I'm lucky enough that the game company I worked for was run by great people, but I've heard horror stories from friends that moved on. The equity piece is just percentages. If I go to a "startup" in series D and get 0.01% of the company, it better be a frickin' unicorn, because it'd have to sell for $1B for me to make $100k, at best. If I'm a cofounder and have 25% of the company, it only needs to sell for $400k for me to make the same amount. Never mind that you'd make that $100k difference within a few years, being paid market rate at an established company, and probably get to go home at 5. Now imagine what happens if you put that extra $25-30k you're making into the company's matching 401k, because they actually have one. And you get real raises instead of more stock options that may wind up worthless. And if things go sour you just go to another company, because your investments aren't based on the success of the dysfunctional company you're currently working for.
    - taurath 7y ago
      > convincing engineers to stay in crap conditions because of how "cool" everything is Games are "cool" and they certainly talk about it, but its also that this is your one shot, and there's 1000 people beating down the door to take your job who will gladly take any mount of pay. There's a lot of "life goals" tied up there.
ck425 7y ago
Shouldn't all 'software engineers' be 'product engineers'? I don't really get his point, all he's describing is what any good engineer should be doing anyway.
- explorigin 7y ago
  In short, it would be wrong to expect all software engineers to be product engineers. It takes more than code-monkey experience to foresee markets needs and develop to them. In some ways it's the difference between a mechanical engineer and an industrial engineer. One makes machines, the other optimizes processes.
  - PopeDotNinja 7y ago
    Just an FYI, saying 'code-monkey' at work can get you in trouble in some places. The sun is setting on the use of 'xxxxx-monkey'. Unintended cultural references & all that.
- OrangeMango 7y ago
  In an ideal company, yes. If that's where you currently work, consider yourself lucky. A long long time ago, I started my first job out of college and that is what was expected of us. Seeking more information and questioning decisions made by those above you were part of the job, and you were expected to do it respectfully, productively and with no doubts about your intention to find the best solution regardless of whether you thought of it or not. You even had a mentor available to help you do that (because it is not something that comes naturally to most people). In my completely unrepresentative sample data set, this is not what I see today. I see engineers that are convinced they are right and refuse any guidance from the "olds", yet they consistently focus on relatively tiny components rather than the system as a whole. They think the customer is a simple construct rather than a complex entity of multiple people/departments all with their own motivations and needs. I see managers and bosses that expect orders to be carried out without question, yet have no idea how any of the technology works or that there may be multiple ways of accomplishing something, whereby some options have complementary effects on other business functions.
Dirlewanger 7y ago
Aside from the clickbait title and the rough writing, good article. The key to excelling as a developer isn't your technical prowess, it's your soft skills, which includes understanding the business you're in and how to interface well with stakeholders in other divisions.
nateburke 7y ago
One dynamic that is not discussed explicitly here concerns junior/mid-level engineers who perhaps didn't get the offer at Google/fb the first go-around and are working at your startup as a fallback. They probably don't care about executing strongly on your startup's mission in year one as much as they care about their own careers/CVs. As they should. Things they might talk about implementing that probably won't help your new business: -distributed systems -hand-rolled ML -react -hiring dedicated QA professionals so that they can focus on coding algorithms If you say no to all of this and tell them to go write another rails view for the admin dashboard, they will simply quit. The challenge is to find the right balance between "product engineer" tasks and tasks that will show the engineer that you genuinely care about their career outside of the next BD stunt. Having some sort of secondary bottom line helps enormously with this tension, in my experience.
w8rbt 7y ago
Hire "problem solvers" who have CS degrees and pay them to solve your problems. They should have a practical bent and should accept 80% solutions (good enough). That is key to getting stuff done. Avoid non-pragmatic roles (architects) that like to talk and draw a lot, but not do anything.
josephwegner 7y ago
I read this article with a bit of hunger and nostalgia to return to my former life as a startup engineer... but I think upon further thought I'm leaning against it again. As a bit of history, I worked as an engineer at startups for most of my early career. Mostly frontend work, all SaaS businesses. I enjoyed it. I wore many hats, and got to think about the customer a lot. I didn't like always worrying about my paycheck and job security. 2 years ago I transitioned to a Platform Support Engineer at Heroku. Now I manage folks on that team. The thing I loved most about startup life was getting to be engaged in every facet of the business - my voice carried weight in technical aspects, financial aspects, support, culture, etc. I have a natural aptitude for things beyond just programming, and think often about the larger business and customer impact. It was great being able to speak up and leverage those parts of my brain. However, part of me thinks that perhaps the joy I found in being involved everywhere was that it made me feel smart. I felt like I could be an expert in every domain. But that's not really realistic, is it? Today I work in a very small domain with a limited breadth of responsibility... but I am _the_ expert on developer support. There is no one else in the organization (outside of my team, of course) that can challenge my thoughts on support, because I am the expert. Similarly, I would not dare challenge the expertise of our finance team. I know quite a bit about finance, but they blow me out of the water. They're specialized, and undeniably make better decisions than me. Is it really that much better to feel smart and make average/bad decisions based on intuition? I'm not sure. I think as far as output goes, specializing is better.
julius_set 7y ago
Great article, BUT there are no examples of what the hell a product engineer ACTUALLY does. It might be good to point out that data driven development is key. A product engineer collect insights with each feature that is created backed BY ACTUAL DATA and not armchair hypothesis
draw_down 7y ago
These kind of distinctions are silly.
soulchild37 7y ago
This is a variation of patio11’s “Don’t call yourself a programmer” article https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
purplezooey 7y ago
Some of this is OK. But I've been at companies that just "do what the customer wants in the next quarter" and nothing else. It is usually a shit show. You need to blend long term thinking with customer focus. It's very hard to get it right.

140 points by fagnerbrack 7y ago

The author believes working as a software engineer in a startup is fine so long as you have the title "product engineer" rather than "software engineer", as if your job title actually matters.

chrisseaton 7y ago
This is an uncharitable reading of the article. They aren’t just suggesting a different title - they’re suggesting doing a different job - shaping the product rather than just implementing it.
- lsaferite 7y ago
  onion2k was simply pointing out that titles are mostly rubbish. What people do is frequently quite different than their title. What the article was summing up and getting to with a little bit of a click-bait title was that when working in a startup you, as a software engineer (or whatever you prefer to be called), need to prioritize the customer and how the product solves the customers needs. Obviously the article goes into more detail.
- onion2k 7y ago
  It's not a different job though. Everyone at a startup shapes the product. That's just what it's like working at a startup. That doesn't mean developers in startups aren't software engineers.
  - deleted 7y ago
    [deleted]
  - ljf 7y ago
    OK, not a title - a different mentality then - I've seen a lot of a lot of people in general, who just want to do what is asked, and never want to ask why or actually help change things/the product for the better.
nbevans 7y ago
Whoosh. He is saying you aren't seeking software engineering perfection - so forget trying to be an architecture astronaut and all that that entails. You are seeking product perfection - at any given time. And product perfection can only be judged by your customer satisfaction and business growth.
- checktheorder 7y ago
  As a Canadian with a lot of iron rings in the family, it's always so weird to see the phrase "software engineer". It just doesn't feel like it's been earned.
  - yourapostasy 7y ago
    > It just doesn't feel like it's been earned. It hasn't. On the other hand, the gravitas of the "engineer" title has significantly eroded to business titles so much that "real engineers" are rarely seen with a seat at the table where power convenes. I don't know if this is just a local minima over the span of history, or the new normal. I hope it is the former, but I have reasons to suspect it will actually get worse. The political power haloed around the "engineer" title, and thus the capacity to affect real, lasting change within organizations, is significantly less than the various equivalent-level management titles. It has eroded to the point that it is a notable anomaly when people remark, "the company is run by engineers". In some circles like some (not all) VC, they use that phrase to damn with faint praise.
  - dagw 7y ago
    Don't they have Software Engineering as an engineering degree in Canada? But I agree that I'm not a fan of using software engineer and programmer interchangeably.
  - mikekchar 7y ago
    As a fellow Canadian I avoid the title. What's wrong with software developer? I don't do engineering, from the perspective of a P.Eng. I've only worked with one P.Eng to my knowledge and he couldn't do software engineering either (he wasn't even a particularly good software developer). I've heard of people doing things that sound like real engineering wrt software, but I've never actually met anyone who did it. I don't really travel in those circles. However, I've worked with a fair number of really good software developers, who I think have earned that title. An iron ring means nothing to me in the work that I do. I don't suppose that you meant to imply that it did, but there is often some weird idea that an engineer is better than a developer. I'm not sure where that idea came from.
chasd00 7y ago
i didn't read the article but in my experience a title is meaningless until head count is > 50 or so. I know people who have 5 separate business cards all with different titles, they choose which one to hand out based on the audience.

halfmatthalfcat 7y ago

But what if I want to join a startup so I can build out the stack of my dreams while accomplishing whatever business goals are set? I’m assuming if you _join_ a startup, rather then creating or co-founding one, there’s already a product person on board.

rfeather 7y ago
Maybe, maybe not. And if there is, they may or may not have enough bandwidth/power to really flesh out the full product vision. Part of the attraction to startups for some, myself included, is the agency that technical people can gain with respect to what they ultimately work on in an environment where anyone with an idea might get "airtime".
stuntkite 7y ago
You are assuming a whole lot with that one. Even when I have had product people it's very rare that they are connected with the development team and a lot of times they are stacked adversely in a team under 10 people. Bridging the product to dev and back again gap is more than a full time job. More often than that situation I've found that there just isn't a product person. I would like to know where your assumptions find startups that aren't a clusterfuck because I need to check that blog or newsgroup or whatever.
marcinzm 7y ago
>But what if I want to join a startup so I can build out the stack of my dreams while accomplishing whatever business goals are set? The article would argue that the startup has a higher chance of failing then since you're focusing on what you personally want rather than what the business/customers need. Startups aren't big companies, the business goals are always "get as much of this done as possible as soon as possible" rather than "we need X by Y." You can't execute on the minimum needs of the business and expect success. >I’m assuming if you _join_ a startup, rather then creating or co-founding one, there’s already a product person on board. In a traditional company the product people (ie: those who define product and how product interacts with technology) includes engineering management (CTO, VP Eng, etc.). It's not just the people with product in their titles. In a startup, however, there isn't a deep hierarchy so that job falls onto everyone in engineering.

auvi 7y ago

If everyone follows this advice then who will implement the system? Outsource to external professional firms? We already outsource to accountants, lawyers, ad agencies etc.

9HZZRfNlpR 7y ago
Cheap labour and automating/using what is already out there. That's how the cycle goes, eventually writing the code will be a low paying factory job. Our industry is extremely welcome to new comers and not protecting it like doctors etc do.
- rvz 7y ago
  > Our industry is extremely welcome to new comers and not protecting it like doctors etc do. The protecting nature of professions that involve impacting the life of an individual such as the healthcare, aviation, transportation etc is indeed justified. I would need very strong qualified AND certified candidates if the requirement was to write safety-critical software that ensures the safety of humans or animals; especially in self-driving vehicles. Startups in the tech industry can easily undo mistakes or revert it, along side bootcamps training up anyone to make a career-change into the profession. Doctors cannot afford to make mistakes that risks danger to life. Thus, they require years of training/studying in medcial school to become fully qualified. So yes, eventually eveyone (including doctors, lawyers, etc) will have the perk of being able to write code and will assist in the automation of their jobs, but not exactly absorbing or replacing their skills.

mothsonasloth 7y ago

I worked at a startup as the first Dev, it was a shock for me having to now consider things like: * What company laptops to buy? * Assess the merits of AWS and GCP and make a decision. * Divine an architecture that will get the product to the customers ASAP but will last at least a year with growth before needing a major rethink. * Present to customers, board members and potential investors about the tech. Eventually I was coding around 60% and doing these other things around 40% of my time. I guess this would be what a CTO does, so it was a great taster for me however I did get burned out with it after a year (plus working in London was taking its toll as well). For any developer who is quite senior, I would recommend trying it. I learned a lot about myself.

asah 7y ago
Y this is exactly what a startup CTO does... and more!
jermaustin1 7y ago
What about London took its toll? I've been contemplating a switch from NYC to London. I know it will be a 30-50% pay cut, but I've been told by other's who have lived and worked in both that it is worth it for the better work/life balance.
- mseidl 7y ago
  I'm German, but was working in the US, but gave up the higher pay to the better health care, and quality of life in Germany.
  - ChicagoBoy11 7y ago
    Cries in NYC with mediocre employer-provided health insurance
  - Dumblydorr 7y ago
    I'd be interested in a write up or blog post of what things specifically were you weighing, pros and cons and numbers. Too often I hear of European healthcare being cheaper but I never see case by case details. My experience as a healthy person in US is mixed. I rarely need things, but it is hard to navigate the complex insurance business when I do try to get things. I see many people, meanwhile, one accident or illness and it sets them back a long way financially.

meabed 7y ago

Last few years developers grew a weird attitude towards work and it's really strange. When you work for someone or with someone, you get paid to do your job that includes mainly _writing_code_ and maybe _product_decisions_ and _business_thinking_, etc.., but first don't hate doing your job! I will ask the author, If you started a business, what would you do? wouldn't you do everything you mentioned there? this one sided-view articles are not interesting views IMO.

jasode 7y ago

Fyi.... This type of advice has been given in many essays using different words. Probably the one that HN is most familiar with is "Don't Call Yourself A Programmer,"[0]. Another variation on the same theme "avoid being paid for code"[1]. tldr: try not to be just a "code monkey" but shift your perspective up the value hierarchy so you can provide business solutions. Try not to be an interchangeable and commoditized "cog in the wheel". IMO, what this essay leaves out is that many people self-select into "product manager" type roles because that's more interesting and fulfilling than coding all day long. On the other hand, other types of programmers prefer to stay "heads down" and just code instead of interfacing with customers. [0] https://hn.algolia.com/?query=don%27t%20call%20yourself%20a%20programmer https://hn.algolia.com/?query=don%27t%20call%20yourself%20a%... [1] https://news.ycombinator.com/item?id=18227768 https://news.ycombinator.com/item?id=18227768

thedancollins 7y ago

Take two software startups. StartupA hires nothing but the stereotypical "software engineer". StartupB hires nothing but the stereotypical "product engineer". Which startup will be more likely to have a future?

onion2k 7y ago
The one with the founders who are best at selling.
- stuntkite 7y ago
  Selling alone can get me a couple years worth of runway but I've been in two where overselling before ops/process where at a stable velocity everything choked so bad it forced the biz to pivot (not in a fun or good way). What OP is calling a "product engineer" is a good perspective for people that don't quite get that we live in a cash ecosystem and love to write good code but a lot of people hired as product engineers haven't written any code in decades. Hiring for that title is as clear as mud. Even if I have one that'll make my day in my company I might still need a senior dev that understands this stuff but wouldn't bother calling himself a "product engineer" for fear of getting crushed by the wheel of chasing customer expectations without qualifying them. At the end of the day no matter what decisions the "product" team makes, as the "software developer" I need to make things happen and that takes leading the narrative enough that I don't get hung out to dry. Engineering predictability and its communication is the key to all success. Something that has helped me wildly has been the Microsoft book Software Requirements (3rd Ed) [0]. The system it lays out for planning, analysis, and risk mitigation is something everyone should read if they want to be more effective. It doesn't even have to be applied dogmatically. If I can respond with a common lexicon of a vision and scope with a well laid out requirements spec then there isn't an issue with product, c suite, and dev communicating and everyone making money. It still shocks me every time I'm in a new org how hard that is to pull off even with the instructions. If comms and velocity track then there's enough wind to fill the sales sails. [0] https://www.amazon.com/dp/0735679665 https://www.amazon.com/dp/0735679665
Aeolun 7y ago
Neither?

arpa 7y ago

Would people please stop shitting on php. It's no better nor worse than let's say, ruby. It gets shit done. It is a valid tool very widely used in the wild.

sterileopinions 7y ago
There are decades of history behind every criticism of PHP? Do you just want people to ignore them? PHP can be a bit of a punching bag, even when it's not topical. But it's not exactly unwarranted.
- mobilemidget 7y ago
  You almost imply as if there is a scripting or programming language that is perfect and free of any criticism or disadvantage?
  - sterileopinions 7y ago
    Where do I do that?
- taneq 7y ago
  A lot of the criticisms were perfectly valid security concerns (some of the old default behaviour was insecure by design). Fortunately the language has evolved a lot and is nowhere near as bad as it once was. Also a lot of the criticisms were based on PHP being an easy "beginner language" and so being used by a lot of people who had no idea what they were doing. If people have valid criticisms of modern PHP then by all means air them, but don't go ragging on the language in 2019 for problems with PHP written in 2004.
  - sterileopinions 7y ago
    > but don't go ragging on the language in 2019 for problems with PHP written in 2004. Reputations can be unfair. But there are many characteristics that many developers still find unsavory about PHP, a lot of them fundamental to the language. It's a bit silly to put a time cap on those characteristics that just aren't going to change. It's really silly to assume people are going to change their tune on a tech stack many actively choose to avoid and have no way of caring or seeing what's changed within the last 3 or so years.

dustinmoris 7y ago

Great article. Here are some examples of how you know if you have a software engineer or product engineer at your startup (real experiences from me): CEO: We need to add a product search to our website so customers can easier find the products which they like. SE: Ok - and walks off and builds a search box into website. PE: Ok - walks off and builds a search box into the website. Also logs all search queries with zero results into a big table to give the startup a better insight into products which customers want, but couldn't find. Another example... CEO: We need some real time messaging into our communication channel (Slack) when a customer order couldn't be fullfilled during packaging, so customer support can pro-actively reach out to the customer and notify them about whatever the problem was. SE: Goes away for a few days and builds a complex real time notifications API which needs to hold state about which notifications it has already sent and which not. Uses latest fanciest tech for that. PE: Starts asking critical questions. Why does it have to be real time? What time are most orders being packed? What time does customer support staff start actually working? Turns out after 10 minutes of asking the right questions that a real time messaging service is overkill if most CS staff only starts working after all the packaging is already done. A simple stateless daily report being sent once to the Slack channel is completely sufficient and does the job just as good if not better than a real time solution. PE walks off and implements this in a couple hours and has the majority of the week still free to do more impactful work. EDIT: Product engineers with a real "get shit done" mindset are invaluable not only to startups but even well established companies. They are the ones who really drive success through good communication, great understanding of the business, all the different parties and the tech which they have to their availability to find the best solution for any given problem.

cryptozeus 7y ago
So people or companies generally look for product engineers ? For job postings I normally have not seen such role defined.
- scarface74 7y ago
  I can usually tell by the interview process. Three years ago I interviewed (and received offers) from two companies paying about the same. Company 1: First question was to do a merge sort on the board. Second question was to do some sql statements. Company 2: “We are starting a new greenfield project and all we have are two developers who have been writing PowerBuilder code, stored procedures, and they are just learning C#. What would be your 90 day plan to start the project”. The correct answer started with budget requirements, training requirements, hiring contractors, etc. Guess which job I took? Two years later my complete interview process around the job I took was around making processes more “cloud native” and more highly available as opposed to one I didn’t take where they asked me to write code on a board to generate a Fibonacci sequence. Short version: if they ask you to do coding whiteboard interviews instead of architectural interviews, you’re being hired as a software engineer.

5trokerac3 7y ago

I agree with the title, but disagree with the article. If you're at all an experienced software engineer, you should avoid working as a "software engineer" at a startup, because you'll most likely be worked to the bone for a pittance in equity. You're much better off either finding a VP or C-level position at a much smaller startup, or doing your own side project. At least when you're working at 3am, because the only client wants something by tomorrow, you'll know that all the net will go into your own bank account.

lonelappde 7y ago
There are good employers and bad employers. I hear software engineering at AAA game companies is no picnic either. HN is flush of people who did quite well on startup equity.
- 5trokerac3 7y ago
  I've been around both industries and the main thing they survive on is convincing engineers to stay in crap conditions because of how "cool" everything is. I'm lucky enough that the game company I worked for was run by great people, but I've heard horror stories from friends that moved on. The equity piece is just percentages. If I go to a "startup" in series D and get 0.01% of the company, it better be a frickin' unicorn, because it'd have to sell for $1B for me to make $100k, at best. If I'm a cofounder and have 25% of the company, it only needs to sell for $400k for me to make the same amount. Never mind that you'd make that $100k difference within a few years, being paid market rate at an established company, and probably get to go home at 5. Now imagine what happens if you put that extra $25-30k you're making into the company's matching 401k, because they actually have one. And you get real raises instead of more stock options that may wind up worthless. And if things go sour you just go to another company, because your investments aren't based on the success of the dysfunctional company you're currently working for.
  - taurath 7y ago
    > convincing engineers to stay in crap conditions because of how "cool" everything is Games are "cool" and they certainly talk about it, but its also that this is your one shot, and there's 1000 people beating down the door to take your job who will gladly take any mount of pay. There's a lot of "life goals" tied up there.

ck425 7y ago

Shouldn't all 'software engineers' be 'product engineers'? I don't really get his point, all he's describing is what any good engineer should be doing anyway.

explorigin 7y ago
In short, it would be wrong to expect all software engineers to be product engineers. It takes more than code-monkey experience to foresee markets needs and develop to them. In some ways it's the difference between a mechanical engineer and an industrial engineer. One makes machines, the other optimizes processes.
- PopeDotNinja 7y ago
  Just an FYI, saying 'code-monkey' at work can get you in trouble in some places. The sun is setting on the use of 'xxxxx-monkey'. Unintended cultural references & all that.
OrangeMango 7y ago
In an ideal company, yes. If that's where you currently work, consider yourself lucky. A long long time ago, I started my first job out of college and that is what was expected of us. Seeking more information and questioning decisions made by those above you were part of the job, and you were expected to do it respectfully, productively and with no doubts about your intention to find the best solution regardless of whether you thought of it or not. You even had a mentor available to help you do that (because it is not something that comes naturally to most people). In my completely unrepresentative sample data set, this is not what I see today. I see engineers that are convinced they are right and refuse any guidance from the "olds", yet they consistently focus on relatively tiny components rather than the system as a whole. They think the customer is a simple construct rather than a complex entity of multiple people/departments all with their own motivations and needs. I see managers and bosses that expect orders to be carried out without question, yet have no idea how any of the technology works or that there may be multiple ways of accomplishing something, whereby some options have complementary effects on other business functions.

Dirlewanger 7y ago

Aside from the clickbait title and the rough writing, good article. The key to excelling as a developer isn't your technical prowess, it's your soft skills, which includes understanding the business you're in and how to interface well with stakeholders in other divisions.

nateburke 7y ago

One dynamic that is not discussed explicitly here concerns junior/mid-level engineers who perhaps didn't get the offer at Google/fb the first go-around and are working at your startup as a fallback. They probably don't care about executing strongly on your startup's mission in year one as much as they care about their own careers/CVs. As they should. Things they might talk about implementing that probably won't help your new business: -distributed systems -hand-rolled ML -react -hiring dedicated QA professionals so that they can focus on coding algorithms If you say no to all of this and tell them to go write another rails view for the admin dashboard, they will simply quit. The challenge is to find the right balance between "product engineer" tasks and tasks that will show the engineer that you genuinely care about their career outside of the next BD stunt. Having some sort of secondary bottom line helps enormously with this tension, in my experience.

w8rbt 7y ago

Hire "problem solvers" who have CS degrees and pay them to solve your problems. They should have a practical bent and should accept 80% solutions (good enough). That is key to getting stuff done. Avoid non-pragmatic roles (architects) that like to talk and draw a lot, but not do anything.

josephwegner 7y ago

I read this article with a bit of hunger and nostalgia to return to my former life as a startup engineer... but I think upon further thought I'm leaning against it again. As a bit of history, I worked as an engineer at startups for most of my early career. Mostly frontend work, all SaaS businesses. I enjoyed it. I wore many hats, and got to think about the customer a lot. I didn't like always worrying about my paycheck and job security. 2 years ago I transitioned to a Platform Support Engineer at Heroku. Now I manage folks on that team. The thing I loved most about startup life was getting to be engaged in every facet of the business - my voice carried weight in technical aspects, financial aspects, support, culture, etc. I have a natural aptitude for things beyond just programming, and think often about the larger business and customer impact. It was great being able to speak up and leverage those parts of my brain. However, part of me thinks that perhaps the joy I found in being involved everywhere was that it made me feel smart. I felt like I could be an expert in every domain. But that's not really realistic, is it? Today I work in a very small domain with a limited breadth of responsibility... but I am _the_ expert on developer support. There is no one else in the organization (outside of my team, of course) that can challenge my thoughts on support, because I am the expert. Similarly, I would not dare challenge the expertise of our finance team. I know quite a bit about finance, but they blow me out of the water. They're specialized, and undeniably make better decisions than me. Is it really that much better to feel smart and make average/bad decisions based on intuition? I'm not sure. I think as far as output goes, specializing is better.

julius_set 7y ago

Great article, BUT there are no examples of what the hell a product engineer ACTUALLY does. It might be good to point out that data driven development is key. A product engineer collect insights with each feature that is created backed BY ACTUAL DATA and not armchair hypothesis

draw_down 7y ago

These kind of distinctions are silly.

soulchild37 7y ago

This is a variation of patio11’s “Don’t call yourself a programmer” article https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

purplezooey 7y ago

Some of this is OK. But I've been at companies that just "do what the customer wants in the next quarter" and nothing else. It is usually a shit show. You need to blend long term thinking with customer focus. It's very hard to get it right.