I wouldn't say that being a "hacker" or "hacking code" necessarily implies doing a low quality job, or anything of the sort. But from a cultural standpoint, there does seem to be a bit of a dichotomy between "hackers" and "software engineers", although I think an individual can be both.
When the day comes that Fogbeam can hire employees, my goal is try focus on hiring engineers more than hackers (with the above caveat in mind). I'd like to establish a culture of people who take a great deal of pride in delivering a well-engineered, high-quality product, that maximizes code reuse, maintainability, modularity and all of those other things. I'd even say I want people who value gasp process gasp, -- as long as the process isn't overly top-heavy, bureaucratic and burdensome.
I definitely wouldn't say low-quality code, or even messy code, but I agree "not software engineers" is a reasonably fair description.
Two kinds of hackerly code that I think are common:
The big, messy, system that you get to work through iteration in an unknown/exploratory problem space. This might be the most classic variety. IIRC, the term 'hacker' was coined, or at least popularized, in the MIT AI Lab for this kind of software, as they were famous for building some pretty monumental but hairy systems. The codebase of some of the big classic Lisp programs, like CMUCL, Emacs, or some of the Symbolics stuff, might fit in this category of hackerly productions.
A small, clean, and elegant program or system designed largely by one person. Fabrice Bellard's 'tcc' is a good example of this kind of hackerly production.
Those lead to pretty different end results, but they have in common a focus on individual creativity and/or virtuosity rather than method/process. I tend to find that style of programming the most interesting to read about and observe, but the point is well taken that I might not want that hackerly approach (either kind) applied to lots of software. Something like train control systems, or business rules, might benefit from something more boring and industrial.
When the day comes that Fogbeam can hire employees, my goal is try focus on hiring engineers more than hackers (with the above caveat in mind). I'd like to establish a culture of people who take a great deal of pride in delivering a well-engineered, high-quality product, that maximizes code reuse, maintainability, modularity and all of those other things. I'd even say I want people who value gasp process gasp, -- as long as the process isn't overly top-heavy, bureaucratic and burdensome.