Please maintain your professional social contacts!
It's fine not to have a native interest in that. But it's part of the job. No blog or bragging needed. No Linkedin needed even, if you really don't want that one. Catalog and maintain some minimal contact with these people who have seen your work: bosses, colleagues, juniors, vendors, consultants, anyone. Expose a few EXTRA people now and then, so they can see your work. This way, when you need to find a new job after many years hidden in just one department, you will have all these people who moved - sometimes frequently - and only wished they could have taken you with them at the time.
And that has nothing to do with "10x" - no matter the skill level you think you have, you'll be better off with a wide set of people who know you. "Know you" to any degree - often people will prefer you to going through the circus of interviewing for pretty random results.
It is interesting, the two best developers I know are on the polar opposite of each other, from the outside.
A: Started coding when he was 6 years old, was making 3D games from scratch at 12, and sold his first software at 15. Never went to college, as he was right in time for the dotcom boom. The man just loves coding, and always works on his side projects in his spare time, mostly software he finds interesting. At work, he's the closest I've seen to a mythical 10x
B: Hadn't written a line code before he switched majors in college. Went from having zero experience with programming, to being a straight A computer science student, finishing one year faster. Best student prize at university for masters, and then a Ph.D in record time. Writes flawless code, is a top tier architect, and just a machine. Doesn't write a line of code when he comes home (at least according to him), basically severs himself from work as soon as he leaves work.
> It is interesting, the two best developers I know
Over time I've come to appreciate the difference between people who are described as the best programmers and people who are best at delivering results.
Some times they're one in the same. It's wonderful when you work with someone who is both an excellent programmer and excellent and delivering results in a team.
Many times I've worked with or even hired people who are brilliant developers and praised as being very smart, yet they didn't deliver results as well as the average developer on the team who diligently gets their work done.
Looking back, some of the most stereotypically brilliant developers I've worked with have also been among the more difficult to work with. Not all of them, but quite a few. The two that come to mind have been bouncing from company to company for a long time. They'll always have job offers and be able to pass interviews, but actually working with them and getting good results is a different story.
One of them even founded a startup with a co-founder, but unsurprisingly they broke up less than a year into it. On paper he should be the perfect fit to get launch a startup product, but working with him is a different matter.
The brilliant devs I know who are great at delivering results usually find their way into good positions and good companies early in their career and then stay there for a long time.
> Many times I've worked with or even hired people who are brilliant developers and praised as being very smart, yet they didn't deliver results as well as the average developer on the team who diligently gets their work done.
Very smart programmers often have a very different way of thinking about programming problems. If the project structure does not accommodate for this way of thinking, brillant programmers can barely use their "superpower".
Also, great programmers often have a deep love for their craft, and thus be very opinionated about the best possible way of solving the programming problem at hand.
So my bet is:
- you don't have software problems that "need" superpowers (otherwise the average developer on the team would be of little use)
- you don't have a project structure that enables exceptional programmers to actually use their superpowers
- you already admitted that you are rather looking for people "who diligently get their work done"
Exaggeratedly: you hired a Fields medalist to fix your clogged toilet, and you are now complaining that the average plumber is much better at fixing it.
100% this. Nothing turns a 10x into a 0.5x faster than telling them they can't fix the horrible issues putting your api performance in the shitter under load, and instead they have to go help automate the QA build process.
> Doesn't write a line of code when he comes home (at least according to him), basically severs himself from work as soon as he leaves work.
I'm truly curios what percentage of programmers do write code outside of work. I'd bet the actually percentage is pretty low, especially those who've been at it for five years or more. I don't know that I ever did, except when I first started.
When I do interviews I like to ask candidates if they want to share anything interesting they've made, studied, worked on, or played with outside of their jobs. I explain their answer can only help, not hurt, as a non-answer is not a negative. It's simply an opportunity to bring up something that wouldn't normally come up during the work-history driven interview.
Very few candidates say they've done any programming outside of their jobs. At most, they share something like running Home Assistant on a Raspberry Pi and using Python to automate their house or something. Another common one is to hear about how they used an Arduino or Raspberry Pi to accomplish some small task.
Very few people say they have side projects. Of those who do, when I ask for details most admit it never went far beyond the idea phase.
So from what I can deduce, it's very uncommon for programmers to have true side projects that go beyond a couple git commits worth of code to solve some task, or an idea they had that they never followed up on.
I don't know how this can be true. Interviewing for a job is a zero-sum competition against the other candidates. If something isn't a positive, it has to be a negative.
It feels slightly disingenuous. Many engineers do their work with a sense of personal duty and pride. Should a drive for self-improvement be neglected because it didn't happen outside of work hours?
For the years I had paid employment I'm very thankful that I didn't make programming my hobby in addition to being my work. For the last 5 years it's been both and I wouldn't wish that experience on anyone
I think this is a rude question to ask, and it would reflect negatively on you, the company, and the group dynamics, if I were asked it.
It shows an unprofessional and inappropriate interest in things unrelated to work, and, from my experience, is a good indicator that the person will either micromanage, has poor work life balance, or is not socially fit to be a manager.
I know that sounds super harsh, but you should seriously reconsider. You're going to scare people away. There's a power dynamic that you don't seem to be aware of, during the interview process. It's not your concern what they do with their free time, unless they present it to you, unprovoked.
This is from someone who has interviewed hundreds of people.
Besides all of that, it opens you up to litigation for discrimination, depending on the answer they give. I suggest talking with your HR department. Where I am now, questions about personal life are strictly prohibited, for that reason.
edit: please note the "unprovoked". If people want to share the projects they do in their personal time, they will include it in their resume as a line item. I've seen it in probably 30% of the candidates. It means "ask me about these things".
> It shows an unprofessional and inappropriate interest in things unrelated to work,
No, it's a chance for candidates to bring up relevant experience that might help their candidacy.
The question isn't about things unrelated to work. The question is asking if they have any additional experience outside of work that might help us better understand their skills for their job application. Many people have relevant experience for the job that they gained outside of work. Asking about that is not only okay, it's a good thing.
> and, from my experience, is a good indicator that the person will either micromanage, has poor work life balance, or is not socially fit to be a manager.
Asking candidates if they have any extra experience to share is not an indicator of micromanaging.
Jumping to completely unrelated conclusions and drawing extreme assumptions about people is not a good way to interpret a question like that.
I explained that the question cannot have any negative value to the candidate. It's a chance to bring up extra things if they have them and we didn't cover them. Literally doing the candidate a favor, not being rude or micromanaging.
> It also opens you up to litigation for discrimination, depending on the answer they give. I suggest talking with your HR department.
Asking candidates to share their work-relevant experience does not invite discrimination lawsuits. How are you coming up with these interpretations? Legal was involved in reviewing our hiring processes, so no need for condescending lectures about getting HR involved.
> Asking candidates to share their work-relevant experience does not invite discrimination lawsuits.
I suggest you talk to your HR department. This isn't my interpretation, it's that of our cooperate lawyers.
If they say "I just had a kid, I spend time with them", is a good example. This should be obvious to you, which is further evidence you should not be asking these questions.
edit: can't reply directly. No, that's not how it works. You being made aware of it, and you using that information is enough. Good luck!
> If they say "I just had a kid, I spend time with them", is a good example.
Your understanding of these laws is flawed. A candidate volunteering information doesn't make the company liable for discrimination against them.
It's a common misconception that if topics like having kids or being married comes up in an interview then the company is liable to be sued for discrimination. It should be obvious that a candidate can't entrap a company by injecting this information into the interview when it wasn't asked. Even if the interviewers do ask, a discrimination lawsuit has a much higher bar than the topic simply coming up in the interview. It has to be demonstrated that the information was used to discriminate against the applicant, not just that it was discussed.
Your interpretation of my question is also flawed. I'm not asking "Tell me what you do in your free time." I'm asking them if they have anything outside of work that they'd like to share that would help their case.
> I suggest you talk to your HR department.
Please read my entire comment. The legal team reviewed our interview process and had no problems with it.
I think maybe your HR department has tried extra hard to scare you away from subjects they want to avoid, which has led to a misunderstanding of how the law actually works. It's common for HR professionals to tell interviewers that there are "illegal questions" or that if a topic comes up at all then you're going to get sued for discrimination. In reality, the legal bar for these cases is much higher. HR professionals just want to scare interviewers away entirely and drive the point home.
Asking candidates if they have an additional experience to share isn't an invitation for discrimination lawsuits. I suggest you open your mind a little bit and consider that some candidates may have more to offer than appears on the bullet points under each job on their resume.
I worked for Google for a while and there was a whole set of banned questions and topics- for example, when interviewing, I was told to never ask where somebody was from- that's discriminatory.
Originally I assumed all of this was good-faith advice from lawyers. It was only over time that I recognized that the leadership at Google continuously got itself in trouble by doing illegal things around hiring, and was telling interviewers all sorts of stuff that simply wasn't supported by law (similarly true for the constant warnings about not reading patents, or speculating about legal problems in a discoverable medium- it was the execs who fucked up, not the employees). I had to unlearn a lot when I left for another company.
Please keep asking people questions like this- I like how you phrased it: "this can only help, not hurt you".
I think a lot of this is simply asymmetric incentives for the lawyers. If they give legal advice that is overly conservative, it's some other portion of the business that suffers - we hire the wrong people, or we provide a worse product, or we lose out on revenue, or deals don't get made, or the code is overly convoluted, or employees get muzzled. If they give legal advice that is overly aggressive, they have to deal with the consequences when we get sued (at best) or they get fired (at worst). So they will always err on the side of caution.
I've also noticed a dramatic difference in how willing legal, HR, PR, REWS, etc. is to take risks now vs. back in the heyday of the 00s when the company was smaller and everybody felt like they were in it together. Some of that is probably simply because the company was a lot smaller and hence less likely to get sued, but a lot of it is because back then people tended to act in Google's interests a lot more while now they act in their own interests.
> Asking candidates if they have an additional experience to share isn't an invitation for discrimination lawsuits.
It's the fact that you decided not to hire them, because you found out that protected information. It was unrelated? Prove it in court. That's the reality of discrimination lawsuits.
I think we'll have to agree to disagree.
If you're confident in this, maybe in your next couple of interviews try "That last question is something new that I'm trying. Do you think it's good, or do you think it's too personal?". You'll have to read their body language, since the power dynamics will prevent a direct answer, for many. If you're not comfortable asking that, then that's evidence enough.
> It's the fact that you decided not to hire them, because you found out that protected information.
Again, you don't understand how this works.
If a candidate runs into your interview room and declares that they are a member of 5 protected classes, that doesn't automatically open you up to discrimination lawsuits.
How is this any different than asking someone about a past job and then they answer with "I didn't finish that project because I had kids and left for parental leave". It should be obvious that a candidate can reveal information about having kids for virtually any question.
> It was unrelated? Prove it in court.
Once again, that's not how it works. The onus is on the applicant to prove that the information was used for discrimination.
A candidate can't claim that a company discriminated against them for information they volunteered during an interview and then the company loses. They have to provide reasonable evidence to proceed to discovery, which would have to reveal something substantial that showed the information was used to discriminate, such as e-mails or chat logs.
> I don't believe you asked your legal department.
Legal was involved. Why do you only believe that your HR department wants to be involved in hiring processes, but mine obviously would not?
If you're not interested in discussing in good faith or you only want to ignore what I wrote and inject alternate facts, I can't help you.
I quickly edited that out but you saw it. I don't want to dox myself, which is why I removed it. You would trust our legal team. It's an opinion shared by every company I've ever worked for, except a startup, where they didn't know wtf they were doing, and there was no training at all: no personal questions that persuades/compels protected info. It's trivial to find this online.
To stop focusing on this last point...
> I'm not asking "Tell me what you do in your free time." I'm asking them if they have anything outside of work that they'd like to share that would help their case.
You are asking them that, in a practically indistinguishable way. Again, because of the power dynamic you don't seem to be aware of, they must give you an answer that explains why, if not. The legally appropriate response would be "I prefer not to answer what I do in my free time outside of work", which people would be uncomfortable, so they're going to be compelled to reveal to you why they don't have anything interesting, if they don't.
Luckily you guys can work at different companies and not have to interact except on HN.
(Personally I've been on both sides of this - early in my career I had a ton of hobby projects, wrote compilers for fun, and would often ask the interviewers what was the most interesting project they've worked on, either for work or for fun. Now I have a family, work stays at work, home stays at home, and I don't really care what my reports do on their own time. But different segments of the tech industry will fall on different ends of this spectrum. Know what you want and don't waste time interviewing at places where the culture is dramatically different.)
> and would often ask the interviewers what was the most interesting project they've worked on
And that's unprovoked. That doesn't conflict with what I said (I intentionally included it). Whenever someone is interesting in sharing, they present the work themselves. They provide their GitHub link, or include it on their resume, mention it, etc.
> And that's unprovoked. That doesn't conflict with what I said (I intentionally included it).
How is asking a direct question to the candidate "unprovoked"? This doesn't make sense.
> Whenever someone is interesting in sharing, they present the work themselves. They provide their GitHub link, or include it on their resume, mention it, etc.
No, they do not always do this. This isn't a good assumption. Asking candidates if they have anything extra to share reveals additional projects quite frequently. I would know because I do ask.
I was responding to what above above said, in the context of an interviewee:
> and would often ask the interviewers what was the most interesting project they've worked on
Above asking, and initiating the conversation, is clearly unprovoked.
A interviewer asking them isn't the same as them asking an interviewer, where their answer potentially means you don't get hired. The interviewer is forcing an answer about their free time. It's "provoked".
No, you're responding to what I said. There are multiple people calling you out here: please try to keep the usernames straight when responding.
The point of an interview is to ask questions, and particularly in the more freewheeling environment of a startup, "what sort of stuff do you like working on?" is very much relevant to whether they'd be a fit. Sergey Brin would famously ask early applicants to Google "Teach me something that I don't know already, about any topic." YCombinator's application form, for a long time, had the question "Tell us about a time you successfully hacked some (non-computer) system to your advantage", and the answers were explicitly supposed to be naughty if not illegal.
Not everybody works for a big company with a big HR department. The tech industry is a broad place.
Author was irrelevant in my reply. I was responding to the context. And come on now, consensus doesn't define correctness.
"Teach me something that I don't know already, about any topic."
"Tell us about a time you successfully hacked some (non-computer) system to your advantage"
This should not surprise you, but those are perfectly fine. These are very similar to the examples given to us for the appropriate/professional way to ask.
That's a good recommendation for the original commenter, on how to reword their question. They're not direct probes into personal time. I should have included something like that in my original reply.
I dabble at home, but it looks nothing like work code. I also started writing code for fun as a kid, before doing it professionally. I do find it hard to do much after a day of work and taking care of family. (I've just been laid off after 20 years at my company, so I guess I've got more free time now.)
Last year I wrote a self-hosted dependent typed programming language, after spending a couple of years helping out with Idris and learning how those languages work. I started that process because I was pretty burned out and needed something stimulating to do.
Before that, it was little things, like code to read various binary file formats. E.g. a read-only sqlite implementation, code to read realm databases, reading indexed db off of disk for various browsers, decoding apple notes database, decoding iOS backups.
Like you I put an enormous amount of personal free time into software engineering in my career. It had massive benefits that have paid out in many, many ways.
Some days, when I wrap up work, I feel burnt out and just watch TV shows or make food. Other days, I get so into what I'm coding (for fun/edification) that I look up and it's 10PM. It helps to have a long term view- my expectation is that I will be working on projects for a decade or more, slowly getting more knowledgeable, so i don't see a need to rush or overwork.
The field is pretty big. There are total mercs who only code because they get the big $$$ for it and wouldn't write a line otherwise, and there are idealist hackers who would keep coding 10 hours a day in "starving artist" mode even if they couldn't get jack for it. And anything in between.
I did for maybe the first 10 years of my career. Then it kinda died down because family and other obligations increased so had less and less spare time.
Also, the older I’m getting the more I’m prioritizing activities that benefit my body. Working out more, home cooked meals (so learning to actually cook well instead of throwing things together and hoping for the best).
I miss the side projects sometimes. At least I still do AoC yearly.
It's a bit like saying from HR employees that they don't recruit/fire people after hours, for fun.
Or surgeons don't operate after hours.
Software developer is a job with really weird expectations from outsiders. Show me your GitHub! Show me your side projects! You can't be good if you are not passionate even after a day's work!
Devs must have high IQs, have autistic traits, a university degree, master algorithms and several programming paradigms and are expected to simultaneously be able to integrate well in any team with average people, while science already identified that this is more difficult for such people...
Sure, but there's no single person that believes engineers must be all those things, you're conflating many opinions to form an impossible litmus test. In reality as the GP pointed out: great engineers don't all fit the same mold, and frankly neither do all jobs and hiring manager expectations.
I don't know man, my parents are surgeons and they're just as much vocateurs as I am. I have come home from football to see a surgical video on the TV. I cannot imagine being something else. Why would I not care about my primary thing? My wife is a creative director and she draws and paints in her spare time.
There's all kinds of people in the world and I like to work with vocateurs. That's an opt-in choice and others can go work with others. No harm done.
I work hard to cultivate hobbies outside of programming, but inevitably, I find a way to improve that other hobby with software. I'm just wired like that I think. I love systems. Code is my love language. :)
I'm currently trying to digitize a hopelessly analog procedure to calibrate aircraft engine fuel injection systems. Rpi, transducers, and python to the rescue! :D
I spent roughly 25 years writing code for a living while also writing code for fun. I think this was pretty normal when I got started; coding was neither cool nor especially lucrative back then, so the people who were into it were into it, for its own sake.
I didn't stop coding in my free time because I stopped enjoying it, either, but because I could no longer sustain the fantasy that anyone was going to use any of the stuff I wanted to build. The level of motivation I feel for a project which is not going anywhere is not high enough to sustain me for more than a week or two.
Shit, how many programmers barely write code at work anymore because that's not what their job is? And I'm not talking about new AI things, I'm talking about design docs and meetings and OKRs.
I programmed at home as a hobby before I worked in the industry. Then, when I worked as a software developer, I pretty much stopped entirely because I did enough software at work. Finally, I moved over to the dark side to start doing product management and project management, and I've re-started hobby projects.
> Hadn't written a code before he switched majors in college. Went from having zero experience with programming, to being a straight A computer science student
I’ve met these people before, they’re almost always undergrads from elite schools that could pick and succeed at anything they choose
I don't think elite school has much to do with talent just with how visible the things they are trusted with are.. From community college I've met some building things for companies too out of the mainstream to understand how unusual their IT worker was.
Pretty much all universes are first and fore-most strong people filters from my experience.
The prestigious schools filter up-front based on merit, and filter a 2nd time based on the ability to keep up and remain diligent to pass the courses. Less famous schools only have the 2nd filter, and have more people drop in the process that could not keep up.
The quality of education can be very similar, or even favor small schools in some subjects based on luck and school staff interests. The vast majority of learning at this level is made by the student anyway; there is only so much a good teacher or expensive teaching resources can do to help.
I've talked with interviewers that seemed completely uninterested in what courses or major was taken, just the fact that someone got through a difficult major as a stamp of quality.
At my undergrad there were 16 4.0s in a CS graduating class of about 120. I didn’t get close - about a 3.92 because I’m a poor student too. Grade inflation isn’t just a thing at elite schools, even my undergrad with a 45-55% accept rate
If you look at the resumes of anyone at top schools and who gets into YC this isn’t true, they’re simply more accomplished before college than the rest of us are after (or in my case, ever).
The content of the article about how do you measure software talent hit home with me. I am not saying I am some x10 developer, but all the metrics used at the companies I worked at just do not capture what makes a good software developer employee.
Today's hiring process feels like you have to go memorize algorithms instead of valuing things an employee actually has done in the past. And if the thing that was done in the past is something older, like Ruby on Rails, or an old PHP project it actually has a negative connotations in respect to hire-ability.
Isn't the ruby gems community currently imploding and in the middle of a hostile takeover? Also I've read about quite a few recent politically aligned actions in the community.
Not pick on Ruby, but is it a good reason? You've got 1 million lines of code and they’re written in Ruby and rewriting it would be, ah, untenable. But would ruby be the best choice today if you were starting from scratch? Maybe! But sheer inertia isn't a good reason in and of itself.
He didn't say inertia, he said mature. It take a while for a language/platform to develop a solid ecosystem and stabilize. That absolutely has value, and is something you can't get out of a new system no matter what novel problems it solves.
As far as new apps go, yeah I think it's still pretty optimal for a huge swath of web apps, especially for early incubation when you have <20 engineers and you need to move quick. Not if you need web sockets, or other concurrency / performance critical applications though.
Yes, I'd also think it's a great idea to build new apps in a language currently undergoing a distribution & supply chain war between the interested parties.
This is what happens when you let people other than the ones doing the work do the hiring. Everybody leans on leet code and chasing the bleeding edge (buzzwords) because that's as far as the HR department's understanding of the technology that pays their salary goes.
It's not just the metrics. Over the years I've come to realize that in many cases these companies just sabotage the talent they do have. My own performance when I have my own office vs. when I didn't is night and day. The possession of an uninterruptible space for a few hours a day, of perceived privacy (a cubicle is little better than a dog crate)...
And in many of the places where I did not have an office, it wasn't because none were available. In most of the jobs I've worked, there have been multiple vacant offices going unused or becoming junk rooms where they stash old equipment to keep it out of the hallways.
Autonomy to solve problems... I don't know how many places I've been where it was tacitly supported for people to goof off for 20-30 hours a week, but god forbid you put effort into work that hadn't been directed from above.
Heh. That's me. The "no presence" part. About the 10x part, ask my colleagues. I want to believe I'm doing some good work but who knows.
But the no presence... I've got a kid, a house, a mortgage. I've been in software since I was a teenager. Am I still fascinated by it? Sure. Will I still spend hours and hours of free time? Nop. It long since stopped being a hobby. Right now I like reading and listening to audio books, when I have a break from house chores and child rearing. I like to cook and experiment in the kitchen. The endorphin feedback cycle is so much faster (hours) than large scale software (weeks to years). I like to watch interesting shows on TV. Write. Coding-wise, I'm invisible outside the company I work at.
Not strictly a 9-5, but with a kid I do try to have quality family time, so I condense as much as possible to my working day, leaving time to be with my loved ones. If there's something important I'll participate. If there's a pagerduty alarm I'll jump. But otherwise, I'll deal with it tomorrow. I've long since learned to identify real emergencies from artificial urgency "because there's a milestone deadline!". Sure there is. Like the old saying goes "I love deadlines. I love the wooshing sound they make when they go by". Is it a customer commitment? No? Then I'll work on it Monday morning, right now I'm out.
I value people like that. Being a hero is a young-people game. You can't be a hero for years and years and not burn out. I've seen that happen. Working every weekend? Then something is wrong with the estimation. Or the design. Or whoever is in charge of priorities.
God helps me when I look for a job again. I guess I'll have to rely on references and hope to hell I'll pass the filtering software to actually get someone to look at my application. So far I've been lucky. Last time I actually sent CVs was at the beginning of my career, as a new grad, 20 years ago. Ever since then I was picked out, carried over, invited in by people who knew me. Really, really hoping that'll keep being the case.
In markets where information on quality is difficult to acquire, assess, and/or trust, you tend to get two results:
- Low-quality products flood the market. This leads buyers to assume lower-value products, and hence ...
- High-quality products are consistently under-priced. This leads those offering higher-value products to withdraw from the market, or to offer those products (or services) only in limited sub-markets where full value is more likely to be obtained.
The problem is a broad one, and long-predates used-car sales. There was a popular late-19th century book David Harum (1898) by Edward Noyes Westcott. All but forgotten today, it was a bestseller at the time and spun off several related franchises, including a 1934 film and 1936 radio serial. The title character was a horse trader, the profession which previously held a similar status to used-car salesman.
This isn’t a unique issue with software developers. In many fields, there’s a distinction between show horses vs work horses. A lot of people who spend time tooting their own horn are not necessarily the best at what they do. Finding the best people often involves word of mouth, not measuring git commits, IMDB rankings, design awards, or whatever.
In my 20 years of engineering, all my distributed systems knowledge was learnt in a period of two years under two amazing engineers working in two failed startups
One was like those legendary OG dogmatic distributed systems software engineer that you can meet and the other was an OG data platform person. They have zero social media presence but they have guaranteed jobs whomever they call.
I learnt my transactions and services from engineer 1 and my analytic/data platform fundamentals from engineer 2
I have made more money in the enterprise land but I think the two failed startups did 10x more to help me grow as an engineer
I am rather confident that an AI cannot come close to what I do and my management knows that
If anything I tend to think that the people who promote themselves the most aggressively are the ones who should be looked at with the most skepticism.
This is one reason startups can be so successfull. A founder who knows that they're doing will have a team of such illegible (and so undervalued) talent scouted out ahead of time and poach them for their venture. Basically talent arbitrage
But talent arbitrage, like any arbitrage closes as its utilized. Basically these people can be rescued by their former coworkers so as long as you make sure to work with people who know talent when they see it in action daily, you will be good
It is not a legibility problem as much as a risk problem. You can’t bee the guy that hires quirky people to take chances, just hire the “proper” people and move on.
It is just not possible to see who is “really” going to be more value anyway.
I started my first full time job out of college a bit over a decade ago, in an old-school boring EU "midtech" company.
I didn't know this back then, but I was very lucky to have landed in a damn strong team.
Fast-forward to today, most of the team members now work for FAANG and other bigtechs... except the guy who was IMO the best of all of us. Still same team, same company, no LinkedIn account etc.
Promotion processes favour people who want to play the promotion game. These are rarely if ever the best people but from a certain point, the ranks are field with this kind of people anyway so they are happy playing together.
You can still do a very meaningful and satisfying career playing by your rule if you don’t care about striking your ego so much.
This is also why talent marketplaces don’t work so well.
We can know who is good for our last situation, but it comes with bias and is very hard to measure. This is true even for jobs that are easier to measure like Sales or Support.
I hate performing, but I don't know if there is a framework for me or for managers to identify and track such things. The irony is that these things would be visible only when they bite us and when the work is done in such situation the reward is high, I strongly believe it should be other way around because preventing something is far greater than fixing something after it goes wrong, the sad fact is that it is hard to realize the impact of the failure unless it happens and even if highlighted in reviews it is overlooked often.
It’s almost like the best engineers are, like, people who come in all shapes and sizes
Super nice guys, complete assholes, showmen, wallflowers - what they have in common is that they are great at making software
There are for sure personally types that are typical in certain traits, but we lose site of the fact that these do not tell you everything about who a person is
I likewise can give you stories of the best developers I’ve worked with - from Devry graduates, to high school dropouts, to HYPE wunderkinds - they come from all walks of life
I think the number of approaches you can take to reach the same goal/standard increases with how abstract the work you're doing is. SWE is quite abstract.
I don't have the greatest work ethic, I waste time sometimes, forget things, am not too organized, etc. It's mostly the fact that 1) I do SWE as a hobby and 2) learn obsessively without BSing myself that gets me into jobs.
However my teammate at my last job. He probably didnt have the same level of intimate knowledge of systems as me. But his work ethic was just breathtaking. Mine simply wouldn't compare in a million years. Averaged over a large enough period, we both ended up doing the same amount of useful work.
Similarly there were others with different "approaches", just included the above 2 cases as an example.
Now. It wasn't the best experiment since we helped each other a lot. But I came away feeling it's true.
My hypothesis is that in less abstract work, the number of approaches is limited, and hiring practices in SWE have just been made the same as those jobs.
I don't really complain since I really can't think of a framework for hiring for abstract jobs that will yield better results than the current one. But who knows, maybe we'll find one.
FWIW, I think leetcode, just one round to bring down the applicant count to a number that's possible to interview {hard if there are too many, medium if there are few, or just Two Sum to weed out folks that can't write a for loop if you have just tens of applicants}, and then system design as the main interview, is a good system. For system design I would skip the common ones like "design a rate limiter/load balancer" stuff that people memorize. IMO it's easily possible to create unique system/API design questions that match the job somewhat.
Even when companies know they need something more than a normal senior developer, they don't necessarily know how to interview for that.
This afternoon, I'm leaning towards bowing out of a supposed more-than-normal engineering role.
If I wanted a battery of commodity techbro interview performance art hoop-jumping, just to be allowed to work at a place... then I would've gone to Google 1-2 decades ago, for 2-5 times what this place is offering, gotten rich, and then retired... so that I could then spend all my time making useful and trustworthy software.
I know what it's like to have a good interview "loop" for this level of impact role. Both sides of the table seem to value each other, ask good questions, focus on getting a sense of what it would be like to work together on the products/projects, with the team(s), and within the company culture. And see if that's something everyone feels really good about doing.
No "I need to haze you to 'understand how you think'". No BS performances of Coding Interview, System Design Interview, and Behavioral Interview, like every techbro is told they must "prep" for. No feeling like the other person might somehow be cheating (because you get the impression that they might be lying trash). No battery of rituals (in some cases) to the exclusion of people who'd be working together actually meeting each other before everyone has to decide whether to offer/join.
The problem here is clearly the one doing the evaluation. Why do they even have a job themselves if they're so incapable of evaluating correctly?
There exists a quantitative method to correctly evaluate workers:
1. Collect each worker's work outputs and construct a training dataset.
2. Train an AI model with all work outputs combined.
3. For each worker, train a model with their respective work outputs deleted.
4. Construct a comprehensive evaluation benchmark over the full combined dataset.
5. For each worker, measure the change in the benchmark's performance with the worker's specific model relative to the full global model.
6. Fire the workers that lead to an unexpected improvement in the benchmark with their respective worker's model. This means that these workers were not contributing in a meaningful way to improving the performance over the benchmark. Keep the rest.
Ignoring how ridiculous and impractical this idea is, it fails to capture some of the most important skills in being a developer. Framing real-world problems as code problems. Anticipating design issues. Knowing the right trade-off between solution correctness, complexity,and effort. Mentoring and accelerating others. This is barely different than leetcode interviews.
> Why do they even have a job themselves if they're so incapable of evaluating correctly?
The only way for this to not be the case is if the first person you hired is the most competent that exists, and can do everything already, and therefor accurately measure the anyone in front of them. And, that goes on down the hiring chain.
In reality, you'll eventually need an expert in an area you are not an expert in, which means you won't necessarily have the insight on the best candidate. Maybe AI can do that someday, but definitely not today.
I also think this is what causes large orgs slowly fail: it's not only difficult for a person to gauge when another is smarter/more capable than them, but a smarter person can look less competent to someone hiring, because their answers/approach is outside of the known solution space of the interviewer. So, you end up with a slow net decrease in competence over time.
I've seen it in every org I've been a part of, from startups to corporate, including myself. Trying to judge a person, within small time slot is hard. The alternatives (like take home, temp to hire, etc) are also talent repellent. I think the most revealing method can be the Jim Keller method, where you let them nerd out on some potentially unrelated problem, but the results of that are hard to write down/justify.
This is magical thinking with trendy AI mixed in. Every step here has massive assumptions that are just baked in, like can their output be quantified in principle? How expensive is it? Will the model even be predictive? Can you gain the cooperation of workers or even the companies that they work for?
Every invention is considered magical thinking by some until it is made possible. Nothing I noted is actually magical or prohibited.
As for its feasibility, that's an engineering task. No cooperation is necessary from workers. It is in fact much more feasible than developing a modern LLM.
As for its cost, various optimizations are possible as with LLMs. Also, there are high costs to incorrect classifications currently made by management, so high that they can result in the disposal of the firm.
Please, your employer captures everything you produce for your work. They have your screenshots, emails, chats, git history, Zoom call transcripts, and everything else. You signed off on it too. So save me the "this is ethical" crap. Actually it is ethical because it is much closer to being a blind and unbiased way of gauging utility.
This is only possible because they broke the power of labor unions. Nothing you've said convinces me that it would be unbiased or even measuring something real, in which case totally arbitrary decisions made by machine would be denying people access to basic necessities under our economic system.
"Legibility" is a distinct reference to Tom C. Scott's Seeing Like a State, and the tendency of states (or other large institutions) to attempt to impose legibility on complex problems, domains, or systems, usually in an attempt to manage or govern them, but often destroying that which makes them valuable in the first place:
It's not invisible, it's incomprehensible to most would-be employers because the information is not in a form that they can understand. That's not the same as invisible.
Passing some leetcode challenges is legible to employers, it puts applicants in the same buckets and measures them in (roughly) the same way. But it's not a good measure of actual talent. The real measures, as discussed in the article are out there but illegible to those employers.
It was a deliberate word choice by the author. "Illegible" conveys that it's difficult to track from the outside. It's a clever analogy: illegible hand writing can be read by those who are familiar with the scribe.
It's not invisible though: those who work with these kinds of engineers easily see how valuable they are.
It's not invisible, because some people can see it. It is illegible because the leadership of a large company won't know how to interpret it. This particular usage of "illegible" has been around for awhile, but is probably best known from the book, "Seeing Like A State":
I'm interviewing for Senior Staff roles and doing quality coding interviews and beyond the basics I'm not sure really what I'm supposed to ascertain from the format because it is so far removed from what is day to day important in the role.
I ask about time complexity, and all the basics, but it's just a bunch of malarkey. So I spend more time quizzing them about technologies I don't know on their resume and getting something out of it for myself. It's easy enough to tell when someone's full of shit, but asking them to describe the tradeoffs between the technologies they've worked with seems more valuable than watching someone sweat-ily cramming out some crap imperative code for a toy problem and telling me they got it down to nlogn. Oooo ee!
It might be helpful to look at this classic post by Joel Spolsky [0]. He discusses many of the points you brought up. I found it most helpful to pull out some of the principles he discusses and then ask "What would this look like when applied to [job in question]?"
> We can't measure what's important, so we'd better measure what we can measure extremely rigorously.
As much as we like to complain about interviews, the alternatives that more accurately reflect the work environment are much more strongly hated.
One of the most accurate interviewing methods is a work trial: Bring the candidate in for a week and have them work the job. Their peers and managers rate their performance.
It's great for revealing how a person works. But think about what's required: You would have to take a week off of your primary job every time you wanted to interview at another company. A company could only interview one candidate per week.
Some companies try this, but it over-selects for unemployed young people. They either give up or start bending the rules when qualified applicants refuse.
Did nobody ask why you would want to reuse contact lens fallen on some grimy ground in the night? Keys, coins, bills, even glasses ok, but putting back the contact lens into your eyes seems dangerous. I thought some kid might have spoken up :-).
No. For example, in science most scientists just look where the streetlight is, but a small number of people build better, stronger lights to search larger areas, and there is a tiny number of people who can mysteriously just find things in the dark.
Is it just me or is [il]legible the word of the month somewhere? I suddenly keep seeing this word pop up in contexts I would not normally associate it with.
James C Scott, a Yale political scientist with an interest in agrarian societies, wrote a book Seeing Like A State in 1998. He was interested in why state-scale, “scientific” and “rational” schemes often fail to improve the outcomes they nominally set out to address (and often make them worse).
The book traced a number of case studies supporting the notion that large enough systems of control require some degree of standardization to implement—for example, to tax stuff, you have to know how much stuff there is. Village life might tend to have advantages for human well-being, but that doesn’t mean you’ll get that result by sending out troops to force everybody out of their traditional structure and into village footprints.
If you’re tallying up a nation’s agricultural capacity, “Farmer John’s got a nice-sized patch that’s extra fertile but he’s lazy” doesn’t add as well as “corn, 5 acres, Grade B”.
In that way of thinking, complexity, nuance, or localized idiosyncrasies—where a lot of useful information lives, but outside of the standardized spec—essentially becomes invisible to the system. Even though it’s essential to the social phenomenon the system is setting out to regulate.
It’s illegible to the centralized governance mechanism, so it may as well not exist, as far as that mechanism is concerned. No National ID number? You’re not a person, go away.
Sean Goedecke recently wrote a blog [1] applying that idea to software companies, I imagine that’s where the resurgence is coming from in these parts :)
Thank you for the detailed explanation. In that case it makes sense because it was actually writing or recordkeeping done by a human hand that failed to communicate some pertinent bits of information (though in a more abstract sense than being physically unable to read the glyphs).
Extending it to observations of natural or emergent phenomena seems like a reach for fanciness when "inscrutable," "unclear," "murky," or "poorly understood" would be more accurate to me.
Edit: Upon further review, I am coming around to it a bit, in the sense of performance reviews looking for the wrong thing, but I still think the larger point is about something more complex that poor evaluation metrics are just a symptom of rather than the cause.
It's used here as a specific term from Seeing like a State[1][2], which is one of those books that got popular with a specific set of online tech folks. "Legibitility" in that particular sense is a very useful concept with no other convenient word, so I'm not too surprised it caught on.
To this point, it is actually wild how we each see a different projection of the chamber depending on which articles and threads we dive into. As much as I feel like I "know" HN, I do marvel at the entire subsections of the discourse I'm completely oblivious to, and this is an interesting cross-pollination.
Please maintain your professional social contacts!
It's fine not to have a native interest in that. But it's part of the job. No blog or bragging needed. No Linkedin needed even, if you really don't want that one. Catalog and maintain some minimal contact with these people who have seen your work: bosses, colleagues, juniors, vendors, consultants, anyone. Expose a few EXTRA people now and then, so they can see your work. This way, when you need to find a new job after many years hidden in just one department, you will have all these people who moved - sometimes frequently - and only wished they could have taken you with them at the time.
And that has nothing to do with "10x" - no matter the skill level you think you have, you'll be better off with a wide set of people who know you. "Know you" to any degree - often people will prefer you to going through the circus of interviewing for pretty random results.
It is interesting, the two best developers I know are on the polar opposite of each other, from the outside.
A: Started coding when he was 6 years old, was making 3D games from scratch at 12, and sold his first software at 15. Never went to college, as he was right in time for the dotcom boom. The man just loves coding, and always works on his side projects in his spare time, mostly software he finds interesting. At work, he's the closest I've seen to a mythical 10x
B: Hadn't written a line code before he switched majors in college. Went from having zero experience with programming, to being a straight A computer science student, finishing one year faster. Best student prize at university for masters, and then a Ph.D in record time. Writes flawless code, is a top tier architect, and just a machine. Doesn't write a line of code when he comes home (at least according to him), basically severs himself from work as soon as he leaves work.
> It is interesting, the two best developers I know
Over time I've come to appreciate the difference between people who are described as the best programmers and people who are best at delivering results.
Some times they're one in the same. It's wonderful when you work with someone who is both an excellent programmer and excellent and delivering results in a team.
Many times I've worked with or even hired people who are brilliant developers and praised as being very smart, yet they didn't deliver results as well as the average developer on the team who diligently gets their work done.
Looking back, some of the most stereotypically brilliant developers I've worked with have also been among the more difficult to work with. Not all of them, but quite a few. The two that come to mind have been bouncing from company to company for a long time. They'll always have job offers and be able to pass interviews, but actually working with them and getting good results is a different story.
One of them even founded a startup with a co-founder, but unsurprisingly they broke up less than a year into it. On paper he should be the perfect fit to get launch a startup product, but working with him is a different matter.
The brilliant devs I know who are great at delivering results usually find their way into good positions and good companies early in their career and then stay there for a long time.
> Many times I've worked with or even hired people who are brilliant developers and praised as being very smart, yet they didn't deliver results as well as the average developer on the team who diligently gets their work done.
Very smart programmers often have a very different way of thinking about programming problems. If the project structure does not accommodate for this way of thinking, brillant programmers can barely use their "superpower".
Also, great programmers often have a deep love for their craft, and thus be very opinionated about the best possible way of solving the programming problem at hand.
So my bet is:
- you don't have software problems that "need" superpowers (otherwise the average developer on the team would be of little use)
- you don't have a project structure that enables exceptional programmers to actually use their superpowers
- you already admitted that you are rather looking for people "who diligently get their work done"
Exaggeratedly: you hired a Fields medalist to fix your clogged toilet, and you are now complaining that the average plumber is much better at fixing it.
100% this. Nothing turns a 10x into a 0.5x faster than telling them they can't fix the horrible issues putting your api performance in the shitter under load, and instead they have to go help automate the QA build process.
> Doesn't write a line of code when he comes home (at least according to him), basically severs himself from work as soon as he leaves work.
I'm truly curios what percentage of programmers do write code outside of work. I'd bet the actually percentage is pretty low, especially those who've been at it for five years or more. I don't know that I ever did, except when I first started.
When I do interviews I like to ask candidates if they want to share anything interesting they've made, studied, worked on, or played with outside of their jobs. I explain their answer can only help, not hurt, as a non-answer is not a negative. It's simply an opportunity to bring up something that wouldn't normally come up during the work-history driven interview.
Very few candidates say they've done any programming outside of their jobs. At most, they share something like running Home Assistant on a Raspberry Pi and using Python to automate their house or something. Another common one is to hear about how they used an Arduino or Raspberry Pi to accomplish some small task.
Very few people say they have side projects. Of those who do, when I ask for details most admit it never went far beyond the idea phase.
So from what I can deduce, it's very uncommon for programmers to have true side projects that go beyond a couple git commits worth of code to solve some task, or an idea they had that they never followed up on.
>a non-answer is not a negative
I don't know how this can be true. Interviewing for a job is a zero-sum competition against the other candidates. If something isn't a positive, it has to be a negative.
It feels slightly disingenuous. Many engineers do their work with a sense of personal duty and pride. Should a drive for self-improvement be neglected because it didn't happen outside of work hours?
For the years I had paid employment I'm very thankful that I didn't make programming my hobby in addition to being my work. For the last 5 years it's been both and I wouldn't wish that experience on anyone
I think this is a rude question to ask, and it would reflect negatively on you, the company, and the group dynamics, if I were asked it.
It shows an unprofessional and inappropriate interest in things unrelated to work, and, from my experience, is a good indicator that the person will either micromanage, has poor work life balance, or is not socially fit to be a manager.
I know that sounds super harsh, but you should seriously reconsider. You're going to scare people away. There's a power dynamic that you don't seem to be aware of, during the interview process. It's not your concern what they do with their free time, unless they present it to you, unprovoked.
This is from someone who has interviewed hundreds of people.
Besides all of that, it opens you up to litigation for discrimination, depending on the answer they give. I suggest talking with your HR department. Where I am now, questions about personal life are strictly prohibited, for that reason.
edit: please note the "unprovoked". If people want to share the projects they do in their personal time, they will include it in their resume as a line item. I've seen it in probably 30% of the candidates. It means "ask me about these things".
edit: better yet, just rephrase, so it's not a potentially uncomfortable probe into personal time: https://news.ycombinator.com/item?id=45543812
> It shows an unprofessional and inappropriate interest in things unrelated to work,
No, it's a chance for candidates to bring up relevant experience that might help their candidacy.
The question isn't about things unrelated to work. The question is asking if they have any additional experience outside of work that might help us better understand their skills for their job application. Many people have relevant experience for the job that they gained outside of work. Asking about that is not only okay, it's a good thing.
> and, from my experience, is a good indicator that the person will either micromanage, has poor work life balance, or is not socially fit to be a manager.
Asking candidates if they have any extra experience to share is not an indicator of micromanaging.
Jumping to completely unrelated conclusions and drawing extreme assumptions about people is not a good way to interpret a question like that.
I explained that the question cannot have any negative value to the candidate. It's a chance to bring up extra things if they have them and we didn't cover them. Literally doing the candidate a favor, not being rude or micromanaging.
> It also opens you up to litigation for discrimination, depending on the answer they give. I suggest talking with your HR department.
Asking candidates to share their work-relevant experience does not invite discrimination lawsuits. How are you coming up with these interpretations? Legal was involved in reviewing our hiring processes, so no need for condescending lectures about getting HR involved.
> Asking candidates to share their work-relevant experience does not invite discrimination lawsuits.
I suggest you talk to your HR department. This isn't my interpretation, it's that of our cooperate lawyers.
If they say "I just had a kid, I spend time with them", is a good example. This should be obvious to you, which is further evidence you should not be asking these questions.
edit: can't reply directly. No, that's not how it works. You being made aware of it, and you using that information is enough. Good luck!
> If they say "I just had a kid, I spend time with them", is a good example.
Your understanding of these laws is flawed. A candidate volunteering information doesn't make the company liable for discrimination against them.
It's a common misconception that if topics like having kids or being married comes up in an interview then the company is liable to be sued for discrimination. It should be obvious that a candidate can't entrap a company by injecting this information into the interview when it wasn't asked. Even if the interviewers do ask, a discrimination lawsuit has a much higher bar than the topic simply coming up in the interview. It has to be demonstrated that the information was used to discriminate against the applicant, not just that it was discussed.
Your interpretation of my question is also flawed. I'm not asking "Tell me what you do in your free time." I'm asking them if they have anything outside of work that they'd like to share that would help their case.
> I suggest you talk to your HR department.
Please read my entire comment. The legal team reviewed our interview process and had no problems with it.
I think maybe your HR department has tried extra hard to scare you away from subjects they want to avoid, which has led to a misunderstanding of how the law actually works. It's common for HR professionals to tell interviewers that there are "illegal questions" or that if a topic comes up at all then you're going to get sued for discrimination. In reality, the legal bar for these cases is much higher. HR professionals just want to scare interviewers away entirely and drive the point home.
Asking candidates if they have an additional experience to share isn't an invitation for discrimination lawsuits. I suggest you open your mind a little bit and consider that some candidates may have more to offer than appears on the bullet points under each job on their resume.
I worked for Google for a while and there was a whole set of banned questions and topics- for example, when interviewing, I was told to never ask where somebody was from- that's discriminatory.
Originally I assumed all of this was good-faith advice from lawyers. It was only over time that I recognized that the leadership at Google continuously got itself in trouble by doing illegal things around hiring, and was telling interviewers all sorts of stuff that simply wasn't supported by law (similarly true for the constant warnings about not reading patents, or speculating about legal problems in a discoverable medium- it was the execs who fucked up, not the employees). I had to unlearn a lot when I left for another company.
Please keep asking people questions like this- I like how you phrased it: "this can only help, not hurt you".
I think a lot of this is simply asymmetric incentives for the lawyers. If they give legal advice that is overly conservative, it's some other portion of the business that suffers - we hire the wrong people, or we provide a worse product, or we lose out on revenue, or deals don't get made, or the code is overly convoluted, or employees get muzzled. If they give legal advice that is overly aggressive, they have to deal with the consequences when we get sued (at best) or they get fired (at worst). So they will always err on the side of caution.
I've also noticed a dramatic difference in how willing legal, HR, PR, REWS, etc. is to take risks now vs. back in the heyday of the 00s when the company was smaller and everybody felt like they were in it together. Some of that is probably simply because the company was a lot smaller and hence less likely to get sued, but a lot of it is because back then people tended to act in Google's interests a lot more while now they act in their own interests.
> Asking candidates if they have an additional experience to share isn't an invitation for discrimination lawsuits.
It's the fact that you decided not to hire them, because you found out that protected information. It was unrelated? Prove it in court. That's the reality of discrimination lawsuits.
I think we'll have to agree to disagree.
If you're confident in this, maybe in your next couple of interviews try "That last question is something new that I'm trying. Do you think it's good, or do you think it's too personal?". You'll have to read their body language, since the power dynamics will prevent a direct answer, for many. If you're not comfortable asking that, then that's evidence enough.
> It's the fact that you decided not to hire them, because you found out that protected information.
Again, you don't understand how this works.
If a candidate runs into your interview room and declares that they are a member of 5 protected classes, that doesn't automatically open you up to discrimination lawsuits.
How is this any different than asking someone about a past job and then they answer with "I didn't finish that project because I had kids and left for parental leave". It should be obvious that a candidate can reveal information about having kids for virtually any question.
> It was unrelated? Prove it in court.
Once again, that's not how it works. The onus is on the applicant to prove that the information was used for discrimination.
A candidate can't claim that a company discriminated against them for information they volunteered during an interview and then the company loses. They have to provide reasonable evidence to proceed to discovery, which would have to reveal something substantial that showed the information was used to discriminate, such as e-mails or chat logs.
> I don't believe you asked your legal department.
Legal was involved. Why do you only believe that your HR department wants to be involved in hiring processes, but mine obviously would not?
If you're not interested in discussing in good faith or you only want to ignore what I wrote and inject alternate facts, I can't help you.
I quickly edited that out but you saw it. I don't want to dox myself, which is why I removed it. You would trust our legal team. It's an opinion shared by every company I've ever worked for, except a startup, where they didn't know wtf they were doing, and there was no training at all: no personal questions that persuades/compels protected info. It's trivial to find this online.
To stop focusing on this last point...
> I'm not asking "Tell me what you do in your free time." I'm asking them if they have anything outside of work that they'd like to share that would help their case.
You are asking them that, in a practically indistinguishable way. Again, because of the power dynamic you don't seem to be aware of, they must give you an answer that explains why, if not. The legally appropriate response would be "I prefer not to answer what I do in my free time outside of work", which people would be uncomfortable, so they're going to be compelled to reveal to you why they don't have anything interesting, if they don't.
Luckily you guys can work at different companies and not have to interact except on HN.
(Personally I've been on both sides of this - early in my career I had a ton of hobby projects, wrote compilers for fun, and would often ask the interviewers what was the most interesting project they've worked on, either for work or for fun. Now I have a family, work stays at work, home stays at home, and I don't really care what my reports do on their own time. But different segments of the tech industry will fall on different ends of this spectrum. Know what you want and don't waste time interviewing at places where the culture is dramatically different.)
> and would often ask the interviewers what was the most interesting project they've worked on
And that's unprovoked. That doesn't conflict with what I said (I intentionally included it). Whenever someone is interesting in sharing, they present the work themselves. They provide their GitHub link, or include it on their resume, mention it, etc.
> And that's unprovoked. That doesn't conflict with what I said (I intentionally included it).
How is asking a direct question to the candidate "unprovoked"? This doesn't make sense.
> Whenever someone is interesting in sharing, they present the work themselves. They provide their GitHub link, or include it on their resume, mention it, etc.
No, they do not always do this. This isn't a good assumption. Asking candidates if they have anything extra to share reveals additional projects quite frequently. I would know because I do ask.
I was responding to what above above said, in the context of an interviewee:
> and would often ask the interviewers what was the most interesting project they've worked on
Above asking, and initiating the conversation, is clearly unprovoked.
A interviewer asking them isn't the same as them asking an interviewer, where their answer potentially means you don't get hired. The interviewer is forcing an answer about their free time. It's "provoked".
edit: "you" to "above".
No, you're responding to what I said. There are multiple people calling you out here: please try to keep the usernames straight when responding.
The point of an interview is to ask questions, and particularly in the more freewheeling environment of a startup, "what sort of stuff do you like working on?" is very much relevant to whether they'd be a fit. Sergey Brin would famously ask early applicants to Google "Teach me something that I don't know already, about any topic." YCombinator's application form, for a long time, had the question "Tell us about a time you successfully hacked some (non-computer) system to your advantage", and the answers were explicitly supposed to be naughty if not illegal.
Not everybody works for a big company with a big HR department. The tech industry is a broad place.
Author was irrelevant in my reply. I was responding to the context. And come on now, consensus doesn't define correctness.
"Teach me something that I don't know already, about any topic."
"Tell us about a time you successfully hacked some (non-computer) system to your advantage"
This should not surprise you, but those are perfectly fine. These are very similar to the examples given to us for the appropriate/professional way to ask.
That's a good recommendation for the original commenter, on how to reword their question. They're not direct probes into personal time. I should have included something like that in my original reply.
You're not contributing anything addition to this thread; I recommend dropping it.
It's completely reasonably to respond to/correct an interpretation that is the logical inverse of the intent and what was written.
I dabble at home, but it looks nothing like work code. I also started writing code for fun as a kid, before doing it professionally. I do find it hard to do much after a day of work and taking care of family. (I've just been laid off after 20 years at my company, so I guess I've got more free time now.)
Last year I wrote a self-hosted dependent typed programming language, after spending a couple of years helping out with Idris and learning how those languages work. I started that process because I was pretty burned out and needed something stimulating to do.
Before that, it was little things, like code to read various binary file formats. E.g. a read-only sqlite implementation, code to read realm databases, reading indexed db off of disk for various browsers, decoding apple notes database, decoding iOS backups.
Like you I put an enormous amount of personal free time into software engineering in my career. It had massive benefits that have paid out in many, many ways.
Some days, when I wrap up work, I feel burnt out and just watch TV shows or make food. Other days, I get so into what I'm coding (for fun/edification) that I look up and it's 10PM. It helps to have a long term view- my expectation is that I will be working on projects for a decade or more, slowly getting more knowledgeable, so i don't see a need to rush or overwork.
The field is pretty big. There are total mercs who only code because they get the big $$$ for it and wouldn't write a line otherwise, and there are idealist hackers who would keep coding 10 hours a day in "starving artist" mode even if they couldn't get jack for it. And anything in between.
I did for maybe the first 10 years of my career. Then it kinda died down because family and other obligations increased so had less and less spare time.
Also, the older I’m getting the more I’m prioritizing activities that benefit my body. Working out more, home cooked meals (so learning to actually cook well instead of throwing things together and hoping for the best).
I miss the side projects sometimes. At least I still do AoC yearly.
It's a bit like saying from HR employees that they don't recruit/fire people after hours, for fun. Or surgeons don't operate after hours. Software developer is a job with really weird expectations from outsiders. Show me your GitHub! Show me your side projects! You can't be good if you are not passionate even after a day's work! Devs must have high IQs, have autistic traits, a university degree, master algorithms and several programming paradigms and are expected to simultaneously be able to integrate well in any team with average people, while science already identified that this is more difficult for such people...
Sure, but there's no single person that believes engineers must be all those things, you're conflating many opinions to form an impossible litmus test. In reality as the GP pointed out: great engineers don't all fit the same mold, and frankly neither do all jobs and hiring manager expectations.
I don't know man, my parents are surgeons and they're just as much vocateurs as I am. I have come home from football to see a surgical video on the TV. I cannot imagine being something else. Why would I not care about my primary thing? My wife is a creative director and she draws and paints in her spare time.
There's all kinds of people in the world and I like to work with vocateurs. That's an opt-in choice and others can go work with others. No harm done.
I'm surprised at this expectation.
I work hard to cultivate hobbies outside of programming, but inevitably, I find a way to improve that other hobby with software. I'm just wired like that I think. I love systems. Code is my love language. :)
I'm currently trying to digitize a hopelessly analog procedure to calibrate aircraft engine fuel injection systems. Rpi, transducers, and python to the rescue! :D
I spent roughly 25 years writing code for a living while also writing code for fun. I think this was pretty normal when I got started; coding was neither cool nor especially lucrative back then, so the people who were into it were into it, for its own sake.
I didn't stop coding in my free time because I stopped enjoying it, either, but because I could no longer sustain the fantasy that anyone was going to use any of the stuff I wanted to build. The level of motivation I feel for a project which is not going anywhere is not high enough to sustain me for more than a week or two.
I'd write code after work if I wasn't writing code at work ;) But...
Shit, how many programmers barely write code at work anymore because that's not what their job is? And I'm not talking about new AI things, I'm talking about design docs and meetings and OKRs.
I programmed at home as a hobby before I worked in the industry. Then, when I worked as a software developer, I pretty much stopped entirely because I did enough software at work. Finally, I moved over to the dark side to start doing product management and project management, and I've re-started hobby projects.
> Hadn't written a code before he switched majors in college. Went from having zero experience with programming, to being a straight A computer science student
I’ve met these people before, they’re almost always undergrads from elite schools that could pick and succeed at anything they choose
I don't think elite school has much to do with talent just with how visible the things they are trusted with are.. From community college I've met some building things for companies too out of the mainstream to understand how unusual their IT worker was.
Pretty much all universes are first and fore-most strong people filters from my experience.
The prestigious schools filter up-front based on merit, and filter a 2nd time based on the ability to keep up and remain diligent to pass the courses. Less famous schools only have the 2nd filter, and have more people drop in the process that could not keep up.
The quality of education can be very similar, or even favor small schools in some subjects based on luck and school staff interests. The vast majority of learning at this level is made by the student anyway; there is only so much a good teacher or expensive teaching resources can do to help.
I've talked with interviewers that seemed completely uninterested in what courses or major was taken, just the fact that someone got through a difficult major as a stamp of quality.
At my undergrad there were 16 4.0s in a CS graduating class of about 120. I didn’t get close - about a 3.92 because I’m a poor student too. Grade inflation isn’t just a thing at elite schools, even my undergrad with a 45-55% accept rate
If you look at the resumes of anyone at top schools and who gets into YC this isn’t true, they’re simply more accomplished before college than the rest of us are after (or in my case, ever).
The content of the article about how do you measure software talent hit home with me. I am not saying I am some x10 developer, but all the metrics used at the companies I worked at just do not capture what makes a good software developer employee.
Today's hiring process feels like you have to go memorize algorithms instead of valuing things an employee actually has done in the past. And if the thing that was done in the past is something older, like Ruby on Rails, or an old PHP project it actually has a negative connotations in respect to hire-ability.
A nit, but Ruby on Rails isn’t “old”. It’s mature. It still receives regular updates and release, even major version releases.
What it isn’t any more is new or trendy. Still pretty widely used though, and with good reason.
Isn't the ruby gems community currently imploding and in the middle of a hostile takeover? Also I've read about quite a few recent politically aligned actions in the community.
I don't know if I'd call that "mature".
Not pick on Ruby, but is it a good reason? You've got 1 million lines of code and they’re written in Ruby and rewriting it would be, ah, untenable. But would ruby be the best choice today if you were starting from scratch? Maybe! But sheer inertia isn't a good reason in and of itself.
He didn't say inertia, he said mature. It take a while for a language/platform to develop a solid ecosystem and stabilize. That absolutely has value, and is something you can't get out of a new system no matter what novel problems it solves.
As far as new apps go, yeah I think it's still pretty optimal for a huge swath of web apps, especially for early incubation when you have <20 engineers and you need to move quick. Not if you need web sockets, or other concurrency / performance critical applications though.
Yes, I'd also think it's a great idea to build new apps in a language currently undergoing a distribution & supply chain war between the interested parties.
This is what happens when you let people other than the ones doing the work do the hiring. Everybody leans on leet code and chasing the bleeding edge (buzzwords) because that's as far as the HR department's understanding of the technology that pays their salary goes.
It's not just the metrics. Over the years I've come to realize that in many cases these companies just sabotage the talent they do have. My own performance when I have my own office vs. when I didn't is night and day. The possession of an uninterruptible space for a few hours a day, of perceived privacy (a cubicle is little better than a dog crate)...
And in many of the places where I did not have an office, it wasn't because none were available. In most of the jobs I've worked, there have been multiple vacant offices going unused or becoming junk rooms where they stash old equipment to keep it out of the hallways.
Autonomy to solve problems... I don't know how many places I've been where it was tacitly supported for people to goof off for 20-30 hours a week, but god forbid you put effort into work that hadn't been directed from above.
And on and on and on.
Heh. That's me. The "no presence" part. About the 10x part, ask my colleagues. I want to believe I'm doing some good work but who knows.
But the no presence... I've got a kid, a house, a mortgage. I've been in software since I was a teenager. Am I still fascinated by it? Sure. Will I still spend hours and hours of free time? Nop. It long since stopped being a hobby. Right now I like reading and listening to audio books, when I have a break from house chores and child rearing. I like to cook and experiment in the kitchen. The endorphin feedback cycle is so much faster (hours) than large scale software (weeks to years). I like to watch interesting shows on TV. Write. Coding-wise, I'm invisible outside the company I work at.
Not strictly a 9-5, but with a kid I do try to have quality family time, so I condense as much as possible to my working day, leaving time to be with my loved ones. If there's something important I'll participate. If there's a pagerduty alarm I'll jump. But otherwise, I'll deal with it tomorrow. I've long since learned to identify real emergencies from artificial urgency "because there's a milestone deadline!". Sure there is. Like the old saying goes "I love deadlines. I love the wooshing sound they make when they go by". Is it a customer commitment? No? Then I'll work on it Monday morning, right now I'm out.
I value people like that. Being a hero is a young-people game. You can't be a hero for years and years and not burn out. I've seen that happen. Working every weekend? Then something is wrong with the estimation. Or the design. Or whoever is in charge of priorities.
God helps me when I look for a job again. I guess I'll have to rely on references and hope to hell I'll pass the filtering software to actually get someone to look at my application. So far I've been lucky. Last time I actually sent CVs was at the beginning of my career, as a new grad, 20 years ago. Ever since then I was picked out, carried over, invited in by people who knew me. Really, really hoping that'll keep being the case.
Related concept: the Market for Lemons: <https://en.wikipedia.org/wiki/The_Market_for_Lemons>.
In markets where information on quality is difficult to acquire, assess, and/or trust, you tend to get two results:
- Low-quality products flood the market. This leads buyers to assume lower-value products, and hence ...
- High-quality products are consistently under-priced. This leads those offering higher-value products to withdraw from the market, or to offer those products (or services) only in limited sub-markets where full value is more likely to be obtained.
The problem is a broad one, and long-predates used-car sales. There was a popular late-19th century book David Harum (1898) by Edward Noyes Westcott. All but forgotten today, it was a bestseller at the time and spun off several related franchises, including a 1934 film and 1936 radio serial. The title character was a horse trader, the profession which previously held a similar status to used-car salesman.
<https://en.wikipedia.org/wiki/David_Harum>
This isn’t a unique issue with software developers. In many fields, there’s a distinction between show horses vs work horses. A lot of people who spend time tooting their own horn are not necessarily the best at what they do. Finding the best people often involves word of mouth, not measuring git commits, IMDB rankings, design awards, or whatever.
In my 20 years of engineering, all my distributed systems knowledge was learnt in a period of two years under two amazing engineers working in two failed startups
One was like those legendary OG dogmatic distributed systems software engineer that you can meet and the other was an OG data platform person. They have zero social media presence but they have guaranteed jobs whomever they call.
I learnt my transactions and services from engineer 1 and my analytic/data platform fundamentals from engineer 2
I have made more money in the enterprise land but I think the two failed startups did 10x more to help me grow as an engineer
I am rather confident that an AI cannot come close to what I do and my management knows that
If anything I tend to think that the people who promote themselves the most aggressively are the ones who should be looked at with the most skepticism.
This is one reason startups can be so successfull. A founder who knows that they're doing will have a team of such illegible (and so undervalued) talent scouted out ahead of time and poach them for their venture. Basically talent arbitrage
But talent arbitrage, like any arbitrage closes as its utilized. Basically these people can be rescued by their former coworkers so as long as you make sure to work with people who know talent when they see it in action daily, you will be good
It is not a legibility problem as much as a risk problem. You can’t bee the guy that hires quirky people to take chances, just hire the “proper” people and move on.
It is just not possible to see who is “really” going to be more value anyway.
Related classic about information asymmetry: https://danluu.com/hiring-lemons/
I started my first full time job out of college a bit over a decade ago, in an old-school boring EU "midtech" company.
I didn't know this back then, but I was very lucky to have landed in a damn strong team.
Fast-forward to today, most of the team members now work for FAANG and other bigtechs... except the guy who was IMO the best of all of us. Still same team, same company, no LinkedIn account etc.
Ah what I would give to say that is the best software engineer I've worked with, alas I've been working in a sea of mediocre.
Promotion processes favour people who want to play the promotion game. These are rarely if ever the best people but from a certain point, the ranks are field with this kind of people anyway so they are happy playing together.
You can still do a very meaningful and satisfying career playing by your rule if you don’t care about striking your ego so much.
This is also why talent marketplaces don’t work so well.
We can know who is good for our last situation, but it comes with bias and is very hard to measure. This is true even for jobs that are easier to measure like Sales or Support.
I hate performing, but I don't know if there is a framework for me or for managers to identify and track such things. The irony is that these things would be visible only when they bite us and when the work is done in such situation the reward is high, I strongly believe it should be other way around because preventing something is far greater than fixing something after it goes wrong, the sad fact is that it is hard to realize the impact of the failure unless it happens and even if highlighted in reviews it is overlooked often.
I remember a Doctor Who episode where he said, paraphrasing, "You never get credit for the crisis you prevented before it happened".
Sort of https://en.wikipedia.org/wiki/Preparedness_paradox
It’s almost like the best engineers are, like, people who come in all shapes and sizes
Super nice guys, complete assholes, showmen, wallflowers - what they have in common is that they are great at making software
There are for sure personally types that are typical in certain traits, but we lose site of the fact that these do not tell you everything about who a person is
I likewise can give you stories of the best developers I’ve worked with - from Devry graduates, to high school dropouts, to HYPE wunderkinds - they come from all walks of life
I have no linked in and no recent GitHub commits. Who’s hiring ;-)
I think the number of approaches you can take to reach the same goal/standard increases with how abstract the work you're doing is. SWE is quite abstract.
I don't have the greatest work ethic, I waste time sometimes, forget things, am not too organized, etc. It's mostly the fact that 1) I do SWE as a hobby and 2) learn obsessively without BSing myself that gets me into jobs.
However my teammate at my last job. He probably didnt have the same level of intimate knowledge of systems as me. But his work ethic was just breathtaking. Mine simply wouldn't compare in a million years. Averaged over a large enough period, we both ended up doing the same amount of useful work.
Similarly there were others with different "approaches", just included the above 2 cases as an example.
Now. It wasn't the best experiment since we helped each other a lot. But I came away feeling it's true.
My hypothesis is that in less abstract work, the number of approaches is limited, and hiring practices in SWE have just been made the same as those jobs.
I don't really complain since I really can't think of a framework for hiring for abstract jobs that will yield better results than the current one. But who knows, maybe we'll find one.
FWIW, I think leetcode, just one round to bring down the applicant count to a number that's possible to interview {hard if there are too many, medium if there are few, or just Two Sum to weed out folks that can't write a for loop if you have just tens of applicants}, and then system design as the main interview, is a good system. For system design I would skip the common ones like "design a rate limiter/load balancer" stuff that people memorize. IMO it's easily possible to create unique system/API design questions that match the job somewhat.
Even when companies know they need something more than a normal senior developer, they don't necessarily know how to interview for that.
This afternoon, I'm leaning towards bowing out of a supposed more-than-normal engineering role.
If I wanted a battery of commodity techbro interview performance art hoop-jumping, just to be allowed to work at a place... then I would've gone to Google 1-2 decades ago, for 2-5 times what this place is offering, gotten rich, and then retired... so that I could then spend all my time making useful and trustworthy software.
I know what it's like to have a good interview "loop" for this level of impact role. Both sides of the table seem to value each other, ask good questions, focus on getting a sense of what it would be like to work together on the products/projects, with the team(s), and within the company culture. And see if that's something everyone feels really good about doing.
No "I need to haze you to 'understand how you think'". No BS performances of Coding Interview, System Design Interview, and Behavioral Interview, like every techbro is told they must "prep" for. No feeling like the other person might somehow be cheating (because you get the impression that they might be lying trash). No battery of rituals (in some cases) to the exclusion of people who'd be working together actually meeting each other before everyone has to decide whether to offer/join.
Well ... a lot of things are invisible if you get all your information from popular sources on the web.
The problem here is clearly the one doing the evaluation. Why do they even have a job themselves if they're so incapable of evaluating correctly?
There exists a quantitative method to correctly evaluate workers:
1. Collect each worker's work outputs and construct a training dataset.
2. Train an AI model with all work outputs combined.
3. For each worker, train a model with their respective work outputs deleted.
4. Construct a comprehensive evaluation benchmark over the full combined dataset.
5. For each worker, measure the change in the benchmark's performance with the worker's specific model relative to the full global model.
6. Fire the workers that lead to an unexpected improvement in the benchmark with their respective worker's model. This means that these workers were not contributing in a meaningful way to improving the performance over the benchmark. Keep the rest.
Ignoring how ridiculous and impractical this idea is, it fails to capture some of the most important skills in being a developer. Framing real-world problems as code problems. Anticipating design issues. Knowing the right trade-off between solution correctness, complexity,and effort. Mentoring and accelerating others. This is barely different than leetcode interviews.
> Why do they even have a job themselves if they're so incapable of evaluating correctly?
The only way for this to not be the case is if the first person you hired is the most competent that exists, and can do everything already, and therefor accurately measure the anyone in front of them. And, that goes on down the hiring chain.
In reality, you'll eventually need an expert in an area you are not an expert in, which means you won't necessarily have the insight on the best candidate. Maybe AI can do that someday, but definitely not today.
I also think this is what causes large orgs slowly fail: it's not only difficult for a person to gauge when another is smarter/more capable than them, but a smarter person can look less competent to someone hiring, because their answers/approach is outside of the known solution space of the interviewer. So, you end up with a slow net decrease in competence over time.
I've seen it in every org I've been a part of, from startups to corporate, including myself. Trying to judge a person, within small time slot is hard. The alternatives (like take home, temp to hire, etc) are also talent repellent. I think the most revealing method can be the Jim Keller method, where you let them nerd out on some potentially unrelated problem, but the results of that are hard to write down/justify.
This is magical thinking with trendy AI mixed in. Every step here has massive assumptions that are just baked in, like can their output be quantified in principle? How expensive is it? Will the model even be predictive? Can you gain the cooperation of workers or even the companies that they work for?
Every invention is considered magical thinking by some until it is made possible. Nothing I noted is actually magical or prohibited.
As for its feasibility, that's an engineering task. No cooperation is necessary from workers. It is in fact much more feasible than developing a modern LLM.
As for its cost, various optimizations are possible as with LLMs. Also, there are high costs to incorrect classifications currently made by management, so high that they can result in the disposal of the firm.
> No cooperation is necessary from workers.
I'm not sure this is ethical tbh.
Please, your employer captures everything you produce for your work. They have your screenshots, emails, chats, git history, Zoom call transcripts, and everything else. You signed off on it too. So save me the "this is ethical" crap. Actually it is ethical because it is much closer to being a blind and unbiased way of gauging utility.
This is only possible because they broke the power of labor unions. Nothing you've said convinces me that it would be unbiased or even measuring something real, in which case totally arbitrary decisions made by machine would be denying people access to basic necessities under our economic system.
I think the title of the article should be "invisible" not "illegible"
"Legibility" is a distinct reference to Tom C. Scott's Seeing Like a State, and the tendency of states (or other large institutions) to attempt to impose legibility on complex problems, domains, or systems, usually in an attempt to manage or govern them, but often destroying that which makes them valuable in the first place:
<https://en.wikipedia.org/wiki/Seeing_Like_a_State>.
It's not invisible, it's incomprehensible to most would-be employers because the information is not in a form that they can understand. That's not the same as invisible.
Passing some leetcode challenges is legible to employers, it puts applicants in the same buckets and measures them in (roughly) the same way. But it's not a good measure of actual talent. The real measures, as discussed in the article are out there but illegible to those employers.
It was a deliberate word choice by the author. "Illegible" conveys that it's difficult to track from the outside. It's a clever analogy: illegible hand writing can be read by those who are familiar with the scribe.
It's not invisible though: those who work with these kinds of engineers easily see how valuable they are.
It's not invisible, because some people can see it. It is illegible because the leadership of a large company won't know how to interpret it. This particular usage of "illegible" has been around for awhile, but is probably best known from the book, "Seeing Like A State":
https://www.amazon.com/dp/B07D2HZXB4/
By analogy, I'm reminded of a skit that we did in school:
A man, on his hands and knees, searching diligently for something on the ground.
Another man, walking by, stops to help search. After a few moments he asks "what are we searching for?"
The first man replies "My contact lens"
After a minute or two the second man, frustrated, asks "Where did you lose it?"
The first man replies "Way over there, but the light is better under this streetlamp."
Coding interviews kinda feel like that to me. We can't measure what's important, so we'd better measure what we can measure extremely rigorously.
I'm interviewing for Senior Staff roles and doing quality coding interviews and beyond the basics I'm not sure really what I'm supposed to ascertain from the format because it is so far removed from what is day to day important in the role.
I ask about time complexity, and all the basics, but it's just a bunch of malarkey. So I spend more time quizzing them about technologies I don't know on their resume and getting something out of it for myself. It's easy enough to tell when someone's full of shit, but asking them to describe the tradeoffs between the technologies they've worked with seems more valuable than watching someone sweat-ily cramming out some crap imperative code for a toy problem and telling me they got it down to nlogn. Oooo ee!
It might be helpful to look at this classic post by Joel Spolsky [0]. He discusses many of the points you brought up. I found it most helpful to pull out some of the principles he discusses and then ask "What would this look like when applied to [job in question]?"
[0]: https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...
https://en.wikipedia.org/wiki/Streetlight_effect
See also:
https://en.wikipedia.org/wiki/McNamara_fallacy
https://en.wikipedia.org/wiki/Goodhart's_law
> We can't measure what's important, so we'd better measure what we can measure extremely rigorously.
As much as we like to complain about interviews, the alternatives that more accurately reflect the work environment are much more strongly hated.
One of the most accurate interviewing methods is a work trial: Bring the candidate in for a week and have them work the job. Their peers and managers rate their performance.
It's great for revealing how a person works. But think about what's required: You would have to take a week off of your primary job every time you wanted to interview at another company. A company could only interview one candidate per week.
Some companies try this, but it over-selects for unemployed young people. They either give up or start bending the rules when qualified applicants refuse.
Did nobody ask why you would want to reuse contact lens fallen on some grimy ground in the night? Keys, coins, bills, even glasses ok, but putting back the contact lens into your eyes seems dangerous. I thought some kid might have spoken up :-).
Contact lenses used to be a lot more expensive and not disposable. They took a long time to get a new set. It was like loosing a pair of glasses.
It's keys, not contact lenses, and it's an old joke.
In the oldest reliable references from the 1920s, it was a $2 bill, $1 bill, a watch, and a dime.
So keys and contacts are both modern revisions.
I thought I sensed the implicit presence of the Quote Investigator!
https://quoteinvestigator.com/2013/04/11/better-light/
I used the AI, the web, and even tried to verify with full page scans but then I realized I have a job.
Over a century old! https://en.wikipedia.org/wiki/Streetlight_effect
Does the specific object matter in any way at all?
No. For example, in science most scientists just look where the streetlight is, but a small number of people build better, stronger lights to search larger areas, and there is a tiny number of people who can mysteriously just find things in the dark.
I just thought it was weird it was framed as "a skit we did in school" when it's a literally-ancient-old joke.
Contact lens is the way I have always heard the joke.
Is it just me or is [il]legible the word of the month somewhere? I suddenly keep seeing this word pop up in contexts I would not normally associate it with.
James C Scott, a Yale political scientist with an interest in agrarian societies, wrote a book Seeing Like A State in 1998. He was interested in why state-scale, “scientific” and “rational” schemes often fail to improve the outcomes they nominally set out to address (and often make them worse).
The book traced a number of case studies supporting the notion that large enough systems of control require some degree of standardization to implement—for example, to tax stuff, you have to know how much stuff there is. Village life might tend to have advantages for human well-being, but that doesn’t mean you’ll get that result by sending out troops to force everybody out of their traditional structure and into village footprints.
If you’re tallying up a nation’s agricultural capacity, “Farmer John’s got a nice-sized patch that’s extra fertile but he’s lazy” doesn’t add as well as “corn, 5 acres, Grade B”.
In that way of thinking, complexity, nuance, or localized idiosyncrasies—where a lot of useful information lives, but outside of the standardized spec—essentially becomes invisible to the system. Even though it’s essential to the social phenomenon the system is setting out to regulate.
It’s illegible to the centralized governance mechanism, so it may as well not exist, as far as that mechanism is concerned. No National ID number? You’re not a person, go away.
Sean Goedecke recently wrote a blog [1] applying that idea to software companies, I imagine that’s where the resurgence is coming from in these parts :)
[0] https://files.libcom.org/files/Seeing%20Like%20a%20State%20-...
[1] https://www.seangoedecke.com/seeing-like-a-software-company/
Thank you for the detailed explanation. In that case it makes sense because it was actually writing or recordkeeping done by a human hand that failed to communicate some pertinent bits of information (though in a more abstract sense than being physically unable to read the glyphs).
Extending it to observations of natural or emergent phenomena seems like a reach for fanciness when "inscrutable," "unclear," "murky," or "poorly understood" would be more accurate to me.
Edit: Upon further review, I am coming around to it a bit, in the sense of performance reviews looking for the wrong thing, but I still think the larger point is about something more complex that poor evaluation metrics are just a symptom of rather than the cause.
It's used here as a specific term from Seeing like a State[1][2], which is one of those books that got popular with a specific set of online tech folks. "Legibitility" in that particular sense is a very useful concept with no other convenient word, so I'm not too surprised it caught on.
[1]: https://en.wikipedia.org/wiki/Seeing_Like_a_State
[2]: available free to read online: https://files.libcom.org/files/Seeing%20Like%20a%20State%20-...
For what is worth, I read the book this year, after reading about it in the blog Bits about Money by patio11.
I find the use of "illegible" in the title weird myself. To my mind, the word they should use is Intangible.
He is leaning into this month's denotative abuse word: illegible.
I prefer "inscrutable" in this context.
There is a reference to a Ribbonfarm post where the term is explored: https://www.ribbonfarm.com/2010/07/26/a-big-little-idea-call...
I see where they are coming from but still have a hard time making the connection between the idea and the word.
This usage originates from Seeing Like a State. There was an HN thread the other day as well: https://news.ycombinator.com/item?id=45505539
We live in a small echo chamber :) It seems extremely likely the author of this post wrote it after reading the other post from the other day.
To this point, it is actually wild how we each see a different projection of the chamber depending on which articles and threads we dive into. As much as I feel like I "know" HN, I do marvel at the entire subsections of the discourse I'm completely oblivious to, and this is an interesting cross-pollination.