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

191–200 of 201 posts

Re: The other kind of staff software engineer

#191

Post by BrandoElFollito »

ncmncm wrote: post #169
tobyjsullivan wrote: post #164

Earlier quoted context omitted.

It sounds like you are conflating “support staff” with “inconsequential” or low-value work. That is definitely not what the author says. By the definitions of the article, the head of engineering at a tech company, or even the CEO, are considered support staff. Their success and failures will 100% map to the success and failures of the company.

The author isn't saying it, but business schools are. The business school mantra is invest in profit centers, nickel-and-dime cost centers . If you are so unfortunate as to be at a company run by an MBA and are in a cost center, woe to you.

This is what happens to Motorola IT.

Some wise exec had the vision to outsource it to an external company and then Motorola (that was already on the path to its death) realized how much was done outside of the process (which is typical for such companies, fortunately or not).

Suddenly your threat of whatever happening if your thing is not fine had exactly zero value against "raise a ticket". Everything crawled to a stop because of that and "golden tickets" were used.

This is one true example of why you should think 20 times before outsourcing something you do not understand.

Re: The other kind of staff software engineer

#192

Post by astrange »

jsmith45 wrote: post #143
sciuromorpha_ wrote: post #37

Earlier quoted context omitted.

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.

It’s popular in games now because of Unity and il2cpp. Even though it started as a Java ripoff, it’s infinitely better because it has value types.

But my impression using it in school was the standard library was even worse than Java. Where Java buries things under six namespaces of reverse domain name, C# buries them under what looks like random technical terms chosen to impress people.

ie there is no reason for System.Console.WriteLine() or System.Collections.ArrayList to be where they are. It doesn’t make your program work better.

Re: The other kind of staff software engineer

#193

Post by adamgordonbell »

erwincoumans wrote: post #145
adamgordonbell wrote: post #100

Earlier quoted context omitted.

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!

Thanks!

Re: The other kind of staff software engineer

#194

Post by travisathougies »

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, but CEO's are not rational beings (nor is any human) and understanding that they usually prefer higher revenue to lower costs is fundamental to understanding how they value different parts of the company. It's not fair, it's just truth (at least in many companies).

A rational CEO prefers revenue growth as companies are valued based on revenue, and the CEO's purpose is to maximize per share value.

Re: The other kind of staff software engineer

#195

Post by anoy8888 »

oblio wrote: post #189
anoy8888 wrote: post #130

Earlier quoted context omitted.

I am a Staff software engineer in a consumer goods company. I got quickly promoted to it manger , head of it and then CIO. The tech is shallow but it exposes me to production, supply chain , sales , finance and pretty much every aspect of the operations. I report directly to CEO. We typically buy erp but small softwares , I choose to write myself so that I got some practice on coding. I go to home before 6 and enjoy…

That's nice, I think the question on everyone's mind is: is your pay comparable to FAANG?

Nope. Much lower . Fanng salaries are crazy. And I live in a developing country. But the salary is comfortable

Re: The other kind of staff software engineer

#196

Post by elcritch »

travisathougies wrote: post #194
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, but CEO's are not rational beings (nor is any human) and understanding that they usually prefer higher revenue to lower costs is fundamental to understanding how they value different parts of the company. It's not fair, it's just truth (at least in many companies). A rational CEO prefers revenue growth as companies are valued ba…

A CEO's purpose is to organize and direct a company to meet its corporate charter.

Good read on the shortcomings of the "agency theory" based view that you're assuming, and which thankfully is finally becoming less of the de facto view: https://hbr.org/2017/05/the-error-at-the-heart-of-corporate-...

Re: The other kind of staff software engineer

#197

Post by travisathougies »

elcritch wrote: post #196
travisathougies wrote: post #194

Earlier quoted context omitted.

> Obviously, a rational CEO would see $1m cost savings the same as a $1m gain in profits, but CEO's are not rational beings (nor is any human) and understanding that they usually prefer higher revenue to lower costs is fundamental to understanding how they value different parts of the company. It's not fair, it's just truth (at least in many companies). A rational CEO prefers revenue growth as companies are valued ba…

A CEO's purpose is to organize and direct a company to meet its corporate charter. Good read on the shortcomings of the "agency theory" based view that you're assuming, and which thankfully is finally becoming less of the de facto view: https://hbr.org/2017/05/the-error-at-the-heart-of-corporate-...

You're redefining what the goals are for the rational CEO, not the rational nature of the CEO though. But suppose I believed your goals were proper. I fail to see how 'cutting costs' is going to help a company better meet its corporate charter than maximizing revenue. It seems again the latter would win out, because more revenue, means more cash coming through you which means (a) more potential for cost savings (whereas cost savings don't typically create potential for revenue) and (b) more ability to exploit that cash once you have (a).

Re: The other kind of staff software engineer

#198

Post by belter »

pjot wrote: post #188
belter wrote: post #131

Earlier quoted context omitted.

No. I always made it very clear. Example: Show me your current budget for your main data center. Let me show a proposal for a Cloud move that will keep equivalent or better quality of service, including training and while defining KPI's for success.

Would you have agreed to a deal that called for you paying _them_ if those KPIs were missed?

Penalties are standard in many Consulting contracts. Fixed price contracts are also frequent.

Re: The other kind of staff software engineer

#199

Post by belter »

vineyardmike wrote: post #141
belter wrote: post #108

Earlier quoted context omitted.

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.

Except when is to reward the board ;-)

Re: The other kind of staff software engineer

#200

Post by wreath »

RHSeeger wrote: post #166
wreath wrote: post #66

Earlier quoted context omitted.

> My perception is that I'm considered too good on the "line"; I'd be a loss to the org to move up a notch. At a previous company, they moved a lot of their top performer “line” engineers to staff level and they all felt unproductive and eventually quit.

This is a fairly well known issue Peter Principle ( https://en.wikipedia.org/wiki/Peter_principle ) > The Peter principle is a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to "a level of respective incompetence": employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one…

Yeah sure but the point being these people never wanted this role and not only t company lost them as productive ICs to some other role but they lost them altogether (great engineers with deep domain expertise)
Post reply on HN