41–50 of 58 posts
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 fa…
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 * 10…
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 see…
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.
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.
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 * 10…
I wish to see more job posts like this. Nice work.
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.
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 * 10…
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...
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.
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 see…
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.
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 * 10…
isn't the hacker the first guy and the developer with experience the second guy?