There's really way too many developers that care way more about the code than the product, let alone the business.
It ends up like fine dining, where 99% of the times a big Mac would've been tastier and made the customer happier, but wouldn't justify the effort and price.
I keep hearing how 10x engineers make their companies millions upon millions but they only get paid a fraction of that. How does that even make sense as a fair exchange? Not to mention is completely unfeasible for most people to have this kind of impact... it is only possible for those in key positions, yet every engineer is tasked with this same objective to increase company value as much as possible. There's just something very wrong with that.
Because they feel they can extract more value from them then they are paying them.
There are no real boundaries of when work starts and stops or when your responsibilities end because the task is to increase business value and that is technically endless
I work 40 hours a week and they pay me the agreed upon amount. There was nowhere in our agreement the expectation of my working more than that. I also knew that they could put me on a plane anytime during the week.
The company keeps piling more and more work, keeps growing and growing,
That’s completely on the employee to communicate trade offs between time, cost and requirements. My time is fixed at 40 hours a week. They can choose to use my 40 hours a week to work with sales and the customer to close a deal, be a project manager, lead an implementation, be a hands on keyboard developer, or be a “cloud engineer”. It’s on them how to best use my talents for the amount of money they are paying me. But seeing that they pay my level of employee the highest of all of the ICs, they really should choose to have me working with sales and clients to close deals.
That’s not bragging. I make now what I made as a mid level employee at BigTech in 2021.
I keep hearing how 10x engineers make their companies millions upon millions but they only get paid a fraction of that. How does that even make sense as a fair exchange?
The concept of a 10x engineer except in very rare cases is a myth if you think of them as just being on a keyboard everyday. All of the things I listed I could do - project management, backend developer or a cloud engineer - I would say I’m only slightly better than average if that. My multiplier comes because i can work with all of those people and the “business” and they can put me on a plane or zoom call and I can be trusted to have the soft skills necessary and my breadth is wide enough to know what needs to be done as part of a complex implementation and how to derive business value.
If you are making a company millions of dollars and you are only getting a fraction of that - and I doubt someone is doing that on their own without the supporting organizational infrastructure - it’s on you to leverage that to meet your priority stack.
Not to mention is completely unfeasible for most people to have this kind of impact... it is only possible for those in key positions, yet every engineer is tasked with this same objective to increase company value as much as possible. There's just something very wrong with that.
If you are a junior developer, there isn’t much expected of you, you are told what to do and how to do it. You aren’t expected to know the business value.
If you are a mid level developer, you are generally told the business objective and expected to know best practices of how to get there and understand trade offs on the epic/work stream level.
If you are a “senior” developer, now you are expected to understand business value, work with the stakeholders or their proxy, understand risks, navigate XYProblems on the project implementation level and deal with ambiguity.
As you move up the more “scope”, “impact” and “dealing with ambiguity” you have to be comfortable with.
“Codez real gud” only comes into play in getting from junior to mid.
> All of the things I listed I could do - project management, backend developer or a cloud engineer - I would say I’m only slightly better than average if that
I completely acknowledge this is a valid way to run a business, but the context here is how this sort of career progression is preventing the specialization of engineers in their domain and contributing to the widespread of software problems. Instead of investing in good engineers that specialize in their domain, companies move them away from engineering into more of an entrepreneur mindset by tasking them with adding value to the business directly, which is not something that you do as an engineer (it's nowhere in a CS degree, aside from say some electives).
A good metaphor here is a football/soccer team. What companies are doing is telling the goal keeper that he needs to score goals because more goals means winning. The team wants to win so everyone on the field has to score a goal. That obviously doesn't make sense even though the premise is true. You want a team composed of specialists and the more they specialize in their domain and work together the more you win. Even though there are only two or three offensive players that are scoring the goals, everyone is contributing to the success of the team if they specialize in their domain. Similarly, just because talking to clients and selling the product is directly contributing to the revenue of a business it doesn't mean that engineering at a higher level has no value.
And once again to stress the context here, companies can do whatever they want, but having engineers progress through their careers by moving AWAY from engineering is precisely why there is so much bad software out there. Letting engineers create better software should result in more profit in the long term, just probably not in the short term, and it's also hard for non-technical people to manage. So it is what it is.
Engineering is not only the physical labor. Aircraft engineers and building engineers don’t spend most of their time doing hands on work.
https://www.careerexplorer.com/careers/engineer/
Designing and Planning: Engineers are responsible for designing and planning systems, structures, processes, or technologies. They analyze requirements, gather data, and create detailed plans and specifications to meet project objectives. This involves considering factors such as functionality, safety, efficiency, and cost-effectiveness.
When doing construction work, who adds more value?
The general contractor? (Staff software engineer),
The owners of the plumbing, electrical, and HVAC companies assuming they have the actual skills (senior level developers). The owners of the plumbing companies could very well be making more than the general contractors. This is where you can specialize and the sky is the limit.
The actual certified workers (mid level developers). This is the level that the completely head down people are. No matter how good they become at being a hands on plumber , there is a hard ceiling they are going to hit at this level.
The apprentices (juniors)?
I work in consulting. I am currently a staff architect (true - IC5) over a hypothetical project (not a real project). I know the project is going to need a cloud architect, a data architect , and a software architect. They are all specialists at their jobs and are all going to lead their “work streams”. They are all IC4s
I expect each architect to take the high level business objectives and work with the relevant technical people on both sides and lead their work along with some hands on keyboard work.
They will each have people under them that are not customer facing at all. While I know all of the domains at some level, I’m going to defer to their technical judgement as long as it meets the business objectives. I did my high level designs before they came on to the project. Was my design work, figuring out priorities, risks, making sure it met the clients needs, discussing trade offs, etc not “engineering”?
Each level down from myself IC5 to junior engineers (IC1) is dealing with less scope, impact and ambiguity. There is no reason that the architects shouldn’t get paid as much as I do. They bring to the table technical expertise and depth. I bring to the table delivery experience, being able to disambiguate, and breadth.
No, but software is inherently different because you can leverage existing software to create more software. Every airplane has to be created individually, but software that already exists can be extended or reused by just calling functions or in the worst case copy/pasting.
> The actual certified workers (mid level developers). This is the level that the completely head down people are. No matter how good they become at being a hands on plumber , there is a hard ceiling they are going to hit at this level.
Yes, with hardware this can be the case as there is a small number of ways to build something. With software there is no ceiling, and the proof here is AI. We might soon see general intelligence that just codes anything you want. This means software can be designed to automate virtually anything in anyway shape or form, but it requires more and more expertise.
> I did my high level designs before they came on to the project. Was my design work, figuring out priorities, risks, making sure it met the clients needs, discussing trade offs, etc not “engineering”?
I agree what you're outlining is how the industry works. Perhaps the core of the issue here is how software engineering was modeled after other kinds of engineering with physical limitations. Software is closer to mathematics (arguably it's just mathematics). You can of course still design and plan and delegate, but once the role starts dealing with the high level planning, scheduling, managing, etc., there is less of a requirement for the technical details.
I've worked with architects that didn't know the specifics of a language or design patterns, not because they're bad at engineering but because they had no more time to spend on those details. These details are crucial for good software that is reliable, robust, extensible, etc. Junior and even mid level engineers also don't know these details. Only someone that has been hands on for a long time within a domain can hone these skills, but I have seen so many good engineers become senior or tech leads and then forget these details only to then create software that needs constant fixing and eventually rewriting.
I'm a senior myself and have no choice but to engage in these activities of planning, scheduling, etc., when I can clearly see they do not require technical expertise. You just need some basic general knowledge, and they just are time consuming. My time would be better spent writing advanced code that mid-level and junior level can then expand on (which has happened before with pretty good success, accelerating development and eliminating huge categories of bugs). Instead I have to resort to mediocre solutions that can be delegated. As a result I can see all kinds of problems accumulating with the codebase. It's also really hard to convince the leadership to invest in "high level" engineering because they think that you create more impact by managing an army of low to mid-level engineers instead of leveraging properly written software. I'm convinced that it does add value in the long term, it's just a hard sell. Ultimately I guess it comes down to the type of org and the business needs, which often does not include writing software that will not break. Most companies can afford to write bad software if it means they get to scale by adding more people.
That’s true. But when I put my “software engineering”, “cloud engineer”, or “data engineer” (theoretically) hat on, I can only do work of one person. No matter how good I am at any of it, I won’t be producing more output than someone equally qualified at my own company. Distributing software does have zero marginal cost more or less and that’s why we get paid more than most industries.
but I have seen so many good engineers become senior or tech leads and then forget these details only to then create software that needs constant fixing and eventually rewriting.
This is just like both my general contractor analogy and my real world scenario. As an “staff architect”, I come up with the initial design and get stakeholder buy in. But I defer to the SMEs the cloud architect, the data architect and the software architect who still eats, sleep and breathe the details in their specialty.
Just like the owners of the plumbing company, HVAC company and electrical company are the subject matter experts. The general contractor defers to them.
In the consulting industry at least, there are two ways you can get to the top, by focusing on depth or breadth. But in neither case can you do it by being staff augmentation (the plumber, electrician, or HVAC person), you still have to deal with strategy.
> You just need some basic general knowledge, and they just are time consuming
Knowledge isn’t the issue, it’s wisdom that only comes with experience that I assume you have. Going back to the hypothetical large implementation. It involves someone who does know architecture, development and data. No matter how good your code is, high availability, fault tolerance, redundancy, even throughput comes from the underlying architecture. Code and hands on implementation is usually the least challenging part of a delivery.
Its knowing how to deal with organizational issues, managing dependencies, sussing out requirements, etc
> No matter how good your code is, high availability, fault tolerance, redundancy, even throughput comes from the underlying architecture. Code and hands on implementation is usually the least challenging part of a delivery.
I agree to a certain extent. Unless the solution is short lived, designing the code to scale properly is extremely important, and this happens at the implementation level where details of how code is being added makes all the difference. I can see how contractors might not be thinking about this, but it's a recurring pattern with legacy systems. Additionally with software, implementation gets automated away if done correctly, so there is only an initial overhead that pays back as the codebase grows larger and larger.
I'm not saying there is no need for engineers that deal with org and management issues, but rather that companies underestimate the need for senior level engineers focusing on the software implementation details, only to pay the price as the codebase inevitably accumulates complexity later as it scales in size.
Anyway, great discussion, I appreciate your input and will be considering it more.
Look, I get that HN is startup-focused, but many companies DO drown themselves in tech debt of the sake of the business case.
Then a few years pass and they are unable to deliver features quickly enough - they can't keep Sr. engineers because their stack is a soul-sucking, career-killing tarpit. The Jr. engineers don't know how to fix the code and don't even see anything wrong with it because it's all they've known.
It's totally fine if you're a megacorp - Salesforce and so on can hire JUST ENOUGH high-level folks to keep the system manageable. It's also fine if you're so small that all your work is greenfield.
The type of company that I'm describing is generally Series D/E and probably worth a few 100M dollars.
Your reasoning for tackling tech debt is sound. “We are moving like molasses. Our foundation is wobbly and we can’t build new features until we start tackling $X tech debt. These are the reasons that it will help us in the future.”
But on the other hand, if I achieve x, y, and z or someone else achieve it and we are told it didn’t achieve enough “impact”, yeah I am going to do like Google employees do and decide to work on the 5th messaging app.
When done correctly it absolutely adds business value and should not make it harder to adapt or change, that's the point of good engineering. The problem is that you need years, if not decades, of technical experience to see this, and it's also a hard sell when there is no immediate "impact". It's basically something that happens because consumers don't know any better, so then it becomes low priority for making profit... at least until a competitor shows up that has better software and then it has a competitive edge, but that's a different matter.
Its called “being out of touch” I believe
Bad software keeps happening because businesses can afford it, as well as hardware improvements. It's a combination of consumers not knowing what they are missing and hardware advancements allowing for bad software to exist.
If you aren’t writing software with the customer and business in mind, why are you doing it? That’s what you are getting paid for.
That said, AI is about to change all this... but ironically this justifies my position. If software can be so powerful such that you can have a general intelligence that can do almost any cognitive task... then it follows that all this time engineers can also engineer clever systems that can add a lot of value to the company if engineered correctly.
There is no ceiling of how much performance and value can be squeezed out of a software system, but this never happens because businesses are not investing in actual engineering but rather in technical entrepreneurs that can bring something to market quickly enough.
There is no “implicit value” of software to a company. The only value of a software to a company is whether it makes the company money or saves the company money. That’s it, there is no other reason for a company to pay anyone except to bring more value to the company than they cost to employ them.
If software can be so powerful such that you can have a general intelligence that can do almost any cognitive task... then it follows that all this time engineers can also engineer clever systems that can add a lot of value to the company if engineered correctly.
It’s just the opposite. If AI can do any of the coding that a software engineer can do and I am not saying that’s possible or ever will be, what’s becomes even more important are the people who know how to derive business value out of AI.
> There is no ceiling of how much performance and value can be squeezed out of a software system
That may be true. But what’s the cost benefit analysis? Should we all be programming in assembly? Should game developers write a custom bespoke game engines and optimize them for each platform?
The implicit part is that if you engineer a good system then it saves money with less bugs and breaks less, and also makes money by allowing faster development and iterations.
There are plenty of examples here. I could point at how the PlayStation network just went down for 24 hours, or how UIs are often still very laggy and buggy, or I can also point at companies like Vercel that are (I assume) very valuable by providing a convenient and easy way to deploy applications... the fact that there are many SaaS out there providing convenience of development proves that this adds value. Despite this businesses are not having their engineers do this in-house because somehow they don't see the immediate ROI for their own business. I would just call that lack of vision or creativity at the business level, where you can't see the value of a well engineered system.
Businesses are free to run their company in whichever way they please, and they can create crappy software if it makes them money, but the point is that when this is industry-wide it cripples the evolution of software and this is then felt by everyone with downtimes and bad experiences, even though hardware is unbelievably fast and performant.
> Should game developers write a custom bespoke game engines and optimize them for each platform?
This is a good example actually. Most companies that want full creative control are making their own engines. The only exception here is Unreal (other smaller engines are not used by large companies), and from what I can tell the Unreal engine is an example of great software. This is one of those exceptions where engineers are actually doing engineering and the company probably can't afford to have them do something else. Many companies could benefit from this, but it's just not as straight line from the engineering to profit and that's kind of the root of why there is so much bad software out there.
Part of “meeting requirements” is always RTO, RPO, the availability requirements, latency, responsiveness, etc.
An alternative but dangerous approach is to make it known you’re looking elsewhere for work. Don’t do that if it’s relatively easy to replace you, and definitely assume the management thinks it’s easy to replace you, especialy if you haven’t been talking to your boss. ;) But there is the chance that they know you’re valuable and haven’t given you a raise because you seem content and they believe they have the upper hand - which may or may not be true.
When I left a company for increased compensation, which funny enough has only been 3x in almost 30 years across 10 jobs, it’s been between a 25%-60% raise. It’s almost impossible for any manager to push that kind of raise for anyone without a promotion.
Even at BigTech promotions usually come with lower raises than if you came in at that level.
Don’t do that if it’s relatively easy to replace you, and definitely assume the management thinks it’s easy to replace you, especialy if you haven’t been talking to your boss.
Everyone is replaceable. If you are at a company where everyone isn’t replaceable, it’s a poorly run company with a key man risk. I never saw any company outside of a one man company or professional practice where one person leaving was the end of the company.
Very true! Though isn’t it also normal in that case for HR to be recommending inflation raises at least? The exception might be if you came in at a salary that’s higher than your peer group and/or high for the title range. Parent’s problem could be that - either peer group correction or not possible for manager to raise at all without a promotion by company rules. There’s lots of reasons I can imagine, but in any case I wouldn’t expect a change with status quo, right? If you haven’t been talking to your boss, continuing to not talk to your boss is unlikely to change anything.
But yeah, the company should be doing at least inflation raises. A company only has at most two full review cycles to not get me somewhere in the range I think I should be making before I start looking for another job.
But I do understand that it is a shit show out here right now. I was looking for bog standard enterprise dev jobs with AWS experience as a “Plan B” while waiting for the “Plan A” interviews to work their way through. I have never seen anything like this in almost 30 years.
It was not this hard for me to get software developer job interviews in either 2000-2001 or 2008-2010. Admittedly, that’s partially because I was only looking for remote jobs and there the competition is fierce.
I'm sorry but I don't buy it.
I've been way too close way too often with lisp and Haskell or many other niches (I know well both Racket/Scheme and Haskell btw) the people that care that much about this correct and reliable and extensible software care about the code more than they care about the products.
That's why the languages that breed creativity and stress correctness have very little, if any, killer software to show when PHP/Java has tons of it.
First, hardware has improved consistently, outpacing any need for optimal software. Second, the end user does not know what they really want from software until it is provided to them, so most people will easily put up with slow, laggy and buggy software until there is a competitor that can provide a better experience. In other words, if companies can make money from making bad software, they will, and this is often what happens because most people don't know any different and also hardware becomes more and more powerful which alleviates and masks the defects in software.
I think there is also another big factor, which is that businesses prefer to scale by adding more people, rather than by making better software. Because they want to scale along human engineers, they tend to prefer low-tier software that is easy to pick up by the masses, rather than the high-level specialized software that is a hard skill to acquire. This is understandable, but is also the reason why software is so slow in advancing forward compared to hardware (and by the same token, hardware engineers require more specialization).