Hacker News new | past | comments | ask | show | jobs | submit login
‘Product engineers’ vs ‘Software engineers’ in startups (dev.to)
140 points by fagnerbrack 28 days ago | hide | past | web | favorite | 121 comments



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.


I'm tired of the whole "if you're doing x at a startup you're foolish"

You only live once, it's amazing to be an engineer now and have all the choices of being able to actually work somewhere that you ENJOY working at, that you align with and find interesting. If that job happens to pay you $250k / year then great, but if it pays you only $150k and you actually enjoy half your waking hours then seems like you're the real winner.


But in startups that whole "work somewhere or on something you enjoy" is a front. Programming is programming, as long as you find a challenging problem. Everything else is ego.

Some of the most gratifying work I've done is on extremely tedious problems for majorly boring products. The fact that the product is boring and technical lowers the amount of drama around it, allowing you to focus on the programming you love.

The most stressful and least gratifying work I've ever done was on the multiple "sexy" and "ground breaking" products I've worked on. Those products attract snake oil salesmen and shady execs looking to make a quick buck, and who make daily life at the company a nightmare.

Another thing is the $250k/$150k numbers you give. That shows a very valley-centric view. There are parts of the US where you can work for tier 1-2 companies and where that same $150k is the equivalent of $300k in the valley.


> "work somewhere or on something you enjoy"

Definitely not true, and a generalization. I've worked at the shittiest of shitty culture game startups in the early 2010s to places that really strive to build a great culture for everyone at work, is empathetic, and cares about putting employees on a career track they care about.

Just because you haven't been at such a place doesn't mean it doesn't exist. Just because you had a bad experience doesn't mean that speaks for everyone.

At this point you can definitely work for interesting startups remotely, I've personally consulted for several in the past year on the side. They use interesting tech, have great people, and are working on interesting problems.


> Definitely not true, and a generalization... Just because you haven't been at such a place doesn't mean it doesn't exist.

That in itself is a false assumption and generalization.

Are we talking product or culture? Because, if it's culture, then startup vs. established company doesn't matter anymore. Either can have good or crap culture, and what is good/crap is wholly subjective, and usually more dependent on where the employee is in their life than the company.

For example, I could care less what amenities I have and how nice everyone is if I don't get to go home and put my kids to bed except once in a blue moon. I could care less about working from home if I'm expected to crawl out of bed in the middle of the night and work during fire drills that always seem to happen.

The question is, are you in programming primarily because you love the art, are you in it to stroke your ego, because it's bleeding edge, or a combo of both?

Startups convince low-level employees with minuscule equity that they should care as much about the company as the founders through stroking of egos. I'm not making the argument that you shouldn't work for a startup, I'm making the argument that working as a everyday software engineer at a startup is almost always a bad, long-term career investment for experienced engineers.


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.


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.


> 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.


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.


So a 'product engineer' is a 'good software engineer'? Unless you are a drone you should always ask the questions of why something needs to be done before implementing it. The engineering part of software development has to be done before you start typing on a keyboard.


The product engineer is just a software engineer with more experience is the main take away here.


So... instead of Product Engineer and Software Engineer, the titles should be Software Engineer and Programmer, respectively.


Possibly but that grade inflation boat has sailed a long time ago.


Product engineer is someone who feels superior to their peers and gives themself a new title.

The euphet treadmill took us from programmer to developer to software "engineer" to product "engineer".


You have more luck than I do since I mostly see 2 variations of this play out:

CEO: I want X....and Y, Z, and enhance A-F, all yesterday

SE: you outsourced me last month!?

PE: I can’t do anything without more specs

Or

CEO: I want X

SE, PE: 3 months later deliver X

Sales: Customer doesn’t want X, wants Y and Big Deal deadline is tomorrow

CEO: drop everything, R.I.P. out X and build Y and ship it tonight!


So a product engineer is a PM and software engineer in a single body. In an organization with actual PMs the CEO doesn’t tell this to a software engineer they tell it to a PM. The PM interviews the CEO, customer support team, and engineering team (since the spec depends on whether the real time solution is 10% or 10x more expensive than the daily digest) and produces a spec. As the engineers iterate they uncover holes in the spec which the PM fills in.

Sometimes the old school methods are better than whatever modern crap has the CEO making feature requests to engineering.


Uh... aren't you leaving out product managers? Is a "product engineer" just a glorified term to get an engineer to do two jobs at once?

CEO: "We need a search box"

Product Owner: "Okay, let me do some research and build out a design. Here are all the metrics we'll track and quantify the success of the project on"

Engineer: "Okay I've implemented your design, and put in all the essential logging to power those dashboards"

Product owner: "Great, after our search box, sales went up 7% for these items. This means $75,000 a year. Success"

CEO: "K."


> 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.

This one confused me. Shouldn't you be logging as much as possible anyway? There's going to be so many things you can't predict ahead of time with this kind of stuff.


I wouldn't build anything beyond what the server logs, which I do by default in the server config.

Having an access log and error log is sufficient, until you know what you want to query. Writing a script to do some custom query is a few minutes of work and can run over all the files created...ever. Then the person who wanted the query will just as likely realize the question they had is impossible to answer right now or doesn't want to expose the answer, or any other of a myriad of results that aren't "this adds business value".

Stop building more than you need. Get back to the work.


Yes - but people dont. You often get pushback for implementing more the than basic request, you have to defend your decision from someone who didnt think of it, so now they think it cant be good.

Logging, auditing, anything that isnt immediately available to solve the next problem is often disregarded until "wow it would have been nice to know..."


I'm in a camp of "do the minimum". The cost of adding some call to a logger to dump data into file/syslog/etc is microscopic. The cost of adding that data into BigTable and building tooling and web interface and reporting around it is probably higher than the cost of the entire project.

In my experience companies are experiencing data overload and data paralysis because they have tons of data that is absolutely useless now and will be even more useless tomorrow. And they keep adding data about the data because that's the current koolaid everyone is drinking.


I think based on your experience that's a fair line to take; I've spent a lot of time on the ops side, and seen much of "well we did nothing and we're all out of ideas AND budget"

The best answer is somewhere between these two extremes, and I like your approach of starting simple and clear - a file based approach also easily lends itself to centralizing or bootstrapping to another medium - the bigtable approach calls for a migration and potentially even a change in the guarantees made by the underlying system because someone started to repurpose it as not just an audit trail because "of course we can just query it." (ugghgghghgh)


Spreadsheets work with BigTable out of the box in the G-Suite. I love dumping stuff in BigTable for analytics so other non engineering people can easily interact with that data and run all sorts of complex and non complex queries against it with tooling which they are already know, Out-Of-The-Box! This is as cheap as it gets when it comes to building a "web interface and reporting" and the cost is zero.


Does your app handle all the errors that insert into a bigtable could trigger? Does it do retries? Does it queue messages for those retries via a separate queue manager? Does it synchronize the state of the transaction and the state of the transaction inside of the big table? If one succeeded and one failed, what do you do?

That's the extra complexity. If dumps into data lake are that important, then it becomes its own special beast that needs to be fed. If the dumps into the data lake aren't important, then the question to ask "Do I need the data lake at all or am I doing it because everyone else is doing it?" If the answer is "yes" then absolutely build that functionality. If the answer is "Eh" the question becomes much murkier.


What you describe as a Product Engineer, I call a Senior Engineer/Developer/Programmer/etc.

Your examples essentially differentiate between 1) a person who accomplishes an assigned task because it was assigned to them and 2) a person who knows that there is more to completing a task than meeting the defined requirements.


So people or companies generally look for product engineers ? For job postings I normally have not seen such role defined.


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.


There's really no consensus on what some of these job titles mean. IMO if it has "engineer" in the title, you're doing more than just writing algorithms. I'd say that in your example, Company 1 was looking for a developer or programmer, whereas the other company was looking for a software engineer or product engineer.

Also, IMO the term "Product Engineer" does not denote that it has to be software-related at all. It could be someone who designs shoes or training seminars or whatever (see https://en.wikipedia.org/wiki/Product_engineering).


Yet and still the stereotypical “software engineer” jobs at big tech companies focus on your ability to do leetCode style whiteboard coding and “reversing a binary tree”.


I think product engineer is used loosely within the software field same as product manager and product engineer. Not to be taken literally as per Wikipedia definition.


Both of these interview questions sound awful though. Are we supposed to think company 2 sounds like a good, high profile ‘product engineer’ job, rather than an indication that you will be expected to fulfill about five radically different different job roles (engineer, interviewer, project manager, mentor, customer manager, etc)?


Yes. And I loved the second job. I left my permanent position for the contract to perm position (got health benefits through my wife’s job) . Billed them an average of 60-70 hours a week, paid off some debt the first six months, negotiated a decent market pay and a title bump to put on my resume and by the time I was made perm, I had a large enough team in place and processes so I was down to a manageable 45 hours a week.

But, I made it clear at the interview that my first steps would be to build up the department, develop processes and training. They already had a barely working 20 year old PowerBuilder implementation where the various offices were forced to use Citrix terminals to access the system. They needed some tighter web and mobile integrations they couldn’t currently do.

I found out the real money was in cloud consulting. They hired a few consultants to “move us to the cloud” (a bunch of no nothing “lift and shifters”). I found out that’s where the real money was.

Left there after a year and half with a better resume, self demoted (responsibility not pay) to my current job and I’m getting a chance to fill in some resume gaps to become a more well rounded (and paid) consultant in a couple of years.


Interesting point.


Why does a product engineer go toward dinosaur tech? Moreover, what does that have to do with anything?


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.


That's exactly the kind of thing I'd expect to do in a technical position in a small company.


I'm a CTO at a 30-ish person company and yep this is my job. Lots of development, but also handling all the infrastructure and ops for a long time (I'm able to offload more to other devs these days).

I still primarily code but also do lots of long term tech strategy like cloud? and which, as well as business planning with the rest of our leadership level, hiring, training new devs, keeping all the devs up to date with new stuff, breaking down and delegating work, reviewing code, monitoring & alerting and understanding a system that's practically a living organism and being able to anticipate trouble spots rising, planning and executing what are sometimes multi-year efforts (e.g., significantly refactoring major parts of a 10+ year old code base).

Personally, I like it, though it has its difficulties. It also makes me an exceptionally valuable person for this size of company - big enough to really need breadth and depth of experience, but not in a position to have several tech people with a decade or two of experience. Find the right company (I was lucky to) and it's a golden ticket.


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.


Haven't worked in NYC but I've worked in London for 3.5 years and am in the process of leaving/going remote because I don't rate the quality of life here at all and I'm exhausted from it. Things that take its toll for me:

1. Too. Many. People. You can barely book a restaurant or get a seat anywhere. 2. Nothing works. Trains, airports and mobile network reception. 3. Commuting. Rush hour is crowded, the tubes are disgusting, getting anywhere across town takes at least an hour so you rarely want to risk trekking somewhere unless you know it will be worthwhile/you can get in. 4. Renting / moving house is super stressful. Estate agents are constantly exploiting you.

A whole bunch of my friends raved about London a few years ago which is why I came out but I don't think it is what it used to be. That being said, there is a lot of opportunity here and you can earn well if you hustle. I'd suggest you look at starting out as a contractor.

I think there are better places to live and work in tech, in other European cities like Berlin, Stockholm and Amsterdam.


Never had a problem getting a set in a restaurant in London - and Compared to NYC the Tube is heaven.

Typical Londoner complains that they have to wait up to 10 minutes for a bus - compared to the rest of the UK where you might get two busses an hour and they stop running after 6:30.


shh berlin sucks don't go there


Londoner here. I've never worked in NYC but having been there for pleasure I can tell you things like commuting will be a lot easier (possibly even cheaper? Weekly tickets will set you back 35 quid if you commute from zone 1 and 2).

My wife is American and recently quit her job with Delta (she's done both office jobs there and she's also flown as an FA). And based on her experience I can tell you you'll have a much better work life balance. This is especially if you're planning to work as a limited company contractor* as your responsibilities don't go beyond your contracted obligations.

Having said all of that, Brexit is coming up so no one is really sure what is going on.

* be careful if you do contract, if you do, read up on IR35 as that's about to shake up the contracting industry for private companies.


More typically you will be commuting from further out Zones 1 and 2 properties are SV levels of expensive - your looking at £4k to 5k year for a season ticket from an affordable area.


Disagree, you can find plenty of places in zone 2 that are fairly affordable, especially for software engineers. If you're willing to share with strangers (as is so often the case these days), it's even cheaper. Bear in mind that when you go further out, what you're saving in housing, likely just moves to a season ticket so the savings are much less, but you add additional time to your commute.


There's plenty of affordable areas in zone 2 and 3 which have average rents considerably less than SV (a 1 bed flat might be £1100-£1400/month). Annual travel within zone 3 is £1648. It's really not comparable, especially since the pound dropped 20% after the Brexit referendum.


I would imagine the original commenter moving from NYC to London isn't going to be interested in renting some tiny one bed studio flat and living on ramen.

I was talking about buying - why throw rent money away.


> I was talking about buying - why throw rent money away.

London has some of the lowest rental yields in the UK, especially as you move towards the higher end of the market. Renting is merely "very expensive", compared to buying which is "very, very expensive".


Bad use of money, certainly in the UK mortgages are cheaper per month than renting and that's not counting the value of the asset..


> UK mortgages are cheaper per month than renting

That's definitely the case outside of London where rental yields are higher but London rental yields are averaging 3-4% [1] (lower as you go up the ladder). Mortgage rates are currently a bit cheaper (1.5-3%) but owning a home also incurs additional costs such as stamp duty, repairs and (sometimes) ground-rents.

1. https://www.knightfrank.co.uk/research/uk-residential-invest...


Public transport, the London "bubble" which people get trapped in, drinking culture which I don't like, high income / high expenditure lifestyle.


I worked in London for 7 years, now in NYC for 3 years. London's definitely better for work life balance. I've managed to find a great balance here in NYC after trying hard to do that but struggle to find friends/colleagues that get it. In London you'll find plenty of talented and smart people that don't feel like working beyond 6pm is acceptable.


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.


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.


Cries in NYC with mediocre employer-provided health insurance


London is probably easier than NYC having lived in London and visited NYC.

Both are pretty... 'fast paced', for lack of a better term.

I've just moved out of London after being there for 5 years - the income required to have a decent standard of living is just getting daft, especially if you care about others around you and not just yourself.


Y this is exactly what a startup CTO does... and more!


I have a side project running on Dark, highly recommend


How do you keep motivated?


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.


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.


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.


> 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.


> 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.

Unless the software developers are paid to wax poetically about those unsavory features rather than affect whatever gets the $$ in the door to pay the software developers salaries "Lolz, lookz at PHPz stupid." is irrelevant.


Most people don't get paid to post opinions on the internet, or any kind of public forum.


Those decades of history are largely talking about a PHP that doesn't exist any more.

Yes, the language has it's warts, but if you think $language doesn't, you're just new to it.

There are many large PHP projects that generate tons of revenue. New frameworks like Laravel and Symfony 4 make whipping out MVPs that can scale pretty damn easy.


>There are many large PHP projects that generate tons of revenue.

Okay, but that doesn't negate any of the criticisms about PHP nor does it suddenly wipe out decades of built up reputation.


Every language has valid criticism, you use the right tool for the right job. When you single out one of your tools as "bad" it just highlights that you don't understand what job the tool is for.

learn your tools.


It's funny you should mention tools. This article uses exactly that analogy to explain why PHP is an awful tool for any job. https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/


Actually, hating on PHP is much older. Heck, if we are to descend into depths of history, let's go straight to the unix haters' handbook and let's find out just why the most ubiquitous and popular server operating system sucks on the most fundamental level.


You're assuming the criticisms between different languages are equatable. It's important to understand that there is a reputation and perception that PHP has because of its colored history.

Invoking platitudes like "the right tool for the job" is irrelevant and isn't going to make that history go away suddenly.


> It's important to understand that there is a reputation and perception that PHP has because of its colored history.

Because no other language has a history?

Look at C it has a coloured history, it has a reputation like any other language, C vs C++, it has bad things like the lack of memory safety, it lacks concepts like object orientation and so on and so on.

No PHP is not special in its flaws.


You almost imply as if there is a scripting or programming language that is perfect and free of any criticism or disadvantage?


Where do I do that?


The best thing about PHP is that it often serves as a good model of how not to solve technical problems. A lot of people have experience with it so taking examples from PHP resonates with them. PHP is getting worse in this regard because the current implementation fixes quite a few things.

Unfixable things remain though and PHP will keep serving as a bad example in the future.


Here's a classic article that addresses exactly your criticisms: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/


> 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

And this, ladies and gentlemen, is whom you should hire as your tech leadership. He will get your product shipped in a reasonable amount of time, rather than rewrite an app that is making you $2 million a month in Go because some new log ingestion framework wants protobufs so you can query "what are the new browser agents that we have never seen before".


That's a really big claim based on a single post that was whining into the void about someone else making a joke about a language.

It even says "(JOKING)" in the article.


It says JOKING about using php, because hurr durr php is stupid caveman language hurr durr of course you shouldn't use it. Idiot. That's dismissive, belittling and straightforward insulting. Yet of course everybody jacks off about elixir or scala or blogs running on custom assembly coded httpd. Because THAT'S smart. And php's bad and stupid. Okay, gotcha.

You converted me. I will stop whining and go code my homepage in haskell. That should keep me busy for a year or so.


This is a false equivalence. Its popularity doesn't make it "valid" for some criterion.


The amount of successful systems based on it is a valid criterion.


SAS is a valid tool as well, many colleagues in healthcare research use it. Useful sure, but that Doesn't mean STATA, R, and Python users will heal their scar tissue over using that awful software. I could calculate regressions with pencil and paper but that valid tool is just not performant.


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.


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.


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.


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.


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.


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.


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.


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.


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.


It's a horrible misnomer of a title, I agree, but here in the states it has stuck for several cascading reasons:

* there's no FE exam needed to call oneself a "software engineer"

* the MBAs doing the hiring have gone through school hearing "software engineer" and so they mentally place them alongside other engineers

* companies hiring software developers don't care to differentiate between a engineer/developer, and as a result...

* software developers (from senior level all the way down to bootcamp graduates) don't give a shit and will put "Engineer" on their resume


I concur. As much as it pains me to realize I'd lose the comfort of the title if someone pushed it.

As a for instance; I'm a high friction actor in software implementations. I dig into the requirements, question the excessive ones, point out when implementations are starting to approach the macabre, and do my best to pressure companies away from being excessively intrusive in their data gathering or use of dark UX.

I've been asked more than once just who it is I think I'm working for informally, and warned at least once via indirect threat that I'm treading on thin ice.

While I'm not technically an Iron Ringer, I've always done my best to live up to the ideal in my practice. Without a PE for Software Engineering and the regulatory framework that comes with it though, for every one of practitioners like me who push to preserve the public's interest first, there are thousands pushing without a second thought to the consequences of what they are making.

Every risk management data corpus, every shortcut taken around regulations, every expedient hack can only have a protest lodged against it, and a suggestion of an alternate implementation given before the inevitable bouncing up and ignoring of the advisement.

In this type of environment, all one can do is puck their battles carefully until more steingent regulation gives one more leverage to bring to the table.


In my part of Europe I expect software engineers to specifically have a university level engineer diploma ("diploma engineer"), and non-engineering MSc computer science graduates to go with some other title.

Frankly that may be becoming a bit unreasonable expectation considering the international use of the title, that's what I just grew up with.


> 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.


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.


True, I didn't mean to imply officially-sanctioned engineers are better than developers in all things, or that one can't be both, or that glacially slow and careful programming is the right approach in all circumstances. I just have issues with developers in companies with "move fast and break things" cultures calling what they do "engineering".


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.


Who cares.


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.


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.


>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.


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.


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".


In early stage startup, CEO usually is company's product person


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.


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.


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.


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.


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%...

[1] https://news.ycombinator.com/item?id=18227768


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?


The one with the founders who are best at selling.


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


Neither?


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-pr...


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.


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.


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


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.


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.


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.


> 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.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: