Hacker News new | past | comments | ask | show | jobs | submit login

This hardly comes as a surprise. How many companies, especially startups, really need to tackle tough technical challenges? On the other hand, how many companies desperately need product talents to figure out what is valuable to produce?

In addition, engineers have commoditized many technical solutions that used to be challenging in the past 15 years. Scaling used to be a tough challenge, not any more for many companies. In fact, part of my daily job is to prevent passionate engineers from reinventing wheels in the name of achieving scalability. It's not because we don't need to solve scalability problems, but because the infrastructure is good enough for most of companies. Building and operating so called "big data platform" used to be hard, not that hard any more. Building machine learning pipeline used to be hard, not that hard any more for many companies. Of course, it's still challenging to build a highly flexible and automated machine learning pipeline with full support of closed feedback loop, but many companies can get by without that level of maturity.




What's up with this usage of the word "talent"? Tech is in such acute need of humble pie I don't even know where to begin. I'm becoming disillusioned. Why is a programmer etc. a "talent", but a carpenter just an employee, hire or whatever?

But maybe it's actually an appropriate term, now when our interview processes so clearly have ceased to be job interviews, and have become auditions - because nothing less satisfies our own grandiose self-importance.

> "On the other hand, how many companies desperately need product talents to figure out what is valuable to produce?"

These middle-management positions are so unmeasurable that I think they may be greatest source of bullshit jobs in tech. So if it's true that their success is largely unmeasureable, I wonder how you've come to that conclusion?


It’s just terminology from acting. Wouldn’t read too much into it. Getting annoyed by that is like being upset you have a team in your org called HR. “Human Resources? Am I just a unit of raw material to be put through the factory?!”


> Am I just a unit of raw material to be put through the factory?!”

Yes. This one is accurate.


I prefer the term 'Human Accounting' myself.


Human Remains is one term used in the UK


"Personnel" is the older, more appropriate name.


Why did we ever change? New hip management terms?


US invented HR, and the world adopted it.


Sorry I was guilty of using slang here its meant in a negative way.


“Associates”


Interestingly HR people don’t refer to themselves as “resources”, they call themselves “professionals” or “business partners”. But at least they’re honest about how they view real workers.


I disagree. To be clear, there's more to techs current flight towards the sun than just this. But for this kind of wording to be possible there need to be certain conditions present. In techs case; partly just a general boom/bubble. If you'd post searches for "talent" without these conditions present you'd likely be laughed out of the building, or at the very least come of as dorky, bordering unreliable.


"Talent" is now used in the context of recruitment for almost any job that requires some level of skill. E.g. I heard it being used for police officers ("law enforcement talent").


I think it's about visibility of failure. When a carpenter or office worker make a mistake, it often doesn't take an expert to figure it out (and if it does, it's always a "clerical" error, not an honest mistake in a complex environment). Thus, whenever people look at these jobs, they're not seeing skilled laborers but someone whose time is simply less valuable than theirs. If only they had the time, they could have done it better - whereas programming is mysterious so they need "talent."


In NYC it takes 8 years verifiable work experience (by W-2 forms) Before you are allowed to take a Plumbing test, for your license. I guarantee that you would Not be able to trouble shoot a problem that a licensed plumber couldn't figure out.

And yes, in a past life I was a master licensed plumber.


Oh, no doubt. I didn't mean to suggest otherwise, just to present a hypothesis on why I think people perceive some jobs as requiring talent.


Fair enough.


> These middle-management positions are so unmeasurable that I think they may be greatest source of bullshit jobs in tech. So if it's true that their success is largely unmeasureable, I wonder how you've come to that conclusion?

But, product improvements shouldn't be immeasurable. Through analysis of engagement metrics, talking with users, etc. one can measure improvements. Sure, it isn't a direct measurement, but pure unmeasurable intuition is not how good PMs function


But the problem is that even if you measure an increase in KPIs you can't accurately attribute that success to the different team members and in the end the manager tends to get disproportionate credit.

It's the credit assignment problem IRL.


Except that no one actually evaluates KPIs like that. Product improvements are not KPIs that anyone gets measured on.


Because Tech is a "profession" and if you think we are you obviously haven't seen how other professions Architects for example and Journalists have a very high opinion of them selves.


Because Tech is a "profession"

If this were true, hard-won experience would be prized, as it is in law, medicine, and all real professions, instead we have rampant ageism and statements like “young people are just smarter”.


Except that Tech isn't a profession. Professions have bodies that establish and enforce professional standards and appropriate evaluations and credentials.

Programmers that call themselves "engineers" are fooling themselves. Unless they are doing the sort of programming that the NASA shuttle team used, none of us are "engineers".


Here in Uruguay if you wish to call yourself an "engineer" you need to have an accredited engineering degree.

There is a career called C.S. Engineer and it has an huge amount of math and physics (equivalent to an undergrad + master's in the U.S.). Most of us take the career that's equivalent to an undergraduate degree though, the extra math (and grueling attrition) is mostly useless.

But graduates are very sought after because they've proven themselves able to go through a tough grind (even though they don't have a shred of practical experience after graduating)


In the UK The BCS and IEEE would beg to differ. And a profession is not just the piece of paper its about social standing and relative pay rates.

And anyone with a degree who works in there field is a "engineer" even though the number that go for full Chartered status is a small minority - and that is more about who you know not what you know.


The BCS

The BCS is a complete joke, completely irrelevant to anyone working in the field, I have no idea how it still exists or what it actually does for practitioners or for the industry.


Software development is not one of the 'Professions', and never will be until it has a governing body and some degree of accountability for the shoddy work they can put out.


They do all countries have certifying bodies for engineers and admit it professionals.

I never bothered going that route as the BCS kept changing their minds on qualifying experience and the rules and actually don't do anything concreate for their members unlike say the BMA does for doctors.

So honest Q here if you feel so strongly why haven't you got your Ceng / E status


> So honest Q here if you feel so strongly why haven't you got your Ceng / E status

I don't feel strongly about it. I don't need people to call me an engineer, because I'm not an engineer and I have no intention of being one.

I'm a software developer, which is very different.


Come to the medical field, and it's all the way down.


All idealists have an high opinion of themselves.


Journalists, idealists, pick one


mainly because while we all go through the same basic CS-math foundations in HS...most never learn how to apply them...


...because the skill gap between “ok”, “good”, and “great” is so much bigger for some jobs (software development) than it is for other jobs (carpentry).


It's not tho.

It's really not. Most of the software you use every day was developed by very average software developers. The vast majority of the work software developers do isn't terribly novel or particularly difficult. And you know what? They do just fine. Things work well. Systems stay on line. Companies make money.

I've seen too many "bad" teams produce perfectly functional software over the years to think that this gap exists anywhere but in Joel Spolsky essays.

I think comparing carpenters to software engineers does a disservice to carpenters. Software developers to me are more like dry-wallers. A really good one can do it faster, but the end result mostly always looks the same.

The difference between an average and a great carpenter, however, is immediately obvious. There is real craftsmanship there, and you can clearly see the difference.

It isn't until you get to the edges of software development that those same differences become clear. When you're dealing with very high scale, very aggressive performance metrics, or very difficult mathematical concepts you see the difference between average and great developers. But those are less than a fraction of 1% of software projects I'd wager.

* I should note: I'm a software developer.


I’d argue they’re more like electricians. All their work is hidden behind the drywall, and as long as the lamp turns on, nobody has any idea of the absolute mess of wire that was used to turn on the single lamp.

If you have great developers, there will be a single straight wire from the switch to the lamp.

The end result for the user is the same though, until the mess of wire eventually overheats and burns down your house.


It really is night and day between a good dev and a bad dev.

The key factor that you're probably not thinking about is time. A good dev doesn't think faster or have blazing fingers that fly across the keyboard, a good dev is constantly setting him/herself up to shave time off of future tasks, and those investments are constantly paying dividends.

Those "bad" teams can definitely produce software that runs, but they do it 10x slower than a "good" team could.

What takes a bad team of four six months to make takes a good team of two only 5 or 6 weeks.


In my view, a good developer writes maintainable code. Easy to understand, easy to fix, no spaghetti.


Yes, but what's the point of maintainable code? Speed. Quickly understandable, quickly fixable, and quickly upgradable.

Time is the key. Writing maintainable code is the investment a good developer makes because it pays off by increasing speed of interacting with that code.


A more accurate comparison is that software devs are like general contractors. I’m referring to those contractors who have experience doing plumbing, drywall, framing, finish work, etc but learned where to sub out to be more efficient for both their profit and to save customers time and money. A bad contractor can make a remodel a complete nightmare.

I should note that I’m a software dev and a family member is a general contractor


I respectfully disagree, having worked in both software and carpentry.

While I do feel that folks grossly underestimate the skills that the best carpenters acquire over time, the software ecosystem generally is unique is that it's vastly large and complex. By any measure (switch points, surface area, person-years, etc.), the software we've all built in the past 70-ish years is the most complex thing ever implemented by human-kind.

Long ago it became far too large for any one person to "master" to the same degree an excellent carpenter might master his or her skills.

And the market agrees with the point of view, and values the economic output of the "best" software developers (at scale, not just one data point) at a far greater multiple over the "ok" ones, relative to other skills and trades.

One may not like this analysis (and my associated statement), but it is the state of the world.


I think most people are not able to tell the difference between a great piece of software and an average one.

For example, the people at Apple who came with blocks and Grand Central Dispatch did an amazing job, but the difference between them and the average software developer is like 100x. A great software developer can write something that other developers can build on, which makes them more productive.

Conversely, the people who came up with Java, they figured out how to turn a great programmer into an average one, and make them want to quit computers altogether, but the below average programmers are now also average.


The statistics I've seen say 60% of all software projects fail. My experience, anecdotal as it is, bears that out.

Projects that don't fail, usually have to be rescued from some crazy doomed plans fairly regularly.

You seem to have found a calmer, saner corner of the industry.


They probably failed due to bad product management.


I think 60% is an underestimate!


Just because you cant distinguish the fine differences between a good and great carpenter doesn't mean they don't exist. Someone making detailed engravings for a casket is far more skilled than someone who hammers a wooden crate.

Any profession to which someone can devote their life to (incl. carpentry or software development) is going to have gaps in skills between "ok", "good", and "great". Pejorative attitudes which measure something like software development as "harder" than carpentry are not beneficial and simply dilute the discourse.


As someone who has worked in carpentry, and as a software engineer for 10 years now, I completely disagree. I actually see the skill gap between ok, good, and great as being really similar in carpentry and software. A junior carpenter will make a lot of mistakes.

Especially as many software devs are becoming more like "code plumbers," if anything the skill gap may be bigger in carpentry in the future.


You would be surprised how hard is and how many years takes to be a good cabinetmaker.


Whoa buddy. There's a huge difference in skills there.


Waves hand, "We can always throw some more engineers at that part of the problem, what's really hard is figuring out what to do", said the project manager, and the product manager, and the QA manager, and the manager-manager. Meanwhile, talking heads in also ran companies in Silicon Valley continued to sell off stock in the mantra, "Innovation is 1% inspiration and 99% perspiration".


Pournelle's Iron Law of Bureaucracy states that in any bureaucratic organization there will be two kinds of people":

First, there will be those who are devoted to the goals of the organization. Examples are dedicated classroom teachers in an educational bureaucracy, many of the engineers and launch technicians and scientists at NASA, even some agricultural scientists and advisors in the former Soviet Union collective farming administration.

Secondly, there will be those dedicated to the organization itself. Examples are many of the administrators in the education system, many professors of education, many teachers union officials, much of the NASA headquarters staff, etc.

The Iron Law states that in every case the second group will gain and keep control of the organization. It will write the rules, and control promotions within the organization.

https://www.jerrypournelle.com/reports/jerryp/iron.html


Personally, I wouldn't go that far, I've found a decent number of managers to be value-adding. I think it is more about the sloppy mindset that tends to underplay the contribution of other producers on a team, to instead heavily over-value their own contributions. Engineers can go too far in this way too, of course. Managers can produce strategy, operational efficiency, organizational support for ill-understood projects, elevate performers, eliminate underperformers etc.


That doesn't contradict Pournelle's observation. The balance of power tends towards those who work for the organization in most firms.

The bigger question in my mind: why firms at all? If individual PMs are so great, why bother with employees? Wouldn't you rather just contract all the elements of a technical project to other folks for a fixed fee?

I do wonder what portion of good ol' boys and good ol' fashion nepotism tend to fill out the "PM" position on big firm's org charts.


There's a ~long history of people attempting to answer that question: https://en.wikipedia.org/wiki/Theory_of_the_firm

From the article, "Firms exist as an alternative system to the market-price mechanism when it is more efficient to produce in a non-market environment."


If that "theory of the firm" is true, then engineering is much less commoditized than stated by the top-level commenter.


I believe that was the evidence provided by the great outsourcing experiment of 1996-2006. Turns out programming can't easily be turned into a low-skill job.


I agree. So why have so many programmers in Silicon Valley? Why don’t they leave and demand independent contracts? Perhaps that kind of “unbundling” of technical talent is the future.


It's the problem of being paid enough. My wife asked me the same question recently, "Why don't programmers unionize?" They could demand more through collective action, but they don't feel the need.

Also, programmers are (often) worth more in teams. Two programmers who work well together are far more productive as a pair than the sum of what they'd do in isolation.


This. A good manager is a force multiplier.


Figuring out what to do is the hardest part. Engineering is typically the least significant part of the success or failure of a company.


"I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the Earth", said Kennedy, and all the senators rushed the podium, slapped him on the back, and popped champagne, as they realized the hardest part was done.


... Yes? Kennedy got them to fund NASA at a level that's never been seen since: https://www.aaas.org/sites/default/files/s3fs-public/BudgetD...


But it was the hardest part wasn’t it? Nobody since then managed to get that commitment for a space program.



And if only Napolean or Hitler had managed to get enough 'commitment' for their plans to conquer Europe, they would be sitting pretty right now? Yeesh.


Not parent, but in every successful project I have been part of, the technical challenges were always a small slice (perhaps less than a quarter) of the main effort. Getting organizational approval (which usually boils down to acquiring buy-in from management) and picking the path to progress (with occasional course-correction) are the main contributors to success.

This isn't to discount the hard work involved in completing the technical tasks, but commiting _to_ begin something along a certain development vector is, indeed, the hard part.


Getting organizational approval (which usually boils down to acquiring buy-in from management

Why not just... not employ the people you need to fight in order to get anything done? How does the organisation and its shareholders benefit from employing full-time professional obstacles to progress?


What do you mean by "figuring out what to do?" If you mean "write a detailed specification for every component in the system", then what is engineering exactly?


Maybe in the short term. In the long term, a company can collapse under the weight of its own technical debt, when it can no longer innovate effectively compared to the competition.


If a company makes it to where they are collapsing under technical debt, they have already made it much farther than most startups.


Totally disagree. In my experience across three tech firms, Product Managers spend a lot of time selling themselves. They are

talking to customers (read: networking for their next job),

going to conferences (read: shmoozing with their next potential boss),

researching competitors (read: figuring out where to apply)

researching products (read: learning on the job)

Is it any surprise they tend to make more than people stuck in the office coding?


talking to customers -> Listening to what the customer's pain points are, what the customer needs, what to address

going to conferences -> Because face-to-face contact is far faster and richer than sending emails

researching competitors -> What aren't we doing that others are doing better / what are we doing that's winning / what to change?

researching products -> well, yes, constantly learning

Is it any surprise they tend to make more than people stuck in the office coding?

Listening to customer needs, staying ahead, constantly learning. Sounds like good general career advice.


I do not see any activity here which would indicate a higher pay from any other ordinary worker.


That's very astute. You are right, there's nothing in those activities that command a higher pay. For product managers, it's the work that comes after doing all the above which commands the higher pay: Synthesizing all the information that was gathered to present a strategy which satisfy consumer needs and exploit competitor weak points. Creating a long term roadmap which gives direction to the work that the engineering department will do. And doing both convincingly enough that upper management buy into the strategy you are proposing. This is the no-right-answer, risky work that product managers are paid for.


We are quite literally running out of productive things to do so we (the collective group) are all currently micro-optimizing everything we can lay our hands on. It's like a pond that's shrinking with all the fish gasping for air.

A paradigm shift is necessary before we end up strangling ourselves.


"The advancement of the arts, from year to year, taxes our credulity and seems to presage the arrival of that period when human improvement must end." -Henry Ellsworth, US Patent Office Commissioner, 1843


Yep exactly. Especially for smaller, faster growing companies: what you choose to not work on is usually more important than what you choose to work on (once you remove the core work to support the company's current state). Without someone with product experience - usually either a PM or an experienced software leader - adding additional engineers often paradoxically hurts total productivity.


Most companies still have a very hard time building a good machine learning pipeline.


And most product managers would confirm that most companies do not need a good machine learning pipeline.


As an older engineer currently having fun digging into ML: yep, a well thought-out set of good-ol business rules can do a lot of what teams are applying ML to these days.

Nothing wrong with learning new things, though. I can get behind that. It's important to stay intellectually honest, however.

On the other hand, research efforts on vision, language and autonomous systems are genuinely pushing boundaries.


Business rules are concrete and have people and names attached to them. ML allows the robot to take all the blame.


Supervised learning using a variety of different neural network pipelines is doing some genuinely impressive things from a business perspective. But not much beyond that at this point (again, from a business perspective).


Really? Because most product managers I meet are the ones going “how can we put AI and Machine Learning into <some task that doesn’t need it>?”

I 100% agree that most companies don’t need nearly as much ML as think though.


full disclosure: I'm a PM in FANG

I think that's what the bad PMs do. Good PMs think 'what is the smallest possible thing we could do to start truly adding value against our problem space?'

A good heuristic is that good pms are problem oriented - bad pms are often focused on solutions first


Why should engineers agree to work for a regular salary from you? Why wouldn't they hold out for ownership in your product venture?


Supply and demand? My assumption is the less challenging a technical project becomes, the more supply of engineering talents can work on the project. There should be more generalists after all. And dynamics of supply and demand will determine if engineers will be able to "hold out for ownership".


What, precisely, limits the supply of people who have "product talents to figure out what is valuable to produce"? Why are are people with such skills apparently more rare than people with technical skills?


That beats me. If I have to guess, I'd venture to say dealing with ambiguity is truly hard. As a production manager, you need to have unique insights on the market you're interested; you need to capture future trend; you need to understand human psyche, you need to convince your company to take risks and invest into something that does not necessarily have a future, you need to build trust with both the engineering team and the management, and you should be analytical enough produce supporting numbers. Many of such activities are ambiguous in nature, and getting clarity and buy-in out of such ambiguity is in high demand in the current market.

On a side node, engineers do sometimes need to function as PMs to build great product.


In my (limited) experience; a lot of our best PMs were once engineers, and they usually transitioned to PM roles because it let them actually execute on their visions, in addition to potentially more career growth potential.


Project managers having an engineering background is definitely beneficial, but should also be in their past. They should not be actively coding on the project. It's not a split role of managing and developing.


I don't think the parent implied "actively coding on the project"...at the very least, I interpreted "execute on their visions" as having been granted the authority to direct the pursuit of business endeavors that previously didn't exist.

I'm also of the opinion that a technical manager who purposely relegates engineering to a forgotten past is one who is pragmatically posturing for premature obsolescence; an axe in denial who refuses the occasional sharpening cannot be discerned from a rusty shovel and will sooner dig his own grave.


I don't think the parent was implying that either. I was simply giving my 2 cents in regards to what a great vs mediocre project manager does. I was actually agreeing with it.


I see. Thanks for the clarification.


There's nothing that limits the hypothetical supply of people with relevant skills (innate or with potential to learn). However, there is a limit on the number of people with experience in those roles - and work experience is used as a proxy for determining skills.


I think as a mathematical comparison. Given a successful product, there are likely way more engineers than product people.


That's assuming the consequent though.


It leads to the supply for any given experience level >0 being smaller for the product people.

Also, even in the 0 experience group, the selection will be tougher. This is independent of the measurable or existing differences in skill. The person that is best at convincing the employer of hiring them as a solo product manager is in a better position to negotiate than the person who managed to be among the five seemingly best developers.


Think the key factor is, talented engineers write software that's maintainable, and easier to change, extend & adapt.

This could make the difference between having to do a complete rewrite at great expense, vs a small tweak.

For startup with no customers it's probably fine to cowboy up a solution, then throw away and start again, to find market fit.

But if you've got lots of customers, and you're forced to rewrite because the previous engineers left an unmaintainable mess, it's going to be hugely complex, risky, long & expensive undertaking.




Applications are open for YC Summer 2020

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

Search: