He then spends the next three years writing software to import and export CSV files into various other formats. XML figures heavily in his job. Java is of course the only programming language allowed, due to corporate rules.

But come on, I think we all know what point the article is really trying to make: You can run off and start writing code to some spec in your head; or you can spend a little time upfront finding out what the business needs and users' needs are before hitting the keyboard.

It's not really about putting down "hackers" or lifting up corporate developers. It's about the approach you take when you're building an application that solves a given business or user problem.

When you're writing code for someone else, it makes sense to ask questions, lest you create something that doesn't actually meet the person's needs. When you're experimenting or just writing code for yourself, by all means just hacking away sometimes makes the most sense.

The example in the article is obviously stretched, but getting feedback on your work isn't always a bad idea. Getting feedback from users, other hackers, or from business people can help you understand what your customers want. I'm not saying you should always follow their advice, but you should definitely listen and make your own decision. If you're at a small startup where you don't have business people, listen to your users instead.

The original, true meaning has been lost: nobody I know uses this word it in's original context. A "hacker" these days means one of these three:

1. Programmer (or a manager) who prefers quick&dirty hacks that can't be maintained and, after accumulating into a critical mass, tend to bring the overall project progress to a halt.

2. Someone who breaks into other people computers, steals their personal porn, collection of cat photos and, of course, credit card numbers.

3. The other, non-business type of founders of "Internet Startups". Often not having an MBA, or simply a possession of "Python in 21 days" automatically qualifies you as a "hacker".

And since majority of people use the word in one of those contexts, I figured why bother... BTW my cat is a hacker too: his portfolio of hacks is growing every day.

If you weren't a hacker in the last decade, you're now a hacker in this one!

Part of writing great code that, as a hacker, one can be proud of, is to understand the purpose of the code. Otherwise, there's no way to tell whether the code is great.

In fact, in my experience, "Developers" (as opposed to hackers... if such an opposition is warranted) are the ones who are likely to over-engineer a solution by building things they think are needed (because they're hinted at in the waterfall-produced spec) rather than questioning every single requirement directly themselves and then producing a much smaller piece of code that does what the business actually needs, rather than what they said they needed.

What he's saying, in fact, is that he prefers developers who are capable of doing analysis work to those who aren't.

Thanks, far better way to put it than the OP. And Alan Perlis agrees: Programmers are not to be measured by their ingenuity and their logic but by the completeness of their case analysis.

http://www-pu.informatik.uni-tuebingen.de/users/klaeren/epig...

To a large extent, yes. At the same time, a piece of code can be elegant and beautiful in the same way that many mathematical proofs are elegant and beautiful, even though they don't do anything immediately useful.

Ah, he has learned the Joel Spolsky secret: with contrived examples, you can prove anything.

To give Blub programmers the warm-and-fuzzies, one assumes...

And this is where I think the article falls flat on it's face -- In my opinion, I think one of the key features of being a hacker is the ability to look at a situation, analyze what you need to build, and come up with a minimal and elegant solution within the constraints that you determined. That requires communication and analysis.

It is a good reminder, as often we're going too deep into the rabbit hole while writing code, forgetting in so doing the real business requirement.

Working on the business core resonates with Agile principles.