> The second developer receives the assignment and spends the next 30 minutes talking to the business to see how the software will be used and what value it provides.
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.
Or he spends the next year producing design document after design document, always being sure to fully discuss the implications of each new requirement, but never writing any code.
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.
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.
Actually UML is the only programming language allowed, so he had to code it all up in the proprietary CASE tool first and then generate the Java from that.
After smoozing the bigwigs, he goes off and tries to figure out how to install Eclipse for 3 days, and gets ever more creative for his reasons for not producing code, eventually using his networking (people) abilities to carve out a niche where he doesn't have to produce anything but still gets paid, and generally tries to have as many meetings as possible, where he shoots down ideas that might have a small chance of causing him to have to produce something. Developers are CANCER.
It's a bit of a fallacious argument, based on some dodgy definitions of the key words. "Hacker" does not equate to "over-engineering-prone developer who likes to live in his little walled garden".
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.
"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.
There's a fallacy more.. The business never, ever, ever puts forward so simple requirements, and if they did, the only right way to respond would be to just f*ing do it.
The business has a problems that's more like, "all of these CSV files clutter my desktop, I need them cleaned up". The hacker that then goes home and makes a Perl script that parses and archives all the files in a relational database need not apply, while the guy who ventures out to figure out how these files got there in the first place and how to fix the broken process should get the job.
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.
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.
Hmm. The hacker / developer dichotomy being set up here just doesn't stand up to scrutiny. At least for the values of "Hacker" with which I am familiar. I definitely consider myself a hacker. But I also know (and practice!) the value of working with the people who will actually use my software, so that I can make them happy. One memorable moment for me was the gratitude I received from a user who had made a request for a small feature. It was only an afternoon's work for me, but it saved her one week a month in make-work. Requirements analysis is a given in my mind for true hackers. Make something people want.
I hate the presumption that "real" developers need to know how to distill requirements. That's what you learn in school, but it isn't necessarily true, it depends entirely on where you work. I never talk to customers where I work, and generally for the requirements we decide as developers we do as a group, we don't need to trick non-techs into telling us what they really want. Somebody at every company is going to have to do this, but it doesn't necessarily have to be the developers
The developers still have to interact with people to figure out what they need to create. The people that they're extracting the information from may still be techies, but determining what you need to build is still key.
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.
So they had one guy who didn't ask any upfront questions, but delivered something. They have another guy who did ask upfront questions, but didn't deliver anything. Why choose the second over the first?
> The second developer receives the assignment and spends the next 30 minutes talking to the business to see how the software will be used and what value it provides. After he's gotten the information he needs he says thanks, but instead of letting him leave, the CTO offers him the job on the spot.
Ah, he has learned the Joel Spolsky secret: with contrived examples, you can prove anything.
I think I am giving up on this "hacker" thing, there are just too many possible meanings and different people perceive it differently, thus it makes no sense to use the word in real life anymore.
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.
This article is like writing about white and black and pretending that there's no such thing as grey. Ninety-nine percent of hackers/developers would have attributes that put them in both categories to varying degrees (by almost any definition you care to give the two terms). By the way, since when did "hacker" start meaning "no real-world development skills"?
Attacking the word "hacker" will definitely get response from the YC community. I think the YC community at large is in love with calling themselves "hackers".
It is sad that this discussion is about the definition of the term 'hacker', instead of the article's topic: some programmers care about the business core (a concept also touched on by Eric Evans (DDD)) while some others don't.
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.
32 comments
[ 4.6 ms ] story [ 31.8 ms ] threadHe 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.
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.
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.
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.
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.
To give Blub programmers the warm-and-fuzzies, one assumes...
Ah, he has learned the Joel Spolsky secret: with contrived examples, you can prove anything.
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!
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.