I’ve got a question which I hope you can cover in a future essay. I can make an argument as to why the two dimensions in your model are knowledge about the solution space an problem domain, but I’d like to hear your thoughts on why those are the two key dimensions. Another dimension could be proficiency in UML or Ruby, or attention to detail, or communication skills. Or perhaps you would bundle these into one of the existing dimensions, which makes me wonder how (other than conceptually) I could represent my knowledge about the solution or problem space as a single number.

This is not disagreement; I just want to understand your thinking on what comprises each of these dimensions and why these particular dimensions are chosen.

Regards,

-George

Aaron, I think you’ve captured the essence of what I was struggling with quite well in your comment. Just like the term “software engineering,” the definition for “hacking” changes based on context and might mean different things to different people at different times. The main point is that it’s wrong to think of “hacking” and “hacks” as being the same thing.

As an engineer, the romanticized hacker persona, the person who goes home one weekend and cranks out a pile of amazing code that “just works” but nobody understands, makes me nervous. But once I realized there are guard rails in place that help prevent this sort of unpredictable, super human behavior (and actually helps to make predictable, super human teams) – one example coming from agile software development processes – hacking becomes something far more positive.

Now, hacking to me is all about action and responsibility. It doesn’t really matter what context you put it in.

“Hacking” is, to me, a very ambiguous term. It means nothing until whoever says it gives some context or meaning. “I just hacked this together really quick” “He’s hacking my computer” “He’s a great hacker” “Open source needs more hackers”

I think, at the broadest level, hacking means using technology to do something with surprising ease. Hackers – as in Hackers and Painters – have this amazing ability to express themselves in code – it just flows and it seems very easy. Hacking – as in script-kiddie, black-hat/white-hat – is about bypassing cyber-security barriers with surprising ease. Hacking – as in life hacking, brain hacks – is using tricks or technology to make self-improvement, or productivity, or learning easy. Hacking – as in hacking it together, quick and dirty – is sacrificing quality (readability, cohesion, tests, edge cases, ux…) to make writing a program surprisingly easy.

Old-school style hackers are a little of the first and last definition. They are very productive and know a ton about a system, but also have a willingness to write some code that nobody else will be able to follow, but which takes advantage of this and that side-effect to Just Work. Hacking on an open source project just means programming; the etymology comes from open source’s past and it appeals to people enough that it hasn’t gone away.

I guess I would say that “hacking” /is/ a dirty word. Not because “hacking” is bad – each definition certainly has a time when it is useful – but because “hacking” has so many different meanings that it’s not clear what you’re trying to say.

lovely thoughts, lovely blog, thanks,

Alistair

You can also add Pseudo-Architects:
1. One Fang: Those who are experts on one technology or platform, many years of experience, and know about architecting, but lack the rest of the one mile wide, one inch deep knowledge.
2. Dark side forcers: Those that know all of one side (IT) but lack the business and process insight.
3. The promotional ones. Those that went up the promotion ladder, and found that the next step after senior engineer was becoming an architect, and are promoted just because of years and experience (and to be able to pay them more).