19 ms·

Software engineering salaries come from one of three budgets

536 points by serialx 3y ago

dbetteridge 3y ago
Background is completely white and text unreadable, toggling 'modes' fixes this but I presume its related to OSX and dark/light mode. Chrome Version 120.0.6099.109 (Official Build) (arm64)
DeathArrow 3y ago
What if you are one of the only few who know how to maintain a Cobol system for a bank? Aren't you very valuable?
- Nextgrid 3y ago
  There's nothing particularly difficult about Cobol, it can be learned, and with enough effort, all the undocumented existing code can be understood and reverse-engineered enough to be able to make changes. It's not pleasant work, but it's doable. If there was value in it, salaries/consulting rates would reflect it and people would be queuing up to learn it and make good money. That isn't happening, so it seems like Cobol devs aren't actually that valuable to these companies.
  - andyjohnson0 3y ago
    There was a comment on HN a while back to the effect that the well-known stories of COBOL devs being dragged out of retirement to earn massive consulting payments was a myth. They were actually being paid good, but not extremely good, rates for their knowledge of the business logic embedded in old code-bases. The implementation language was largely irrelevant.
- izacus 3y ago
  You're valuable in a way where everyone really wants to get rid of you and is planning hard on how to do that.
  - deleted 3y ago
    [deleted]
- w4tty 3y ago
  No. Because COBOL maintenance is outsourced to the third world.
  - vanderZwan 3y ago
    Do you seriously suggest that banks outsource the maintenance of the mainframes that process their money transfers? If so I'd like to see a source, because the only articles I have read about on this topic (e.g. [0]) tell me the exact opposite: it's all in-house the risks are too high. For larger banks it's practically a national security risk. Maybe the software they use is from abroad (usually ancient IBM shit), but that's not the same. [0] https://ezali.substack.com/p/interviewing-my-mother-a-mainframe https://ezali.substack.com/p/interviewing-my-mother-a-mainfr...
    - nijave 3y ago
      They don't "out source", they in-source by opening technology hubs in cheaper locations.
      - vanderZwan 3y ago
        Again, I would like to see a source. I'm not saying you're wrong. Maybe you're talking about small banks in the US or something, of which I know basically nothing. I am thinking of examples like Nordea, the bank in the article I linked, which has a market share of around 20% in Sweden[0] and handles the government's bank accounts. Especially that last part makes me extremely skeptical that the Swedish government would be OK with handing over the keys to their economic kingdom to cheap digital labor abroad so a company might save some money. [0] https://en.wikipedia.org/wiki/Nordea#History https://en.wikipedia.org/wiki/Nordea#History
        geodel 3y ago
        Well my brother worked in BNY Mellon India center. They have thousands of people and work core banking processing. BofA have their own India development center with thousands of employees. And this is outside of 10s of thousands outsourced to Tata, Infy etc. You think core banking process like transfers/ trading is some kinda crown jewel. It may be in terms of messaging but most of core IT part is just a cost center. Customer data and all need to be in their own secure data centers for legal reasons but all the processes can be designed, developed and executed from anywhere at lower cost.
- lifestyleguru 3y ago
  People get overly excited by some "last man standing" success stories of a COBOL developer based in US of A. My only encounter with COBOL developer was a freshly graduated girl based in post Communist country, her earnings were something around 25k EUR annually. I pointed out that her career might be something of a dead end but she was more like "a job is a job". Oh, and they were using some dinosaur version control as well.
  - ponector 3y ago
    I've seen a post on local job board in Poland, IBM was looking for junior cobol engineer. Any student with some java knowledge will fit, they said. I'm sure they will not pay anything more than 25k eur anually. Also if there is some legacy cobol system, many managers are incentivised to gather a new team to write a replacement with some modern technology stack. Cobol is definitely a dead end for the career.
    - lifestyleguru 3y ago
      > legacy cobol system, many managers are incentivised to gather a new team to write a replacement with some modern technology stack. Absolutely not in outsourcing centers like this. You're not supposed to show any initiative or god forbid - design anything. You grunt the COBOL until budget for the project is zero.
  - rgblambda 3y ago
    >her earnings were something around 25k EUR annually. That's a fairly good salary for a recent graduate in Eastern Europe. Although I admit it does illustrate your point that some legacy tech stacks are quite easy to pick up.
- chasd00 3y ago
  > What if you are one of the only few who know how to maintain a Cobol system for a bank? Aren't you very valuable? The bank would see the situation (only one person knows the Cobol system) an extreme risk and do whatever it takes to mitigate that risk. The short term answer is to keep you hired but the long term answer is to either find a steady supply of Cobol programmers or move away from Cobol to something where expertise is more available.
mooreds 3y ago
In addition to knowing which bucket your salary comes from, I think it is also useful to know how your organization values building software. Because this affects your career just as much. * Is your company selling software development hours (consulting)? I'm this car you'll be valued for client relations skills and the ability to bang out acceptable software. * Is your company selling a software product (product company)? In this case you'll be valued for your ability to build and run software. * Is your company selling something else that has a software component or that software enables (pretty much every other company)? In this case, you'll be valued for your ability to deliver on or below budget and you'll never be the star of the show. Funnily enough, these seem to map well to the three categories the author mentioned. Consulting to sales/marketing, product to research and development, everyone else to maintenance.
- zerr 3y ago
  > * Is your company selling a software product (product company) In the B2B world it is common to have a complex enough product that needs training services and tech support as well. Some vendors also add exams/certifications on top of it.
  - mooreds 3y ago
    That's fair, I was painting with a broad brush. Once you get to a certain size of consulting company, you may also have an r&d department or someone responsible for building common libraries or knowledge repositories, for example.
- Scarblac 3y ago
  Or a combination. I'm in a pretty small company (about 80 people total, 15 devs) and worked on all three of those last year.
  - mooreds 3y ago
    I'm a bit confused. You worked as a consultant selling hours, one a software product sold for a price and also on an internal enablement tool for the same company?
DeathArrow 3y ago
I think profit center vs cost center is a better model.
- vanderZwan 3y ago
  Why not combine them? Both give different insights that could complement each other, no?
  - verinus 3y ago
    But I think it has a lot to do with how profit is made: if you sell machinery for example that has a software part you are a cost factor, even if software is required to run it. Think of it as an in-house supplier that could even be outsourced. Not that I think it is feasible, but upper management does. And as long as they do, you won't rise far building software in such a company...
- joshka 3y ago
  This has been how I've usually define it too. I like the addition of the R+D section because I think a good Maintenance oriented team should be doing R+D related to bringing their maintenance costs down the same way a good sales team would be doing R+D to bring their sales profits up.
- LudwigNagasena 3y ago
  I think it’s a nonsensical model. Every department is ideally responsible for both revenues and costs. If you can’t measure it, it is a problem of your KPIs. So the KPIs may be cost-oriented (and thus badly aligned), it doesn’t make the department itself a cost center.
  - Kudos 3y ago
    Which department are you talking about? If your department doesn't drive revenue, then the business leaders will see it as a cost center. It doesn't matter if you disagree with that perspective unless you can change their minds. How have you done that in the past, or hypothetically how do you think that might work?
thiago_fm 3y ago
It doesn't matter where you work at, when layoffs come, the executives will care about location, timezones, desire on finishing the current project you are working on, (maybe) performance etc. There are too many criteria and no clear pointer on what is safe and what isn't. Being part of a layoff and also watching other colleagues coming from other Big Tech companies share their experiences, you'd see people laid off from literally everywhere: key projects, R&D (I was part of), sales, high-performing etc. It's a financial decision, the cut NEEDS to happen once the higher ups have decided and you can be cut, for you as an employee, anything can happen. Lots of R&D people end up being on the chopping block as well because you could be suddenly in a very promising project, but that the company no longer cares about, because some executive above even the boss of your boss told it isn't a priority.
- deleted 3y ago
  [deleted]
- vsnf 3y ago
  The higher up the org chat you report to is, the safer your position becomes. At one job, I reported directly to the still-reigning cofounder of a long lived company. Never have I felt a stronger sense of job security than that.
  - vasco 3y ago
    It's different security. Like in game of thrones in that scenario you're as safe as your boss is, which will depend on the evolving politics. Even founders get housted sometimes, but I'd agree that I'd choose your scenario over others.
    - gtirloni 3y ago
      I can totally attest to that. I once worked for a company where the CTO that was 3-4 levels above hired me directly and I reported to him. It felt very empowering and motivating because I was working on what he considered a critical area for the day-to-day of the company. Once he was gone, I suddenly was a huge problem to all the middle managers that disagreed with the CTO. If you happen to be in that situation, better to watch Game of Thrones (which I did only for entertainment not for work-related reasons). Ignore politics (like I did) at your own peril.
Guid_NewGuid 3y ago
Maybe someone who knows more about this stuff can enlighten me. From what I've heard there are actually only 2, opex and capex. If I recall correctly capex is better for the business because of how it gets treated in the accounting stuff. This naturally gives rise to the feature factory style work of a lot of dev jobs. Some reason like they can record capex spend as an asset with depreciation. Is this true?
- zer00eyz 3y ago
  This is close, there is more nuance to it, and a lot of it is going to be specific to your org. If you work in office, and there are accountants there go make friends. They are just another flavor of nerd, so you're gonna get along with them, and they have insights into the company that you will never get outside of the C level. IF you dont KNOW the answers to accounting questions, take some classes. Candidly this is a function of every business that engineers should be aware of! The projects that cost money upfront (OPEX) and can provably reduce recurring costs (CAPEX) can be HUGE wins for all involved. There is a story about how Dr's in the US have no idea what a procured costs, and that many non us ones do. Though the example is about insurance, I think the lack of awareness of costs is pervasive in more places. Do you know your AWS spend? Do you know the per customer cost/spend (is that individual or organization).... These numbers start to matter in a value engineering situation.
  - radiator 3y ago
    > The projects that cost money upfront (OPEX) and can provably reduce recurring costs (CAPEX) So you mean OPEX are upfront costs, and CAPEX are recurring costs?
    - marcosdumay 3y ago
      Yeah, whatever mistakes the GP did, those names are the other way around.
      - zer00eyz 3y ago
Mashimo 3y ago
All 3 actually. Depending on what task I work on. Sometimes the customers want a specific feature, sometimes we have an idea that we want to develop in the hopes of selling it later, and sometimes you need to work on maintenance. Which also gets paid by customers in our case.
a1o 3y ago
> Maintenance is always on the chopping block I wonder if someone or someplace figured a way to make software maintenance and support to be better valued. It's like, it's reasonably easy to market and sell internally the start of a project and consume from some internal investment (CapEx like) budget to make it, but once you have done all of that was in scope, you delivered, it's a lot harder to keep it going at the same steam and get budget for the continuous maintenance (OpEx like). Also, why it's so hard to get promotions or market work in good maintenance.
- deleted 3y ago
  [deleted]
- generic92034 3y ago
  Maintenance is instantly a good business case if you can sell maintenance and support contracts to your customers. Of course you will rarely find that in B2C areas, but in B2B it is not uncommon.
  - thfuran 3y ago
    Though that just kicks the can. We sell support contracts so everyone does a bunch of bug fixing as a matter of course, and that doesn't even get called maintenance internally. "Maintenance" is the refactoring or other tech debt quashing that the devs always want to do but which mostly isn't a priority.
    - generic92034 3y ago
      Where I am working bug fixing was always classified as maintenance work. That is even relevant for taxes, as ticket processing is a different category, with different tax rules.
  - ocimbote 3y ago
    Excellent point. I do Platform Engineering in a B2C business, our budget is very thin despite demonstrated the economy of scale provided by proper use of the platform.
deleted 3y ago
[deleted]
lp4vn 3y ago
The article cleverly groups the budget in three categories: - A first one that develops a product that creates a value for the company in the present(sales/marketing). - A second one that develops a product that will possibly create value for the company in the future(research/development). - And the last one that develops a product that created value for the company in the past and now has only to be maintained(maintenance). Honestly I think that this division is a bit tautological. Everybody in the industry knows that maintenance project are bad and only are worth it if you're making a good money working in them. Now in practice the hypothetical division between sales/marketing and research/development that the author proposes is pretty blurry and in my opinion doesn't do a great service in categorizing the activity of a developer.
zuhayeer 3y ago
Another framing of this is whether companies treat their engineering organizations as a cost center or a profit center. Cost centers suppress salaries as much as possible optimizing the budget. There's little growth within these companies which is why the zero-sum philosophy is passed down to their compensation strategy. Whereas profit centers encourage more and more investment as compounding profits come in from previous dividends. Growth is what powers everything, higher pay has a positive-sum gravitational pull on talent sustaining a flywheel for more profits to come in (hopefully). All the companies that pay very well such as on https://levels.fyi/2023/ https://levels.fyi/2023/ are profit centers encouraging investment in talent, competing for the best across companies because they know its worth it. Each hire even at extremely competitive wages will make back their salary manyfold if they're successful.
georgyo 3y ago
I don't understand our modern tech culture of saying maintenance is the last on the list; always getting chopped and cut; never getting a decent budget. In 20 years and several different companies I have always heard this but never agreed with it. Sure, the company wants new features to market, but the company also wants things to freaking work. During layoffs and hiring freezes I have seen SRE type orgs fair better than their R&D siblings. In only one place I worked was there this culture shift of always having to keep building new things and not reward maintaining old things. It actually shifted to that culture while I was there. Constant migration to new internal tools, constant depreciation, and half baked migration stories. After the people who built the product get their promotion they go off to the build their next portfolio piece. The new shiny quickly becomes unmaintained and a new team comes and builds yet another replacement. In 6 years one internally built tool was replaced 4 times with new internal tools, with users spread across all four. You can say that this was just poor execution, but in reality saying maintenance is not valued by the business is incredibly toxic and leads to self destruction.
- ponector 3y ago
  Both maintenance and testing are not valued by business. Because you cannot sell maintenance to the customer, you only can sell features. From the developer's point of view maintenance also a thing to avoid. You cannot put a maintenance as a shiny point to your CV. Everyone wants to see your achievements, projects you shipped, and with modern technology, of course.
  - generic92034 3y ago
    > Because you cannot sell maintenance to the customer, you only can sell features. That does not seem to be true in many B2B areas. Software suppliers are selling maintenance and support contracts to their customers. Think ERP.
    - ponector 3y ago
      Maintenance of your software. Can you sell bug fixing of your software? You can sell new features. Of course you will add a line to the contract about bug fixing, and put few poor souls occasionally to fix issues reported by vip customers, but it is not a selling point.
bux93 3y ago
"Sales & Marketing" and "Research & Development" are categorizations you may read about in companies' annual reports, but "Maintenance"? I'd suggest you read your company's financial statements. You'll find headings like "cost of revenue" or COGS, "General & Administrative" and others like one-off costs for mergers. All of these will have different dynamics, and in each company the dynamics may be different.
schnable 3y ago
I'm having trouble with this framing. The buckets only make sense metaphorically, but is written literally. The "laws" only make sense literally, too. For maintenance, if "you'll see this role smeared into product development" and "We give you a generous 2 days every sprint to take care of shit that's annoying," the budget here is R&D, not "Maintenance." Similarly, Growth and Developer Relation engineers are often (usually?) in the Product org. If these roles are actually in the R&D/Product Development budget, the "laws" about budget management don't apply cleanly enough that they can be a "law."
- jrochkind1 3y ago
  Right, I read that situation as they've gotten rid of "maintenance" budget altogether, because it was so de-valued -- you won't find any software engineering jobs actually attached to maintenance budget anymore in such an organization -- and now what maintenance is done is done in the margins of jobs whose primary purpose is R&D, attached to R&D budgets.
deleted 3y ago
[deleted]
Steven-Clarke 3y ago
Re: (US) Internal Revenue Code (IRC) Section 174 "The Tax Cuts and Jobs Act was enacted more than five years ago, but certain changes under the legislation are only now coming into focus as taxpayers prepare their 2022 tax returns. In particular, there are significant changes as to the deductibility of certain research and experimentation expenses, as well as the ability to utilize net operating loss (NOL) carryforwards. These changes may result in greater tax liabilities for companies and may also affect certain qualified small business stock eligibility requirements". ref/ https://www.cooley.com/news/insight/2023/2023-04-28-startups-rd-heavy-companies-higher-tax-2022 https://www.cooley.com/news/insight/2023/2023-04-28-startups...
- ttyprintk 3y ago
  Software development costs now must be amortized. https://news.ycombinator.com/item?id=38698457 https://news.ycombinator.com/item?id=38698457
physicsguy 3y ago
The only orgs I’ve not had mad stress have been research oriented, with the expectation that some things will pan out and others won’t.
SamuelAdams 3y ago
I really like this, but patio11’s blog does a nice job as well. He breaks it down into cost centers and profit centers, and argues why you really want to be attached to a profit center. Lots of other good stuff in here if you haven’t read it. https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
- shermantanktop 3y ago
  That’s my #1 rule; go (and stay) where there is either profit or a realistic path to profit. Rule #2 is to play a role within that profit center which can be credibly linked to continued profitability. It doesn’t have to be directly making money, but it should be clear why the money will be directly impacted if I stop doing my job.
hellectronic 3y ago
Sounds like the Gartner RGT model https://www.gartner.com/smarterwithgartner/align-it-functions-with-business-strategy-using-the-run-grow-transform-model https://www.gartner.com/smarterwithgartner/align-it-function...
jpswade 3y ago
Historically software engineering was part of the IT function, which historically was born out of accounting, a computer literally was someone’s job, before a machine could do it. Today, for many businesses accounts is still the main driver behind software, and also the budget.
ConnorMooneyhan 3y ago
I'm in sales/marketing; bored out of my mind, so I'm studying to be in R&D.
scarface_74 3y ago
Amazon: “we can build S3 - a service that millions use with no down time. But we can’t build a simple website to serve our internal employees come review time in April”
scarface_74 3y ago
> Building internal tools can fall into this category. That unloved admin dashboard that runs the company but never quite gets priority. Amazon: “we can build S3 - a service that millions use with no down time. But we can’t keep a simple website up to serve our internal employees come review time in April”
chrisweekly 3y ago
Tangent: Swizec authored a book I found very useful a few years ago ("Serverless Handbook"), and writes a thoughtful and insightful email newsletter I've enjoyed for many years. He's firmly in the "learn by doing / learn in public" camp, and does an excellent job sharing what he learns along the way. Highly recommended follow / subscribe.
throwawaaarrgh 3y ago
Sales/marketing don't even exist when a product is first being built, but you're getting paid... but your salary isn't R&D. The pace isn't calm. The stakes are high. The target can pivot violently. Your salary is coming from the Business Plan's Capital Expenditure, as part of an initial round of investment needed to achieve the Business Goals. This is a marked difference from Operational Expenditure, which "Maintenance" is most often lumped under. Whether your salary is CapEx or OpEx has a much larger impact on your ability to work freely and productively than what of these 3 (really 4) categories are.
- prepend 3y ago
  I think a better way to think is as product development. Sales and marketing exist from the beginning even though nothing is being sold yet.
prepend 3y ago
I remember early advice in my career to always work for a revenue center not a cost center. This was really helpful as having something that makes a firm money seems more easy to measure impact than a cost center. The natural incentives seem to jive better. Revenue centers are supposed to increase and are a function of margin. So more salaries and expenses should lead to more revenue. Cost centers are supposed to decrease or stay the same. So always a pressure to cut expenses.
paxys 3y ago
No company I have ever worked for has had growth engineering salaries come out of the marketing budget. And there's no such thing as a "maintenance" budget either. It is all simply R&D/engineering. Sure the expectations are very different depending on your team/role, but that's not a budget thing, and depends on how the company tracks its goals.
- SkyPuncher 3y ago
  These budgets aren't often labelled as explicitly as the article states, but I've found they're generally accurate. You either make money now (sales), you build long term value (product), or are circling the drain (maintenance) on an existing product.
- paradite 3y ago
  I think the budget is used figuratively here to mean where your contribution / value-add to the company is.
osigurdson 3y ago
As an aside, it seems that the $500K/year jobs have dried up - at least I don't see much of that on the "Who's hiring". Salary ranges seem to be more in the $100K - $200K range.
- angarg12 3y ago
  I'm in FAANG making close to that, and I have been testing the market for a few months. I found less than a handful of companies that could beat my current comp. The vast majority of companies I've talked to seem to top around 250k even for Staff+ roles. The author says that EU ain't no Silicon Valley, but 2024 sure ain't no 2022.
- closeparen 3y ago
  These compensation packages served the very specific purpose of enticing US-based talent to relocate to the Bay Area. As we increasingly accept remote work for senior talent and look abroad (or not at all) for junior talent, this is not as much of a need anymore. The inflow to the Bay Area always had a built-in expiration given there are only finitely many neighborhoods to gentrify and still no appetite for significant housing growth.
  - killjoywashere 3y ago
    It's also self-inflicted pain: if you keep inflating wages you keep inflating home prices, which makes it even harder to attract people in. Google is doing everything it can to cut costs, closing daycares, tracking who eats, but they have literally acres of empty, brand-new real estate. I suspect another round of layoffs may be coming. And I doubt they'll do the "random selection" again. The smart ones at the fringes started bolting for the doors in December.
- __turbobrew__ 3y ago
  I think the ceiling is still there where if you have special hard to find skills (ML and distributed systems at my company) you can still command that salary but if you are just writing crud apps nobody is going to pay you half a mil per year anymore.
irrational 3y ago
What about HR? HR Tech is not working on software to create new products (research and development) or on software to sell said products to other people (sales/marketing), but it also isn't maintenance.
- patja 3y ago
  The whole blog post is very tech company product oriented and seems almost completely oblivious to the vast number of software engineers building line of business applications for internal use, under the COO's budget.
- OJFord 3y ago
  Maintenance is a bad word for it, but the author clearly intends it to be in that category: > Building internal tools can fall into this category.
uticus 3y ago
Very closely related, this comes up on HN from time to time: "Don't Call Yourself A Programmer, And Other Career Advice" https://news.ycombinator.com/item?id=3170766 https://news.ycombinator.com/item?id=3170766
indymike 3y ago
There are actually four buckets: 1. Research and Development. Special tax treatment and tax credits usually apply to R&D. 2. Sales/Marketing - Pre-sale sales engineers, sometimes implementations 3. Maintenance. Developers that fix bugs and perform non-R&D work on code that usually isn’t eligible for special tax treatment or credits. 4. In hosted services/PaaS/SaaS, operations usually carry some level of swe salaries. Understanding the tax implications of which budget and what work is being done is really important, and gets much more complex as you grow.
- MichaelZuo 3y ago
  There's also a fifth bucket for really large companies and really high end engineers: 5. CEO/COO/CTO's special budget for special consultants
phkahler 3y ago
>> You're only as good as the multiplier a company gets on pouring money into your bucket. Well that's why some places have sales people on commission. You set a fixed multiplier and let the sales person do their thing. You can still offer bonuses, but if one guy makes half the sales as another so what? He automatically gets paid half as much. Software supporting multiple sales people isn't so individualized though.
GCA10 3y ago
The analysis of maintenance budgets is depressingly accurate. Especially as tech companies get older (and they age surprisingly fast), it's quite startling to see how most of them become organizationally indifferent to various small to medium glitches in established products. I can see why a lot of people working in tech will focus weekend/break energy on side projects (woodworking; solo sports; playing in a band) where exquisite craft is everything.
tonymet 3y ago
It's also important to understand the business of the industry that you are in. Many are judgmental (even within this thread) of some companies not "valuing" software engineering. It's naive to compare social media companies that are making 70% topline margins to auto or airlines companies that are making ~ 15-20% . Of course one industry can hire more engineers, pay them better, give them more swag & benefits. Even within companies, some product lines and functions will be receiving long term investment. Some product lines may be higher margin than others. There will be a big difference in the money available for software products depending on the budget. I encourage engineers to consider their business' finances when thinking about their job. The company is not a charity or a church -- it's a business with cash flow, revenue & a long term strategy that all has to be balanced with the cost of building the product.
giantg2 3y ago
My salary comes from Arachis hypogaea.
shadowgovt 3y ago
It's important I think to note the head fake that Google's engineering pulled off when they developed site reliability as its own discipline. It's maintenance, but the argument they successfully sold to management was that if management planned to scale indefinitely, maintenance cost would also scale indefinitely unless maintenance also had a budget for R&D to push up the ratio of services maintained to maintainers (and the authority to tell software engineering "Yes, you built a new shiny thing, but it's not shaped correctly yet to be maintainable so here is the pager, enjoy your 2:00 a.m. wake up calls to keep the money flowing"). This has, overall, worked pretty well for them given what they want to do. While maintenance is still a cost, it's understood that they minimize that cost via R&D, not cutting.
realjohng 3y ago
Lol! “ We give you a generous 2 days every sprint to take care of shit that's annoying! Why aren't you happy!??"
rutharcher655 3y ago
[dead]
lucasyvas 3y ago
I disagree with the absolute framing of 2 and 3. They're not wrong takes, but they're highly dependent on the company stage. For 2, it's a feature factory below a certain size or market penetration. You will be valuable but you will be anything but calm and relaxed. Research doesn't qualify, talking about Product here. 3, which is Platform and/or maintenance is definitely unsexy until you are a scale up and your software sucks ass since you never maintained it and no amount of infrastructure can save it. Then to grow you become extremely important. I think you want to consider the company size, the state of the product, and its market fit before making these assertions. All three are the best and worst jobs to have, it just depends when and where you are.
jsdwarf 3y ago
One word of warning about the cozy R&D department of a product org: you may suffer from the boiling frog syndrome. Little attrition and long-time continuity means everybody stays in their seat and there a few true career opportunities beyond seniority promotions (dev - senior dev etc). After 5-10 years you find yourself quickly at the end of your promotion trajectory and realize that much younger/cheaper folks have the same role as you. This puts you at a disadvantage in salary negotiations and increases the risk of being let go. Project-driven orgs can be brutal environments, but there is always a possibility to climb up the ladder due to high churn.

536 points by serialx 3y ago

Background is completely white and text unreadable, toggling 'modes' fixes this but I presume its related to OSX and dark/light mode. Chrome Version 120.0.6099.109 (Official Build) (arm64)

DeathArrow 3y ago

What if you are one of the only few who know how to maintain a Cobol system for a bank? Aren't you very valuable?

Nextgrid 3y ago
There's nothing particularly difficult about Cobol, it can be learned, and with enough effort, all the undocumented existing code can be understood and reverse-engineered enough to be able to make changes. It's not pleasant work, but it's doable. If there was value in it, salaries/consulting rates would reflect it and people would be queuing up to learn it and make good money. That isn't happening, so it seems like Cobol devs aren't actually that valuable to these companies.
- andyjohnson0 3y ago
  There was a comment on HN a while back to the effect that the well-known stories of COBOL devs being dragged out of retirement to earn massive consulting payments was a myth. They were actually being paid good, but not extremely good, rates for their knowledge of the business logic embedded in old code-bases. The implementation language was largely irrelevant.
izacus 3y ago
You're valuable in a way where everyone really wants to get rid of you and is planning hard on how to do that.
- deleted 3y ago
  [deleted]
w4tty 3y ago
No. Because COBOL maintenance is outsourced to the third world.
- vanderZwan 3y ago
  Do you seriously suggest that banks outsource the maintenance of the mainframes that process their money transfers? If so I'd like to see a source, because the only articles I have read about on this topic (e.g. [0]) tell me the exact opposite: it's all in-house the risks are too high. For larger banks it's practically a national security risk. Maybe the software they use is from abroad (usually ancient IBM shit), but that's not the same. [0] https://ezali.substack.com/p/interviewing-my-mother-a-mainframe https://ezali.substack.com/p/interviewing-my-mother-a-mainfr...
  - nijave 3y ago
    They don't "out source", they in-source by opening technology hubs in cheaper locations.
    - vanderZwan 3y ago
      Again, I would like to see a source. I'm not saying you're wrong. Maybe you're talking about small banks in the US or something, of which I know basically nothing. I am thinking of examples like Nordea, the bank in the article I linked, which has a market share of around 20% in Sweden[0] and handles the government's bank accounts. Especially that last part makes me extremely skeptical that the Swedish government would be OK with handing over the keys to their economic kingdom to cheap digital labor abroad so a company might save some money. [0] https://en.wikipedia.org/wiki/Nordea#History https://en.wikipedia.org/wiki/Nordea#History
      - geodel 3y ago
        Well my brother worked in BNY Mellon India center. They have thousands of people and work core banking processing. BofA have their own India development center with thousands of employees. And this is outside of 10s of thousands outsourced to Tata, Infy etc. You think core banking process like transfers/ trading is some kinda crown jewel. It may be in terms of messaging but most of core IT part is just a cost center. Customer data and all need to be in their own secure data centers for legal reasons but all the processes can be designed, developed and executed from anywhere at lower cost.
lifestyleguru 3y ago
People get overly excited by some "last man standing" success stories of a COBOL developer based in US of A. My only encounter with COBOL developer was a freshly graduated girl based in post Communist country, her earnings were something around 25k EUR annually. I pointed out that her career might be something of a dead end but she was more like "a job is a job". Oh, and they were using some dinosaur version control as well.
- ponector 3y ago
  I've seen a post on local job board in Poland, IBM was looking for junior cobol engineer. Any student with some java knowledge will fit, they said. I'm sure they will not pay anything more than 25k eur anually. Also if there is some legacy cobol system, many managers are incentivised to gather a new team to write a replacement with some modern technology stack. Cobol is definitely a dead end for the career.
  - lifestyleguru 3y ago
    > legacy cobol system, many managers are incentivised to gather a new team to write a replacement with some modern technology stack. Absolutely not in outsourcing centers like this. You're not supposed to show any initiative or god forbid - design anything. You grunt the COBOL until budget for the project is zero.
- rgblambda 3y ago
  >her earnings were something around 25k EUR annually. That's a fairly good salary for a recent graduate in Eastern Europe. Although I admit it does illustrate your point that some legacy tech stacks are quite easy to pick up.
chasd00 3y ago
> What if you are one of the only few who know how to maintain a Cobol system for a bank? Aren't you very valuable? The bank would see the situation (only one person knows the Cobol system) an extreme risk and do whatever it takes to mitigate that risk. The short term answer is to keep you hired but the long term answer is to either find a steady supply of Cobol programmers or move away from Cobol to something where expertise is more available.

mooreds 3y ago

In addition to knowing which bucket your salary comes from, I think it is also useful to know how your organization values building software. Because this affects your career just as much. * Is your company selling software development hours (consulting)? I'm this car you'll be valued for client relations skills and the ability to bang out acceptable software. * Is your company selling a software product (product company)? In this case you'll be valued for your ability to build and run software. * Is your company selling something else that has a software component or that software enables (pretty much every other company)? In this case, you'll be valued for your ability to deliver on or below budget and you'll never be the star of the show. Funnily enough, these seem to map well to the three categories the author mentioned. Consulting to sales/marketing, product to research and development, everyone else to maintenance.

zerr 3y ago
> * Is your company selling a software product (product company) In the B2B world it is common to have a complex enough product that needs training services and tech support as well. Some vendors also add exams/certifications on top of it.
- mooreds 3y ago
  That's fair, I was painting with a broad brush. Once you get to a certain size of consulting company, you may also have an r&d department or someone responsible for building common libraries or knowledge repositories, for example.
Scarblac 3y ago
Or a combination. I'm in a pretty small company (about 80 people total, 15 devs) and worked on all three of those last year.
- mooreds 3y ago
  I'm a bit confused. You worked as a consultant selling hours, one a software product sold for a price and also on an internal enablement tool for the same company?

DeathArrow 3y ago

I think profit center vs cost center is a better model.

vanderZwan 3y ago
Why not combine them? Both give different insights that could complement each other, no?
- verinus 3y ago
  But I think it has a lot to do with how profit is made: if you sell machinery for example that has a software part you are a cost factor, even if software is required to run it. Think of it as an in-house supplier that could even be outsourced. Not that I think it is feasible, but upper management does. And as long as they do, you won't rise far building software in such a company...
joshka 3y ago
This has been how I've usually define it too. I like the addition of the R+D section because I think a good Maintenance oriented team should be doing R+D related to bringing their maintenance costs down the same way a good sales team would be doing R+D to bring their sales profits up.
LudwigNagasena 3y ago
I think it’s a nonsensical model. Every department is ideally responsible for both revenues and costs. If you can’t measure it, it is a problem of your KPIs. So the KPIs may be cost-oriented (and thus badly aligned), it doesn’t make the department itself a cost center.
- Kudos 3y ago
  Which department are you talking about? If your department doesn't drive revenue, then the business leaders will see it as a cost center. It doesn't matter if you disagree with that perspective unless you can change their minds. How have you done that in the past, or hypothetically how do you think that might work?

thiago_fm 3y ago

It doesn't matter where you work at, when layoffs come, the executives will care about location, timezones, desire on finishing the current project you are working on, (maybe) performance etc. There are too many criteria and no clear pointer on what is safe and what isn't. Being part of a layoff and also watching other colleagues coming from other Big Tech companies share their experiences, you'd see people laid off from literally everywhere: key projects, R&D (I was part of), sales, high-performing etc. It's a financial decision, the cut NEEDS to happen once the higher ups have decided and you can be cut, for you as an employee, anything can happen. Lots of R&D people end up being on the chopping block as well because you could be suddenly in a very promising project, but that the company no longer cares about, because some executive above even the boss of your boss told it isn't a priority.

deleted 3y ago
[deleted]
vsnf 3y ago
The higher up the org chat you report to is, the safer your position becomes. At one job, I reported directly to the still-reigning cofounder of a long lived company. Never have I felt a stronger sense of job security than that.
- vasco 3y ago
  It's different security. Like in game of thrones in that scenario you're as safe as your boss is, which will depend on the evolving politics. Even founders get housted sometimes, but I'd agree that I'd choose your scenario over others.
  - gtirloni 3y ago
    I can totally attest to that. I once worked for a company where the CTO that was 3-4 levels above hired me directly and I reported to him. It felt very empowering and motivating because I was working on what he considered a critical area for the day-to-day of the company. Once he was gone, I suddenly was a huge problem to all the middle managers that disagreed with the CTO. If you happen to be in that situation, better to watch Game of Thrones (which I did only for entertainment not for work-related reasons). Ignore politics (like I did) at your own peril.

Guid_NewGuid 3y ago

Maybe someone who knows more about this stuff can enlighten me. From what I've heard there are actually only 2, opex and capex. If I recall correctly capex is better for the business because of how it gets treated in the accounting stuff. This naturally gives rise to the feature factory style work of a lot of dev jobs. Some reason like they can record capex spend as an asset with depreciation. Is this true?

zer00eyz 3y ago
This is close, there is more nuance to it, and a lot of it is going to be specific to your org. If you work in office, and there are accountants there go make friends. They are just another flavor of nerd, so you're gonna get along with them, and they have insights into the company that you will never get outside of the C level. IF you dont KNOW the answers to accounting questions, take some classes. Candidly this is a function of every business that engineers should be aware of! The projects that cost money upfront (OPEX) and can provably reduce recurring costs (CAPEX) can be HUGE wins for all involved. There is a story about how Dr's in the US have no idea what a procured costs, and that many non us ones do. Though the example is about insurance, I think the lack of awareness of costs is pervasive in more places. Do you know your AWS spend? Do you know the per customer cost/spend (is that individual or organization).... These numbers start to matter in a value engineering situation.
- radiator 3y ago
  > The projects that cost money upfront (OPEX) and can provably reduce recurring costs (CAPEX) So you mean OPEX are upfront costs, and CAPEX are recurring costs?
  - marcosdumay 3y ago
    Yeah, whatever mistakes the GP did, those names are the other way around.
    - zer00eyz 3y ago

Mashimo 3y ago

All 3 actually. Depending on what task I work on. Sometimes the customers want a specific feature, sometimes we have an idea that we want to develop in the hopes of selling it later, and sometimes you need to work on maintenance. Which also gets paid by customers in our case.

a1o 3y ago

> Maintenance is always on the chopping block I wonder if someone or someplace figured a way to make software maintenance and support to be better valued. It's like, it's reasonably easy to market and sell internally the start of a project and consume from some internal investment (CapEx like) budget to make it, but once you have done all of that was in scope, you delivered, it's a lot harder to keep it going at the same steam and get budget for the continuous maintenance (OpEx like). Also, why it's so hard to get promotions or market work in good maintenance.

deleted 3y ago
[deleted]
generic92034 3y ago
Maintenance is instantly a good business case if you can sell maintenance and support contracts to your customers. Of course you will rarely find that in B2C areas, but in B2B it is not uncommon.
- thfuran 3y ago
  Though that just kicks the can. We sell support contracts so everyone does a bunch of bug fixing as a matter of course, and that doesn't even get called maintenance internally. "Maintenance" is the refactoring or other tech debt quashing that the devs always want to do but which mostly isn't a priority.
  - generic92034 3y ago
    Where I am working bug fixing was always classified as maintenance work. That is even relevant for taxes, as ticket processing is a different category, with different tax rules.
- ocimbote 3y ago
  Excellent point. I do Platform Engineering in a B2C business, our budget is very thin despite demonstrated the economy of scale provided by proper use of the platform.

deleted 3y ago

[deleted]

lp4vn 3y ago

The article cleverly groups the budget in three categories: - A first one that develops a product that creates a value for the company in the present(sales/marketing). - A second one that develops a product that will possibly create value for the company in the future(research/development). - And the last one that develops a product that created value for the company in the past and now has only to be maintained(maintenance). Honestly I think that this division is a bit tautological. Everybody in the industry knows that maintenance project are bad and only are worth it if you're making a good money working in them. Now in practice the hypothetical division between sales/marketing and research/development that the author proposes is pretty blurry and in my opinion doesn't do a great service in categorizing the activity of a developer.

zuhayeer 3y ago

Another framing of this is whether companies treat their engineering organizations as a cost center or a profit center. Cost centers suppress salaries as much as possible optimizing the budget. There's little growth within these companies which is why the zero-sum philosophy is passed down to their compensation strategy. Whereas profit centers encourage more and more investment as compounding profits come in from previous dividends. Growth is what powers everything, higher pay has a positive-sum gravitational pull on talent sustaining a flywheel for more profits to come in (hopefully). All the companies that pay very well such as on https://levels.fyi/2023/ https://levels.fyi/2023/ are profit centers encouraging investment in talent, competing for the best across companies because they know its worth it. Each hire even at extremely competitive wages will make back their salary manyfold if they're successful.

georgyo 3y ago

I don't understand our modern tech culture of saying maintenance is the last on the list; always getting chopped and cut; never getting a decent budget. In 20 years and several different companies I have always heard this but never agreed with it. Sure, the company wants new features to market, but the company also wants things to freaking work. During layoffs and hiring freezes I have seen SRE type orgs fair better than their R&D siblings. In only one place I worked was there this culture shift of always having to keep building new things and not reward maintaining old things. It actually shifted to that culture while I was there. Constant migration to new internal tools, constant depreciation, and half baked migration stories. After the people who built the product get their promotion they go off to the build their next portfolio piece. The new shiny quickly becomes unmaintained and a new team comes and builds yet another replacement. In 6 years one internally built tool was replaced 4 times with new internal tools, with users spread across all four. You can say that this was just poor execution, but in reality saying maintenance is not valued by the business is incredibly toxic and leads to self destruction.

ponector 3y ago
Both maintenance and testing are not valued by business. Because you cannot sell maintenance to the customer, you only can sell features. From the developer's point of view maintenance also a thing to avoid. You cannot put a maintenance as a shiny point to your CV. Everyone wants to see your achievements, projects you shipped, and with modern technology, of course.
- generic92034 3y ago
  > Because you cannot sell maintenance to the customer, you only can sell features. That does not seem to be true in many B2B areas. Software suppliers are selling maintenance and support contracts to their customers. Think ERP.
  - ponector 3y ago
    Maintenance of your software. Can you sell bug fixing of your software? You can sell new features. Of course you will add a line to the contract about bug fixing, and put few poor souls occasionally to fix issues reported by vip customers, but it is not a selling point.

bux93 3y ago

"Sales & Marketing" and "Research & Development" are categorizations you may read about in companies' annual reports, but "Maintenance"? I'd suggest you read your company's financial statements. You'll find headings like "cost of revenue" or COGS, "General & Administrative" and others like one-off costs for mergers. All of these will have different dynamics, and in each company the dynamics may be different.

schnable 3y ago

I'm having trouble with this framing. The buckets only make sense metaphorically, but is written literally. The "laws" only make sense literally, too. For maintenance, if "you'll see this role smeared into product development" and "We give you a generous 2 days every sprint to take care of shit that's annoying," the budget here is R&D, not "Maintenance." Similarly, Growth and Developer Relation engineers are often (usually?) in the Product org. If these roles are actually in the R&D/Product Development budget, the "laws" about budget management don't apply cleanly enough that they can be a "law."

jrochkind1 3y ago
Right, I read that situation as they've gotten rid of "maintenance" budget altogether, because it was so de-valued -- you won't find any software engineering jobs actually attached to maintenance budget anymore in such an organization -- and now what maintenance is done is done in the margins of jobs whose primary purpose is R&D, attached to R&D budgets.

deleted 3y ago

[deleted]

Steven-Clarke 3y ago

Re: (US) Internal Revenue Code (IRC) Section 174 "The Tax Cuts and Jobs Act was enacted more than five years ago, but certain changes under the legislation are only now coming into focus as taxpayers prepare their 2022 tax returns. In particular, there are significant changes as to the deductibility of certain research and experimentation expenses, as well as the ability to utilize net operating loss (NOL) carryforwards. These changes may result in greater tax liabilities for companies and may also affect certain qualified small business stock eligibility requirements". ref/ https://www.cooley.com/news/insight/2023/2023-04-28-startups-rd-heavy-companies-higher-tax-2022 https://www.cooley.com/news/insight/2023/2023-04-28-startups...

ttyprintk 3y ago
Software development costs now must be amortized. https://news.ycombinator.com/item?id=38698457 https://news.ycombinator.com/item?id=38698457

physicsguy 3y ago

The only orgs I’ve not had mad stress have been research oriented, with the expectation that some things will pan out and others won’t.

SamuelAdams 3y ago

I really like this, but patio11’s blog does a nice job as well. He breaks it down into cost centers and profit centers, and argues why you really want to be attached to a profit center. Lots of other good stuff in here if you haven’t read it. https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

shermantanktop 3y ago
That’s my #1 rule; go (and stay) where there is either profit or a realistic path to profit. Rule #2 is to play a role within that profit center which can be credibly linked to continued profitability. It doesn’t have to be directly making money, but it should be clear why the money will be directly impacted if I stop doing my job.

hellectronic 3y ago

Sounds like the Gartner RGT model https://www.gartner.com/smarterwithgartner/align-it-functions-with-business-strategy-using-the-run-grow-transform-model https://www.gartner.com/smarterwithgartner/align-it-function...

jpswade 3y ago

Historically software engineering was part of the IT function, which historically was born out of accounting, a computer literally was someone’s job, before a machine could do it. Today, for many businesses accounts is still the main driver behind software, and also the budget.

ConnorMooneyhan 3y ago

I'm in sales/marketing; bored out of my mind, so I'm studying to be in R&D.

scarface_74 3y ago

Amazon: “we can build S3 - a service that millions use with no down time. But we can’t build a simple website to serve our internal employees come review time in April”

scarface_74 3y ago

> Building internal tools can fall into this category. That unloved admin dashboard that runs the company but never quite gets priority. Amazon: “we can build S3 - a service that millions use with no down time. But we can’t keep a simple website up to serve our internal employees come review time in April”

chrisweekly 3y ago

Tangent: Swizec authored a book I found very useful a few years ago ("Serverless Handbook"), and writes a thoughtful and insightful email newsletter I've enjoyed for many years. He's firmly in the "learn by doing / learn in public" camp, and does an excellent job sharing what he learns along the way. Highly recommended follow / subscribe.

throwawaaarrgh 3y ago

Sales/marketing don't even exist when a product is first being built, but you're getting paid... but your salary isn't R&D. The pace isn't calm. The stakes are high. The target can pivot violently. Your salary is coming from the Business Plan's Capital Expenditure, as part of an initial round of investment needed to achieve the Business Goals. This is a marked difference from Operational Expenditure, which "Maintenance" is most often lumped under. Whether your salary is CapEx or OpEx has a much larger impact on your ability to work freely and productively than what of these 3 (really 4) categories are.

prepend 3y ago
I think a better way to think is as product development. Sales and marketing exist from the beginning even though nothing is being sold yet.

prepend 3y ago

I remember early advice in my career to always work for a revenue center not a cost center. This was really helpful as having something that makes a firm money seems more easy to measure impact than a cost center. The natural incentives seem to jive better. Revenue centers are supposed to increase and are a function of margin. So more salaries and expenses should lead to more revenue. Cost centers are supposed to decrease or stay the same. So always a pressure to cut expenses.

paxys 3y ago

No company I have ever worked for has had growth engineering salaries come out of the marketing budget. And there's no such thing as a "maintenance" budget either. It is all simply R&D/engineering. Sure the expectations are very different depending on your team/role, but that's not a budget thing, and depends on how the company tracks its goals.

SkyPuncher 3y ago
These budgets aren't often labelled as explicitly as the article states, but I've found they're generally accurate. You either make money now (sales), you build long term value (product), or are circling the drain (maintenance) on an existing product.
paradite 3y ago
I think the budget is used figuratively here to mean where your contribution / value-add to the company is.

osigurdson 3y ago

As an aside, it seems that the $500K/year jobs have dried up - at least I don't see much of that on the "Who's hiring". Salary ranges seem to be more in the $100K - $200K range.

angarg12 3y ago
I'm in FAANG making close to that, and I have been testing the market for a few months. I found less than a handful of companies that could beat my current comp. The vast majority of companies I've talked to seem to top around 250k even for Staff+ roles. The author says that EU ain't no Silicon Valley, but 2024 sure ain't no 2022.
closeparen 3y ago
These compensation packages served the very specific purpose of enticing US-based talent to relocate to the Bay Area. As we increasingly accept remote work for senior talent and look abroad (or not at all) for junior talent, this is not as much of a need anymore. The inflow to the Bay Area always had a built-in expiration given there are only finitely many neighborhoods to gentrify and still no appetite for significant housing growth.
- killjoywashere 3y ago
  It's also self-inflicted pain: if you keep inflating wages you keep inflating home prices, which makes it even harder to attract people in. Google is doing everything it can to cut costs, closing daycares, tracking who eats, but they have literally acres of empty, brand-new real estate. I suspect another round of layoffs may be coming. And I doubt they'll do the "random selection" again. The smart ones at the fringes started bolting for the doors in December.
__turbobrew__ 3y ago
I think the ceiling is still there where if you have special hard to find skills (ML and distributed systems at my company) you can still command that salary but if you are just writing crud apps nobody is going to pay you half a mil per year anymore.

irrational 3y ago

What about HR? HR Tech is not working on software to create new products (research and development) or on software to sell said products to other people (sales/marketing), but it also isn't maintenance.

patja 3y ago
The whole blog post is very tech company product oriented and seems almost completely oblivious to the vast number of software engineers building line of business applications for internal use, under the COO's budget.
OJFord 3y ago
Maintenance is a bad word for it, but the author clearly intends it to be in that category: > Building internal tools can fall into this category.

uticus 3y ago

Very closely related, this comes up on HN from time to time: "Don't Call Yourself A Programmer, And Other Career Advice" https://news.ycombinator.com/item?id=3170766 https://news.ycombinator.com/item?id=3170766

indymike 3y ago

There are actually four buckets: 1. Research and Development. Special tax treatment and tax credits usually apply to R&D. 2. Sales/Marketing - Pre-sale sales engineers, sometimes implementations 3. Maintenance. Developers that fix bugs and perform non-R&D work on code that usually isn’t eligible for special tax treatment or credits. 4. In hosted services/PaaS/SaaS, operations usually carry some level of swe salaries. Understanding the tax implications of which budget and what work is being done is really important, and gets much more complex as you grow.

MichaelZuo 3y ago
There's also a fifth bucket for really large companies and really high end engineers: 5. CEO/COO/CTO's special budget for special consultants

phkahler 3y ago

>> You're only as good as the multiplier a company gets on pouring money into your bucket. Well that's why some places have sales people on commission. You set a fixed multiplier and let the sales person do their thing. You can still offer bonuses, but if one guy makes half the sales as another so what? He automatically gets paid half as much. Software supporting multiple sales people isn't so individualized though.

GCA10 3y ago

The analysis of maintenance budgets is depressingly accurate. Especially as tech companies get older (and they age surprisingly fast), it's quite startling to see how most of them become organizationally indifferent to various small to medium glitches in established products. I can see why a lot of people working in tech will focus weekend/break energy on side projects (woodworking; solo sports; playing in a band) where exquisite craft is everything.

tonymet 3y ago

It's also important to understand the business of the industry that you are in. Many are judgmental (even within this thread) of some companies not "valuing" software engineering. It's naive to compare social media companies that are making 70% topline margins to auto or airlines companies that are making ~ 15-20% . Of course one industry can hire more engineers, pay them better, give them more swag & benefits. Even within companies, some product lines and functions will be receiving long term investment. Some product lines may be higher margin than others. There will be a big difference in the money available for software products depending on the budget. I encourage engineers to consider their business' finances when thinking about their job. The company is not a charity or a church -- it's a business with cash flow, revenue & a long term strategy that all has to be balanced with the cost of building the product.

giantg2 3y ago

My salary comes from Arachis hypogaea.

shadowgovt 3y ago

It's important I think to note the head fake that Google's engineering pulled off when they developed site reliability as its own discipline. It's maintenance, but the argument they successfully sold to management was that if management planned to scale indefinitely, maintenance cost would also scale indefinitely unless maintenance also had a budget for R&D to push up the ratio of services maintained to maintainers (and the authority to tell software engineering "Yes, you built a new shiny thing, but it's not shaped correctly yet to be maintainable so here is the pager, enjoy your 2:00 a.m. wake up calls to keep the money flowing"). This has, overall, worked pretty well for them given what they want to do. While maintenance is still a cost, it's understood that they minimize that cost via R&D, not cutting.

realjohng 3y ago

Lol! “ We give you a generous 2 days every sprint to take care of shit that's annoying! Why aren't you happy!??"

rutharcher655 3y ago

[dead]

lucasyvas 3y ago

I disagree with the absolute framing of 2 and 3. They're not wrong takes, but they're highly dependent on the company stage. For 2, it's a feature factory below a certain size or market penetration. You will be valuable but you will be anything but calm and relaxed. Research doesn't qualify, talking about Product here. 3, which is Platform and/or maintenance is definitely unsexy until you are a scale up and your software sucks ass since you never maintained it and no amount of infrastructure can save it. Then to grow you become extremely important. I think you want to consider the company size, the state of the product, and its market fit before making these assertions. All three are the best and worst jobs to have, it just depends when and where you are.

jsdwarf 3y ago

One word of warning about the cozy R&D department of a product org: you may suffer from the boiling frog syndrome. Little attrition and long-time continuity means everybody stays in their seat and there a few true career opportunities beyond seniority promotions (dev - senior dev etc). After 5-10 years you find yourself quickly at the end of your promotion trajectory and realize that much younger/cheaper folks have the same role as you. This puts you at a disadvantage in salary negotiations and increases the risk of being let go. Project-driven orgs can be brutal environments, but there is always a possibility to climb up the ladder due to high churn.