Brent Simmons:

I had a bias about engineers that worked for large corporations. I assumed that they weren’t as good as indies and engineers at small companies

I work for a small company and my clients are usually big companies, so I have some perspective here¹.

From my experience, the difference between working for large and small companies is bureaucracy and focus. A tolerance or affinity for these things means that the people attracted to each are different. Normally when we talk about “bureaucracy,” it’s a pejorative, but that’s not what I mean here. Larger companies need more formal process to function. We can save the argument about good or bad process for another time.

Competence is orthogonal to both bureaucracy and focus. It’s not about one being good and the other bad. I would suspect that it’s easier to hide at a bigger company. But, on the other hand, larger companies often have processes and procedures for managing poor performance. Maybe it averages out?

But the impression of a lack of competence of corporate engineers is often just that: an impression.

Corporates have more people, which means there’s more communication and more process. And more people inevitably means that each individual is responsible for a smaller slice of the pie. Contrast with an indie developer who is responsible for the whole.

This means that when you ask a corporate developer a question, the person you’re talking to quite possibly doesn’t know the answer! What you’re asking is about another part of the system that they’ve spent no time on.

If you’re from a small company, that looks like incompetence. But it’s really just a consequence of the scale.

It’s a form of adaptation or preference. The way you get things done differs between big and small companies.

At a small company, I might just be able to do something, or I’ll know exactly who to ask. At a big company, it might take some time to figure out who is even responsible.

When I interview engineers who have worked mostly for large companies, it’s not their technical skills that fall short. Instead, it’s their ability to Get Things Done. Because larger companies typically have processes and teams in place to do the more mundane aspects, often they’ve not even thought about how it works behind the scenes.

Just feed the data in from Kafka? Sure, how are you going to set up Kafka? What’s the best practice for using this particular feature? Good question! No, it’s not in the documentation. How are you going to figure it out? There’s no proscribed process, no one officially in charge of that.

Ultimately, it comes down to preference. Do you want to know a little about a lot of things, or a lot about a few things? Neither is objectively the “right” choice. Myself, I like to get involved in things outside my little pigeonhole. When I’ve worked at larger companies (typically through an acquisition) I’ve felt frustrated by the “it’s not your concern” responses when I’ve brushed up against other teams. I know my preference.

But I don’t like to underestimate “corporate” developers. They’re usually good but just have different preferences.