5 ms·
Programmer Passion: An Enterprises Most Useful Yet Repressed Advantage
- bretpiatt 16y agoPassion being the key to success is not limited to programming. If you love what you're doing you'll give it everything. This could be programming or carpentry. If you are doing what you're doing just for the paycheck you'll do the bare minimum required to achieve your desired performance level (i.e. some may still work hard enough to get an Outstanding rating to get paid more $ but hate what they do). This is the key thing I've learned to look for in hiring.
- gacba 16y agoSuccess in the Enterprise is dictated by throughput and repeatability, not in coolness of the solution. It's unfortunate, but the nature of the beast. They want their batch reports run on time, every night, and come out 100% accurate. That's not sexy, but it helps them make $. The end.
- tomjen3 16y agoThis is a common misconception: they make money until somebody else comes by and beat them with tech that outclass their own. The issue isn't that using better tech is better, but that it is better for the job security just to go with whatever everybody else does - then if something goes wrong, you can't be singled out for blame.
- igrekel 16y agoI agree that it can be a competitive advantage but it is rarely because of the technology itself, it is because of the change in business it enables. But there a lot of software used in an enterprise that is not a competitive advantage. You could argue that it could become an advantage but often the advantage would be marginal so you're better off working on where you can get significant gains or advantages. To see these opportunity, you need to know your business extremely well, you have to be passionate about the business too, not just technology.
- edw519 16y agoNice rant, but too bad that OP probably hasn't heard some of the more reasonable counter-arguments and understood their logic. Just a few "enterprise axioms": - Stuff must work consistently, regardless of who works there. - All data and programs must satisfy corporate audit requirements. - All data and programs must be backed up and restorable. - All technology must be supported, no matter what. I've seen all kinds of creative solutions to enterprise problems that didn't satisfy these axioms. And you know what happens? Something goes wrong and no one knows what to do. That server under Joe's desk with those cool spreadsheets just crashed and no one ever backed it up. The nifty little Ruby app that Sue put together; she's gone and no one else knows Ruby. The open source web server just crashed and no one is to blame because there is no vendor to blame. The nine new kinds of smart phones that different sales guys like but no one knows how to support. It goes on and on. Creative people get creative. Cool solutions help. Until they don't help anymore. Because the costs suddenly outweigh the benefits. And one more dirty little enterprise secret than many creative people overlook: you can solve most problems with many different tools. Sure the old tools may not be as fun, but they can still get the job done at a lower cost. In an ideal world, we'd get to work will cool stuff AND help the enterprise at the same time. But if the trade-off is our intellectual gratification vs. the enterprise's profits, the enterprise will win every time; count on it.
- vog 16y ago> The open source web server just crashed and no one is to blame because there is no vendor to blame. With all due respect, this is FUD. It is one of the typical "arguments" used by Microsoft to discredit Free Software. Of course you need (paid) support for all software you can't maintain on your own. If you fail to ensure support for Free Software, you are as doomed as if you fail to ensure support for the proprietary software. (However, with Free Software you have some chance to find another company that provides support for it. This is - by design - impossible with proprietary software.)
- gacba 16y agoIf you are a passionate programmer that wants to work with new tools, sexy frameworks, and other passionate developers... ...you should NOT be working in the Enterprise. Unfortunately, the nature of the Enterprise will kill much of that because of the 4 reasons laid out above.
- gvb 16y agoTremendously good quote: If your existing, potentially expensive and off the shelf solution, was any good then you wouldn’t need to mandate its use. There have been discussions on HN of what characterizes (in a derogatory way) "enterprise software". The quoted sentence captures in a nutshell the discriminator between "good software" and "enterprise software". FWIIW, I wrote down my thoughts on why "enterprise software" sucks: http://jerryjousting.blogspot.com/2010/09/three-ninety-percents-open-source.html http://jerryjousting.blogspot.com/2010/09/three-ninety-perce...
- kenjackson 16y agoI personally think its a horrible quote and seems to rely on fundamentally not understanding enterprises in any meaningful way. And its simply a cop-out to say that if what he suggests then hire better programmers (because practically, you probably already tried to hire the best programmers you could). I love the "empowering dev" perspective, but with no data to back it up, and a very naive sounding post that didn't even, in passing, mention a couple of reasons why such mandates happen (and effictively exist at companies like Google and Facebook) it comes off as completely not credible.
- gvb 16y agoI spent 24.8 years in a big company (sold three times "up the food chain" during that time - after the last sale, I made it a serious goal to not make it to my 25th anniversary). I've lived in an "enterprise" as it went from fairly entrepreneurial (founded by Bill Lear http://en.wikipedia.org/wiki/Bill_Lear http://en.wikipedia.org/wiki/Bill_Lear) to stifling (PCs weren't locked down, but having unauthorized software was grounds for firing... and getting software authorized was a like a byzantine quest for the Holy Grail). And its simply a cop-out to say that if what he suggests then hire better programmers (because practically, you probably already tried to hire the best programmers you could). That is dead on in my experience, but from a different angle. The best programmers aren't interested in working for a locked down stifling enterprise - witness the exodus from Sun - so enterprises cannot hire them. The enterprise I left lost a lot of good engineers over the past couple of years and have not had much success replacing them. As companies morph into enterprises, the Japanese proverb comes into play: the nail that sticks out gets hammered down. http://en.wikiquote.org/wiki/Japanese_proverbs http://en.wikiquote.org/wiki/Japanese_proverbs The result is they lose most of the above average people and only retain average and below average people. The result is their average is below average. pg talks about this in You weren't Meant to Have a Boss http://www.paulgraham.com/boss.html http://www.paulgraham.com/boss.html (skip forward to two paragraphs before the section "Programmers").
- wallflower 16y ago> Don’t mandate stacks, languages and frameworks. I know someone who had to put his job on the line to get use of Spring vs heavyweight J2EE approved. Seriously. There are entrenched forces who will spread disinformation if it threatens their comfort zone. A corporate environment is one where J2EE is just another checkbox on the thousand-item RFP.
- strlen 16y agoIt's somewhat of a chicken and egg problem: if you don't give programmers the ability to choose their tools, you can't hire top talent; if you can't hire top talent, you can't give programmers the ability to choose their tools. Recruiting is also a zero-sum game: if you don't hire the best, your competitors will. That means if technology is an enabling factor in what you do (it doesn't have to be your core competence), empowering programmers is a competitive advantage. I was at CUFP (Commercial Users of Functional Programming) recently where I had a conversation with Yaron Minsky of Jane Street. He mentioned that due to their use of OCaml (and being one of the few places in their industry where software engineers are not treated as second class citizens) they have a much higher quality of not only hires but applicants. He mentioned a job listing on a caml mailing list yielding a fairly small number of resumes, but a much higher percentage of these resumes translated into phone screens, on-sites and finally hires. I am not sure I'm allowed to disclose the percentage, but it's a fairly incredible number compared to what I've seen elsewhere; even the people they passed on, were of high quality. They are effectively choosing "the best of the best". If someone is willing to learn spend the time to learn a non-mainstream language (this used to be Ruby and Python in 2004, but now they're Haskell/OCaml/Scala, CL/Scheme/Clojure, Erlang; this may change again, I see at least one of Scala, Clojure or Erlang becoming mainstream) -- and I am talking about actually learn, beyond "fizz buzz" -- chances are they have the passion and the work ethic to be a good programmer. Of course this isn't a bijective map: there are good programmers who aren't interested in non-mainstream languages (in many cases they have highly specific knowledge e.g., machine learning where the language used doesn't matter as much), but I've yet to see someone take the time to learn Haskell on their own (without being forced to do so for a university course) who wasn't a good programmer: they may not be best of the best or a good fit for every position, but they are certainly not the kind of person you're going to regret bringing on-site to interview.
- tomjen3 16y ago>I see at least one of Scala, Clojure or Erlang becoming mainstream I doubt that, if only because they are so foreign to most programmers. That said I would love for a Lisp language to become mainstream again.