Oh, I've definitely met princesses at large companies, though you are spot on about the ownership issues. The problem really isn't the size of the company but how siloed the code is.

Yeah, one of the 1000-person companies had a dev whole-own a critical microservice. Changing it was always a battle, because the owner was very critical of anyone touching 'his' service. Large companies aren't immune, but due to eng specs and collaboration baked into development, its less likely for this to happen.

It looks management was a problem too, as "wholly owned" is a double-edged sword, especially if it's a microservice.

Make sure you have solid metrics on your side to record problems with that microservice, document any delays caused my missing features, and eventually even non-technical management should get your point and start to apply pressure.

Problems were resolved and everyone was professional, but there certainly was more friction than necessary.

Usually management doesn't want to participate in these discussions, because they are more careful about retention (and stepping on toes). 1 engineer quitting is a 10% reduction in their workforce.

Yeah I could see that. The place in question where I worked was developing some new products, so we didn't have that kind of situation where someone was gatekeeping or otherwise being unpleasant.

200-400 is the sweet spot, I've found.

> At large companies no one feels like they own 100% of the code, and each change is very collaborative.

That's how you end up with endless process, design by committee, and having a dozen meetings with all "stakeholders" before actually writing any code.

I'd much rather work at a place where individuals or small groups have a strong vision on the code and product and are capable on executing independently on that. It sounds like the OP would too. But I understand it's a personal preference.

I read something about how a lot of 'super group' bands kind of don't do anything truly great because of this type of dynamic. They all know they're good, they know the others are good, and they all have a bit of an ego and don't want to stomp on the others, so they all tend to "go along with it" without getting too pushy. That leads to good, but not great music.

Definitely. Though there are exceptions. Led Zeppelin comes to mind first.

I think part of the idea was that in an actual band that has been a band for a while, they usually find a way of working together that includes "difficult conversations" and saying no, and sometimes listening to one person's vision rather than tiptoeing around egos.

This is the long term way to greatness. In companies and life.

Enterprise software is not art and shouldn't be approached the same way. You want a roller-coaster-like experience, go join a startup

No one said 'roller coaster'. Part of quality software is saying 'no' to stuff, or having a coherent vision, not 'software by committee'.

Only if you have a quality engineer at the wheel though. Otherwise you just end up with horrible software.

I guess that’s why large enterprises hate it, since they’re all about reducing risk.

If they get middling software every time then that’s preferable to the two extremes.

Enterprise software isn't middling, it's usually only barely functional and falls just short of what it should do (i.e. it's shit). Everyone is just so pathologically used to it they think it can't be better. Probably due to the allergy to risk that you mentioned. Ironically risk is eliminated, but in doing so you've just ensured you have consistent problems that can never get better.

"I'd much rather work at a place where individuals or small groups have a strong vision on the code and product and are capable on executing independently on that"

Isn't that dependent on whether you are the person guiding the code though?

Honestly, not necessarily--there are often many ways to solve a given software problem. If someone else has a vision for the software and a plan to achieve it as a team, as long as I can see that it is looks like a viable alternative I'm generally happy to go along with it. Far better than flapping in the breeze with nobody providing clear guidance or input, in my opinion!

> But I understand it's a personal preference.

Indeed. No company size is perfect. There are dysfunctions typical for small companies. There are dysfunctions typical for large ones.

But people have preferences; some things they can handle, other things drive them crazy. What drives you crazy may be different from what drives your friends crazy.

Perhaps everyone should try to work once in a large corporation, and once in a startup, to figure out their own preferences.

Small groups of 1+ with a vision isn't really software engineering though. You aren't building to solve someone else's problem and it's that which is engineering. Turning up to the beach with bricks and cement on a whim with mates to create a small damn because it's your vision? Well that's kind of build it and (hope) they will come.

Or to be kinder. If you are filling your own hole (identified need) you can be more free in your approach. After all only you decide if it's right, finished, a failure or success.

> I’ve worked at 3-4 small companies (less than 30 employees)

What I vastly prefer is the 500-ish size. You can realistically at least know of every other developer (and find those you prefer working with and can learn with), there's more resources than just a 30 person company, and you're just not a tiny insignificant cog in the machine at a 100k mega corp.

It really depends what team you're on! My little corner of megacorp is fast, pretty lean, and I definitely feel like I am able to make an impact on our product (which is a smaller product in the company). I feel much better here than at some of the mid size companies where I felt there was a low ceiling on growth opportunities.

Come, oh my child, and be attentive to everything you see Me doing, in order to do it together with Me, that I may continue my Life in you.

Are you ideas normally implementable in the next month or something far-fetched? Try to come up with ideas that are low hanging fruits, easy to do but have a high value. I don't think any company/management in their right mind would constantly reject "good" ideas that ultimately result in more revenue. The ideas I see being rejected are either too far out there or some "dev utopia"-kind of ideas that don't bring in more cash, just burn effort.

> I don't think any company/management in their right mind would constantly reject "good" ideas that ultimately result in more revenue.

We must have worked at very different places.

The problem is there are many ways to implement a feature. Often one isn't objectively better or worse than the other (but subjectively it is).

Everyone wants the problem solved, but how the problem is solved leads to frustration.

> I don't think any company/management in their right mind would constantly reject "good" ideas that ultimately result in more revenue.

This happens extremely frequently and is in fact entirely normal.