I enjoy programming in my free time and spend a considerable amount of time hacking away at open source projects as well as implementing those projects for various clients. My recent interests have included messaging (RabbitMQ specifically), Node.js, NoSQL, and alternative JVM languages such as Scala. You can also occasionally find me at several conferences speaking on some of my passions as well. Of course, got to balance all of this out with my wonderful baby girl and beautiful wife. James is a DZone MVB and is not an employee of DZone and has posted 20 posts at DZone. You can read more from them at their website. View Full User Profile

A Tale of Two Cultures

03.09.2012
| 3602 views |
  • submit to reddit

Today I found myself thinking again of what I see as two distinct cultures in the development world: Hackers and Enterprise Developers. This really isn’t any kind of a rant just an observation that I’ve been thinking over lately.

Hackers are really bleeding edge. They have no problem using the commandline, using multiple languages, or contributing back to open source. They’ll find and fix bugs in the opensource software they use and issue pull requests frequently. They’ll always be willing to use new tools that help them produce better software when there might not even be any good IDE support. Finally, they’re always constantly investigating new technologies and techniques to give them a competitive edge in the world.

Now when I say hacker I don’t mean someone who just hacks lots of random shit together and calls it a day (that kind of developer isn’t good for anyone). Just someone who isn’t afraid to shake up the status quo, isn’t afraid to be a bit different and go against the grain. They’re the polar opposite of enterprise developers.

Enterprise Developers on the other hand are fairly conservative with their software development methodology. I’m not saying that a lack of standards is a good thing, but enterprise developers want standards for doing everything and they want it standardized across the company. If there isn’t IDE support for a tool they’ll refuse to use it. Want to use mongodb, riak, etc? Not unless there’s a fancy GUI client for interacting with it. If they find a bug they’ll back away from the framework they’re using and simply declare that the company shouldn’t use the framework until the bug is fixed externally. I find this group prefers to play it safe and work on solidifying their existing practices rather than explore new ideas.

Now don’t get me wrong, this isn’t another rant on IDEs or developers who don’t use the command line. But give me a couple days in any organization and I can quickly point out who the Hackers and Enterprise Developers are. The hackers are always pushing the envelope, trying new ideas out, giving presentations. Most likely they’re facing off against enterprise developers on a daily basis who attempt to rebuff their ideas. The enterprise developers on the other hand are pretty content to do their same daily routine for the rest of their lives without any change or growth. To paraphrase Q from the Star Trek episode Tapestry, “He learned to play it safe. And he never, ever got noticed by anybody.”

What I’ve been considering though is whether or not both are beneficial to an organization. It’s no secret I associate myself with the hacker group (and thus I am a bit biased) but I keep wondering if enterprise developers truly are just the right fit for some organizations. I always think hackers are perfect because they push the envelop and come up with all kinds of interesting solutions to scalability problems, such as using Bitorrent to deploy to thousands of servers. Enterprise developers on the other hand rarely exhibit such innovation and would require shelling out several million dollars for an application to copy a file to multiple destinations. In a nutshell, you can really get more done with hackers (who will seek to automate manual tasks as much as possible) while you can use enterprise developers in bulk to brute force through any problem.

To repeat the beginning of my post… this isn’t a rant. And I don’t mean to put “enterprise developers” in a negative light. This is all just some random thoughts going through my mind about the two cultures I commonly see in every organization I have been in. What’s your opinion?

 

Published at DZone with permission of James Carr, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Partha Bhattacharjee replied on Fri, 2012/03/09 - 3:05am

Can't agree with you more. There indeed are these two very distinct type of coders. Your assessment is spot on. However, like most of things in real life, things are not really only black and white. There are shades of grey. Your article got me thinking and I found myself riding both the boats. Personally I am a bit of a hacker. I love tinkering with software. I love reading, writing and talking software. But while it makes me happy, it does not pay my bills. Professionally, I must admit, I strive to blend into the job, whatever that is at the moment. My current job just happens to be in corporate world where they have to have enterprise (conforming) coders, and hence I am. So, I think this is also a factor of your job and not necessarily always a function of your personal preference. Nice article though.

Joao Cerdeira replied on Fri, 2012/03/09 - 5:37am

Excellent Post !! In the rigth moment!!

 

I'm struggling because I put myself in the hackers group but If I want to feed my family I need to be in the other group ....

 I love NoSQL and my home project are using them but in my company I use RDBMS.

I love Scala and Groovy and use them in my home projects but I have to use JAVA in my company.

I love Actors (gpars and akka) and use them in my home projects but I have to use thread pools in my company.

 

I think this is not the best way to work but ... I  haven't found a solution yet ... so I need to live in a limbo .... :D

Taruvai Subramaniam replied on Fri, 2012/03/09 - 12:01pm

I am sorry but this is a complete caricature. I have run several enterprise groups in my career and my colleagues would be shocked to be described this way. The article seems to suggest that 'Enterprise Developers' and "hackers' are two breeds apart where hackers are the learners and the adventerous ones and aren't afraid to use the command line and the Enterprise developers are stuck in the mud types who demand GUIs and standardization across the enterprise to touch anything new. Hardly. If you have a responsibilty to develop and maintain large clusters of mission critical applications, it is forgivable if you are cautious and conservative in how you approach things. But Enterprise Developers do push for new ideas. In the right circumstances enterprises do use MongoDb. I have been in enterprises that have developer forums, where developers push to use the latest JSR something and the change happens if we can demostrate the benifits.

 

I am sure there are places where the enterprise devolopers are as you describe but don't tar everyone with the same brush.

Darryl Parks replied on Fri, 2012/03/09 - 1:33pm

Interesting article James.  I think I'd change the perspective to Innovators vs Enterprise Developers (9-5ers).  Personally I think I fit somewhere in between.  When I think of 'Hacker', I think of the guy who spent a week hunting down a Tomcat bug instead of doing his assigned work or the guy whose code is 'Hacked' together. 

I, like Corporations, at the end of the day need to put food on the table.

Mark Unknown replied on Fri, 2012/03/09 - 1:40pm

Corporate Developer would be a better description.

Nico Mommaerts replied on Fri, 2012/03/09 - 3:47pm

 

+1 for Taruvai 

It's not unless you have been at the same corporation for a few years, and had to live with the consequences of your choices (yes, that includes doing maintenance and bugfixing), that you begin to appreciate the "conservative" approach. I put conservative between quotes because I think it's not the exact word. It is more about seeing ahead and the big picture in a large IT department with developers of various skills having to support dozens of mission critical applications. Knowing there is more than the current development of a project to consider, like configuration management, operations, maintenance over several years, perhaps decades.

I understand what you are trying to say but imho that's a bit shortsighted/naive (I admit I used to think the same, doing <1 year projects all the time, but now I've been at a large bank for a few years, I'm starting to think differently) 

Oleg Kozlov replied on Fri, 2012/03/09 - 5:24pm

 

These are pretty extreme definitions and I would say there are few PROFESSIONAL developers who would fall into either of the two groups as described above. And I would definitely not want to have anyone matching any of the two definitions from above working in my group/organization. The best developers would have traits from both groups: innovation - yes, trying out new stuff - there is no progress without it, but at the same time not sacrificing software quality and reliability just for the sake of being on the "bleeding edge".. the main point in professional software development is creating good useful and useable products - not an opportunity to play with cool new stuff, that's for weekend projects.. Hackers as defined above are usually good for writing throw-away software and keeping QA people employed.

Also, I would not call using command-line tools for software development in 21st century being on the "bleeding edge" - I would call it "getting stuck in the 70s and refusing to evolve"... In my mind  "command line hackers" are dinasours refusing to learn something new and sacrificing productivity. Yes, both VI and emacs, and TextPad developers. If you consider yourself a hacker and find that an IDE doesn't support something you need like a new great tool or framework - hack together a new IDE plug-in or submit a patch for a broken one, so that others in your group can take advantage and work with new technology - that's what I call "useful hacking" in professional world.

 

Ronald Miura replied on Sat, 2012/03/10 - 7:32am

What I see is those 'so-called hackers' come into the organization, 'push their innovative ideas forward', leave the company before the project is finished, and the 'enterprise developers' have to:

- figure out what the hell they did, because they've left no documentation behind;

- finish the project, that is, that 'boring' phase of fixing bugs, writing user documentation, help defining operation procedures, and actually shipping the product;

- hunt down really crazy bugs, caused by 'workarounds' the 'so-called hackers' did to make some 0.1-alpha lib they got from github (the new sourceforge, but much worse) to work the way they wanted;

- integrate the 'thing' that uses REST services (aka ad hoc JSON/plain text/CSV/binary responses to ad hoc HTTP GET/PUT/POST/DELETE/PATCH?! requests) to the other corporate applications, that all use boring XSD-defined SOAP messages.

I really like my IDEs and tools, because they warn me when I do something wrong (because, different from 'so-called hackers', enterprise developers do make mistakes sometimes). And I don't think being capable of program using vi is something to be proud of.

I don't really need a 'fancy GUI', but I need the management/administration tools my task (and the operation team) requires.

New, shiny NoSQL databases? That require you to write a Map-Reduce algorithm to extract a simple consolidated report to your manager, instead of a simple SELECT with JOINs and SUMs? That assume your application code is perfect, because they simply don't care about data integrity? Well, I'm sure they have their uses when implementing massively scalable systems, but that's definitely not the usual case in the enterprise. 100 users? 1000 users? 10000 users? Postgres will cope with it just fine. I'm not implementing Facebook or Twitter (and different from them, I do care about not losing any data).

And I do like trying new things, but in my pet projects. I only suggest the use of a new technology by my company if I've tested it enough to understand it, and see clearly its benefits and shortcomings. I don't like to use my payer's money to make my experiments (aka enhance my CV to get a better job).

Competent, responsible, professional developers will neither be on the 'bleeding edge', nor stuck with COBOL forever (well, some will). They will advance, with care.

Oh, and this was a rant by the way.

Lund Wolfe replied on Sat, 2012/03/10 - 6:08am

I have to agree with the previous comments.  I think there is a middle ground or reasonable compromise here.

There is the tool user vs programmer.  If the tool can't do it then they can't do it until they get an improved or different tool.  They can't problem solve or think outside the box.  You learn the tool or you learn the programming language, libraries, patterns, best practices, etc.  The first extreme is obviously a dead end.  This is very common, but I don't think it's fair to only blame this on corporate developers.

At the other extreme is what you are calling a "hacker" vs professional programmer.  The hacker may be experienced, smart and get things done, but leaves a legacy of programming languages, scripts, tools that the corporate/enterprise developers have to maintain going forward and the job skill descriptions for the development group will get longer until it looks like they are looking for a "jack of all trades, master of none" (an obvious red flag to potential new hires who think the company may have no standards and be clueless).

 Hopefully the corporate/enterprise developer is still able and empowered to pick the right tool for the job.

Andrew Spencer replied on Sat, 2012/03/10 - 10:19am

Yes, it's not about whether you use the command line or not (though there's definitely a correlation), it's about attitudes to risk and awareness of long-term viability issues.

I agree with most of the preceding comments, and I think that the answer to the original question is that, even in a corporate environment, youneed both types of people. The conflict that arises between the two tendencies, though frustrating to both, is a symptom of a necessary and healthy process.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.