‘Product engineers’ vs ‘Software engineers’ in startups
dev.to
dev.to
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.
HN is flush of people who did quite well on startup equity.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
The euphet treadmill took us from programmer to developer to software "engineer" to product "engineer".
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.
Logging, auditing, anything that isnt immediately available to solve the next problem is often disregarded until "wow it would have been nice to know..."
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.
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)
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.
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.
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!
Sometimes the old school methods are better than whatever modern crap has the CEO making feature requests to engineering.
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."
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.
* 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.
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.
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.
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.
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".
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...
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.
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.
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.
PHP can be a bit of a punching bag, even when it's not topical. But it's not exactly unwarranted.
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.
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.
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.
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.
Okay, but that doesn't negate any of the criticisms about PHP nor does it suddenly wipe out decades of built up reputation.
learn your tools.
Invoking platitudes like "the right tool for the job" is irrelevant and isn't going to make that history go away suddenly.
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.
Unfixable things remain though and PHP will keep serving as a bad example in the future.
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".
It even says "(JOKING)" in the article.
You converted me. I will stop whining and go code my homepage in haskell. That should keep me busy for a year or so.
-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.
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.
But I agree that I'm not a fan of using software engineer and programmer interchangeably.
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.
Frankly that may be becoming a bit unreasonable expectation considering the international use of the title, that's what I just grew up with.
* 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
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.
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.
I’m assuming if you _join_ a startup, rather then creating or co-founding one, there’s already a product person on board.
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.
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.
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%...
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.
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
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.