Hire for the Ability to Get Shit Done (2011)
blog.eladgil.com
blog.eladgil.com
IME, people who have a reputation of getting shit done tend to:
(1) Have little ethics around quality of work, and
(2) Have their greatest skill in self-promotion which is used to sell their lack of attention quality as a pragamtism.
People who have a reputation for getting shit done well, OTOH...
Product Managers get a reputation for getting shit done too by encouraging this.
Managers go directly to these people for sketchy, half-baked ideas done in 3 seconds that can boost whatever metric makes them look good to their bosses.
Of course, it's always an unmaintainable spaghetti mess. Over my years in the industry I've come to realize these types of people are really damaging to engineering culture within an organization. They represent a quick buck over quality.
I once got a call from a Project Manager on conference with a bunch of VPs, letting me know I was now the sole support person for a new customer-facing product that went live that day.
On the call I confirmed with everyone listening there was no documentation for the entire system, no support procedures, nobody could tell me the name of the server or any credentials to even access anything, or what to do if anything went wrong. But there it was, dumped in my lap.
That PM always got a green tick for delivering projects on time, and got many promotions and bonuses.
So I let management decide. Do they want a quick prototype that is going to be unstable and buggy and difficult to maintain long-term, or do they want something solid that is well tested and stable and refactored and well-documented so newcomers can work on it easily as the team grows?
There are trade-offs. The quick prototype allows you to get something in front of your stakeholders that resembles the desired end product. This allows them to easily identify things that they missed, and allows them to quickly change direction if need be.
This can backfire really easily though, because if your prototype is too good, they will think it's a polished product that can be sold even though it's completely lacking tests and is duct taped together behind the scenes.
You have to CONSTANTLY remind them that THIS IS NOT A STABLE PRODUCT and that it still needs tests and refactoring and clean-up. A lot of the time, you will have to create the JIRA stories and advocate for this extra work to be done yourself, or else management simply won't prioritize it.
I've been a part of multiple startups with successful exits now, and they were all based on code that was rapidly prototyped and duct taped together behind the scenes.
Being able to pivot and adapt is more important than stability, when you are a startup.
But once the startup has been bought by a larger company, it's probably time to rewrite and refactor and stabilize things. Now that you have big clients and people depending on the systems, it's time to batten down the hatches and prioritize stability and longevity.
In my experience; every time I've shown a quick prototype that 'mostly' worked - that went into production.
One way to pass the buck is to just "hire on the ability to get shit done" and justify it with "well, the shit needed to be done and now it is."
I can see it working okayish in the short term. However, eventually you want something (or need something a competitor has) and the answer is "cannot be done because the codebase is infested with demon spiders." Meanwhile the "got shit done" people are either gone (if you're lucky) or insist that the only way to do it is to continue the nightmare development philosophy they created on their own that mixes ideas from shintoism and kabbalah into C++ templates. Every week they're "making good progress" but the features are going to show up exactly never.
There's Cyclomatic Complexity (https://en.wikipedia.org/wiki/Cyclomatic_complexity) but I think that's too low-level for what we really need. Cyclomatic Complexity allows us to evaluate one function implementation versus another, when what we really want is the ability to evaluate different architectures and designs.
Additionally, even if CC turns out to be useful, it is rather targeted. Basically, it's a metric to make sure you don't have too many if-statements[1]. Not as effective in our current OO/FP world where lots of decisions can be shunted off to an unknown object or lambda.
However, whether or not you want to claim CC is useful for non-if-statement branches, it definitely doesn't say anything about code that's bad because of bad variable names, or code that's bad because of deep inheritance, or code that's bad because the wrong abstraction is used, etc (which is kind of what you're already saying with your statement about architectures and designs).
[1] - So, I guess you could probably create a CC setup that is able to count linear independent paths that aren't if-statement related. However, both OO and FP allow you to setup scenarios where the execution path indirection is decided at run time (pass in a different object implementation or a different lambda). So you crash head first into the halting problem pretty quickly. [Not to mention, I've never seen anyone try to do this ... although I haven't actually been checking very carefully, so maybe there are tools that try to do this in a limited fashion?]
However, it's also debatable which linearly independent paths are bad and which ones are actually helpful. Like, I bet that TCP library call contains a ton of linear independent paths. But if you fix that by just vomiting your hand rolled communication protocol onto the internet with objectively less linear independent paths, then I can't call that an improvement in program comprehensibility just because the linear independent paths have been reduced.
Tech debt mills cannot grow exponentially. They grow quickly for a couple of years, then stop growing once the accrued tech debt slows down growth.
Once the 10xers/rockstar/ninjas that "got shit done" for years are asked to make things work for that missing "5% of the time", they will look for another job and disappear.
Tech debt mills should not be treated as startups. They are small or medium businesses that are not prepared for exponential growth, and as such, do not deserve startup-level funding. The obsession over "getting shit done" and "shipping" are traits of tech debt mills.
Sustainable growth and a long-term vision beats tech debt mill mentality.
Used to work with a really nice guy (everyone loved him). Wrote code really fast. It worked. It was scary code though.
When a customer had a crisis we’d send him in. He’d find the 10 holes in the dike and stick his fingers in. As soon as he went to work on something else the water would come rushing back in.
But that was ok. He’d stabilize things while somebody wrote a saner patch. What he did was usually a clue about the underlying problem.
Actually this wasn’t his only mode. You probably are running some of his decades old code right now.
I could use someone like him again.
1. Eliminate all discussion, information sharing or teamwork to avoid complex conversations or communication slowdowns or pushback (Try to form silos)
2. Attempt to dramatically simplify their work so it can be streamlined and done faster, perhaps by doing a very bad job or doing everything the way they want to do it
3. Continually step on political landmines or get into a lot of fights by accidentally wandering into someone else’s area through blind execution
4. Be incredibly sneaky and underhanded and opaque and do everything in a way that seems slimy
5. Have some unusually strong managerial backing to go plow ahead and run over any obstacles or objections
Startups are wonderful because there aren’t 9,000 people in the way claiming every square inch of space. At a big company, everything you do is a potential territory violation.
I used to be much, much, much more aggressive when I was younger. I just ran over everyone in my way and destroyed or avoided obstacles.
Turned my career into a giant heaping pile of wreckage. Get shit done at a large company turns out badly for your career I learned.
This is very temporary career advice. You’ll be fine if you do this at a small startup. Medium size and up, you will get zapped like cancer for doing too much of the above.
Set off a turf battle of resource allocation, billing, hours, and a couple cents in cloud systems. I had nothing to do, but a battle started over what I did. They fought over how to allocate time they had no use for.
It was also one of those companies that pulled the entire programming team into hour long meetings they didn't need to be in...
Maybe its just me, but a 5-10 minute conversation with another programmer can save hours of wasted time trying to figure out how something already works or how to implement something.
Employment is increasingly a 1-2 year stint where workers are swapped in frequently and you need to get value out of them before they leave. But it really screws over people who are not known factors or who might need adjustments.
And that's okay. Startups are a little over-romanticized anyway.
You might be surprised by the hyper-focus abilities of folks with ADHD.
Keep in mind that your perception is skewed by selection bias — you probably already know many productive coworkers that never told you they have ADHD.
ADHD symptoms are a multidimensional spectrum [citation needed], and so-called normal people lie somewhere on that spectrum. Making affordances for folks with ADHD is a win for everyone. For example: write meeting notes and assign action items, use a bug tracker, ask people if the process works for them.
Every manager should be sympathetic to their team and try to make a reasonably accommodating environment. However, it’s still up to the employee to take ownership and be accountable for getting things done. You can’t reasonably expect managers to constantly micromanage employees to extract work from them, nor can we expect companies to create perfectly distraction-free environments. At some point, it’s the employee’s responsibility to manage their own output.
It’s not just the employer who suffers when a team member is unable to complete tasks. The rest of the team has to step up and fill in the missing pieces or constantly watch over the person who can’t get things done. Eventually you start losing talent because your good employees are tired of doing a job and a half while some other employees are only delivering half of their work, and everyone suffers.
If they did, then they are living in their email, not getting shit done for their current job. Is that really the good signal that the author thinks it is?
Code machine go brrrrrr.
- Lack of urgency <-- wait, isn't that the manager's fault? (for failing to clearly communicate the timelines)
- Easily distracted. Heavy procrastinator <-- wait, isn't that the manager's fault? (for failing to provide goal clarity)
- Lazy / doesn't work hard. <-- wait, isn't that the manager's fault? (for failing to provide the right conditions and motivation)
- Starts but never finishes things. <-- wait, isn't that the manager's fault? (for failing to provide task boundaries)
- Lack of follow through <-- wait, isn't that the manager's fault? (for failing to clearly allocate task ownership and accountability)
- Argumentative. <-- wait, isn't that the manager's fault? (for not ensuring buy-in in decisions)
- Slow. (overcomplicating simple stuff) <-- wait, isn't that the manager's fault? (for failing to communicate requirements clearly)
- Perfectionist. <-- wait isn't that the manager's fault? (for not communicating priorities clearly)
I've seen a lot of shitty companies like this where the programmers are expected to do the management as well as the programming.
Sure there is skill to hiring, but a lot of what you can hire is determined by how desirable you are as an employer. If you’re a hot company, hot employees want to talk to you. Sound familiar?
IMO focus on a great employee pitch and make yourself known/visible to social circles populated by quality engineers. The match making process doesn’t need to be a coked out box checking session…
I wonder if HN has become a parody, have you considered that?
I find it's still a useful pointer to interesting links, but if I go into the comments it's knowing they'll be annoying. Align expectations with the reality and it's OK.
However, the _community_ has changed. I still read the headlines to get an idea of what is happening in the world, but the fine comments have been garbage from the moment Taco left.
Enough of us have been given speeches by corporate culture execs or flashy tech leaders making vapourware, so when we hear those words, we await a pile of nonsense to follow.
You can still say many things here that can't be said practically anywhere else on the Internet.
Sadly, like "open" source developers, startups are quite afraid of MAGAF as well, so they no longer talk as freely as they did 5 years ago.
I believe there is a lot more cynicism around now, because we're several decades into the whole startup thing, and such cynicism is often a good thing. Employees are way more savvy about looking into a startup's finances, business practices ( so many startups were built around the idea that regulations didn't actually exist...), and work culture before listening to the company's hype.
Not to mention that in my large company stints I encountered many people whose work ethic I found admirable. Really the difference between a startup and a large company in my experience, and the reason I prefer startups, is quite simply that startups are not large enough to experience the inevitable communication/hierarchy issues that come up when any group of homo sapiens becomes sufficiently large. I tend to get lost in my work and will work most of my waking hours, and that often isn't even possible at a large company because of the cross team orchestrations, while a typical startup has a big pile of things you can simply dive into individually and solve. You certainly can do that at a large company if you look for things to do, but I like my work to have measurable impact as well.
Well, they want better than average liars. Could go either way.
If I'm expected to make a 3-days homework exercise plus a half day live coding session, and then I'm expected to jump at their every whim too (respond email when it's convenient for them, honesty seen as a weakness, expected to be proactive but not too much or you become argumentative), I'd rather look somewhere else.
This reads more like "how to screen for people who will blindly follow your orders". And sure, if you have a small startup maybe you do want people like that. But as a developer I don't think this guide has my best interests in mind.
What this is, in my view, if it is taken too seriously, is the perfect recipe for instigating employee burnout in short order.
Okay, apples and oranges. It's actually okay for a team to crank out a prototype held together by duct tape, but you should move away from this mentality as soon as you prove the business idea otherwise the technical debt will sink you quick.
"Bonus points: financial stability. This could be a low personal burn rate, or ability to take a low salary either through a past financial success, being straight out of school so living costs low, or other means. This means the person may be more willing to take a low salary in exchange for more equity, which helps the company survive longer on less."
This makes me worry they have no respect for their workers and want cheap people the can bully into long hours, high workloads and low pay.
I don't know if you can read that much into the comment but it would scare me away.
Then putting it on a shirt for the ad agency people to wear.
Do people really do this as part of interviews?
Those very candid people who say they are average on GSD? Those would be my executives.
If companies were empires, "get shit done" translates into exploitation colonialism:
1) "Recruit" large amounts of people.
2) Assign them to bruteforce tasks. Set production quotas.
3) Punish individual agency, self improvement and free thinking.
We know now that exploitation colonialism is an inefficient and primitive approach to governance that fails at achieving what it was designed to do: maximize value. Instead, it just maximizes poverty and misery. The empires that used it lost and capitulated to the empires that didn't. And this happened for a reason: it's a greedy heuristic, not a real strategy, it lacks a long-term vision.
The poorest countries in the world are governed either in this way or a similar one (extractivism), and are often so weakened by this form of governance that are forced to become vassal states that exist only to be bullied.
It doesn't matter if you throw all your entire country's population to "get shit done" (e.g.: agriculture, mining). Maximizing value means you also have to invest in education, infrastructure, science, culture, etc.
Instead of telling your employees to work mindlessly towards a goal, tell everyone to believe in themselves, and pursue their ideas if they think they have value.
"It doesn't make sense to hire smart people and then tell them what to do, we hire smart people so they can tell us what to do" - Steve Jobs
Why do you assume that people answered accurately, rather than depending on their confidence level/interview knowledge?
lol, wait, if this line of thought works, why don't you also just ask them how good they are at coding, instead of wasting all that time doing interviews?
You definitely run the risk of not hiring people who are victims of impostor syndrome, but it's the same logic, and it would for sure apply to coding.