Live data from Hacker News

Enterprise Software Projects Killed the Software Developer

javahippie.net

141–150 of 150 posts

Re: Enterprise Software Projects Killed the Software Developer

#141
post #140

Earlier quoted context omitted.

> There's a secret third option: The organization could just hire good devs. That's rarely up to the individual developer to decide. If you cook a complex bowl of abstraction soup, knowing that mediocre developers will maintain it after you, that's on your conscience.

The evaluation objective for those medicore devs should be to „get up to speed” or the company will never improve and soon become overrun by competition.

Aha. And should every single company employ above-average developers? How does that work out, mathematically?

Re: Enterprise Software Projects Killed the Software Developer

#142
post #140

Earlier quoted context omitted.

The evaluation objective for those medicore devs should be to „get up to speed” or the company will never improve and soon become overrun by competition.

Aha. And should every single company employ above-average developers? How does that work out, mathematically?

It doesn't: The average startup goes bankrupt.

Re: Enterprise Software Projects Killed the Software Developer

#143

Earlier quoted context omitted.

Aha. And should every single company employ above-average developers? How does that work out, mathematically?

It doesn't: The average startup goes bankrupt.

The average corporation doesn't go bankrupt, so you moved the goalpost from "corporation" to "startup". Ok, sure. So, in your view, a developer who leaves behind over-architected complexity to "mediocre" developers is a surefire recipe for going bankrupt... and this was supposed to be in defense of overarchitecting complex codebases? To me it sounds like going bankrupt is bad, so we as developers should strive to prevent our employers from going bankrupt, no? So if you work for a startup that you know is going to hire mediocre developers after you, surely you should strive to leave behind the kind of codebase that doesn't bankrupt the company after you leave?

Re: Enterprise Software Projects Killed the Software Developer

#144

Earlier quoted context omitted.

It doesn't: The average startup goes bankrupt.

The average corporation doesn't go bankrupt, so you moved the goalpost from "corporation" to "startup". Ok, sure. So, in your view, a developer who leaves behind over-architected complexity to "mediocre" developers is a surefire recipe for going bankrupt... and this was supposed to be in defense of overarchitecting complex codebases? To me it sounds like going bankrupt is bad, so we as developers should strive to pre…

> The average corporation doesn't go bankrupt, so you moved the goalpost from "corporation" to "startup".

For a lot of corporations, making the jump to software is effectively starting a new company within the company.

> To me it sounds like going bankrupt is bad, so we as developers should strive to prevent our employers from going bankrupt, no?

Bad hires tank companies.

> So if you work for a startup that you know is going to hire mediocre developers after you, surely you should strive to leave behind the kind of codebase that doesn't bankrupt the company after you leave?

That's a red flag right here. It means sell your RSU as soon as you can.

Re: Enterprise Software Projects Killed the Software Developer

#145
post #79

You'll never see a purely Agile or Lean product from an Enterprise, because those don't have a clearly defined set of expenses, profits, and timelines. One terrible thing about Enterprises is the way their finance team leads product decisions. In order to maximize their profit, they announce a product will be ready by X date, and estimate the cost leading up to it. If you don't hit those numbers, it affects a lot of…

Would you mind telling me at what kind of Enterprise you had that experience with finance? I led a product finance team at a SaaS company (ServiceNow, Atlassian, Okta, etc. tier) and all of our models and analyses are product driven including a/b testing and surveys with customers.

Largely Enterprises that had too much profit to care, or were controlled by a parent org with a tight leash on expense with no regard to product. Old-school businesses that had barely begun digital transformation. As long as they got their 2% growth YOY, there was no interest in closely tracking anything but the core BI metrics for growth and expense.

I would add that a/b and surveys are not good enough to identify customer pain and solve the problems they most want solved. There's a raft of feedback mechanisms that most Enterprises ignore because their products are so complicated that nobody wants to sit with the users and find new methods for continuous improvement. Agile/Lean/DevOps/SRE constantly emphasize quality and immediate halting of product work until bugs are fixed, yet no Enterprise I have ever heard of does this (even for reliability - one of the core metrics of any online product!)

Re: Enterprise Software Projects Killed the Software Developer

#146
post #140

Earlier quoted context omitted.

The evaluation objective for those medicore devs should be to „get up to speed” or the company will never improve and soon become overrun by competition.

Aha. And should every single company employ above-average developers? How does that work out, mathematically?

I dont know a corporation in IT that doesnt have evaluation programs. All management expects you to get better over time.

So using the opportunity to learn from a better dev is a great objective that positively will impact not only you but also the company you work for.

On the other hand if developers stagnate and dont improve -> this is a red flag for company growth. And each corporation wants to grow. Such dev is just a bad hire and will tank the company.

Re: Enterprise Software Projects Killed the Software Developer

#147

Earlier quoted context omitted.

The average corporation doesn't go bankrupt, so you moved the goalpost from "corporation" to "startup". Ok, sure. So, in your view, a developer who leaves behind over-architected complexity to "mediocre" developers is a surefire recipe for going bankrupt... and this was supposed to be in defense of overarchitecting complex codebases? To me it sounds like going bankrupt is bad, so we as developers should strive to pre…

> The average corporation doesn't go bankrupt, so you moved the goalpost from "corporation" to "startup". For a lot of corporations, making the jump to software is effectively starting a new company within the company. > To me it sounds like going bankrupt is bad, so we as developers should strive to prevent our employers from going bankrupt, no? Bad hires tank companies. > So if you work for a startup that you know…

> Bad hires tank companies.

We weren't talking about bad hires, we were talking about mediocre hires. It seems like you expect all companies to higher above-average developers, even though that is mathematically impossible.

Re: Enterprise Software Projects Killed the Software Developer

#148
post #146

Earlier quoted context omitted.

Aha. And should every single company employ above-average developers? How does that work out, mathematically?

I dont know a corporation in IT that doesnt have evaluation programs. All management expects you to get better over time. So using the opportunity to learn from a better dev is a great objective that positively will impact not only you but also the company you work for. On the other hand if developers stagnate and dont improve -> this is a red flag for company growth. And each corporation wants to grow. Such dev is j…

Of course developers should learn and improve. Nobody is arguing otherwise. Yes, people can improve, that doesn't change the fact that the average company employs average developers. If your company hires average developers, then you need to maintain your codebase complexity at a level that is manageable by average developers. All this talk about "bad hires" and such is really missing the mark here.

Re: Enterprise Software Projects Killed the Software Developer

#149

Earlier quoted context omitted.

> The average corporation doesn't go bankrupt, so you moved the goalpost from "corporation" to "startup". For a lot of corporations, making the jump to software is effectively starting a new company within the company. > To me it sounds like going bankrupt is bad, so we as developers should strive to prevent our employers from going bankrupt, no? Bad hires tank companies. > So if you work for a startup that you know…

> Bad hires tank companies. We weren't talking about bad hires, we were talking about mediocre hires. It seems like you expect all companies to higher above-average developers, even though that is mathematically impossible.

> It seems like you expect all companies to higher above-average developers, even though that is mathematically impossible.

No, but that's what I expect from the companies that will succeed.

Re: Enterprise Software Projects Killed the Software Developer

#150
post #146

Earlier quoted context omitted.

I dont know a corporation in IT that doesnt have evaluation programs. All management expects you to get better over time. So using the opportunity to learn from a better dev is a great objective that positively will impact not only you but also the company you work for. On the other hand if developers stagnate and dont improve -> this is a red flag for company growth. And each corporation wants to grow. Such dev is j…

Of course developers should learn and improve. Nobody is arguing otherwise. Yes, people can improve, that doesn't change the fact that the average company employs average developers. If your company hires average developers, then you need to maintain your codebase complexity at a level that is manageable by average developers. All this talk about "bad hires" and such is really missing the mark here.

IMHO If the company hired you for your superiour knowledge and expects you to deliver. You should deliver. Its really not your problem they opened hiring for someone out of their league. Even worse if managers agree to your improvement plan.

Dont you think that someone before or after hiring of a real expert dev should check whether you really need that ?

They can always fire someone for being „too good” or like you say „decreasing own standards”.

Thankfully those experts sooner or later leave those medicore companies but they are not responsible for the mess that was left - its always the management that did not create clear expectations towards hires…

Post reply on HN