Had worked someplace for a short stint. There was a guy who'd started a couple months before I did. His work was 'revolutionary' and 'groundbreaking' - he'd been trying to build some sort of AOP-style PHP system - PHP4, mind you - without any extensions or internals work. It was just 'program this way' - undocumented patterns that encouraged copy/paste to half-way almost get you something usable (except, not really). "Build a form to take a few fields input and store in a database" example took days to develop, because... he was just winging it. Session management? nope - we'll need to roll our own, and that'll take a few weeks.
About half the team (20ish folks) were enraptured by this guy. Someone rambled about great this guy was, said something along the lines of "you know those sorts of geniuses that are so far ahead of everyone else that they can't even explain things, and no one else can quite understand it? that's where we're at, and it's just so awesome - I can't wait to learn more!"
This guy saying that was, at the time, like... the #2 guy on the team, had been there for years, and was the defacto 'team lead' for that work, and he was taken in by a huckster. The aop guy was there for about 10 months, then left abruptly - left on a friday, sent an email on monday with "i resign, i got another job". somehow, some folks were "shocked" at his "unprofessionalism". The entire tenure had been unprofessional, but few cared to label it that.
You're so good and smart that you built something we all need to use, but you can't explain it (let alone why it's good/better), everyone else plainly admits they don't understand much about it, and use the lack of understanding as evidence that they're so bad this must be genius-level work. Insane...
Richard Feynman was certainly a genius and he was well-known for his ability to explain complex topics in ways laypeople could grasp.
*I'm skeptical of any quote attributed to Einstein, but Goodreads said it's by him.
Having used the product (which would not-infrequently manage to make keyboard input lag by full seconds on strong hardware, ate hundreds of megabytes of ram and tons of processor cycles while idle—even worse than your average webshit "app") and putting 2 and 2 together, I'm pretty sure I could have written a list of things they'd failed to take into account, and reasons the results were so poor. It was a fun read thanks to all the details, like "oh, that's why this is so awful, I see exactly what's wrong now".
[EDIT] Though to be fair—and why I hesitated to name them—I haven't used their product in four or five years, and it may be much better now. Looks like the framework they created is called Luna.
We fired our top talent. Best decision we ever made. - https://www.freecodecamp.org/news/we-fired-our-top-talent-be... ( https://news.ycombinator.com/item?id=15474893 125 comments; https://news.ycombinator.com/item?id=32211953 30 comments)
> “You will never be able to understand any of what I’ve created. I am Albert F**ing Einstein and you are all monkeys scrabbling in the dirt.”
> And so our resident genius, our Dr. Jekyll, explosively completed his transformation into Mr. Hyde.
> He declared this in front of the product design team, developers, management, and pre-launch customers. One of our project sponsors had the temerity to ask when the problem crippling our product would be fixed.
And then follow up:
A team reborn after the fiery departure of its misanthropic guru - https://blog.solha.co/life-after-rick-our-team-reborn-after-...
Amazing how much of this resonates with behaviors I've seen over the past few years.
There is also the type of "genius" who creates an overcomplicated framework as a foundation for a new project, and then leaves the implementation details to lesser minds trying to understand his work, while he moves to start another new project. He is always too busy working on a new project, doesn't have time to answer questions about the old ones. (The problem is sometimes solved by gradually removing his code. In extreme case, the library remains included, to avoid a political conflict, but the code is actually never called.)
Ah yes, if the wrong people become aware that the code is never called, better to claim that it happened as too many people had their hand in the pot, and hey, the code is still working, and the tests are passing, so you didn't realize anything was wrong, rather than ruffle feathers and say you didn't want to touch the "genius" code because it was stuck up its own ass.
I've come to think it's the biggest existential risk to doing Haskell in industry - it's red meat to org-chart climbing sharks. And the people who tend to be willing to learn and do FP in prod tend to not be politically-minded (usually due to strong principles and values), making them even weaker to these attacks.
A significant part of choosing a technology is economics of people available to hire. Who can work with that technology 5 years later, when original authors will be long gone.
Is it really cheaper to rewrite an entire working system (that took a year+ to build in the first place) than to just learn something new? I have learned a new language in order to inherit a working, hardened, well-made system before. But I am finding for certain senior engineers, the answer to "can I learn a new language" is a resounding no. The cost is infinite, so of course it's cheaper to rewrite. Plus they are incentivized to rewrite thanks to political reasons (i.e. it's a great way to get promoted).
The last time it happened, I was lucky enough to be accidentally shielded from accountability due to the organizational quagmire that resulted from the team blowing up. I basically got to do nothing for a year and make $200k. And I got to be less than useful to the principal who made the powerplay (not -10x level but I did get to spend time maintaining the existing FP system due to it having a single production consumer left). That dude did not like that I never turned my camera on. My manager also seemed pretty checked-out, so that was extra buffer.
So to summarize, I'll say that it's easy to have be prescient when you make self-fulfilling prophecies. That's one skill I've learned from senior management over the years.
I like Google's strategy of having the simplest language that anybody can pickup as fast as possible. Go.
Also it's not hard to hire Haskellers or Haskell-adjacent devs. Haskell in fact makes you stand out. Those sorts of people don't need months. I've seen people new to Haskell make their first commits within a week. And they weren't geniuses or anything. But they also didn't have an attitude about it.
Seriously, what important industrial problems does it solve? Explain it to me like to a manager you met in an elevator. If you say e.g. lower bug rate, then be prepared to show some evidence (and no, please don't compare it to Python or other dynamic languages).
But I will say that bugs in Haskell tend to be easier to diagnose (helpful at 2am) and aren't usually bad (although they can be). I have debugged Other People's Code while on-call in Haskell way easier than any other language.
And finally, the vast majority of bugs can be prevented or curbed by the type system. I find every time a Haskell company runs into a nasty bug or annoying issue, libraries that make use of the type system are made that reduce or remove that class of bug entirely. This sounds like you can do it in every language, but really what can be made a "library" in Haskell dwarfs what you can reasonably library-ify in most other languages.
Now, I can't give quantitative evidence of this because I don't even know how I would begin to measure it. But these qualities are definitely a big reason why I don't even listen to job offers that aren't Haskell anymore (going on 10 years of that soon) and I have and will promptly quit a job if the company moves off Haskell.
And then you lose 50k whenever the app crashes in production because someone forgot a nil/err check and your tests didn't catch it. Or you pay extra 50k whenever the whole team needs to spend a week on finding a race condition caused by someone accidentally mutating a shared slice, 20 layers below the place the corruption was seen for the first time. Or you spend extra 50k over the year for fixing all the resource leaks caused by missing defers. Or you spend 50x50k to rewrite everything in a more performant stack because of GC pauses (Discord) ;).
There are multiple ways a project can fail or add unexpected costs, and likely there's no silver bullet. There are trade-offs.
And, btw, as for simplicity, there are dozens of languages easier to learn than Go. E.g. scratch, basic, brainfuck. Why not use them? ;)
Simplicity of a language has it costs. Programs written in simpler languages tend to be more complex to compensate for lower expressive power.
Yeah, but if the stack was something common then it still wouldn't be as big a problem.
It was only when a drive-by principal engineer got wind of it that there were problems. "We don't use Haskell here" was literally the only argument for rewriting it. Nobody left before then. We were hiring people fine. The problems you are FUDing around didn't exist.
In fact, the rewrite was so slow and off-target that I had to maintain the Haskell project through a peak season with a skeleton crew of two other people who didn't leave. And we didn't even have an outage - I didn't even get paged! The project got to make the company millions of dollars yet again.
When the rewrite finally started to form, it actually had significantly less functionality than the Haskell implementation. The internal users complained so much about that. And it took just as long to create. What a failure that rewrite was.
In the end, it was the attitude you are espousing that killed the project, not anything technical or hiring-/team-building-wise. It was literally just an opinion not to use Haskell by a guy who couldn't be bothered for the life of him to try to understand it.
Only choose technologies that are popular for production stacks -> more people using those technologies professionally(implying less using others) -> only choose popular technologies -> etc.
From a "making a quality product" standpoint it would make more sense to me to choose the technology intelligently according to the needs of the product. Anything less is just a business mythology about trying to deliver a lower quality product for a lower cost.
The "needs of product" should include "long term maintenance cost".
If software stopped pandering and coddling developers who cannot be bothered to read code we would not need conversations like these. We also wouldn’t need a bunch of superficial nonsense most developers believe they cannot live without. Most companies drastically over spend on finding and retaining developers that aren’t qualified to be there in the first place when really in most cases it’s just about trying to put text on a screen. These companies would save so much money finding people off the street, evaluating them against minimally required intelligence and just training them to read and write code in house.
It's not "super subjective" when something super niche like Haskell[1] is chosen.
There are pragmatic reasons to choose a tech stack, the biggest of which is "can we find people to maintain it?". If you cannot, then it's unmaintainable.
[1] That's the example that was chosen upthread.
It never ceases to amaze me how far you can get with going back to basics of solid software engineering and the manifestations of those basics, mainly:
1. OOP to prove that you have a good grasp of the domain and problem space. Show me you know what's actually happening through code and tests. 2. Build relations - it's far, far, FAR easier to go from BCNF/3NF to a denormalized state than the opposite when you've got lots of data. It's also far easier to perform operations on that normalized state with certainty that your change will fucking work. 3. Focus on APIs first. Whatever the bounded context, focus on the APIs and how they'll be consumed.
He saw DB.Users.Where(a => a.Id == 1) on the screen and launched a tirade of "Are you retarded? You're downloading the whole Users table when you do that!"
It was fun watching our boss explain how LINQ worked and seeing the shame in the engineer's face.
LINQ allows you to use the same syntax for both local arrays and in an ORM, or any data source really, if you implement its IQueryable interface. You implementation can "parse" the AST and generate an SQL query, like a regular ORM.
If a developer working on that sort of task A) matches the coding conventions of the underlying framework and B) employs basic use of docblocks to describe things like function signatures, they're 90% of the way to decent, understandable code that someone else can pick up and work with.
It's amazing, though, how many developers will not do those two things unless you drive home that they're mandatory.
They are pretty objective guidelines that I use to "grade" code in my head and it's pretty rare that anyone who follows them produces code that isn't at least a B, and that other people are able to pick up and extend later on without too much trouble.
And now we have problems A through E.
Personally, through decades of experience, I've learned that when this impulse hits me, I need to consciously remind myself of these truths:
1) The engineer(s) that wrote the offensive code were almost certainly not idiots. The code is probably that way for a reason, even if that reason isn't obvious to me.
2) If I embark on rewriting it "correctly", the odds are very good that I will learn why the code was as it was in the first place, and my rewrite will undoubtedly have my own style, but will not likely avoid whatever issue it was that made me think it should be rewritten.
While I agree with #1, that "offensive" code is offensive for a reason (no time, no experience, no tooling, no hindsight), I don't really agree with point #2. With enough hindsight and careful study, it is entirely possible to avoid the offensive characteristics while doing the same thing.
IMO: bad code is often due to accidental complexity, often brought in by the programmers themselves. And very rarely due to essential complexity.
> With enough hindsight and careful study, it is entirely possible to avoid the offensive characteristics while doing the same thing.
You're right. I should have been more expansive. The rewrite may not reproduce the same issue (although the odds are good you'll see what the issue was!), but it will have its own issues, and is also likely to eventually also become "offensive" code that a future dev will have the urge to rewrite.
I use the word "offensive" here in a technical sense, not in a judgmental sense. Great code can become offensive with time as requirements, environments, and development methodologies change.
The main thing is that rewriting code is very expensive in both the monetary and risk sense. In the end, it's a question of cost/benefit. If the benefit of a rewrite is less than the cost, then rewriting is the wrong decision.
> bad code is often due to accidental complexity, often brought in by the programmers themselves.
Yes, I agree. And the majority of it turned out bad because of maintenance. Too much duct tape and bubble gum has accumulated over time.
Bold statement, but closer to accurate than the first impression.
Truth is, the cost of “just rewrite it” is as large as your unit of software architecture. Prefer loosely coupled, cohesive small parts and rewriting to accommodate changed requirements becomes preferable to the alternatives that tack on complexity as landscape evolves.
The world and our model of it both evolve all the time; the current version is not a work of an idiot but a necessary step towards a better solution and a lesson.
Often, you pick "just rewrite it" when the complexity of a module seems to have grown too high and refactoring to reduce complexity or to hit new objectives seems difficult.
The problem is, a lot of that complexity there may be necessary because of subtlety. Or, we may not do all that much better the next time around.
There's a strong bias in software engineering in particular to underestimate inherent difficulties and overestimate our own capabilities. Sometimes a rewrite is a win, but this bias causes us to select rewrites in times when it ends up not being son.
Once bitten, twice shy.
The example that I had to deal with most recently used a "clean architecture" approach in an api. The incoming calls went through three layers of redundant code - of which each layer had its own set of unit tests - before hitting the db and then passing up the response back through the stack.
It deeply annoys me to have to deal with people who have some pattern like this that they read about and, I assume mostly due to its relative obscurity, they feel ... smart? ... when applying it and forcing whomever comes after to deal with it.
To say that I want to viciously rip out the redundant layers is an understatement.
Something something memory allocating llamas cough.
Whether an architecture is objectively excellent doesn't really matter. The question is whether the people who are going to maintain the thing can work well with it. A tribe of OO partisans will produce a very different system than a tribe of FP ones. Each could find their own system highly maintainable but find the others' incomprehensible enough that they'd rather rebuild it than take it over.
What I think really matters is close, respectful collaboration among a group of people in a context with frequent iteration, so that the team can learn to make good choices together. And, over the longer term, enough continuity in that team so that new people can absorb enough context that the culture is transmitted for as long as the code lasts.
A frontend developer that uses lots of bitwise operations and tricky mathematical algorithms to display CRUD is simply a developer who studied those things.
Unfortunately, this guy played management in a way that caused him to keep getting away with the behavior. Awful person to work with!
Time has proven that generally I'm close enough, but I still fear it.
This is my biggest pet peeve of them all. I tell wet-behind-the-ears engineers "always strive to make the life of the next person to touch the code easier, even if only because the 'next person' will probably be you."
I have dealt with opposite - a monolith-based company grew to a point where more complexity was required, but none of the engineers there seemed to have been equipped with an iota of distributed systems knowledge.
The "senior" and "staff" engineers obviously built something, and everyone was still monkeypatching out all the consistency issues 5+ years later, and some of them were still around declaring that there are no issues.
I don't believe 10x engineers actually exist. Maybe 1.5x, 2x, or 3x engineers exist at most. 10x is a huge exaggeration of human capability.
Get this, say a project takes a year to complete. The concept is saying a 10x engineer can do this in about month. If such a person exists it will be so rare I estimate that most people haven't ever encountered an actual "10x" engineer. Even a 3x engineer is super rare. I can see something like 2x happening where a project that takes a year is done in 6 months. That is rare but plausible.
You also might get a lead who can ramp up the effectiveness of an entire team by say 3x at most. If the size of the team was N, then it's N*3X. If N is like 4 then it's a 12x increase. This is the closest thing to an actual 10x engineer. But it's not actually a 10x engineer here it's just better management.
This article isn't about engineers that make your team better; it's about engineers that make your team worse.
10x engineers do exist, but they're vanishingly rare. I actually met one once. He eventually burnt out and left the industry permanently.
You've really never met this person? Feels like more or less everyone with real expertise should be able to do this in the right job.
The statement that every engineer can be a 10x engineer is recursively paradoxical. If a 10x engineer existed, in my mind, he would immediately be able to identify this logical error.
I won't waste any more words on someone who willfully misunderstands them.
Nope. I've never met anyone who can complete in a month what it takes an average coder a year to complete.
Neither have you.
i've built in two weeks something that took another guy 5 years to not even quite finish. with better performance, reliability and extensibility across the board.
that's a factor of 130x (or more!). how do you want to divide that up between the two of us? if he's 0.01x, how rare must he be for the "average" to still be sitting at 1x?
Remember, for every Bellard, Carmack or jart: there's at least 100,000 glue engineers who are just trying to cash in some easy VC checks - can't blame them at all.
The true 10x engineer looks at the project, sees the inherent needless complexity, goes back to the sponsor and uses his business knowledge to renegotiate the specs. Leading to a reduced scope with 98% of the business value and 10% of the work.
I think the reason so many people have doubts on the existence of 10x is that they might have never encountered one.
I recall a story someone told me a while ago. Software business that did local CoL/prevailing wages. Hired an intern one summer that was just running around in circles around the other, more senior devs. Useless to say they loved him and the next summer they tried to get him back, even offering a signing bonus for an internship (something they considered unheard of) but he was already at a large search engine company down in the Bay. You can guess the comp was probably already 3x what his previous job was offering. Of course, he wouldn't return.
There's a whole class of engineers were completely invisible to most companies, even if they are in the same "local market" [0][1] (Some use the term "dark matter devs" but I know it has another meaning [2]). 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). When hiring is red hot, they might completely disappear from the hiring pool by junior year.
> Get this, say a project takes a year to complete. The concept is saying a 10x engineer can do this in about month. If such a person exists it will be so rare I estimate that most people haven't ever encountered an actual "10x" engineer. Even a 3x engineer is super rare. I can see something like 2x happening where a project that takes a year is done in 6 months. That is rare but plausible.
That's thinking in terms of bricklaying. 10x, like Carmack or Woz for example, bring completely new ideas and paradigm shifts. Think of the engineering happening at Xerox PARC for instance.
[0] https://blog.pragmaticengineer.com/software-engineering-sala...
[1] http://danluu.com/bimodal-compensation/
[2] https://www.hanselman.com/blog/dark-matter-developers-the-un...
All of that are arbitrary numbers. 10 is arbitrary and not actually measurable, but your 3, 4 are as well.
But I think you're on the right track with this thinking. "10x engineer" does not make things 10 times as fast as "1x" engineer does, they do qualitatively different things
Take an example of an engineer who sees through the bullshit of a "cloud architect" who specifies a complicated architecture with novel technologies to pad his resume. Cutting down on this can easily save the project / deliver much faster.
This is kind of an interesting view - 10x engineer does not make projects run 10x faster, but they prevent mistakes which would slow down the project by factor of 10.
If mean = 1x (by definition 1x should be the mean) and the std is the maximum possible value (also 1x). Then 10x would be 10 std past the norm.
This makes my numbers not arbitrary. 2x or 3x would only be 2 or 3 std past the norm. Which is reasonable (only if the std = 1x which is likely not the case and is most likely lower).
If a 10xer existed, That's like saying you found a human who runs 10x faster then the mean (10mph) or you found a human 10x taller than the mean (5'10"). 10 is arbitrary but 2 or 3 is less arbitrary. Ever heard of the company 3sigma? The name represents Rarest non arbitrary anomaly from the norm.
It is actually fundamentally illogical to think of human ability in terms of a multiple of the mean because no other measurable human quality follows that kind of distribution. Almost all of these measured things follow the normal distribution.
You are therefore highly highly unlikely to find a 10x engineer or a -10x engineer. This applies even to things like engineering leadership.
When viewed from this lens you can actually see that it's actually very unlikely for even the best leader to improve the productivity of every member of his team by even 2x. So I take that back. Likely what we are seeing is something like a 1.1x.or 1.2x increase and our minds are exaggerating the effect like an optical illusion.
The concept of measuring any human trait along multiples of the mean via 1x or 2x or 3x or 10x is fundamentally unrealistic when you take a data driven viewpoint of normal distributions. Everyone on this thread is erroneously following this model and while my instincts were more tempered, to a certain extent even I'm following this erroneous model as I declared 3x to be within the realm of reality.
We are all going about this all wrong (including me), the data driven conclusion is that at best you can find 2x engineers and they are freaking rare (because the actual std is nowhere near 1x). The maximum likely delta between the best engineer and worst engineer is 4z, where in this case the z represents 1/2x or an engineer half as good as the average.
Likely people are anecdotally seeing this 4z delta and their mind is exaggerating the delta to 10x. From what we know of statistical reality an actual 10x is unlikely to happen at all.
Sorry, but this is a completely arbitrary definition and honestly one I've never seen so far.
So for IQ, or height, no one can have negative or zero height. This limit effectively limits the std. It is not arbitrary. Try it.
For a distribution of integers on a range from 0 to infinite, let's say the mean is 1. The std will also have a maximum value of 1.
If you add extreme data points to change std, you will also change the mean.
This makes sense right? If you add say 9999999 to a distribution of numbers to keep the average the same you have to counterbalance it with a -9999999 or something like that. But however because the domain is limited from 0 to infinite you can't do that. So effectively the maximum value of the std is the mean itself assuming that the system is normally distributed.
For height, sure, but since IQ scores are defined by the standard deviation of 15, a negative score is possible (you’d expect a single-digit number of people in the world population to have such scores.) Not sure if the typical test resolution is sufficient to distinguish that, though.
In other words the statistical model is not an entirely accurate model of the IQ test. Which to me is what IQ is.
That's just my interpretation though. Regardless of this though, it is highly highly unlikely for engineering productivity to go that deep into the negative. It's also fundamentally impossible to have infinite productivity too. The real domain is for sure some fixed range of numbers which makes the std for sure limited by the distance of the mean to the first number in the range.
By this logic, A 10x engineer is analogous to someone with 1000 IQ or 58 feet in height. We have intuitions about this that is inline with the statistical outcomes I outlined above... and it makes sense to apply these intuitions to the concept of 10x engineers.
You can now define the std to be whatever you want up to 1x. So I take the most ludicrously large std then interpret what the term 10x means in terms of the maximum std.
10x is 10 std from the norm. So the 10x is ludicrously improbable. The real std is likely much lower than this making the concept if 10x even less likely.
And it's wrong. Read the title of this discussion again, "How to be a -10x Engineer" and think about what it means for max. std value.
No one and I mean no one has seen a project accelerate backwards by negative 10. It's akin to -1000iq or -58 feet in height. A "10x" engineer would find this obvious if such a thing existed.
The entire point of my post on statistics is to say 10x or -10x are both fundamentally impossible. Additionally the scale should be 0 to infinite, it does not actually scale negatively. The idea of even -1x is ludicrous. -1x means the project is rapidly disassembling itself and engineers are losing knowledge and intelligence.
Have you read the article? -10x is not about "accelerating backwards", it's about bringing the project to stand still / significantly slowing it down.
And I have seen this multiple times. People who in one way or another managed to slow down other people. Toxic people can create such an environment that the productive people quit. They don't bring smaller value, not even zero value, they bring negative value to the team/project.
> -1x means the project is rapidly disassembling itself and engineers are losing knowledge and intelligence.
I don't know where you come with this arbitrary interpretation of exactly -1, but yes, that happens to projects.
I know the article is generally just talking about bad engineers. However the topic I started here is more about the term 10x.
>And I have seen this multiple times. People who in one way or another managed to slow down other people. Toxic people can create such an environment that the productive people quit. They don't bring smaller value, not even zero value, they bring negative value to the team/project.
Sure but negative progress or -10x progress or 10x progress is just not realistic. The 10 in the term 10x is the thing that is arbitrary. Not only is it arbitrary it's completely inaccurate.
>I don't know where you come with this arbitrary interpretation of exactly -1, but yes, that happens to projects.
Arbitrary definition of 1x? 1x is default -1x would be the default but backwards. It's anything but average. The 10 on 10x is again the arbitrary constant here. Also, Losing knowledge and intelligence is the equivalent of brain damage so are people banging their heads against walls and shooting up on brain damaging drugs? Doubt it. Productivity stops at zero, negative progress is so rare it's basically non-existent.
Pick one. Can't be both.
> 1x is default -1x would be the default but backwards
Not backwards. In terms of value, 1x is a value produced by 1 typical developer. -1x is a decrease of value.
> Also, Losing knowledge and intelligence is the equivalent of brain damage so are people banging their heads against walls and shooting up on brain damaging drugs?
Organizations lose knowledge all the time because people quit because of e.g. toxicity in the workplace (brought by -10x employees).
I guess I'm done with this conversation, it no longer interests me.
Pick what? I didn't pick anything. I'm just laying out examples.
>Not backwards. In terms of value, 1x is a value produced by 1 typical developer. -1x is a decrease of value.
Yeah so my point is -1x is Not arbitrary. You said it is. I simply said it isn't.
>Organizations lose knowledge all the time because people quit because of e.g. toxicity in the workplace (brought by -10x employees).
That's one way of looking at it. It's valid. But by itself I was referring to an honest employee acting to the best of his capability. Like IQ this part cannot be negative. Things like side effects of a bad actor deliberately damaging the company is not something I was referring to. Overall though this type of thing is hard to measure.
>I guess I'm done with this conversation, it no longer interests me.
Sure. That's fine. The conversation is getting into the nitty gritty of interpretation of words which is pointless imo. I think you're pretty clear about what I'm talking about. All in all though my statistical interpretation is still ultimately correct.
> Pick what?
Arbitrary or unrealistic. Utterly obvious from context; you said "arbitrary and unrealistic", they replied "pick one or the other".
Somewhere else you write about "if you only understood what I wrote". Honestly... This shows that the problem there wasn't with someone else's understanding of English, but yours.
At the end of the day it is 10x what, tasks closed (features, bugs, etc) at same or higher quality? Terrible metric but those people exist.
But you can also be a 50/100x engineer if the metric becomes value rather than tasks closed. E.g. convincing key stakeholders their project is a bad idea can save millions, years and companies.
There's plenty of such moments to make huge differences and they compound.
The most spectacular example of this I've ever seen was a developer writing Java that only ever used single-character identifiers.
As in the following style:
class D {
public A foo(B b, C c ) {
D d = b.x( c );
return new A(d.f(1));
}
}
You might be wondering: what happens when he gets to "z" and runs out of identifiers? No problem! He just kept going thus: aa, ab, ac, ad, etc... I saw code up to "dh" or somesuch.
He had perfect job security... right up until the startup he was working for imploded because nobody could collaborate on that code.
Off the top of my head these are the most common two "negative engineer" behaviors I have seen
1) Biggest one: an engineer who is not experienced at architecting complex systems, goes and architects one when complexity was not required in the first place. This is the key to never shipping and destroying entire companies.
2) Close runner up: an engineer who writes code that is inscrutable and therefore unmaintainable (always by others, often by themselves as well). This is the key to your product dying a slow death over several years.
There are negative engineers doing this stuff ALL. THE. TIME. EVERYWHERE. Despite unquantifiable volumes of both ink and blood spilled trying to prevent them.