
ZenPayroll Is Not Hiring Hackers - tyre
https://zenpayroll.com/blog/zenpayroll-is-not-hiring-hackers/
======
pg
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.

~~~
selmnoo
This is clearly a case of semantic disputes.

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.

[http://en.wikipedia.org/wiki/Hacker_(programmer_subculture)](http://en.wikipedia.org/wiki/Hacker_\(programmer_subculture\))

~~~
pg
Has "Lisp hacker" also developed separately as a phrasal noun? "Unix hacker?"
"C Hacker?"

The term "hack" extends to sloppy implementation. I wrote about that here:

[http://paulgraham.com/gba.html](http://paulgraham.com/gba.html)

but the word "hacker" doesn't simply mean someone who produces hacks in that
sense.

------
joshuareeves
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.

~~~
pbreit
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".

------
sjm-lbm
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.

------
breckinloggins
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.

~~~
wyager
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.

~~~
breckinloggins
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.

------
purephase
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.

------
10098
I'm tired of the term "hacker" being thrown around this way. Authors just
attach whatever meaning they want to it.

[http://www.catb.org/esr/faqs/hacker-
howto.html#what_is](http://www.catb.org/esr/faqs/hacker-howto.html#what_is)

~~~
bcbrown
I also prefer the original definition, but I think you're fighting a losing
battle. I think in common use, there's now three definitions:

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"

~~~
10098
The third one is what annoys me the most.

------
mindcrime
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.

~~~
mjn
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.

------
lawnchair_larry
Perfect linkbait for this crowd.

------
fleitz
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

~~~
jdross
Hackers solve problems. Hacks defer them.

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.

~~~
moocowduckquack
_our company is filled with shirts and signs that say "Build"_

Do you need special sunglasses to see them?

~~~
Game_Ender
I sure hope that is a They Live [0] reference.

0 -
[http://en.wikipedia.org/wiki/They_Live](http://en.wikipedia.org/wiki/They_Live)

------
fleitz
Good call, imagine you had a task like taking the input from the form for the
employees wage.

A good developer with no knowledge of IEEE754 might do something like this:

    
    
      float hourlyWage = hourlyWageTextbox.text.floatValue();
    

While a hacker with intricate knowledge of IEEE754 might insist that everyone
do the following:

    
    
      string hourlyWage[] = hourlyWageTextbox.text.split('.')
      int hourlyWage = hourlyWage[0].to_int * 100 + hourlyWage[1].to_int
    

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.

~~~
jameshart
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...

~~~
fleitz
Haha good point

------
RogerL
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.

------
georgemcbay
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.

~~~
pc86
Weird that it works fine on my 6-year-old Dell laptop.

~~~
rhizome
You don't get any broken loops on lower-case 'g's?

~~~
nols
Not on my seven year old Dell.

------
seivan
I wish to see more job posts like this. Nice work.

~~~
scrumper
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.

~~~
aerolite
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.

------
aestetix
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.

------
Ravenous
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.

------
UNIXgod
Interesting. Maybe they should hire a small training department to teach their
programmers how not to be hackers.

------
polutropos
Lex: I'm a hacker!

Tim: That's what I said: you're a nerd.

Lex: I am not a computer nerd. I prefer to be called a hacker!

