391–400 of 543 posts
Earlier quoted context omitted.
Out of 10 richest people of the world, 8 have background in software engineering. Musk, Zuck, Bezos, Ellison, Gates, Page, Brin, Ballmer. Only Buffet and Arnault are exceptions.
They are not richest people though, they are biggest public shareholders. Real wealth is always well-hidden.
The costs associated to managing teams without an ambition for excellence are substantial. As far as scaling an org goes, building average teams scales better than having exceptional teams, because by definition, exceptional teams are the exception. But if you work on a project that has winner-takes-it-all dynamics, the costs of average teams are immense.
I really don't get why people argue so much against it. Nobody debates it in sports or music. Not every software project is like the world cup championship. But if you're in a VC market where the winner takes it all, yeah, then it's a lot like music or sports. You want your team to have the ambition to win.
Earlier quoted context omitted.
You really can over-hire and I've seen it happen in many shops If a "10x engineer" is not given 10x problems, they will.. create some.
If by “create some” you mean “Identify a major new revenue stream” or “Investigate something everyone else considers great, improve it 10x and save hundreds of millions of dollars”, then yeah, that’s what I do.
The thing that bugs me with this article is that a lot of regular software engineering is plagued by a lack of ambition. 10x engineers bring that ambition (I hate the term 10x, but let's just stick with it). Because of the scaling effects in software, if you work on the right project, that ambition can significantly increase your impact on the market/world/field you're working in. The costs associated to managing tea…
Am I working hard at Meta? You bet I am.
For median SWE salary and 0.001% in “options” that will likely never have a liquidity opportunity? I’m not so sure…
Earlier quoted context omitted.
> No, the field grew tremendously and you can see a clear generational bias -- by years of experience, not age -- where the cohort from the last 10-15 years has a completely different understanding of what the craft is I bet a lot of people 10-15 years older than you would say the same thing - except they'd say it about you and your generation. I'm not that old, but I've been around long enough to hear people of ever…
> I bet a lot of people 10-15 years older than you would say the same thing - except they'd say it about you and your generation. And they’d probably be right! I remember the grognards giving me shit about memory management and me giving it right back by explaining that what they considered a large chunk of memory would be worth pennys next year because of Moore’s law and I wasn’t going to waste time considering some…
But ignore memory at your peril. I have one proj that has a 256GB instance. For a fairly boring CRUD app. I am asking a lot of questions as apparently we are having the yearly 'we need more memory' questions. Things that are leading to speedups. Just by using less memory. At the bottom of that stack is a L1 cache with less than a hundred KB. It doesnt matter right up until it does. I have seen huge 300+ item string classes that needed maybe 10 of the fields. They threw it in 'just because there is enough'. Yet something has to fill in those fields. Something has to generate all the code for those fields. The memory mangers have to keep track of all of that junk. Oh and all of that is in a pipeline of a cascade of applications so that 300+ class is copied 10 times. Plus the cost to keep it on disk and shove it thru the network.
I have had many colleagues who produce more code and functionality at a constant rate than me. But I have also had that the experience that some of those colleagues were trying to reproduce a certain customer bug for weeks and not being able to reproduce it and that when I finally decided to also have a look at the code, within half a day found the bug and a two click way to reproduce it. When I told them about this…
Due to changes in the input data, a simulator was crashing completely and very early in the simulation, making it unusable. We had to solve this quickly. The underlying module that was crashing had been written by a non-software engineer, and it showed. The project manager was trying to understand it and do the most minimal fix to it as possible. My solution was to rewrite the module from the ground up; this solved the bug, the whole thing is going 2x faster than the previous version and is much simpler. This day I should have been working on a bullshit, internal politics-driven license module, and thus I disobeyed the manager. I couldn't think of anything else anyway, the code has to "get out".
A few days after, I showed my thing and the client royally ignored it, preferring to continue with fixing the older, shittier solution. After 10 or 20 minutes they finally caved and accepted to merge my thing. I don't understand the initial reaction at all.
I could not disagree more with nearly everything in this article. Individuals ship software not teams, unless you are pair programming. Nearly all complex technical projects are owned by one super smart person (Ex: linux). You don't need to have a scientific measurement of productivity to know that in your median team of 12 there really are 2 people carrying the water for everyone else. A players hire A players, B pl…
Understanding this distribution of productivity is a great litmus test for a manager. If they say the distribution of productivity is shaped much differently than this, that is a red flag. They probably can't tell who is contributing, and you can't trust them to do the basic functions of hire, retain, fire.
The article reads like it was written by a manager with tunnel vision. A manager's value-add comes from making a bunch of "normal" people productive, while staying out of the way of the few engineers who will deliver >50% of the value anyways. If you only focus on making the normal people productive, you are only doing the additive part of your job, and neglecting the negative part, which is to recognize and not interfere with the high performers. I would imagine this guy goes around creating lots of least-common-denominator systems/processes, which drive away talent and make the high performers less productive.
Earlier quoted context omitted.
I'll change the perspective so that we can look further. Have you ever seen a product that got worse over time instead of better? I find that it's the majority. Even if they get sales and more users. I'll list the exceptions: whatsapp, and even they succumb to bloat features like ai slop or stories or "communities". If you take a wider period, all software gets worse with time(they die, nothing is forever).
It's hardly the fault of the engineer that products are poorly managed, or poorly designed.
If a bridge falls, will the engineer wash his hands?
I could not disagree more with nearly everything in this article. Individuals ship software not teams, unless you are pair programming. Nearly all complex technical projects are owned by one super smart person (Ex: linux). You don't need to have a scientific measurement of productivity to know that in your median team of 12 there really are 2 people carrying the water for everyone else. A players hire A players, B pl…
The "complacency" and "mediocrity" you mention have deep roots in politics and human psychology and I'd wager less than 1% have anything to do with tech. One of the many things you do in a business is wrestling with such monsters as capitalism and its various types of dysfunction and a plethora of other nice human factors such as hunger for prestige, power and social status.
To give a concrete example: at the moment I am quite ineffectual at work and the core reason is that I just don't give a flying F. I wasn't always like this. I distinctly remember not being like this. I was made into this and I'm sick and tired to pretend it's actually my own fault.
It's sad to see us engineering types being herded by power hungry psychopaths into arenas where we fight eachother to the death like roosters to see who is the "10x".
Earlier quoted context omitted.
Have you ever worked on large projects? I'm talking about projects which involve hundreds of people, thousands even, and those that stretch over many years. In the grand scheme of things, the 10x-100x engineers work gets attenuated - think of it as some kind of averaging filter. Do you think some 10x engineer carried the moon landing? or the Large Hadron Collider? Sure, if you work on some dinky team single-digit num…
10x is not about the number of lines produced. It is about programming languages and tools, about database design/schemas. Choose the wrong language/tool for the job and the amount of work needed to solve the job easily expands 10x. Guido van Rossum and James Gosling and Anders Hejlsberg likely have reduced the amount of work by 10x for a lot of projects compared to implementing them in a lower level programming lang…
The Roman emperor could make or break entire regions by vaguely wagging a few fingers. If and when he made a good decision - which could often easily be attributed to good luck - he could be, and was, heralded as the best thing since sliced bread because he saved millions. Such power surely must be divine. I don't think so.
Not saying Linus or Guido aren't competent engineers. I'm just saying that I don't think they are the sliced bread many make them out to be. They are good. Lots of people are good, but not many people get to be the first to create Python.
And, to be frank, Python - and its ecosystem - and me are through the honeymoon phase. Let's just say the chemistry has worn off and I'm not quite so sure Guido is the net positive we think he is. Maybe Python replaced some other upcoming far superior language. We can't know. (I suspect it did.)
In general I don't think individual/personality worship is a net positive on any axis.