10 ms·
I have a different (admittedly controversial) take, having been on the "tech ladder" for some time now (as a Senior SWE and Lead Engineer): most individual cont
by sidlls 9y ago
I have a different (admittedly controversial) take, having been on the "tech ladder" for some time now (as a Senior SWE and Lead Engineer): most individual contributors overestimate how much value they actually provide, especially in the Bay Area. That isn't to say we're not under-appreciated and under-compensated (we are both). But realistically much of the time work we do is easily done by literally thousands of other people just as well. The same just isn't true of product development, sales and marketing. Any one of those three teams, staffed well, will account for well more than the value of the entire engineering organization.
Mostly this is a self-inflicted problem. Especially in the Bay Area, where developers tend to value CS ability signaling rather than the ability to work well with product teams and the ability to engage in practical engineering.
There's too much focus by developers on shallow things, like fad-following the latest frameworks, on pseudo-intellectualism or technology-purism (e.g. "coding is doing math", code "elegance", whether/how FP is just so much better than anything else, etc.), and trivia like programming language choice.
- vvanders 9y agoEverything you listed is just a multiplier on if the technology actually works. If you have a sucky multiplier of course your product won't do well but if it isn't technically executed right you still have a zero.
- sidlls 9y agoIt isn't binary: value is created by all parties involved. It's just, in my opinion, that if we normalize the value created to be 1 for the product team, then engineering's value is less than 1, and sales and marketing is (more often) greater than or equal to 1, most of the time. Exceptions exist. But they're not normal, by definition.
- ddustin 9y agoAn engineer's value can be exponential and can even go well beyond their own lifespan. Sales and marketing impact is immediate and falls off over time while engineering's impact is slow and can speed up over time.
- rockostrich 9y agoRight, at a start-up the value of product, sales, and marketing is huge compared to that of engineering. Most engineers can create an MVP that will deliver the promises of the other 3. The problem is trying to scale that product once marketing and sales do their job. I think the value of each of these 4 changes depending on the company size and tend to normalize to 1 as the company scales to the size of Google, Amazon, FB, etc.
- sgift 9y ago> that if we normalize the value created to be 1 for the product team, then engineering's value is less than 1 Well yes, if we make completely baseless "normalizations" than that's true. Obviously, there is no reason to do that, but sure, if we do it that's the result.
- roenxi 9y agoBut that argument goes all the way down the value chain. You'll end up with something like food production > transport > tech. The chain can be as long as you feel too. It is a radical proposition that a farm day laborer adds more value than an elite tech worker because 'the system would stop without food'. The value add is controlled by the person who decides what "value add" is. That is the executive, original product designers and customers (who may well be represented by marketing in some businesses, I dunno).
- Retric 9y agoFood surplus comes from mass production not farm hands. The guy who handles 20,000+ acres of crop is more productive than the average dev and makes more money. http://www.cornandsoybeandigest.com/are-1000-acres-part-time-work http://www.cornandsoybeandigest.com/are-1000-acres-part-time... “One of the most difficult factors for many 1,100-acre or less farmers to accept is that, unless they have livestock, they're probably underemployed. Thirty years ago, 1,000 acres was enough to support Dad, me and three hired men. ... As one industry sage puts it, “It's not the 1,000-acre farmer that needs to worry. They can still support themselves with off-farm income. The guy who needs to worry is the 3,000- to 5,000-acre farmer who knows he needs to reach 10,000 acres if he wants to stay in business.
- graycat 9y agoIf your farm is too small, then lease it to someone who farms, say, 10,000 acres by leasing smaller chunks. Then get a job in town!
- vvanders 9y agoYes, we call that Society and as you're seeing Puerto Rico none of the tech matters if you don't have basic infrastructure. They definitely add more value than us. Are they under-represented and under-valued? Probably. Just like IT, they only get noticed when things screw up or go wrong.
- dasil003 9y agoThe reason this argument doesn't hold water is because the underlying infrastructure supporting the company as a whole is just a commodity. There is nothing special about the food or the transportation or even the server infrastructure that the startup uses, it's all fungible and thus there is an efficient market around it. But engineering and sales for a single product are inextricably linked. If engineering does not create a good product, that directly affects the success of the sales people; and vice versa if the sales team sucks then a great products potential value can go unrealized.
- mo1ok 9y agoI agree and both disagree. I'm working right now for a client that is a large corporation that didn't do any of those "fad" things - and it is _tremendously_ costly. For example, one team has spent several weeks and thousands of dollars to get another team's SOAP integration working correctly, when it would have taken five minutes in REST. The codebase did not follow a "elegant" practice and is an absolute spaghetti mess. Things that should take 30 minutes take one week and this add tremendously to personnel cost. I agree though that working together is tremendously undervalued. A decently smart person can be taught anything (which is part of the replacability problem you mentioned), but how to not be an entitled ass is nearly impossible to teach in a workplace environment.
- bostonvaulter2 9y ago> I agree though that working together is tremendously overvalued. I think you mean undervalued.
- mo1ok 9y agoOopsie. Fixed.
- Newtopian 9y agoRegardless of how long it REST or how much you pump it full of SOAP, a spaghetti mess will still be a giant bowl of indigestible pasta.
- nostrademons 9y agoSOAP was the fad before REST. And spaghetti code is usually the result of fulfilling customer's requests without taking (/wasting, depending on your perspective) the time to rewrite & refactor. This'll probably come across as depressing to most of the engineers in the audience, but I don't see this as an example of a company that did anything wrong. Rather, it's a company that did everything right but did it too early. They followed the fad of the early 2000s; there was no way to know then that a better fad would come out in the mid 2000s. And they're still around (and a "large corporation") now, which indicates that from a customer & business POV, they've actually been more successful than ~99% of other technology companies founded in that era. If you're successful, you too can get to have the kindergartners of today complain about what an idiot you are. That's the best-case outcome, though: more likely, nobody will use your code or it will be thrown away a year later for the newer, shinier fad. (The more positive spin on this is that our industry actually is making progress, and quite rapidly. What other industry can you look at the best practices of 15 years ago and say "What idiots we all were back then!"?)
- jcmoscon 9y ago>"whether/how FP is just so much better than anything else" Hey, FP IS much better than anything else! Lol, this is me
- disiplus 9y agothats just if you sell shit that nobody wants but its marketing/sales reposnibility to sell it, then sure marketing and sales are more imporant. but if you create a product that is realy solving some problems then, the product is important and the team that created it.
- yahna 9y agoThe same just isn't true of product development, sales and marketing. Any one of those three teams, staffed well, will account for well more than the value of the entire engineering organization. Okay, slash your engineering staff and double the sales people and lets see how you do. How is any of that not done by thousands of other people as well? Especially sales.
- biohax2015 9y agoSales is more difficult than engineering. There, I said it.
- sidlls 9y agoI disagree. Sales is fuzzier than engineering and requires a different set of skills and methods to resolve problems.
- SturgeonsLaw 9y agoFor a certain type of person, sales is much easier - if not completely natural. For others, the same could be said about technical pursuits. I don't think it's possible to make general statements that one is harder than the other, because it depends very heavily on the person involved.
- richardjennings 9y agoI'm sure selling mediocre, repackaged, off the shelf tech is harder than engineering it. Standing on the shoulders of giants gets us a long way quickly (and easily). IMHO engineering is more valuable; I define value as the expansion of possibilities & opportunities (to sell).
- ouid 9y agoWell, without radically changing the economic system, your compensation will be, at most, the cost of replacing you, and the gap between your compensation and that figure depends on the information gap, and the chutzpah with which you negotiate. I'd wager that if developers renegotiated their contracts at the point where they were most irreplaceable on projects they would be able to extract a lot more money.
- crdoconnor 9y ago>I'd wager that if developers renegotiated their contracts at the point where they were most irreplaceable on projects I'd wager that most executives would rather pay 5 people to do the job of 2 or even simply bury their head in the sand and not admit to themselves that replacing you is going to be more costly than let you have that kind of leverage.
- ouid 9y agoThreaten to quit and see if you don't get executives offering you more money.
- CoreXtreme 9y agoMost aren't in position of sending threats in the way of their executives.
- taneq 9y agoYou're right. It's critical not to let the troops catch a whiff of their individual importance or you'll have to start paying them closer to their actual value to you... and that's bad for profits.
- deleted 9y ago[deleted]
- hahamrfunnyguy 9y agoAs a manager I disagree. The right people are difficult to come by. Sure an engineer can be replaced - but in how many weeks or months, and what about the knowledge leaving the company?
- charlesdm 9y agoIsn't this just also dependent on pay? Let's take a ridiculous example, but if someone were to offer me, say, $1m (a year) to work on a specific key niche project (i.e. something that fits within my skill set and where I could add tremendous value) then I would happily move wherever around the world. Pay more -> you'll probably get a (significantly) higher amount of qualified applicants?
- abraae 9y agoYou seem to assume its easy to sort the wheat from the chaff. If you offer $1m per year (which is a ridiculous premise from the get go), you'll maybe get more good candidates (though a lot would assume there was something weird going on and would balk), but you'll certainly also get way more bad candidates, including many who are cunning and able to take up a lot of your recruiting bandwidth, and maybe cunning enough to actually talk their way in - making your problem worse. It's just too simplistic to assume that throwing money at the problem will solve your talent problems.
- ryandrake 9y agoSorting the wheat from the chaff is Problem One you need to solve regardless of whether you offer below, at, or above market pay. I think the grandparent poster's point was that by offering well above market pay, you will have more of both (wheat and chaff) in your funnel so you'll be able to sort through more wheat. Assuming you have Problem One nailed you'll end up ahead of those offering below market (who might only attract chaff).
- alien_at_work 9y ago>It's just too simplistic to assume that throwing money at the problem will solve your talent problems. Labor is a market exactly as any other: paying the highest price does not always get you the best quality but paying the lowest price always ensures you don't.
- kartan 9y ago> The same just isn't true of product development, sales and marketing. Any one of those three teams, staffed well, will account for well more than the value of the entire engineering organization. Why is it not true for them? Sales are not magic, it is a profession that can be learned. I have seen a lot of companies stating how important is sales, and how unique they are. It can't be true for all companies. It is like everyone thinking that they are above average, it is just not possible. If your product is software, literally it is impossible that sales add more value than the engineering organization that builds the product. Without engineering organization, you don't have anything to sell. Without sales and marketing, you will also have a hard time. It is collaboration what brings success. > There's too much focus by developers on shallow things, like fad-following the latest frameworks, on pseudo-intellectualism or technology-purism This is usually a problem with recruiting. You get what you pay for. If your interviews are about technical expertise and you ignore basic persona-values evaluation and fit to build valuable features, you get that. And it jeopardizes the viability of a company. You need some really good experts, but you don't need everyone to be one.
- JumpCrisscross 9y ago> Why is it not true for them? Sales are not magic, it is a profession that can be learned Like software engineering. And like writing software, some people are better at it / enjoy it more than others. Software engineers and good salespeople are very well compensated because they're hard to replace. > I have seen a lot of companies stating how important is sales, and how unique they are. It can't be true for all companies. It is like everyone thinking that they are above average, it is just not possible. Most companies, particularly most start-ups, suck at sales. "Great engineers, shit sales" is a more common failure mode in Silicon Valley than "sold something couldn't be built." Also, "good at sales" isn't a one dimensional metric. There are different sales processes, some of which some people (and consequently companies) are better at than others. > If your product is software, literally it is impossible that sales add more value than the engineering organization that builds the product You're conflating how essential a step is to a process with how valuable it is. Mediating those factors is how difficult it is to replace the parts in the step. Consider, for example, an automobile assembly line. It would be incorrect to assume that just because the vehicle is useless without an engine, it is impossible for anyone to be more valuable than the person who mounts the engine.
- JamesBarney 9y agoJust like how you say the work engineers do is not magic. That literally 1000s of other people can do it. That's also true of marketing, sales, and product development. Takes sales for instance, sales is knowing your clients needs, and knowing how your product fits into those needs and then having a shit load of conversations about how your product fits clients needs. There isn't any magic. You can contact more people, and you can convince a few percent more people to buy your product.
- seppin 9y ago> You can contact more people, and you can convince a few percent more people to buy your product. This represents a fundamental misunderstanding of how sales works.
- JamesBarney 9y agoI'd be curious what about it is wrong?
- lostcolony 9y agoYou are both correct and incorrect. As others mentioned, product/sales/marketing/etc can all be replaced just as easily as developers. However, and I think this -may- be your point, the work generated by those groups is understood by upper management as a key to success, whereas upper management likely does not understand that having the best tech is also a key to success (and, honestly, it's one that can many times be partially overcome by sufficient marketing, or overshadowed by bad product people, or...).
- curun1r 9y ago> the work generated by those groups is understood by upper management as a key to success I think you could have left off the "as a key to success" part. Software engineering, as a discipline, is very hard to quantify and hard to understand. Every metric that anyone proposes for measuring the output and quality of work of a developer has largely been shown to be possible to game and not representative of good work. We wax poetically about an extremely productive day in which we got rid of 200 lines of code...no sales person would consider losing a customer to be a success, so you can see how that would sound confusing to a non-engineer. And the interview process is largely lampooned for asking questions that have very little applicability to the actual work being done and, yet, no one can agree on what questions a good candidate should be able to answer. Even engineers can have vastly different stances on what constitutes good work. There's an old saying, "that which cannot be measured cannot be managed." A sales team can easily be stack ranked and their dollar value to the company measured to the penny. A marketing team can be judged by engagement numbers, inbound leads and other quantifiable results that are easy for an executive to understand. A product team's output is somewhat harder to quantify, but executives usually do take the time to understand their product and customers, so they can relate and have opinions on the work produced by the product team. Meanwhile, the engineers spend they day looking at text in another language, having conversations and arguments about bizarre made-up words like Hadoop, Riak and Mesos. They often have trouble communicating technical concerns to non-technical members of the team, including management. And seemingly simple changes in product direction are met with large time estimates and mutters of "redesigning the schema" or "scalability." So executives decide to focus on optimizing and rewarding the departments that they can understand and engineering gets seen as a black box assigned to someone somewhat technical who's often only good at spin/messaging and not really a great technical leader. It's pretty undeniable that engineers create value. Even executives realize that. But the marginal value of one engineer over another is extremely difficult to know, even for people in engineering. So it's much easier to just assign them to tiers (SSE, Senior SSE, Staff SSE, Lead SSE, Architect, etc) and then treat them as fungible quantities.
- madeofpalk 9y ago> That isn't to say we're not under-appreciated and under-compensated This is possibly the most HN thing I've ever read. Bay Area developers are under-compensated?
- ticviking 9y agorelative to demand and cost of living potentially
- sidlls 9y agoRelative to the value we add? Absolutely. The under-compensation is even worse elsewhere.
- RHSman2 9y agoIf software developers add so much value they should start their own business. Then they'll see how valuable sales and marketing is
- Philomath 9y agoI think he is thinking in terms of shares of the company, not salary. Salaries in the Bay are obviously higher than anywhere else, but what people want is to become millionaires when the company they work for sells to a bigger company.
- madeofpalk 9y agoDoesn't everyone want to become millionaires though? Seriously, discussions like this just show how out of touch sometimes this crowd is like.
- alien_at_work 9y agoJust because someone is paid a lot doesn't mean they're not under-compensated. Remember the sports team strikes? They were making lots of money before but they felt they weren't getting enough of the value they created so they did a strike and proved it. Wages are (very purposely) not an efficient market so a group making more than most doing the same kind of work does not mean said group is overcompensated. It could be that the entire group is under-compensated, some of them just less so.
- jjsjdhh88 9y ago"...most individual contributors overestimate how much value they actually provide..." Am reading "Deep Work" right now. In it he touches on this while explaining how hard it is to measure, and how no reliable attempts have turned up by those who try. This applies to C*O level on down, no one is sure how to measure this. So when you write: "The same just isn't true of product development, sales and marketing." I call BS. There is no measure out there that can accurately gauge the specific contributions of an individual or a team within an org, in knowledge-centric work these days. There are outliers. A team will luck into a bigger than expected sales deal. Or engineering stumble into a way to provide the same performance with less servers.
- Kalium 9y agoAttribution is critical. A salesperson who lands a big deal can claim it's their exclusive work. An engineer who is one of a dozen people working on a feature that customers like does not have a similarly clear number they can point to as value added.
- plicense 9y agoI've come to the realization in my short career that 90% of my time will be spent on activities that produce 10% impact and 10% of my time will go towards activities that have 90% impact. But the 10% time producing 90% impact stems from the fact that I spent the other 90% doing mundane work and understanding the environment/product/whatever problem am working towards solving. As an example, my company uses Django and the first 6-8 months I have spent hours debugging what would be a stupid issue like misconfigured Django or missing url. Eventually, that led me to optimizing the version of shell_plus that my company was using improving its bootup time by 200%(this was a rather large codebase). That's an instant 200% gain per developer/per django shell load and is probably the most impactful thing I've ever done. We estimated it would save around 6.67 hours of developer time per day(2 minutes saved - was originally 2.45 * 200 developers * 1 shell load every day)
- tommikaikkonen 9y agoWhat was the optimization?
- plicense 9y agoOur version of shell_plus was trying to handle aliased models that were defined in settings.py. In order to do this, it was maintaining a map of {appName: [list of imports]}. When constructing this map, for some reason, it n^2 the imports - i.e., if an app "foo" had models "Bar", "Foo", "FooBar", then the import strings were, "from foo import Bar; from foo import Bar, Foo; from foo import Bar, Foo, FooBar" instead of "from foo import Bar, Foo, FooBar". Some apps had 50+ models, so instead of 1 import line for these 50 models, it was executing 2500 import lines. I fixed this so that it executed only one import line instead n^2 import lines.
- graycat 9y agoIf you work for others as a programmer, then likely they will want you to have spent the last five years using the tools they are using. If have your own business and write your own code, then you get to pick what you want to learn and use and stay with just that. And maybe you already know enough. E.g., if some parts of Microsoft's .NET are enough for what you need to code and you know it, then why rush off to Linux? E.g., for my startup, I typed in 100,000 lines of typing with 24,000 statements in Visual Basic .NET; it all runs. And I know a lot more in computing but is not popular now. From just what I know, I can't be hired as a programmer, but I have no trouble programming for my startup.
- kamaal 9y ago>>The same just isn't true of product development This statement is laughable. In almost 99% of the companies out there 'product development' is simple a placeholder to describe people who look at the results of A/B testing and say which design to go with. You could supplant a child in their position and it would barely make a difference in any value created. Product development is the place where MBAs go to retire and for all practical purposes add 0 value to anything real. Mostly its UI designers who suggest ideas. Engineers implement them, a data analysis team crunches data and finally presents it in a pie chart. All the so called product manager does is look at which parts occupy a bigger chunk and make a yes or no decision.
- taway_1212 9y agoMaybe that's true at companies selling to consumers (everyone is a consumer, so everyone can conceviably have valid ideas for new features). However, at companies selling to businesses, the developer is usually more or less clueless about the product domain (even if it's something technical, like CAD or data science) and has no useful ideas. It's the product people who (ideally) have decades of domain experience and talk to users from various companies constantly about what they would like to see added.