I'm embarrassed to see such nonsense coming from a company we funded. A hacker is not intrinsically someone who throws things together to see if they'll work. The phrase "kernel hacker," for example, doesn't mean someone who writes OSes in that way. It means someone who is deeply familiar with OS internals.
I didn't read it as ZenPayroll trying to redefine what "hacker" means. Rather, they are simply stating what "hacker" typically describes in the context of a job board. In my experience, their described usage is pretty common, especially among hiring posts for startup jobs.
Hacker in the MIT definition of the word emphasizes cleverness and playfulness, and I think this is how most people (including the HN crowd here) usually mean to use the word. I should note that the term 'kernel hacker' has more or less developed on its own, separately, as a phrasal noun. One could very well argue that the definition of 'hacking' extends to sloppy implementation methods, so calling the logic in the submitted post 'nonsense' may be going a little overboard here.
While I agree with the notion of the word as you're using it here being material, it's disingenuous to ignore that "hacker"—in common usage—is constantly fighting with going the way of "ninja rockstar". (Is this better than going the way of "cracker"? Who knows.)
It seems that as soon as a term becomes an HR draw a flood of overinflated resumes comes quickly to erase its meaning.
Hacker the way you're using it is, I believe, a term bestowed upon someone by another, more universally recognized hacker. In that way, I don't think it's possible for a company to broadcast that they're "hiring hackers". By definition, you have to know who's a hacker before you can approach them.
It's use in marketing for hires is thus pretty much dead on arrival.
Unfortunately, the meanings of words change over time. "Hacker" in the general usage has come to mean throwing things together quickly to see if they'll work.
It is frustrating to see, but once a word comes into common use you lose control of it.
If you take a look at the HN jobs page, you'll see that's not true. Of the companies looking for "hackers" one is doing document signing and the other is writing healthcare software.
I think this is an issue of a semantic mismatch surrounding a buzzword. A kernel "hacker" and web "hacker" have different flavours. I can see where they're coming from against certain interpretations of the word, but they should have been more specific.
opened the comments just to see if pg had chimed in on this. glad you came in to clarify. thank you.
this is somewhat offensive as a hacker -- moving fast allows me to iterate, and several iterations is wayyyy better at trying to build something perfectly the first time. even if you want things to be perfect, you should hire hackers. just have them iterate before you do new releases.
I'm the CEO of ZenPayroll and I want to apologize for any misunderstanding with this post. Our intent was to highlight the business critical nature of payroll and the fact that we spend a lot of time making sure things are done correctly.
There are many definitions of the term "hacker" and I strongly believe there is no single right way to build software. Every team has to find the approach that's right for them and I want to sincerely apologize to anyone that was offended by the terminology we used.
We're proud to be a part of the YC and HN community, and many of my teammates are avid participants in HN.
If anyone wants to chat more with me directly, my personal email address is josh@zenpayroll.com.
I think you messed up with this post. You've apparently alienated to some extent one of the company's best and most prominent friends. And I believe most of the post's readers will feel you've mis-defined what it means to be a "hacker".
IMHO, the thing that makes the post compelling isn't what they claim they aren't hiring (hackers, of course), but the detail they go into about who they want to hire.
It's annoying to me when job descriptions like "hacker" or "rockstar" get thrown around, mostly because they tell you nothing about what a company is actually looking for. If you're looking for a hacker, are you looking for someone who can conceptualize problems quickly? A person who feels OK editing a production database directly? Heck, most nontechnical people will assume that "hacker" is probably some sort of security vulnerability tester. The problem is that I'm only some of those things - and, frankly, nobody is all of them.
What's impressive to me about this post is how much time they spend stating the things that they do value, and why they value them. That's much more meaningful than the headline about who they aren't.
This is such a welcome change. There's nothing wrong with "hacking" and being a "hacker", but it truly does connote the idea of fiddling with something until it works and then saying "tadaa!"
As a developer (and sometimes developer lead), I strongly prefer a process wherein "hacking" is only the first step. As the old adage goes:
1. Make it work
2. Make it right
3. Make it fast
"Hacking" is only step 1. We've all seen the results of a codebase where there is no step 2 or 3.
I don't know if I agree with that adage. I think "Make it right" should come first. It's very easy to assemble perfectly constructed, but not fully functional, pieces of software into a coherent piece. It's comparatively very difficult to "fix" something that already works, both psychologically and practically.
I think if you start from "making it right" there is a bigger chance of not getting anywhere at all due to the tendency of over engineering the solution. Can't speak for everyone, but I've seen this hapen quite few times.
I think as long as you go with modular design choices, you have the best of both worlds. You apply those three steps to each component in turn, and on the system as a whole.
I don't think the whole project should work like that, I think the developers should work like that.
Example: I want to make a node.js push server. I've never made a push server, let alone a node.js one. The first thing I'm going to do is make an "echo server" just to verify I understand what I'm doing. If I'm doing this for Unity or Flash, I'll quickly learn I need a separate "policy server" to even make this work, so I'll hack it together until it works.
I'll then iterate on this until I have a client sitting there and at random times it receives "push events" and reacts to them by printing something to the console or lighting up something on the GUI.
This is Step 1: I've hacked it, I made it work.
The point is that I wouldn't dare push my changes to everyone else yet. I'm going to iterate a few times, add a couple more of the features I know I'll need. I'll quickly discover the abstractions I need for this to have something of an architecture. At this point all the little nitpicky things and API calls I needed to do just to "make it work" get put in their proper places. Build scripts are made or modified. Tests are written.
This is Step 2: I've made it right. I haven't overengineered it, but I've expressed my solution in terms of the abstractions that make the most sense. I can bring in my experience outside of this specific problem to determine how far is too far. YAGNI and all that.
Next, I might throw a wild amount of connections at it. I might have it generate as many push notifications per second as it possibly can. I'll find some crashes, some resource leaks, and some REALLY naive, slow code that an hour ago I thought was OK. But that's alright, it's almost never the abstractions that are slow, it's an algorithm that needs to be improved or replaced, or an API I didn't quite understand.
That's Step 3: make it fast.
When all is said and done, I probably have 10 - 20 commits in my local repository. The first ones were absolute brutish hacks. The middle ones were factorings and abstraction exploration. The latter ones are performance tweaks and polishing.
This never gets pushed to anyone else, it's my private experience and workflow. These commits all get rebased on top of everyone else's finished work and squashed into one commit. I will still HAVE my local history, but nobody else needs to know or care that version 0 of my push server was held together with duct tape and bailing wire.
When a whole team works like this (and if you're lucky enough to find a team that can), really good things happen. "Hacking" is still involved, it just turns into "engineering" by the time the code has to move out of my basement and start paying its own bills.
I understand both points of view on the usage of the term "hacker" but I think most people are missing the key point of the post.
Payroll is incredibly difficult to do. Even more so to do well. Having spent many, many years in the space I can honestly say that it is one of the most taxing systems I've ever been involved with.
A lot of startups and the folks that are interested in them are looking for cool, hip and fast moving projects to jump in and out of. For people of that mindset, payroll is one of those fields where you will be consistently frustrated.
It is filled with thousands/millions of a little one-off rules (per employee, per state/province, per country, per vertical/horizontal etc. etc.) that it can drive a type-A go-getter insane. I think it is better to get that out of the way first before possibly attracting the wrong type of talent.
Words tend to change meaning over time. Some words fade out of usage, and others get invented. Such is the nature of language, I'm not sure there's much point in getting upset about it.
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.
It seems they are confusing hackers with hacks. I've often found that hackers deliver better quality code than process hacks. It's probably going to be a hacker that finds out for you that you have an Xss problem that is exposing your clients information
That said, I really like their sentiment; our company is filled with shirts and signs that say "Build" as a contrast to "Hack," because some things are actually important to do right, not just fast.
It's essential to get rid of all these hackers who just slow down the dev process with extra unnecessary code. After all a quick unit test will show that there's no benefit from all the extra work of storing currency values as cents.
And then the developer with ISO 4217 experience realizes that splitting the input on '.' doesn't cut it. The Indonesian rupiah is formatted 1.234,56; the Japanese Yen is formatted 123,456; the Lebanese pound is formatted 1 234.
The rabbit hole goes deep. Be careful when you think you've reached the end of it.
Well, while the developer might have cased a few rounding errors, the people with an hourly wage of 6.8325 are in for a nice bonus paycheck the month the hacker starts work...
Several posts are talking about 'hacking' and the meaning thereof. In my mind, it is pretty simple - it's a reference to Zuckerberg's "The Hacker's Way", which goes to considerable length talking about there being no need to get it right the first time, just prototyping and releasing something to see if it works, and so on. Great for Facebook and the like (debatable, but I digress); a disaster for payroll apps, dialysis machines, and most of the rest of the engines of our economy.
Fair enough, but you may want to consider hiring a designer who can make the text on your website and blog legible on systems that aren't retina MacBooks or similar.
The low contrast between font and background (especially on the site proper, where it is mostly grey on grey, more so than the blog) combined with the font's thinness makes the text really fall apart when viewed at lower resolutions or on non-IPS panels.
I thought it was good too. It stands in great contrast to a series of hiring posts from another payroll startup earlier this year. Those posts emphasized the exact opposite - I think one even talked about developing on the production branch - and saddened me as a result.
you haven't lived until you've put pdb statements directly on a production machine and kept restarting the web server to catch a bug after days trying to catch it the normal way.
I think it's kind of hilarious how these guys are badmouthing hackers as slinging things together, and then go on to aggrandize the government and payroll systems. Most systems are slung together with lots of duct-tape, and I don't think government/payroll is an exception.
Hacking is yielding an output from something other than the basic expected output. That doesn't mean it has to be thrown together, or done in a non efficient way. Hackers are immensely intelligent people, and if they're not then we must be battling over semantics.
