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.

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.

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.

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.

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>

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.

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

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

Related classic about information asymmetry: https://danluu.com/hiring-lemons/

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

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.

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.

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.

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.

What would a perfect hiring selection process look like? If we think there exists a perfect hiring process, then it would suggest there is a truth concerning who should be hired in each role. Our imperfect real world hiring processes can then be seen as trying to approximate these truths.

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.

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

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.

Its not who you know, it is who knows you.

This seems like a romantization of what good developers are supposed to be.

Most likely it is an exagerated take on what these individuals were able to achieve, and it downplays the role of HR.

Instead of HR being to blame for missing talent, it portrays that missing talent as "inherently stealthy", which might not be as true as reported.

Overall, we need less of this kind of mythology.

undefined

I have no linked in and no recent GitHub commits. Who’s hiring ;-)

I think the title of the article should be "invisible" not "illegible"

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.

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.

[flagged]

[flagged]