Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The other kind of staff software engineer

earthly.dev

Post reply on HN
Print view View original

141–150 of 201 posts

Re: The other kind of staff software engineer

#141

Post by vineyardmike »

belter wrote: post #108
nunez wrote: post #92

Earlier quoted context omitted.

That owner was absolutely correct. If you can make the company money and you can prove how, the sky's the limit. You're much more likely to get a cut of profits over a cut of savings.

I worked as Consultant for several years and instead of a daily rate, always proposed for each of my large projects, that companies would pay me 0.5% of the money my activities made the company or 0.1% of the money I saved the company. Not one ever took up on this offer...

Yea because people want a single invoice and to be done with you. No one wants to pay a ongoing expense, nor an expense that isn’t fixed. Math/accounting is way harder.

Re: The other kind of staff software engineer

#142

Post by awkward »

throwanem wrote: post #84
awkward wrote: post #77

Earlier quoted context omitted.

That's called COGS, or Cost Of Goods and Services. It's separate the kind of costs he's talking about. If you're working on COGS you're working in a profit center generating revenue, not in a cost center performing necessary but expensive functions. Tech doesn't usually measure COGS, because the cost of another user on a website is near zero.

I've seen the distinction drawn, usefully I think, between "Cost of Revenue" as more or less fixed operating costs eg AWS spend, and "Customer Acquisition Cost" as specifically the average spend to gain "another user on a website", usually in a way that can be either considered in the aggregate or broken out per channel such as for specific ad vendors or similar. I think "COGS" as discussed here would probably be a r…

Cost of Revenue and Customer Acquisition Cost are both different metrics. COGS is used in manufacturing in order to peg inputs to a per widget basis. Cost of Revenue gets used in tech because per customer costs are both a bad way to measure it and likely to be fractions of cents.

Customer Acquisition Cost gets used in subscription businesses to measure sales and marketing performance. It can be relevant alongside COGS if you're manufacturing the thing you're selling subscriptions to, but that's kinda rare.

Re: The other kind of staff software engineer

#143

Post by jsmith45 »

sciuromorpha_ wrote: post #37
_the_inflator wrote: post #15

Earlier quoted context omitted.

Reminds me of C Sharp developers until I joined a purely MS stack using company. Also a silent majority in my opinion.

I saw a post on r/ProgrammerHumor a while back saying something along the lines of "why does no one make jokes about C# here" and the replies were all the same - there's nothing particularly funny, and all the users are quietly plugging away at their corporate jobs. Made me chuckle.

Yeah. It's not a language you come across a lot ouside of corp work, it largely avoided the absurdity of AbtractFactoryFactory and similarly overdesigned architecture that is a common focus of Java jokes, and it did not suffer from language stagnation for enough years to make the alternate languages for the VM feel like actually competition, as opposed to things that are mostly useful in certain specialist scenarios.

Re: The other kind of staff software engineer

#144

Post by kqr »

phkahler wrote: post #53
adamgordonbell wrote: post #3

Author here. Working at a tech company as a developer vs working at a non-tech company are very different. These two types of roles were called line vs staff when I took a business school class and I think the differences between these two types of roles have a big impact on what the job is like, even if doing the same type of work. It's a bit confusing because it overlaps with 'staff software engineer' term. I recal…

Two thing. One, I always hated the cost center vs profit center distinction. These are accounting terms. It's super common in places that have embedded software (auto industry is close to me) where any manufacturing plant is considered a profit center, and engineering is often a cost center. When things are tight they tend want to reduce "costs" not realizing that engineering can also be seen as an investment in the…

> engineering can also be seen as an investment in the companies future.

In fact, when things are tight is the very moment you should go all in for R&D.

Let's clear up something simple people forget: when things are tight for you, they are normally also tight for your customers. In fact, that's generally how they become tight for you.

So you can forget investing in production and sales when things are tight. Things are tight because the world is in a period where your customers aren't buying. You won't change that by trying to sell harder.

However, small research projects are an incredibly cheap way to learn things and invent new technologies. When you're not encumbered by turning things into products, you can discover at a frightening speed. So you spend on research when the times are tough, and then when things go better you have a huge backlog of technologies you can apply right away.

Re: The other kind of staff software engineer

#145

Post by erwincoumans »

adamgordonbell wrote: post #100
erwincoumans wrote: post #79

Earlier quoted context omitted.

Sure, I just wished the author/article would have spelled out/confirm the standard definition of 'staff swe' as step/level in the ladder before going into the 'other' meaning of 'staff swe' as being part of non-core product.

Like this, from article footnotes: When talking about “staff” in this article, I do not mean the Staff software engineer role that is found at tech companies after senior. That is a different usage of the term

Indeed, like that but then in the main text instead of in a footnote, so it doesn't get overlooked. Anyway, I enjoyed your nice writing and congrats with the HN exposure!

Re: The other kind of staff software engineer

#146

Post by escapedmoose »

jimmaswell wrote: post #82
adamgordonbell wrote: post #3

Author here. Working at a tech company as a developer vs working at a non-tech company are very different. These two types of roles were called line vs staff when I took a business school class and I think the differences between these two types of roles have a big impact on what the job is like, even if doing the same type of work. It's a bit confusing because it overlaps with 'staff software engineer' term. I recal…

I work at a non-tech company. I mostly write/maintain unexciting components for a website's CMS, and any tertiary work around that. Easygoing, remote, great work/life balance, good pay. Often go fishing or work on projects like an ebike for a lot of the day, sporadically checking the work chat and tuning into meetings from my phone. On the rare occasion something really important comes up I'm always ready to jump in…

My partner and I both have similar roles to yours, in non-tech companies. Sometimes we both feel like we’re not being ambitious enough… but we walk into town for two-hour lunches together 2-3 times per week, finish household errands on weekdays, and never have to worry about money. The initial transition from “working hard” to “hardly working” was difficult to settle into, but imo as long as we can keep up our skills with all this extra time, it’s a very enjoyable lifestyle.

Re: The other kind of staff software engineer

#147

Post by gernb »

adamgordonbell wrote: post #3

Author here. Working at a tech company as a developer vs working at a non-tech company are very different. These two types of roles were called line vs staff when I took a business school class and I think the differences between these two types of roles have a big impact on what the job is like, even if doing the same type of work. It's a bit confusing because it overlaps with 'staff software engineer' term. I recal…

It's crossed my mind in the past that there are companies where often devs run things and companies where devs are just support for the real business. I don't think I ever want to work at a company where devs do not run things only because my spoiled experience has entirely been at companies where they do and I selfishly don't want to just be support staff for the real business.

You might disagree with these examples but:

A stock trading company, IT stuff are support for the real employees, the traders. You have a trader, you have a trading company. The programmers are just support for them.

Animated Movies (even pixar). Sure, there are important software devs but the real staff at pixar are animators. They can ship animations with off the shelf software or paper and pencil. In house software devs are super important but at the end of the day if all they had was animators they could still ship animation.

Lawyer firms, Medical Facilities: Yea, they need IT staff to help run things but they can function with just lawyers or just doctors.

VS say Apple, Google, Facebook, Microsoft. No devs, no company.

Video Game companies used to be and probably mostly still are this way. No software devs no product ships. That might be fraying as tools get better.

Re: The other kind of staff software engineer

#148

Post by whimsicalism »

pgodzin wrote: post #122
chadash wrote: post #65

Related to this article: The owner of a company (non-startup, but growing and profitable) I used to work for gave me great career advice. He said to always focus on things that produce revenue. If you aren't doing things that produce revenue, try to move into those areas if possible. His view was that revenue can soar 100%, 200%, 1,000%, 10,000% or however high. Cost savings, on the other hand, can only go down to a…

> Obviously, a rational CEO would see $1m cost savings the same as a $1m gain in profits This is generally incorrect, especially at SaaS companies where revenue is recurring. It's very likely that you'll see much of that $1m gain again in future years, possibly even growing, while cost savings are hard to repeat consistently without impacting future growth.

that makes no sense at all

Re: The other kind of staff software engineer

#149

Post by pgodzin »

Brystephor wrote: post #133
pgodzin wrote: post #122

Earlier quoted context omitted.

> Obviously, a rational CEO would see $1m cost savings the same as a $1m gain in profits This is generally incorrect, especially at SaaS companies where revenue is recurring. It's very likely that you'll see much of that $1m gain again in future years, possibly even growing, while cost savings are hard to repeat consistently without impacting future growth.

If you save $500k this year by optimizing some pattern or behavior (eg infrastructure) then why wouldn't that $500k also be saved the next year? You're right if it's a one-time cut (eg no free snacks this year) but most savings are going to be on things that happen more than once.

Agree on things like infrastructure optimization. Most significant savings happen on people costs though, and layoffs/hiring freezes tend to not last forever, and also have impacts on future growth as well.

Compared to the same amount of revenue offering, most top SaaS companies have >100% net dollar retention, which means that their existing contracts tend to grow year-over-year from usage/upsells, so the long-term value of that $1m in revenue increases over time.

Re: The other kind of staff software engineer

#150

Post by filoleg »

gernb wrote: post #147
adamgordonbell wrote: post #3

Author here. Working at a tech company as a developer vs working at a non-tech company are very different. These two types of roles were called line vs staff when I took a business school class and I think the differences between these two types of roles have a big impact on what the job is like, even if doing the same type of work. It's a bit confusing because it overlaps with 'staff software engineer' term. I recal…

It's crossed my mind in the past that there are companies where often devs run things and companies where devs are just support for the real business. I don't think I ever want to work at a company where devs do not run things only because my spoiled experience has entirely been at companies where they do and I selfishly don't want to just be support staff for the real business. You might disagree with these examples…

Fully agreed with your overall position, but I got a small correction in regards to what you said about fintech.

While you are correct in that at a lot of finance companies, devs just act as "support for the real business" (e.g., Goldman Sachs). But there are others where devs and quants pretty much harmoniously run the show.

Look at something like Jane Street and their tech blog[0]. Their annual "what our interns have wrought" blog posts grab my attention like nothing else, and from everything I read coming from them, it seems like engineering there is not just "support for the real business". And there are quite a few companies in fintech like this, they just won't be flashed in the mass media due to their relatively small size, but everyone in the industry (and plenty of people on the outside) knows about them. Out of all things, they are known as one of the largest contributors to OCaml language and its ecosystem.

Jane Street was just a singular example, and there are other fintech firms of a similar engineering-focused culture.

0. https://blog.janestreet.com/

Post reply on HN