Hacker News Reader

I posted this as a comment on the original post, but will make the point here...

Large organizations are often more dysfunctional than small ones, yes, especially when it comes to building software. But that doesn't mean they aren't filled with very smart people. The fact that enterprise programmers can't get hired at startups is not, in my opinion, a reflection of the dysfunctional nature of software development at large companies, but of a mismatch in expectations about how to communicate your ability to do your job.

As an example: one pattern I’ve seen that consistently holds enterprise programmers back in startup interviews (especially in phone screens and technical screens) is the inability to effectively articulate the projects they’ve worked on. Enterprise programmers have often worked on optimizing one small part of a very large and complex system that no one person may understand completely, and in my experience, they often cannot describe that system clearly or holistically. Startups usually need people who can build a system end-to-end, and when an enterprise programmer doesn’t seem to understand their own projects, it reflects very poorly. I see this pattern way too often.

My suggestion (and obviously this is a gross generalization) is for enterprise programmers who want to work at startups to practice being able to clearly and consisely explain what they worked on and how it fit into the overall product. Startups will care more about this than showing, for example, a deep understanding of how Java's various memory pools work (even if they work in Java).

There is also a bias against enterprise developers in that most often their work is on proprietary systems, leaving no code artifacts to view on Github, which a lot of companies have started using in their recruiting process.

This has been a huge issue for me- I used to be very active on Github, but the past year or so I've been working either on proprietary systems that are internal to the company I'm at, or working on private projects that I don't want in public repos. So, if you were to look at just my Github profile, you'd see almost no activity. That doesn't mean I'm not constantly working, though!

> usually at least two to three generations behind on every technological trend

It's easy to refactor (or completely rewrite) for whatever the hot new fad is when you're dealing with small codebases (<100k loc) that haven't been around very long and most likely won't continue to be in use for long. That's not productive when you're working on a product that has millions of lines of code and has been in use for years (and most likely will continue to be so).

It has nothing to do with "pointy haired bosses" - believe it or not a lot of us [enterprise developers] care more about actually getting stuff done then bragging to our friends how we're playing with whatever is hip this week.

I think that's a valid point but it only explains a small fraction of the ugliness of enterprise software. It explains why it tends to trend a bit behind, but it does not explain why you need 2gb of RAM to run a web application server or why you need ten pages of XML vomit to add a record to a database. Those kinds of things smack of over-engineering (usually via premature generalization and "architecture astronautism") and cargo cultism among other things. When I look at those systems and code bases I always just sit there and ask "what problem does this solve? what problem does this solve? what problem does this solve?"

I also didn't mean to imply that there are no good developers in "enterprise." But I do believe that "enterprise" is to good developers what, say, a corrupt economy is to good entrepreneurs. You can operate there but it's painful and everything about it gets in the way of doing the right thing.

Also also (heh) I didn't mean to imply that all enterprises are "enterprise." That's why I put it in quotes. Some large organizations manage to avoid these pathologies. I've even seen really excellent systems emerge from government labs if the people running them are clueful. "Enterprise" in quotes refers to the pathologies that afflict big over-priced over-engineered slow clunky UX abominations. Everyone's seen them and everyone's been forced to use them... forced because nobody would ever voluntarily do so.

> You can operate there but it's painful and everything about it gets in the way of doing the right thing

Yikes, that hit close to home. Where I'm working now is very "enterprise", but when they brought me on they gave me a huge amount of autonomy and it's worked out great for them- I started fresh on new projects and was able to make them lightweight, fast, and pretty.

And then they toss at me a behemoth of an ancient, 10-year-old project with services that connect to services that connect to services (all on the same machine!) and probably uses more than 2GB of RAM for simple CRUD screens. There's no funding and it's too big and "vital" to rewrite, so they're stuck with it (probably for another 30+ years, just like they were stuck with the COBOL system it replaced)

It was around that time I started looking (and am still looking...) for a new job.

> It's so bad that I've actually heard people advise startups to pass on some enterprise revenue if they can afford it (pass on REVENUE!) if it might lead them down an "enterprisey" path, since doing so would in the end result in a systematically inferior product.

Yes, because it's much better to have an architecturally pure product nobody uses than something generating millions in recurring revenue.

It depends on the situation. It's bad to forego millions in recurring revenue, but it's not bad to forego smaller gains if you have a vibrant business in other areas and if those smaller gains require that you go down a path that will ultimately make your product a loser in the marketplace.

This is why Apple shuns "enterprise." They value user experience. Exposing UX to enterprise development priorities and methodologies is like exposing a kitten to mustard gas. Even a little bit does tremendous harm and it's definitely cruel.

Last I checked Apple was among the most valuable companies in the world. Their stuff is also heavily used in enterprise in spite of their dismissal of it. Sometimes a good product can make inroads into enterprise if it's good enough to overcome certain biases and entrenched pathologies. Some organizations have departments running their own "guerrilla IT" to support things that aren't awful vs. the awful stuff shoved down their throats by corporate IT.

The root problem with enterprise is that products are often built to artificial specifications that someone made up, not to actual specifications learned through real use and feedback or that are shaped by underlying reality. This results in a lot of superfluous complexity that does not reflect the actual complexity of the problem domain. Another major problem is that purchasing tends to be based on feature check boxes instead of actual evaluation of the product by people who will actually be using it. You'd be surprised how often a large org will make a major purchase without even consulting with those who will actually be using the product. I've also seen cases where people go so far as to pretend to use the "boat anchor" product while actually doing things using a different system purchased or built with off-normal-channels funds.

Apple shuns enterprise, huh? http://www.apple.com/business/mobile-enterprise-apps/

I've worked for startups and I've worked for enterprise apps, and at least the enterprise apps I've worked on actually got used by a good number of people. Some of the startup apps I worked on completely failed to find their audience precisely because someone in charge was making it all up as they went along and didn't base anything on what customers actually wanted.

I tried to do the best I could in that situation, and sometimes managed to convince myself that the apps would find their audience, but the artificial specifications can exist equally in both domains.

And the startup arena was the only place where I saw the client/producer completely flip flop on how a feature should be designed multiple times in a single week, based on whatever article they read or dream they had the night before, and then get all pissed why I wasn't already halfway done with their brand new vision they just told me two minutes ago.

It can go both ways. At least the enterprise apps had a mechanism where the users could provide feedback, and had a definite audience and need that needed fulfilled.

> The root problem with enterprise is that products are often built to artificial specifications that someone made up, not to actual specifications learned through real use and feedback or that are shaped by underlying reality.

Sounds familiar. The previous app I worked on was so flexible and customizable via parameters, that in fact half of the bugs we've had were due to crappy configuration management process rather than actual code bugs.

So you would not hire someone of a Microsoft or Google background?

That's not what I said. I certainly would. I was responding to the bias against enterprise -- my point was that I understand the bias but do not agree that it should exclude developers with an enterprise background.

Why would this get down-voted? It's spot on. I know it hurts when it hits close to home folks, I know.