ZenPayroll Is Not Hiring Hackers
zenpayroll.com
zenpayroll.com
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.
It is frustrating to see, but once a word comes into common use you lose control of it.
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.
The term "hack" extends to sloppy implementation. I wrote about that here:
http://paulgraham.com/gba.html
but the word "hacker" doesn't simply mean someone who produces hacks in that sense.
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.
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.
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.
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.
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.
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.
1) The original definition. Someone with curiosity who digs into the internals of systems, more or less
2) Crackers who 'hack into' protected systems
3) Someone who works for a startup that's "going to change the world"
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.
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.
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.
Do you need special sunglasses to see them?
A good developer with no knowledge of IEEE754 might do something like this:
float hourlyWage = hourlyWageTextbox.text.floatValue();
string hourlyWage[] = hourlyWageTextbox.text.split('.')
int hourlyWage = hourlyWage[0].to_int * 100 + hourlyWage[1].to_int
A "developer" is usually someone who just codes for money, isn't into it, and therefore probably sloppy.
The rabbit hole goes deep. Be careful when you think you've reached the end of it.
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.
Tim: That's what I said: you're a nerd.
Lex: I am not a computer nerd. I prefer to be called a hacker!