Things I’ve learned in my 20 years as a software engineer(simplethread.com)
simplethread.com
Things I’ve learned in my 20 years as a software engineer
https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/
745 comments
I do a lot of dev work with non-profits and such. About a year ago I was working on an extremely difficult project as a volunteer where I was insistent that a specific part was vitally important to getting the project to move forward (generalizing tables extraction from scanned OCR docs) and I was spending a lot of time on it. One of the devs I worked with, with 40+ years of experience, basically told me this exact thing. He argued that what I as working on was a waste of time and that I shouldn't work on "code golf" problems, because of the likelihood of failure and that ultimately I should consider the human side of the problem. He said it was best to work on other things instead.
Fast forward a month later, I managed to actually do it, and it worked almost flawlessly, across about 100k scanned PDFs. Multiple long-term projects spawned off from the extracted information, including some projects from the dev who told me to stop.
My point being -- sometimes it seems like that line is used as an excuse to not tackle hard problems if they seem likely to fail. I agree with the line, and it's the exact reason I worked on it as hard as I did, but the dev failed to consider that I understood the social part of the problem, on experienced principle.
Fast forward a month later, I managed to actually do it, and it worked almost flawlessly, across about 100k scanned PDFs. Multiple long-term projects spawned off from the extracted information, including some projects from the dev who told me to stop.
My point being -- sometimes it seems like that line is used as an excuse to not tackle hard problems if they seem likely to fail. I agree with the line, and it's the exact reason I worked on it as hard as I did, but the dev failed to consider that I understood the social part of the problem, on experienced principle.
> generalizing tables extraction from scanned OCR docs
I would actually categorize this as a human problem. As a society, we scan documents all the time. Data entry is a massive time sink usually involving lots of corrections.
True code golf would be like switching languages/frameworks for no discernable reason or trying to hit an arbitrary code coverage metric because you're unsatisfied with the current one.
I would actually categorize this as a human problem. As a society, we scan documents all the time. Data entry is a massive time sink usually involving lots of corrections.
True code golf would be like switching languages/frameworks for no discernable reason or trying to hit an arbitrary code coverage metric because you're unsatisfied with the current one.
It's a permanent balance. I have to "manage" (but I still am a main contributor) a small team in a big investment bank with angry busy trader-users, irrational "global" management in other continent thinking we're all dumbasses in Asia, and people on loaned rotation.
So, like your colleague, I try to strategize delivery. I would never tell a guy not to work on a genius idea that could change the entire paradigm, in fact I let 3 of my guys do just that for the last 3 months, together, sometimes alone. But they either not deliver, or very slowly, or sketchily (not working as well as thought).
So what I do a lot is a compromise. I force them, despite their complaint I don't care enough about the big picture of their non-delivering work, to take smaller issues every week. 1 or 2, give a candy to the user, and do your stuff then.
It worked incredibly well: while they've delivered absolutely nothing of value in their own initiatives yet (but I still think they can, it's just very long term), the users are delighted by a constant stream of little innovations and we've been recently identified as one of the most productive team.
Meanwhile, the team next to us, algo programmers in C++, can take 2 months to enhance an error message. Because they're all revolutionizing the system and have no time for basic human needs. They don't know yet, but they're gone soon. The budget people found there's a new model of delivery that could work, I wonder which one ;)
So, like your colleague, I try to strategize delivery. I would never tell a guy not to work on a genius idea that could change the entire paradigm, in fact I let 3 of my guys do just that for the last 3 months, together, sometimes alone. But they either not deliver, or very slowly, or sketchily (not working as well as thought).
So what I do a lot is a compromise. I force them, despite their complaint I don't care enough about the big picture of their non-delivering work, to take smaller issues every week. 1 or 2, give a candy to the user, and do your stuff then.
It worked incredibly well: while they've delivered absolutely nothing of value in their own initiatives yet (but I still think they can, it's just very long term), the users are delighted by a constant stream of little innovations and we've been recently identified as one of the most productive team.
Meanwhile, the team next to us, algo programmers in C++, can take 2 months to enhance an error message. Because they're all revolutionizing the system and have no time for basic human needs. They don't know yet, but they're gone soon. The budget people found there's a new model of delivery that could work, I wonder which one ;)
Good on you for trusting your team and allowing for such experimentation! We need more people in management with this attitude.
As per the blog's opening statement: context is key.
The industry (and really, it's not specific to the industry) is rife with people who take pearls of wisdom out of their context and apply them without the context to serve their own ends.
The industry (and really, it's not specific to the industry) is rife with people who take pearls of wisdom out of their context and apply them without the context to serve their own ends.
minuscule anecdote: my most cherished lines of code were an 8 lines vba excel macro to count duplicates for a non tech colleague.
Turned her day from hell to cool (she had to filter duplicates by hand and quadratic formulas over 2000+ lines spreadsheet.
That's what computers are for.
Turned her day from hell to cool (she had to filter duplicates by hand and quadratic formulas over 2000+ lines spreadsheet.
That's what computers are for.
I once spent two hours thinking about how to recursively assemble a tree structure from the database in a way that the JS presentation library wanted the data, then finally I wrote 2 lines of code.
Definitely my most cherished code.
Definitely my most cherished code.
Hah, this is something I've done when trying getting data from a government agency that can't run or write code themselves. It's usually in some awkward meta-adversarial context and they tend to be fearful of macros and such, but it's possible to get around that fear by writing everything in excel functions.
Sometimes those damn excel sheets take hours and hours to make even though it would otherwise take me less than a minute to write in SQL or unix. But it pays off every time and pushes a clear message that they can do better.
Sometimes those damn excel sheets take hours and hours to make even though it would otherwise take me less than a minute to write in SQL or unix. But it pays off every time and pushes a clear message that they can do better.
> sometimes
Any rule of wisdom, followed blindly, leads to disaster.
Don't substitute rules for good judgement.
Any rule of wisdom, followed blindly, leads to disaster.
Don't substitute rules for good judgement.
Or sometimes you have an approach that is high risk/reward. That's totally fine to take as long as your aware of the risk and have mitigations or offramps at the right points if you find the path isn't viable.
If we take your first statement to be a "rule of wisdom" then it is either false, or all roads lead to disaster anyway.
If you leave off the rest of my post, you're likely to misunderstand it :-)
If you're volunteering, why shouldn't you work on projects that you find interesting? I don't understand the point of view of the older dev.
I've found that volunteer work is _harder_ in terms of getting the human aspect right.
New volunteers sometimes expect the red-carpet treatment as someone volunteering their (pretty expensive presumably!) time and as someone accomplished in their field. Volunteers usually get the opposite treatment since it turns out the other volunteers tend to come from a similar perspective and someone doing the hard human work is often contributing a lot more to the project than an otherwise excellent engineer.
You can of course choose your volunteer activities to be interesting to you. Open source is one such very fun activity but lo-and-behold in projects I've been involved with the human aspect is often very important and requires a similar amount of hard work. This is often truer for bigger projects/organizations than small ones.
New volunteers sometimes expect the red-carpet treatment as someone volunteering their (pretty expensive presumably!) time and as someone accomplished in their field. Volunteers usually get the opposite treatment since it turns out the other volunteers tend to come from a similar perspective and someone doing the hard human work is often contributing a lot more to the project than an otherwise excellent engineer.
You can of course choose your volunteer activities to be interesting to you. Open source is one such very fun activity but lo-and-behold in projects I've been involved with the human aspect is often very important and requires a similar amount of hard work. This is often truer for bigger projects/organizations than small ones.
Even if you're volunteering you still have to work towards agreed upon objectives. You wouldn't show up on a Habitat for Humanity build site an start modifying the blueprints and working on whatever you found interesting because you are volunteering and are entitled to only work on interesting projects.
Presumably you want to maximize the positive impact your volunteering has on others.
But having people working on potentially extremely useful moonshots that they are interested in for free is a huge win. I think it's really just a case of bad advice, and not all developers with 40+ years of experience are correct. In my opinion, it's better to have a motivated volunteer engaged and working on something with unknown impact that she is interested in, rather than get her to work on boring things with less impact.
of course not, humans are most often wrong about everything. Someone with experience is just that. Our perspective changes.
I started coding at 12 because everyone said it was much to hard for me. Now im old and motivate people by doing the same. At the same time its good to be reminded by others what happens if you drop one thing in favor of the other.
I started coding at 12 because everyone said it was much to hard for me. Now im old and motivate people by doing the same. At the same time its good to be reminded by others what happens if you drop one thing in favor of the other.
Predicting the future is hard. You were both right. You only have the outcome to judge the decision, not the full probability distribution.
This is so important - it's so hard to gauge what another person's mental model of a scenario is compared to yours.
As in - perhaps OP and 40+ year person had the same, accurate mental model of the probability distribution of success, but OP and 40+ had different attitudes towards risk/reward.
Or perhaps the OP happened to have a much more realistic picture of the probability of success, and 40+ was unnecessarily pessimistic.
So hard to evaluate these things, and to internalise the fact that other people don't have the information you have all the time.
As in - perhaps OP and 40+ year person had the same, accurate mental model of the probability distribution of success, but OP and 40+ had different attitudes towards risk/reward.
Or perhaps the OP happened to have a much more realistic picture of the probability of success, and 40+ was unnecessarily pessimistic.
So hard to evaluate these things, and to internalise the fact that other people don't have the information you have all the time.
Yep! If I wasn't successful, he would have been right and I can't really blame him too much for thinking it his way. The problem was particularly tricky because it combined bunches of distinctly esoteric domains (OCR, text/vector maps, image processing, fuzzy string matching).. recursively. There were no boundary lines and inconsistently sized black redaction boxes. If I hadn't worked on problems in each domain in separate projects, I doubt I would've been able to do it and he had no way of knowing my experience.
Make an API out of that. There is huge demand for it.
I needed to do this, so happy someone else made it!
A nice FOSS library for it was on HN recently, sharing is caring I guess
https://news.ycombinator.com/item?id=28680136
https://extract-table.com/
https://github.com/vegarsti/extract-table
A nice FOSS library for it was on HN recently, sharing is caring I guess
https://news.ycombinator.com/item?id=28680136
https://extract-table.com/
https://github.com/vegarsti/extract-table
I'm pretty sure AWS Textract does that already.
https://aws.amazon.com/textract/
https://aws.amazon.com/textract/
I believe such an API already exists: https://pdftables.com/ (no affiliation).
Went to a presentation at a Golang meetup in Amsterdam by the guys behind this company. Seemed to know their stuff. But I have no real world experience using it.
Went to a presentation at a Golang meetup in Amsterdam by the guys behind this company. Seemed to know their stuff. But I have no real world experience using it.
I had a look - from their FAQ [0]:
However, some PDFs are scanned documents, or only contain images. PDFTables doesn't perform Optical Character Recognition (OCR) to turn these images into text.
To process these kinds of documents, you will need to either enable OCR in your scanning software, or run the PDF through specialist OCR software before using PDFTables.
[0] https://pdftables.com/faq
However, some PDFs are scanned documents, or only contain images. PDFTables doesn't perform Optical Character Recognition (OCR) to turn these images into text.
To process these kinds of documents, you will need to either enable OCR in your scanning software, or run the PDF through specialist OCR software before using PDFTables.
[0] https://pdftables.com/faq
I’m in need of that right now! Would pay for it, especially if the proceeds benefitted that non-profit!
Looks this does it https://www.extracttable.com/
30+ years here, so I'm just a youngster compared to you, but yes, that seems to get lost.
My first mentor in the 80's was a jolly drunken programmer genius who enjoyed getting me to laugh at how bad my code was.
His biggest lesson was that other people need to read and use my code, not just me. It isn't enough to just hack a solution -- "Anyone CAN write code, but not everyone SHOULD write code" was his favorite quote -- but code needs "style" and "heart".
He even had a t-shirt made for me after my internship ended that had those two words and a bunch of my worst code examples printed on it. I still have it: just a bunch of MASM code. I'll Never forgot that guy.
My first mentor in the 80's was a jolly drunken programmer genius who enjoyed getting me to laugh at how bad my code was.
His biggest lesson was that other people need to read and use my code, not just me. It isn't enough to just hack a solution -- "Anyone CAN write code, but not everyone SHOULD write code" was his favorite quote -- but code needs "style" and "heart".
He even had a t-shirt made for me after my internship ended that had those two words and a bunch of my worst code examples printed on it. I still have it: just a bunch of MASM code. I'll Never forgot that guy.
I think this applies to not just software, but engineering in general. See, science is mostly about observing the natural phenomena. On the other hand, there are jobs that are mostly about taking care of people's needs. Engineering sits in the middle. It's a mediator. We have to understand the circumstance of both sides - nature (this could be something like hardware capacity in our case) AND people. Just taking care of one side makes you a bad engineer. You need to be technical and sympathetic at the same time.
It applies to every job not just engineering. I thought this was considered obvious.
To clarify, you're saying that you vire that that being technical and observing natural/physical phenomena are important parts of selling clothing at retail, being a novelist and working as a receptionist?
I think those are important jobs, and completely disagree with you. I'm trying to understand if those are jobs you weren't considering, or if we view each the responsibilities of those jobs very differently.
I think those are important jobs, and completely disagree with you. I'm trying to understand if those are jobs you weren't considering, or if we view each the responsibilities of those jobs very differently.
No. I'm saying that retail, much like being a novelist or a receptionist or a software programmer or indeed any job is, as the OP puts it, a "social service".
That being one of the defining charactetistics of a job.
That being one of the defining charactetistics of a job.
You're saying you're agreeing with OP, but your statements contradict.
OP calls out 3 categories of jobs. Mainly natural/technical, mainly social, and those which sit in the middle and require both. Finally OP says engineering sits in the middle and requires both.
You said it's not just engineering (that requires both), but all jobs.
Both I and OP disagree with that statement.
OP calls out 3 categories of jobs. Mainly natural/technical, mainly social, and those which sit in the middle and require both. Finally OP says engineering sits in the middle and requires both.
You said it's not just engineering (that requires both), but all jobs.
Both I and OP disagree with that statement.
For many people it definitely is not - some folks get into software engineering because they have the mistaken (albeit not as mistaken as if they were going into another career like medicine!) belief they can avoid people and just deal with machines.
Approching the same experience level and fully agree.
A piece of coding art that doesn't fulfill customer needs, or requires understading of language standard minutia for fellow devs to do maintainance updates is worthless.
A piece of coding art that doesn't fulfill customer needs, or requires understading of language standard minutia for fellow devs to do maintainance updates is worthless.
Yes, or in some cases even worse than useless - an active problem that requires expensive specialization to not make things an even bigger mess
The biggest mistake people in our industry make is thinking they are somehow exempt from the rules of society and business just because they can use a computer better than most people.
Heads down genius coder everyone steps around ends up fired or stuck in mid level forever, in reality. Guy who makes friends with the Customer Service department and Sales team with mediocre fixes get promoted, and in reality achieves more with his career.
Software is useless without users.
Heads down genius coder everyone steps around ends up fired or stuck in mid level forever, in reality. Guy who makes friends with the Customer Service department and Sales team with mediocre fixes get promoted, and in reality achieves more with his career.
Software is useless without users.
What's the quote? Knowledge can be taught. Wisdom can't be taught or told... it can only be learned through experience?
Edit: Ah, found it.
"Wisdom cannot be imparted. Wisdom that a wise man attempts to impart always sounds like foolishness to someone else ... Knowledge can be communicated, but not wisdom. One can find it, live it, do wonders through it, but one cannot communicate and teach it." - Siddhartha
Edit: Ah, found it.
"Wisdom cannot be imparted. Wisdom that a wise man attempts to impart always sounds like foolishness to someone else ... Knowledge can be communicated, but not wisdom. One can find it, live it, do wonders through it, but one cannot communicate and teach it." - Siddhartha
"Wisdom can't be taught or told... it can only be learned through experience"
I recently had the thought, that good education guides you to certain experiences to really learn the subject and not memorize some definitions.
I recently had the thought, that good education guides you to certain experiences to really learn the subject and not memorize some definitions.
Problem is that people learn the wrong things from their experiences, not that they lack the experiences.
The way I was told it: "Knowledge is knowing it's a one-way street. Wisdom is learning to look both ways anyway."
Software is whatever you want it to be. I can write software that is not for other humans. That's the most fun part of software engineering to me, when you don't care about the users and just do it just for the fun of doing it.
Almost any advice is useless if you write code purely for your own enjoyment. This is why the context is so important. If you enjoy writing convoluted unmaintainable useless code then who is to stop you? Just understand most advice does not apply to your context.
Most software development advice tacitly assume you want to write code which works and is long-term maintainable (potentially by someone other than yourself) and which fulfills some purpose beyond just the fun of writing the code.
Most software development advice tacitly assume you want to write code which works and is long-term maintainable (potentially by someone other than yourself) and which fulfills some purpose beyond just the fun of writing the code.
> If you enjoy writing convoluted unmaintainable useless code then who is to stop you?
Does anyone actually do this? I think it's the opposite.
I've spent truly absurd amounts of time thinking about how to do things properly. I read books, read other people's code, read programming language implementations, I just read and learn as much as I possibly can before I even start doing anything. I want my code to be right. I want it to represent the truth of how the world works.
In a professional context where people actually have deadlines, working code is usually enough to satisfy them. How complex and maintainable it is tends to be a lesser concern, to be addressed at a later time or never.
Does anyone actually do this? I think it's the opposite.
I've spent truly absurd amounts of time thinking about how to do things properly. I read books, read other people's code, read programming language implementations, I just read and learn as much as I possibly can before I even start doing anything. I want my code to be right. I want it to represent the truth of how the world works.
In a professional context where people actually have deadlines, working code is usually enough to satisfy them. How complex and maintainable it is tends to be a lesser concern, to be addressed at a later time or never.
> > If you enjoy writing convoluted unmaintainable useless code then who is to stop you?
> Does anyone actually do this? I think it's the opposite.
Code style, structure, and design are more of an art than a science, so different people will have wildly different opinions (extreme examples notwithstanding).
> Does anyone actually do this? I think it's the opposite.
Code style, structure, and design are more of an art than a science, so different people will have wildly different opinions (extreme examples notwithstanding).
I don't think anyone deliberate writes unmaintainable code except as a joke. Hard to maintain code happen when some other objective takes priority - performance, abstractions, architectural purity, DRY or whatever else a developer might enjoy focusing on.
The most maintainable code tend to be the least clever. But developers enjoy being clever, so without any outside pressure to deliver maintainable code, developers will tend towards less maintainable code.
The most maintainable code tend to be the least clever. But developers enjoy being clever, so without any outside pressure to deliver maintainable code, developers will tend towards less maintainable code.
And, as the article says, your advice and the GP’s are contextual.
If you’re interested in creating software that makes people happy, solves their problems, gets cherished and recommended - then work hard to not lose sight of that goal in the thick of crafting a massive code edifice.
If you’re interested in pushing the limits of your own creativity, and building a technical structure capable of handling domain complexity with ruthless efficiency - then sure, don’t worry too much about how it looks, how it reads, or how others respond to it.
If you’re lucky, you might get to do both in the same body of code. But not likely.
If you’re interested in creating software that makes people happy, solves their problems, gets cherished and recommended - then work hard to not lose sight of that goal in the thick of crafting a massive code edifice.
If you’re interested in pushing the limits of your own creativity, and building a technical structure capable of handling domain complexity with ruthless efficiency - then sure, don’t worry too much about how it looks, how it reads, or how others respond to it.
If you’re lucky, you might get to do both in the same body of code. But not likely.
Even if YOU are the only user, you're still writing software for a human.
Hopefully.
Hopefully.
With that argument you could say that everything humans ever did was for humans. So either it is a platitude or it is wrong.
You could say that, but my cat thinks you'd be wrong.
However, I'm yet to see my cat boot up the computer.
However, I'm yet to see my cat boot up the computer.
Ultimately pets are for humans, whatever you do for your cat you do for humans. The same logic works there.
My cat would often turn the computer on or the tv off, and I swear he did it on purpose because that's when he was complaining he didn't got enough attention.
My cat has turned off my computer on me - does that count?
You’re writing software for all of your future selves.
http://www.catb.org/~esr/writings/unix-koans/prodigy.html
http://www.catb.org/~esr/writings/unix-koans/prodigy.html
Thank you for posting this. I feel understood.
But then we can also go the other way, and forget how crazy and diverse humans are. So you will still, eventually, end up facing the same challenge, framed differently.
Well, you could create software as art. Basically to create it for the fun of creating it, not to use it.
But yeah, the end result is useless then, and can be thrown out.
But yeah, the end result is useless then, and can be thrown out.
Or, like some art, of variable degrees of folks caring about it based on other interesting properties - and made for some purpose other than maintainability.
Demoscene, obfuscated coding contests, etc. seem to fall under that category.
Uselessness in the eye of the beholder or something like that.
Demoscene, obfuscated coding contests, etc. seem to fall under that category.
Uselessness in the eye of the beholder or something like that.
But in those cases you are creating for other people. The point was made about software that didn't have any use for any people.
In those cases, only the creation itself has a use, not the end result. By definition.
In those cases, only the creation itself has a use, not the end result. By definition.
Don't forget to write for future you. They'd appreciate some consideration as well. Mostly along the lines of "wtf does this module do?"
The best one for me was documentation to complicated for me - by me.
You seem to have a complicated relationship with your past self. I foresee further trouble in your future. Its best if you take a torch or you'll be eaten by a grue.
> when you don't care about the users and just do it just for the fun of doing it
Yes!! That makes me so happy.
Yes!! That makes me so happy.
So you write code in machine language? Or are you writing in a language that tries to be readable by English speaking humans?
Or they write it for themself and not _other_ humans.
Your future self can be seen as “other” humans given a long enough time frame.
Anybody who has looked at their own code done more than 5 years ago can surely attest.
Anybody who has looked at their own code done more than 5 years ago can surely attest.
5 years is optimistic. A lunch break can be enough.
Can't agree with this enough. Sometimes it is directly for other humans (a GUI), other times it is indirectly related (an ETL job that converts data into a form that can be easily used to drive a recommendation engine which provides recommendations ... to people).
This is tied into asking "why", another one of the author's points. At the end of the day, if you dig deep enough, the why will be related to human happiness.
Bonus! If you keep this in mind, you'll also gain perspective. While you don't want to live at 30k feet all the time, periodically gaining high level perspective of the problem you are solving has been, for me, one of the joys of software development. (Not the only one, but definitely a significant one.) Hopefully it is that way for you too.
This is tied into asking "why", another one of the author's points. At the end of the day, if you dig deep enough, the why will be related to human happiness.
Bonus! If you keep this in mind, you'll also gain perspective. While you don't want to live at 30k feet all the time, periodically gaining high level perspective of the problem you are solving has been, for me, one of the joys of software development. (Not the only one, but definitely a significant one.) Hopefully it is that way for you too.
> At the end of the day, if you dig deep enough, the why will be related to human happiness.
At one of my jobs, one of my tasks was to take client HR feeds and load them into downstream systems for travel management. On your second day of employment at your company, you should have a profile in our system which was a portal that displayed all travel policies and a profile in whatever booking tool your company used.
We knew who your manager was so approval emails went out automatically. We knew what corporate card was assigned to you, so you never had to deal with that. We knew what preferred vendors your company had agreements with etc
All I was doing was data manipulation and loading on a scheduled or triggered basis. But ultimately it allowed new hires in a new environment to have an easy time booking their trip for mandatory training.
Any time our process failed, you had a traveler stressed out that they wouldn’t be able to book the trip in time or have to outlay money and reimburse later or get stuck at a distant airport.
At one of my jobs, one of my tasks was to take client HR feeds and load them into downstream systems for travel management. On your second day of employment at your company, you should have a profile in our system which was a portal that displayed all travel policies and a profile in whatever booking tool your company used.
We knew who your manager was so approval emails went out automatically. We knew what corporate card was assigned to you, so you never had to deal with that. We knew what preferred vendors your company had agreements with etc
All I was doing was data manipulation and loading on a scheduled or triggered basis. But ultimately it allowed new hires in a new environment to have an easy time booking their trip for mandatory training.
Any time our process failed, you had a traveler stressed out that they wouldn’t be able to book the trip in time or have to outlay money and reimburse later or get stuck at a distant airport.
> Software is a social service. Its for other humans.
I deeply disagree with this Calvinist utilitarian sentiment. Its akin to saying sex is for making babies. Maybe its an academic thing - When I went to grad school for CS, on Day 1 my Algorithms Professor paraphrased Perlis's famous quote on the blackboard - "Shaft the paying customer!"
You can find the whole quote on the first page of SICP[1], or elsewhere[2]. imho its a highly toxic sentiment to think that whatever a programmer does is for other humans. Software as a Social Service...SAAS :)
imho the best software is written to scratch a personal itch. Not to appease this customer. Not for other humans. Not as a social service. In fact all the people I deeply admire in the software world - Arthur Whitney, Kenneth Iverson, Mattis & Kimball, Perlis, Dijkstra, hell even Linus, are generally characterized as egotistical assholes in the public space who really don't give a flying fuck about social service & humans but care deeply about the software they created for their own selfish reasons.
Mattis is quite explicit about this - "You should understand that the GIMP and GTK weren't written to fill holes in the software available under the GPL...GIMP was started because I wanted to make a Web page. GTK was started because I was dissatisfied with Motif...These are purely selfish reasons. That is probably why the projects...eventually succeeded. I find it much more difficult to work on something for selfless reasons."
Perlis - "I hope we don’t become missionaries. Don’t feel as if you’re Bible salesmen. The world has too many of those already. What you know about computing other people will learn."
otoh the people I deeply detest in software (too numerous to name) are generally these do-gooder types who write software to save the world & provide social service, employment to the masses, add "value" insert-marketing-speak-here etc...
I'm ok with the hypocrisy in pretending to care about software as a social service because I need to put food on the table like any other programmer on the market, but deep inside, I write code only for myself. I think a big fraction of developers are like that. There's no harm in saying it out loud.
[1]https://cloudflare-ipfs.com/ipfs/QmQ3C4ooSCmBMuK7mKq4sqVAfGq...
[2]https://www.goodreads.com/quotes/405620-i-think-that-it-s-ex...
I deeply disagree with this Calvinist utilitarian sentiment. Its akin to saying sex is for making babies. Maybe its an academic thing - When I went to grad school for CS, on Day 1 my Algorithms Professor paraphrased Perlis's famous quote on the blackboard - "Shaft the paying customer!"
You can find the whole quote on the first page of SICP[1], or elsewhere[2]. imho its a highly toxic sentiment to think that whatever a programmer does is for other humans. Software as a Social Service...SAAS :)
imho the best software is written to scratch a personal itch. Not to appease this customer. Not for other humans. Not as a social service. In fact all the people I deeply admire in the software world - Arthur Whitney, Kenneth Iverson, Mattis & Kimball, Perlis, Dijkstra, hell even Linus, are generally characterized as egotistical assholes in the public space who really don't give a flying fuck about social service & humans but care deeply about the software they created for their own selfish reasons.
Mattis is quite explicit about this - "You should understand that the GIMP and GTK weren't written to fill holes in the software available under the GPL...GIMP was started because I wanted to make a Web page. GTK was started because I was dissatisfied with Motif...These are purely selfish reasons. That is probably why the projects...eventually succeeded. I find it much more difficult to work on something for selfless reasons."
Perlis - "I hope we don’t become missionaries. Don’t feel as if you’re Bible salesmen. The world has too many of those already. What you know about computing other people will learn."
otoh the people I deeply detest in software (too numerous to name) are generally these do-gooder types who write software to save the world & provide social service, employment to the masses, add "value" insert-marketing-speak-here etc...
I'm ok with the hypocrisy in pretending to care about software as a social service because I need to put food on the table like any other programmer on the market, but deep inside, I write code only for myself. I think a big fraction of developers are like that. There's no harm in saying it out loud.
[1]https://cloudflare-ipfs.com/ipfs/QmQ3C4ooSCmBMuK7mKq4sqVAfGq...
[2]https://www.goodreads.com/quotes/405620-i-think-that-it-s-ex...
> imho the best software is written to scratch a personal itch. Not to appease this customer. Not for other humans.
This statement shows you partially understand, but don't understand the why. You recognize that people working on software for things they truly care about can write better more successful software, but you miss the final step of why that software is more successful.
The reason why Linus can write such great software for software engineers is because he is a software engineer. Fundamentally the software you love is successful for other people, it is for other people and because your idols are one of those people part of that group, they understand it as well as anyone.
Linux was made for passionate hobbyist programmers by a passionate hobbyist programmer. And because it is made for those people, and met their needs perfectly is why it caught on. The reason it met their needs is because Linus understood their needs, because he shared them.
That's the key piece - that great software is written by completely meeting users needs. The easiest way to understand and meet other people's needs is by sharing them. That's the final step of it.
Fundamentally software becomes successful by meeting other people's needs. Anything else that doesn't, you've never heard of.
This statement shows you partially understand, but don't understand the why. You recognize that people working on software for things they truly care about can write better more successful software, but you miss the final step of why that software is more successful.
The reason why Linus can write such great software for software engineers is because he is a software engineer. Fundamentally the software you love is successful for other people, it is for other people and because your idols are one of those people part of that group, they understand it as well as anyone.
Linux was made for passionate hobbyist programmers by a passionate hobbyist programmer. And because it is made for those people, and met their needs perfectly is why it caught on. The reason it met their needs is because Linus understood their needs, because he shared them.
That's the key piece - that great software is written by completely meeting users needs. The easiest way to understand and meet other people's needs is by sharing them. That's the final step of it.
Fundamentally software becomes successful by meeting other people's needs. Anything else that doesn't, you've never heard of.
> imho the best software is written to [...]
What do you mean by "best"? If it is supposed to be judged by the original author of the software alone, your opinion does not matter. If you think your opinion of software written by others matters, then BAM, you've acknowledged what you set out to refute, i.e. Software is written for (or at least its quality can be judged by) other humans. (Unless you're actually a GPT-3 bot in disguise, in which case you win :D)
What you might have shown is that software not written for others can still be great in the eyes of other people, but even that is somewhat nuanced. IIRC one of Linus' egotistical outbursts was triggered by a kernel dev intentionally breaking user-space compatibility. At least in this case Linus' example doesn't support your claims.
I also don't see why "software is written for other humans" necessarily snuffs the fun or interesting aspects out of it. There certainly are large number of un-fun software that serves a commercial purpose, but it doesn't mean that fun software has to be anti-social. Even entries submitted to IOCCC (purposely obfuscated C code written purely for fun) sometimes lead to useful stuff (Fabrice Bellard's work).
What do you mean by "best"? If it is supposed to be judged by the original author of the software alone, your opinion does not matter. If you think your opinion of software written by others matters, then BAM, you've acknowledged what you set out to refute, i.e. Software is written for (or at least its quality can be judged by) other humans. (Unless you're actually a GPT-3 bot in disguise, in which case you win :D)
What you might have shown is that software not written for others can still be great in the eyes of other people, but even that is somewhat nuanced. IIRC one of Linus' egotistical outbursts was triggered by a kernel dev intentionally breaking user-space compatibility. At least in this case Linus' example doesn't support your claims.
I also don't see why "software is written for other humans" necessarily snuffs the fun or interesting aspects out of it. There certainly are large number of un-fun software that serves a commercial purpose, but it doesn't mean that fun software has to be anti-social. Even entries submitted to IOCCC (purposely obfuscated C code written purely for fun) sometimes lead to useful stuff (Fabrice Bellard's work).
> provide social service, employment to the masses,
If I want the computer to do XYZ, and I can provide an XYZ service to other people? They're paying me to do my bug testing, and I get to feel good about it.
If you're providing something that you think is a really good service, but not for people like you, and not for somebody specific you know either, it's probably going to be rubbish.
If I want the computer to do XYZ, and I can provide an XYZ service to other people? They're paying me to do my bug testing, and I get to feel good about it.
If you're providing something that you think is a really good service, but not for people like you, and not for somebody specific you know either, it's probably going to be rubbish.
So if Linus works on Linux for his own selfish reasons, howcome Linux isn't a one-person effort that nobody else is using? And why did they pick the GPL?
It sounds to me like you're describing bad social behavior but generally altruistic motivations with good social behavior but non-altruistic motivations, and you prefer the former over the latter. Sure, thats fine.
It sounds to me like you're describing bad social behavior but generally altruistic motivations with good social behavior but non-altruistic motivations, and you prefer the former over the latter. Sure, thats fine.
I think software is human expression. It can be a social good or a business driver. But it does not have to be. It can have no users, no IO or never run on a computer and still encode deep meaning.
Does it need to be social to be useful? That is a value system.
Many here communicate (beautiful) value systems, and that's great! But ideas and software can transcend those.
Does it need to be social to be useful? That is a value system.
Many here communicate (beautiful) value systems, and that's great! But ideas and software can transcend those.
35y+ here, i just sent him something along:
"software is communication, made by people, for people"
(which is more or less what you say :)
With all the consequences. Most people, on either side, don't get it. Ever.
"software is communication, made by people, for people"
(which is more or less what you say :)
With all the consequences. Most people, on either side, don't get it. Ever.
you can replace the word "software" with basically any other professional work and that is still the same. I don't know what you can learn from the fact that it's a social service.
I've met a lot of people who are writing code to satisfy requirements and collect a paycheck. They're good people, but just don't automatically think about the end user. They stop when the requirements are met, instead of when the user will be happy.
That's what they're supposed to learn from that, IMO.
That's what they're supposed to learn from that, IMO.
> They stop when the requirements are met, instead of when the user will be happy.
that's because they are doing software "for other humans" - aka, their manager and PM, who gave them the requirements.
So the problem is not the software engineer, but the person who creates those requirements to be fulfilled.
that's because they are doing software "for other humans" - aka, their manager and PM, who gave them the requirements.
So the problem is not the software engineer, but the person who creates those requirements to be fulfilled.
I think what the parent may have been complaining about is essentially myopia in interpreting things - ‘well, this technically checks the box of what they ask for’ while willingly avoiding thinking about the larger context of what is being attempted or trying to understand requirements that don’t make much sense.
Don’t get me wrong - it has it’s place, and if everyone always tried to understand everything, there are a lot of organizations and situations it would be crushing - but it’s also very frustrating in many situations for those who want high quality products.
It’s the ‘not my job’ syndrome, essentially.
Don’t get me wrong - it has it’s place, and if everyone always tried to understand everything, there are a lot of organizations and situations it would be crushing - but it’s also very frustrating in many situations for those who want high quality products.
It’s the ‘not my job’ syndrome, essentially.
> I think what the parent may have been complaining about is essentially myopia in interpreting things - ‘well, this technically checks the box of what they ask for’ while willingly avoiding thinking about the larger context of what is being attempted or trying to understand requirements that don’t make much sense.
I think what your post’s parent was pointing out is that in lots of environments, such myopia is just an engineers job definition, for which they will be punished if they stray. Interpreting end-user needs is someone else's job.
I think what your post’s parent was pointing out is that in lots of environments, such myopia is just an engineers job definition, for which they will be punished if they stray. Interpreting end-user needs is someone else's job.
I think we just violently agreed, and even repeated the same last line?
I'm not asking that develop to go against the requirements. But it's often possible to satisfy requirements without satisfying the user, even though it's actually possible to do both.
Some organizations are structured such that it is difficult for an engineer to do anything else. An engineer doesn't always have access to the end user, unfortunately.
Well, all economy is human economy, so yeah .. okay.
You can learn from the fact that its a social service by actively NOT resisting the truth of this fact.
Incorporate it into your thinking with every commit you make and you will become a better programmer over time.
(Corollary: those developers who forget this fact, make shitty software...)
You can learn from the fact that its a social service by actively NOT resisting the truth of this fact.
Incorporate it into your thinking with every commit you make and you will become a better programmer over time.
(Corollary: those developers who forget this fact, make shitty software...)
Everyone agrees that software is to serve humans. What they disagree about is how to best make software that serves humans.
For example, lets say you write an API that translates text. Should you assume the text the human sent in is correct and return an error? That way you can make better translations when they send the right data. Or should you try to be helpful and automatically fix spelling errors you think you've found in order to make the API more human friendly? Would make it easier but reduce accuracy.
You seem to be in the second camp, reduce power of API and make them easier to use. But lots of people think that the best way to serve humans is to make more powerful and strict API's.
For example, lets say you write an API that translates text. Should you assume the text the human sent in is correct and return an error? That way you can make better translations when they send the right data. Or should you try to be helpful and automatically fix spelling errors you think you've found in order to make the API more human friendly? Would make it easier but reduce accuracy.
You seem to be in the second camp, reduce power of API and make them easier to use. But lots of people think that the best way to serve humans is to make more powerful and strict API's.
Either option is fine, as long as your user agrees.
You have more than one user. Some of them will want power, other will want ease of use. You can't satisfy everyone without making multiple products.
More than that, there may be a whole stack of software components between your API and your users. In this sense, quite a lot of software is written for computers and not other humans (or, your users are other software devs).
This is to say, "all software is written for humans" is too general to be useful - the important issues are all in the details.
This is to say, "all software is written for humans" is too general to be useful - the important issues are all in the details.
Probably something to do with the computer not caring about that. If you constantly divide your time between someone that’s 100% logical, and someone that generally isn’t, you’re bound to get confused.
Gonna expand on this just a bit. Software isn't a product or a service. It's a tool. No end user cares what your stack looks like, they just want to click a button that solves their problem.
Nothing between "click button" and "problem solved" is your user's problem, they're all yours.
Nothing between "click button" and "problem solved" is your user's problem, they're all yours.
Very few recent programs i've seen were socially useful. Some might find comedy in this but the app my current gig uses:
- is un ergonomic and redundant (typing the same thing over and over, no keyboard shortcut jquery era procedural code)
- the overall design is useless, it produces libreoffice templates that takes ages to be badly filled
- secretaries go faster using fucking paper and filling everything by hand
- the application has all the data at hand but nobody has access to stats or complex queries, people have to also write down stats with stick marks on paper so the hierarchy knows what's going on
alas
- is un ergonomic and redundant (typing the same thing over and over, no keyboard shortcut jquery era procedural code)
- the overall design is useless, it produces libreoffice templates that takes ages to be badly filled
- secretaries go faster using fucking paper and filling everything by hand
- the application has all the data at hand but nobody has access to stats or complex queries, people have to also write down stats with stick marks on paper so the hierarchy knows what's going on
alas
What do I do with this, though?
I think I get what it means but how do I act on it?
I think I get what it means but how do I act on it?
Always keep the human in mind, whatever software you are righting. Its turtles all the way up to the human.
Is this meant to be "code is for the reader, not the compiler", or "people are the ultimate end users of your software"?
20+ years and I concur.
Improvements in my "soft skills" have carried me further than any technical learning.
Improvements in my "soft skills" have carried me further than any technical learning.
A corollary-ish observation of my own:
* If coders could write useful documentation (starting w/inline comments) they probably wouldn't be coders.What would they be instead?
Communicators. (Writers, marketers, teachers, ...)
Then they'd make less money.
Why would they choose less money
(Unless of course if they like those other jobs better)
Why would they choose less money
(Unless of course if they like those other jobs better)
[deleted]
They would be what then?
> Incredibly, it doesn't matter how educated the developer, they still seem to have to learn this lesson themselves, over and over, until it sinks in...
That's probably because many devs were socially isolated when growing up. (How do you think they got so much time spent tinkering with computers?)
Also, it is generally hard to imagine yourself in other's shoes. Example: imagine trying to use your UI but with a 60-year old vision instead of that of a 20-yo. Example: imagine having no formal address or no citizenship (stateless).
That's probably because many devs were socially isolated when growing up. (How do you think they got so much time spent tinkering with computers?)
Also, it is generally hard to imagine yourself in other's shoes. Example: imagine trying to use your UI but with a 60-year old vision instead of that of a 20-yo. Example: imagine having no formal address or no citizenship (stateless).
I fully agree with this.
another 40+ here
w0rd!
Isn’t this true of basically any job?
Sure, but that doesn't make it any less useful as a fact - especially when you are working with other developers who choose to try to ignore/avoid it as a maxim.
Please don't tell me you've never met such a developer ..
Please don't tell me you've never met such a developer ..
I reached quite the opposite conclusion: the purpose of software is to make a computer do work. Then again, I purposely refrain from writing end-user software and focus on backend automation. It is a deliberate choice.
For whom does the computer do work?
Other computers
I see you work in finance. Where the humans are just office decoration.
It may be computers all the way down, but at the bottom there is a human. Somewhere. Poor thing.
Unless it’s consumed by an AI. Which I don’t fully understand but am comfortable assuming that the AI might be able to ‘teach’ itself to consume an API.
> “if they ask about time off in the first interview then they are never going to be there!”
The fact that this attitude is common scares me when I'm doing interviews.
Time off is incredibly important to me. What's the use of making a great income if you can't get the time off to enjoy it?
The culture about the use of PTO varies wildly between companies. A friend of mine worked somewhere that supposedly gave 20 days PTO per year, but trying to actually use more than a single day at a time was always met with denials, and even if you did take a Friday off, you were expected to work 10 hours/day the other 4 days of that week to make up for it.
So yeah, when I'm interviewing, I want to know how much time people are taking off, but I don't want the interviewer to think I'm lazy and will be trying to avoid work as much as possible.
The fact that this attitude is common scares me when I'm doing interviews.
Time off is incredibly important to me. What's the use of making a great income if you can't get the time off to enjoy it?
The culture about the use of PTO varies wildly between companies. A friend of mine worked somewhere that supposedly gave 20 days PTO per year, but trying to actually use more than a single day at a time was always met with denials, and even if you did take a Friday off, you were expected to work 10 hours/day the other 4 days of that week to make up for it.
So yeah, when I'm interviewing, I want to know how much time people are taking off, but I don't want the interviewer to think I'm lazy and will be trying to avoid work as much as possible.
Your quote of the article made me think I was going to hate the advice, but then I realized you quoted it out of context, here's the full quote:
> People might claim they have “signals” for these things… “if they ask about time off in the first interview then they are never going to be there!” But these are all bullshit. If you’re using signals like these you’re just guessing and turning away good candidates
> People might claim they have “signals” for these things… “if they ask about time off in the first interview then they are never going to be there!” But these are all bullshit. If you’re using signals like these you’re just guessing and turning away good candidates
Ooof...re-reading my comment, I can certainly see your interpretation.
It definitely was not my intent to paint the author of the article as the person who made that quote.
Unfortunately, I can't edit my comment now.
It definitely was not my intent to paint the author of the article as the person who made that quote.
Unfortunately, I can't edit my comment now.
I was also put off from the article by the quote, but that's on me, not you. The article was great and I agree with everything in it.
Maybe we should all ask this question in our interviews so we can avoid these shitty teams that way!
I like to ask if their health insurance covers drug rehab. That goes over well.
Unfortunately, there are too many different ways to be shitty, so while it would filter out a few, a lot of shitty teams wouldn't be detected by that particular question.
That’s a pretty huge distinction. Can’t believe he misrepresented the author like that.
If you re-read the comment with the assumption that they were not trying to (mis)represent the author, it still makes sense, so I don't think that was the intention.
There is even a name for that: https://en.m.wikipedia.org/wiki/Principle_of_charity
That was not my intention. I was operating under the assumption that anybody in the comment section had read the article first, since then it would have been known that I wasn't quoting the author, I was quoting something the author quoted.
It's the correct assumption to be made for the comments section to the article you quoted from.
Reading the comments to decide if you want to read the article is also a valid workflow. Although anyone doing that (me included) isn't entitled to complain about quotes not having enough context.
I always look at the HN comments first to see if the article is worth reading, and probably other people do as well. HN loads quickly, doesn't have a paywall/cookie pop-up so it's just a better experience to look here first, and often the comments here are better value anyway.
It's easy to write something with an assumed context that is easily misinterpreted by readers without that context. I think it's unreasonable to interpret that as 'misrepresenting' something unless you can show that the writer knew their audience wouldn't have that context.
He didn't misrepresent or disagree with the author. He added extra commentary on something the author brought up.
The lack of context reltated to what the author wrote is a sin of omission -- because anyone reading a top-level comment that begins with a quote (like this) is, to a first approximation, going to imagine the commenter is responding to the position of the author.
I think that’s a good reason to read the linked article before drawing conclusions about its contents from discussion threads. Having read the article first, I understood immediately that the comment was not misrepresenting anything from the article, and that their commentary bolsters the point made there.
And you don’t necessarily have to read the article before comments. I often don’t! But when I encounter something in comments which seems incongruous with what I’d expect or hope to find in the article, that’s a good prompt to go ahead and read it to gain context.
And you don’t necessarily have to read the article before comments. I often don’t! But when I encounter something in comments which seems incongruous with what I’d expect or hope to find in the article, that’s a good prompt to go ahead and read it to gain context.
A sin or lie by omission requires intent, and the OP stated their intent was not to misrepresent the author.
That is not how quotation marks are designed to work.
The words offered up as a quote are meant to represent the views of the person being quoted. In this instance that is clearly not the case.
This is a perfect example of how quotes can be used to misrepresented a view.
The words offered up as a quote are meant to represent the views of the person being quoted. In this instance that is clearly not the case.
This is a perfect example of how quotes can be used to misrepresented a view.
To be fair, they used `>` to quote the article, and then included the article's `"` to indicate that the article itself quoted someone else.
Vote with the down arrow. Why is it the first comment in this thread eden is complete nonsense?
I had the same thought process.
As I once told a boss who tried to cancel my already approved vacation in a former job/company, you can't stop me from going. You can only stop me from coming back. Let me know which you prefer. (I really needed that vacation and I was done with bullshit.)
I had a manager who tried to cancel my vacation the day I was at the airport for the flight. I had given advance notice, and they agreed to it, especially when my vacation days have been maxed out for months. Obviously I went for it anyway, and left the team as soon as I come back.
I recently had a job offer taken away for other atupid reasons that we discussed, but conveniently after I brought up how I should handle billing for time away. Maybe I dodged a bullet.
Usually I am more inclined to hire someone who discusses time off during an interview. It shows that they think about their life-work balance.
I do not need heroes, I need reliable folks who do not burn themselves out.
Or to put it in a cliche... I need people who work to live rather then live to work.
I do not need heroes, I need reliable folks who do not burn themselves out.
Or to put it in a cliche... I need people who work to live rather then live to work.
and also importantly people who have family to take care of. If someone comes to me and asks for time off because they have children or partners or parents to take care off and they take that seriously that certainly deserves some respect
would make a better impression on me than someone showing up with a Patrick Bateman business card in hand
would make a better impression on me than someone showing up with a Patrick Bateman business card in hand
Nobody should have to even give a reason for a time off request if it's part of your work agreement.
Sure thing. But I always give reasons. That stuff builds trust.
Even silly things like "hey I'm tired and feeling down, gonna take a couple of days off" builds a lot of rapport.
And unless you're dealing with a huge asshole of a boss, it's never a problem. And if it is, you'd get warned so you can leave faster.
Even silly things like "hey I'm tired and feeling down, gonna take a couple of days off" builds a lot of rapport.
And unless you're dealing with a huge asshole of a boss, it's never a problem. And if it is, you'd get warned so you can leave faster.
If I ask for time off to sit on my arse all day and play games what would you say?
plenty of people have families and abuse the crap out of them, and people without families that want one still need to socialize enough to meet people to eventually have a family
book != cover
book != cover
We interviewed someone a while back and she said (without being asked - asking questions on this line is illegal) she was prepared to leave her husband and kids to move here. It didn't affect our results, but we all agreed in the discussion after that was a negative sign if we were allowed to consider it. She probably would have been good, I hope her search went well.
This is especially true if the company uses "unlimited"/not-tracked/etc. time. Otherwise, unless you know someone at the place (and even then it can vary by group), you're left with making assumptions about norms that may not be accurate.
Personally, I've never not used all my PTO in a given year and would consider being unable to do so a show stopper.
Personally, I've never not used all my PTO in a given year and would consider being unable to do so a show stopper.
I've heard the "unlimited PTO" policy referred to jokingly as the "no PTO policy" at some shops.
Most companies are great about it though and encourage PTO.
Most companies are great about it though and encourage PTO.
I once asked hr from a position advertising "unlimited PTO" what was the average of PTO days in the team. She panicked a little bit
Great question.
Unlimited just means they don’t have to pay out when you quit or get laid off, doesn’t it?
Yes, but it also doesn't give any indication of norms around the amount of time off people take.
Expectations may differ from how much time is in a traditional PTO bank but at least in general, it's OK to take accrued time off barring special circumstances.
Expectations may differ from how much time is in a traditional PTO bank but at least in general, it's OK to take accrued time off barring special circumstances.
I worked at a place that gave us 2 weeks and then took an act of Congress and months of social engineering to take even a day.
We got bought out and the new overlords announced they were going to give us five weeks of vacation. There was actual laughter in the room. We can't even use 2 weeks, what's 5 gonna do for us?
We got bought out and the new overlords announced they were going to give us five weeks of vacation. There was actual laughter in the room. We can't even use 2 weeks, what's 5 gonna do for us?
In Norway you're required by law to take four weeks and a day vacation every year. Almost everyone has five weeks vacation time in total. Both you and your employer can demand that three of those are continuous during summer, and most of the country shuts down three weeks in July.
Wonder what did you guys produce that required all hands on deck at all time non-stop?
We really need a new standard. Unlimited PTO Min 20 days/year. If you don’t put a number then it’s assumed to be 0
In Norway you're required by law to take four weeks and a day vacation every year. Almost everyone has five weeks vacation time in total. Both you and your employer can demand that three of those are continuous during summer, and most of the country shuts down three weeks in July.
In Australia it is 4 weeks minimum (and 10 days for sick/carers leave). The leave accumulates if you don't take and have to be paid out as per your finally pay if you leave the company. Since it is a liability on balance sheet most companies will demand you to take leave if you have accumulated over 20 days. You can also ask to cash out any leave more than 20 days.
I live in a state where that's not required, so it doesn't happen anyways. ¯\_(ツ)_/¯
When I put in my two-weeks at my last job, my boss said that if I can get all my work transferred in only a couple days (I did, since I basically had almost no work, hence my search for a new job), then I could just fill the rest of my two-week notice time with my remaining PTO. No reason to spend two weeks pretending to work at my computer.
When I put in my two-weeks at my last job, my boss said that if I can get all my work transferred in only a couple days (I did, since I basically had almost no work, hence my search for a new job), then I could just fill the rest of my two-week notice time with my remaining PTO. No reason to spend two weeks pretending to work at my computer.
Yeap, PTO is a liability on the books and unlimited PTO is a way to get rid of it.
Bingo.
I really like the policy of "minimum mandatory time off" some companies have. That makes a big statement about where their priorities are in terms of care for their employees' well-being.
The company I'm at effectively has that as part of their unlimited PTO policy, though the timing is company-mandated, being the first week of August and the week between Christmas and New Years, which is a week so many people are likely to take off anyways, it just makes things easier to make everyone take it off.
Going into the week off in August, I wasn't sure how seriously they took it, but sure enough, I didn't get a single e-mail that week other than weekly reports from automated tools. I even checked Slack that Friday, and there wasn't a single message except for the channel where people post pictures of fun stuff they do over the weekend.
It was pretty nice.
Going into the week off in August, I wasn't sure how seriously they took it, but sure enough, I didn't get a single e-mail that week other than weekly reports from automated tools. I even checked Slack that Friday, and there wasn't a single message except for the channel where people post pictures of fun stuff they do over the weekend.
It was pretty nice.
I pretty much hate policies that require you to take PTO at specific times. They're almost never the times I would choose to take on my own and are often at times it's difficult to combine into a longer trip.
Having everybody take the time off can be good, but it doesn't achieve the goal of making sure all processes can go as usual while any individual isn't there, as mentioned in your peer comment about banks.
Banks tend to have this policy because there are a lot of ways to steel in ways that you can cover your tracks. But most of those ways require regular effort to cover your tracks, so if you are locked out of the office for at least two weeks someone is likely to notice. Note that this is two continuous business weeks. Nothing happens over Christmas so that doesn't count.
I had a manager who couldn't let anything happen without her input. She went on vacation and participated in everything via Slack for two weeks. Making her disconnect might have helped more people realize how much she was ... "translating" requirements and work status between her reports and other teams.
In many jurisdictions, there's a statutory minimum amount of annual leave; you can take less but then the difference must be paid in lieu. (Versus if you give 30d, 18d is minimum, and employee takes 20d, then you don't have to do anything. Obviously could have a company policy of paying it if you want.)
So, a more cynical take on mandatory time off, and something that absolutely does happen, is that they'd just rather not have the work than have to pay extra for it.
Also common is not rolling over into the next year, so use it or lose it.
So, a more cynical take on mandatory time off, and something that absolutely does happen, is that they'd just rather not have the work than have to pay extra for it.
Also common is not rolling over into the next year, so use it or lose it.
In Norway you're required by law to take four weeks and a day vacation every year. Almost everyone has five weeks vacation time in total. Both you and your employer can demand that three of those are continuous during summer, and most of the country shuts down three weeks in July.
The author's company avoids that "unlimited PTO" pitfall in their job listings by describing the benefit as:
> generous time off
> generous time off
That doesn't necessarily mean it's "unlimited". It could be that you get eight weeks and they just don't say so.
I think most people understand that "unlimited" does not mean you can take half the year off. It means there is no hard limit and it is up to a discussion between you and your manager. 8 weeks is pretty generous.
I imagine it's really hard for employers to balance that, though.
A good employer wants employees to take the time off they need without worrying about running out of PTO to do the stuff they want. They don't want an employee to ever have to think "Shit, if I take that day off for a dentist appointment, then I won't have enough PTO for that weeklong trip to Hawaii!"
But if you try to avoid this scenario by being extremely generous and declare an explicit 8-week PTO policy, then you will have people using 6-8 weeks PTO. Even as someone that strongly values work-life balance and PTO, 8 weeks is pretty nuts. If everyone took 8 weeks PTO every year, that would be pretty costly and could significantly impact productivity. 8 weeks is 1/6th of the year! It would cause chaos with people frequently coming in and out of the office.
So I think an unlimited policy sounds good, but expectations have to be set. Personally, I'd like to see it paired with a 10-day MINIMUM policy, with at least one full week off.
A good employer wants employees to take the time off they need without worrying about running out of PTO to do the stuff they want. They don't want an employee to ever have to think "Shit, if I take that day off for a dentist appointment, then I won't have enough PTO for that weeklong trip to Hawaii!"
But if you try to avoid this scenario by being extremely generous and declare an explicit 8-week PTO policy, then you will have people using 6-8 weeks PTO. Even as someone that strongly values work-life balance and PTO, 8 weeks is pretty nuts. If everyone took 8 weeks PTO every year, that would be pretty costly and could significantly impact productivity. 8 weeks is 1/6th of the year! It would cause chaos with people frequently coming in and out of the office.
So I think an unlimited policy sounds good, but expectations have to be set. Personally, I'd like to see it paired with a 10-day MINIMUM policy, with at least one full week off.
I guess to someone in the US, 8 weeks sounds like a lot. But, especially if you consider holidays and sick time, 6-8 weeks total over the course of a year doesn't seem unreasonable. I've been in that range for total nonweekend days off for much of my recent career.
It depends a lot on the company in the US.
If we're including holidays, I've seen plenty of companies that do 4 weeks PTO + 8-9 holidays which is just shy of 6 weeks, and there some that do 5-6 weeks PTO after you've been there for a number of years.
But there are also ones where you basically get no PTO. Presumably (hopefully?) you get paid more money to work at these places, but I've never found them worth investigating.
If we're including holidays, I've seen plenty of companies that do 4 weeks PTO + 8-9 holidays which is just shy of 6 weeks, and there some that do 5-6 weeks PTO after you've been there for a number of years.
But there are also ones where you basically get no PTO. Presumably (hopefully?) you get paid more money to work at these places, but I've never found them worth investigating.
I don't include holidays in that total.
Yes, at my work the manager made it clear he expects people to take time off -- often getting then to take the minimum is a struggle.
If the company thinks they have a good story around PTO they will sell it in the first interview. As an interviewee it's very important to me and I will definitely ask questions, but later in the process when I have more leverage. I don't think someone asking in the first interview is lazy, just perhaps naive. They'd be better to ask about work/life balance and expectations in general and then probe what the interviewer answers back.
At my company you get one interview, if you get a second interview it is because we liked you but someone else was better and passed your resume on to a different team. One thing we do is take every candidate to lunch (COVID has changed this of course) with someone who doesn't have input into if you are hired: so feel free to ask those questions that you are not sure about.
Having done a few interviews, nobody knows what questions to ask.
Having done a few interviews, nobody knows what questions to ask.
> lunch ... with someone who doesn't have input
I think part of this could be that they don't know whether to believe that you truly have no input.
When I was an interviewee, my lunch escort told me they didn't, and I was pretty sure it wasn't a devious trick to get me to let my guard down, but I had no way of knowing for sure. I also thought, if there isn't a formal process, maybe if I say something too dumb or wrong, they would still mention it to someone. So I stuck to really superficial topics.
Then I got hired and later served as a lunch escort. Now knowing the process and knowing there truly is no input, I tried to convince the interviewee, and he didn't seem to believe me just like I didn't when I was in his shoes.
I think part of this could be that they don't know whether to believe that you truly have no input.
When I was an interviewee, my lunch escort told me they didn't, and I was pretty sure it wasn't a devious trick to get me to let my guard down, but I had no way of knowing for sure. I also thought, if there isn't a formal process, maybe if I say something too dumb or wrong, they would still mention it to someone. So I stuck to really superficial topics.
Then I got hired and later served as a lunch escort. Now knowing the process and knowing there truly is no input, I tried to convince the interviewee, and he didn't seem to believe me just like I didn't when I was in his shoes.
Maybe better than a single 'lunch escort' would be a group of friends, or a team the candidate isn't being considered for or something.
So that there's some joviality (or not! Something to get an impression of) without putting such one on one pressure on the candidate so that it still feels like an interview. Candidate can just sit and eat even and enjoy others' conversation.
So that there's some joviality (or not! Something to get an impression of) without putting such one on one pressure on the candidate so that it still feels like an interview. Candidate can just sit and eat even and enjoy others' conversation.
Yeah, in principle it's a great idea. Realistically no rational candidate would believe that the lunch escort has no input.
I always leave time off conversations to the offer negotiation stage when I make it past the interview stage. I want my time off in writing and if it's not enough I'll ask for much more money before I accept.
Correct. It is in the interest of the company to sell you on all the perks and they should do that up front.
It is in your interest to view PTO as any other form of compensation and to make those compensation demands after you have demonstrated how valuable you are to the company via the interview process. You don't start negotiating salaries before the first interview, because that's a bad strategy.
It is in your interest to view PTO as any other form of compensation and to make those compensation demands after you have demonstrated how valuable you are to the company via the interview process. You don't start negotiating salaries before the first interview, because that's a bad strategy.
How often do people really negotiate PTO? I have been flatly refused the times I have asked about it. It seems to be much more difficult than negotiating salary or other comp. Companies handle those individually so they are used to negotiating on them. PTO is often handled at a departmental or company level and companies can be hesitant to make exceptions for an individual employee.
I have seen salary bumps offered when additional PTO is requested, which can be calculated into x days of unpaid leave.
Spot on. I always ALWAYS ask about time off during interviews. But I don't ask the manager because I found they always try to stretch the truth or reframe shit.
I just ask the individual contributors how much PTO they've taken in the past 12 months. It's more or less an open question, doesn't necessarily means I'm interested in taking too much PTO. You'd be surprised of how honest people are. I had interviewees even start venting about burnout. Someone from an e-commerce company (not Amazon) told me he's gonna take a month off as he took 0 vacation days for the past 1.5 years (!!!). He admitted he's probably going to get in trouble but he doesn't care anymore.
I just ask the individual contributors how much PTO they've taken in the past 12 months. It's more or less an open question, doesn't necessarily means I'm interested in taking too much PTO. You'd be surprised of how honest people are. I had interviewees even start venting about burnout. Someone from an e-commerce company (not Amazon) told me he's gonna take a month off as he took 0 vacation days for the past 1.5 years (!!!). He admitted he's probably going to get in trouble but he doesn't care anymore.
You should ask about vacation and sick leave both, not generic PTO. The two can be very different, or the same thing.
I get vacation that I'm required to take every year. I have unlimited sick leave - but I actually have to be sick to use it (going to the dentist for a regular checkup counts as sick though)
I get vacation that I'm required to take every year. I have unlimited sick leave - but I actually have to be sick to use it (going to the dentist for a regular checkup counts as sick though)
Someone who replies with that kind of hyperbole is just saying they don’t want anyone who is going to take more than a bare minimum of PTO.
If you’re dealing with a reasonable person, you should be able to preface the question by explaining how having sufficient time off helps you do your best work and avoid burnout, and that you want to clarify expectations up front to make sure that you and the company are an ideal match.
It’s also of course a bit less risky to bring up this sort of thing a bit later in the interview process when you’ve built a bit of a rapport with the interviewer and ideally demonstrated your value somewhat.
If you’re dealing with a reasonable person, you should be able to preface the question by explaining how having sufficient time off helps you do your best work and avoid burnout, and that you want to clarify expectations up front to make sure that you and the company are an ideal match.
It’s also of course a bit less risky to bring up this sort of thing a bit later in the interview process when you’ve built a bit of a rapport with the interviewer and ideally demonstrated your value somewhat.
> If you’re dealing with a reasonable person, you should be able to preface the question by explaining how having sufficient time off helps you do your best work and avoid burnout
If you are dealing with a reasonable person, hopefully you want have to explain any of that.
If you are dealing with a reasonable person, hopefully you want have to explain any of that.
Have you ever had a date where the first thing someone talks about is something like having babies, or going on and on about their ex, or they want to know how much you make in the first 15 minutes? It is not a pleasant feeling, and makes it pretty clear what their priorities are (and aren’t). Namely that having some idea who YOU are and if they like you doesn’t really matter much.
If someone starts the interview process talking about about the vacation amounts (and not much else), that isn’t that different. Chances are at that point they don’t know folks on the team, and vice versa, they don’t know about the company (much), or what the job would likely look like, it may entail, or really much of anything.
It’s just weird, and a bit concerning, in the same way that someone might ask about perks and pay without even trying to understand any of those factors too. Because those factors matter too, a lot.
I’m not saying asking about vacation is a round file thing - rather I have seen, and can definitely imagine, scenarios where it is or would be a pretty major red flag.
If part of the general background comp discussion after someone has spent some effort figuring things out, or as part of the initial listing? Of course, that’s not weird at all. And giving a pay range for a role is of course necessary to avoid people wasting their time.
So ‘it depends’
If someone starts the interview process talking about about the vacation amounts (and not much else), that isn’t that different. Chances are at that point they don’t know folks on the team, and vice versa, they don’t know about the company (much), or what the job would likely look like, it may entail, or really much of anything.
It’s just weird, and a bit concerning, in the same way that someone might ask about perks and pay without even trying to understand any of those factors too. Because those factors matter too, a lot.
I’m not saying asking about vacation is a round file thing - rather I have seen, and can definitely imagine, scenarios where it is or would be a pretty major red flag.
If part of the general background comp discussion after someone has spent some effort figuring things out, or as part of the initial listing? Of course, that’s not weird at all. And giving a pay range for a role is of course necessary to avoid people wasting their time.
So ‘it depends’
Interview is not a date. Its a formal meeting where parties are trying to acheive something concrete. Hire a good employee, find a good job.
If someone starts off with asking about essential thing that is important factor for them it means that its a dealbreaker issue for them.
Whats the point of interview if they know there is no flexi time, and you only look for flexitime jobs??
Its actually a matter-of-fact approach that goes straight into details and saves everyone time. Given it was properly delivered I would be more inclined to hire engineer like that.
If someone starts off with asking about essential thing that is important factor for them it means that its a dealbreaker issue for them.
Whats the point of interview if they know there is no flexi time, and you only look for flexitime jobs??
Its actually a matter-of-fact approach that goes straight into details and saves everyone time. Given it was properly delivered I would be more inclined to hire engineer like that.
If properly delivered? Sure. As many folks seem to be indicating in these threads, as the primary or even sole topic of interest to them?
Would you then consider that a plus?
Would you then consider that a plus?
They know what they want, they do go around the bush doing pleasantries and waiting for the script to get to the place where they can ask the question they wanted to ask in the first place.
To me person like that will be first to raise a hand when something is not right in the project. It might also be a good indication of goal oriented thinking, they know whats important and prioritize to achieve goal
To me person like that will be first to raise a hand when something is not right in the project. It might also be a good indication of goal oriented thinking, they know whats important and prioritize to achieve goal
As long as they’re not just talking about nothing but what they want, then they aren’t the problematic cases I was referring to.
The few times I’ve had someone do that, the last thing those folks did was (as one put it) “look for problems” by raising project issues or really doing anything but the bare minimum. A bare minimum that had to be clearly articulated several times to the several people I’ve run across - who one then specifically asked EXACTLY what I meant by ‘keep the system running’, so they could exclude a bunch of long term maintenance work from that minimum shrug
IMO, if someone is curious and cares about what they are working on, it shows, and we would never even have this discussion about them - even if they did ask about EXACTLY what the vacation policy was.
The few times I’ve had someone do that, the last thing those folks did was (as one put it) “look for problems” by raising project issues or really doing anything but the bare minimum. A bare minimum that had to be clearly articulated several times to the several people I’ve run across - who one then specifically asked EXACTLY what I meant by ‘keep the system running’, so they could exclude a bunch of long term maintenance work from that minimum shrug
IMO, if someone is curious and cares about what they are working on, it shows, and we would never even have this discussion about them - even if they did ask about EXACTLY what the vacation policy was.
Sure, I've just found that it can be helpful to clarify intent is all, especially when you're dealing with someone you've just met - e.g. maybe the interviewer is mostly reasonable, but is scarred from past negative experiences with colleagues who were legitimately lazy. This phrasing might help such a person understand where you're coming from a bit more easily.
If you need to clarify intent for something as fundamental as work/life balance, wouldn’t that be (at best) a yellow flag?
This needs to not be a taboo. It’s very important how many days I get off, how many hours I’m expected to work and if I’m expected to work nights and weekends. Those are like my top 3 concerns, I don’t really care about your snacks or vision or stack to be honest.
But they do care about those things - a lot. And since being employed requires both parties are happy with the deal, it is something worth considering that obviously not caring about the things they care about could cause them concern.
It goes both ways of course - them not caring about your well-being is obviously just a big a red flag for a candidate.
It goes both ways of course - them not caring about your well-being is obviously just a big a red flag for a candidate.
If you are not dealing with a reasonable person you don't want to work there anyway.
I remember a friend who wanted to work for apple. He wanted to take time off before he started.
They said "hey, we shutdown anyway during the holidays you can take it then, just start now"
and of course, did he get to take that time off? NO.
They said "hey, we shutdown anyway during the holidays you can take it then, just start now"
and of course, did he get to take that time off? NO.
Think about it the other way, if they reject a candidate for asking, it's their way of saying "The PTO situation is terrible here".
Yeah, if I ever discovered that a potential employer took this view of PTO then I wouldn't want to work there anyway. Huge red flag.
I'm hearing answers about why they would be either inclined to or not inclined to hire based on that question. My opinion is that it's just a question. Answer it and move on. Don't read for patterns where they don't exist. This also reflects lot of unconscious biases we might be nurturing by having strong opinions about these.
And then there are cases where you can take PTO, but you end up having to work during that time anyway.
It seems you live in US. In other parts of the world it's perfectly normal to have time off and benefit from it. But as a compensation wages are higher.
However, I prefer having some free time for myself than accumulate a large amount of money.
However, I prefer having some free time for myself than accumulate a large amount of money.
[deleted]
Agree. If I were the interviewer I would probably do the same. Asking about how people spend their life can also reveal a lot about their personality as well.
Asking about how people spend their life is often illegal to ask. If you don't know the local laws only ask job related questions. This is why my company gives me a script of questions I'm allowed to ask - to get the conversation started on legal topics in ways that are unlikely to stray into illegal areas. (more than once I've had illegal information given to me - but I didn't ask so that is okay)
Illegal information isn't anything that will affect how someone does the job in general. You learn about personality, but I hope you can deal with those personalities anyway.
Illegal information isn't anything that will affect how someone does the job in general. You learn about personality, but I hope you can deal with those personalities anyway.
Thank God I was born in a poor socialist country and I don't have to think about obvious stuff like my days off
Edit: sorry if that sounded offending but I can't wrap my head around the fact that people in US have problems of this kind
Edit: sorry if that sounded offending but I can't wrap my head around the fact that people in US have problems of this kind
I think time off is very important, but you don't need to ask it during the interviews. Just wait until they give an offer and then ask for what you want.
so spend how much of my time and theirs going through the entire interview process to find out the answer to a trivial question that could make or break any final decision?
....Or...and hear me out here...fuck that noise.
if people are making snap judgement about candidates from asking a basic company culture/hr question during the interview question, then the candidate winds up having dodged a bullet one way or the other.
....Or...and hear me out here...fuck that noise.
if people are making snap judgement about candidates from asking a basic company culture/hr question during the interview question, then the candidate winds up having dodged a bullet one way or the other.
Nah, just like salary, I'm getting a ball park range on that topic before bothering to come into the office for an interview. Otherwise, you're wasting other people's time and your own.
Maybe it’s just where I’m at in my career and priorities, but I’m way more inclined to put work/life balance first and leave comp discussion for negotiation.
I make plenty. I could make more, sure. Could I be more aggressive at making more? Absolutely. But I care far more about being happy where I work. And anyone trying to hire me knows or should know the market well enough they’re not going to make an absurdly lowball offer.
I make plenty. I could make more, sure. Could I be more aggressive at making more? Absolutely. But I care far more about being happy where I work. And anyone trying to hire me knows or should know the market well enough they’re not going to make an absurdly lowball offer.
agree: if you don't get the job it doesn't matter, and until they offer you the job you don't have any leverage.
This is so strange. I have 40 hrs /week (registered, if I work over time I can take days off to compensate for) and 30 days of vacation per year (on doctor's note sick days are not taken from the vacation-days account).
It's plenty of time for my employer to extract value from me. If the org wants me to work more, they can make me be in meetings less.
It's plenty of time for my employer to extract value from me. If the org wants me to work more, they can make me be in meetings less.
The context is key. First interview.
The issue isn’t taking time off, it’s that the prospective employee’s head is up their proverbial ass. First interview is propspecting. If you were selling a product, if the customer is asking about the return policy before even selecting an option, it’s a similar signal.
When you’re in a subsequent interview talking about the benefit plan, salary, etc, that’s where that sort of question is appropriate - you’re finalizing the deal.
The issue isn’t taking time off, it’s that the prospective employee’s head is up their proverbial ass. First interview is propspecting. If you were selling a product, if the customer is asking about the return policy before even selecting an option, it’s a similar signal.
When you’re in a subsequent interview talking about the benefit plan, salary, etc, that’s where that sort of question is appropriate - you’re finalizing the deal.
I find this line of thinking incredibly bizarre. If PTO is important to the candidate, why should they waste their time spending hours interviewing only to find out that the work-life balance in this position isn't going to work for them? To you that's having their head up their ass? God that's strange to me. I'm sure glad I don't work for people who make sweeping judgements like that.
You’re looking for a job. You have 10 minutes to ask questions that make you stand out, to a individual who probably cannot answer the question.
You do you.
You do you.
Employment is a partnership, not servitude. That means the employer needs to convince the employee to work for them. I'm fine being rejected by a place that will treat me like shit.
Isn’t a partnership supposed to be mutual?
You seem to think that it should be one sided, with them doing all the selling/figuring though, which seems to be pretty problematic in other ways.
For some folks, at some times, that can certainly work. But it sounds like you want them to be in servitude to you, not an actual partnership.
You seem to think that it should be one sided, with them doing all the selling/figuring though, which seems to be pretty problematic in other ways.
For some folks, at some times, that can certainly work. But it sounds like you want them to be in servitude to you, not an actual partnership.
That's so spot on. Your Q&A session is your chance to learn something real and convey what you care about. A good question might me like "what's the hardest thing you had to do this year" or "how did you make decisions in cases of disagreement?" or something like that. It shows you're thinking about the job and whether you're a right fit.
High quality questions say something about you. Low quality questions do too. Would you ever hire someone whose question is like "so, do a lot of hotties work here?" Probably not, because ... what kind of person is this? Similarly, if the person who doesn't have an offer and doesn't know much about the role is hyper-focused on their time-off, something is off too. PTO is important, it's just a thing you need to be thinking about once you have an offer and think the job is otherwise a match, not as like the #1 question.
High quality questions say something about you. Low quality questions do too. Would you ever hire someone whose question is like "so, do a lot of hotties work here?" Probably not, because ... what kind of person is this? Similarly, if the person who doesn't have an offer and doesn't know much about the role is hyper-focused on their time-off, something is off too. PTO is important, it's just a thing you need to be thinking about once you have an offer and think the job is otherwise a match, not as like the #1 question.
Different priorities I guess. Personally I’m exchanging my time for money and would like to know what kind of a deal I’m getting. I’m too old for all the fluff bullshit.
Yes yes yes I’m sure you’re changing the world and creating super exciting CRUD
Yes yes yes I’m sure you’re changing the world and creating super exciting CRUD
> Different priorities I guess. Personally I’m exchanging my time for money and would like to know what kind of a deal I’m getting. I’m too old for all the fluff bullshit.... Yes yes yes I’m sure you’re changing the world and creating super exciting CRUD
You know, I actually found this comment clarifying. I don't look at work as solely exchanging time for money (don't get me wrong, I care about money a lot, I just want to get a lot more than money out of my work) so I was coming at it from a different direction.
I do think there's an employee-employer compatibility in play here. Because I care about engagement/mission, I tend to work at companies with a strong culture and seek the same when I interview others - but yeah it's a good reminder that this is not for what everyone wants/needs.
You know, I actually found this comment clarifying. I don't look at work as solely exchanging time for money (don't get me wrong, I care about money a lot, I just want to get a lot more than money out of my work) so I was coming at it from a different direction.
I do think there's an employee-employer compatibility in play here. Because I care about engagement/mission, I tend to work at companies with a strong culture and seek the same when I interview others - but yeah it's a good reminder that this is not for what everyone wants/needs.
Depends. HR does everything they can to ensure I don't consider the questions I'm asked when deciding if we hire them. They can't stop me, but it is tricky to shoehorn your questions into their form so I don't try.
Working a full time job with family and hobbies is incredibly time consuming. I'm not going to squeeze in 6-10 hours of interviews for a company before I ask an important questions about company culture, PTO, benefits, salary etc. I'll ask the questions I find important in the first interview, if it isn't a good fit I just saved me hours of time interviewing at a company I don't want to work at - and I just saved hours of interviewing an employee they don't want to have.
Umm exactly? I’d rather get my own red flags out of the way rather than waste 8h of everyone’s time to find out the company has a shitty culture. I also checksum the compensation and on-call and other things in the first interview
Like it or not, when interviewing for a job, you're doing a sales presentation. A good sales presentation doesn't open by saying what you want. It opens by finding out what the customer's problems are, then you demonstrate that you can solve them, then when the customer is sold the price negotiation starts.
If you want to vet a company's benefits and culture beforehand, which is a good idea, do the homework first and research it before getting into the sales process.
If you want to vet a company's benefits and culture beforehand, which is a good idea, do the homework first and research it before getting into the sales process.
> Like it or not, when interviewing for a job, you're doing a sales presentation
Maybe in the 90s. Nowadays it's becoming very balanced in the way that companies are the ones who are doing a sales presentation as well.
Maybe in the 90s. Nowadays it's becoming very balanced in the way that companies are the ones who are doing a sales presentation as well.
The company buys, the candidate sells. This is proven by which way the money flows - from the company to the employee.
But both have to agree. You're right that a company will have to be willing to offer enough to get the candidate willing to sell.
I recall interviewing a candidate long ago who was only interested in what the company could do for him. He never displayed any interest in the company or what he could do for the company. I recommended no hire.
After all, what would you think if you went to a car dealership and their salesman would only talk about how much you had to pay and how much the dealership wanted your money, and never talked about what the car would do for you?
But both have to agree. You're right that a company will have to be willing to offer enough to get the candidate willing to sell.
I recall interviewing a candidate long ago who was only interested in what the company could do for him. He never displayed any interest in the company or what he could do for the company. I recommended no hire.
After all, what would you think if you went to a car dealership and their salesman would only talk about how much you had to pay and how much the dealership wanted your money, and never talked about what the car would do for you?
I understand that I have to bullshit people like you in interviews and pretend to care.
Picking a career you're interested in and company you're interested in makes things a lot easier than having to maintain a phony facade.
A word of caution - interviewers tend to interview people an order of magnitude or two more times than candidates do interviews. What this means is they learn to detect the bullshit. A friend of mine is in the recruiting business. He interviews candidates all day, and has for many years. He told me that detecting bullshitters and liars is a crucial job skill, and he's pretty good at it.
A word of caution - interviewers tend to interview people an order of magnitude or two more times than candidates do interviews. What this means is they learn to detect the bullshit. A friend of mine is in the recruiting business. He interviews candidates all day, and has for many years. He told me that detecting bullshitters and liars is a crucial job skill, and he's pretty good at it.
Maybe, but who dreams about envelopes? Yet society would fall apart without someone making them. The same can be said for the vast majority of things most companies make - it needs to be made, but it is in reality boring.
All companies have interesting problems to solve along the way. But most have boring products. I can work for most companies because even though the product is boring I know I will find something interesting. (the exceptions are companies doing something I find immoral)
All companies have interesting problems to solve along the way. But most have boring products. I can work for most companies because even though the product is boring I know I will find something interesting. (the exceptions are companies doing something I find immoral)
> who dreams about envelopes?
There are all kinds of people. That said, if envelopes isn't your bag, nobody is making you interview with them. Find something that does interest you. Me, I'd rather be a lion tamer than a tax accountant (yes, I have the hat), but the guy who does my tax accounting loves it.
> I know I will find something interesting.
And there you go.
There are all kinds of people. That said, if envelopes isn't your bag, nobody is making you interview with them. Find something that does interest you. Me, I'd rather be a lion tamer than a tax accountant (yes, I have the hat), but the guy who does my tax accounting loves it.
> I know I will find something interesting.
And there you go.
[deleted]
I don’t have to maintain a facade. Most companies don’t actually give a hoot if you buy into the CEOs blabberings. They care if I can get my tasks done on time and with decent quality. It’s all a part of the Gervais principle
You're right, but people know that someone interested in the work is likely to do a better job. Also, my point is about selling your ability to solve the company's problems rather than focusing on "what do I get".
Besides, why not pick a career that interests you? It makes for a better life.
Besides, why not pick a career that interests you? It makes for a better life.
And they know they need to not hire people who think this way, as it is inevitably cancer for whatever team or product they are on.
Why not find something you actually care about instead of spending all your time and effort faking it?
Why not find something you actually care about instead of spending all your time and effort faking it?
This made me chuckle because occasionally, for some things I buy, return policy might be my primary concern (more important than even having the item in the first place).
You're reading way too deeply in to signals that could mean anything. At the risk of coming across as antagonistic - I'll probably start asking about PTO in the first interview even though it tends to be irrelevant to me, to avoid working with organizations that foster this mindset.
You're reading way too deeply in to signals that could mean anything. At the risk of coming across as antagonistic - I'll probably start asking about PTO in the first interview even though it tends to be irrelevant to me, to avoid working with organizations that foster this mindset.
PTO is not the return policy, it’s a core feature of the product (in this case the job).
There's a delicate balance. I've worked on teams where it felt like I could never rely on one team member because he was using sick leave, personal days, PTO, and going to appointments at every opportunity. I don't hold it against him personally, but professionally it's hard to estimate workload for a given task if one person on a team of 5 is hardly ever actually doing work.
I've also worked on teams that, same as your friend, heavily implied that taking longer leave breaks were a no-go.
As with all things, it's a balance.
I've also worked on teams that, same as your friend, heavily implied that taking longer leave breaks were a no-go.
As with all things, it's a balance.
The problem is not what's important to you when you do an interview. It's not a friendly club, it's the guys who will pay your rent for a while, just act like you pretend to understand this, and ask by side channel, out of sheer strategy.
You CAN refuse once the contract arrives for signature, the interview is a lot also for the company to have argument to sell you to management as a worthy investment.
I admit I never take a guy talking about time off myself, because while I agree it's an important contractual part and something we must give as generously as we can, the fact he asked the first minute of our relationship means it's going to be painful for him and for us, because we're not a paradise company, things can be tough and high pressure (investment bank), people not nice on purpose and sometimes you have to do the right thing rather than the perfect thing, so compliant positive nearly sacrificial profiles will be happily surprised by what's still good while a dude asking "and holidays, 20 or 25 days" the first day will be very sad and burnt out by all the shit.
You CAN refuse once the contract arrives for signature, the interview is a lot also for the company to have argument to sell you to management as a worthy investment.
I admit I never take a guy talking about time off myself, because while I agree it's an important contractual part and something we must give as generously as we can, the fact he asked the first minute of our relationship means it's going to be painful for him and for us, because we're not a paradise company, things can be tough and high pressure (investment bank), people not nice on purpose and sometimes you have to do the right thing rather than the perfect thing, so compliant positive nearly sacrificial profiles will be happily surprised by what's still good while a dude asking "and holidays, 20 or 25 days" the first day will be very sad and burnt out by all the shit.
Sounds like a toxic workplace environnement. I'm grateful that my bank/employer cares about our work/life balance. A burnout employee is not a productive employee.
I've stopped applying to place where they are not upfront with their PTO / Salary brackets. It sounds like you don't want people to take their PTO.
I've stopped applying to place where they are not upfront with their PTO / Salary brackets. It sounds like you don't want people to take their PTO.
> things can be tough and high pressure (investment bank)
> people not nice on purpose
Sounds like a miserable place to work.
> people not nice on purpose
Sounds like a miserable place to work.
I've considered places like that - but none would offer me 5x market pay. If they would pay me 5x what I'm worth - I can save the extra for 5 years and then retire.
I'm not sure if I'd take such a job if it was offered, but at least it would be an interesting offer.
I'm not sure if I'd take such a job if it was offered, but at least it would be an interesting offer.
This sounds absolutely dreadful. You’re doing everyone you turn away a huge favor, and I feel bad for anyone you don’t. If I got even a hint of this in an interview I’d be out the door without letting you complete a sentence.
The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly.
You know, 10x is an optimistic number here. Some programmers will do in 1 day what you wont achieve in a life time. And not understanding that makes you a bad programmer by my book simply because this is the foundation of the job.
So let me give one advice: you are not producing code, you are engineering code. Some will find solutions that the others will not find. Thats where the 10x programmer thing come from. The guy who wrote bittorrent said something like the following: "I've written bittorrent in a way you would never have thought about".
You think John Carmack was the only one trying to make 3d games when Doom came out? Thousands of programmers where trying to. Does that make him a 10x programmer in your opinion? Or more like a 1000x?
You know, 10x is an optimistic number here. Some programmers will do in 1 day what you wont achieve in a life time. And not understanding that makes you a bad programmer by my book simply because this is the foundation of the job.
So let me give one advice: you are not producing code, you are engineering code. Some will find solutions that the others will not find. Thats where the 10x programmer thing come from. The guy who wrote bittorrent said something like the following: "I've written bittorrent in a way you would never have thought about".
You think John Carmack was the only one trying to make 3d games when Doom came out? Thousands of programmers where trying to. Does that make him a 10x programmer in your opinion? Or more like a 1000x?
Agreed, I don't know why the industry (or people?) in general have a problem with accepting this abilities gap.
It's as if the notion of people being arbitrarily born more or less with a knack for something is evil.
Let me tell you the story of when I realized I was (at best), a "not-mediocre" dev:
This is called "innate ability". Humans aren't created equal, nobody said they had to be, and it's not a crime to acknowledge it. Folks ought to get over it IMO, it's not a big deal.
I will never understand CS and programming-language theory concepts at that caliber or that intuitively, but who cares?
I'm also short as fuck so I doubt I'll be playing in the NBA anytime soon either. Life goes on.
It's as if the notion of people being arbitrarily born more or less with a knack for something is evil.
Let me tell you the story of when I realized I was (at best), a "not-mediocre" dev:
1. I've been programming for fun even as a kid. That's what got me into it: If you count kid-programming as "programming", I've been programming for ~14-15 years.
2. There was a girl who used to work with me at $DAYJOB, who is fairly well-known on The Orange Website, and has written some "thought leader" papers in certain niches. A real einstein.
"A couple of years -- and a few of those were writing another language. This is my first real job writing $LANGUAGE_WELL_KNOWN_FOR."
This is called "innate ability". Humans aren't created equal, nobody said they had to be, and it's not a crime to acknowledge it. Folks ought to get over it IMO, it's not a big deal.
I will never understand CS and programming-language theory concepts at that caliber or that intuitively, but who cares?
I'm also short as fuck so I doubt I'll be playing in the NBA anytime soon either. Life goes on.
There was some tweet recently that went "Saying 10x engineers don't exist is as true as saying 10x basketball players don't exist or that all writers are basically the same." It's self-evidently not true.
No. It's like saying that a good mechanic can fix a car 10 times faster than another. Even if a good mechanic manages to find the problem in less time than a non experienced one, he still has to do the repair.
That is similar to programming: even if you have everything clear in your head, you know how to do every single thing that is written in the requirements of the program, you still have to type it out.
A lot of time I thought, well this is fairly easy, and then spent I month just typing out code.
The only situation where really a more experienced programmer can be more or less 10 times faster than a non experienced one is in debugging/troubleshooting problems, because with more experience he tends to know by experience where it's most likely that the problem is and thus test in that direction.
That is similar to programming: even if you have everything clear in your head, you know how to do every single thing that is written in the requirements of the program, you still have to type it out.
A lot of time I thought, well this is fairly easy, and then spent I month just typing out code.
The only situation where really a more experienced programmer can be more or less 10 times faster than a non experienced one is in debugging/troubleshooting problems, because with more experience he tends to know by experience where it's most likely that the problem is and thus test in that direction.
You are misunderstanding the definition. A 10x developer does not write code ten times faster than average. They have ten times higher impact on the results of an organization than average. And that's not far-fetched at all. This does not magically happen. There are individuals behind it, often a surprisingly small number doing the critical work that visibly brings the world forward.
It's not about writing a regular boring CRUD app that no one cares about as fast as 10 regular developers. It's about choosing the right problems to solve on their own initiative, building the foundation of a technology organization that can sustainably & quickly grow in scope and users, being the first to solve a problem no one else has understood such that the organization crushes their competition and so on.
Leading the development of web software that scales to 100 million users in 2003. Planning novel computer vision algorithms to a vehicle fleet of millions of vehicles, running on custom hardware they've also made contributions towards. Realizing that consumer VR headsets are now _just barely possible_ if you do everything right, and bringing it to market. Etc.
This is the difference between a small organization being capable of solving a difficult business problem and achieving profitability, and not.
It's not about writing a regular boring CRUD app that no one cares about as fast as 10 regular developers. It's about choosing the right problems to solve on their own initiative, building the foundation of a technology organization that can sustainably & quickly grow in scope and users, being the first to solve a problem no one else has understood such that the organization crushes their competition and so on.
Leading the development of web software that scales to 100 million users in 2003. Planning novel computer vision algorithms to a vehicle fleet of millions of vehicles, running on custom hardware they've also made contributions towards. Realizing that consumer VR headsets are now _just barely possible_ if you do everything right, and bringing it to market. Etc.
This is the difference between a small organization being capable of solving a difficult business problem and achieving profitability, and not.
F1 mechanics changes tires in 2 seconds. For my local workshop it takes an hour. That's like 1000x.
Bad analogies aside, as others already pointed out, the biggest gain is usually on more creative and architectural tasks with amplified impact, where the requirements given are not as clear as code. Not how fast you change a bolt or type 100LOC. Instead, for example choosing the right tools instead of reinventing your own, or writing a composable interface that enables integration with other tools instead of of an unmaintainable spaghetti monstrosity.
Bad analogies aside, as others already pointed out, the biggest gain is usually on more creative and architectural tasks with amplified impact, where the requirements given are not as clear as code. Not how fast you change a bolt or type 100LOC. Instead, for example choosing the right tools instead of reinventing your own, or writing a composable interface that enables integration with other tools instead of of an unmaintainable spaghetti monstrosity.
I'm not sure that fixing something that is broken is a good allegory for what programmers do, because a lot of us (most of us?) create new things.
The impact that creating something new can have can range from changing the course of history, to literally nothing (like most everything I've written).
Programmers and mechanics have a vastly different impact potential than one another.
No: One developer probably cannot _type_ x10 as fast as another. But they might be able to write code that can cure cancer -- while you/I can only regurgitate the same CRUD app over and over.
The impact that creating something new can have can range from changing the course of history, to literally nothing (like most everything I've written).
Programmers and mechanics have a vastly different impact potential than one another.
No: One developer probably cannot _type_ x10 as fast as another. But they might be able to write code that can cure cancer -- while you/I can only regurgitate the same CRUD app over and over.
IMO having a fancier keyboard that does more clickety-clack will not make you a better programmer. If anything, your co-workers cannot work as good and will have to put more energy to focus.
Experience and the skill to remember or recall well, help a lot with engineering.
Experience and the skill to remember or recall well, help a lot with engineering.
A fancy keyboard on its own is probably not a good indicator.
But I would switch this around and definitely say with my few years of experience, those that were “the best” were also those that were interested the most in their tools of the trade.
And whether that is a mechanical keyboard or a better screen or better performance or better IDE setups. Doesn’t really matter. Sadly many companies don’t seem to encourage this enough imho
But I would switch this around and definitely say with my few years of experience, those that were “the best” were also those that were interested the most in their tools of the trade.
And whether that is a mechanical keyboard or a better screen or better performance or better IDE setups. Doesn’t really matter. Sadly many companies don’t seem to encourage this enough imho
sorry - you'll have to pry my model m from my cold, dead fingers
> Agreed, I don't know why the industry (or people?) in general have a problem with accepting this abilities gap.
I don’t think it’s that people have a problem admitting that there are significant outliers. It’s that there’s a backlash to the fetishization of “hiring 10x programmers” and most people claiming to be one really aren’t.
I know I’m good at it, but I am not and will probably never get to 10x on just writing code. I’ve worked with people who have a better claim to being a 10x. And having seen that, I have also never encountered any company that claims to hire 10x engineers that actually has a process to consistently hire even 1-2x engineers.
I don’t think it’s that people have a problem admitting that there are significant outliers. It’s that there’s a backlash to the fetishization of “hiring 10x programmers” and most people claiming to be one really aren’t.
I know I’m good at it, but I am not and will probably never get to 10x on just writing code. I’ve worked with people who have a better claim to being a 10x. And having seen that, I have also never encountered any company that claims to hire 10x engineers that actually has a process to consistently hire even 1-2x engineers.
If there are 10x engineers, it's a right place, right time situation. Very good engineers with the right experience, luck, a good idea, and the relentless desire to execute. Miss any of those things, and you can still be a a multiplier, just probably not 10x.
Even so at my companies the difference between between good engineers and bad is massive (a lot of the difference is talent and motivation). Imagine you had a company full of shitty engineers, a motivated good engineer in the right could deliver 10x the value of some shit engineer
Even so at my companies the difference between between good engineers and bad is massive (a lot of the difference is talent and motivation). Imagine you had a company full of shitty engineers, a motivated good engineer in the right could deliver 10x the value of some shit engineer
There's honestly quite a few developers that produce zero or negative value (e.g. by implementing the wrong things, introducing lots of bugs or significant complexity etc). 10x:ing them is not difficult.
[deleted]
Totally agree with you. I’m in the same category and have had to accept my fate to some degree. I keep improving relative to myself, but that’s all I can reasonably do.
What gets me is when I meet many of these “innate talent” coders I get to hear phrases like:
“I just want to work with the best possible team…”
And then from their behaviour, you see how they get irritated with the regular folks and try and convince everyone that if we all just “be more like them” it’ll all work better.
Many of them are blind to how much their talents make what is easy for them, very hard for the rest of us.
I call this the “talented arrogance” syndrome.
What gets me is when I meet many of these “innate talent” coders I get to hear phrases like:
“I just want to work with the best possible team…”
And then from their behaviour, you see how they get irritated with the regular folks and try and convince everyone that if we all just “be more like them” it’ll all work better.
Many of them are blind to how much their talents make what is easy for them, very hard for the rest of us.
I call this the “talented arrogance” syndrome.
> Many of them are blind to how much their talents make what is easy for them, very hard for the rest of us.
See also: Asking very old people how they managed to win so long.
See also: Asking very old people how they managed to win so long.
Regarding this issue of "innate" talent, I want to ask, how do you know?
there are just so many variables that go into human cognition. Belief. Drive. Focus. Grit. Exposure to ideas. Social support. Physical resources. Exercise. Health.
Each of these contribute, in some way, to every moment we spend learning. They are always changing. Each moment we learn affects the outcome of the next. It's Conway's game of life in n-dimensions.
My second question, and this is perhaps more important; what is the effect of a belief in innate talent? What don't you do or try because you believed it wouldn't work? Because you believed you couldn't? What do you beliefs cost you?
I realize my questions are pointed, and for that I apologize. They are, however, genuine.
there are just so many variables that go into human cognition. Belief. Drive. Focus. Grit. Exposure to ideas. Social support. Physical resources. Exercise. Health.
Each of these contribute, in some way, to every moment we spend learning. They are always changing. Each moment we learn affects the outcome of the next. It's Conway's game of life in n-dimensions.
My second question, and this is perhaps more important; what is the effect of a belief in innate talent? What don't you do or try because you believed it wouldn't work? Because you believed you couldn't? What do you beliefs cost you?
I realize my questions are pointed, and for that I apologize. They are, however, genuine.
They've done some pretty extensive studies on ability / achievement. The big driver being parents wanting to ensure their kids turn out great, or to make their kids smart.
Turns out environment can only really have _detrimental_ effects on outcomes for kids. You can't increase what they don't have, but you definitely can fuck them up. I thought it was pretty interesting.
So basically, the advice most parents get now is, don't drop them on their head :) Of course, that also means provide them with the opportunities to learn / use their ability.
Turns out environment can only really have _detrimental_ effects on outcomes for kids. You can't increase what they don't have, but you definitely can fuck them up. I thought it was pretty interesting.
So basically, the advice most parents get now is, don't drop them on their head :) Of course, that also means provide them with the opportunities to learn / use their ability.
Can you link to these? I'm interested in what they found out, if a little skeptical about how thinking can be precisely measured.
I went back and dug to find the exact source I was thinking of (I heard it in a freakonomics podcast long ago, took awhile to find).
https://freakonomics.com/podcast/reasons-to-be-cheerful/ https://www.inquirer.com/philly/health/Nature_vs_Nurture__Do...
The big thing is this is purely about IQ.
Think of it like folks being born at a certain IQ, and you can really only maintain it (exercise, love, healthy eating, sleep, etc.) You can't bolster it beyond what is innate. However, you (and your environment, typically our parents) can definitely cause decreases in your IQ (poor sleep, anxiety, poor nutrition, toxins like lead, etc.)
I found it pretty interesting, but also kind of obvious in hindsight. I would love to be able to increase my IQ, as would many others, but we all gotta just work the best to maximize what we got. Maybe tech / gene manipulation will make it possible in the future though.
https://freakonomics.com/podcast/reasons-to-be-cheerful/ https://www.inquirer.com/philly/health/Nature_vs_Nurture__Do...
The big thing is this is purely about IQ.
Think of it like folks being born at a certain IQ, and you can really only maintain it (exercise, love, healthy eating, sleep, etc.) You can't bolster it beyond what is innate. However, you (and your environment, typically our parents) can definitely cause decreases in your IQ (poor sleep, anxiety, poor nutrition, toxins like lead, etc.)
I found it pretty interesting, but also kind of obvious in hindsight. I would love to be able to increase my IQ, as would many others, but we all gotta just work the best to maximize what we got. Maybe tech / gene manipulation will make it possible in the future though.
So, there are a ton of resources out there on how unreliable IQ is, and whether it's a valid indicator of general cognitive ability. Instead of linking them, I'll just link to the place that has the most good links:
https://en.wikipedia.org/wiki/Intelligence_quotient#Reliabil...
My understanding is that save for general statistical measures of a large aggregate, IQ is a poor measure for an individual (as it has been shown to change quite a bit for individuals over the course of a lifetime).
My understanding is that save for general statistical measures of a large aggregate, IQ is a poor measure for an individual (as it has been shown to change quite a bit for individuals over the course of a lifetime).
It’s probably not important whether the talent is encoded in someone’s DNA or whether it was formed during their childhood and early education they got. But by the time people are teenagers, there can be large differences in learning ability that are impossible to level anymore. You can push through those differences through “belief, drive, focus, grit,” etc, but the baselines are different.
there are differences between any two people anywhere ever, though. Is there some reason that being over 20 means you're done developing?
You can learn a new foreign language when you’re 20. But it’s way easier when you’re 10 or 5. Same goes for learning to play chess, to code, and more broadly, for learning to learn.
I'm 35. I started learning to code 5 years ago. I have a job in the industry, and I advance my understanding of the space daily - I'm sorry, but that just doesn't gel with the actual, firsthand experience I have with this stuff.
You're never past expanding your understanding of the world.
You're never past expanding your understanding of the world.
Isn't this because everything is new to you when you have close to no life experience? Aside from our default programming mode of eat, sleep, walk the bucket we call brain is practically empty of experiences and theories when we are 5.
[deleted]
> Agreed, I don't know why the industry (or people?) in general have a problem with accepting this abilities gap.
Bias and poor processes. When people become reliant upon a technique or process to attain viability that means of execution becomes more important than the thing you are producing. As a result people will defend slow unproductive means of execution to the death. This is also a socially reinforced phenomenon.
It is completely realistic to achieve 10x (or even much greater) productivity and it isn’t challenging, but it requires abandonment of closely held ideas that are socially reinforced.
Bias and poor processes. When people become reliant upon a technique or process to attain viability that means of execution becomes more important than the thing you are producing. As a result people will defend slow unproductive means of execution to the death. This is also a socially reinforced phenomenon.
It is completely realistic to achieve 10x (or even much greater) productivity and it isn’t challenging, but it requires abandonment of closely held ideas that are socially reinforced.
It's harder to achieve 10x in a vacuum, but if you make 10 engineers twice as productive, there ya go
> It is completely realistic to achieve 10x (or even much greater) productivity and it isn’t challenging, but it requires abandonment of closely held ideas that are socially reinforced.
OK, you piqued my curiosity. Can you elaborate?
OK, you piqued my curiosity. Can you elaborate?
This is completely off the top of my head.
Objective quick wins:
1) Less code. The less there is the less there is to debug and maintain. This applies to all code including dependencies, frameworks, abstractions, and decoration in your own code. If abandoning OOP means substantially less code then do it without question.
2) Iterate faster. If you have a build that takes 10 minutes and the next guy has a build that takes less than a minute they can fail 10x more frequently and achieve the same level of productivity.
3) Know your foundations with confidence. Things you rely upon become more of a barrier than a help given a long enough time line (shorter time line that could otherwise imagine).
4) The point of software is automation. If you find you are doing manual curation in the code you are likely wasting your productivity. An investment in better automation returns interest on the initial investment.
More opinionated personal preferences:
1) Unless you are writing in a language where you manage access to memory, such as C++ or Rust, abandon OOP. In garbage collected languages like Java, JavaScript, C# it only provides composition. It is a tremendous increase in code that does more harm in troubleshooting.
2) Prefer a statically typed language. As a JavaScript developer I have fallen in love with TypeScript. There are performance benefits to ensuring all primitives are strongly typed, but the developer performance benefits come from typing complex types. This is a quick win for defining execution of microservices and functional programming.
3) Prefer functional programming techniques and code portability. Code is less defective when it is highly predictable and explicit.
4) Save composition for last. Don't worry about how to put things together. Complete each micro-task in isolation, which forces a separation of concerns. Once everything is written putting things together becomes natural and typically works itself out.
5) Avoid pronouns in the code. The pronoun of JavaScript is the keyword this. Don't use it. You don't need it. I have been writing in this language full time for 13 years both at work and for personal projects. In that time I have really needed this only twice. The problem with pronouns is that they aren't clear (in either value or intention) by just reading the code, which takes substantially more time to interpret as a human.
6) Think in writing. You can save some refactoring effort by having a solid execution plan. The best way to plan is write things down as if to explain it to somebody who has no idea. If you cannot even explain it to yourself you won't be able to do in code.
Objective quick wins:
1) Less code. The less there is the less there is to debug and maintain. This applies to all code including dependencies, frameworks, abstractions, and decoration in your own code. If abandoning OOP means substantially less code then do it without question.
2) Iterate faster. If you have a build that takes 10 minutes and the next guy has a build that takes less than a minute they can fail 10x more frequently and achieve the same level of productivity.
3) Know your foundations with confidence. Things you rely upon become more of a barrier than a help given a long enough time line (shorter time line that could otherwise imagine).
4) The point of software is automation. If you find you are doing manual curation in the code you are likely wasting your productivity. An investment in better automation returns interest on the initial investment.
More opinionated personal preferences:
1) Unless you are writing in a language where you manage access to memory, such as C++ or Rust, abandon OOP. In garbage collected languages like Java, JavaScript, C# it only provides composition. It is a tremendous increase in code that does more harm in troubleshooting.
2) Prefer a statically typed language. As a JavaScript developer I have fallen in love with TypeScript. There are performance benefits to ensuring all primitives are strongly typed, but the developer performance benefits come from typing complex types. This is a quick win for defining execution of microservices and functional programming.
3) Prefer functional programming techniques and code portability. Code is less defective when it is highly predictable and explicit.
4) Save composition for last. Don't worry about how to put things together. Complete each micro-task in isolation, which forces a separation of concerns. Once everything is written putting things together becomes natural and typically works itself out.
5) Avoid pronouns in the code. The pronoun of JavaScript is the keyword this. Don't use it. You don't need it. I have been writing in this language full time for 13 years both at work and for personal projects. In that time I have really needed this only twice. The problem with pronouns is that they aren't clear (in either value or intention) by just reading the code, which takes substantially more time to interpret as a human.
6) Think in writing. You can save some refactoring effort by having a solid execution plan. The best way to plan is write things down as if to explain it to somebody who has no idea. If you cannot even explain it to yourself you won't be able to do in code.
Great stuff!
> 2) Iterate faster. If you have a build that takes 10 minutes and the next guy has a build that takes less than a minute they can fail 10x more frequently and achieve the same level of productivity.
I think this is very under rated. There are so many things that can reduce developer latency (time between making a change to the code and seeing if it works, or deploying to production) is one of the most under rated aspects of software engineering productivity.
Most other factors pale in comparison.
> 2) Iterate faster. If you have a build that takes 10 minutes and the next guy has a build that takes less than a minute they can fail 10x more frequently and achieve the same level of productivity.
I think this is very under rated. There are so many things that can reduce developer latency (time between making a change to the code and seeing if it works, or deploying to production) is one of the most under rated aspects of software engineering productivity.
Most other factors pale in comparison.
Yeah, 10x is really fast. Lots of companies couldn’t bear to go that fast … the rate of change scares them.
[deleted]
The reason people struggle with the idea of 10x programmers is that people are very bad at evaluating the impact of others. Obviously we can all agree on a select few but for those who are just "regular" workers there is often not enough context.
I think it's also because we have a lot of ego. Let's admit it. There are some people who have a rare insight or mobilize people and code in a way that provides 10x value to the company and people.
Think about all the kickass Python libraries people have wrote. Those provide 10x value across the board to entire industries.
Think about all the kickass Python libraries people have wrote. Those provide 10x value across the board to entire industries.
> I don't know why the industry (or people?) in general have a problem with accepting this abilities gap.
Because it's not in their interest to accept it openly.
What would be the point of a employer to tell their employees that they are mediocre at best and no matter how hard they try they will never shine? That is the exact opposite of the carrot dangling ever slightly out of reach.
Why would someone blessed by luck tell their employees he didn't get there by working himself to death?
McDonalds is a money printing machine despite not using world class chefs. Telling everybody they can code depending on effort and hiring them for relatively cheap is a solid business plan.
Because it's not in their interest to accept it openly.
What would be the point of a employer to tell their employees that they are mediocre at best and no matter how hard they try they will never shine? That is the exact opposite of the carrot dangling ever slightly out of reach.
Why would someone blessed by luck tell their employees he didn't get there by working himself to death?
McDonalds is a money printing machine despite not using world class chefs. Telling everybody they can code depending on effort and hiring them for relatively cheap is a solid business plan.
I figure there are a lot of aspects to the job and I'm exceptional at some of the ones most people suck at, and I dont know much about some common things and can find that embarrassing at times. The rest I'm average. So I try to find work where I can bring those less common skills, and I try to fill my gaps too sometimes. Everyone is different, find a place that needs what you have to offer.
I accepted this long ago. I don't have the right brain to be an über-dev, I'm not technically gifted, I just have a high enough IQ to brute-force my way through technical challenges.
I'm great at writing, simplifying technical concepts, and strategizing on larger projects, so I try to work to those strengths, which usually means making my PM's life a hell of a lot easier.
I'm great at writing, simplifying technical concepts, and strategizing on larger projects, so I try to work to those strengths, which usually means making my PM's life a hell of a lot easier.
> It's as if the notion of people being arbitrarily born more or less with a knack for something is evil.
The stretch from person A is a better programmer / SW engineer than B to 'thus, person A is innately better' is unnecessary.
In my experience, the programmer that spends more time programming is almost always better than the one who does not. You can hate side projects, open-source work, whatever as much as you want, but IME, the programmers that engage in that (and thus have multiple times more actual experience than one who works 9-5) are universally the 10x people.
In other words, it's not innate intelligence... it's simple effort and working towards improvement.
Now... there are some people that are truly just stellar, and I can attribute perhaps some of this to innate ability, but the difference between mediocre programmer and 10x is typically one of hard work. Between 10x and the extremely rare 100x... well maybe we can talk brain differences. Those programmers are so rare though, it's futile to expect you'd be able to hire them, since there's not enough supply. 10x is good enough.
The stretch from person A is a better programmer / SW engineer than B to 'thus, person A is innately better' is unnecessary.
In my experience, the programmer that spends more time programming is almost always better than the one who does not. You can hate side projects, open-source work, whatever as much as you want, but IME, the programmers that engage in that (and thus have multiple times more actual experience than one who works 9-5) are universally the 10x people.
In other words, it's not innate intelligence... it's simple effort and working towards improvement.
Now... there are some people that are truly just stellar, and I can attribute perhaps some of this to innate ability, but the difference between mediocre programmer and 10x is typically one of hard work. Between 10x and the extremely rare 100x... well maybe we can talk brain differences. Those programmers are so rare though, it's futile to expect you'd be able to hire them, since there's not enough supply. 10x is good enough.
> You can hate side projects, open-source work, whatever as much as you want, but IME, the programmers that engage in that (and thus have multiple times more actual experience than one who works 9-5) are universally the 10x people.
The usual correlation-vs-causation disclaimer goes here. How many open source developers spend time on it because they produce good code?
I spent quite a bit of time on side projects and helping (as I thought) others with projects that I like. After many years of doing this I have come to the conclusion that I simply cannot produce really good code. So rather than being a drain on already overworked maintainers I decided not to bother them anymore. Seeing a few others starting 5-10 years later and quickly outrunning me is quite discouraging, but such is life.
The usual correlation-vs-causation disclaimer goes here. How many open source developers spend time on it because they produce good code?
I spent quite a bit of time on side projects and helping (as I thought) others with projects that I like. After many years of doing this I have come to the conclusion that I simply cannot produce really good code. So rather than being a drain on already overworked maintainers I decided not to bother them anymore. Seeing a few others starting 5-10 years later and quickly outrunning me is quite discouraging, but such is life.
> "I spent quite a bit of time on side projects and helping (as I thought) others with projects that I like. After many years of doing this I have come to the conclusion that I simply cannot produce really good code."
Who cares if it's "GOOD" code -- did you have fun/did you enjoy it? It surely couldn't have been SHIT code, because you cared even the slightest degree.
Statistically, I figure most people writing code don't give a rat's ass and are there to pay rent.
"GOOD" is just skewed by the fact that you can also write code so brilliant it changes the course of humanity -- that's quite an upper bound to place on "great" or "10/10" code.
-------
On the topic of "x10 Developer/Engineer" and terminology:
You know "that 1 genius kid in the grade/school" who is just on a completely different level -- that's been my experience with these "x10" programmers.
There's a 17 year old in the Scala Discord (christ, she's legally a CHILD!) that I thought was a 30-something with some higher degree and was teaching me a bunch of stuff. I about spit out my drink when it casually came up in conversation from some older regular that she was 17.
Half of what she says I can't understand.
That's the sort of thing that comes to mind, for me anyways. Even though I live and breathe code, I think I'd have to be delusional to think I'd ever be as competent as her.
I could maybe memorize the amount of KNOWLEDGE she has currently, but there's a depth of understanding that I can't begin to comprehend.
I’m not sure if you described 10x people or one-track minds.
I love programming, I’m good at it, but what I do with my free time isn’t necessarily related to programming but is still definitely productive. I read up on economics, politics, maybe write a few essays or short stories, work out, pick up a new skill or something. Somehow being a holistic person is now considered mediocre?
I love programming, I’m good at it, but what I do with my free time isn’t necessarily related to programming but is still definitely productive. I read up on economics, politics, maybe write a few essays or short stories, work out, pick up a new skill or something. Somehow being a holistic person is now considered mediocre?
Those with one track minds tend to excel specifically at the one track they dedicate themselves to while failing at other things. There are also those who are good at many things. Both have valuable skills (and both are actually well compensated and highly necessary for companies, IME). But if you want to be that guy who can just crank out code for any problem, then I believe this ability is based on the amount of time you've spent coding, which, for those who have one-track minds, is naturally going to be a lot more than the average programmer. It takes all types. There is no value judgement in my descriptions.
I think it is more a case of “talent x perspiration = skill”. Everybody can get better by working at it, but some people advance more quickly.
> You think John Carmack was the only one trying to make 3d games when Doom came out? Thousands of programmers where trying to. Does that make him a 10x programmer in your opinion? Or more like a 1000x?
I think the idea of 10x programmers gets so much pushback because it's often bundled with this kind of toxic hero worship. There's a difference between acknowledging the impressive ability of outliers, and idolizing heroic one-man efforts as the pinnacle of what we should all aspire to as software developers.
Incidentally, Carmack was not the only programmer on early id Software games, and Doom was far from the first 3d first-person game made. Arguably, it wasn't even that ambitious compared to, say, Ultima Underworld, but the programmers working on that get much less immediate recognition.
As a matter of fact, these discussions often remind me of that famous IGN quote of Warren Spector. Except we really should know better on HN.
I think the idea of 10x programmers gets so much pushback because it's often bundled with this kind of toxic hero worship. There's a difference between acknowledging the impressive ability of outliers, and idolizing heroic one-man efforts as the pinnacle of what we should all aspire to as software developers.
Incidentally, Carmack was not the only programmer on early id Software games, and Doom was far from the first 3d first-person game made. Arguably, it wasn't even that ambitious compared to, say, Ultima Underworld, but the programmers working on that get much less immediate recognition.
As a matter of fact, these discussions often remind me of that famous IGN quote of Warren Spector. Except we really should know better on HN.
Warren Spector's quote, for reference:
>"There's a tendency among the press to attribute the creation of a game to a single person," says Warren Spector, creator of Thief and Deus Ex.
https://www.ign.com/articles/2001/11/12/deus-ex-2
>"There's a tendency among the press to attribute the creation of a game to a single person," says Warren Spector, creator of Thief and Deus Ex.
https://www.ign.com/articles/2001/11/12/deus-ex-2
Theres also this insane idea that people are just come out of the womb as 10x devs, as though they are literally different breeds and there is no amount of studying or effort that could bridge the gap. Its like a bunch of people who still believe their dad is magical & best and haven't discovered that we're all made of mostly the same stuff.
This is the opposite of how you should want any knowledge worker to think. If you believe that there’s some innate ability that makes people 10x better at a skill than you rather than hours of practice and study then you are much less likely to acquire that skill or learn those skills efficiently. You need to have a growth mindset to be an effective knowledge worker not a fixed mindset.
This is discussed in the book Make It Stick on learning science, in chapter 7 they discuss how your own views on whether skill is innate vs the result of practice affects your own ability to learn and grow.
This is discussed in the book Make It Stick on learning science, in chapter 7 they discuss how your own views on whether skill is innate vs the result of practice affects your own ability to learn and grow.
> This is the opposite of how you should want any knowledge worker to think.
Some of us don't choose our beliefs based on what is most convenient or most beneficial to us. Instead, we try to see the world for what it is, truthfully (or as close to a true representation of the world as it's possible to get, anyway). If having a realistic worldview hinders my ability to learn, then so be it. Not everything is about maximizing productivity.
Some of us don't choose our beliefs based on what is most convenient or most beneficial to us. Instead, we try to see the world for what it is, truthfully (or as close to a true representation of the world as it's possible to get, anyway). If having a realistic worldview hinders my ability to learn, then so be it. Not everything is about maximizing productivity.
> If having a realistic worldview hinders my ability to learn, then so be it.
I think the point is that the worldview you described is not realistic.
Many people are successful because of hard work and dedication. Sometimes having talent in a tangential field (design, reading, being a good listener) is enough to make you an excellent engineer or team member. Success is complicated and often depends more on the world than on your particular attributes. Example: Maxwell was a true genius, but he had Faraday's life's work to read through. Faraday was a hard worker and a meticulous note taker who didn't really know math, but without his work Maxwell would not have been able to write his equations. Can you imagine if Faraday gave up science because he wasn't good at math?
I think the point is that the worldview you described is not realistic.
Many people are successful because of hard work and dedication. Sometimes having talent in a tangential field (design, reading, being a good listener) is enough to make you an excellent engineer or team member. Success is complicated and often depends more on the world than on your particular attributes. Example: Maxwell was a true genius, but he had Faraday's life's work to read through. Faraday was a hard worker and a meticulous note taker who didn't really know math, but without his work Maxwell would not have been able to write his equations. Can you imagine if Faraday gave up science because he wasn't good at math?
One thing I've learned in programming as well as life is that Sources of Truth are deeply tied to individual perspectives.
I feel the core idea is that hard work and deliberate practice will move both those with talent and those without forward and fretting over things you cannot change is an exercise in futility, and you're rather focus on things that you can change.
I fully you agree with you here. But that's not the core idea in the post you're referring to. The core idea in that post was that beliefs should be chosen based on utility, as opposed to truthfulness. I disagree with that idea, because I think truth has inherent value in and of itself. I want to believe things that are true, even if those beliefs are harmful to me.
Furthermore, the poster has very clearly expressed in subsequent posts that they don't believe talent ("innate ability") exists. I strongly disagree with this idea as well, and there is a mountain of evidence to support my position.
Furthermore, the poster has very clearly expressed in subsequent posts that they don't believe talent ("innate ability") exists. I strongly disagree with this idea as well, and there is a mountain of evidence to support my position.
If you read the book the researchers argue that worldview is neither factual nor is it helpful.
> factual
Nope. Just because it says so in a book doesn't make it true. When you make a statement of the form "X does not exist", a single counter-example is sufficient to prove you wrong. Lucky for me, many such counter-examples exist, and many have even been discussed in this thread. I'll add one to the list: tourist (Gennady Korotkevich). He's a competitive coder that's several orders of magnitude (e.g. 1000x) better at coding competitions than the average competitor. And the average competitor is a few orders of magnitude better than the average professional programmer who doesn't have algorithm experience. All of this is measurable (at most we can quibble about whether the skill differences are 100x or 10000x or infinite). If you don't believe me, please go and take a simulated Codeforces competition right now and see how long it will take you to solve some set of problems that tourist solved in under 2 hours (or if you will be able to solve them at all - I certainly won't be able to solve the hardest Codeforces div1 problems no matter how much time I put in).
I have a feeling this mountain of empirical evidence was insufficient to change your mind about this. I would appreciate if you could take the time to explain why? Why is this evidence not enough?
Nope. Just because it says so in a book doesn't make it true. When you make a statement of the form "X does not exist", a single counter-example is sufficient to prove you wrong. Lucky for me, many such counter-examples exist, and many have even been discussed in this thread. I'll add one to the list: tourist (Gennady Korotkevich). He's a competitive coder that's several orders of magnitude (e.g. 1000x) better at coding competitions than the average competitor. And the average competitor is a few orders of magnitude better than the average professional programmer who doesn't have algorithm experience. All of this is measurable (at most we can quibble about whether the skill differences are 100x or 10000x or infinite). If you don't believe me, please go and take a simulated Codeforces competition right now and see how long it will take you to solve some set of problems that tourist solved in under 2 hours (or if you will be able to solve them at all - I certainly won't be able to solve the hardest Codeforces div1 problems no matter how much time I put in).
I have a feeling this mountain of empirical evidence was insufficient to change your mind about this. I would appreciate if you could take the time to explain why? Why is this evidence not enough?
I think you’re missing the point or I was unclear. The point is not that masters at a skill don't exist. The point is that attributing their skill mostly to something innate rather than practice, study, etc is not supported by the body of research they review in the book (the book is written for a general audience, their academic research supports the arguments in the book).
There is a mountain of evidence to the contrary. No matter how much you or I would practice, study, etc. we would never become as good as tourist. Most people reach their plateau in competitive coding within 1 year.
For example, here's my Codeforces profile: https://codeforces.com/profile/baobab
Started in 2015, plateau'd in 2016 and no measurable improvement from subsequent 3 years of practice and study.
For example, here's my Codeforces profile: https://codeforces.com/profile/baobab
Started in 2015, plateau'd in 2016 and no measurable improvement from subsequent 3 years of practice and study.
is it at all possible that practice and study are insufficient to create further growth? What I think faizshah is talking about is that there is enormous complexity that goes into creating skill.
what sort of community do you leverage for their knowledge? how frequently do you expose yourself to new ideas? do you practice abstraction in places other than code? do you practice effectively and take notes that you review? keep a journal? meditate? are you in good cardiovascular shape?
all of these are the tip of the iceberg when it comes to contributing factors. a plateau is a sign of stagnant processes.
I apologize in advance for what I'm sure is a frustrating tone. I'm sympathetic to your situation.
what sort of community do you leverage for their knowledge? how frequently do you expose yourself to new ideas? do you practice abstraction in places other than code? do you practice effectively and take notes that you review? keep a journal? meditate? are you in good cardiovascular shape?
all of these are the tip of the iceberg when it comes to contributing factors. a plateau is a sign of stagnant processes.
I apologize in advance for what I'm sure is a frustrating tone. I'm sympathetic to your situation.
> is it at all possible that practice and study are insufficient to create further growth? What I think faizshah is talking about is that there is enormous complexity that goes into creating skill.
Sure there is enormous complexity and many factors that go into creating skill, but that's a generic claim, whereas faizsah was making some specific claims. In particular, they were claiming that talent does not exist (or "innate ability" is not a significant contributor to creation of skill, if you want to phrase it more softly). There is a mountain of evidence to show that innate ability is one of the largest differentiating factors between "masters" at a skill compared to "normal people" who practice that skill.
> a plateau is a sign of stagnant processes.
Nope, there are limits to achievable skill. If I practice height jumping, I'm going to plateau pretty quickly and make only incremental improvements even with the best of processes. Same goes for mental pursuits like competitive programming as well.
Sure there is enormous complexity and many factors that go into creating skill, but that's a generic claim, whereas faizsah was making some specific claims. In particular, they were claiming that talent does not exist (or "innate ability" is not a significant contributor to creation of skill, if you want to phrase it more softly). There is a mountain of evidence to show that innate ability is one of the largest differentiating factors between "masters" at a skill compared to "normal people" who practice that skill.
> a plateau is a sign of stagnant processes.
Nope, there are limits to achievable skill. If I practice height jumping, I'm going to plateau pretty quickly and make only incremental improvements even with the best of processes. Same goes for mental pursuits like competitive programming as well.
... And the limits are personal, and can vary immensely, unfair as it might be. Some people high jump 2.45 meter, or design a spaceship that flies to the moon, whilst most people couldn't do this in a thousand lifetimes
Usually, though, people don't do something for long enough to get close to their limits, so, generally in life, all this doesn't matter that much, does it.
And to keep trying and doing what one enjoy is good advice :-)
Usually, though, people don't do something for long enough to get close to their limits, so, generally in life, all this doesn't matter that much, does it.
And to keep trying and doing what one enjoy is good advice :-)
Chess is another example -- two people, the same amount of practice, can yield vastly different results
Thanks for the Codeforces link :-) didn't know about
Thanks for the Codeforces link :-) didn't know about
> we would never become as good as tourist.
Huh, "tourist"? Typo for "Turing"?
Huh, "tourist"? Typo for "Turing"?
No, not a typo. "tourist" is Gennady Korotkevich, I explained this upthread.
Ah, gotcha, found it now. Sorry, I'd missed that, and was thoroughly confused by the pseudonym.
[deleted]
[deleted]
As your sports coach always said "You don't need talent to practice!"
I'm not a huge believer of some mystical "innate ability" that people sometimes use to explain talent. Imagine a great concert pianist who plays flawlessly. After the concert, someone says, "Oh, you were born with such a wonderful gift of talent!" If I were that pianist, I'd be kind of offended--it totally ignores the decades of daily practice it took to get that good. Or a chess grandmaster. You're such a natural! Oh yea? STFU, this took years of grinding!
I'm not a huge believer of some mystical "innate ability" that people sometimes use to explain talent. Imagine a great concert pianist who plays flawlessly. After the concert, someone says, "Oh, you were born with such a wonderful gift of talent!" If I were that pianist, I'd be kind of offended--it totally ignores the decades of daily practice it took to get that good. Or a chess grandmaster. You're such a natural! Oh yea? STFU, this took years of grinding!
Talent is used as a label by someone who doesn't understand the practice involved in the given craft.
No one wakes up and paints a masterpiece. It takes years and years of hard work and studying to get to a point before you can even get close to masterpiece level.
No one wakes up and paints a masterpiece. It takes years and years of hard work and studying to get to a point before you can even get close to masterpiece level.
But conversely, most people will never produce a masterpiece regardless of how long they spend at it.
The 2 aren’t mutually exclusive. You need talent and hard work to be “the best” in any given field. It doesn’t matter how hard I practice, I’m not going to be a world class sprinter or a world famous singer, my body isn’t built for it.
For some reason when it comes to physical limitations we accept it. But we reject it when it comes to mental capabilities. There are naturally smarter people, at least in specific areas.
For some reason when it comes to physical limitations we accept it. But we reject it when it comes to mental capabilities. There are naturally smarter people, at least in specific areas.
People understand things they can see, like, someone is short, then, how good s/he can get at basketball is a bit limited (right). Or, someone having a body shape good for running, but won't lift much weights.
But mental capabilities are invisible, and then it's harder for many people to see that there are different and personal limits.
But mental capabilities are invisible, and then it's harder for many people to see that there are different and personal limits.
The capacity to practice is itself partially innate. Take a person with ADHD - they will naturally have a harder time practicing piano. I myself was unable to practice piano as a child, but for different reasons.
> Take a person with ADHD - they will naturally have a harder time practicing piano.
Or easier. Depending on how the hyperfocus-or-none dice roll for piano...
Or easier. Depending on how the hyperfocus-or-none dice roll for piano...
Couldn't agree more, thanks for this perspective!
You can be both. I can get better at programming and enjoy beating my personal best but acknowledge some people may be genetically disposed to be better at it even when not trying.
Same reason there is a gaggle of personal trainers at the park near me every morning but none of those working out are thinking they’ll compete in the Olympics
Same reason there is a gaggle of personal trainers at the park near me every morning but none of those working out are thinking they’ll compete in the Olympics
There is an innate ability that drives it to a large extent: inherited intelligence. Recognizing this might not be helpful to the individual's motivation but that doesn't make it untrue. Not everyone can be a 10x (or 100x) Ramanujan-level genius, you really need to win the genetic lottery, in addition to working very hard, for elite level cognitive performance in STEM domains.
Are (were) you a fighterpilot for real? (I think then one needs to do cognitive intelligence tests?)
When you say "[s]ome programmers will do in 1 day what you wont achieve in a life time" you are no longer talking about the 10X programmer myth. You're talking about invention, rather than day-to-day productivity.
They're the same thing if your day-to-day productivity requires invention, as it does in Carmack's case (and I would argue most programmers)
They are not the same thing, unless they achieve what a 1x programmer won't on a lifetime on a day-to-day basis.
If the 10x, 100x or 1000x programmer does not do the 10x, 100x or 1000x times on average on their day to day then they are not 10x, 100x or 1000x programmers.
(for whatever the heck a 1x programmer is, which people talking about 10x programmers oddly always skip on giving any decent definition)
If the 10x, 100x or 1000x programmer does not do the 10x, 100x or 1000x times on average on their day to day then they are not 10x, 100x or 1000x programmers.
(for whatever the heck a 1x programmer is, which people talking about 10x programmers oddly always skip on giving any decent definition)
Yes, exactly.
The best programmers can produce code every day that a mediocre programmer cannot ever produce under any conditions. That is the entire point of the discussion.
I don't even think it's that controversial of a statement, just shift to another field and I think it's self-evident. Paul Erdos could on any day produce better mathematics than the rest of us could produce in a lifetime. Not better maths than his peers, but his peers were also exceptional. Better than the average person who knows how to do their times tables though? Absolutely.
The best programmers can produce code every day that a mediocre programmer cannot ever produce under any conditions. That is the entire point of the discussion.
I don't even think it's that controversial of a statement, just shift to another field and I think it's self-evident. Paul Erdos could on any day produce better mathematics than the rest of us could produce in a lifetime. Not better maths than his peers, but his peers were also exceptional. Better than the average person who knows how to do their times tables though? Absolutely.
Most people might never realized things like that, because they aren't good enough at math (or software) to see the difference between an ordinary everyday mathematician (if there was something like that -- maybe a high school mats teacher), and Paul Erdos.
Maybe from most people perspective, everyone else is about as bright as everyone else. Because they cannot tell the difference. (And instead people fallback to things like how others dress and how self confident they sound)
Maybe from most people perspective, everyone else is about as bright as everyone else. Because they cannot tell the difference. (And instead people fallback to things like how others dress and how self confident they sound)
I would argue that that's not the case for most programmers, at least not in the sense of developing a new p2p protocol, or a fast inverse square root algorithm. Would John Carmack code, e.g. a checkout system for an iPhone app 1000x faster than most programmers? I doubt that.
The interface he produced for that checkout system, the naming conventions he chose, the nature of state encapsulation, the testability of it? Yes, I believe Carmack would produce _better_ code in all those things than the median programmer every time.
There is much more to 10x than how many lines of code you can produce. A monkey on a keyboard can type faster than Carmack but productivity is not assisted. No one is arguing that a 10x programmer is more efficient by way of swift fingers.
There is much more to 10x than how many lines of code you can produce. A monkey on a keyboard can type faster than Carmack but productivity is not assisted. No one is arguing that a 10x programmer is more efficient by way of swift fingers.
How does the invention happen if not through day to day productivity?
I think the "10x programmer" as a term is confusing.
In one analogy it could be the 10x bricklayer. One who does a well defined job 10 times faster than the others. I think this is the notion people oppose.
Another analogy is the 10x classical composer. A person who produces music that is 10 times better music. But this is much more about creative/artistic capacity than about producing. Nobody oppose this.
I that your examples incarnate the same idea: It is not about producing code faster. It is about having better ideas.
In one analogy it could be the 10x bricklayer. One who does a well defined job 10 times faster than the others. I think this is the notion people oppose.
Another analogy is the 10x classical composer. A person who produces music that is 10 times better music. But this is much more about creative/artistic capacity than about producing. Nobody oppose this.
I that your examples incarnate the same idea: It is not about producing code faster. It is about having better ideas.
> In one analogy it could be the 10x bricklayer. One who does a well defined job 10 times faster than the others.
Software as brick-laying gets a laugh out of me. If someone uses that analogy, that's a red-flag: they don't really understand software (and tech). It's like offshored bodyshops that just keep throwing more warm bodies at a codebase.
Truth is, a 10x isn't someone who lays bricks 10 times faster. A 10x is someone who thinks differently. Instead of building you a something with load-bearing walls, he'll innovate and use an internal steel frame, paving the way for your building to be taller than anything previously considered possible. [0]
[0] https://en.wikipedia.org/wiki/Home_Insurance_Building
Software as brick-laying gets a laugh out of me. If someone uses that analogy, that's a red-flag: they don't really understand software (and tech). It's like offshored bodyshops that just keep throwing more warm bodies at a codebase.
Truth is, a 10x isn't someone who lays bricks 10 times faster. A 10x is someone who thinks differently. Instead of building you a something with load-bearing walls, he'll innovate and use an internal steel frame, paving the way for your building to be taller than anything previously considered possible. [0]
[0] https://en.wikipedia.org/wiki/Home_Insurance_Building
I think this is entirely correct. In this framework we wouldn't call it a 10x programmer, but a 10x thinker.
>> In one analogy it could be the 10x bricklayer. One who does a well defined job 10 times faster than the others.
> Software as brick-laying gets a laugh out of me.
I think that may have been precisely GP's point: The quantitatively-exact-sounding "10x" could possibly be used about an easily-measured well-defined task like brick-laying (which usage could be confirmed by the occurrence of variants like "I'm actually a 12x [or only a 9x] bricklayer"), but not about less well-defined / measurable crafts like programming.
> Software as brick-laying gets a laugh out of me.
I think that may have been precisely GP's point: The quantitatively-exact-sounding "10x" could possibly be used about an easily-measured well-defined task like brick-laying (which usage could be confirmed by the occurrence of variants like "I'm actually a 12x [or only a 9x] bricklayer"), but not about less well-defined / measurable crafts like programming.
> It's like offshored bodyshops that just keep throwing more warm bodies at a codebase.
Yet they are doing software, aren't they ? So bricklaying has to be part of the "writing software" definition.
Yet they are doing software, aren't they ? So bricklaying has to be part of the "writing software" definition.
But very often what makes an idea "better" is that it produces a result faster. I've done exactly this: spent hours trying to solve a problem to no avail. Then walk away, come back to it and see that a completely different approach will solve it in ten minutes.
I doubt the bricklayer will become more efficient by taking a walk ruminating. But sure, some tasks are like that. Those are the tasks where you have 10x producers.
> Some programmers will do in 1 day what you wont achieve in a life time. And not understanding that makes you a bad programmer by my book simply because this is the foundation of the job.
Most projects out there will not benefit from such a person. If you don't understand this, then in my book it makes you a poor employee. I mean, it's great if this 10x guy can solve some challenging problems that most people cannot, but if that 10x guy cannot show how it helps the business, I hope he's not in my team.
Most businesses are complex and messy. Connecting your code to business value is not easy.
Looking at some of the comments here, people are going out of their way to both defend the existence of 10x programmers, while simultaneously working very hard at not putting any kind of metric on their ability (e.g. "no, it doesn't mean they can produce 10x code or replace 10 people or ... it means <something very hard to measure>"). If you're going to insist on some quality that is hard to quantify, then stop using numbers to describe them. They are geniuses, but not 10x.
In my experience:
1. You cannot replace 10 average programmers with a 10x programmer and hope to achieve the same output. Output, by the way, is not defined by code, but by activities that help the business move forward.
2. While there are some good claimed 10x programmers who work well with others, most of the ones I've encountered do not. In my last job, we had a team of several truly brilliant folks. They could dive deep to the assembly level or work at the system level (scripting, etc). Any bottleneck that arose - they would dig deep and figure it out.
It was the least productive team I've been in. They argued amongst themselves on the pettiest of things that had no impact on the business. When asked why I was leaving the team, I literally told them that I want to be in a team that writes SW. That team's productivity was so low I couldn't reasonably claim they wrote SW. It's not that they didn't write code, but that most of it would not see the light of day because of constant bickering.
Most projects out there will not benefit from such a person. If you don't understand this, then in my book it makes you a poor employee. I mean, it's great if this 10x guy can solve some challenging problems that most people cannot, but if that 10x guy cannot show how it helps the business, I hope he's not in my team.
Most businesses are complex and messy. Connecting your code to business value is not easy.
Looking at some of the comments here, people are going out of their way to both defend the existence of 10x programmers, while simultaneously working very hard at not putting any kind of metric on their ability (e.g. "no, it doesn't mean they can produce 10x code or replace 10 people or ... it means <something very hard to measure>"). If you're going to insist on some quality that is hard to quantify, then stop using numbers to describe them. They are geniuses, but not 10x.
In my experience:
1. You cannot replace 10 average programmers with a 10x programmer and hope to achieve the same output. Output, by the way, is not defined by code, but by activities that help the business move forward.
2. While there are some good claimed 10x programmers who work well with others, most of the ones I've encountered do not. In my last job, we had a team of several truly brilliant folks. They could dive deep to the assembly level or work at the system level (scripting, etc). Any bottleneck that arose - they would dig deep and figure it out.
It was the least productive team I've been in. They argued amongst themselves on the pettiest of things that had no impact on the business. When asked why I was leaving the team, I literally told them that I want to be in a team that writes SW. That team's productivity was so low I couldn't reasonably claim they wrote SW. It's not that they didn't write code, but that most of it would not see the light of day because of constant bickering.
A 10x programmer doesn't cost 10 times as much as a regular programmer. 10x programmers are real and drive real business value. The people who insist 10x programmers are a myth simply have not worked with one. Do not conflate brilliant-but-an-asshole or prodigious-output-but-creates-a-mess programmers with 10x programmers.
Yet another comment that uses the phrase 10x but does not provide any way to quantify it.
No one is disputing geniuses exist. Calling them 10x, however, is problematic.
No one is disputing geniuses exist. Calling them 10x, however, is problematic.
> that uses the phrase 10x but does not provide any way to quantify it
Understand your complaint but "10x" is best interpreted as a figure-of-speech and not an exact mathematical equation. It's just a short & snappy sounding label that's easy-to-say and easy-to-type on the keyboard. (My previous comment about that: https://news.ycombinator.com/item?id=13753178)
We use numerical type phrases without quantitative precision all the time:
- He doubled-down on his opinion. (We don't nitpick and ask how can an opinion be quantitatively measured as 2x?)
- The old editors like vi/emacs is a million times better than IDEs. (We don't nitpick about where the 10^6 quantity improvement comes from.)
- Microsoft decimated the competition. (Some might nitpick that exactly 1/10th didn't get eliminated but Websters Dictionary says that so-called "correction" is wrong anyway: https://www.merriam-webster.com/words-at-play/the-original-d...)
And yesterday, the top comment[1] in "Economics Programming Languages" wrote:
- >a new language to be adopted it needs to do something (something reasonably important) 10x better than the competition. Even 2x better is not enough to motivate the disruption of changing languages.
Yes, it's hard to measure "10x" in languages beyond synthetic benchmarks. But I think most of us get the idea that "10x" is a just a synonym for "a massive amount" of a fuzzy quality.
For some reason, "10x" attracts a lot of extra nitpicking that we don't consistently apply to many other examples ("double-down", "million times", etc).
[1] https://news.ycombinator.com/item?id=28784181
Understand your complaint but "10x" is best interpreted as a figure-of-speech and not an exact mathematical equation. It's just a short & snappy sounding label that's easy-to-say and easy-to-type on the keyboard. (My previous comment about that: https://news.ycombinator.com/item?id=13753178)
We use numerical type phrases without quantitative precision all the time:
- He doubled-down on his opinion. (We don't nitpick and ask how can an opinion be quantitatively measured as 2x?)
- The old editors like vi/emacs is a million times better than IDEs. (We don't nitpick about where the 10^6 quantity improvement comes from.)
- Microsoft decimated the competition. (Some might nitpick that exactly 1/10th didn't get eliminated but Websters Dictionary says that so-called "correction" is wrong anyway: https://www.merriam-webster.com/words-at-play/the-original-d...)
And yesterday, the top comment[1] in "Economics Programming Languages" wrote:
- >a new language to be adopted it needs to do something (something reasonably important) 10x better than the competition. Even 2x better is not enough to motivate the disruption of changing languages.
Yes, it's hard to measure "10x" in languages beyond synthetic benchmarks. But I think most of us get the idea that "10x" is a just a synonym for "a massive amount" of a fuzzy quality.
For some reason, "10x" attracts a lot of extra nitpicking that we don't consistently apply to many other examples ("double-down", "million times", etc).
[1] https://news.ycombinator.com/item?id=28784181
Most of your examples are commonly used phrases. "10x programmer" is a unique phrase. We don't hear "10x electrical engineer" or "10x politician".
Phrases like "decimate", double-down, etc are part of the English language, and is well understood to have multiple meanings.
Your other examples (e.g. vi/emacs being a million times better) are examples of random numbers people throw out. Someone will say vi/emacs is a ton better, or an order of magnitude better, or a million times better. Whereas with 10x, it's always 10x. I don't hear people talk about 3x programmers or 20x programmers.
The HN comment actually supports my point. You can see how different people are interpreting 10x in the responses. That's the exact same problem we have in this comment thread.
Phrases like "decimate", double-down, etc are part of the English language, and is well understood to have multiple meanings.
Your other examples (e.g. vi/emacs being a million times better) are examples of random numbers people throw out. Someone will say vi/emacs is a ton better, or an order of magnitude better, or a million times better. Whereas with 10x, it's always 10x. I don't hear people talk about 3x programmers or 20x programmers.
The HN comment actually supports my point. You can see how different people are interpreting 10x in the responses. That's the exact same problem we have in this comment thread.
>Most of your examples are commonly used phrases.
Yes, and "10x" is itself also becoming a commonly used phrase that's getting less tied to the math number 10. This thread's extensive non-quantitative usage from many people is evidence of that. (I'm guessing that in a few decades, the bikeshedding about "10x" will eventually stop and it will be accepted as a non-numerical description like "a million times better")
>We don't hear "10x electrical engineer" or "10x politician".
The "10x" is relatively new compared to "double-down" but it's spreading out to other uses besides "10x programmer":
- "10x manager" : https://www.google.com/search?q=%2210x+manager%22
- "10x author" : https://www.amazon.com/10X-Author-Level-Left-Behind/dp/10841...
- "10x <various_nouns>" : https://www.hugo.team/10x
- "10x" spreading out to company names, etc : https://www.google.com/search?q=10x
- "10x programming language" : yesterday's HN thread comment example
Why do all the above non-mathematical usages keep happening? Probably because "10x" sounds cool. We're witnessing language evolution as it happens.
>Whereas with 10x, it's always 10x. I don't hear people talk about 3x programmers or 20x programmers.
Sometimes people talk about 100x and 1000x and infinityX to try and emphasize extra rare skills etc. Again, interpreting 1000x literally as 10^3 isn't the intended meaning. And to build on your point... the fact that nobody says "9x programmer" or "11x programmer" but almost always "10x" is actually evidence that it's not trying to communicate exact mathematics.
Yes, and "10x" is itself also becoming a commonly used phrase that's getting less tied to the math number 10. This thread's extensive non-quantitative usage from many people is evidence of that. (I'm guessing that in a few decades, the bikeshedding about "10x" will eventually stop and it will be accepted as a non-numerical description like "a million times better")
>We don't hear "10x electrical engineer" or "10x politician".
The "10x" is relatively new compared to "double-down" but it's spreading out to other uses besides "10x programmer":
- "10x manager" : https://www.google.com/search?q=%2210x+manager%22
- "10x author" : https://www.amazon.com/10X-Author-Level-Left-Behind/dp/10841...
- "10x <various_nouns>" : https://www.hugo.team/10x
- "10x" spreading out to company names, etc : https://www.google.com/search?q=10x
- "10x programming language" : yesterday's HN thread comment example
Why do all the above non-mathematical usages keep happening? Probably because "10x" sounds cool. We're witnessing language evolution as it happens.
>Whereas with 10x, it's always 10x. I don't hear people talk about 3x programmers or 20x programmers.
Sometimes people talk about 100x and 1000x and infinityX to try and emphasize extra rare skills etc. Again, interpreting 1000x literally as 10^3 isn't the intended meaning. And to build on your point... the fact that nobody says "9x programmer" or "11x programmer" but almost always "10x" is actually evidence that it's not trying to communicate exact mathematics.
> This thread's extensive non-quantitative usage from many people is evidence of that.
Even putting aside comments like mine complaining about the actual number, this thread's extensive use of 10x to mean as many different things is a good reason to avoid the term altogether. The whole thread is just "10x programmers don't exist because X" and "10x programmers exist because Y", where X and Y are unrelated.
> "10x manager"
All but one of the links in the first page were in the context of SW, or written by people in the SW industry. Many of them explicitly pointed out they derived the phrase from 10x developer.
I cannot count this as an independent use of 10x.
> "10x author"
Written by a tech guy.
> 10x <various_nouns>" : https://www.hugo.team/10x
Written by a guy who started a SW company.
> "10x" spreading out to company names, etc : https://www.google.com/search?q=10x
Sad, but fair enough.
It sounds like 10x is the equivalent of putting 2.0 on everything (and also as meaningless).
Even putting aside comments like mine complaining about the actual number, this thread's extensive use of 10x to mean as many different things is a good reason to avoid the term altogether. The whole thread is just "10x programmers don't exist because X" and "10x programmers exist because Y", where X and Y are unrelated.
> "10x manager"
All but one of the links in the first page were in the context of SW, or written by people in the SW industry. Many of them explicitly pointed out they derived the phrase from 10x developer.
I cannot count this as an independent use of 10x.
> "10x author"
Written by a tech guy.
> 10x <various_nouns>" : https://www.hugo.team/10x
Written by a guy who started a SW company.
> "10x" spreading out to company names, etc : https://www.google.com/search?q=10x
Sad, but fair enough.
It sounds like 10x is the equivalent of putting 2.0 on everything (and also as meaningless).
>10x to mean as many different things is a good reason to avoid the term altogether. The whole thread is just "10x programmers don't exist because X" and "10x programmers exist because Y", where X and Y are unrelated.
Yes, I understand your complaint here too but the various X-Y meanings isn't really the fault of "10x"... it's caused by any label. Previous comment about that: https://news.ycombinator.com/item?id=28797871
E.g. the alternative word "expert" or "effective" such as "effective programmer" would cause the same debates:
- I think an effective programmer is one who understand the whole stack from hardware gates to web stack
- No I think a truly effective programmer is one who empowers his team members.
- No an "effective programmer" is really X. No it's Y.
- <... ad infinitum disagreements ... >
It doesn't matter what the word is... "10x", "talented", "expert", "master", etc. There's no consensus definition and yet we haven't tried to eliminate those words.
Generally, I understand that people typically mean "10x" as a synonym for "massively better". (Because nobody who says "10x" has a stopwatch and rigorous academic studies measuring it.) And yes, the counterargument is "10 doesn't really mean anything" ... that's true but the "'massively better'" also doesn't really mean anything -- and yet we can't strike "massively better" from our language so we're back to the same issue.
There is no short label X that "really means" whatever everybody agrees it to mean. That's human language. We muddle onward regardless.
Yes, I understand your complaint here too but the various X-Y meanings isn't really the fault of "10x"... it's caused by any label. Previous comment about that: https://news.ycombinator.com/item?id=28797871
E.g. the alternative word "expert" or "effective" such as "effective programmer" would cause the same debates:
- I think an effective programmer is one who understand the whole stack from hardware gates to web stack
- No I think a truly effective programmer is one who empowers his team members.
- No an "effective programmer" is really X. No it's Y.
- <... ad infinitum disagreements ... >
It doesn't matter what the word is... "10x", "talented", "expert", "master", etc. There's no consensus definition and yet we haven't tried to eliminate those words.
Generally, I understand that people typically mean "10x" as a synonym for "massively better". (Because nobody who says "10x" has a stopwatch and rigorous academic studies measuring it.) And yes, the counterargument is "10 doesn't really mean anything" ... that's true but the "'massively better'" also doesn't really mean anything -- and yet we can't strike "massively better" from our language so we're back to the same issue.
There is no short label X that "really means" whatever everybody agrees it to mean. That's human language. We muddle onward regardless.
Fyi ... a correction as I've since listened to the book author's background since this thread. (https://www.youtube.com/results?search_query=sean+platt+inte...)
>> "10x author"
>Written by a tech guy.
The author of that book, Sean M. Platt, is not a tech guy nor a programmer. He's a high-school dropout that started writing articles and stories. Now, he's mostly a publisher.
The interesting thing is that somehow, the "10x programmer" meme made its way to a non-programmer and he adopted it as "10x author".
>> "10x author"
>Written by a tech guy.
The author of that book, Sean M. Platt, is not a tech guy nor a programmer. He's a high-school dropout that started writing articles and stories. Now, he's mostly a publisher.
The interesting thing is that somehow, the "10x programmer" meme made its way to a non-programmer and he adopted it as "10x author".
> They argued amongst themselves on the pettiest of things that had no impact on the business.
> It sounds like 10x is the equivalent of putting 2.0 on everything (and also as meaningless)
What do you mean by that ? If I write a cooking book titled, "pizza 2.0" everyone in the world will understand what the 2.0 means.
What do you mean by that ? If I write a cooking book titled, "pizza 2.0" everyone in the world will understand what the 2.0 means.
It's 2 the latest version of the book?
Or a new better pizza
Or a new better pizza
The problem is value and productivity in software (or any creative space) is hard to quantify in general. How much better is the best engineer you’ve worked with compared to the worst? 2x? 1.5x? How do you quantify that? But you know one is significantly better than the other I assume.
If you want to replace 10x with “much much better”, then ok. But the general idea is the same. Some engineers produce an outsized impact compared to their peers.
If you want to replace 10x with “much much better”, then ok. But the general idea is the same. Some engineers produce an outsized impact compared to their peers.
How is it a problem?
Carmack is an interesting choice here, oddly. He and team were among the first ones there, but it isn't like they weren't rapidly met. Nor, strictly, the first. Ultima Underworld, I'm pretty sure, has a bit of that distinction.
Even more impressive, much of the success of later titles came from his picking the likes of Abrash to help make things fast. Notably, the WTF comment in the "fast square root" trick was from Carmack about a contractor's code that was speeding things up.
Getting even more meta on it, they had amazing dev tools at their disposal that many other programmers just couldn't afford. Look at the recreations folks do nowadays using pico8 and friends. Some folks get some really amazing tricks running in that field.
None of which is to say Carmack is a bad dev. Quite the contrary, he is quite good. But don't discount the role of everything else to the early success that Doom and friends had. In particular, the artistic execution and vision of everyone else was probably worth more than you'd consider.
Even more impressive, much of the success of later titles came from his picking the likes of Abrash to help make things fast. Notably, the WTF comment in the "fast square root" trick was from Carmack about a contractor's code that was speeding things up.
Getting even more meta on it, they had amazing dev tools at their disposal that many other programmers just couldn't afford. Look at the recreations folks do nowadays using pico8 and friends. Some folks get some really amazing tricks running in that field.
None of which is to say Carmack is a bad dev. Quite the contrary, he is quite good. But don't discount the role of everything else to the early success that Doom and friends had. In particular, the artistic execution and vision of everyone else was probably worth more than you'd consider.
I don't know about producing in one day what it would take another person 2 weeks to accomplish, but I do know there are some core features of my company's app that were created by a very talented developer that I don't think could be reproduced by some of our junior developers in a year.
I think it's a mistake to conceive of the difference as one between the tortoise and the hare, where the tortoise gets there, eventually. There are bits of this code that the tortoise just wouldn't ever end up producing if you gave them all the time in the world.
I think it's a mistake to conceive of the difference as one between the tortoise and the hare, where the tortoise gets there, eventually. There are bits of this code that the tortoise just wouldn't ever end up producing if you gave them all the time in the world.
The myth part is that you can hire these 10x programmers by asking harder whiteboard coding questions and they will sit and close jira tickets for your company thereafter.
I think that depends on the context in which you’re working. Flashes of genius don’t have much place an an enterprise code base. Everything is rigorously standardized and separated into layers. Each layer has a bunch of bookkeeping about dependencies, interfaces, mocks, expectations, and test cases. This is not really brain work; it’s typing. Now maybe if you’re really brilliant, you’ll do much better than average with the implementation of a really tricky layer. But the layers are rarely tricky, implementing them never takes all that much time, the slow part is always the integration and associated mocking rituals. Typing speed pays better dividends than brainpower in terms of productivity, there.
Maybe that's why so many people think 10x programmers don't exist - they work in environments where a 10x programmer isn't needed and couldn't really demonstrate their skills.
How many people will never achieve their potential because they don't work in a room with a door?
So the 10x programmer realizes you can accomplish the same goals with 1/10 of the book keeping, dependencies, interfaces etc. etc. etc.
In other words, the processes themselves place hard upper limits on the possible productivity.
In other words, the processes themselves place hard upper limits on the possible productivity.
One could make the argument that skipping the bureaucracy catches up with you in the long run.
Or maybe a small team of 10x programmers could really get away with it, indefinitely. But can you reliably staff enough of them, now and forever, to keep that going? For a business it is often better to have a codebase that scales with arbitrarily many average-quality engineers, than to be dependent on hiring miracles. Even small numbers of them.
Or maybe a small team of 10x programmers could really get away with it, indefinitely. But can you reliably staff enough of them, now and forever, to keep that going? For a business it is often better to have a codebase that scales with arbitrarily many average-quality engineers, than to be dependent on hiring miracles. Even small numbers of them.
I find this true to an extent, but this also where a lot of unnecessary complexity, risk aversion and process live.
This is always my go to example of a 10x programmer:
https://norvig.com/spell-correct.html
How many developers do you know that would bang out a spelling corrector on a single plane flight, in half a page of code?
It's a question of knowing the algorithms of tools that make things possible that other developers might not even consider, and how to express those ideas cleanly and concisely, evaluate your solution, and iterate and improve quickly.
And then consider the quality of his documentation and considerations for improvement and future work.
https://norvig.com/spell-correct.html
How many developers do you know that would bang out a spelling corrector on a single plane flight, in half a page of code?
It's a question of knowing the algorithms of tools that make things possible that other developers might not even consider, and how to express those ideas cleanly and concisely, evaluate your solution, and iterate and improve quickly.
And then consider the quality of his documentation and considerations for improvement and future work.
Norvig wasn't given a random problem that he then solved quickly. He picked the problem to work on. I'm sure I can give him problems of similar complexity that I work on for my job and he wouldn't do it that quickly. Quicker than me, for sure - but it wouldn't be hard to find someone who does it quicker than he did.
I'm sure I can find problems that I can solve quickly and amaze people. Being able to pick your own problems makes for a bad metric for identifying 10x programmers.
I'm sure I can find problems that I can solve quickly and amaze people. Being able to pick your own problems makes for a bad metric for identifying 10x programmers.
This is one example.
Norvig has written a ton of kick ass programs in his career that are concise, efficient, and correct, in much less time than most programmers would require.
Furthermore, even picking your own problems can be a way to achieve > 10x productivity, as identifying useful problems to solve is also a crucial skill.
I attended a talk given by Norvig, where he frankly admitted Google picked markets to enter where they could get good quality data to train their machine learning models on (this was many years ago). Maybe lesser developers wouldn't have that insight.
Norvig has written a ton of kick ass programs in his career that are concise, efficient, and correct, in much less time than most programmers would require.
Furthermore, even picking your own problems can be a way to achieve > 10x productivity, as identifying useful problems to solve is also a crucial skill.
I attended a talk given by Norvig, where he frankly admitted Google picked markets to enter where they could get good quality data to train their machine learning models on (this was many years ago). Maybe lesser developers wouldn't have that insight.
People can be 10x in one domain but not in others, experience is part of the equation. That's not too strange is it? Compare a football player in a ice hockey team. Even though they still have a significant head start compared to someone on the street, when it comes to physique, ball sense, etc.
> It's a question of knowing
Exactly. Norvig's skill set happens to be of the upscale variety, but similar "10x" knowledge+practice effects exist in more pedestrian domains as well.
Compared to my current self, my teenage self was a 10x PHP programmer. I'm absolutely sure that it would take years for me to get back to being even remotely good at PHP-interleaved-with-HTML style coding.
Exactly. Norvig's skill set happens to be of the upscale variety, but similar "10x" knowledge+practice effects exist in more pedestrian domains as well.
Compared to my current self, my teenage self was a 10x PHP programmer. I'm absolutely sure that it would take years for me to get back to being even remotely good at PHP-interleaved-with-HTML style coding.
I think the fundamental issue with 10x is that a lot of people simply never met one. These guys tend to fly under the radar quite a bit. If you are in a tier 2 market or company, your chances of attracting one are close to nil. Because they are extremely valuable, they don't interview a lot and tend to hop between companies where they know people (or get fast tracked internally).
I remember someone laughing at the idea of 10x programmers. I asked him where he hired from and what's the compensation like. Turns out two high performers I had recently hired were from the same college he was trying to hire from. Of course, he had no chances of attracting anyone since my offer was ~3x what he was offering!
I remember someone laughing at the idea of 10x programmers. I asked him where he hired from and what's the compensation like. Turns out two high performers I had recently hired were from the same college he was trying to hire from. Of course, he had no chances of attracting anyone since my offer was ~3x what he was offering!
Author nails it though with: "We should be far more concerned with keeping 0.1x programmers off our teams than finding the mythical 10x programmer."
No, you need to watch out for the -1x programmers. At least the 0.1x are moving forward,
I agree, because the effort required to filter out a 0.1x programmer is vastly smaller than trying to find a 10x outlier. Way more bang for the buck.
This is just rescaling. The author is actually acknowledging that there exists 10x differences but divides by 10 for some reason.
The author's point is that more effort should be spent removing negative outliers instead of hunting for elusive positive outliers.
1x is supposed to be a baseline for an average productive programmer.
0.1 is someone who isn't actually a productive engineer but somehow faked the interview process.
It's not difficult to be 10 times more productive than somebody who isn't productive at all. I'm at least 100x better Kotlin developer than my 30 years dead grand-grand father who never saw computer IRL.
It's much more difficult to show that you can be 10 times more productive than the average productive developer.
0.1 is someone who isn't actually a productive engineer but somehow faked the interview process.
It's not difficult to be 10 times more productive than somebody who isn't productive at all. I'm at least 100x better Kotlin developer than my 30 years dead grand-grand father who never saw computer IRL.
It's much more difficult to show that you can be 10 times more productive than the average productive developer.
You don't say that so-and-so is a "10x painter". Art is obviously not about the quantity of paint used per day, but how it gets used and in what context. This is what you seem to be communicating with your quote about bittorrent.
Because we're programmers, we chose an empirical measurement ("10x") as our term for high skill. This terminology is confusing and stupid, but now we're stuck with it
Because we're programmers, we chose an empirical measurement ("10x") as our term for high skill. This terminology is confusing and stupid, but now we're stuck with it
I'm guessing there are clearly 10x painters other painters can identify, but there are even fewer quantifiable metrics to measure a painter's output than there are for programmers.
> You know, 10x is an optimistic number here. Some programmers will do in 1 day what you wont achieve in a life time
Exactly. There are many modes of that, and you named a few examples. Another example, company has 2 systems maintained by 10 people each. Someone comes in and figures out how to generalize one of the systems to both cases, so they free up 10 of those programmers to go do something else.
Or - 10 people are beating their head on a problem for months, someone comes along and says "it might be OK if we don't solve that problem, let's move on"
Or - someone figures out that a system/module doesn't need to be written because an out-of-the-box solution exists.
Like, I am not a 10X programmer in the sense that I can write 10X the code of the next guy. But have I prevented 10-people's-worth of wasted effort in my career? Yeah...
Exactly. There are many modes of that, and you named a few examples. Another example, company has 2 systems maintained by 10 people each. Someone comes in and figures out how to generalize one of the systems to both cases, so they free up 10 of those programmers to go do something else.
Or - 10 people are beating their head on a problem for months, someone comes along and says "it might be OK if we don't solve that problem, let's move on"
Or - someone figures out that a system/module doesn't need to be written because an out-of-the-box solution exists.
Like, I am not a 10X programmer in the sense that I can write 10X the code of the next guy. But have I prevented 10-people's-worth of wasted effort in my career? Yeah...
If nobody had previously succeeded then I would take the point that Carmack was somehow unique, but by the time Doom came out lots of programmers had produced 3d games, and we had ray-tracing and lots of graphics theory and implementation (e.g. elite written in 6502 assembly on an 8 bit cpu).
>You think John Carmack was the only one trying to make 3d games when Doom came out? Thousands of programmers where trying to.
Yes Doom was a great game, and well programmed, but it didn't really move the state of the art forward massively, as I would argue that hundreds of programmers had already written and published 3d games by that point.
>You think John Carmack was the only one trying to make 3d games when Doom came out? Thousands of programmers where trying to.
Yes Doom was a great game, and well programmed, but it didn't really move the state of the art forward massively, as I would argue that hundreds of programmers had already written and published 3d games by that point.
What do people gain by arguing over these? Genuinely confused
Just to be proud and gain that dopamine?
Just to be proud and gain that dopamine?
> What do people gain by arguing over these? Genuinely confused
If you assume some arguments (eventually, in some way) lead to people altering their opinions closer to the truth, then people gain more accurate views of the world. This also reduces the spread of misinformation (when the people who have corrected their views no longer spread it), thus having a compounding effect on more people getting closer to the truth.
Or if you assume people never change their opinions as the result of arguments, then I suppose people gain nothing by arguing.
If you assume some arguments (eventually, in some way) lead to people altering their opinions closer to the truth, then people gain more accurate views of the world. This also reduces the spread of misinformation (when the people who have corrected their views no longer spread it), thus having a compounding effect on more people getting closer to the truth.
Or if you assume people never change their opinions as the result of arguments, then I suppose people gain nothing by arguing.
@VMtest, Personally I think these discussions are interesting as a small part of learning and reading about hiring and recruiting.
@baobabKoodaa
> if you assume people never change their opinions as the result of arguments, then I suppose people gain nothing by arguing
One thing: they can slightly learn how others can react to what they say, and thereafter, in real life, better know what to say, or not.
@baobabKoodaa
> if you assume people never change their opinions as the result of arguments, then I suppose people gain nothing by arguing
One thing: they can slightly learn how others can react to what they say, and thereafter, in real life, better know what to say, or not.
I'm about 1/1,000,000th a Fabrice Bellard, and I'm fine with that.
Bellard is who I reference in these situations also. He's a sort-of empirical refutation of the assertion "10x programmers don't exist". I always liked that he lists qemu and ffmpeg on his website as afterthoughts mixed in with all the other code he's written.
Bellard is obviously 10x (or 100x) engineer when you need to port Linux kernel to JavaScript or compute the longest Pi sequence.
But most jobs aren't like that and require a mixed skillset - problem solving, people skills, stress resistance etc. and it's entirely unclear how Bellard would fare there.
But most jobs aren't like that and require a mixed skillset - problem solving, people skills, stress resistance etc. and it's entirely unclear how Bellard would fare there.
But the question isn't about those skills, the question is about programming. Bellard is blatantly an insanely productive programmer.
Also if you think a man who can build an LTE base station from scratch isn't good at "problem solving" I really don't know what metric we're talking about anymore.
Also if you think a man who can build an LTE base station from scratch isn't good at "problem solving" I really don't know what metric we're talking about anymore.
No, this is about being 10x engineer and part of the job description is much more than programming.
On the edge of possible/impossible, ratios will lose their meanings. In the same way, you can say "Einstein is a 10,000x scientist."
Continuing with this analogy and using Kuhn's concepts, maybe it's better to bracket out breakthroughs (paradigm shifts) when talking about everyday productivity (normal science).
Continuing with this analogy and using Kuhn's concepts, maybe it's better to bracket out breakthroughs (paradigm shifts) when talking about everyday productivity (normal science).
The point is 10x what? Compared to who?
We all know people who code faster than the rest of the team but they always cut corners. Part of the reason that everyone else is slower is because they're trying to work around the under-tested tightly coupled mess left behind by the 10x guy.
Then there's the 10x complexity discussed in the parent comment. Plenty of people will take years to solve a problem, if at all, that someone else would manage in a month. However this may be reversed for a different problem since it depends on experience and predisposition, so it makes no sense to talk about a '10x engineer' in this regard.
I share the conclusion with the OP that it's a vague and ultimately useless distinction.
We all know people who code faster than the rest of the team but they always cut corners. Part of the reason that everyone else is slower is because they're trying to work around the under-tested tightly coupled mess left behind by the 10x guy.
Then there's the 10x complexity discussed in the parent comment. Plenty of people will take years to solve a problem, if at all, that someone else would manage in a month. However this may be reversed for a different problem since it depends on experience and predisposition, so it makes no sense to talk about a '10x engineer' in this regard.
I share the conclusion with the OP that it's a vague and ultimately useless distinction.
Mess creators that slow the company down isn't what's meant with 10x.
What you're describing sounds more like a -0.5 developer
What you're describing sounds more like a -0.5 developer
[deleted]
The confusion is that it's all about what people can and cannot do, not how much code they can write.
If your development needs are mundane crud stuff, you don't need a "10x programmer". If you're doing tricky stuff, on the other hand, you absolutely do.
If your development needs are mundane crud stuff, you don't need a "10x programmer". If you're doing tricky stuff, on the other hand, you absolutely do.
I do CRUD stuff mostly at work but I always research things to improve. A good programmer can make a huge difference in CRUD applications. Things like proper relational database design can save a lot of issues down the road. Using good OOP practices can improve reliability. Keeping things DRY is great too.
I have seen some awful source code that run business applications for years.......but bad engineering practices may cost millions in the long run one way or another.
I have seen some awful source code that run business applications for years.......but bad engineering practices may cost millions in the long run one way or another.
I shouldn't have said CRUD. I agree with you, there's a place for genius stuff everywhere.
What I meant is that there is also a lot of boring stuff that just needs to get done. A 10x programmer won't help you much there.
What I meant is that there is also a lot of boring stuff that just needs to get done. A 10x programmer won't help you much there.
Even if you are doing mundane crud stuff, you are eventually going to run into hard problems that don't have obvious answers. Not everyone has to be able to solve those problems, but it's useful to have someone in the team who can.
I experienced people who are 10x better than me through Google codejam.
I looked at one of the problems of the final round, looked at the solution, read it for hours, and I couldn't implement it correctly.
Then, there are these top 3 who came up with their own solution and wrote correct code within 20 minutes.
For comparison, I can consistently be in the top 1000 of Google codejam. So, I consider myself a fairly good coder.
I experienced this with topcoder as well. There are some people who are way too smart.
10x programmers and engineers are very much real. It is just rare.
I looked at one of the problems of the final round, looked at the solution, read it for hours, and I couldn't implement it correctly.
Then, there are these top 3 who came up with their own solution and wrote correct code within 20 minutes.
For comparison, I can consistently be in the top 1000 of Google codejam. So, I consider myself a fairly good coder.
I experienced this with topcoder as well. There are some people who are way too smart.
10x programmers and engineers are very much real. It is just rare.
[deleted]
[deleted]
[deleted]
what would be nice is turning the skill gap into motivation to make other people grow faster
but the reflex for humans is to fear and be angry (understandably, but a bad reflex)
but the reflex for humans is to fear and be angry (understandably, but a bad reflex)
This is a very insightful list. But there is one thing I'd quibble with: while it's inherently a super-subjective metric, I would say that 10x programmers do exist. Both in the "can support a company by themselves" sense and the "mad lone genius" sense. Not all the 10x programmers are good at working with other people or on other people's ideas.
0.1x programmers are often lost or afraid, although they may just be unimaginative. The real risk of fear is introducing 0.1x processes. People are often willing to sacrifice any amount of development velocity to avoid being seen to make mistakes.
Sometimes this makes sense, sometimes it doesn't. Arguably the reason for the success of SpaceX is that they were willing to fly, crashland, and improve a dozen rockets in the time that a conventional company would spend agonizing over whether to launch at all. On the other hand, nobody wants to be on the same roads as the "move fast and break things" self-driving car.
0.1x programmers are often lost or afraid, although they may just be unimaginative. The real risk of fear is introducing 0.1x processes. People are often willing to sacrifice any amount of development velocity to avoid being seen to make mistakes.
Sometimes this makes sense, sometimes it doesn't. Arguably the reason for the success of SpaceX is that they were willing to fly, crashland, and improve a dozen rockets in the time that a conventional company would spend agonizing over whether to launch at all. On the other hand, nobody wants to be on the same roads as the "move fast and break things" self-driving car.
Saying 10x programmers are a myth because it's crazy that someone could do in 1 day what another could do in 1 week makes the assumption that both programmers in the example have the same amount of context, background understanding, and experience.
The benefit of talented engineers comes from the fact that they avoid costly pitfalls - not that they pump out more code per hour worked.
I feel this "10x programmers are a myth" attitude comes from a good place of wanting to promote harmonious working and skill-up junior engineers, but it seems so totally detached from reality. I'm not sure the "benefit" of propagandizing against talented assholes is worth the cost of demotivating people who might be inspired that they could become a 10x engineer.
The benefit of talented engineers comes from the fact that they avoid costly pitfalls - not that they pump out more code per hour worked.
I feel this "10x programmers are a myth" attitude comes from a good place of wanting to promote harmonious working and skill-up junior engineers, but it seems so totally detached from reality. I'm not sure the "benefit" of propagandizing against talented assholes is worth the cost of demotivating people who might be inspired that they could become a 10x engineer.
Realistically, I’ve always found it a weird sentiment more because issues caused by software developers are not of the “this person is 1/10 as productive as this other person” type. A bad developer isn’t a low positive effect on a project, but an active negative effect. As such, you can put literally any Y for a (Y)X programmer, since the scale of how inefficient a programmer can be goes up to infinite.
I think the pushback against 10X programmers comes primarily from the fact that many programmers who look good to managers (constantly push out new features) are in actuality an albatross around the necks of the other programmers who constantly have to fix the messes they create (in reality, a negative on team-wide production). What matters more to me in a teammate than how productive they are is to ensure that they are on the positive side of the scale at all, which the perceived 10X programmer is often actually a failure at.
Though I’ve definitely met people who just have such a wide knowledge base and think so quickly that they are in fact 10X as effective as a standard productive programmer, so I do understand where the idea comes from.
I think the pushback against 10X programmers comes primarily from the fact that many programmers who look good to managers (constantly push out new features) are in actuality an albatross around the necks of the other programmers who constantly have to fix the messes they create (in reality, a negative on team-wide production). What matters more to me in a teammate than how productive they are is to ensure that they are on the positive side of the scale at all, which the perceived 10X programmer is often actually a failure at.
Though I’ve definitely met people who just have such a wide knowledge base and think so quickly that they are in fact 10X as effective as a standard productive programmer, so I do understand where the idea comes from.
More people should be aware of Comrade Stakhanov, the "10x miner": https://en.wikipedia.org/wiki/Alexey_Stakhanov
> In 1988, the Soviet newspaper Komsomolskaya Pravda claimed that the widely cited achievements of Stakhanov were puffery. The paper insisted that Stakhanov had used a number of helpers on support works, while the throughout was tallied for him alone. Still, according to the newspaper, Stakhanov's approach had eventually led to increased productivity by means of a better work organization, including specialization and task sequencing
Exactly the same discussion, except there it was tonnes of coal which can be easily and unambiguously measured. But they can't be easily attributed. How much of his work was really that of his team? And how much of it was simply inflation by his managers for propaganda purposes? And how much of it was, underneath all the propaganda, real process improvements?
> In 1988, the Soviet newspaper Komsomolskaya Pravda claimed that the widely cited achievements of Stakhanov were puffery. The paper insisted that Stakhanov had used a number of helpers on support works, while the throughout was tallied for him alone. Still, according to the newspaper, Stakhanov's approach had eventually led to increased productivity by means of a better work organization, including specialization and task sequencing
Exactly the same discussion, except there it was tonnes of coal which can be easily and unambiguously measured. But they can't be easily attributed. How much of his work was really that of his team? And how much of it was simply inflation by his managers for propaganda purposes? And how much of it was, underneath all the propaganda, real process improvements?
TAN: I fearst heard of "Stachanovism" over forty years ago, in my teens. Some time before that I had read an anthology of American folk tales, so to me Comrade Alexei Grigorijevitj was always kind of a Soviet version of John Henry. Made it easier, when I later found out, to accept that Stachanov was also at least in part a myth...
Yes attribution can be hard.
At the same time, if one compares shoveling coal and laying bricks with software, then it'd be good to smash and destroy bricks, throw the coal back into the mine, raze houses. (Reducing the amount of code)
Software would be more comparable to designing the coal mining site, or architecturing a city (but not building it). And then maybe it's simpler to see, that individuals sometimes can have much impact.
At the same time, if one compares shoveling coal and laying bricks with software, then it'd be good to smash and destroy bricks, throw the coal back into the mine, raze houses. (Reducing the amount of code)
Software would be more comparable to designing the coal mining site, or architecturing a city (but not building it). And then maybe it's simpler to see, that individuals sometimes can have much impact.
> The benefit of talented engineers comes from the fact that they avoid costly pitfalls - not that they pump out more code per hour worked.
Not just avoid pitfalls, being able to put together a good architecture is a huge factor as well. The effect is cumulative. If you have a good design to begin with, everything becomes easier with less risk of bugs. The result is that implementing new, or changing existing functionality takes less time.
The 10x developer doesn't write 10x as much code, (s)he will probably write less code than the 1x developer.
Not just avoid pitfalls, being able to put together a good architecture is a huge factor as well. The effect is cumulative. If you have a good design to begin with, everything becomes easier with less risk of bugs. The result is that implementing new, or changing existing functionality takes less time.
The 10x developer doesn't write 10x as much code, (s)he will probably write less code than the 1x developer.
Exactly. It's not how fast someone churns out code but how well thought out/elegance in approach that delivers this 10x value.
Instead of writing entire systems from scratch, maybe you have enough experience or familiarity with well known techniques and libraries to ship faster.
Instead of writing entire systems from scratch, maybe you have enough experience or familiarity with well known techniques and libraries to ship faster.
> (s)he will probably write less code than the 1x developer.
Or better yet, remove code.
Or better yet, remove code.
This needs to be required reading for every first time, non-technical manager of software developers.
I always read it as a direct comparison though.
It doesn’t matter if I have better experience or I can contextualise intent better; the phrase “10x” means it would take a team of 10 to do it, in the time, scope, budget (whatever).
But there are major reasons this could be the case, if I’m on my own and I know the direction then I don’t have to quibble about what framework to use, how to name my variables, what I consider “proof of concept quality”. You just get your head down and do it with the entire scope and progress in your head at once.
No infighting about semantics, no deeply technical progress reports or trying to subdivide tasks which are not inherently subdividable.
More people is more communication and it’s quadratic.
It doesn’t matter if I have better experience or I can contextualise intent better; the phrase “10x” means it would take a team of 10 to do it, in the time, scope, budget (whatever).
But there are major reasons this could be the case, if I’m on my own and I know the direction then I don’t have to quibble about what framework to use, how to name my variables, what I consider “proof of concept quality”. You just get your head down and do it with the entire scope and progress in your head at once.
No infighting about semantics, no deeply technical progress reports or trying to subdivide tasks which are not inherently subdividable.
More people is more communication and it’s quadratic.
The author exactly says this "two engineers with the same experience".
I'm sure there are engineers that can create an architecture 10x better than mine.
But show me someone that can create UI 10x faster and I'll admit they're a God.
Some things can't be 10xed after some point. It just takes work.
Some things can be 10xed and some just can't. I find it silly to think someone can be overall 10xer at everything.
I'm sure there are engineers that can create an architecture 10x better than mine.
But show me someone that can create UI 10x faster and I'll admit they're a God.
Some things can't be 10xed after some point. It just takes work.
Some things can be 10xed and some just can't. I find it silly to think someone can be overall 10xer at everything.
> Saying 10x programmers are a myth because it's crazy that someone could do in 1 day what another could do in 1 week makes the assumption that both programmers in the example have the same amount of context, background understanding, and experience.
Yes, because that's how it's always presented. And if it's not, then it's also a myth because then it's not a 10x dev, it's 10x context, background understanding, and experience.
Either way it doesn't hold water.
Yes, because that's how it's always presented. And if it's not, then it's also a myth because then it's not a 10x dev, it's 10x context, background understanding, and experience.
Either way it doesn't hold water.
> it's 10x context, background understanding, and experience.
A person who is able to build 10x context, background and understanding is a 10x developer. Most people lack the ability to do that. Your post makes it seem like you could give those traits to anyone easily, but it doesn't work that way building the right mental models and being able to generalize your knowledge are key factors in talent.
A person who is able to build 10x context, background and understanding is a 10x developer. Most people lack the ability to do that. Your post makes it seem like you could give those traits to anyone easily, but it doesn't work that way building the right mental models and being able to generalize your knowledge are key factors in talent.
Why do people need to be motivated in such a way? Won't that just lead to a lot of disappointment and misery later on? Why isn't "being a good programmer" something we should admire?
Of course one programmer can create 10X the code of another. The limit isn't how fast they type. Its how correct the code is, and how much it leverages what you have and what you'll need. And that results in 'pumping out' more code per day. Whatever the reason (context, background, experience)
> The limit isn't how fast they type. Its how correct the code is
And how good your autocomplete tools are, or you repertoire of code based to copy from.
And how good your autocomplete tools are, or you repertoire of code based to copy from.
> I feel this "10x programmers are a myth" attitude comes from a good place of wanting to promote harmonious working and skill-up junior engineers
When comparing juniors you observe the same distribution.
I've met 10x straight out of college who ran around other new grads.
When comparing juniors you observe the same distribution.
I've met 10x straight out of college who ran around other new grads.
1 day vs 1 week: wouldn't that make them a 5X engineer? That's half of the advertised 10X...
>, I would say that 10x programmers do exist.
Yes but I think the underlying issue is that some people really Really don't like to acknowledge (or are unaware) there's a small set of elite programmers that can do things average coders can't. But any label we use to describe them (i.e. "10x", "rockstar", "ninja", etc) will be psychologically distasteful. I previously commented about that effect:
- https://news.ycombinator.com/item?id=13753178
- https://news.ycombinator.com/item?id=24753594
To see that hidden psychology driving the narrative... look at how the author constructed his comparison with extra qualifiers of "competent" & "similarly experienced" : ">The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly."
In other words, if we artificially construct the comparison by a priori assuming both programmers are equal, then the 10x difference is a myth. Well yes, that's tautology. If you invent a sentence to "prove" a point, you can set any conditions in the artificial universe in your favor that seems to support it.
However in the real world, the stack of resumes will have a candidates with wildly different skill levels. Some struggle with Fizz Buzz. Some can write a 3d game from scratch. But it's impossible to create a label to describe that wide gap which also doesn't invite bikeshedding on that label.
EDIT reply to: >"Why can't we call them master programmers?"
Because we'd still have endless bikeshedding of the label "master" as in "Master programmers are a myth..."
Yes but I think the underlying issue is that some people really Really don't like to acknowledge (or are unaware) there's a small set of elite programmers that can do things average coders can't. But any label we use to describe them (i.e. "10x", "rockstar", "ninja", etc) will be psychologically distasteful. I previously commented about that effect:
- https://news.ycombinator.com/item?id=13753178
- https://news.ycombinator.com/item?id=24753594
To see that hidden psychology driving the narrative... look at how the author constructed his comparison with extra qualifiers of "competent" & "similarly experienced" : ">The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly."
In other words, if we artificially construct the comparison by a priori assuming both programmers are equal, then the 10x difference is a myth. Well yes, that's tautology. If you invent a sentence to "prove" a point, you can set any conditions in the artificial universe in your favor that seems to support it.
However in the real world, the stack of resumes will have a candidates with wildly different skill levels. Some struggle with Fizz Buzz. Some can write a 3d game from scratch. But it's impossible to create a label to describe that wide gap which also doesn't invite bikeshedding on that label.
EDIT reply to: >"Why can't we call them master programmers?"
Because we'd still have endless bikeshedding of the label "master" as in "Master programmers are a myth..."
We don't call Vermeer a 10x painter, Beethoven a 10x composer, nor Shakespeare a 10x author. It would be silly to call Turing a 10x computer scientist, or rockstar and ninja would be insulting.
Vermeer, Beethoven and Shakespeare are masters of their crafts. The same word we use for skilled tradesmen. Why can't we call them master programmers?
Vermeer, Beethoven and Shakespeare are masters of their crafts. The same word we use for skilled tradesmen. Why can't we call them master programmers?
People typically call them geniuses, not masters. And the reason we don't call them genius programmers is that people don't like to use the genius label for people who aren't famous.
Because we're talking about different things.
A master craftsman will solve a problem quickly, efficiently, and elegantly, combining insightful attention to detail with speed and effectiveness.
A master creator will produce work of lasting relevance and power. The metric is quality and impact, not speed and efficiency.
Occasionally you get people like Mozart who combine elements of both, but they're exceptionally rare. And they work best in a relatively limited context which they have mastered completely. They're not perpetually chasing the latest shiny. (Mozart basically knew one style. Even he would struggle to master all the languages and genres that are common today.)
Turing would likely have made a poor backend developer, but he produced work that had lasting impact.
A typical 10X developer will be more like a master builder than a master computer scientist.
I don't find the labelling offensive, because it's clearly realistic. Some people are just very, very good. They produce clean, tight, code at speed, far more quickly than muddlers who produce reams of mediocre code which creaks along, breaks when you look at it, and doesn't actually solve the problem.
But a 10Xer isn't going to be good at everything. If they mostly do backend, they're not going to go toe to toe with game devs. Etc.
A master craftsman will solve a problem quickly, efficiently, and elegantly, combining insightful attention to detail with speed and effectiveness.
A master creator will produce work of lasting relevance and power. The metric is quality and impact, not speed and efficiency.
Occasionally you get people like Mozart who combine elements of both, but they're exceptionally rare. And they work best in a relatively limited context which they have mastered completely. They're not perpetually chasing the latest shiny. (Mozart basically knew one style. Even he would struggle to master all the languages and genres that are common today.)
Turing would likely have made a poor backend developer, but he produced work that had lasting impact.
A typical 10X developer will be more like a master builder than a master computer scientist.
I don't find the labelling offensive, because it's clearly realistic. Some people are just very, very good. They produce clean, tight, code at speed, far more quickly than muddlers who produce reams of mediocre code which creaks along, breaks when you look at it, and doesn't actually solve the problem.
But a 10Xer isn't going to be good at everything. If they mostly do backend, they're not going to go toe to toe with game devs. Etc.
I think part of the reasoning is in the trades there's the presumption that to be a master you must also be old (with exceptions, Da Vinci was active when he was still younger, 20).
In the programming industry, there's likely a bias more toward younger people, and hiring offices ask for the world. They'd like a whole staff of masters and rockstars. Though that doesn't preclude "older" people from being known as masters either. Take John Carmack or Jonathan Blow, for example.
In the programming industry, there's likely a bias more toward younger people, and hiring offices ask for the world. They'd like a whole staff of masters and rockstars. Though that doesn't preclude "older" people from being known as masters either. Take John Carmack or Jonathan Blow, for example.
That is a interesting thought, that seems to imply that those young programmers will not improve. If you are a master at 25, what do you call yourself after you have gained twenty more years of experience? It may be that those 25 year old's a more like journeymen then masters, or that programming is more like sports where youthful vigor are more important than experience.
John Carmack programmed Wolfenstein at 21 and doom when he was 22. At that point he did what most "masters of that craft" couldn't do. What would you call him? And what would you call him now, 30 years later?
> And what would you call him now, 30 years later?
Something else than thirty years ago, because presumably he has developed since then.
I think that was why GP suggested "journeyman" for younger people, because otherwise there's nothing to differentiate young "masters" from masters honed by thirty years of additional experience -- except adding the whole phrase "with thirty years of experience", which is pretty clumsy.
Something else than thirty years ago, because presumably he has developed since then.
I think that was why GP suggested "journeyman" for younger people, because otherwise there's nothing to differentiate young "masters" from masters honed by thirty years of additional experience -- except adding the whole phrase "with thirty years of experience", which is pretty clumsy.
[deleted]
How many times faster is an O(n) algorithm over a O(n^2) squared algorithm?
How many times faster is a developer who can write a compiler over one who can not?
We are at least consistent; I rather frequently see programmers claiming a "105 times faster!" benchmark that was actually the result of a fundamental complexity change.
Not everything is on a linear scale.
How many times faster is a developer who can write a compiler over one who can not?
We are at least consistent; I rather frequently see programmers claiming a "105 times faster!" benchmark that was actually the result of a fundamental complexity change.
Not everything is on a linear scale.
I once worked on a team that in hindsight had two 10x developers in a team of only 12. They were vastly different, and the difference to me is extremely interesting.
The first one was not a bad person by any means, but had no social skills, no ability to communicate and often just forged ahead building great stuff on his own. Entire areas of the software were entirely conceived and created by him, and it was difficult to even grasp what he was doing while pair programming with him. In a day he would write more tests and get more coverage than the rest of us would create in a week.
The second one had come from a FAANG-ish place where he was extremely successful, but didn't want the money or stress. He was extremely kind, considerate and great at communicating. Pair programming with him was a joy and he helped everyone else on the team grow. I'm confident he could have created entire regions of the software on his own, but he knew that wasn't the right thing to do. He would often ask questions until someone else on the team could solve a problem, even though I'm sure he knew how to solve it easily himself.
The first one was not a bad person by any means, but had no social skills, no ability to communicate and often just forged ahead building great stuff on his own. Entire areas of the software were entirely conceived and created by him, and it was difficult to even grasp what he was doing while pair programming with him. In a day he would write more tests and get more coverage than the rest of us would create in a week.
The second one had come from a FAANG-ish place where he was extremely successful, but didn't want the money or stress. He was extremely kind, considerate and great at communicating. Pair programming with him was a joy and he helped everyone else on the team grow. I'm confident he could have created entire regions of the software on his own, but he knew that wasn't the right thing to do. He would often ask questions until someone else on the team could solve a problem, even though I'm sure he knew how to solve it easily himself.
Yeah the first one is a risk. I've met one whom I had to take over the code of when he left and psh, I wished he was a dumbass instead. He could produce shitloads (but would never test, interestingly), do stuff I honestly can't do, but do you really need to bitshift instead of doing a modulo to save 1 CPU instruction ?
The amount of obscure waste of programming complexity made us actually just abandon the thing he spent years on to just not do it. And everything works fine and we still make money and we're just probably a little bit less clever about how we do it. We also have a lot more time to listen to users and solve their problems, rather than gloat on our genius and solve our own created problems :D
Your second example is inspiring and I hope to meet one to learn from too !
The amount of obscure waste of programming complexity made us actually just abandon the thing he spent years on to just not do it. And everything works fine and we still make money and we're just probably a little bit less clever about how we do it. We also have a lot more time to listen to users and solve their problems, rather than gloat on our genius and solve our own created problems :D
Your second example is inspiring and I hope to meet one to learn from too !
My go-to examples of 10x developers are benevolent dictators like antirez (of Redis), evanw (of esbuild + Figma CTO), youyuxi (of Vue), Carmack, etc.
Both qualitatively and quantitatively, their output is at least 10x of a typical developer at a typical company, not even counting everything these people do besides writing code. Many more are not famous but are in the same league of impact/productivity - I'm genuinely puzzled how someone can say such people do not exist.
Both qualitatively and quantitatively, their output is at least 10x of a typical developer at a typical company, not even counting everything these people do besides writing code. Many more are not famous but are in the same league of impact/productivity - I'm genuinely puzzled how someone can say such people do not exist.
I agree. Another example, Linus T wrote git from scratch to hosting the Linux kernel in 2.5 months. I'd say 10x is a low estimate.
I've worked with a guy who wrote great code like he was typing an email.
Everyone has a ceiling of the complexity of problems they can handle, some programmers are outliers in this regard.
I've worked with a guy who wrote great code like he was typing an email.
Everyone has a ceiling of the complexity of problems they can handle, some programmers are outliers in this regard.
Bit of an aside, but writing an email is its own art. Not many developers know how to write an email that a busy, non-technical VP will read, understand and act on in the way they intended. (Then again, neither do many managers.)
You mix popularity with 10x. Not all 10x programmers are popular.
I believe 10xers exist within a business or technical context. This isn't limited to the field of computer science, but even traditional engineering (Edison) and sciences (Newton) have plenty 10x examples.
I believe 10xers exist within a business or technical context. This isn't limited to the field of computer science, but even traditional engineering (Edison) and sciences (Newton) have plenty 10x examples.
I'm not mixing - as I wrote, many more are not famous, but their impact is similar. When discussing abstract concepts, it helps to have concrete examples of that phenomena. Using "famous" people is a shortcut to define a shared definition for what "10x" might look like.
And yes, there are "10x" teachers, investors, lawyers, storytellers, sales folks, etc. Similarly, the distribution of talent that helps with "software development" might have a very long tail, leading to extraordinary performance versus the median.
And yes, there are "10x" teachers, investors, lawyers, storytellers, sales folks, etc. Similarly, the distribution of talent that helps with "software development" might have a very long tail, leading to extraordinary performance versus the median.
IF 10x exist, some will be popular and most won’t. Obviously he won’t know the obscure ones or pick examples you can’t relate to. So while he didn’t prove his point perhaps, perhaps you didn’t disprove his either. :)
To pose it another way: for general software Dev (not some niche use case that only one guy understands), let’s say building websites in Vue or React, the idea of a 10x developer is that they can work in January and another, average, programmer can then spend February, March, April, May, June, July, August, and Sept… and the average guy won’t get more done?
Or they come in only every other Monday and contribute as much as a median Dev working full time?
It just doesn’t seem reasonable at all, at least if we read it literally.
I have worked with and met great, outstanding, developers who are much better than me. Some of them famous. None of them are anything close to 10x as productive, and I’m not particularly great. They’re much smarter than me, for sure, but they’re not 10x as productive.
Or they come in only every other Monday and contribute as much as a median Dev working full time?
It just doesn’t seem reasonable at all, at least if we read it literally.
I have worked with and met great, outstanding, developers who are much better than me. Some of them famous. None of them are anything close to 10x as productive, and I’m not particularly great. They’re much smarter than me, for sure, but they’re not 10x as productive.
How long would it have taken you or me to write Doom, or Quake? How long would it have taken Carmack, if it'd just been him?
I think you have a false dichotomy here. Carmack isn't 10x better a C or assembly than me. But in his domain he's easily 10x smarter and more productive than me.
And on top of that, he has a quarter century more experience in graphics programming than me. That shit accumulates.
Yes, actually. In graphics programming, from 2D and software rendered, to OpenGL and VR, you could give him and me (and presumably you) any task achievable in a few human decades, and he'd do it more than 10x faster.
"Graphics programming" is not a small niche, and yes in that space he's a 10x programmer.
I think you're thinking of this the wrong way. I agree that for something as simple as "build some websites", yeah, 10x is going to be very hard. You're then just turning specs into code, pretty much.
10x programmers are those that don't waste 9 months. The hard part is knowing which 9 months out of 10, which 9 ideas and components out of 10, is waste.
For "build a web forum" or something, yeah there are no 10x programmers. Though there are many many 0.1x programmers still.
I think you have a false dichotomy here. Carmack isn't 10x better a C or assembly than me. But in his domain he's easily 10x smarter and more productive than me.
And on top of that, he has a quarter century more experience in graphics programming than me. That shit accumulates.
Yes, actually. In graphics programming, from 2D and software rendered, to OpenGL and VR, you could give him and me (and presumably you) any task achievable in a few human decades, and he'd do it more than 10x faster.
"Graphics programming" is not a small niche, and yes in that space he's a 10x programmer.
I think you're thinking of this the wrong way. I agree that for something as simple as "build some websites", yeah, 10x is going to be very hard. You're then just turning specs into code, pretty much.
10x programmers are those that don't waste 9 months. The hard part is knowing which 9 months out of 10, which 9 ideas and components out of 10, is waste.
For "build a web forum" or something, yeah there are no 10x programmers. Though there are many many 0.1x programmers still.
> How long would it have taken you or me to write Doom, or Quake? How long would it have taken Carmack, if it'd just been him?
I'm not a games programmer. I doubt a median games programmer would take 10x the length of time that it would take any other games programmer. It just seems implausible, and I don't know why people want to defend it.
I'm not a games programmer. I doubt a median games programmer would take 10x the length of time that it would take any other games programmer. It just seems implausible, and I don't know why people want to defend it.
I spent 8 years at EA and was a senior software engineer. I have absolutely witnessed 10x game programmers.
I think in any field where you have a deep domain with complex, difficult constraints, it is entirely possible to have programmers with 10x the effectiveness of the median simply because of their greater domain expertise. They know the unique algorithms, data structures, design patterns, hacks, tricks, hardware quirks, tools, debuggers, code smells, etc. All of that has a huge compounding factor when it comes to output.
Here's a story I like to tell:
I joined EA shortly after the PS2 came out and worked at the studio that made Madden. Madden was a launch title on the PS2 (meaning it shipped right as the PS2 hardware did) and that version essentially sealed Madden's success. It was hugely successful.
But making a launch title is really hard. You're developing softare for a hardware platform that is itself in flux. When EA first started working on Madden PS2, they didn't have any dev kits to work on. I don't know if dev kits even existed. They needed to write code that they couldn't compile and run. But if they didn't start immediately, they would never be able to get the game done in time for the launch.
They had a guy on the team with a reputation for being a wizard. He took the MIPS R5900 reference manual, and disappeared into an office with blacked out windows for some number of weeks. When he re-emerged, he had written a PS2 emulator despite never having access to an actual PS2. The rest of the team were able to compile and run the game on that emulator so that they could make progress until eventually real dev kits arrived. From what I heard, when the real hardware showed up, the game actually ran on it.
Now, some of this legend may have grown in the retelling (it was already legendary by the time it was told to me), but I worked with that engineer a few times and I can vouch for his incredible ability to get stuff done. I remember once when FIFA was having performance problems and couldn't get their framerate high enough to ship. He was called into to help and a few days later, got it up to a solid 30 FPS. This was even though the team's own engineers had been trying to make progress and he had never touched the code before.
I think people dislike the mythos of 10x engineers because it's interpreted as some sort of cognitive essentialism. But I think most of it is just really deep domain expertise. Instead of talking about "10x engineers", we should talk about 10x at what.
I think in any field where you have a deep domain with complex, difficult constraints, it is entirely possible to have programmers with 10x the effectiveness of the median simply because of their greater domain expertise. They know the unique algorithms, data structures, design patterns, hacks, tricks, hardware quirks, tools, debuggers, code smells, etc. All of that has a huge compounding factor when it comes to output.
Here's a story I like to tell:
I joined EA shortly after the PS2 came out and worked at the studio that made Madden. Madden was a launch title on the PS2 (meaning it shipped right as the PS2 hardware did) and that version essentially sealed Madden's success. It was hugely successful.
But making a launch title is really hard. You're developing softare for a hardware platform that is itself in flux. When EA first started working on Madden PS2, they didn't have any dev kits to work on. I don't know if dev kits even existed. They needed to write code that they couldn't compile and run. But if they didn't start immediately, they would never be able to get the game done in time for the launch.
They had a guy on the team with a reputation for being a wizard. He took the MIPS R5900 reference manual, and disappeared into an office with blacked out windows for some number of weeks. When he re-emerged, he had written a PS2 emulator despite never having access to an actual PS2. The rest of the team were able to compile and run the game on that emulator so that they could make progress until eventually real dev kits arrived. From what I heard, when the real hardware showed up, the game actually ran on it.
Now, some of this legend may have grown in the retelling (it was already legendary by the time it was told to me), but I worked with that engineer a few times and I can vouch for his incredible ability to get stuff done. I remember once when FIFA was having performance problems and couldn't get their framerate high enough to ship. He was called into to help and a few days later, got it up to a solid 30 FPS. This was even though the team's own engineers had been trying to make progress and he had never touched the code before.
I think people dislike the mythos of 10x engineers because it's interpreted as some sort of cognitive essentialism. But I think most of it is just really deep domain expertise. Instead of talking about "10x engineers", we should talk about 10x at what.
[deleted]
The median games programmer wouldn't be able to do it in 50 years. (assuming they were locked in a room for 50 years with that same hardware, not that they got to see state of the art progress and upgrade their machine)
The amount of innovation, from applied BSP, Zbuffer tradeoffs, light maps with interpolation, interleaved FPU corrections for texture mapping, multiplayer protocols (qtest used TCP), brush-levels, etc...
Before ID software did these things, they weren't checkboxes for what to do. After, sure. But the hard part of programming is not typing.
The median programmer would not have been able to do it before it had been completely irrelevant. The median games programmer could do it in 2005. In 1993-1996? Not a chance.
The main competitor to Quake was Duke Nukem, which technologically was just "doom and a half". The enemies were sprites, ffs.
ID software was years ahead of every other games developer.
The reason other games licensed the Quake engine wasn't that it was cheaper than doing it yourself, it was that they couldn't do it.
Edit: granted, I have a low opinion of the median programmer. But sometimes in life you meet people who, with things you think you're actually pretty good at, just completely mop the floor with you without even trying (or showing off). It's humbling.
The amount of innovation, from applied BSP, Zbuffer tradeoffs, light maps with interpolation, interleaved FPU corrections for texture mapping, multiplayer protocols (qtest used TCP), brush-levels, etc...
Before ID software did these things, they weren't checkboxes for what to do. After, sure. But the hard part of programming is not typing.
The median programmer would not have been able to do it before it had been completely irrelevant. The median games programmer could do it in 2005. In 1993-1996? Not a chance.
The main competitor to Quake was Duke Nukem, which technologically was just "doom and a half". The enemies were sprites, ffs.
ID software was years ahead of every other games developer.
The reason other games licensed the Quake engine wasn't that it was cheaper than doing it yourself, it was that they couldn't do it.
Edit: granted, I have a low opinion of the median programmer. But sometimes in life you meet people who, with things you think you're actually pretty good at, just completely mop the floor with you without even trying (or showing off). It's humbling.
> I doubt a median games programmer would take 10x the length of time that it would take any other games programmer. It just seems implausible, and I don't know why people want to defend it.
Then why did all those thousands of other game programmers fail at creating a decent 3d game, before Doom was released? It's not like Carmack was the only one trying.
Then why did all those thousands of other game programmers fail at creating a decent 3d game, before Doom was released? It's not like Carmack was the only one trying.
> How long would it have taken you or me to write Doom, or Quake?
Almost definitely not 10 years.
Almost definitely not 10 years.
I think it's more likely that we wouldn't have thought something like Doom to be possible until Carmack came along and squeezed oodles of math tricks and hacks into the game to let it run on hardware of the era. So it may as well have be an infinitely long development time for us.
If you wanted to write Doom, starting in 1993, and take 10 years, your most efficient strategy would probably be to do something else for the first nine of them and wait for the technology to change around you.
Waiting for the equivalent of Carmack to write and open source the underlying libraries, basically.
Almost certainly you would just plain have not been able to do it at all. Not in 1993-1996. Not without it already having been done once.
And if you had, it would have taken you more than 10 years to realize what the right thing is, and to solve all very complex problems that showed up on the way.
Quake doesn't even have any load times! Not even with the hardware available at the time.
And if you had, it would have taken you more than 10 years to realize what the right thing is, and to solve all very complex problems that showed up on the way.
Quake doesn't even have any load times! Not even with the hardware available at the time.
There is no "10X" touch-typist because a) the performance limit is absolute & relatively low and b) the learning curve is such that it's easy to get to the limit and plateau. Now let's increase complexity - still typing, but you must translate the text from another language. Increase again - now you're translating poetry. Increase again - the poetry is original Shakespeare. You need to translate into contemporary English approachable to Gen Z, as a script for a TikTok short, referencing memes from current events. There is no doubt that some people will have a combination of talents - in language, typing, copywriting, built-up cultural knowledge, lived experiences - that will make them 10X in such jobs.
The more software development work approaches touch-typing, the less difference between 1x and 10X — strict Jira tickets in, garbage out, maybe slightly faster. Spec-work, and most grunt-work, is undifferentiated and does not benefit from a 10X person. The more your work approaches poetry - such as exercising user empathy, improving the architecture, considering UX, respecting performance constraints, understanding user's jobs to be done, and improving your implementation around that - the more creative space there is for 10X to reveal itself.
The more software development work approaches touch-typing, the less difference between 1x and 10X — strict Jira tickets in, garbage out, maybe slightly faster. Spec-work, and most grunt-work, is undifferentiated and does not benefit from a 10X person. The more your work approaches poetry - such as exercising user empathy, improving the architecture, considering UX, respecting performance constraints, understanding user's jobs to be done, and improving your implementation around that - the more creative space there is for 10X to reveal itself.
>There is no "10X" touch-typist
Ironically enough your example is flawed: there are documented 10x touch-typists.
The realities of the court system place high demands on the typists; the minimum required typing speed is already quite high: trained court reporter or closed captioner must write speeds of approximately 180, 200, and 225 words per minute (wpm) at very high accuracy in the categories of literary, jury charge, and testimony, respectively[1] - and some exceed the minimum and go for 300 wpm. Even better, the official record for American English [is] 375 wpm [2].
Compare that to the average typing speeds around 30 - 40 wpm [3] Granted, the court reporters use specialized input devices (stenotypes) - but hey, the same can be said about highly productive programmers, who use specialized development environments - and sometimes also specialized input devices.
--
[1] https://en.wikipedia.org/wiki/Stenotype
[2] ibid.
[3] https://en.wikipedia.org/wiki/Touch_typing#Speed
Ironically enough your example is flawed: there are documented 10x touch-typists.
The realities of the court system place high demands on the typists; the minimum required typing speed is already quite high: trained court reporter or closed captioner must write speeds of approximately 180, 200, and 225 words per minute (wpm) at very high accuracy in the categories of literary, jury charge, and testimony, respectively[1] - and some exceed the minimum and go for 300 wpm. Even better, the official record for American English [is] 375 wpm [2].
Compare that to the average typing speeds around 30 - 40 wpm [3] Granted, the court reporters use specialized input devices (stenotypes) - but hey, the same can be said about highly productive programmers, who use specialized development environments - and sometimes also specialized input devices.
--
[1] https://en.wikipedia.org/wiki/Stenotype
[2] ibid.
[3] https://en.wikipedia.org/wiki/Touch_typing#Speed
You make a good point that hints at another often-undefined assumption in these discussions - 10X performance vs who, exactly? IMO, it should be vs "a typical peer in that profession". For court reporters, if "a typical peer" is a trained court reporter who averages ~200 wpm, and a superstar is at 300wpm, then it's a 1.5X gain. If a "typical peer" is a regular Joe, then 300wpm would be 10X - but this doesn't feel appropriate because we compare productivity of a "10x developer" vs a "typical developer", rather than vs "an average Facebook visitor".
Fair enough.
I've had good luck discussing the subject back in 2013: https://news.ycombinator.com/item?id=6464807 and https://news.ycombinator.com/item?id=6465175, with the insightful replies.
Wow, reading the discussion from back then shows how much HN changed in spirit.
I've had good luck discussing the subject back in 2013: https://news.ycombinator.com/item?id=6464807 and https://news.ycombinator.com/item?id=6465175, with the insightful replies.
Wow, reading the discussion from back then shows how much HN changed in spirit.
Even with drudge ticket-punching work, there is a vast spectrum of productivity between somebody who is capable and conscientious enough to do it correctly the first time and the person who has to rework everything multiple times because they can't do it right the first time and continue making mistakes.
That definition is too narrow. How about this one: can someone work for 1 year and (consistently) produce 10x more value for their organization than the median engineer? This seems transparently true if you've worked in any large organization.
> some niche use case that only one guy understands
But that's where all the value is! Step 1 of being an exceptional worker is not to do unexceptional work if you can at all avoid it.
> at least if we read it literally
This is where it does fall down. There isn't an X that you can reliably measure 10 of, it's all very subjective.
But that's where all the value is! Step 1 of being an exceptional worker is not to do unexceptional work if you can at all avoid it.
> at least if we read it literally
This is where it does fall down. There isn't an X that you can reliably measure 10 of, it's all very subjective.
-1x programmers also exist, in a variety of guises. From the dev with long cv of projects he’s contributed nothing to and been sidelined from, but who manages to keep getting hired because of his cv, to the dev who crowbars in new tech where it’s not needed and causes a ton of problems.
Presumably a 1x programmer is an average programmer. The type who does his job acceptably. He doesn't create huge problems, nor solve them. He is a fine team player and team member, but not a leader. Nobody despairs when he leaves, and he will be forgotten after a few months.
Basically, the majority of programmers.
Basically, the majority of programmers.
This was about minus 1x, so having a negative impact. And yes, these do exist.
Now that I think about it, the worst code seem to lead to situations where the top developers can really show their value.
I mean if the code base is quite good and is kept that way, then a normal developer can deal with it quite well. But if you get a legacy mess, then the hard-core developer can make really drastic changes that have enormous value to the maintainability, future development and bug-wise.
If a normal developer tries to tackle that mess, it's easy to get into trouble and drown in the sea of opportunities and not see the big picture and take a proper road plan to improve things.
So in a way -1 developers enable the top developers to show the gap between them and the normal devs.
I mean if the code base is quite good and is kept that way, then a normal developer can deal with it quite well. But if you get a legacy mess, then the hard-core developer can make really drastic changes that have enormous value to the maintainability, future development and bug-wise.
If a normal developer tries to tackle that mess, it's easy to get into trouble and drown in the sea of opportunities and not see the big picture and take a proper road plan to improve things.
So in a way -1 developers enable the top developers to show the gap between them and the normal devs.
This could be managers who deem themselves programmers or software architects. (Often they would use their authority to promote their ideas and effectively shut everyone else up.)
[deleted]
I've also met one 10x programmer in my life. A lot comes down to being able to reason fast, architect well, and write code on the fly without resorting much to:
* Documentation
* The debugger / print()
Becoming a 10x developer means that you have a set of skills that work well together in an end to end process from going to initial requirements to fully fledged architecture and/or code.
* Documentation
* The debugger / print()
Becoming a 10x developer means that you have a set of skills that work well together in an end to end process from going to initial requirements to fully fledged architecture and/or code.
I think most people who have worked with me would consider me a 10x developer, I am capable of writing something in hours that would take others weeks (not in a half-arsed way, but taking all of the complexities of the domain into account). And I think that's what most people think a 10x'er is: that they can just do stuff quicker.
That's not what I think 10x'er is though. I think a 10x'er is someone who enables the 'average' developer to become a 2x, 3x, 4x developer. This can be through writing some core tech, a library used by all, or through mentoring and guidance. The 10x'er can then become a 100x or even 1000x developer. The 10x dev is the person who picks up the really difficult or ugly stuff and says: "Hold my beer, I'll get that done" - motivating the team and helping them to keep velocity. They lead by example and explain to the team why they've taken the approach they have.
Sometimes people use the term Rockstar to define a 10x developer. I think that's a loaded term that comes with an 'arrogance' tag. The true 10x developers shouldn't be arrogant (beyond the base level arrogance everyone of ability has), they can and should be the glue that holds a team together and helps everyone achieve more.
That's not what I think 10x'er is though. I think a 10x'er is someone who enables the 'average' developer to become a 2x, 3x, 4x developer. This can be through writing some core tech, a library used by all, or through mentoring and guidance. The 10x'er can then become a 100x or even 1000x developer. The 10x dev is the person who picks up the really difficult or ugly stuff and says: "Hold my beer, I'll get that done" - motivating the team and helping them to keep velocity. They lead by example and explain to the team why they've taken the approach they have.
Sometimes people use the term Rockstar to define a 10x developer. I think that's a loaded term that comes with an 'arrogance' tag. The true 10x developers shouldn't be arrogant (beyond the base level arrogance everyone of ability has), they can and should be the glue that holds a team together and helps everyone achieve more.
The way I see it:
Developer: a person that creates software.
10x development: a person that does it 10x faster.
What you describe, I'd simply call a lead developer since making other developers 2x or more is a lead developer his job.
If you're a developer and you're doing this, then it'd be one argument to get promoted to lead.
Also, if you really are a 10x dev, the one I know works in the HFT space. He's making bank. I'm not sure if that's your thing, but I've noticed they seem to appreciate 10x devs a lot more than any other company out there (and that includes FAANG).
Developer: a person that creates software.
10x development: a person that does it 10x faster.
What you describe, I'd simply call a lead developer since making other developers 2x or more is a lead developer his job.
If you're a developer and you're doing this, then it'd be one argument to get promoted to lead.
Also, if you really are a 10x dev, the one I know works in the HFT space. He's making bank. I'm not sure if that's your thing, but I've noticed they seem to appreciate 10x devs a lot more than any other company out there (and that includes FAANG).
Leading by example is not necessarily the same as being a lead developer. For example, my principal engineer is easily a 10x'er as just a pure developer, but he's also a force multiplier for everybody on the team, he's literally a machine. He leads no one, I made him principal engineer so he didn't have to.
If he was to just write code he'd be a 10x'er, with the other work he does to help his colleagues, he's many times more than that.
If he was to just write code he'd be a 10x'er, with the other work he does to help his colleagues, he's many times more than that.
In the fantasy organization where means justify ends, the 10x-er's time is
better spent making the 1x-er obsolete. Your lip service to the 1x-er however
does not go unappreciated as keeping him on and making him feel more
productive is instrumental for political advancement, which is more important
for your fortunes than the technical kind.
What an incredibly cynical view of the world. Teams where people collaborate are more successful, if you think trying to make your colleagues obsolete is time "better spent", I honestly feel sorry for your co-workers. Yes, if I sat and just wrote code all day I would get a lot done. But, if I help my colleagues too, we all get lots more done.
Being a 10x developer is a factor of experience. You don’t need to debug the issue if you can already reason through to where it must be.
Yes, but some people generalize their experiences much much better and therefore can master domains and adjacent things to a degree others will never reach.
> Becoming a 10x developer means that you have a set of skills that work well together in an end to end process from going to initial requirements to fully fledged architecture and/or code.
The problem with that definition is that it tags the coveted 10x label onto the problematic cases mentioned in the article: that guy who is able to hack together POC code that he demos and passes off as the solution, but requires a whole team to fix and to rewrite and to rearchitect to get it to actually work and be production-ready and be maintainable.
Inadvertently, this means that we see the 10x label being tied to observable behaviors that are actually a productivity nightmare just because they go from zero to demo in record time.
The problem with that definition is that it tags the coveted 10x label onto the problematic cases mentioned in the article: that guy who is able to hack together POC code that he demos and passes off as the solution, but requires a whole team to fix and to rewrite and to rearchitect to get it to actually work and be production-ready and be maintainable.
Inadvertently, this means that we see the 10x label being tied to observable behaviors that are actually a productivity nightmare just because they go from zero to demo in record time.
Honestly I’ve met real 10x programmers.
Well, speaking honestly probably more like 5x, but it would take a solid 5 person team working well together to do the same things he did.
His ability to reason about the problem- get to the root of the persons actual issue, proof of concept intitial revision and iterate until it was better quality than most popular open source projects was honestly awe inspring.
His only problem was his own lack of self confidence. He used tools and always asked if they were really the best or if he was inflicting them, had good reasons for not using things that we consider industry standard (he prefers restructured text over markdown because it’s more expressive, for example) but was ultimately very sad about every project he made because he felt like he had inflicted his (good) work on the world.
So, idk. The people who think they are rockstars probably not. He definitely didn’t think he was but he was a god to me.
Well, speaking honestly probably more like 5x, but it would take a solid 5 person team working well together to do the same things he did.
His ability to reason about the problem- get to the root of the persons actual issue, proof of concept intitial revision and iterate until it was better quality than most popular open source projects was honestly awe inspring.
His only problem was his own lack of self confidence. He used tools and always asked if they were really the best or if he was inflicting them, had good reasons for not using things that we consider industry standard (he prefers restructured text over markdown because it’s more expressive, for example) but was ultimately very sad about every project he made because he felt like he had inflicted his (good) work on the world.
So, idk. The people who think they are rockstars probably not. He definitely didn’t think he was but he was a god to me.
Disclaimer: I feel strongly about this. However, if you have a strong other opinion, then I applaud you and I'd be curious to read it. Rationally, I don't think this term matters a lot as there are better terms to describe programmers, but emotionally it's tied too much to a friend of mine and that's what makes me feel so strongly about it.
> The problem with that definition is that it tags the coveted 10x label onto the problematic cases mentioned in the article: that guy who is able to hack together POC code that he demos and passes off as the solution, but requires a whole team to fix and to rewrite and to rearchitect to get it to actually work and be production-ready and be maintainable.
As I said in another comment. I've met one 10x programmer. So I consider him to be the archetype 10x programmer since he's the only visible proof I have. We're good friends, we mostly talk about life. I sometimes see him code. Let me assure you, he is the last guy that would hack together POC code. I know this, because I'd be one of the first to do that and he gives me a lot of flack for that when I show it to him xD
I should have left out the "or" in my definition. He knows how to architect, he knows how to code, he micro-optimizes every nano, is capable of understanding how underlying ISAs are doing their thing. He knows how to reason well. At companies where he'd enter as a junior, he was immediately recognized for having better technical skills than people 10+ years their senior (note: not his social skills, those are simply normal).
They exist. And it's easy to see why 10x programmers exist. Take a bell curve of ability and you find many 10x'ers on many scales of ability.
Or would you argue that people like Einstein was not a 10x physicist, or that Euler wasn't a 10x mathematician? And there are many more that I wouldn't even know of.
10x programmer is very related to the idea of a genius, in my opinion. It's simply a subset of it.
Feel free to disagree. It's good to see other perspectives.
> The problem with that definition is that it tags the coveted 10x label onto the problematic cases mentioned in the article: that guy who is able to hack together POC code that he demos and passes off as the solution, but requires a whole team to fix and to rewrite and to rearchitect to get it to actually work and be production-ready and be maintainable.
As I said in another comment. I've met one 10x programmer. So I consider him to be the archetype 10x programmer since he's the only visible proof I have. We're good friends, we mostly talk about life. I sometimes see him code. Let me assure you, he is the last guy that would hack together POC code. I know this, because I'd be one of the first to do that and he gives me a lot of flack for that when I show it to him xD
I should have left out the "or" in my definition. He knows how to architect, he knows how to code, he micro-optimizes every nano, is capable of understanding how underlying ISAs are doing their thing. He knows how to reason well. At companies where he'd enter as a junior, he was immediately recognized for having better technical skills than people 10+ years their senior (note: not his social skills, those are simply normal).
They exist. And it's easy to see why 10x programmers exist. Take a bell curve of ability and you find many 10x'ers on many scales of ability.
Or would you argue that people like Einstein was not a 10x physicist, or that Euler wasn't a 10x mathematician? And there are many more that I wouldn't even know of.
10x programmer is very related to the idea of a genius, in my opinion. It's simply a subset of it.
Feel free to disagree. It's good to see other perspectives.
If their code isn't running in production with little maintenance required then they didn't actually produce the thing. Just add that requirement and it becomes clear.
So there are these moments in development, where the task boils down to ‘I just need to build this system. I can see it all in my head, and I need to turn it into code’
And for that task, factors like how well a developer knows the libraries, how fluently they can express themselves in the language, how fast they can type, how seamlessly their mental model fits with the tools available.. all of those things can make the difference between it being something one dev can crank out in a couple of days, and another dev takes a few weeks over.
And I definitely want more of the first kind of dev on my team than the second kind.
But here’s where that doesn’t match up to what we expect of lead developers and more senior devs as their careers advance, and why ‘10x’ is not necessarily an indicator of ‘ready for promotion’.
The person who can see the whole problem and turn it into code in 2 days often struggles to figure out how to scale what they do to more people. They can’t express how the code should work to someone else because they’re already three steps ahead - explaining how it needs to be done will take longer than just doing it!
So the problem is as soon as this person encounters a problem that is too big to fit all in their head and crank out in a few days, or that requires expertise they don’t yet have, so they need to collaborate… the approach they have learned to rely on stops working.
But it turns out there are 10x team leaders too - devs who can break large projects up into chunks that can be delivered separately, who make sure the team is building the right thing, who know how to make use of that individual who can just crank out a complex system in a couple of days - repeatedly and sustainably - and who make systems that are the right shape so that later features are cheaper and easier to add, rather than becoming harder and slower. In fact at this level the multipliers go way beyond 10x.
And some of those skills build on the individual 10x dev skill set but some are orthogonal to it. Some are downright opposed.
And for that task, factors like how well a developer knows the libraries, how fluently they can express themselves in the language, how fast they can type, how seamlessly their mental model fits with the tools available.. all of those things can make the difference between it being something one dev can crank out in a couple of days, and another dev takes a few weeks over.
And I definitely want more of the first kind of dev on my team than the second kind.
But here’s where that doesn’t match up to what we expect of lead developers and more senior devs as their careers advance, and why ‘10x’ is not necessarily an indicator of ‘ready for promotion’.
The person who can see the whole problem and turn it into code in 2 days often struggles to figure out how to scale what they do to more people. They can’t express how the code should work to someone else because they’re already three steps ahead - explaining how it needs to be done will take longer than just doing it!
So the problem is as soon as this person encounters a problem that is too big to fit all in their head and crank out in a few days, or that requires expertise they don’t yet have, so they need to collaborate… the approach they have learned to rely on stops working.
But it turns out there are 10x team leaders too - devs who can break large projects up into chunks that can be delivered separately, who make sure the team is building the right thing, who know how to make use of that individual who can just crank out a complex system in a couple of days - repeatedly and sustainably - and who make systems that are the right shape so that later features are cheaper and easier to add, rather than becoming harder and slower. In fact at this level the multipliers go way beyond 10x.
And some of those skills build on the individual 10x dev skill set but some are orthogonal to it. Some are downright opposed.
I like to say that I am a 10x developer 10% of the time. My work tends to be very "bursty" followed by long bouts of low productivity. It probably has more to do with my mental health than anything else. :/
I have the same problem. But the more I tackle it in reasonable ways, the better it gets. Here's some pointers that work for me:
- enough sleep, rather get in bed early than late as the quality of the sleep depends on natural rhythms
- engage with people that are affected by my work - this is important for motivation and to keep track of what actually matters
- operationalize everything, say out loud what to do next
- being honest when I have bad focus, talk about it
- trust my instinct and do the right thing, if I don't I quickly lose focus and motivation, if opinions don't align learn why
- enough sleep, rather get in bed early than late as the quality of the sleep depends on natural rhythms
- engage with people that are affected by my work - this is important for motivation and to keep track of what actually matters
- operationalize everything, say out loud what to do next
- being honest when I have bad focus, talk about it
- trust my instinct and do the right thing, if I don't I quickly lose focus and motivation, if opinions don't align learn why
My personal joke about this is "I used to be a 10x developer but then I took an arrow to the knee".
Many, many years ago a colleague wrote about the experience of being bipolar and choosing to stop taking the lithium for a temporary productivity boost and subsequent crash.
Many, many years ago a colleague wrote about the experience of being bipolar and choosing to stop taking the lithium for a temporary productivity boost and subsequent crash.
> choosing to stop taking the lithium
Having been unmediated and undiagnosed for most of my life, mania is a hell of a drug. But the cost is high... really high.
Having been unmediated and undiagnosed for most of my life, mania is a hell of a drug. But the cost is high... really high.
Sounds like ADHD hyperfocus.
There can be that. But also some managers do not like you wander off task. So stick in your lane stick to your tasks... So eventually after years of that you just do only what is needed and skip anything else. After a few of those 'that is very nice but...' conversations you just say screw it and coast. Every once and awhile I get a burst where I can propel my group forward. But then usually I feel like I am bolder chained to them and dragging them down. More than likely I am just average and doing OK.
Was just coming here to say, this is my exact situation
I think he's beating up a straw man, here.
> The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly.
Over such short time scales, maybe, but the idea that someone could contribute in 1 year what another programmer wouldn't accomplish in 10 years is highly plausible, to me.
> The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly.
Over such short time scales, maybe, but the idea that someone could contribute in 1 year what another programmer wouldn't accomplish in 10 years is highly plausible, to me.
Also, sometimes it isn’t someone ‘moving fast and breaking things’ - sometimes everyone else gets paralyzed with indecision and can’t even get started.
Someone who can sit down and start coding in an ambiguous environment, period, can easily make 10x more value themselves, and allow others to go from .1x to 1-5x merely by being able to pick somewhere to start and just doing it, which allows everyone else to break their own ‘freeze’ and start engaging as now there is something concrete that breaks the locked up state they were in.
I’ve done it a few times, and seen others do it to. It’s magic going from ‘everyone rehashing things on a whiteboard for the 10th time’ to ‘everyone working on the next iteration’
Someone who can sit down and start coding in an ambiguous environment, period, can easily make 10x more value themselves, and allow others to go from .1x to 1-5x merely by being able to pick somewhere to start and just doing it, which allows everyone else to break their own ‘freeze’ and start engaging as now there is something concrete that breaks the locked up state they were in.
I’ve done it a few times, and seen others do it to. It’s magic going from ‘everyone rehashing things on a whiteboard for the 10th time’ to ‘everyone working on the next iteration’
The "MVP" or "strawman" is incredibly valuable; people can't tell a blank sheet of paper what they want, but if you show them a thing they'll tell you what's wrong with it.
I've noticed myself that I can happily write detailed comments on HN or StackOverflow but have no inclination for blog posts, for that kind of self-content-marketing that seems to be popular these days.
I've noticed myself that I can happily write detailed comments on HN or StackOverflow but have no inclination for blog posts, for that kind of self-content-marketing that seems to be popular these days.
>sometimes everyone else gets paralyzed with indecision and can’t even get started.
I once worked on a project where exactly that happened, and I view it as one of my biggest failures of my career. I often wonder why I didn't just sit down one day and type int main( ... and just get on with it.
In the end the project got canned and both contractors terminated early, so I made sure that never happened again.
I once worked on a project where exactly that happened, and I view it as one of my biggest failures of my career. I often wonder why I didn't just sit down one day and type int main( ... and just get on with it.
In the end the project got canned and both contractors terminated early, so I made sure that never happened again.
I like FactoryFactory devs, they are even worse than 0.1x. After some time every other team member who touches their code becomes 0.5x.
I'm not claiming to be a 10x developer or anything like that, but I have a related story to share:
Once I had to tweak a 7000 line signal generator (ie spits out wav files) written in Java. It had a mind boggling structure, and I'm sure whoever wrote it was a mad genius of some kind.
I rewrote it in less than 100 lines of Python, where each signal primitive was basically a few lines of code max, which you can functionally combine.
Since this new program was not even 100 lines long, we were able to do a LOT more with it, and in a super flexible manner.
It's one of my happiest accomplishments.
Once I had to tweak a 7000 line signal generator (ie spits out wav files) written in Java. It had a mind boggling structure, and I'm sure whoever wrote it was a mad genius of some kind.
I rewrote it in less than 100 lines of Python, where each signal primitive was basically a few lines of code max, which you can functionally combine.
Since this new program was not even 100 lines long, we were able to do a LOT more with it, and in a super flexible manner.
It's one of my happiest accomplishments.
And then you encounter the 10x programmer, who is not afraid to throw the bullshit code away and write it in a way that is easy to manage for other devs. I'd say this is really a more realistic example of a 10x programmer. Most programmers are just afraid of asking the "why" question and the actually acting if there is no good answer.
> while it's inherently a super-subjective metric, I would say that 10x programmers do exist
Even worse than super-subjective, it seems like people don't agree on the definition of "10x programmer".
Is that 10x value (code * code quality) produced per unit of work-time? Per brain cycle? Are you controlling for programmer experience, or domain knowledge, as [1] pointed out? Do you actually mean 10x, or is that a stand-in for "significantly more productive" with an unknown value? Do you include collaborative skills and working with a team, or even entirely base your definition off of that?
I'm both curious as to the exact definition you have in mind, and also trying to point out the more general issue so that others arguing past each other can realize that they have two different ideas in mind.
[1] https://news.ycombinator.com/item?id=28797923
Even worse than super-subjective, it seems like people don't agree on the definition of "10x programmer".
Is that 10x value (code * code quality) produced per unit of work-time? Per brain cycle? Are you controlling for programmer experience, or domain knowledge, as [1] pointed out? Do you actually mean 10x, or is that a stand-in for "significantly more productive" with an unknown value? Do you include collaborative skills and working with a team, or even entirely base your definition off of that?
I'm both curious as to the exact definition you have in mind, and also trying to point out the more general issue so that others arguing past each other can realize that they have two different ideas in mind.
[1] https://news.ycombinator.com/item?id=28797923
Have a 1 year project. One side is a team of 10 developers with 5 years of experience in the field. Other side is 1 developer with 5 years of experience in the field. Do you think it is unreasonable that there is any developer that could beat the team in that situation? The quality expectations for both are the same, so no shortcuts.
I don't find that unreasonable at all, most teams are very unproductive. So what I'd call it is "A 10x developer is a developer who can outperform a typical team of 10 developers".
I don't find that unreasonable at all, most teams are very unproductive. So what I'd call it is "A 10x developer is a developer who can outperform a typical team of 10 developers".
For me, it's definitely "a stand-in for "significantly more productive" with an unknown value". Neither the input nor the output can be properly quantified, and we don't really know the full set of variables to control for, and it inevitably runs into serious questions of inequality, SES, and background that are likely to make people even more cross.
I see it as more of a compliment. Nobody should be seriously and unironically calling themselves a 10x programmer, it should be bestowed by other people.
I see it as more of a compliment. Nobody should be seriously and unironically calling themselves a 10x programmer, it should be bestowed by other people.
People are often willing to sacrifice any amount of development velocity to avoid being seen to make mistakes.
IMO that attitude never makes sense - it can make sense to avoid certain mistakes at all costs (self-driving car), but it never makes sense to try to avoid blame for them (company refuses to admit their car isn't good enough).
This is a problem of culture, not individuals.
Does the culture at a company openly admit mistakes, try to learn from them, and put systemic fixes in place to address them, or do they punish people for mistakes?
If the latter, you end up with nobody admitting to mistakes and a terrible culture, it's not about the people, it's about the situation you have put them in and the incentives given to them.
IMO that attitude never makes sense - it can make sense to avoid certain mistakes at all costs (self-driving car), but it never makes sense to try to avoid blame for them (company refuses to admit their car isn't good enough).
This is a problem of culture, not individuals.
Does the culture at a company openly admit mistakes, try to learn from them, and put systemic fixes in place to address them, or do they punish people for mistakes?
If the latter, you end up with nobody admitting to mistakes and a terrible culture, it's not about the people, it's about the situation you have put them in and the incentives given to them.
No, it's also a matter of personality. One manager used to urge me to do things in half the time at 90% of quality, and stop chasing the remaining 10% at such high opportunity cost. To this day, I try, but it's hard to overcome a natural, obsessive tendency.
> it can make sense to avoid certain mistakes at all costs (self-driving car), but it never makes sense to try to avoid blame for them
Eh? As you say, it's a culture thing, and the culture of a lot of humans is that the mistake only matters if you take blame for it. Plenty of people and organisations put more effort into avoiding blame for things than the thing itself.
Blame-free culture is great, but it has to be actively maintained.
Eh? As you say, it's a culture thing, and the culture of a lot of humans is that the mistake only matters if you take blame for it. Plenty of people and organisations put more effort into avoiding blame for things than the thing itself.
Blame-free culture is great, but it has to be actively maintained.
Plenty of people and organisations put more effort into avoiding blame for things than the thing itself.
Blame is pointless (particularly directed at humans), learning from mistakes is invaluable. What I'm saying is it is a terrible mistake to put more effort into avoiding blame than avoiding mistakes.
Blame-free culture is great, but it has to be actively maintained.
I agree.
Blame is pointless (particularly directed at humans), learning from mistakes is invaluable. What I'm saying is it is a terrible mistake to put more effort into avoiding blame than avoiding mistakes.
Blame-free culture is great, but it has to be actively maintained.
I agree.
> People are often willing to sacrifice any amount of development velocity to avoid being seen to make mistakes.
I'm living this at the moment and it's driving me crazy.
I'm living this at the moment and it's driving me crazy.
Maybe 0.4x and 3x programmers exist, and so when you introduce a little noise it's easy to perceive as a 10x difference at certain points in time.
> I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all.
I've been a developer for 15 years... anybody else feel like the further they get into their career, the more they want to keep their opinions to themselves?
I feel like as a junior dev I had way stronger opinions and I was a lot more vocal about them. Now, I still have opinions, but I've learned that nobody gives a damn about my opinions so I just keep them to myself.
I've been a developer for 15 years... anybody else feel like the further they get into their career, the more they want to keep their opinions to themselves?
I feel like as a junior dev I had way stronger opinions and I was a lot more vocal about them. Now, I still have opinions, but I've learned that nobody gives a damn about my opinions so I just keep them to myself.
No, I've been doing this for ~30 years now and I have really strong unpopular opinions on things. Like:
- NPM/Yarn/Gems etc is a disaster waiting to happen. Having lots of dependencies is a security nightmare and a maintenance issue. As these projects get dropped by their original maintainers we'll start seeing more supply-side attacks and more vulnerabilities going unpatched.
- Docker is a great solution for a specific problem. But I don't think it needs to be used for everything. Same for K8s. Same for microservices architecture.
- Simplicity is an important design goal for all systems. Complexity breeds bugs. Boilerplate is simple. DRY can be taken too far. Every abstraction layer leaks at least a little. "clever" code is usually not what is needed for reliable software.
I expect to get downvoted because these are unpopular opinions. But I'm used to arguing about them. It's always interesting to discuss.
- NPM/Yarn/Gems etc is a disaster waiting to happen. Having lots of dependencies is a security nightmare and a maintenance issue. As these projects get dropped by their original maintainers we'll start seeing more supply-side attacks and more vulnerabilities going unpatched.
- Docker is a great solution for a specific problem. But I don't think it needs to be used for everything. Same for K8s. Same for microservices architecture.
- Simplicity is an important design goal for all systems. Complexity breeds bugs. Boilerplate is simple. DRY can be taken too far. Every abstraction layer leaks at least a little. "clever" code is usually not what is needed for reliable software.
I expect to get downvoted because these are unpopular opinions. But I'm used to arguing about them. It's always interesting to discuss.
Those seem like pretty unobjectionable opinions. Have an upvote!
You want a controversial opinion (on HN), how about mine:
"It's not always a good tradeoff to throw something under the bus to save developer time."
So many important things are routinely sacrificed at the altar of developer speed and comfort, app runtime performance being the big one. It's used to justify all sorts of crazy things we do in modern software to ship faster, but so hard to push back on because developers are expensive and software needs to be done yesterday.
Some things are worth giving up so that developers can move faster, but I argue not everything. Need to evaluate case by case.
You want a controversial opinion (on HN), how about mine:
"It's not always a good tradeoff to throw something under the bus to save developer time."
So many important things are routinely sacrificed at the altar of developer speed and comfort, app runtime performance being the big one. It's used to justify all sorts of crazy things we do in modern software to ship faster, but so hard to push back on because developers are expensive and software needs to be done yesterday.
Some things are worth giving up so that developers can move faster, but I argue not everything. Need to evaluate case by case.
Have an upvote yourself! yes, totally agree.
Like Wordpress optimises for edit functionality, at the expense of render speed. Most of the internet is now slow, optimised for Susan From Marketing because they don't know how to edit HTML.
Same for Ruby/Rails, same for Python/Django, same for Node/whatever. Web pages render slower so that whoever edits them can do that faster.
This isn't good.
Like Wordpress optimises for edit functionality, at the expense of render speed. Most of the internet is now slow, optimised for Susan From Marketing because they don't know how to edit HTML.
Same for Ruby/Rails, same for Python/Django, same for Node/whatever. Web pages render slower so that whoever edits them can do that faster.
This isn't good.
Last month I ran into The Principle of Least Power, and it's grabbed me and the more I think about it, the more it expands. I think all of your statements lines up with this principle, except one.
Containers are a simpler solution than Operating Systems. Operating Systems is a tightly bound non-simplistic system that breeds complexity, just as you state npm does. Because those interfaces are tightly bound, we were not about to build on top of them. Almost immediately after we got Docker, we got K8s. Once we got Docker we got the ability to manage these things at a higher level. That's the mark of a more simple solution.
Are there things that Docker can't do? Are there things that require so much performance that Docker can't handle it? Only then should you step back to the more powerful solution.
Not to say that there aren't problems with Docker. Dockerfiles have a lot to improve. Running containers has a lot to improve.
I think. I'm still at a state where I might change my mind. It's partially why I'm posting this.
[0]: https://blog.codinghorror.com/the-principle-of-least-power/
Containers are a simpler solution than Operating Systems. Operating Systems is a tightly bound non-simplistic system that breeds complexity, just as you state npm does. Because those interfaces are tightly bound, we were not about to build on top of them. Almost immediately after we got Docker, we got K8s. Once we got Docker we got the ability to manage these things at a higher level. That's the mark of a more simple solution.
Are there things that Docker can't do? Are there things that require so much performance that Docker can't handle it? Only then should you step back to the more powerful solution.
Not to say that there aren't problems with Docker. Dockerfiles have a lot to improve. Running containers has a lot to improve.
I think. I'm still at a state where I might change my mind. It's partially why I'm posting this.
[0]: https://blog.codinghorror.com/the-principle-of-least-power/
yeah, no. Containers run on top of Operating Systems. They inherit everything that the underlying OS has. They're not simpler, they're actually more complex, but pretend to be simpler.
What you're thinking of is Unikernels. These are simpler than OS's. And yes, Unikernels are a good alternative to containers for a lot of applications we currently use containers for.
What you're thinking of is Unikernels. These are simpler than OS's. And yes, Unikernels are a good alternative to containers for a lot of applications we currently use containers for.
Appreciate this response. Thanks. Totally agree now that I see your perspective.
> Simplicity is an important design goal for all systems. Complexity breeds bugs
Counterpoint: some problem-spaces are inherently complex; most problem-spaces have hidden complexity. Complexity cannot be removed, it can only be moved up or down your tech stack, and obviously, you can needless add more complexity.
Docker, K8s and the like are perfectly fine when they fall below your project's complexity floor - they are good place to shift your complexity to as they are battle-tested and well-documented. If your projects complexity floor is lower than docker/k8s, then integrating them will just increase your solutions complexity needlessly.
Counterpoint: some problem-spaces are inherently complex; most problem-spaces have hidden complexity. Complexity cannot be removed, it can only be moved up or down your tech stack, and obviously, you can needless add more complexity.
Docker, K8s and the like are perfectly fine when they fall below your project's complexity floor - they are good place to shift your complexity to as they are battle-tested and well-documented. If your projects complexity floor is lower than docker/k8s, then integrating them will just increase your solutions complexity needlessly.
Totally agree. Some problems are complex. However, that does not mean that the code needs to be complex. Simplicity should still be a design goal even if the problem space is complex.
I don't really agree that there is a "complexity floor". Things can always be made simpler, up to the limit of the problem space. As you say, complexity can always be added. Most projects do this. Very few stick to the minimum complexity. The complexity floor for most projects is therefore way below where that line is normally drawn.
I don't really agree that there is a "complexity floor". Things can always be made simpler, up to the limit of the problem space. As you say, complexity can always be added. Most projects do this. Very few stick to the minimum complexity. The complexity floor for most projects is therefore way below where that line is normally drawn.
> up to the limit of the problem space.
This is the key. One of the harder things to do in software design is to find a representation of the problem that gets closest to that complexity floor. It's often not obvious.
This is the key. One of the harder things to do in software design is to find a representation of the problem that gets closest to that complexity floor. It's often not obvious.
> I expect to get downvoted because these are unpopular opinions.
Well, not really. These opinions are very common among my peers. We sold multi-million dollar transformation projects with the stated goal of making things simpler and easier to use and understand.
Well, not really. These opinions are very common among my peers. We sold multi-million dollar transformation projects with the stated goal of making things simpler and easier to use and understand.
Fellow 30+'er here...
You had me at
> - Simplicity is an important design goal for all systems. Complexity breeds bugs. Boilerplate is simple. DRY can be taken too far. Every abstraction layer leaks at least a little. "clever" code is usually not what is needed for reliable software.
Nuff said.
You had me at
> - Simplicity is an important design goal for all systems. Complexity breeds bugs. Boilerplate is simple. DRY can be taken too far. Every abstraction layer leaks at least a little. "clever" code is usually not what is needed for reliable software.
Nuff said.
There are unpopular opinions? It’s pretty shared in the industry.
Quite brave to share these unpopular opinions like “npm is bad” on HN.
Same here. Been working professionally as a dev for 20 years and each year I care less and less about changing other people’s minds about architecture.
Just this year I was working with another team that wanted to move to an architecture that I thought was overengineered for their specific problems. They shared with me an article about some company that was using it. I explained my experiences with such a pattern and where the pitfalls were, hoping their lead dev would think about it or discuss the pros and cons. Well, it was met with silence. They went ahead with their plan anyway.
Too many times that’s happened in the work world, so at least now I don’t invest a lot of effort into changing minds. Best advice
I’ve learned these last few years is don’t tie yourself to your work. If you’re opinionated about how to do things because you love designing software, that’s great, but you’re setting yourself up to be disappointed by how things really get done.
Just this year I was working with another team that wanted to move to an architecture that I thought was overengineered for their specific problems. They shared with me an article about some company that was using it. I explained my experiences with such a pattern and where the pitfalls were, hoping their lead dev would think about it or discuss the pros and cons. Well, it was met with silence. They went ahead with their plan anyway.
Too many times that’s happened in the work world, so at least now I don’t invest a lot of effort into changing minds. Best advice
I’ve learned these last few years is don’t tie yourself to your work. If you’re opinionated about how to do things because you love designing software, that’s great, but you’re setting yourself up to be disappointed by how things really get done.
All said and done I think you tend to learn that opinions are just that - opinions. Often a team doesn't need more opinions, they need to make decisions and come to consensus, so helping them decide on which opinion is best is more important than bringing yet another complicating-but-not-discussion-progressing vote to the table
It comes in waves. I'm in my 22nd year of developing software and I can reflect on times when I felt incredibly confident and didn't shy away from sharing my opinions, and other times when I felt like it was better to remain silent because I had things to learn from others.
There are times for both speaking and listening in our careers; as I've progressed further in my career I have felt it is often more valuable to exercise active listening.
There are times for both speaking and listening in our careers; as I've progressed further in my career I have felt it is often more valuable to exercise active listening.
I pick my battles pretty judiciously these days. I've learned that a huge amount of what people talk about doing ends up going nowhere anyway, so why burn the energy and look disagreeable? A lot of people with bad ideas also aren't very good at getting things done.
I think that is also because as a Junior one thinks that he should have opinions and be vocal about them and be right to further their career or to become Senior/Manager/Leader. Just like getting good grades in school you would have to put your hand up and tell that smart thing to the class/teacher.
After couple of years people realize that just having opinion and being vocal about it does not make one a Senior/Manager/Leader. There is much more to it and one learns about it on the job.
After couple of years people realize that just having opinion and being vocal about it does not make one a Senior/Manager/Leader. There is much more to it and one learns about it on the job.
Junior dev: Let's use this amazing algo I learned in school!
Senior dev: This won't work but it's no use explaning why since they've made up their minds (as have I).
Senior dev: This won't work but it's no use explaning why since they've made up their minds (as have I).
I got dinged in a 360 review by peers for not advocating for my views more.
I feel that if I present what I think we should do, and why I think it's the best alternative, I shouldn't have to get into a shouting match or even a debate. I don't take it personally if people disagree with me.
If I've got the best ideas and my managers are ignoring them for the loudest ideas, that's on them, not me.
I feel that if I present what I think we should do, and why I think it's the best alternative, I shouldn't have to get into a shouting match or even a debate. I don't take it personally if people disagree with me.
If I've got the best ideas and my managers are ignoring them for the loudest ideas, that's on them, not me.
Maybe they are pissed that they cant drag you in the failures by saying "even X had the same opinion..."
Most people mostly care about his/her own opinions, and others opinions only insofar as they reflect on himself/herself (even though of course the others are also thinking about themselves mostly), we're hopelessly self-involved creatures like that. Nonetheless there is inertia and subtle shifts that can come from sharing them, and though it may often feel like coming up against a brick wall if you look in the right way you'll see the bricks may be aligned a bit differently, and you can trace some of those differences to opinions you may have expressed.
As always the wise approach is probably somewhere in the middle, in this case choosing your battles. You don't have to voice every opinion, but you shouldn't be silent if you have a strong and well-formed opinion about something important.
As always the wise approach is probably somewhere in the middle, in this case choosing your battles. You don't have to voice every opinion, but you shouldn't be silent if you have a strong and well-formed opinion about something important.
Having opinions is good, but only if they’re genuinely informed opinions and everyone is willing to disagree and commit.
I’ve worked with too many people who think that their opinions are their identity and defended them as such. A difference of opinions shouldn’t become an excuse to go to war with your coworkers or argue endlessly instead of getting things done.
One of my worst work experiences was with a team of developers who were old friends from a college debate team. We could never have any productive discussions because they entered every conversation intent on winning instead of having an honest, productive conversation.
The best engineers I’ve worked with have had strong opinions but have also been happy and willing to go a different way if that’s what the team decides as a whole.
I’ve worked with too many people who think that their opinions are their identity and defended them as such. A difference of opinions shouldn’t become an excuse to go to war with your coworkers or argue endlessly instead of getting things done.
One of my worst work experiences was with a team of developers who were old friends from a college debate team. We could never have any productive discussions because they entered every conversation intent on winning instead of having an honest, productive conversation.
The best engineers I’ve worked with have had strong opinions but have also been happy and willing to go a different way if that’s what the team decides as a whole.
For me it's more a matter of putting those opinions into perspective. Example: I still highly value good API design but I'm not getting into debates anymore if an endpoint isn't RESTful or 100% consistent with every other endpoint. It's often just not that important at the end of the day.
I mostly express opinions about things than affect my productivity. I don't care about npm vs yarn. It doesn't affect how I work. But I care a lot about not having excessively firm lint rules because they slow down my coding.
It's the same in any area of life and is called maturity.
The longer you are in a career, the more you realize opinions are one of those things that always change (and should). Strong opinions weakly held
What a depressing reaction to adversity. An alternative reaction is to try and figure out why nobody cared, and get better at expressing yourself in ways that people will care.
"Interviews are almost worthless for telling how good of a team member someone will be"
Just like "avoid the 0.1x programmers", interviews are for weeding out the really bad team mates. They aren't for finding the best ones.
For instance, I and a female programmer do the interviews. During one interview, my coworker kept asking questions of the candidate, and he would not look at her when he talked. He would actually talk to me instead while answering her questions.
My first through was that he was misogynistic, which is an automatic disqualification. But even if he was just shy, he's going to have to work with her daily for the first few months, and be in meetings with her for the entire time he worked there.
That's an extreme example, but there were plenty of instances where we were looking for the best candidate, and the interview made the decision easier when the code hadn't. We can only hire 1 candidate, and we have to do what we can to pick the one that will do the best work and get along best with the team.
That's what interviews are for.
Just like "avoid the 0.1x programmers", interviews are for weeding out the really bad team mates. They aren't for finding the best ones.
For instance, I and a female programmer do the interviews. During one interview, my coworker kept asking questions of the candidate, and he would not look at her when he talked. He would actually talk to me instead while answering her questions.
My first through was that he was misogynistic, which is an automatic disqualification. But even if he was just shy, he's going to have to work with her daily for the first few months, and be in meetings with her for the entire time he worked there.
That's an extreme example, but there were plenty of instances where we were looking for the best candidate, and the interview made the decision easier when the code hadn't. We can only hire 1 candidate, and we have to do what we can to pick the one that will do the best work and get along best with the team.
That's what interviews are for.
> During one interview, my coworker kept asking questions of the candidate, and he would not look at her when he talked.
Or maybe he just thought she looked hot, and was afraid of appearing to be ogling her too much. Sometimes people fuck up by trying too hard not to fuck up.
Or maybe he just thought she looked hot, and was afraid of appearing to be ogling her too much. Sometimes people fuck up by trying too hard not to fuck up.
I've been developing software for decades and here's the most important thing I've learned: systems will be around running for far longer than you ever thought possible, even when you allowed for systems being around for far longer than you thought possible!
Keeping that in mind, I'm continually amazed at the number of developers who just love complexity. Don't get me wrong, they all profess to strive for simplicity but their work betrays them. They just love intricate dances carefully coordinated across several components, never minding how anyone 5, 10, 15 or 20 years down the road will ever comprehend this madness or how it will ever be maintained without incurring exorbitant costs.
I religiously adhere to the KISS principle - Keep It Stupid Simple. Once you think it's simple look for ways to make it even more simple. Think about operations failing at the worst time of day possible on the worst possible day of the year - how will you quickly find and resolve the issue? What if it's a new hire who gets the call? I'm just amazed at how developers gloss over this, all while bitching about the "spaghetti code" they inherited. It boggles the mind.
Keeping that in mind, I'm continually amazed at the number of developers who just love complexity. Don't get me wrong, they all profess to strive for simplicity but their work betrays them. They just love intricate dances carefully coordinated across several components, never minding how anyone 5, 10, 15 or 20 years down the road will ever comprehend this madness or how it will ever be maintained without incurring exorbitant costs.
I religiously adhere to the KISS principle - Keep It Stupid Simple. Once you think it's simple look for ways to make it even more simple. Think about operations failing at the worst time of day possible on the worst possible day of the year - how will you quickly find and resolve the issue? What if it's a new hire who gets the call? I'm just amazed at how developers gloss over this, all while bitching about the "spaghetti code" they inherited. It boggles the mind.
In 2017 I had someone call me and say "the system's broken". I knew who it was, but didn't know what they were referring to. Turns out it was a web application I'd put together in 2003. 14+ years later, it wasn't working, and... they needed help.
I went spelunking a bit in my own code, cursing the jerk who built some of it, praising the genius who put in other parts, remembering cutting certain corners to get home for dinner on time, etc.
Having to support anything 10-15-20 years down the line gives you a different perspective on maintenance and simplicity that I don't think you can quite ever really comprehend beforehand.
I went spelunking a bit in my own code, cursing the jerk who built some of it, praising the genius who put in other parts, remembering cutting certain corners to get home for dinner on time, etc.
Having to support anything 10-15-20 years down the line gives you a different perspective on maintenance and simplicity that I don't think you can quite ever really comprehend beforehand.
Speaking of iteration, iterating over the most popular replies to this tells me that the points which hit home enough to drive engagement are replies to the effect of:
1) "No, my 37 day interview process is good, actually."
2) "Rails sucks"
3) "Making a thing people would want to use is a bad idea."
4) (two long threads) "The 10x programmer exists, I saw him once at a con."
5) "No one cares what anyone else thinks."
HN really does represent the finest that the largest corporations have to offer. The proof is in the pudding.
1) "No, my 37 day interview process is good, actually."
2) "Rails sucks"
3) "Making a thing people would want to use is a bad idea."
4) (two long threads) "The 10x programmer exists, I saw him once at a con."
5) "No one cares what anyone else thinks."
HN really does represent the finest that the largest corporations have to offer. The proof is in the pudding.
There's also a path-dependent local optimisation aspect to HN comment threads. All things equal, threads that are higher up the page during the right time window get more eyeballs and more engagement, which might encourage people to hang their replies off the currently-popular thread. If we reran the "experiment" under essentially the same conditions we might find that a different bunch of responses get the most engagement.
It's still reflective of reality though!
If I know one thing from working for large corporations, it's that whatever is talked about the most will never change.
If I know one thing from working for large corporations, it's that whatever is talked about the most will never change.
Aand there’s a segue back to the current discussion. There was a thread about “people don’t actually like innovation”. :)
> 13. Your data is the most important part of your system
+1. Most (including me) internalise, if at all, this lesson the hard way through trial and error.
I wish this is was taught in colleges. Software is mostly about manipulating data and it's a pity that not much is taught in a structured manner about building systems around data.
I expected Domain Driven Design (DDD) would address this but it doesn't.
+1. Most (including me) internalise, if at all, this lesson the hard way through trial and error.
I wish this is was taught in colleges. Software is mostly about manipulating data and it's a pity that not much is taught in a structured manner about building systems around data.
I expected Domain Driven Design (DDD) would address this but it doesn't.
Thirty years ago at my first job, a senior dev told me "2% of what we do is interesting. 98% is sort, select, sum."
(I think then that was more or less true, but the numbers in the industry as a whole have gotten a lot better in the past 30 years. And I've gotten better jobs.)
(I think then that was more or less true, but the numbers in the industry as a whole have gotten a lot better in the past 30 years. And I've gotten better jobs.)
It is taught. And then you enter the real world and you find that everyone just ignores this shit whenever it is convenient (and unsurprisingly the data is garbage).
Agree. This is one hill I would choose to die on, data is so much more important and valuable than code.
Database design - normal form, relations, etc - was a major part of my education. Surely that's not unusual?
Database design - normal form, relations, etc - was a major part of my education. Surely that's not unusual?
> 1. I still don’t know very much
> “How can you not know what BGP is?”
I learned a while ago that answering someone who asks you "What is X?" and replying with a phrase similar to the above is probably one of the worst ways to broach the subject. It comes off as questioning the person's intelligence/knowledge.
Instead try to see it as a teachable moment. If it is something you think is cool and/or you are passionate about, you should be excited that you can show your friend/coworker something really cool. ie: "I've never seen Rick and Morty", "You are absolutely going to love that show. I know what you will be binge watching this weekend!"
Anyhow, to put it bluntly, don't be a dick about it.
> “How can you not know what BGP is?”
I learned a while ago that answering someone who asks you "What is X?" and replying with a phrase similar to the above is probably one of the worst ways to broach the subject. It comes off as questioning the person's intelligence/knowledge.
Instead try to see it as a teachable moment. If it is something you think is cool and/or you are passionate about, you should be excited that you can show your friend/coworker something really cool. ie: "I've never seen Rick and Morty", "You are absolutely going to love that show. I know what you will be binge watching this weekend!"
Anyhow, to put it bluntly, don't be a dick about it.
I used to be pretty bad about this, and I honestly didn't realize I was doing it until someone pointed it out.
I hate when people do it to me, so no idea why I was doing it right back.
I hate when people do it to me, so no idea why I was doing it right back.
Amazingly, I agree with every single point.
>> Nobody asks “why” enough
This point is the most important IMO. It's so common for people to do things without asking themselves why they're doing it. Every line of code should fulfill a clear purpose. You want to avoid writing code which is difficult to explain to a non-technical person.
>> People don’t really want innovation... If you believe in what you’re doing, and know it will really improve things, then brace yourself for a long battle.
This sounds ridiculous at a glance, but it 100% matches my own experience in pretty much every company and project I've ever worked on.
It applies to everything; jobs, getting funding. Nobody wants to see real innovation and nobody wants to see real talent. If you're too good as a developer and innovate too much, developers who work for big companies will get jealous and they will reject you. If you're very good, you need to pretend to be mediocre and above all; compliant.
>> Nobody asks “why” enough
This point is the most important IMO. It's so common for people to do things without asking themselves why they're doing it. Every line of code should fulfill a clear purpose. You want to avoid writing code which is difficult to explain to a non-technical person.
>> People don’t really want innovation... If you believe in what you’re doing, and know it will really improve things, then brace yourself for a long battle.
This sounds ridiculous at a glance, but it 100% matches my own experience in pretty much every company and project I've ever worked on.
It applies to everything; jobs, getting funding. Nobody wants to see real innovation and nobody wants to see real talent. If you're too good as a developer and innovate too much, developers who work for big companies will get jealous and they will reject you. If you're very good, you need to pretend to be mediocre and above all; compliant.
Mmm, in my experience, it’s more that people don’t believe that something truly valuable to them comes packaged in your arrogance, brilliance, or effortlessness.
They’re so accustomed to those things being signs of assholes, or reasons to feel inadequate, that they resist looking at what’s being delivered.
The OP’s point about bracing for a long battle means that truly persuading others is not just about making the amazing thing. It’s about having the humility to weather their resistance and care harder than they do about the merits of the way. And patiently, tenaciously demonstrating the value instead of doing anything that seems like boasting about it. Then they’ll stop ignoring you, and you’ll both win.
They’re so accustomed to those things being signs of assholes, or reasons to feel inadequate, that they resist looking at what’s being delivered.
The OP’s point about bracing for a long battle means that truly persuading others is not just about making the amazing thing. It’s about having the humility to weather their resistance and care harder than they do about the merits of the way. And patiently, tenaciously demonstrating the value instead of doing anything that seems like boasting about it. Then they’ll stop ignoring you, and you’ll both win.
I'm not at all arrogant in real life.
My last boss even told me that I don't stand up for myself enough. Besides, I didn't even say it was about me and merely brought it up to make a point.
Imagine constantly improving yourself for 15 years, then after 15 years, everyone you work with only gives you positive feedback and everyone wants to be on your team. You even launch open source projects which get thousands of stars on GitHub... You know you're good because there is no other explanation and nobody helped you and you have 0 meaningful industry connections and come from a modest background... but somehow you struggle to even land a first technical interview at a big tech corporation in spite of having the required university degree. That's my situation, so forgive me if I sound like an asshole on this anonymous website where I can finally vent my frustration.
Imagine constantly improving yourself for 15 years, then after 15 years, everyone you work with only gives you positive feedback and everyone wants to be on your team. You even launch open source projects which get thousands of stars on GitHub... You know you're good because there is no other explanation and nobody helped you and you have 0 meaningful industry connections and come from a modest background... but somehow you struggle to even land a first technical interview at a big tech corporation in spite of having the required university degree. That's my situation, so forgive me if I sound like an asshole on this anonymous website where I can finally vent my frustration.
No offense, and I mean this, but from what you've said I wonder if you suffer from Nice Guy Syndrome.
It is often referred to in the context of dating, but applies to work as well.
There is a book called "No More Mr Nice Guy" that you might find interesting.
It is often referred to in the context of dating, but applies to work as well.
There is a book called "No More Mr Nice Guy" that you might find interesting.
One person tells me my problem is that I might be an asshole and you tell me my problem might be that I'm too nice... Why is it so far fetched to suggest that maybe the problem is not me? What if the problem is that most people in power have impostor syndrome and they feel jealous and/or guilty when they see a competent person who didn't achieve as much as they did. It makes them doubt their own success narrative. People don't want to be reminded how lucky they are; as an employee, I would be a walking reminder of that. That's the best explanation I can come up with to explain my experience in recent years why I struggle to find opportunities. I had many more opportunities 5 years ago back when I was far less skilled.
CTO types wants to be mentors to starry-eyed juniors, they don't want to improve themselves anymore, they think they're already as good as they can be, they don't want to be schooled by some low rank person.
CTO types wants to be mentors to starry-eyed juniors, they don't want to improve themselves anymore, they think they're already as good as they can be, they don't want to be schooled by some low rank person.
> One person tells me my problem is that I might be an asshole and you tell me my problem might be that I'm too nice...
No, what the GP actually said was
>> I wonder if you suffer from Nice Guy Syndrome.
That's not the same thing. Because sufferers from Nice Guy Syndrome only actually think they're being "nice", but they're being so in ways or from motives that actually make them, in practice, assholes. (Sorry if that's a distortion or oversimplification of the book GP suggested; I recently skimmed through it, but didn't actually get to read the whole thing.)
> Why is it so far fetched to suggest that maybe the problem is not me?
Because usually, when one person has trouble with everyone else, and goes "What's wrong with all of them?!?", Ockham's Razor suggests the simpler hypothesis, "Maybe there's something wrong with you?", lies nearer to hand.
All in all, I'd suggest you try to get that book and read it more thoroughly than I did. (And so should I.)
No, what the GP actually said was
>> I wonder if you suffer from Nice Guy Syndrome.
That's not the same thing. Because sufferers from Nice Guy Syndrome only actually think they're being "nice", but they're being so in ways or from motives that actually make them, in practice, assholes. (Sorry if that's a distortion or oversimplification of the book GP suggested; I recently skimmed through it, but didn't actually get to read the whole thing.)
> Why is it so far fetched to suggest that maybe the problem is not me?
Because usually, when one person has trouble with everyone else, and goes "What's wrong with all of them?!?", Ockham's Razor suggests the simpler hypothesis, "Maybe there's something wrong with you?", lies nearer to hand.
All in all, I'd suggest you try to get that book and read it more thoroughly than I did. (And so should I.)
> developers who work for big companies will get jealous and they will reject you. If you're very good, you need to pretend to be mediocre and above all; compliant.
To add to what another poster said, it's not jealousy.
Big companies move slow because generally, to get big, they had to be successful (to some extent) and changing too much all at once is a risk that the bureaucracy isn't always comfortable with.
One of my old managers (I work in "enterprise") used to say things like "the efficiencies that this solution will bring the company..." which was just a euphemism for more folks getting laid-off (happened all the time, and glassdoor was full of warnings about this) or more jobs being shipped to our offshore units or even down-sizing in our offshore units.
I think it's reasonable, at least in the US, where healthcare & retirement & welfare is so tightly coupled with employment, for folks in big companies to be wary of innovation. They might want their job to be easier, sure, but too easy and they could be out of a job (for example, if the workload that previously took 5 people can now be managed by 2 or 3).
We're building software for people.
To add to what another poster said, it's not jealousy.
Big companies move slow because generally, to get big, they had to be successful (to some extent) and changing too much all at once is a risk that the bureaucracy isn't always comfortable with.
One of my old managers (I work in "enterprise") used to say things like "the efficiencies that this solution will bring the company..." which was just a euphemism for more folks getting laid-off (happened all the time, and glassdoor was full of warnings about this) or more jobs being shipped to our offshore units or even down-sizing in our offshore units.
I think it's reasonable, at least in the US, where healthcare & retirement & welfare is so tightly coupled with employment, for folks in big companies to be wary of innovation. They might want their job to be easier, sure, but too easy and they could be out of a job (for example, if the workload that previously took 5 people can now be managed by 2 or 3).
We're building software for people.
Maybe. It could be a fear of anybody who is talented enough and ambitious enough to potentially disrupt the pecking order within the company. Unfortunately, it feels like almost all the big companies are like this.
I think "jealous" is not a useful lens here. People reject innovation because genuinely changing the way the way they have to do things is painful even if the attempt fails, and will probably lead to some people losing their jobs if it succeeds.
I feel like once you’ve worked on a few projects the desire to “reinvent” the wheel is quickly destroyed. The main thing they never teach in school and you really can’t understand until your doing it is maintenance.
Projects are like a balancing act where you need to weigh the pros and cons of every choice and choose the best one. The hard part is being able to do that and do it in a reasonable amount of time.
Projects are like a balancing act where you need to weigh the pros and cons of every choice and choose the best one. The hard part is being able to do that and do it in a reasonable amount of time.
The difference between a senior engineer and a junior engineer to me is that a senior engineer knows how to evolve a system into the system that they want/need it to be. They don't just say "well, looks like we have to throw the whole thing out the window and use this other new shiny/rebuild it from scratch". The desire to reinvent is important to keep throughout your years as long as it is rooted in reason and in the best intentions of the team and company.
Riffing on that, more senior engineers better know how to evolve those systems (whether that is working with larger systems or working on people problems or working to support large customers, etc)
Riffing on that, more senior engineers better know how to evolve those systems (whether that is working with larger systems or working on people problems or working to support large customers, etc)
Whenever I've "started over", I've sometimes longed for going back to pre-existing stuff and evolving it. Sometimes, but not always. Whenever I've 'evolved' existing systems, I've almost always wish we'd started over (or some variation thereof).
Recent-ish project: holding on to multi-year old legacy data that was simply bad/broken (but was assumed to be good because it was barely used/examined), then requiring every single new feature to work flawlessly with broken data, ensuring that legacy customers 'never' hit an error (when 95% of them have not logged in in years). That's a candidate for 'rewrite from ground up' - you can keep an old system going in maintenance mode, build the archetypal "version 2", then decide if/when/how to migrate old data over...
Knowing that you can 'evolve' a system towards improvements and knowing when you should do that is another sign. Something may be technically possible, but the time/effort/cost can outweigh whatever benefits there may be.
Recent-ish project: holding on to multi-year old legacy data that was simply bad/broken (but was assumed to be good because it was barely used/examined), then requiring every single new feature to work flawlessly with broken data, ensuring that legacy customers 'never' hit an error (when 95% of them have not logged in in years). That's a candidate for 'rewrite from ground up' - you can keep an old system going in maintenance mode, build the archetypal "version 2", then decide if/when/how to migrate old data over...
Knowing that you can 'evolve' a system towards improvements and knowing when you should do that is another sign. Something may be technically possible, but the time/effort/cost can outweigh whatever benefits there may be.
One of the things I have noticed lately is that people who change jobs often have completely different perception of the industry as compared to people who don't change that often. Both of the strategies have pros and cons. For instance people who change jobs quite often don't seem to care alot about the business per say they seem to emphasis on the technology more as compared to people who stick to one org. However, people who have changed job quite often, seem to have seen broad variety to problem sets and always bring fresh new pair of eyes to existing business. People who stick to the same org, do tend to become very conservative but it often good for the business as people not quitting brings lot of stability. Again, it really depends on situation, person to person. In general this is my observation.
If you are good in tech that is transferrable skill.
Being good at what your company does is often not that useful anywhere else and usually you get non-compete so you cannot really use it.
If someone is a dev it is better to switch jobs and sharpen your "software stack" skills than waste time on learning whatever business needs. Of course there is some level that one has to understand the business they make code for - but don't overdo it.
Being good at what your company does is often not that useful anywhere else and usually you get non-compete so you cannot really use it.
If someone is a dev it is better to switch jobs and sharpen your "software stack" skills than waste time on learning whatever business needs. Of course there is some level that one has to understand the business they make code for - but don't overdo it.
You can always argue that every 5 years there is shift, sharpening your software stack might be a continuous process as compared to being a domain expert
If you stay put, you start to believe your own PR. IF you move around you see that most of the things people fixate in aren’t that important or critical, and meanwhile some of the things they refuse to look at are and probably should be fixated on. The apparent differences in priority aren’t necessarily bad or even indicate less concern. They just aren’t as interested in the pet concerns of some verticals that are not universal.
If you’ve been at the same place 5-10 years you have seen only a few rodeos, as it were. Their speculations on how things will play out are based largely on hope, not experience.
If you’ve been at the same place 5-10 years you have seen only a few rodeos, as it were. Their speculations on how things will play out are based largely on hope, not experience.
5. Software is a means to an end
Yes, yes and yes. Many times we lose sight of the fact our job is to support the business (money-making) functions of the company. The software itself isn't the end-all-be-all point of what the organization does unless you write open source software all day long and survive off donations. My gut tells me that most departments are like this and sees themselves as the core of the company but I think software engineers think of themselves more highly than most (and more highly than they should). A bit of humility would really help - myself included more than most probably.
I agree with a lot of what he says... A few points are a little off IMHO but I've only been doing this for a few more years than this gentleman. Perhaps I'll feel differently in a few more. :)
Yes, yes and yes. Many times we lose sight of the fact our job is to support the business (money-making) functions of the company. The software itself isn't the end-all-be-all point of what the organization does unless you write open source software all day long and survive off donations. My gut tells me that most departments are like this and sees themselves as the core of the company but I think software engineers think of themselves more highly than most (and more highly than they should). A bit of humility would really help - myself included more than most probably.
I agree with a lot of what he says... A few points are a little off IMHO but I've only been doing this for a few more years than this gentleman. Perhaps I'll feel differently in a few more. :)
In my 22+ years of work as an Engineer/Architect, I've found that:
1. Software development skill means nothing if the power goes out, always cultivate other skills and passions, those passions will drive you to develop more meaningful, functional, and well informed tools.
2. My resume never parses correctly on the job application, no matter how big the company is, and I'll always have to retype it over again.
3. The level of functionality on each company's web site job application tool tells you everything you need to know about the development quality and talent within each company.
1. Software development skill means nothing if the power goes out, always cultivate other skills and passions, those passions will drive you to develop more meaningful, functional, and well informed tools.
2. My resume never parses correctly on the job application, no matter how big the company is, and I'll always have to retype it over again.
3. The level of functionality on each company's web site job application tool tells you everything you need to know about the development quality and talent within each company.
>> resume never parses
Every time I rewrite my CV I always think, finally it's picture perfect. Next time I revisit it, because I'm looking for another job, I always think, who the F wrote this piece of crap.
I'm either slowly making progress or I'm running in circles.
Every time I rewrite my CV I always think, finally it's picture perfect. Next time I revisit it, because I'm looking for another job, I always think, who the F wrote this piece of crap.
I'm either slowly making progress or I'm running in circles.
I found a lot more success in the working world once I choose to just embrace the "normalcy" of certain things that routinely don't make sense in the working world, and to simply try to make what I can make work better.
The working world is really nonsensical and absurd if you ask me, but the end goal of doing a job for money that in turn allows me to do things that "make sense" to me is the payoff.
Self Sacrifice is sometimes necessary for success, but it is a finite resource, and can hurt or destroy you if not carefully applied (the simple equation)
A resume just needs to show the mountains you've climbed against the odds, without lamenting about the battle scars you got along the way... Resume formatting is really just fluff, that you don't need if they need you because you've proven that you can climb real mountains. :P
The working world is really nonsensical and absurd if you ask me, but the end goal of doing a job for money that in turn allows me to do things that "make sense" to me is the payoff.
Self Sacrifice is sometimes necessary for success, but it is a finite resource, and can hurt or destroy you if not carefully applied (the simple equation)
A resume just needs to show the mountains you've climbed against the odds, without lamenting about the battle scars you got along the way... Resume formatting is really just fluff, that you don't need if they need you because you've proven that you can climb real mountains. :P
> No one is going to tell you in an interview that they are going to be unreliable, abusive, pompous, or never show up to meetings on time. People might claim they have “signals” for these things…
I had a great interview with one of the FAANG companies. The technical interviews, 6 of them in a row!, felt more like they were wanting to see me fail spectacularly rather than focus on my approach of solving whiteboard problems. Still, I did more than average to get "pass" from them. But HR dropped me because she didn't like the answer to "what's your weakness?" question along the lines of - "I focus too much on job at hand to an extent that I struggle with work-life-balance and working on it. If I can overcome that and learn how to take breaks timely I might be more productive.". HR didn't like it because it was not one of the canned responses she was expecting ¯\_(ツ)_/¯
I had a great interview with one of the FAANG companies. The technical interviews, 6 of them in a row!, felt more like they were wanting to see me fail spectacularly rather than focus on my approach of solving whiteboard problems. Still, I did more than average to get "pass" from them. But HR dropped me because she didn't like the answer to "what's your weakness?" question along the lines of - "I focus too much on job at hand to an extent that I struggle with work-life-balance and working on it. If I can overcome that and learn how to take breaks timely I might be more productive.". HR didn't like it because it was not one of the canned responses she was expecting ¯\_(ツ)_/¯
>> I struggle with work-life-balance and working on it. If I can overcome that and learn how to take breaks timely I might be more productive.".
.. HR didn't like it because it was not one of the canned responses she was expecting ¯\_(ツ)_/¯
Just curious, how do you know that (a) you failed in HR (b) that it was this question and (c) for this reason?
I ask because it's unlikely that this was literally the feedback given you. Also, "I work too hard" does sound a bit canned.
>> The technical interviews, 6 of them in a row!, felt more like they were wanting to see me fail spectacularly rather than focus on my approach of solving whiteboard problems.
I do think this is more "in your head" that real. Nobody shows up to an interview wanting the other person to fail, but "how they solve whiteboard problems" isn't the goal either. It's more about - how does the person, think, collaborate, make tradeoffs and drives to an outcome - the goal being specifically to translate that outside the whiteboard space.
Just curious, how do you know that (a) you failed in HR (b) that it was this question and (c) for this reason?
I ask because it's unlikely that this was literally the feedback given you. Also, "I work too hard" does sound a bit canned.
>> The technical interviews, 6 of them in a row!, felt more like they were wanting to see me fail spectacularly rather than focus on my approach of solving whiteboard problems.
I do think this is more "in your head" that real. Nobody shows up to an interview wanting the other person to fail, but "how they solve whiteboard problems" isn't the goal either. It's more about - how does the person, think, collaborate, make tradeoffs and drives to an outcome - the goal being specifically to translate that outside the whiteboard space.
Yeah even if the person came to this answer of their own independent thought process, this answer to the weakness question either comes off as:
1. "I work too hard" which is one of those classic canned answers to avoid that makes you sound like a suckup
or
2. "I can't manage my time to the point where I am in danger of tanking my own productivity or burning out or both", which even if true (plenty of us suffer from this), it is obviously not a great answer to give in a hiring process.
1. "I work too hard" which is one of those classic canned answers to avoid that makes you sound like a suckup
or
2. "I can't manage my time to the point where I am in danger of tanking my own productivity or burning out or both", which even if true (plenty of us suffer from this), it is obviously not a great answer to give in a hiring process.
> (a) you failed in HR (b) that it was this question and (c) for this reason?
A very close friend on the same team (the one who referred me but he didn’t do the interview, obviously) but yes according to him that’s exactly why I failed. The recruiter told me exactly the same thing when he gave me the “bad news”.
> “in your head” Maybe but almost all of them were being very condescending. And I have been on the both sides of interviews a few times so I’d know.
A very close friend on the same team (the one who referred me but he didn’t do the interview, obviously) but yes according to him that’s exactly why I failed. The recruiter told me exactly the same thing when he gave me the “bad news”.
> “in your head” Maybe but almost all of them were being very condescending. And I have been on the both sides of interviews a few times so I’d know.
> I do think this is more "in your head" that real. Nobody shows up to an interview wanting the other person to fail
You say that but I've known interviewers who have taken delight in putting pressure on candidates and then showing off how clever they are in comparison. These types of interviews definitely aren't the norm but sadly it does happen from time to time.
You say that but I've known interviewers who have taken delight in putting pressure on candidates and then showing off how clever they are in comparison. These types of interviews definitely aren't the norm but sadly it does happen from time to time.
I remember recruiting one junior and the HR representative asked that "What is your weakness" question. Personally I hate it because it almost never returns an interesting answer. However on this one occasion the junior did proceed to list off several genuine weaknesses. After about the 3rd point he listed I had to stop him from talking.
Ironically it was his honesty in that interview that won me over. For a junior role I'd rather than a rough diamond who I can shape than someone who already thinks they're perfect. And he turned out to be an incredibly good hire too.
Despite being a hiring manager for many years, I still dread getting asked this question myself. It is easily my least favourite interview question. Even the "Explain an occasion when you disagreed with your manager" question is much more favourable than being asking "what is your worst quality".
Ironically it was his honesty in that interview that won me over. For a junior role I'd rather than a rough diamond who I can shape than someone who already thinks they're perfect. And he turned out to be an incredibly good hire too.
Despite being a hiring manager for many years, I still dread getting asked this question myself. It is easily my least favourite interview question. Even the "Explain an occasion when you disagreed with your manager" question is much more favourable than being asking "what is your worst quality".
> "The only way someone can be a 10x programmer is if you compare them to 0.1x programmers. Someone who wastes time, doesn’t ask for feedback, doesn’t test their code, doesn’t consider edge cases, etc… We should be far more concerned with keeping 0.1x programmers off our teams than finding the mythical 10x programmer."
I think I would add to that that 0.1x programmers are to some extent a product of their environment. Maybe there are people who are inherently 0.1x programmers and there's nothing anyone can do about it, but I think it's also the case that the local engineering culture can turn people into 0.1x programmers. So, the important thing is to figure out how that happens and don't do it.
Some examples: make people do arbitrary repetitive tasks. Hide information. Make infrastructure changes frequently to the point where people regularly have to ask "how do I do this important job function today?" Create domain-specific languages and don't document them. Use build systems that don't work reliably. Have CI systems that require users to wade through megabytes of errors to find the one line that failed. Invent new words for things, or use old words in creative new ways. Speak in acronyms. Create technical documentation (if at all) that never explains "why". Don't set aside time for training. If a question warrants a one-sentence answer, filibuster for ten minutes to prevent follow-up questions from being asked. If it warrants a ten minute answer, reply with a sentence. Especially if you're in a very different time zone, and every follow-up question adds 24 hours to task completion time. Treat "programming ability" as some immutable attribute that is conferred on developers by completion of a bachelor's degree in a computer-related field, and that these programmers are interchangeable and their skills always current and directly applicable to the task at hand. Create Byzantine labyrinths of web-based tools that none can navigate without first having been shown the way through.
I think I would add to that that 0.1x programmers are to some extent a product of their environment. Maybe there are people who are inherently 0.1x programmers and there's nothing anyone can do about it, but I think it's also the case that the local engineering culture can turn people into 0.1x programmers. So, the important thing is to figure out how that happens and don't do it.
Some examples: make people do arbitrary repetitive tasks. Hide information. Make infrastructure changes frequently to the point where people regularly have to ask "how do I do this important job function today?" Create domain-specific languages and don't document them. Use build systems that don't work reliably. Have CI systems that require users to wade through megabytes of errors to find the one line that failed. Invent new words for things, or use old words in creative new ways. Speak in acronyms. Create technical documentation (if at all) that never explains "why". Don't set aside time for training. If a question warrants a one-sentence answer, filibuster for ten minutes to prevent follow-up questions from being asked. If it warrants a ten minute answer, reply with a sentence. Especially if you're in a very different time zone, and every follow-up question adds 24 hours to task completion time. Treat "programming ability" as some immutable attribute that is conferred on developers by completion of a bachelor's degree in a computer-related field, and that these programmers are interchangeable and their skills always current and directly applicable to the task at hand. Create Byzantine labyrinths of web-based tools that none can navigate without first having been shown the way through.
> The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly.
The only thing about the 10x programmer saying that's a myth, is the assumption that it's a quality inherent to the person. You can absolutely accomplish the same level of impact in a week that might take a competent respectable colleague a year, and you don't have to be a genius to do it.
You just have to have a good idea at the right moment. It doesn't even have to be a constant thing. In my career, sometimes I'm just a normal programmer and sometimes I do some bona fide 10x work. A lot the times the 10x work I get the most kudos for will be some absurdly simple low-effort yet impactful thing, like sending pull requests to projects that change a single line of code to bump up a version number in an xml file that has 0days. But because the idea is so simple and almost silly, I can do it a few hundred times and have more impact. Then I can take into consideration that many of these projects I'm fixing are libraries or frameworks, so I'm not only rescuing the project but rescuing their users too.
That kind of transitive impact is what makes 10x possible. Programming isn't like a 19th century assembly line where labor had a very static measurable and manageable impact. Our culture is still catching up in fully understanding and internalizing the enabling impact that computers make possible.
The only thing about the 10x programmer saying that's a myth, is the assumption that it's a quality inherent to the person. You can absolutely accomplish the same level of impact in a week that might take a competent respectable colleague a year, and you don't have to be a genius to do it.
You just have to have a good idea at the right moment. It doesn't even have to be a constant thing. In my career, sometimes I'm just a normal programmer and sometimes I do some bona fide 10x work. A lot the times the 10x work I get the most kudos for will be some absurdly simple low-effort yet impactful thing, like sending pull requests to projects that change a single line of code to bump up a version number in an xml file that has 0days. But because the idea is so simple and almost silly, I can do it a few hundred times and have more impact. Then I can take into consideration that many of these projects I'm fixing are libraries or frameworks, so I'm not only rescuing the project but rescuing their users too.
That kind of transitive impact is what makes 10x possible. Programming isn't like a 19th century assembly line where labor had a very static measurable and manageable impact. Our culture is still catching up in fully understanding and internalizing the enabling impact that computers make possible.
The main thing I’ve learned is there is a glass ceiling of pay as
a SWE and although it seems to pay well, once you have a family to support its pretty much working class. Trying to make money in side hustle is futile for most (You are the commodity compliment to FAANG etc.). Investments are the way to go to increase comfort of living.
Why all the money focus and not about craft and blah blah? Because you are a worker for a business. You will unlikely get to build your magnum opus at work and probably won’t have the energy to do that at the weekend (for most of us). So programming as a job is heavily about earning a living. Work hard, do a great job. If you are 10x then what are you doing working for someone else anyway? Are they paying you 1M a year?
Why all the money focus and not about craft and blah blah? Because you are a worker for a business. You will unlikely get to build your magnum opus at work and probably won’t have the energy to do that at the weekend (for most of us). So programming as a job is heavily about earning a living. Work hard, do a great job. If you are 10x then what are you doing working for someone else anyway? Are they paying you 1M a year?
Anyone who denies the existence of the 10x programmer has either simply not encountered one, or is blinded by their own ego. In my 20 years in industry, I can think of maybe 10 engineers I've directly worked with who were an order of magnitude above all their peers in terms of both code volume AND quality.
These are people who will implement a feature with clean code, well commented, well thought-out and meeting the exact need, correctly structured, in the time that the entire rest of the engineering team would still be scratching their head and debating what to do. One guy years ago who refactored the entire backend at a startup in 2 days, then asked "OK, what can I work on now?" Another guy who wrote an IPC system we needed, which I'd expected would take us 6 weeks, and he did it over the weekend (and it worked perfectly). Another who debugged and patched a critical infrastructure problem in a very complex system, in about 2 days... and would do this time and again, just cranking out features and fixes, week after week.
* "Oh, but their code must have been rushed!" It was fast but not rushed. Some of the best code I've seen.
* "Oh, but they didn't consider user requirements." They did.
* "Oh, they must have been insufferable to work with!" For the most part, super friendly and great teammates.
And so on.
So, sorry if it offends, but some people are just much better developers than everyone else around them (including, possibly yourself). I was much happier after I realized and accepted this fact!
These are people who will implement a feature with clean code, well commented, well thought-out and meeting the exact need, correctly structured, in the time that the entire rest of the engineering team would still be scratching their head and debating what to do. One guy years ago who refactored the entire backend at a startup in 2 days, then asked "OK, what can I work on now?" Another guy who wrote an IPC system we needed, which I'd expected would take us 6 weeks, and he did it over the weekend (and it worked perfectly). Another who debugged and patched a critical infrastructure problem in a very complex system, in about 2 days... and would do this time and again, just cranking out features and fixes, week after week.
* "Oh, but their code must have been rushed!" It was fast but not rushed. Some of the best code I've seen.
* "Oh, but they didn't consider user requirements." They did.
* "Oh, they must have been insufferable to work with!" For the most part, super friendly and great teammates.
And so on.
So, sorry if it offends, but some people are just much better developers than everyone else around them (including, possibly yourself). I was much happier after I realized and accepted this fact!
In my 20 years of industry at both small and large tech companies, I couldn't disagree more with you. I'd also appreciate if you toned down the insults.
It should not be an insult to be told that there are people more skilled than you, though. It is hubris to think otherwise.
Are you saying in 20 years, you haven't met any engineers that were head and shoulders noticeably more productive than their peers, in terms of code volume+quality?
Are you saying in 20 years, you haven't met any engineers that were head and shoulders noticeably more productive than their peers, in terms of code volume+quality?
There are undoubtedly developers who are 10x more productive. But I doubt its because they are born smarter. There are developers who are 100x more invested in their work, and only 10x more productive.
How can developers be "100x more invested in their work"? Assuming the average lazy developer spent 2 years in college learning their craft and 20 hours a week actually working, you're saying the 100x-invested programmer spent 200 years learning about software and 2000 hours a week working?
That's an insane claim. How far must people go to be politically correct and to avoid "insulting"(?!) the average person?
That's an insane claim. How far must people go to be politically correct and to avoid "insulting"(?!) the average person?
Sure, I don't know if they were "born" smarter. At least one of these people, I got to witness up-close his methodological approach to all his coding work. I don't know if the rest had a specific technique or not. All I know: these guys were all insanely fast, and only very rarely made any coding errors.
I agree with you there. There are certainly much faster, much more dedicated workers. My irritation is with:
1. All the hero worship 2. This idea that they are unreachably superior to everyone else
1. All the hero worship 2. This idea that they are unreachably superior to everyone else
I guess I don't see the hero worship. Mention "10x Engineer" around here and people become furious.
Unreachably superior? Well, I'll never be as good as these guys I'm thinking of, and probably not even if I doubled down on sharpening my craft. There's lots of factors for that. Maybe they picked up better habits early, maybe I need to drop dumb hobbies. Or maybe, they're just clearer thinkers. Who knows, but I'm OK with it.
Unreachably superior? Well, I'll never be as good as these guys I'm thinking of, and probably not even if I doubled down on sharpening my craft. There's lots of factors for that. Maybe they picked up better habits early, maybe I need to drop dumb hobbies. Or maybe, they're just clearer thinkers. Who knows, but I'm OK with it.
[deleted]
Thanks, love the post. I agree with everything you said. Recently, I was in an interview for a company and they gave me three requirements for a versioning tool I should design conceptually. I started with the data models and then the backend / frontend communication. I wasn't told who this versioning tool should be for, how many people would use it and other important domain related things, so I said I'll concept a simple solution that would work fine for a group of people but would have to be refactored if we'd want to scale up and support thousands or more connections simultaneously, I was told "sure, go for it".. Once I finished I said that I was confident that a versioning tool has way more complexity and requirements than described initially within those three sentences and that 60 minutes to design such system in a stable way is optimistic.
A week after the interview I was told that they don't want to continue with me because I didn't ask enough questions and that my solution wouldn't work if millions of people would use the system at the same time. I think I avoided a bullet
A week after the interview I was told that they don't want to continue with me because I didn't ask enough questions and that my solution wouldn't work if millions of people would use the system at the same time. I think I avoided a bullet
12. People don’t really want innovation
People talk about innovation a whole lot, but what they are usually looking for is cheap wins and novelty. If you truly innovate, and change the way that people have to do things, expect mostly negative feedback. If you believe in what you’re doing, and know it will really improve things, then brace yourself for a long battle.
Ain’t that the truth. I’ve come up against this my entire career.
People talk about innovation a whole lot, but what they are usually looking for is cheap wins and novelty. If you truly innovate, and change the way that people have to do things, expect mostly negative feedback. If you believe in what you’re doing, and know it will really improve things, then brace yourself for a long battle.
Ain’t that the truth. I’ve come up against this my entire career.
"We may be the culmination of our experiences, but we view them through the lens of the present."
This is so important. I think a lot of the advice given out there comes with the bias of having been successful doing it. There are countless others who have tried to scale the same ladder, doing the same things even, and still did not achieve the same success.
This is so important. I think a lot of the advice given out there comes with the bias of having been successful doing it. There are countless others who have tried to scale the same ladder, doing the same things even, and still did not achieve the same success.
> You can design the most technically impressive thing in the world, and then have nobody want to use it. Happens all the time.
Very true... just yesterday someone posted about the Pony language main user switching to Rust:
https://www.wallaroo.ai/blog-posts/wallaroo-move-to-rust
Despite Pony being an impressive programming language, technically, with a lot of promise, pretty much only one company ever used it and now that it's moved on, Pony is pretty much in the camp "no one uses it".
And much of it is serendipity. A few tiny things could've happened differently, and now everyone would be talking about Pony, not Rust. Similarly, perhaps, happened with Ceylon (anyone remembers that??) VS Kotlin.
Very true... just yesterday someone posted about the Pony language main user switching to Rust:
https://www.wallaroo.ai/blog-posts/wallaroo-move-to-rust
Despite Pony being an impressive programming language, technically, with a lot of promise, pretty much only one company ever used it and now that it's moved on, Pony is pretty much in the camp "no one uses it".
And much of it is serendipity. A few tiny things could've happened differently, and now everyone would be talking about Pony, not Rust. Similarly, perhaps, happened with Ceylon (anyone remembers that??) VS Kotlin.
20 years of experience here. My little contributions:
21. Do not mistake hype and popularity for quality.
22. The best code is no code, but configuration is worse than code. Maintaining 1000 lines of YAML is worse than 9000 lines of code.
23. The best code is no code, but replacing a script with a zoo of tools and libraries is often worse.
21. Do not mistake hype and popularity for quality.
22. The best code is no code, but configuration is worse than code. Maintaining 1000 lines of YAML is worse than 9000 lines of code.
23. The best code is no code, but replacing a script with a zoo of tools and libraries is often worse.
The best code is no code; the second best code is high quality third party code; the third best code is your code; the worst code is low quality third party code, and that one is by a huge margin.
Nicely put. Yet I would add that your code is preferable to third party code if you can solve the same problem with 10x less SLOCs or complexity.
To change a completely misunderstood citation into a new one that nobody will understand either:
> Unnecessary flexibility is the source of all evil
Just as with the original "premature", the word "unnecessary"is doing a lot of heavy lifting here, and there's no way to state that rule that saves people from thinking before applying. Some times those 10x SLOC are really important and will save you; most times it's just a 90% waste ratio multiplied over your previous one.
> Unnecessary flexibility is the source of all evil
Just as with the original "premature", the word "unnecessary"is doing a lot of heavy lifting here, and there's no way to state that rule that saves people from thinking before applying. Some times those 10x SLOC are really important and will save you; most times it's just a 90% waste ratio multiplied over your previous one.
I think I somewhat disagree with 22. Not specifically in terms of YAML or what is categorized as configuration (basically anything?). I think a well designed data model is much more productive and simple than arbitrary code.
A relevant and a fascinating read is this recent paper by Barry M. O’Reilly titled The Machine in the Ghost: Autonomy, Hyperconnectivity, and Residual Causality [1].
> This article will examine the unnamed and potentially devastating constraining effect of software on human autonomy. I call this concept residual causality, where software design decisions made long ago in different circumstances for different reasons constrain human action in an unknown future. The less aware the designers of software systems are of complexity in social systems, the more likely they are to introduce residual causality."
[1] https://www.mdpi.com/2409-9287/6/4/81/htm
> This article will examine the unnamed and potentially devastating constraining effect of software on human autonomy. I call this concept residual causality, where software design decisions made long ago in different circumstances for different reasons constrain human action in an unknown future. The less aware the designers of software systems are of complexity in social systems, the more likely they are to introduce residual causality."
[1] https://www.mdpi.com/2409-9287/6/4/81/htm
I think I agree with every point on that post.
Only thing that I would add to the context:
If someone is a junior developer and has position where he has to "just write code" don't worry much about that advice. Yes you should understand what this advice is and look for ways to grow into that mindset but as junior dev such person still has privilege to fully focus on coding stuff as quickly as possible to learn have their movements worked out.
Then as such junior gets to 2 or more years of experience this advice should sink in and such person should start working as those points guide. After 2 years of being code monkey and having the feel for the code one can start looking at bigger picture.
Only thing that I would add to the context:
If someone is a junior developer and has position where he has to "just write code" don't worry much about that advice. Yes you should understand what this advice is and look for ways to grow into that mindset but as junior dev such person still has privilege to fully focus on coding stuff as quickly as possible to learn have their movements worked out.
Then as such junior gets to 2 or more years of experience this advice should sink in and such person should start working as those points guide. After 2 years of being code monkey and having the feel for the code one can start looking at bigger picture.
I’ve been into it about 25 years. Here’s a few of mine.
1. This industry is very faddish, and many fads are designed to make money for the people driving them or lock you into someone’s ecosystem. Avoiding those is a superpower. A ton of today’s cloud native trends fit into this category. They are gateways to a paradigm where you buy a lot of things as a service at a massive markup that are relatively easy to do locally or obtain at much lower rates.
2. Simplicity is harder than complexity. Managing complexity is merely clever while eliminating it is intelligent. Eliminating it without sacrificing coverage of the problem domain is genius. There is some very interesting academic literature on the idea that intelligence is or at least heavily involves data compression (and that this is what "learning" is), so this has some basis beyond the field.
3. Unfortunately re: #2 more complex less elegant solutions often win. Many argue that this is because they capture more of the problem domain, but I often disagree. I think it's a mixture of sophomore developers being impressed by complexity (having not yet learned #2) and the fact that complexity creates industries where money can be made on adjacent software, services, and consulting. As a result of the latter complex clunky solutions can be better at building an ecosystem full of self-interested evangelists. Recent example: Kubernetes vs. the Hashicorp stack.
4. If you make something work, you are only maybe a quarter of the way to making it a product. UI/UX is the rest of the journey. UI/UX tends to not be fun, so people have to be paid to do it. This is why open source and open systems almost always fail to achieve wide adoption beyond developers and IT people. They have no economic model, so they can't hire people to make the product usable for people other than nerds.
5. Infosec people are usually afraid of the wrong things. Most breaches involve social engineering or a passive mode of entry. Infosec people like to obsess about things that are sexy like cryptography but will happily type "npm install" as root on production and pay far too little attention to security against social engineering vectors.
6. There are 10X (ish) developers just like there are 10X athletes, 10X mathematicians, 10X writers, 10X salespeople, 10X musicians, and so on. The reason many people don't believe in 10X developers is that it's so hard to objectively measure developer productivity, especially at scale.
1. This industry is very faddish, and many fads are designed to make money for the people driving them or lock you into someone’s ecosystem. Avoiding those is a superpower. A ton of today’s cloud native trends fit into this category. They are gateways to a paradigm where you buy a lot of things as a service at a massive markup that are relatively easy to do locally or obtain at much lower rates.
2. Simplicity is harder than complexity. Managing complexity is merely clever while eliminating it is intelligent. Eliminating it without sacrificing coverage of the problem domain is genius. There is some very interesting academic literature on the idea that intelligence is or at least heavily involves data compression (and that this is what "learning" is), so this has some basis beyond the field.
3. Unfortunately re: #2 more complex less elegant solutions often win. Many argue that this is because they capture more of the problem domain, but I often disagree. I think it's a mixture of sophomore developers being impressed by complexity (having not yet learned #2) and the fact that complexity creates industries where money can be made on adjacent software, services, and consulting. As a result of the latter complex clunky solutions can be better at building an ecosystem full of self-interested evangelists. Recent example: Kubernetes vs. the Hashicorp stack.
4. If you make something work, you are only maybe a quarter of the way to making it a product. UI/UX is the rest of the journey. UI/UX tends to not be fun, so people have to be paid to do it. This is why open source and open systems almost always fail to achieve wide adoption beyond developers and IT people. They have no economic model, so they can't hire people to make the product usable for people other than nerds.
5. Infosec people are usually afraid of the wrong things. Most breaches involve social engineering or a passive mode of entry. Infosec people like to obsess about things that are sexy like cryptography but will happily type "npm install" as root on production and pay far too little attention to security against social engineering vectors.
6. There are 10X (ish) developers just like there are 10X athletes, 10X mathematicians, 10X writers, 10X salespeople, 10X musicians, and so on. The reason many people don't believe in 10X developers is that it's so hard to objectively measure developer productivity, especially at scale.
21. is that management cannot, will not, and will never understand why open plan offices are the worst for reducing productivity. You don't want the plebs to also have their own offices.
22. no matter how well you plan, as soon as the (completely arbitrary) deadline gets close, everybody - even people who know better - will demand that you throw in last-minute hacks at 10 PM to "fix" a problem that nobody thought of before that create technical debt that will never be paid off and will be blamed on you.
I like the advice (and the "context" caveat, at the start).
> The best code is no code, or code you don’t have to maintain
I always say "The best code I write, is the code I don't write."
> The best code is no code, or code you don’t have to maintain
I always say "The best code I write, is the code I don't write."
I always say "code is a liability".
I remember seeing a .sig someone had, that said something like:
I hate code, and want as little of it as possible in my programs.I have seen many similar posts what people have learned but not once have I seen:
"Don't assume anything".
So many times when shit hit the bricks because someone assumed something about some other thing they clearly don't know everything about. Which eventually lead to the system failing.
"Don't assume anything".
So many times when shit hit the bricks because someone assumed something about some other thing they clearly don't know everything about. Which eventually lead to the system failing.
That's a useless advice IMO. How can you not assuming anything. I assume that my CPU works, for example. You can't write useful programs without many assumptions. Imagine program that does not assume that CPU works and reruns every algorithm few times with few different code versions to verify that outputs match. It might make sense for moon mission, but definitely not for another CRUD app.
I don't have 20 years of experience yet. But my PoV is as follows: assume as much as you can and ensure that if those assumptions are broken, you have fail-fast-and-log triggers (when it's possible). So when that trigger hits, you'll understand what assumption is broken. For example in Java I'll write Objects.requireNonNull(x, "x") and move on. If that assumption is broken, I'll have stack trace in my logs and I'll write additional logic. It won't take much time. But if that assumption will not be broken, I just saved few hours of time and few dozens of LoC from future maintenance.
Some people hate NullPointerExceptions and want to get rid of them. I love them. They're incredibly useful for me.
I don't have 20 years of experience yet. But my PoV is as follows: assume as much as you can and ensure that if those assumptions are broken, you have fail-fast-and-log triggers (when it's possible). So when that trigger hits, you'll understand what assumption is broken. For example in Java I'll write Objects.requireNonNull(x, "x") and move on. If that assumption is broken, I'll have stack trace in my logs and I'll write additional logic. It won't take much time. But if that assumption will not be broken, I just saved few hours of time and few dozens of LoC from future maintenance.
Some people hate NullPointerExceptions and want to get rid of them. I love them. They're incredibly useful for me.
> I assume that my CPU works
This is not a blind assumption that you make, but one based on lots of evidence (for example you are aware of the testing procedures and QA processes of the CPU manufacture, and you are aware that millions of people and companies use the same CPU model as you and if there were bugs they would have detected them).
If you were to buy some CPU that someone shady made themselves in their basement, them you would probably not make the assumption that the CPU works.
A lot of times programmers make assumptions without properly verifying that the assumption is true, and that is when problems happen. for example, when working with a library function, the programmer might test that it works with certain types of inputs and then just assume that it also works with other types, without actually checking the documentation or verifying
This is not a blind assumption that you make, but one based on lots of evidence (for example you are aware of the testing procedures and QA processes of the CPU manufacture, and you are aware that millions of people and companies use the same CPU model as you and if there were bugs they would have detected them).
If you were to buy some CPU that someone shady made themselves in their basement, them you would probably not make the assumption that the CPU works.
A lot of times programmers make assumptions without properly verifying that the assumption is true, and that is when problems happen. for example, when working with a library function, the programmer might test that it works with certain types of inputs and then just assume that it also works with other types, without actually checking the documentation or verifying
TBH, I got bitten by this assumption. Once, in the course of many decades. A single flipped bit - in a place where it never could happen in the program. After checking everything up and down the stack, this was our conclusion: "the issued command was invalid, thus caught and aborted; the higher-level operation was rolled back, retried, and succeeded; impact: some insignificant delay; root cause: probably cosmic rays; probability of repeating: infinitesimal. Result: no point in guarding against that." (Note that this was in normal athmospheric conditions, not in deep space, hence the probability.)
I completely agree with your second paragraph but the last sentence seems like you don't know what people mean when they say they hate NullPointerExceptions.
They don't mean that you just silently ignore the null value, they mean that they would prefer to use a language that has proper optional types.
They don't mean that you just silently ignore the null value, they mean that they would prefer to use a language that has proper optional types.
People tend to not languages without null though. They have all those NullPointerExceptions in their mind and figure coding would be easier if those didn't exist, but when you give them that they don't like it. Null sits in a very nice spot between dynamic typing and static typing.
I believe you are violently in agreement ;)
You are doing exactly that, assuming nothing. The number of times I've seem "meh, x can't be null here, just do nothing about it" (instead of some way of asserting that assumption, such as you provide) is staggering.
You are doing exactly that, assuming nothing. The number of times I've seem "meh, x can't be null here, just do nothing about it" (instead of some way of asserting that assumption, such as you provide) is staggering.
It would be impossible to do any work at all without making assumptions.
This attitude belies the fact that of the 1000s of assumptions you make every day 1 or 2 will end up being incorrect, but it's usually very, very hard or even impossible to know which in advance.
This attitude belies the fact that of the 1000s of assumptions you make every day 1 or 2 will end up being incorrect, but it's usually very, very hard or even impossible to know which in advance.
Yes the point would better rather be made as "continually question your assumptions" especially when troubleshooting (hence the value of having a rubber duck).
The original point is invalid, although one could say that being good at systematically validating and invalidating assumptions is the sign of a good engineer.
One who doesnt make assumptions at all just wouldnt do anything, though.
One who doesnt make assumptions at all just wouldnt do anything, though.
I assume that when I press a key on my keyboard, the corresponding character will show up in my code editor. If I couldn't assume that, I doubt I'd see the use of pressing any keys at all.
(For clarity's sake: Not disagreeing at all, just illustrating your point with a reductio ad absurdum example.)
(For clarity's sake: Not disagreeing at all, just illustrating your point with a reductio ad absurdum example.)
It’s fine when you don’t do it deliberately. It’s just that about 100% of the time someone says “I just assumed…” that is the source of whatever problem you are having.
A colleague of mine always came with the quote: "Assumption is the mother of all fuckups". https://www.youtube.com/watch?v=7rr88Szc5q0
A principal I worked with for a couple years, actually has that quote up on the wall of his office. It is specially true with projects where you have multiple teams or distributed systems.
"1. I still don’t know very much"
I've been in the game for almost 30 years. I often feel like I know less than I thought I did 25 years ago, and that I know less as time goes by. I'd also have this as my #1 on the list because it just feels so surprising. I think most of us start out in our 20s thinking that in 30 years we'll have mastered the field, but it definitely doesn't feel like that, not even close.
I've been in the game for almost 30 years. I often feel like I know less than I thought I did 25 years ago, and that I know less as time goes by. I'd also have this as my #1 on the list because it just feels so surprising. I think most of us start out in our 20s thinking that in 30 years we'll have mastered the field, but it definitely doesn't feel like that, not even close.
The domain of software engineering has almost certainly increased in size and complexity faster than any of us have learned. We must focus on the fundamentals. All of the new languages and architectures are a storm hovering over a bedrock of empirical computer science.
It's not just all the new stuff that's emerged in the last 30 years. I feel like I didn't really understand a lot of the fundamentals like I thought I did back in my 20s and that there were some major holes in my education that only became apparent after some years of experience in the field. Often you don't know what you don't know. I now know there's a lot I didn't (and don't) know and I think that's a valuable thing that mostly only comes with experience.
10. I don't think the bottom end of the scale is zero. I've seen people being actively harmful to the project.
That being said where you lay on the scale depends on context.
In my previous project I was a [-0.25;0.25], so I quit, because I was miserable and so were my teammates who had to work with me.
Now I'm doing great and even helping others be more productive.
That being said where you lay on the scale depends on context.
In my previous project I was a [-0.25;0.25], so I quit, because I was miserable and so were my teammates who had to work with me.
Now I'm doing great and even helping others be more productive.
Avoid the word 'just' and be suspicious of those that use it: It's just a new model and a few pages, how hard could it be? It should take just a couple of weeks. When people use this word they are being overly optimistic about something they're not sure of.
It's harder than you think: The name of the game is to avoid fooling yourself and you're the easiest person to fool (that's from Feynman). If the problem seems hard it probably is harder than you think. Be ruthless and don't settle for unsatisfactory, hand-waving solutions to these problems. Most people can't detect deadlocks or temporal properties of concurrent programs in their heads.
It's harder than you think: The name of the game is to avoid fooling yourself and you're the easiest person to fool (that's from Feynman). If the problem seems hard it probably is harder than you think. Be ruthless and don't settle for unsatisfactory, hand-waving solutions to these problems. Most people can't detect deadlocks or temporal properties of concurrent programs in their heads.
> 19. Interviews are almost worthless for telling how good of a team member someone will be
I've been pondering the wisdom of having engineers do interviews at all. Interviewing, and getting someone to reveal their hand to you, is a massively specific skill, one that few get good at, let alone software engineers. Why is it that we think a 2 hour course on ethics and STAR can make someone capable of telling the difference between a con artist and a genius?
I do wonder if having a professional hiring team to dig into who the person is, and then just trial them for competence would be a superior strategy?
I've been pondering the wisdom of having engineers do interviews at all. Interviewing, and getting someone to reveal their hand to you, is a massively specific skill, one that few get good at, let alone software engineers. Why is it that we think a 2 hour course on ethics and STAR can make someone capable of telling the difference between a con artist and a genius?
I do wonder if having a professional hiring team to dig into who the person is, and then just trial them for competence would be a superior strategy?
My Markov chain hiring process: Flip a coin. Heads, hire them on the spot. Tails, give them the usual guantlet of algorithm problems and coding challenges.
This is a great list. My two from 10 years of experience would probably be:
- Simplicity is everything. Complexity is fun but business is not about fun. It’s about solving problems. It’s about having other people be able to read your code and quickly understand it. Or having a system that can be debugged without a PhD in the specific tool you’re using.
- Everything is a tradeoff. If something feels too good to be true it probably is. If it’s easy up front, it’s probably hard in other ways. If you want to make something faster you’ll probably need to make it more complicated.
- Simplicity is everything. Complexity is fun but business is not about fun. It’s about solving problems. It’s about having other people be able to read your code and quickly understand it. Or having a system that can be debugged without a PhD in the specific tool you’re using.
- Everything is a tradeoff. If something feels too good to be true it probably is. If it’s easy up front, it’s probably hard in other ways. If you want to make something faster you’ll probably need to make it more complicated.
Wish there was more philosophy of science and exploration into what "technology" means in CS programs. Maybe get undergrads to read Crime and Punishment by Foucault. Not saying he's the be-all end-all but just that perspective of seeing technology as subjective and situated in historical contexts.
Technology in CS ends up instead being taught to be magical progress fuel that brings us towards the inevitable future rather than tools built by people with access to capital in order to achieve specific ends
Technology in CS ends up instead being taught to be magical progress fuel that brings us towards the inevitable future rather than tools built by people with access to capital in order to achieve specific ends
I feel that programmers in general have a lot to learn from the postmodernists. Learning about social constructivism alone can teach you a lot about how to think about abstractions.
”The 10x programmer is a silly myth.”
Incredibly high performers exist, but are rare.
For example, the following quote is from a talk given by Gabe Newell.
(Unfortunately, I do not have the URL to the source video for this quote.)
“At IBM in the 1980s, typical productivity would be 1,000 debugged, shipped lines of code per year. That was the metric that they used for their median employee. Where as, when we were shipping Half Life 1, one employee, Yahn Bernier, was shipping 4,000 lines of code per day.”
Incredibly high performers exist, but are rare.
For example, the following quote is from a talk given by Gabe Newell.
(Unfortunately, I do not have the URL to the source video for this quote.)
“At IBM in the 1980s, typical productivity would be 1,000 debugged, shipped lines of code per year. That was the metric that they used for their median employee. Where as, when we were shipping Half Life 1, one employee, Yahn Bernier, was shipping 4,000 lines of code per day.”
I think it's more that the "10x programmer" myth has caused a lot of pain and bullshit.
There are startup CEO's who won't settle for anything less than a "10x programmer" and waste everyone's time trying to find one.
There are narcissistic coders who think they're "10x" and therefore can act like spoiled children to everyone around them.
If I hear "10x programmer" in anything other than "...is a myth" then it's a sign that whoever is speaking is probably someone I don't want to work with.
There are startup CEO's who won't settle for anything less than a "10x programmer" and waste everyone's time trying to find one.
There are narcissistic coders who think they're "10x" and therefore can act like spoiled children to everyone around them.
If I hear "10x programmer" in anything other than "...is a myth" then it's a sign that whoever is speaking is probably someone I don't want to work with.
If you measure lines of code you will indeed find people who produce a lot of it. Is that a lot of value though?
HalfLife 1 wasn't shipped in the 80s though. Maybe HL3 will be shipped in the (20)80s.
> Good written communication is one of the most important skills for any software engineer to master.
But there is no "mastery" -- lifelong effort is required from all of us, especially to avoid falling into fashionable bad habits of the moment propagated so vigorously by our social media.
> ... good of a team member ...
"The word 'of' often intrudes where it does not belong, as in 'not that big of a deal'"
- Garner's Modern English Usage, 4th edition, page 647.
But there is no "mastery" -- lifelong effort is required from all of us, especially to avoid falling into fashionable bad habits of the moment propagated so vigorously by our social media.
> ... good of a team member ...
"The word 'of' often intrudes where it does not belong, as in 'not that big of a deal'"
- Garner's Modern English Usage, 4th edition, page 647.
Point 12 is objectively the most true in practice.
In my 20 years of experience quality of software engineer comes down to personality, the ability to make decisions based upon evidence more than intuition and the ability to make decisions in the face of insufficient evidence. There is a certain vision of systems that cannot be taught as many people are incapable of accepting concepts of economic abstractions outside what they can put their hands on.
In my 20 years of experience quality of software engineer comes down to personality, the ability to make decisions based upon evidence more than intuition and the ability to make decisions in the face of insufficient evidence. There is a certain vision of systems that cannot be taught as many people are incapable of accepting concepts of economic abstractions outside what they can put their hands on.
Thanks for taking the time to share your experience. I appreciate you starting with context and the sections about innovation and data had me laughing.
> “How can you not know what BGP is?” “You’ve never heard of Rust?” Most of us have heard these kinds of statements, probably too often.
My problem is I’ve heard of it, probably even know a bit about it but never used or worked with it. Meanwhile it seems like everyone around me is both an insane domain expert in their own thing while also a pretty damn good generalist having worked across everything.
My problem is I’ve heard of it, probably even know a bit about it but never used or worked with it. Meanwhile it seems like everyone around me is both an insane domain expert in their own thing while also a pretty damn good generalist having worked across everything.
[deleted]
> 4. The best code is no code, or code you don’t have to maintain
> 17. Keep your processes as lean as possible
> 20. Always strive to build a smaller system
He stops just short of saying it, but IMO a program with fewer lines of code is almost always better. You can write your Java in Python and have it be 1/5th the lines. You can drop the classes and use functions and save some lines.
Exceptions to this rule only happen because lines of code isn't an infallible measure of "size" or complexity.
> Project size is easily the most significant determinant of effort, cost and schedule
https://blog.codinghorror.com/diseconomies-of-scale-and-line...
This comes to mind after having written some short pieces of code which get "improved" by others. But all they did was move things into different files and turn some functions into classes. As though what makes good code is trivially wrapping everything in a class. I can't understand it.
> 17. Keep your processes as lean as possible
> 20. Always strive to build a smaller system
He stops just short of saying it, but IMO a program with fewer lines of code is almost always better. You can write your Java in Python and have it be 1/5th the lines. You can drop the classes and use functions and save some lines.
Exceptions to this rule only happen because lines of code isn't an infallible measure of "size" or complexity.
> Project size is easily the most significant determinant of effort, cost and schedule
https://blog.codinghorror.com/diseconomies-of-scale-and-line...
This comes to mind after having written some short pieces of code which get "improved" by others. But all they did was move things into different files and turn some functions into classes. As though what makes good code is trivially wrapping everything in a class. I can't understand it.
I think that's because non-generated lines of code are a form of "incompressible human work". Sure, one person can write twice as much lines as another. Even 10! But when you have a codebase of 10 millions lines of code, this is going to take a certain amount of man-years, and there is no way to reduce that. This is in stark contrast to the programs we write, that can replace large quantities of human work easily.
Some other ways of looking at this: compilers are an impressive force multiplier. When you compare the size of the source and the size of the executable, it's easy to see how much work you avoid. Compilers allow one single person to create way bigger programs. That would also explain why some people are so insistent on Lisp: macros are compilers. If you can write your own compiler, you can increase even more your own productivity.
This raises the question of why not everyone uses Lisp. The answer is collaboration. Collaboration happens when people share a mental model of things. The bigger the language, the harder it is to find lots of people that share that entire mental model. This may be why you often hear programmers with a lot of experience that prefer "small and simple" things, like C or Go. It makes collaboration easier. Dynamic vs static typing might be the same. It's about "how much context you need in your head at all time". If you have a lot of context in your head, it's easy to think about things succinctly. But when people don't have the same context as you or you lose yours, understanding their short and full of context code might be very hard. Spaghetti programs are that, a mix of context. You can't take one spaghetti out. You have the same exact problem in parsing, context-free vs context-sensitive grammar.
I don't know if and how the context-free vs context-sensitive ideas translate in terms of people. If anyone really likes using Lisp or Go or Haskell, I would be interested in your opinion about my "theory", and if you think that preference for context-free or context-sensitive applies to other parts of your life or personality.
Some other ways of looking at this: compilers are an impressive force multiplier. When you compare the size of the source and the size of the executable, it's easy to see how much work you avoid. Compilers allow one single person to create way bigger programs. That would also explain why some people are so insistent on Lisp: macros are compilers. If you can write your own compiler, you can increase even more your own productivity.
This raises the question of why not everyone uses Lisp. The answer is collaboration. Collaboration happens when people share a mental model of things. The bigger the language, the harder it is to find lots of people that share that entire mental model. This may be why you often hear programmers with a lot of experience that prefer "small and simple" things, like C or Go. It makes collaboration easier. Dynamic vs static typing might be the same. It's about "how much context you need in your head at all time". If you have a lot of context in your head, it's easy to think about things succinctly. But when people don't have the same context as you or you lose yours, understanding their short and full of context code might be very hard. Spaghetti programs are that, a mix of context. You can't take one spaghetti out. You have the same exact problem in parsing, context-free vs context-sensitive grammar.
I don't know if and how the context-free vs context-sensitive ideas translate in terms of people. If anyone really likes using Lisp or Go or Haskell, I would be interested in your opinion about my "theory", and if you think that preference for context-free or context-sensitive applies to other parts of your life or personality.
More lines is generally less good, but I hesitate to really give out this advice. Classes are useful because they make great nucleation sites for future complexity, and often, more simpler lines of code is easier to read (and change). Not all additional lines of code are equally bad.
> We should be far more focused on avoiding 0.1x programmers than finding 10x programmers
Exactly my words two weeks ago: https://news.ycombinator.com/item?id=28640661
We as an industry really should put a lot of effort into helping 0.1x coders improve their skills to 1x level.
Exactly my words two weeks ago: https://news.ycombinator.com/item?id=28640661
We as an industry really should put a lot of effort into helping 0.1x coders improve their skills to 1x level.
Agree with most of this.
> 1. I still don’t know very much
Same here, Im still realising how much I dont know.
> The 10x programmer is a silly myth.
Yes it is. It's a stupid harmful myth. Everyone on HN and Reddit think they are the "10xers", and its used as an excuse to be rude and insufferable.
Some time ago, I decided I'd be happy being a 1x programmer[1]
> Don’t mistake humility for ignorance
Very true. Some of the best engineers I worked with, those who would never get job at these 10x companies, were quiet and reserved. But when you actually talked to them, you realised it was humility and a willingness to learn.
> Interviews are almost worthless for telling how good of a team member someone will be
Yes, interviews are just a form of hazing. The survivors are those who can stand the hazing, not the best programmers
1. https://new.pythonforengineers.com/blog/confessions-of-a-1x-...
> 1. I still don’t know very much
Same here, Im still realising how much I dont know.
> The 10x programmer is a silly myth.
Yes it is. It's a stupid harmful myth. Everyone on HN and Reddit think they are the "10xers", and its used as an excuse to be rude and insufferable.
Some time ago, I decided I'd be happy being a 1x programmer[1]
> Don’t mistake humility for ignorance
Very true. Some of the best engineers I worked with, those who would never get job at these 10x companies, were quiet and reserved. But when you actually talked to them, you realised it was humility and a willingness to learn.
> Interviews are almost worthless for telling how good of a team member someone will be
Yes, interviews are just a form of hazing. The survivors are those who can stand the hazing, not the best programmers
1. https://new.pythonforengineers.com/blog/confessions-of-a-1x-...
The 10x exists, I've met and worked with him and it's not me. But it is a guy who graduated Stanford before he could legally drive a car, so good luck finding many like him. But yeah, if I had to use a word to describe him, humble would fit.
Wow, you are a great writer though. Love your blog!
The sad realisation that I'm the 0.1x software engineer.
Maybe software engineering isn't for you? Not judging you but if you admit to being 0.1x, why continue to do it?
I really hope software engineering isn't the problem. I love building software; Thinking about creative solutions, trying to apply the right design pattern in the right context and all.
Seeing myself in 3rd person, the main reason why I'm 0.1x engineer is attitude/motivation problem. Not having power over specification/design, reading bad code, seeing a bad UI specification, or when my code doesn't work is enough for me to start complaining, getting super pissed and not get anything done.
I just can't work for other people, and really believe if I leave, many people would have the biggest sigh of relief.
Seeing myself in 3rd person, the main reason why I'm 0.1x engineer is attitude/motivation problem. Not having power over specification/design, reading bad code, seeing a bad UI specification, or when my code doesn't work is enough for me to start complaining, getting super pissed and not get anything done.
I just can't work for other people, and really believe if I leave, many people would have the biggest sigh of relief.
The one thing I've learned in software/computers: The more I learn, the less I know.
To survive in this field, one has to accept the fact that everything he/she's worked so hard to learn and master is gonna be replaced by something new in a few years. Don't fight it. Embrace it.
To survive in this field, one has to accept the fact that everything he/she's worked so hard to learn and master is gonna be replaced by something new in a few years. Don't fight it. Embrace it.
[deleted]
[deleted]
I loved a lot of this list, but the best part was the disclaimer in front. I've given talks about software development in the past and usually start with a similar disclaimer.
If I am giving you advice, you should know my context. It'll help you determine if my advice is useful in yours.
Bravo!
If I am giving you advice, you should know my context. It'll help you determine if my advice is useful in yours.
Bravo!
If you try to wait for the money making opportunity in order to build something it may never come. Just start building. Keep building. There are more ideas at the end of a long path than there are at the start. If you don’t keep building they will remain unseen.
> Software engineers, like all humans, need to feel ownership
I've always found this to be very true personally. Unfortunately fear often directly opposes it, i.e concepts like "what if that guy gets hit by a bus" which are valid but sometimes taken too far to the point of attempting to make everyone easily "replaceable"... i've a saying to warn of this that has helped me alleviate such fears in others so far:
If you make your entire developer team replaceable, they will create code and products that are equally replaceable and hold no value. People are the company, they need to be valued as such.
I've always found this to be very true personally. Unfortunately fear often directly opposes it, i.e concepts like "what if that guy gets hit by a bus" which are valid but sometimes taken too far to the point of attempting to make everyone easily "replaceable"... i've a saying to warn of this that has helped me alleviate such fears in others so far:
If you make your entire developer team replaceable, they will create code and products that are equally replaceable and hold no value. People are the company, they need to be valued as such.
Excellent advice. I would add:
Showcase your work as much as possible and refine your ability to do so over time - Not only does regular showcasing of things you've built improve your reputation within a company but also allows you to disconnect from the implementation and focus on how something will be used. You'll often find bugs, shortcomings, or opportunities for improvement that you may otherwise have overlooked. Look for opportunities to showcase wherever possible and advocate for opportunities if they don't exist already.
Showcase your work as much as possible and refine your ability to do so over time - Not only does regular showcasing of things you've built improve your reputation within a company but also allows you to disconnect from the implementation and focus on how something will be used. You'll often find bugs, shortcomings, or opportunities for improvement that you may otherwise have overlooked. Look for opportunities to showcase wherever possible and advocate for opportunities if they don't exist already.
> The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly.
N× programmers for N>1 are mostly not N× cowboy solo code slingers, lots of gains are in enabling other members of the team.
The idea that programmer contributions to output are all in solo code slinging is a close cousin of the myth “programmer contributions can meaningfully be measured in lines of code”.
N× programmers for N>1 are mostly not N× cowboy solo code slingers, lots of gains are in enabling other members of the team.
The idea that programmer contributions to output are all in solo code slinging is a close cousin of the myth “programmer contributions can meaningfully be measured in lines of code”.
At some point, you start to become effective not by churning out code faster than anyone else can do it, but by anticipating upcoming blockers and clearing them out before they become a problem for the team. You're able to use a holistic insight of the project to your advantage in order to keep the team's efficacy to a high level.
> Sometimes the noisiest people are the ones we want to listen to the least.
Yes, especially umm... everywhere in life. `s/sometimes/most of the time/`
> Sharks, not dinosaurs
Gonna remember that one, thanks.
Yes, especially umm... everywhere in life. `s/sometimes/most of the time/`
> Sharks, not dinosaurs
Gonna remember that one, thanks.
"People talk about innovation a whole lot, but what they are usually looking for is cheap wins and novelty." This rings true from being at a Fortune 100 going through "digital transformation". So much jabber about "innovation" and AI / machine learning this and that, when what they really wanted was just to do what everyone else was doing, and just implement similar systems to what Amazon had done a decade+ ago.
I'd say the top lesson I learned is that when you get a list of requirements from someone, most of the time they are not 100% set on them and if they agree to change something very minor, it can allow you to create significantly simpler solution and all parties will benefit from that.
Junior developers often get lost while trying to design a super complex system, which satisfies all the requirements, while it doesn't really need to be that complex.
Junior developers often get lost while trying to design a super complex system, which satisfies all the requirements, while it doesn't really need to be that complex.
An excellent article. Thank you for your insights. I used to run a software engineering practice and I must admit that almost all of your points resonated with me.
I'd like to add that one should catch oneself when falling into the "Perfect is the enemy of good" trap. As engineers, we would like things to be perfect, but sometimes at the peril of late delivery, little feedback, and development of features not required.
I'd like to add that one should catch oneself when falling into the "Perfect is the enemy of good" trap. As engineers, we would like things to be perfect, but sometimes at the peril of late delivery, little feedback, and development of features not required.
> 11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be
I found that another thing which separates a junior from a senior is tendency to give up and cut corners. Stuck a wall making that integration test work? get back to it after the current task, don't settle on manual testing.
But maybe that's a trait of bad developers, rather than junior ones.
I found that another thing which separates a junior from a senior is tendency to give up and cut corners. Stuck a wall making that integration test work? get back to it after the current task, don't settle on manual testing.
But maybe that's a trait of bad developers, rather than junior ones.
I really disagree with point 11. I've seen and worked with so many "senior" engineers who had wretched opinions about everything. One thing in particular is what I like to call "perl behavior". The structure and logic makes perfect sense to the developer but is borderline gibberish to anyone else. Eventually senior software engineers enforce their view as the baseline(which is over flooded with anti patterns) to junior developers and they too end up pouring buckets of the same gibberish everywhere. For example custom built linters which partially follow some standard, and partially doing the complete opposite of what the standard says. But you know... The senior engineers enforce it and 2 years down the line when the junior jumps into another job, it's back to the basics all over again. Anyone with X number of years of experience has strong opinions, that does not make anyone "senior". To my mind, point 11 should be the ability to consider, shift or change your strong opinions when presented with an alternative.
Umm, I don't agree (with OP). Senior (or juniors, if it matters) engineers who have strong opinions about anything are, in my limited experience, very stubborn and difficult to work with. I find myself more and more answering with "it depends, give us more time to see what can be done/what tools we can use".
> The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly.
I think the 10x programmer myth was never about productivity. The idea is more about creativity. I.e. one creative programmer can create a product that would have never existed otherwise.
I think the 10x programmer myth was never about productivity. The idea is more about creativity. I.e. one creative programmer can create a product that would have never existed otherwise.
the dot com boom is over, you can make the next apple or google from your garage any more. All the low hanging fruit have been picked...
The 10x programmer discussion feels a bit silly partly because it’s on the wrong scale. The real scale is more like this:
In a specified amount of time, N, what is the conditional probability that the engineer, e, can design and code a solution which is (relatively) error free?
This shifts into [0, 1] and is really asking the more important question.
In a specified amount of time, N, what is the conditional probability that the engineer, e, can design and code a solution which is (relatively) error free?
This shifts into [0, 1] and is really asking the more important question.
# 20 - Always strive to build a smaller system, is probably the most important one. The new generation of engineers have yet to learn (again) that complexity kills. The amount of resources spent maintaining unnecessary complexity is staggering. Your small thing does not have to be a distributed system.
It was alluded to in the list but I like this great quote:
"the best way to deal with complexity is to remove it"
"the best way to deal with complexity is to remove it"
> We should be far more focused on avoiding 0.1x programmers than finding 10x programmers
I disagree here. A 10x programmer (or whatever other metric you want to use) brings a high level vision and uses that to turn around things faster like building Dynamics UIs, automation, or other tools.
I disagree here. A 10x programmer (or whatever other metric you want to use) brings a high level vision and uses that to turn around things faster like building Dynamics UIs, automation, or other tools.
"If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system"
That is what the "old" models such as waterfall say: as a first phase, complete and accurate software requirements list to be captured in a product requirements document
That is what the "old" models such as waterfall say: as a first phase, complete and accurate software requirements list to be captured in a product requirements document
You are conflating process with design. You can have an iterative process and still take time to think, design and specify things.
> You can have an iterative process and still take time to think, design and specify things.
Start with some thinking, designing and specifying, then start implementing from that -- but remember to take the time for some more thinking, designing and specifying throughout the process going forward.
(Not disagreeing, just "spelling out". Hm, is this my new personal definition of "Agile"?)
Start with some thinking, designing and specifying, then start implementing from that -- but remember to take the time for some more thinking, designing and specifying throughout the process going forward.
(Not disagreeing, just "spelling out". Hm, is this my new personal definition of "Agile"?)
Enterprise Software is at the mercy of every bureaucracy that the enterprise must deal with and the interactions between bureaucracies can create incredibly complex non-logical logic.
Just remember, at one point every gallon of biodiesel in the US had its own serial number.
Just remember, at one point every gallon of biodiesel in the US had its own serial number.
"Nothing worries me more than a senior engineer that has no opinion of their tools"
Nothing worries me more than the opinioned. Open your mind. You shouldn't have deep opinions on your tools because they change, your need and understanding of them changes.
Nothing worries me more than the opinioned. Open your mind. You shouldn't have deep opinions on your tools because they change, your need and understanding of them changes.
> You shouldn't have deep opinions on your tools because they change, your need and understanding of them changes.
What's the problem with that? Opinions can also change.
What's the problem with that? Opinions can also change.
I liked 8 a lot
> Every system eventually sucks, get over it
I'm a fresh recent grad developer, and this is good to know to calm me down from over architecting. I'll do my damnedest, but it's to know it's not awful if things get a bit messy eventually.
> Every system eventually sucks, get over it
I'm a fresh recent grad developer, and this is good to know to calm me down from over architecting. I'll do my damnedest, but it's to know it's not awful if things get a bit messy eventually.
A better way to phrase this is that there is always room for improvement but we don't have infinite time. Deciding what to improve when is a skill.
> Software engineers should do anything that requires them to keep their written communication skills sharp.
In my opinion, code is nicest when it is written communication. When it is almost the same as teaching someone about a problem domain.
In my opinion, code is nicest when it is written communication. When it is almost the same as teaching someone about a problem domain.
> In my opinion, code is nicest when it is written communication. When it is almost the same as teaching someone about a problem domain.
In a way, code is "teaching" the computer how to do some specific task in some specific problem domain. Fortunately, we know how to do that; it's what we do all day. It's just that the computer is a very dumb pupil, so it needs everything explained to it in detail. OK, no problem, so we explain in detail. We know how to do that too; that's still what we do all day.
The next thing is, the computer is very literal-minded, has an excellent memory, and no imagination or sense of "the whole picture". It has absolutely no problem with us calling everything "i, j, k..." and "x, y, z..." But people do; in that sense we're pretty much the opposite of the computer. If only we could remember to call everything something more precise than "i, j, k..." and "x, y, z," the same "explanation" -- our code -- would be much more comprehensible to humans, too, and work as communication not just with the computer but with other people, including ourselves at some later time. (Albeit a rather tedious and detailed explanation, since most humans aren't as dumb as the computer.)
That's (probably, IMO, at least in large part) why "Naming things is the most important problem in computing".
In a way, code is "teaching" the computer how to do some specific task in some specific problem domain. Fortunately, we know how to do that; it's what we do all day. It's just that the computer is a very dumb pupil, so it needs everything explained to it in detail. OK, no problem, so we explain in detail. We know how to do that too; that's still what we do all day.
The next thing is, the computer is very literal-minded, has an excellent memory, and no imagination or sense of "the whole picture". It has absolutely no problem with us calling everything "i, j, k..." and "x, y, z..." But people do; in that sense we're pretty much the opposite of the computer. If only we could remember to call everything something more precise than "i, j, k..." and "x, y, z," the same "explanation" -- our code -- would be much more comprehensible to humans, too, and work as communication not just with the computer but with other people, including ourselves at some later time. (Albeit a rather tedious and detailed explanation, since most humans aren't as dumb as the computer.)
That's (probably, IMO, at least in large part) why "Naming things is the most important problem in computing".
> they’ve formed opinions about the way things should be
I feel the opposite. I'd rather have no opinions rather than have strong opinions that prevent me form seeing new possibilities. Infact, I work hard on keeping my opinions under control.
I feel the opposite. I'd rather have no opinions rather than have strong opinions that prevent me form seeing new possibilities. Infact, I work hard on keeping my opinions under control.
Reinventing the wheels lol it’s everywhere. Not just in software engineering field. Some people do it to look busy and others do it to keep employed! Thanks for sharing your wisdom. I have enjoyed reading your writing.
Similar experience and life path, agree with each one of these really, very valuable. The silly 10x argument which is quite prevalent around here especially, probably says a bit about the audience.
> "6. Sometimes you have to stop sharpening the saw, and just start cutting shit"
Yeah no kidding. I learned how to write code in notepad but now it's like what happened to me :(
Yeah no kidding. I learned how to write code in notepad but now it's like what happened to me :(
There are so many items on this list that I've internalized over the years and this has done a great job breaking them down into a paragraph of text.
This is an interesting perspective. As a developer, I already realized that there's too much to learn as our technology is progressing rapidly.
As Very nice advice. I really like this phrase: "I’ve seen a lot of systems where hope was the primary mechanism of data integrity. "
Learned: software that you write will ALWAYS be for other people to pick-up, and that is hard. Keeping things simple is a tool to that end.
30 years of experience, 2 more:
* You don't know what the hard part was until the software is in production.
* If you know the right way to do it, do it the right way.
* You don't know what the hard part was until the software is in production.
* If you know the right way to do it, do it the right way.
Great advice.
One of the things that I have learnt is how important effective communication is for software developers. It can make or break the products.
One of the things that I have learnt is how important effective communication is for software developers. It can make or break the products.
Expect always the worst case.
Don't assume anything.
If it is not the worst case, be happy, it saves you work. If it is the worst case, be happy, you expected it.
Don't assume anything.
If it is not the worst case, be happy, it saves you work. If it is the worst case, be happy, you expected it.
It’s rare that I see a post where I agree with it enough that I probably could have written it, but here we are.
Not a Software Engineer here, but in Operation here:
1. This is great advice
2. The overall spirit applies to any and all roles across any company.
3. YMMV
1. This is great advice
2. The overall spirit applies to any and all roles across any company.
3. YMMV
from 15 years experience. The best code is no code. I learned to say no 99% of the times. it works
4. The best code is no code, or code you don’t have to maintain
5. Software is a means to an end
these x1000!
Thanks for a very succint, distilled list.
5. Software is a means to an end
these x1000!
Thanks for a very succint, distilled list.
most valuable lesson I've learned in 20 years:
* companies and/or owners don't care about you. take everything you can get and don't be shy about it. don't listen to them when they continually tell you that you're "highly paid"
* companies and/or owners don't care about you. take everything you can get and don't be shy about it. don't listen to them when they continually tell you that you're "highly paid"
Programming to an interface rather than the implementation is the only rule to me.
> 11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be
I don't like this one. IMO it tells you nothing and assumes everyone shares the same culture of pushing opinions.
I don't like this one. IMO it tells you nothing and assumes everyone shares the same culture of pushing opinions.
> > 11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be
> I don't like this one. IMO it tells you nothing and assumes everyone shares the same culture of pushing opinions.
I like it, and think it tells you a lot. It doesn't say they have to be pushing their opinions, just that they should have some.
And honestly, can anyone really know a lot about something and not form an opinion about it? Ask someone, "So, what do you think about ...?", and if their answer is "I don't think anything about it", then most likely you know that yeah, they haven't thought about it.
> I don't like this one. IMO it tells you nothing and assumes everyone shares the same culture of pushing opinions.
I like it, and think it tells you a lot. It doesn't say they have to be pushing their opinions, just that they should have some.
And honestly, can anyone really know a lot about something and not form an opinion about it? Ask someone, "So, what do you think about ...?", and if their answer is "I don't think anything about it", then most likely you know that yeah, they haven't thought about it.
This is a great list. Really appreciate all the experience.
this one got me "10. We should be far more focused on avoiding 0.1x programmers than finding 10x programmers" - preach
This is a great list, I often wonder how people come up with such lists. Is it a long-term conscious effort to write down points like these as they come to you or do they sit for a few hours and these points come to their mind. I can't imagine being able to compile such a good list in a day.
I have some comments as a software engineer of 8+ years of professional experience.
> 1. I still don’t know very much
Yep.
> 2. The hardest part of software is building the right thing
That's definitely hard but I'd say it's the people that are the hardest part.
> 3. The best software engineers think like designers
I'm not sure I entirely agree. It's also in total conflict with the growth economy the employs many of us; properly designing stuff takes time. No matter what, I always end up in a situation where "they want this as soon as possible". Being able to take the time to actually design something seems more like the exception than the norm. The only way around it is experience so that something resembling good design can occur by knee-jerk.
> 4. The best code is no code, or code you don’t have to maintain
> 5. Software is a means to an end
> 6. Sometimes you have to stop sharpening the saw, and just start cutting shit
Yes.
> 7. If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system
Honestly, I don't that any of us have a good grasp of the universe of possibilities. A "good" system is highly subjective. Bad code is at least somewhat measurable if it doesn't work, isn't efficient, or takes a long time for engineers to understand.
There may be no such thing as good code. There's working code and there's code that fails to do its job.
> 8. Every system eventually sucks, get over it
I'd put an asterisk in front of "every". Many "good" systems turn out to suck not only because people ruin them but because engineers learn, grown, and change. While I tend to hate codebases more over time, there are some that I come back to years later and am still impressed by.
> 9. Nobody asks “why” enough
Yes. This has to be part of company culture, however. Many get defensive when subordinates question even the simplest of things, no matter how much they encourage that you "ask questions".
> 10. We should be far more focused on avoiding 0.1x programmers than finding 10x programmers
Maybe, but I've met more 10x developers than I have 0.1x. And I've met exactly one 10x developer.
There was one guy who got canned at the first company that I worked for, and my bosses justified it because they thought he "wasn't doing anything". In actuality, he was directed poorly. Some people can just ignore bullshit management but others need seniors who can provide direction and some level of mentorship. That doesn't mean they are 0.1x developers. It may mean that team leaders haven't managed to find that developer's particular strength.
The closest I've found to 0.1x developers were some dudebros I met during my education, but every one of them flunked out.
> 11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be
I've always had opinions so I'm not sure I relate to this as a senior engineer. I have more opinions, and sometimes more nuanced ones, but in many ways I feel similar to how I did as a junior engineer. I'm frequently astounded by how much more I need to learn.
I guess the major difference I see is in the kind of opinions. Many juniors have opinions, but they are largely additive. Senior engineers who have been in the battle field long enough have opinions but they're more subtractive, or saying "you know, we don't need to add more steps to our toolchain, and maybe we don't need another framework".
> 12. People don’t really want innovation
Innovation rocks the boat for businesses beyond a certain "escape velocity" and what many consider "innovative" is actually confusing since innovation by definition is non-standard.
> 13. Your data is the most important part of your system
> 14. Look for technological sharks
> 15. Don’t mistake humility for ignorance
Yes.
> 16. Software engineers should write regularly
Meh.
> 17. Keep your processes as lean as possible
If I had things my way, I'd get rid of "standups" and "retros", uninstall unadulterated bullshit like Pivotal Tracker in favor of something much simpler like Trello or even a Google spreadsheet, eliminate estimations, and only have meetings that are goal oriented.
> 18. Software engineers, like all humans, need to feel ownership
> 19. Interviews are almost worthless for telling how good of a team member someone will be
> 20. Always strive to build a smaller system
Yes.
> 1. I still don’t know very much
Yep.
> 2. The hardest part of software is building the right thing
That's definitely hard but I'd say it's the people that are the hardest part.
> 3. The best software engineers think like designers
I'm not sure I entirely agree. It's also in total conflict with the growth economy the employs many of us; properly designing stuff takes time. No matter what, I always end up in a situation where "they want this as soon as possible". Being able to take the time to actually design something seems more like the exception than the norm. The only way around it is experience so that something resembling good design can occur by knee-jerk.
> 4. The best code is no code, or code you don’t have to maintain
> 5. Software is a means to an end
> 6. Sometimes you have to stop sharpening the saw, and just start cutting shit
Yes.
> 7. If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system
Honestly, I don't that any of us have a good grasp of the universe of possibilities. A "good" system is highly subjective. Bad code is at least somewhat measurable if it doesn't work, isn't efficient, or takes a long time for engineers to understand.
There may be no such thing as good code. There's working code and there's code that fails to do its job.
> 8. Every system eventually sucks, get over it
I'd put an asterisk in front of "every". Many "good" systems turn out to suck not only because people ruin them but because engineers learn, grown, and change. While I tend to hate codebases more over time, there are some that I come back to years later and am still impressed by.
> 9. Nobody asks “why” enough
Yes. This has to be part of company culture, however. Many get defensive when subordinates question even the simplest of things, no matter how much they encourage that you "ask questions".
> 10. We should be far more focused on avoiding 0.1x programmers than finding 10x programmers
Maybe, but I've met more 10x developers than I have 0.1x. And I've met exactly one 10x developer.
There was one guy who got canned at the first company that I worked for, and my bosses justified it because they thought he "wasn't doing anything". In actuality, he was directed poorly. Some people can just ignore bullshit management but others need seniors who can provide direction and some level of mentorship. That doesn't mean they are 0.1x developers. It may mean that team leaders haven't managed to find that developer's particular strength.
The closest I've found to 0.1x developers were some dudebros I met during my education, but every one of them flunked out.
> 11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be
I've always had opinions so I'm not sure I relate to this as a senior engineer. I have more opinions, and sometimes more nuanced ones, but in many ways I feel similar to how I did as a junior engineer. I'm frequently astounded by how much more I need to learn.
I guess the major difference I see is in the kind of opinions. Many juniors have opinions, but they are largely additive. Senior engineers who have been in the battle field long enough have opinions but they're more subtractive, or saying "you know, we don't need to add more steps to our toolchain, and maybe we don't need another framework".
> 12. People don’t really want innovation
Innovation rocks the boat for businesses beyond a certain "escape velocity" and what many consider "innovative" is actually confusing since innovation by definition is non-standard.
> 13. Your data is the most important part of your system
> 14. Look for technological sharks
> 15. Don’t mistake humility for ignorance
Yes.
> 16. Software engineers should write regularly
Meh.
> 17. Keep your processes as lean as possible
If I had things my way, I'd get rid of "standups" and "retros", uninstall unadulterated bullshit like Pivotal Tracker in favor of something much simpler like Trello or even a Google spreadsheet, eliminate estimations, and only have meetings that are goal oriented.
> 18. Software engineers, like all humans, need to feel ownership
> 19. Interviews are almost worthless for telling how good of a team member someone will be
> 20. Always strive to build a smaller system
Yes.
> 11. .....
> Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software.
The more you learn the more you realise you were wrong.
Having an opinion has often come to mean one is a fan boy of something and will have it no other way.
I have heard team leads say "this python code is bad because it uses no classes" or "we need to use EMR so we can process all customer data together"
Bad opinions formed can be dangerous and counter productive.
Though I do agree that an opinion based on having a well thought out plan and experience is a sign of maturity.
The more you learn the more you realise you were wrong.
Having an opinion has often come to mean one is a fan boy of something and will have it no other way.
I have heard team leads say "this python code is bad because it uses no classes" or "we need to use EMR so we can process all customer data together"
Bad opinions formed can be dangerous and counter productive.
Though I do agree that an opinion based on having a well thought out plan and experience is a sign of maturity.
The more I learn the more I realise everyone else is wrong too. Especially when it comes to general purpose tools - there's so many tradeoffs even in an ideal world but really often the original author just did things wrong, but right enough that his solution stuck and everyone kept piling on and building on top.
PHP and node come to mind immediately.
Ruby is down right retarded with promoting Concerns for modeling cross cutting concerns and fat controller/model is a pattern for creating technical debt.
Dealing with python environments and packages makes me want to avoid python if at all possible.
Using C# and Java means I'm probably going to have 3 projects for a hello world.
I'm not positively opinionated about my tools - it's more about deciding which one sucks least for a particular task.
PHP and node come to mind immediately.
Ruby is down right retarded with promoting Concerns for modeling cross cutting concerns and fat controller/model is a pattern for creating technical debt.
Dealing with python environments and packages makes me want to avoid python if at all possible.
Using C# and Java means I'm probably going to have 3 projects for a hello world.
I'm not positively opinionated about my tools - it's more about deciding which one sucks least for a particular task.
> Dealing with python environments and packages makes me want to avoid python if at all possible.
I see this a lot, and I don't blame folks for having this stance. It's taken me over a decade to dial in my workflow.
Quick rundown:
- don't use python2. Ever.
- don't use the system python, or brew python for anything other than bootstrapping
- only use `pip install --user` for exactly one thing: `pip install --user pipx` when you don't have brew
- never, ever, ever `sudo pip` anything. No exceptions.
- use pyenv to manage your python versions.
- use `pipx` to install stand-alone CLI tools, like virtualenvmanager, poetry, black, mypy.
- always develop in virtualenvs. No exceptions
- prefer installable python packages over scripty standalone .py files
- using PYTHONPATH is a smell
- poetry is likely the future of tooling, but it's not mature enough to be considered best practice for python beginners just yet. Stick with pip if you are uncertain.
- use lockfiles for writing applications but not writing libraries
- editable installs are a double-edged sword
I see this a lot, and I don't blame folks for having this stance. It's taken me over a decade to dial in my workflow.
Quick rundown:
- don't use python2. Ever.
- don't use the system python, or brew python for anything other than bootstrapping
- only use `pip install --user` for exactly one thing: `pip install --user pipx` when you don't have brew
- never, ever, ever `sudo pip` anything. No exceptions.
- use pyenv to manage your python versions.
- use `pipx` to install stand-alone CLI tools, like virtualenvmanager, poetry, black, mypy.
- always develop in virtualenvs. No exceptions
- prefer installable python packages over scripty standalone .py files
- using PYTHONPATH is a smell
- poetry is likely the future of tooling, but it's not mature enough to be considered best practice for python beginners just yet. Stick with pip if you are uncertain.
- use lockfiles for writing applications but not writing libraries
- editable installs are a double-edged sword
I think the fact that you feel working with python requires adhering to a specific 12-step programme may go some way to explaining why I've never gotten comfortable with it.
I love Python and the Python 2-3 debacle really soured things for me as well. It was hard to get over that hump and I can understand that many were put off by it forever.
None of that fix the fact that 3 years later, all of your dependencies will have conflicting requirements.
Your comment about Ruby is actually referring to the Rails framework. It also suffers for the slur.
True, my problem with Ruby is stuff like having select/filter/find_all or map/collect and then frameworks also inventing their own conventions and this somehow being ruby philosophy. Also naming conventions like to_i to_a to_s to_h. And then the scoping rules. I'm not a fan of the language or the design philosophy and will avoid in all future projects.
As for calling it retarded - it's the emotion it evokes, I don't find it particularly offensive - but thankfully I'm not from the pronoun declaring part of the world.
As for calling it retarded - it's the emotion it evokes, I don't find it particularly offensive - but thankfully I'm not from the pronoun declaring part of the world.
Do you think that because you don't find it offensively personally, that it's 100% fine to say and anyone else who finds it distasteful is wrong?
Tasteful is subjective by definition. In a casual conversation on a anonymous forum ? I don't really see the issue. The only people that might be offended here are authors of RoR but then again, I have no qualms about offending them since their designs caused me a lot of pain the year I worked on a project written with it.
Was the slur super necessary to make your point?
I think that there is a very important distinction between having opinions, and willing to have it 'my way only'.
I subscribe to the 'strong opinions, weakly held' model. It's necessary to have opinions about things you're involved with. However, the real art is to be able to not be too attached to one's opinions, be open to change them, and be able to be a productive team member, even if there is a decision to do things in a way that doesn't conform to one's opinions even when the opinions haven't changed.
I subscribe to the 'strong opinions, weakly held' model. It's necessary to have opinions about things you're involved with. However, the real art is to be able to not be too attached to one's opinions, be open to change them, and be able to be a productive team member, even if there is a decision to do things in a way that doesn't conform to one's opinions even when the opinions haven't changed.
> I have heard team leads say "this python code is bad because it uses no classes"
And they'll say it's "best practice".
"best practice" has basically come to mean "whatever that particular developer knows/likes"
And they'll say it's "best practice".
"best practice" has basically come to mean "whatever that particular developer knows/likes"
Just to be fair: in Python, there are "best practices". They're in PEP-8.
If someone is making a claim about anything outside PEP-8 (like whether to use classes) or worse, AGAINST PEP-8...that's when you know there's a problem.
If someone is making a claim about anything outside PEP-8 (like whether to use classes) or worse, AGAINST PEP-8...that's when you know there's a problem.
I think points 11 and 15 (Don’t mistake humility for ignorance) play of each other.
I don't have a hate/love opinion on most things. I may have an opinion on wether or not one particular technical choice is contextually a good or bad idea. I may not be able to form an opinion.
I don't have a hate/love opinion on most things. I may have an opinion on wether or not one particular technical choice is contextually a good or bad idea. I may not be able to form an opinion.
Right, there's a big difference between an engineer with well-founded opinions, and a fanboy with strong emotions. If you can't explain the weaknesses of your favourite tools, that's not a good sign. If you can't explain your preference for one tool over another, that's a bad sign. It's disappointing to encounter developers who, for example, love C# but hate Java, and are entirely unable to articulate why. They're very similar languages!
Somewhat related: Rich Hickey (of Clojure fame) makes the point that one of the disappointing aspects of the software development community is that there's so much talk about 'better', and so little about trade-offs.
Somewhat related: Rich Hickey (of Clojure fame) makes the point that one of the disappointing aspects of the software development community is that there's so much talk about 'better', and so little about trade-offs.
While I agree, I think the essence of this comment is that the converse of OP is not true, i.e. "you should trust a senior engineer that has strong opinions". As a sibling pointed out, it's sort of two steps: 1) make sure they have opinions, then 2) ask yourself if those opinions are that of a fan-boy or somebody who has been around the block enough to know a thing or two.
Perspective by definition is something that requires time, so any top 10 list
of this kind can't be applied consciously with any rigor. I will say point
12 (everyone loves cheap wins, and hates substantive progress) is
unadulterated (but unactionable) truth.
> 20. Always strive to build a smaller system
K.I.S.S. is a great principle, but inexperienced devs really have no way to understand what is small/simple and what isn't.
If you find yourself doing 3 unrelated things before you can finally get to the one thing you were meant to be doing, it's probably already too complicated. If you build it really simple, it can look under-designed, or inefficient, or out of date. But if you find yourself thinking, "this would be better if it were a little bit more complicated", you might have just hit the sweet spot.
K.I.S.S. is a great principle, but inexperienced devs really have no way to understand what is small/simple and what isn't.
If you find yourself doing 3 unrelated things before you can finally get to the one thing you were meant to be doing, it's probably already too complicated. If you build it really simple, it can look under-designed, or inefficient, or out of date. But if you find yourself thinking, "this would be better if it were a little bit more complicated", you might have just hit the sweet spot.
>The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly.
It's not a myth, or silly. It's not even super uncommon.
Incredibly, it doesn't matter how educated the developer, they still seem to have to learn this lesson themselves, over and over, until it sinks in...