Trouble is I've burnt a lot of man hours fixing shit that was done truly shitly by people who had a reputation for getting shit done... and then they move onwards and upwards to another role to create more shit that needs cleaning up before it can be really called a product and actually sold.
Yeah, a large problem in software engineering is that we have zero metrics for how terrible anything is. So, you have some engineers complaining about code written by another one of your vendors. Are they just unfamiliar with the technique/programming language being used? Or maybe the other vender is just too sophisticated and their engineers can just do better? Or maybe they were a bunch of hacks that threw together code until it worked well enough to pass the acceptance criteria needed to get the final milestone payment released.
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.
You know, I recognize that this is a somewhat serious discussion? But I can think of a few scenarios from experience where saying "the codebase is infested with demon spiders, can't do it" would be a satisfying thing to say in reply to unrealistic development requirements.
> "we have zero metrics for how terrible anything is"
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.
Yes, we do have Cyclomatic Complexity and it seems like that's it. Unfortunately, Cyclomatic Complexity is of dubious value. Even the wiki link you have here contains a section where they question the correlation between CC and the number of defects. Some studies say yes, but it looks like total program length is also correlated and sometimes better. Or in other words, line count might be a better metric than CC, which isn't exactly a ringing endorsement.
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.
I don't see this as an ethics issue, but just a trade off and given how long employees stay in a role, there is no long term. I can do both. "Do you want carefully tested code in 3 days or do you want it tomorrow?" And whenever I have put it to any non-technical product manager or business analyst, 90% of the time the answer is "tomorrow."
Product Managers get a reputation for getting shit done too by encouraging this.
Exactly, I think its more like, capture 80% of the value tomorrow, or capture 0% until day 3, where it now becomes >80%, but only immeasurably so in the eyes of the program. There will be future risk to that work that was done in 1 day, and that's where the tradeoff comes into play.
I always thought is was more of a semantics things. For example the article, and all the comments in this thread at this time, don't define the word "done". I am pretty sure we're not all using the same criteria for "done".
One thing I've noticed about "get shit done" people is that they quickly become the poster child to management for "Dirty Deeds Done Dirt Cheap".
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 worked at a very large telco for 4 years, and you just described a few of the people I worked with better than I ever could.
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.
Whoa, hold up, if someone made a mess and then cleaned it up, that would be just fine. Great even. Almost nobody does that. Around here there are people making messes but getting shit done, people cleaning things up but looking like they’re getting nothing done, and people who actually do nothing. Somebody who gets something done AND cleans up the mess is automatically top tier as far as I’m concerned.
There are those who forge the path and those who finish the paving. Both types are required as it's exceptionally rare to find people who can consistently do both.
I can do both (and have), but it really is a case of time constraints.
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.
> 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?
In my experience; every time I've shown a quick prototype that 'mostly' worked - that went into production.
Yep. That's why you have to give management the full disclaimer and sign-off so they are aware of the risks of launching a prototype as if it was production ready. The decision and ramifications of their decision should be on them, not the devs.
Re: Ramifications - management tends to be fine with asking me to prop up a POC-as-production service for years after the fact with duck tape and bubblegum.
A positive use case that still matches your criteria:
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.
The reason startups get large amounts of funding is because they are expected to grow exponentially.
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.
At a big company, or in a complex market, project or ecosystem - People who “get things done” have to:
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.
Even at a "startup" those turf battles emerge. At one company I once had nothing to do so started to help someone on another team automate work.
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.
God I hate hearing this. I once worked at a company where it wasn't allowed for 2 programmers to be at 1 computer ever. Programmers were never allowed to go to another programmers desk to work on something together or discuss something. Because it was "wasted time".
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.
Everything in the list of "Inability to get things done" is something someone with ADHD struggles with and can be successfully managed in the right environment, but it sounds like this person would fire that person without reflecting on the environment they've created and how that person experiences it.
Environment can absolutely influence people’s ability to get things done. That effect may be amplified by ADHD, but it’s not unique to ADHD.
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.
I didn’t say the employee has no responsibility. This article makes it sound like the person is completely unwilling to work with anyone who isn’t perfect.
Thank you, I've felt the list was heavily something a person with ADHD struggles with as well. In the right environment, ADHD people can shine brilliantly and beyond any expectations.
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.
It's not about being human or not. In a very early stage startup you just simply cannot always afford the investment (time and/or money) needed to create a flexible enough environment to support someone who struggles with things like staying focused or working at a fast pace.
And that's okay. Startups are a little over-romanticized anyway.
> someone who struggles with things like staying focused or working at a fast pace.
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.
Perhaps ADHD comes in many forms and severities. My wife has ADHD and her ability to "hyper-focus" is about as good as my ability to breath under water.
My experience of ADHD is that I hyperfocus on work because it's interesting. I'd basically do the same thing without medication, but I wouldn't be able to do my laundry or cook dinner at the end of the day because I'd be exhausted.
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.
This is my favorite one: "Did the candidate respond to every email from me quickly?"
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?
No, but its a very common thing for people who have a reputation for getting shit done to do. Such reputations aren't built on actually getting shit done (and especially not on getting it done well), but on knowing how to present the image of someone who gets shit done. Responsiveness, both because of the impression it creates on its own and because it provides the opportunity to instantly begin image management when a concern arises and before other input has been received, is central to that.
I’m always amused that people think they can just “hire great talent” by instinct and sheer force of will.
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…
"It was surprising how honest some (very smart) people would be on this. E.g. "I am average compared to other engineers". For an early stage startup, average is not enough."
Well, they want better than average liars. Could go either way.
People have definitely found ways to turn PG into a monster, so I am prepared for anything... but Elad Gil? That would be a first, so super excited to hear which parts rubbed you the wrong way. If possible, try to keep the context in mind (early stage startup: 5 people with less than 12 months worth of runway).
I didn't think it was satire, but I'm at the point of my career where I wouldn't want to work for a company like this.
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.
I feel like HN has become a mecca of FAANG workers, laissez-faire engineering that complain about this and that, look down on startups as slavery, hardwork is considered right-wing ideology and perspiration is toxic.
I wonder if HN has become a parody, have you considered that?
I've been doing startups since 2001, with brief stints at larger places due to acquisitions, and then a sojourn at a FAANG. Something that irritated me well before Hacker News existed, and manifested as Hacker News came into being, was the performative nature of startups. By that I mean all the boxes that startup founders would tick in order to be seen as a 'real' startup. This would create an excessive focus on superficial aspects of a company's culture: things like open plan offices, underpaying employees to keep them 'hungry', employees work 24/7 churning out code... In my own experience I never saw these things actually improving a startup's output. And along side that were many experiences of actual employee exploitation: promising employees the moon on equity by obfuscating their actual stake, shaming employees who did not conform to the founder's superficial sense of a productive programmer, etc.
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.
HN isn't nearly as bad as some "open" source projects, whose code and infrastructure has been completely taken over by seriously under-performing but power-hungry Microsoft, Google and Facebook employees (Amazon and Apple are less prominent here).
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.
Maybe the startup ecosystem has just burned a lot of people? Startups seem great for the owners. But for the employees, they can easily be a terrible deal.
There are just so many more Big Tech workers than us scrappy startup people reading and writing here than in the early HN days, and frankly, we have much more to do that keeps us too busy to post on HN as much as they probably have. Yeah, I said it.
Look, I fully support lots of vacation, staying happy, diversity, avoiding burnout - all the things big tech workers rally for. But HN offers zero optimism about solving hard problems, joy of discovery and innovation, struggling through challenges and facing them head on, cooperating with others, leadership and straightforwardness, etc. It's become a cesspool of big tech agony, mixed with social drama, activism and shunning down people that are looking for inspiration. Used to be not like that and it is affecting people like you and many new brilliant people that see no hope but to get a cozy gig at FAANG, check the stock market everyday.
Anecdotally, I used to get sucked into HN for hours because the discussions were good. Now I scan and many days don't find a single decent discussion. Lots of Rust vs Go and politics under the guise of technology. Then again, maybe this is reflecting our society, which is being eaten alive and conglomerated.
I am embarrassed to admit that many years ago, I wasted one of my few moments with PG to make the dumbest suggestion ever - in my mind, HN could make some minor SEO tweaks and easily acquire a ton of new traffic, which would help YC get more exposure. He just smiled and didn't say anything. I knew right then and there why I was wrong, but the true extent of my stupidity has only been recently dawning on me.
HN is no longer the site you're looking for. It's no longer the site I'm looking for, either. That irritated me to an unreasonable degree for a while, but I just accept it for what it is now.
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.
Other than the Beta redesign, /. _the site_ has always been good. The content has been consistently interesting.
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.
> optimism about solving hard problems, joy of discovery and innovation, struggling through challenges and facing them head on, cooperating with others, leadership and straightforwardness,
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.
I've felt this recently, was there a wantrapreneur-exodus I wasn't aware of? Where are all the tales-from-the-trenches posts? Where did the hustle posts go!? Was there a "startups considered toxic" moment that I missed?
I read lobste.rs but don’t have an invite. It’s absent of politics and ideology discussions. Pure tech as far as I can tell. “What are you doing this weekend?” threads are fun.
Meh. It's a very small subset of tech and has all of the problems of '90s IRC (unnamed rules, cabals of power, cliques of opinion, minimal accountability) with none of the structure that more "modern" organizations (like OFTC) embraced. It's focused mostly around programming languages, tech minimalist culture, and open source culture, though they won't write that anywhere on the site. Anything else is either ignored, flagged, or shunned. Opinions there are strongly held, and opposing them will result in people being nasty to you. I largely view Lobste.rs as an anti-pattern of how to run a community.
This is why some people think software engineers are not real engineers. No one will ever ask a structural engineer to build "it" quickly and cover 95% of the failure cases.
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.
Reading the authors section on culture fit I found this:
"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.
If I were working at a startup and this was the content coming out of it, I'd assume they'd be hiring competitive sociopaths and the risk of politicking and aggressive diluting of shares would go way up even if it did succeed.
This article describes the kind of person who launches things, meets deadlines, and is comfortable creating lots of tech debt in the process. Perhaps it _is_ a good idea to hire lots of these people at a startup, but I definitely prefer working on a team with more of a balance.
People seem to be missing that this is targeted at an early stage startup. Honestly, an early stage startup will likely fail without people who are focused on GSD to an unreasonable and unhealthy degree.
I was told in a screening interview once that they don’t really need people who can solve problems or write maintainable code, or who understand software design. They said the tech lead will do all that. They said they just really needed people with framework experience. I was at a loss for words
Half a day coding exercise? Mate you're not hiring the best, you're getting for people who will tolerate a lot of crap. Which it sounds like you'll need.
I've been in one of those interviews with a person with really bad English. It's a preview of how painful working there is. I just quit the interview after hearing the first question, and a few days later got a nice well-paid job at a larger company with a 30min interview about my previous experience.
I've definitely had similar experiences with companies still at the "handful of employees" stage. If I'm actually interested in what they're doing, I enjoy the exercise. If I'm not actually interested, well it was an easy way to learn that before wasting their time or mine.
I've heard of (clever? sociopath?) executives that would do this periodically to get fresh perspectives at a cost of zero dollars. They had no intention of hiring any of the candidates.
Sure. But every startup, no matter what stage, can benefit from mature, thoughtful people, who may take a little longer to get things done, but they will be done better. They are also the people who will ask the right questions, introduce positive paranoia, etc. There is tension with the GSDs, but it's for mutual benefit.
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
Wow, I really appreciate all the comments here. My takeaway here is that there is no formula or framework for hiring, you just have to spend the time it takes to hire the right people for your company. Period. Some of the insights in this blog post is useful to me, some aren't. The comments here help balance me out.
> I would often straight out ask people how effective they were at GSD, and how did they compare to their peers? It was surprising how honest some (very smart) people would be on this. E.g. "I am average compared to other engineers". For an early stage startup, average is not enough.
Why do you assume that people answered accurately, rather than depending on their confidence level/interview knowledge?
> Ask the candidate. I would often straight out ask people how effective they were at GSD, and how did they compare to their peers? It was surprising how honest some (very smart) people would be on this. E.g. "I am average compared to other engineers". For an early stage startup, average is not enough.
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 probably could, and people would volunteer that they aren't that good at coding and therefore screen themselves out (assuming you need people who are good at coding).
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.
I think this is an even bigger issue: A cultural one. We live in a (western) society where NOT getting shit done has become the norm. Often things don't get finished at all and if they do they take forever. There seem to be only few companies/founders (have to mention Elon here!) that are able to break this habit.
Many of the replies in this thread talk about empathy, and I get where they are coming from. The problem is, if your priority when hiring was empathy you would just offer the job to everyone you interview. It's true, everyone has the ability to grow and learn on the job, and once you hire someone you should be empathetic and help them grow as best you can. But it's asinine to suggest that watching for the signs and markers described in this article during the hiring process wouldn't be helpful.
Might you also argue that empathy is putting people into roles they would flourish in? That hiring just anyone might be placing people into situations they would ultimately be unhappy with? That you may need to remove or even fire people when that role changes and this person isn't able to change with it? That putting the wrong person in the role is an opportunity cost for a better fit being happier with that position?
