Hacker News new | past | comments | ask | show | jobs | submit login
How to be a -10x Engineer (taylor.town)
875 points by surprisetalk on April 4, 2023 | hide | past | favorite | 494 comments



> Ask your team to perform tasks that resemble work. Common examples include presentations, diagrams, and ticket management.

I'm as salty as the next guy, but in my experience it has been the sub-par employees who are the ones that don't do this. Ticket management is not busy work, it's a necessity for everyone to keep updated. Presentations and diagrams are tools to communicate. I can safely say that by far the most waste I've ever seen has always come down to poor communication rather than anything actually business or technical related.


Yeah that was an interesting read. I like the concept of a -10x engineer because they definitely exist (in my mind it is someone whose work moves you farther away from the project goals, rather than closer to them). But a lot of the bullets sounded like stuff bad managers do, not bad engineers.

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.


And the problem our industry has is that these concepts are not well-defined. You can easily have engineer A strongly claim that the code that was put in front of them from engineer B is terribly designed and will be unmaintainable and then they write an alternative proposal that they love, and then the next guy C comes with the exact criticism of the alternative, and the twist is that C is actually B, the guy who wrote the originally criticized code. You can watch this kind of stuff first hand here in HN discussions. It's so sad, it's actually pretty comical again if you are not vested in it.


I get what you're saying, but I don't good definitions are the problem.

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.


The solution is that the one who write the software/architecture is also the one maintaining it. When it comes to writing easy to maintain code, that can only be learned by maintaining code for a long time. If that dude leaves the team and you have no one that can edit it, just rewrite the code from scratch! So you basically want to follow the Unix philosophy or micro service architecture. This allows you to hire any kind of programmer, you no longer need to find someone experienced in programming language X, with frameworks Y for platform Z (which is impossible), you can hire anyone that is experience enough to do the work and let him/her write the software in whatever environment he/she pleases.


"Rewrite from scratch everything that engineer X touched in four years of working here after he leaves" does not sound like a feasible approach to development. Also, while having good code separation between contractual APIs is a good goal and worth pushing towards, the idea that nobody would ever have shared ownership of any code unit between API contracts is too extreme.


"Rewrite it" is almost always the wrong answer, although it can be an overpowering instinct.

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.


I've "rewrote" a lot of code in my career. I'm putting "rewrote" in quotes, because it was sometimes porting from unmaintained programs in obsolete platforms to something more modern (sometimes without even being able to run them), and other times by doing large-scale refactoring that left the codebase almost unrecognizable.

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.


Your examples are excellent reasons to do a rewrite. Rewriting code is not always the wrong decision. But in the main, when it seems that a rewrite is warranted, it's a good idea to think long, hard, and objectively about why it seems like a good idea.

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


I find value in rewriting/refactoring it as a learning exercise. just take a quick pass. now you are in a really good position to talk about what the strengths and weaknesses are of the existing version.


Oh, yes, I agree with this. But I count this more as "research" than creating production code.


Have you met, for instance, the "clean architecture" paradigm? No there are definitely patterns that will be used by developers which end up getting in the way of the intent of the code, making it harder to reason about and maintain over time.

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.


"The engineer(s) that wrote the offensive code were almost certainly not idiots."

Bold statement, but closer to accurate than the first impression.


I find the argument against rewriting to be like the DRY principle: an oft-misapplied rule of thumb causing much of the unwarranted complexity in software around us.

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.


> Truth is, the cost of “just rewrite it” is as large as your unit of software architecture.

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 problem could be one level up though. It's not just the implementation of a part that's incomprehensible but the design/architecture of how some of the parts interact.


You should not rewrite something that works, only when you need to make larger changes, even if the guy who wrote the program is still there you might want to rewrite from scratch if the requirements change, like you now need to handle 100x more traffic and need to have something with better performance, or scaled out.


SOLID principles at work. Closed for modification. If you’re modifying it, you’re not doing SOLID programming. /s


You both are providing a wonderful example of: "You can easily have engineer A strongly claim that the code that was put in front of them from engineer B is terribly designed and will be unmaintainable and then they write an alternative proposal that they love, and then the next guy C comes with the exact criticism of the alternative, and the twist is that C is actually B, the guy who wrote the originally criticized code. "


The solution is D, which means we come up with a methodology that solves problems A-C and then mandate that everyone sticks to it.

And now we have problems A through E.



> You can watch this kind of stuff first hand...

Something something memory allocating llamas cough.


These are so common. The problem engineer will tend to be seen as a genius with inadequate help, the only one who can save us (from the pit he dug for us).


From a bit ago:

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


Awesome. They fired him after he'd become burned out and snapped, but were perfectly happy to let him grind away day and night for years while the rest of the team was twiddling thumbs.


Thanks for reposting this. Sounds so eerily similar to my last principal that I wonder if it's the same guy, although I'm sure this is a common phenomenon.



Great read, thanks for (re)sharing.

Amazing how much of this resonates with behaviors I've seen over the past few years.


Holy tamole.

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


I remember reading a blog post from a certain project management software startup bragging about their genius lead engineer who created this wonderful NIH frontend framework for them, how it worked, et c.

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


I think referring to office 365 as a ‘software startup’ is a fairly long stretch, so I may have come to an incorrect conclusion but the rest is a fairly accurate description of o365 in my experience.


Asana.

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


> "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?"

Richard Feynman was certainly a genius and he was well-known for his ability to explain complex topics in ways laypeople could grasp.


Totally agreed. I don't trust smart people who can't explain their ideas. It's not that I don't think they're right, it's that I don't think it's a good business idea to operate on faith. But also, being able to break a concept down increases the smart person's level of comprehension of their ideas - it's not only proof, it has tangible benefit.


I don't believe a fellow is clever, unless he can explain his clever thoughts clearly. Feynman was seriously clever.


Yep, someone smart enough to come up with something should also be smart enough to be able to break down and explain what he came up with.


"If you can't explain it to a six year old, you don't understand it yourself." - Albert Einstein*

*I'm skeptical of any quote attributed to Einstein, but Goodreads said it's by him.


Pretty sure that one is from Feynman.


The "genius" who saves the company from the problems he created, is not the apex negative engineer. The time he spends fixing his own mistakes is the time he does not spend creating new ones. Sometimes his creativity will be limited to a single project.

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


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


And it's funny how wherever things finally come to a head and you part ways to much hand-wringing and doom and gloom scenarios... Lo and behold, turns out the new guy can make it work just fine. In fact he's refactoring out the unnecessary complexity as we speak


I had a -10x engineer in my team. They refused to test their own work, because that was the tester's job. They sometimes implemented a feature in the wrong place, both technically and functionally, requiring a complete rewrite (and removing code, roll-back was not an option in this tool). They started using float in HTML while we used grid, this caused stuff to be on top of each other.

Unfortunately, this guy played management in a way that caused him to keep getting away with the behavior. Awful person to work with!


I call them 100x engineers, since they create 100x more work for others


It's all too common for engineers to encourage (or to "request changes" and block a pull request from merging) changes to some code to eke out a bit of non-perceptible performance improvement by rewriting code in a way that makes it more difficult to understand or more complex. There are certainly situations where every ounce of performance gain is worth it, but no, your web app serving 100 DAUs is not it.


Super subjective. The most common thing I see is developers compensating for this by never writing original code and then demonizing others who do when they cannot read it. By original code I don’t mean config files or glue for frameworks.


Yep I've seen seniors/principals come in and steamroll people trying to do FP by claiming that it was inscrutable and irresponsible. Sometimes even going up the chain to cause shake-up without the team's input. Even though said FP was in production, working with a low bug rate, and the entire team was fine with it. And I've seen this happen at multiple companies.

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.


Heh, I was once walked through a live “code review” where all my code that used Java steam maps were replaced by this one dude with for loops in private methods. What a dress-down… pff, the project was canned a few months after I left. But I’m a consultant, no long term investments


Man, I got a story not with Streams but with its C# cousin, LINQ. A long time ago I've seen a senior engineer totally lambasting a junior because the junior used a LINQ ORM.

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.


I've never really worked with C# before but I assume that query is about as efficient as a similar SQL statement?


Exactly.

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.


I am that guy. Because you’ll leave and there will be no one brave enough to support and expand this code. And so it’ll get rewritten from the scratch. Why not write it in a maintainable way from the start.

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.


Uugggghhh… “maintainable way” is again super subjective. Normally when people say that what they really mean is in a way that fits a pattern familiar to them.

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.


> Uugggghhh… “maintainable way” is again super subjective.

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.


You know there are entire companies using Haskell in production successfully and have been for years, right?


The number of companies using boring old Java, C#, C++ dwarfs your number by several orders of magnitude.


So that's proof that you should never deviate? Hegemony always wins?


The only reason the 10+ authors (all plenty skilled in Haskell either before joining or due to working on the project) were all gone is because said senior came in and pushed them out. As I said, the team was fully functional, in production, low bug rate, generally happy.

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.


> The only reason the 10+ authors (all plenty skilled in Haskell either before joining or due to working on the project) were all gone is because said senior came in and pushed them out.

Yeah, but if the stack was something common then it still wouldn't be as big a problem.


I think you're missing my main point which is that it didn't happen. The project was successful and chugging along.

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.


Now, every time you hire an engineer they need to spend weeks or months learning Haskell on top of everything else. It now costs the business an extra 50K every time you get a new developer.

I like Google's strategy of having the simplest language that anybody can pickup as fast as possible. Go.


There are more costs than onboarding costs.

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.


I guess the problem with Haskell is not really hiring, but it is simply a very hard sell to people without academic background. Haskell is for sure elegant, and has some cool features, but this is too little to get wide adoption.

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


So "bug rate" is not a real hard metric anyways. And I only have my experience to go on.

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.


> I like Google's strategy of having the simplest language that anybody can pickup as fast as possible. Go.

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.


You're gonna take heat for that position, but I'd support you, having been in the same position. Came to a team in a company that had a handful of services where folks had been "doing things" in an FP manner where it was entirely inappropriate (CRUD app, without going into details). The had wonderfully illegible, but functional, code that was lacking required basics like transaction management, yet were befuddled as to why certain integration tests or deployments were behaving unpredictably. Similar to your situation, the original decision makers were long gone by the time I arrived.

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.


Isn't that kind of self-fulfilling?

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.


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


They should and I'm not saying to write it in a new language just because it meets the needs a little better. But in a world where the primary motivation for most things is profit, do you think "developer/maintenance costs" are having a little too much weight in the decisions.


It's easy be prescient when you make self-fulfilling prophecies.


It seems as though the main issue here is not with FP itself, but with the politics and power dynamics within organizations.


Oh definitely, but sadly I think the culture and people involved in FP tend to be susceptible to politics. But I am in no way _blaming_ that or acting like FP should change. Those same cultures, values, and people are what make the various FP languages and communities out there great.


The "genius" who transforms complex systems into Eldritch horrors and the "swore an oath to never reinvent the wheel" glue engineer are equally as damaging imo.


Yes and no. I don't think the basics are subjective. A lot of the code which needs to be written basically is framework glue or some CRUD app or something else that doesn't need to be computationally sophisticated or elaborate.

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.


> Close runner up: an engineer who writes code that is inscrutable and therefore unmaintainable

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));
        }
    }

Now imagine this for several hundred thousand lines. Zero comments. Massive functions.

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.


This looks like typical variable naming in Haskell. That community just loves one-letter variable names... I'll never understand why.


Wow. He probably thought this was making the code more compact/efficient/faster.


No, it was job security. This happens all the time when incentives are not aligned. Some engineers even have private dictionaries to convert between the obfuscated code and the real definitions.


We hire for case 2. The hiring process requires deep, esoteric knowledge on sub-optimal data structures and algorithms.

A frontend developer that uses lots of bitwise operations and tricky mathematical algorithms to display CRUD is simply a developer who studied those things.


> an engineer who writes code that is inscrutable and therefore unmaintainable (always by others, often by themselves as well).

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


Yeah, I've had so many experiences of coming back to something I wrote 6-18mo ago, and being so relieved that I wrote it "simply" and with clear comments explaining the intent/purpose. Not only a great refresher, but anyone else could also gain context and easily make changes. I think there's also an aspect of that "broken windows" phenomenon[0] where inscrutable code existing in a project becomes a sort of implicit acceptance of more such inscrutable code being added to the project.

[0] https://en.wikipedia.org/wiki/Broken_windows_theory


So is someone who can grok and refactor an inscrutable codebase a +10x engineer (since they fixed a -10x engineer's work) or ... something else?


3) “Engineers” who resist any kind of structure on the assumption that (1) is going on. That, is, the fear of (1) is just as bad as (1). One manifestation of is today is pythoners resisting real solutions to packaging problems thus making packaging problems impossible to solve.


I find #2 is fairly easy for me to avoid by focusing on code quality and readability. But working in front-end, I'm always afraid of doing #1. The paradigms shift so quickly I never feel sure I'm using the right patterns.

Time has proven that generally I'm close enough, but I still fear it.


> an engineer who is not experienced at architecting complex systems, goes and architects one when complexity was not required in the first place

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.


>Yeah that was an interesting read. I like the concept of a -10x engineer because they definitely exist

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.


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

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.


Another thing to think about is how basically every human trait follows a normal distribution.

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.


> ...and the std is the maximum possible value (also 1x). Then 10x would be 10 std past the norm.

Sorry, but this is a completely arbitrary definition and honestly one I've never seen so far.


It's not arbitrary. Theoretically the max range of the std is infinite. However because the input values are limited in range the std also becomes limited. You're thinking of it in terms of an infinite range from negative infinity to positive infinite. In terms of what we are dealing with practically things like IQ, height or engineering effectiveness are on a scale of 0 to infinite.

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.


> So for IQ, or height, no one can have negative or zero height.

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.


Negative IQ? The test should be the definition of IQ, the statistical distribution doesn't define IQ. If the statistical distribution is saying you can have negative IQ but it is fundamentally impossible to score that amount on the test then the statistical model is the one that doesn't make any sense.

In other words the statistical model is not an entirely accurate model of the IQ test. Which to me is what IQ is. If negative IQ exists what does it even mean? These numbers have to have some physical actualization. It doesn't make sense for IQ to be some measure of some factor that's impossible to ever actualize.

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.


Your interpretation that "10x engineer" has to mean 10 standard deviations is completely arbitrary.


I didn't say it has to mean that. 1x is the average. We agree on that. The std can be anything. But the max possible std is 1x. that's all I'm saying.

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 in this case, 10 std from the norm IF 1x was the std. So the 10x concept is ludicrously improbable. The real std is likely much lower than 1x this making the existence of a 10x engineer even less likely.

This isn't arbitrary. This is the definitive interpretation using statistics. Science so to speak. If you like to interpret 10x under some crazy uneven scaling or use some other methodology other then science, be my guest. But such actions wouldn't be conducive of a 10xer would it? Which further supports my point.


> The std can be anything. But the max possible std is 1x. that's all I'm saying.

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.


[flagged]


> No one and I mean no one has seen a project accelerate backwards by negative 10.

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.


Bring a project to a stand still with the term -10x? The term itself doesn't make sense.

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

>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 arbitrary as it's the smallest whole number metric for negative performance. The 10 on 10x is again the arbitrary constant here. Why 10? is it because we have 10 fingers or use base 10 in our number system? 10 is Arbitrary.

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, that is unless you think people are regularly suffering from brain damage.

People who use the term 10x or -10x as some kind of relatively accurate metric (like many in this thread are doing) aren't applying good intuition or statistical knowledge to the situation. 2x for really good engineers and 0x for really bad engineers are the more technically accurate term. I get the usage of 10x as purely an expression but that is Not what the topic of this thread as evolved into.


> Not only is it arbitrary it's completely unrealistic.

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 one. Can't be both.

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 and anecdotally rare.

I mean if you want to factor in terrorists who bomb the tech and kill everyone in the company into your model, sure. Terrorists have -10000x productivity.

>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 one. Can't be both.

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


> Get this, say a project takes a year to complete. The concept is saying a 10x engineer can do this in about month.

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.


In some domains and markets they're probably a genuine myth.

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.


I don't know... As you imply, there's a lot of mediocrity among those 100,000+ glue engineers trying to cash-in. Being 10x faster/better/whatever than the average of that is nowhere near as challenging as being 10x compared to the average kernel contributor or systems programmer. Which makes being Bellard and Carmack even more impressive.


> You've really never met this person?

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.


> Nope. I've never met anyone who can complete in a month what it takes an average coder a year to complete.

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?


In my time at Google, I saw numerous projects completed that a whole army of me could never complete (according to the required standards). There are many such problems where throwing more bodies at it won't help; genuine insight is necessary. I'm surprised you haven't encountered this.


TempleOS anyone?


I don't know. It was really made over a long, long time by a person working at it virtually full-time, I bet much more than 40h/week. I remember Terry posting LoseThos (or whatever it was called at before that) it in the OsDev forums in the early 2000s, and he had already been working at it for quite a while. Plus, at least back then, it was more of a novelty toy-like OS-simulacrum than a real OS. There were much more impressive projects at the OsDev forums at the time, with people running real app, connecting to the internet and talking to 3d cards.


Every competent and qualified engineer should be able to do the job of 10 competent and qualified engineers?

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 didn't say "competent and qualified engineers". I said "experts".

I won't waste any more words on someone who willfully misunderstands them.


a 10x engineer might not exist. A -10x engineer (or more accurately: a 1/10x engineer) definitely does.

This article isn't about engineers that make your team better; it's about engineers that make your team worse.


The distinction is important: someone else already wrote that the -10× person will move you further away from the goalpost, while the 10⁻¹× counterpart is still moving towards it, only slower.


That's a good point. If your team has an 0.1x engineer, you'll still get to your goal eventually. If you have a -1x engineer, you might be going in the wrong direction to ever finish your project.


> a 10x engineer might not exist

10x engineers do exist, but they're vanishingly rare. I actually met one once. He eventually burnt out and left the industry permanently.


> Get this, say a project takes a year to complete. The concept is saying a 10x engineer can do this in about month.

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

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


A 10x engineer is someone who helps ten people around them be twice as good.


Negative 10x


Oh man. My eyes just skipped over that negative sign every time. Now it makes sense. I thought the article was sarcastic. I'm blind.


Why do you assume 3 is an okay number but 10 isn't, it seems quite arbitrary.

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.


FWIW :)

I used to despise the incredible amount of time we could spend on a single powerpoint slide sometimes.

Then one day when going over same slide for the 5th time with my boss and mentor, I realized:

* This slide will be seen by a person in power

* they will make a decision based upon that slide

* I would like to spend 3 hours explaining them the intricacies of my project/architecture/problem/whatever

* But they have 10/100/1000 other projects, and they have 20/10/5/1 minute to devote to me before they make a decision

* A slide or set of slides might therefore have an impact across 1/10/100 people over week/month/years due to a decision based on a slide or set of slides

* therefore, it can at times be rationally logical to spend a lot of time word-smithing a slide in order to help the right decision

As programmers, we understand that we might spend 10min/hour/days/weeks on a small but crucial piece of code, because we need the computer to understand it and do the exactly right thing in a complicated scenario; and we do not consider it a waste of time (though our management might! It's a curiously symmetrical situation :-)

Sometimes, slides are exactly that, but for people - distilled information to enable executive stakeholder to do the correct thing.

Same with other items - diagrams? They can be phenomenally useful! A good diagram can spread understanding of goal and ensure we all build the right thing. Bad diagram can set 100 smart people on divergent paths!


I suspect that the presentations and diagrams which need to be made, are made. Good communication is important, but the artefacts come about from the organic need to communicate an idea rather than orders from on high.

Consider "The Bar team wants to know about our new Foo architecture" vs "The Bar team needs a 30 minute presentation on our new Foo architecture". Does the Bar team actually need a presentation, and could it be a live demo? Do they just need better documentation? Are they building an integration, and would someone from your team working with them for a week unblock them in a way a presentation wouldn't? Could this be a ten minute call between you and the one engineer who needs a hand?

Good and experienced engineers do their best work on open-ended tasks. This is as true of communication as it is solo work. Artificially dictating the solution without understanding the problem limits them.


> I suspect that the presentations and diagrams which need to be made, are made.

I don't think that's true.

E.g. diagrams are made, once, because of an audit, instead of made iteratively as the software changes.

Or someone says, "If they want to know, they can just talk to me. You know, have a conversation?"


The whole "yeah, just have a conversation" thing bugs me a lot. I like talking, and having conversations. It's rarely enough. The information needs to be written down (or codified in tests or whatever). Future people won't have the luxury of a conversation with whoever originally wrote something. Conversations aren't indexable. Conversations lose nuance, memories fade or get jumbled. Have your conversation, then document/diagram it afterwards.


And it's like talking about code and coding. Once you start writing you find all^W a lot of assumptions/hypotheses you made implicitly or even flaws in your reasoning.

Writing is nature's way of letting you know how sloppy your thinking is.


Plus, conversations are synchronous. If it's just one person explaining to another, it's no so bad. But what if that person needs to explain it to five or ten people? Do you have multiple 1:1 conversations or try to schedule a meeting at a time everyone is available?


The problem is when engineers make presentations instead of writing documentation. The best presentations are when an engineer has written a long page of documentation and walks through it, interspersed with Alt+Tabs to demos of the documented stuff in action.

Too many dysfunctional teams have a culture where engineers make a 1 hour presentation at the end of a multi-week project, upload the ppt and recording somewhere and call it a wrap, without writing a word of searchable and version-controlled documentation.


Yes. Presentations are summaries. There needs to be real documentation that they're summarizing.


I'm going to go out on a limb and suggest that the author probably thinks a healthy balance exists between zero communication and spending 100% of one's time playing JIRA games and visibility hacking.


Agreed. I think the nuance got lost here. "Typical examples" is the key phrase here.

Not all presentations are created equal. Text you throw on a slide in 10 min to guide a 1 hour conversation, versus trying to make everything pixel perfect for 40 hours prepping the deck for the public. Ticket management is critical, but do you really need to spend 4 hours doing it each day?


It’s a jira version of “talks a lot, has little to say.”


I recently heard a quote that resonated with me: "If you want to go fast, go alone. If you want to go far, go together". I wonder if someone who treats these tasks as "non-work" is thinking of themselves as being more productive because they go faster than the folks around them, not considering that these other tasks that slow them down individually also help the team go farther in the long run...


Unless of course, they are not helping the team at all. Unless they are busywork we go through without ever looking at again or using it practically. Unless they are made to avoid making decision and then to avoid it again.

The company I work for have quite a lot of all hands presentations with content relevant to like ... 5 people. While everyone else nods, sleeps, reads reddit, zooms out daydreaming. We have diagrams that have nothing to do with anything, but make manager feel like she is controlling something.

We do not spend much time on ticked management tho. Which an argument against that idea too - you can in fact have functional ticket management without everyone spending too much time on it. But, I did seen overly complicated systems in the past that required constant fiddling.


It's always a balance. There is no universally-correct amount (or types) of meta-work to make a team function optimally.

For some teams, especially very small ones (and most especially if they're all volunteers), adding significant amounts of bookkeeping to their tasks is likely to be much more trouble than it's worth. (Though, again, even for some solo developers, the bookkeeping can be very valuable—it's all about the specifics of the projects and the ways different people operate.)

For other teams, not having the extra bookkeeping will mean that the people struggle to keep their tasks straight, or get abused by their managers, or have a variety of other problems.

The most important thing is to be reflecting on your and your team's work and processes, and being open to changes that might improve them.


> We have diagrams that have nothing to do with anything, but make manager feel like she is controlling something.

Guh, I remember at a previous job, one of my managers would always dedicate a multiple minutes to pie charts of types of tests done at the end of each sprint - the business stakeholders and the developers at the retrospectives couldn't have cared less that 30% of testing effort was spent on smoke testing compared to 28% last sprint.


> Common examples include presentations, diagrams, and ticket management.

Ticket management is stuff that needs doing, obviously.

Diagrams are illustrations; if something is so complicated it can only be understood with a picture, it's too complicated. But a quick diagram on a whiteboard (or with a pencil on the back of a fag packet) might be helpful.

Presentations (with slide-decks) are for managers[0], not engineers. They are a huge drain on time. I got severely dinged by my manager for doing a presentation without a slide-deck; I hadn't prepared one, because I had real work to do. But I think I showed my manager up, because all the other engineers had turned up with slide decks.

A crap slide deck is quick to make, and completely useless. A really good slide deck can take days to make; it's a specialist trade, like making good user documentation. Slides must augment the presentation, not distract from it.

[0] I've been forced into formal management once or twice; my experience was that at least half of management is bragging to other managers about how important your team is, and slide decks are great for that.


> if something is so complicated it can only be understood with a picture, it's too complicated

Absolutes like this contribute significantly, depending on the perspective they're spoken from, to the anti-intellectualism in our society today, or to a culture of elitism.

For the first, some things are complex, and that complexity is part of the real-life systems and structures they have to interface with or represent. Explaining complex things with a diagram can be an extremely effective method for making what might otherwise require a very high cognitive load much easier to process.

And for the second, if someone needs a diagram to understand something complex, it's not because they're stupid, and insisting that everything worth explaining can—and must—be explained in text only does them a disservice.


It seems like a good rule of thumb though. Here's a diagram of the 11 different tools you need to study to create an installer with WiX, which takes literally thousands of lines of XML: https://documentation.help/WiX-Toolset/tools.html

By contrast, WiX# provides a complete code sample that specifies a complete installer in less than 20 lines, with no diagram necessary: https://github.com/oleg-shilo/wixsharp


You seem to be arguing that the existence of one bad diagram and one (related) good text explanation proves that, in general, needing a diagram is bad, and being able to explain something succinctly and clearly in text proves the merit of the thing being explained.

I...do not feel that this follows in any way, either as an absolute or as a rule of thumb.


In my personal opinion as a user, usage of WiX is extremely complicated (requiring multiple different tools, thousands of lines of XML, understanding of the incomprehensible MSI database format as well as the multiple levels of inscrutable macro substitution WiX puts on top of it, and so on). The documentation presents a diagram of the 11 different tools involved (which I'm not saying is a "bad diagram").

Usage of WiX-sharp (which wraps and hides the mess decribed above) is so simple that a complete sample project is just a few lines of code, as shown in the README. There is no diagram because none is needed.

This is consistent with (but doesn't prove as a general rule) the idea that "if something is so complicated it can only be understood with a picture, it's too complicated"


> to the anti-intellectualism in our society today, or to a culture of elitism.

It wasn't meant to be an absolute, it is just a rule of thumb, and for me. I expressed it that way for rhetorical purposes.

I don't think retreating to real language is anti-intellectual; but you may be right that it's elitist to mistrust stories told in pictures. Anti-intellectuals mistrust stories told in words.


I find that I write most diagrams for myself as a reader. It takes much less time to get an overview some logic I have not touched in a while when there is a diagram to start with. Once I remember the big picture I dig deeper via the code.


> Ticket management is not busy work, it's a necessity for everyone to keep updated.

I would say that rather depends on how much of it you do.


Oh, I see... I just assumed people read tickets and did the work and updated the ticket?

For example, I went through a dozen tickets this morning and 96% of my time was spent either writing updates or doing the work the tickets were talking about. 4% probably went to reading the ticket itself and placing it in the correct place after updates/work. That 4% means meetings later will flow faster, and I don't have to remember or write down details and statuses of things somewhere else.

Are people really wasting time on 'ticket management' that isn't as I've described?

Edit:

I've spent some time thinking about this, and despite being the org owner for our companies Azure DevOps instance I'm actually firmly in the 'Ops' camp of Ops<->DevOps<->Dev. My job is mainly Ops and I do some DevOps/SRE work on the side as the pragmatic-infrastructure-guy. I often see lots of nonsense done in the Developer camp. I think why I don't see the downsides of tickets is because I come from the background where tickets are more Help Centre-like. It's just pieces of work that needs doing or people need help with. If the help centre started arguing about if something is 'high' or 'critical' or spent 50% of their time just 'managing tickets' then they would flat-out just get fired. I guess that's the cultural difference between HC/Ops and 'Dev' that I wasn't really seeing before.


I mean, first we really need to align on which Jira components to add to that ticket of yours, because we use them to reflect the products that benefit from the change and you should get in touch with the Automated Horse Warehousing PO whether changing the hue on the "Apply Now" button on the About Us page impacts their Siemens automation codebase. Also, you didn't fill out the seven big free text fields with the proper info in the proper format, and while I understand you physically can't know half of this before making the change, you must or the ticket can't advance from "Backlog" to "Under Consideration for To-Do" in our pre-grooming meeting on Thursday. Oh and I think the update comment you wrote under BLLSHT-173 got auto-deleted because you didn't follow our Task Update Formatting Guidelines, could you reformat and post again?


I see you worked for both of the past two companies I worked for as well.


Emphatically yes, there's some really broken process out there.

I sat on a team with 6+ hours per week of full-team, in a room, jira ticket creation/reviewing/sizing/prioritizing. So thats 15% overhead right off the top.

This of course was not the only time we spent interacting with tickets, as we then had daily standup, random "check-ins" from product/management on ticket status, and of course actually picking, updating, and closing our own tickets throughout the sprint.

Easily spent 30% of our time talking at high level management view about doing work rather than just technically planning & doing it.


I understand developers’ complaints about this sort of thing and I am as much of a Jira-burnout victim as the next coder.

But.

How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one?

15% honestly doesn’t sound like a number I would automatically assume is ‘too much’ for such activity. I’m not sure even 30% sounds like a crazy high number. Building the wrong thing is expensive. Building pieces that don’t fit together is expensive. Avoiding those mistakes requires investing time in some sort of planning activity.

It doesn’t have to be Jira backlog grooming, sure. But it has to happen.

If the developers aren’t spending their time doing this, who is?


> Figuring out if the plan is still the right one?

15% every week is the problem here. If you spend 10% of your annual budget on upfront planning and 5% monthly on checkins, that's maybe ok. Putting the whole team in a room every week is just going to churn the plan constantly - inputs likely aren't changing with that frequency, and you aren't going to be able to pull in all the other stakeholders that often anyway


> Putting the whole team in a room every week is just going to churn the plan constantly

Yes, that's the point, that after each week (or two) of work, we've learned more and the plan already is outdated and needs to change.

> inputs likely aren't changing with that frequency

In my experience, they absolutely are unless you're building the simplest CRUD app that's identical to one you've built before. The inputs are less often changes from external stakeholders, and more often tasks that are turning out to be more difficult than hoped.

> and you aren't going to be able to pull in all the other stakeholders that often anyway

Of course you are. It's the PM's job to gather the new inputs, go check in with relevant stakeholders (takes a day or two at most), update or re-confirm their priorities, and then make the updated decisions for the next sprint.

In my experience, 15% of time spent each week on planning is about right. It doesn't maximize the productivity of each person coding, but it hugely maximizes the productivity of the whole team in delivering a valuable end result.


My experience with weekly ticket grooming is that most of the time we spent 1-2 hours talking about the exact same tickets we talked about last week and left everything in the exact same order as it was when we started. When working on quarter+ long projects there just wasn't anything that changed week-to-week, and when things did change the actual planning to adapt to that was done immediately, not in the weekly meetings.


What was great with my ticket grooming bi-weeklies was that despite having 20 engineers in a room, we were strongly admonished from going into technical details of implementation in the room. "Take those offline. But please put a size on the ticket, thank you."

What else do you want us to do for 4-6 hours/week? Write poetry?

Eventually every ticket just gets sized "medium-big", and people keep their heads down with mouths closed.


So, in my example, we were having 2-3x/week 2-hour, full dev staff meetings.. without product in the room. He was a very busy man and could only grace us with his presence for 30 min every 2 weeks to basically sort the tickets we had spent 12 hours putting together and decide which he actually cared about.

Much could be accomplished more efficiently by getting product, management, and 1-2 seniors in a room for 30min to actually decide what/if plans have changed & cascade the changes accordingly.

99 times out of 100, the plan didn't change because something raised from the bottom, but because management has changed direction or users have asked for something new. Why subject 95% of the team to hour long monologues?


I don't think that's the case for most of the substantial software projects. The plan for the Linux kernel doesn't change each week (do they have "PMs"?).

15% seems very excessive. Almost a whole day a week and two days lost of deep work. Try to aim for 1.5%. Do as much of the planning as possible without a meeting.


1.5% of a workweek is 36 minutes.

I don’t know how you can get a team of developers to productively spend 39 hours and 24 minutes of keyboard time productively coding in the same direction with only 36 minutes of discussion.


That works great in FAANG companies, you might have 1-3 hours of meetings in total a week. That is how your typical PhD program works too, meet with your supervisor once a week. And low meeting culture seems to work just fine for the Linux kernel developers too. You're always free to engage in extracurricular activities, but it's not mandatory.

It's the lesser tier, often non-tech companies doing this kind of micromanagement.


Exactly. A real product driven company with a mature product isn't interacting with customers frequently enough to upend their plans every 1-2 weeks.

How do people think Apple develops completely new product lines like the iPhone, iPad, watch, etc.

There's a lot more up front planning (and yes .. of course, course corrections) than a lot of agile advocates want to admit.

Most agile hyped up senior management I've met just use it as an excuse to be derelict in their ability to plan anything.


> isn't interacting with customers frequently enough to upend their plans every 1-2 weeks.

As I said, re-planning is more often than not needed because of technical challenges developers are running into. If one person is going to take 4 weeks to deliver something instead of the expected 2 days, lots of things may have to be rejiggered.

But also, yes even "real product driven company with a mature products" are changing plans every 1-2 weeks. Because each new incremental feature is a little project of its own. I never said plans get "upended" but they absolutely need to get re-adjusted ever 1-2 weeks based on both dev input and product/user reaction.

If you want to talk about the iPhone, just look up the history of how the software keyboard was developed. Talk about rapid prototyping and upending plans!


The good software companies do these projects in the 3-6 month length instead of 1-2 weeks.


No they don't.

They absolutely plan where they want to be in 3-6 months -- they're generally quarterly OKR's -- but the only way they consistently achieve their targets is with weekly or biweekly readjustments.


They do, and if you need to adjust a project you don't need 10 hours of weekly planning meetings (the Linux kernel developers don't need it, so your CRUD app developers don't either).

The higher you go, the less agile it gets, because that's a horrible way to develop software, or any high-skill professional service or product.


Sorry, are you suggesting a better way to operate is to have the team go off for like a five week offsite to come up with a plan for the rest of the year? Then once a month, they get a day to figure out if the plan’s still working?

It’s an option, I guess… let us know how it works out for you.


That's a horrible idea for sure, but I'm not sure the current model being derided works for all team compositions either.

In a 20+ person dev team with a lot of juniors, the team is not "coming up with a plan" or "deciding if its still working" so much as product/tech lead/a couple seniors who have zones of responsibility are handing one down. The two hours spent in the room is agile kayfabe.

"Get everyone in a room and hash it out for 2 hours" is maybe a model that works at team size of 5, senior, empowered engineers, but it is not something that works at large scales.


I mean... yeah. That's kind of how a lot of big enterprise projects with VP-level visibility get managed (I participated in versions of this at both Amazon and Facebook)

Obviously you don't need to pull all the junior eng offsite for a whole month, but the engineering leads + PMs + engineering management end up there. And obviously there's also ongoing prioritisation happening between leads/PM/management throughout the year - but that doesn't require pulling the whole team every week.


Yeah, I think this level of planning has gotten lost in our recent fad of agileness.

Senior management thinks they know where they want to be in 3 years, but there is no cascading multi-quarter, let alone multi-year planning of the projects & steps to get there.

I've even been in orgs where someone senior is trying to make very very large org & tech changes, and really can't be bothered to put the big building block steps to get from here to there. As it turns out, they never get "there".

Somehow they know enough to bring in project managers for big concrete things like "retire a datacenter" and go all out with MS Project, GANTT, etc.

However when it comes to software changes like "split an on-prem Java monolith into a fleet of python micro services in the cloud" ... it's all iterative vibes the whole way.


Agileness is many things but I really think we can stop thinking of it as a ‘recent fad’ by now. The manifesto was written 22 years ago. It’s been the dominant mode of engineering organization for over a decade.


> Building the wrong thing is expensive. Building pieces that don’t fit together is expensive. Avoiding those mistakes requires investing time in some sort of planning activity.

The promise of "agile" is, IIRC, faster turnaround and iterative development. Yes, the 'wrong' thing is expensive. Getting something basic in someone's hands in 2-3 days to get some feedback is usually more productive than days of figma then 'sign off' then work work work then putting it in hands and getting back "this is wrong" (missing data, etc). Sometimes those things can be found in 'design-only' sessions, but I've rarely seen it happen where lots is found there, then things are implemented perfectly afterwards not requiring any further changes.

Much depends on the size/scope of the work, and I don't think there's one-size that fits all, but the ticketization of work process as teams grow pushes towards "one true way", which then seems to paper over a lot of cracks that don't easily show up in burndown charts.

That 15 or 30% might be the time ultimately taken on thinking/planning/etc of a specific issue, but too often it seems there's an idea of doing more up front "gets it done" and the notion of fast feedback/iteration cycles is glossed over, and you're expected to "get it done" - "all the planning was already done".

When doing dev-type work, I always end up needing to iterate with endusers/stakeholders, and there's little 'up front' that could have been planned to avoid some of that. It may be the nature of the people/teams I've worked with, though.


Yeah and the larger issue - putting 20 people in a room for 2 hours violates like every single management / efficiency / socio-political recommendation in the book.

The more people in the room, the fewer participate, the fewer decisions get made, the more gets punted to the next time 20 people are in the room again in 3 days.


> The promise of "agile" is, IIRC, faster turnaround and iterative development.

The promise of agile is working software.

Iterative development is a how, not a what.


arguably the goal of any software project is... working software, no?

i understand your point, but also think 'agile' is at least as much of a 'how' as much as a 'what', especially over the last 5 years or so.

"agile" itself would seem to be a 'how'. "agile software development" as a phrase is describing - at least too many folks - 'how' the software development will be carried out.

but... it's also a massive amount of hair splitting it seems.


People should absolutely be planning their work. Measure twice, cut once. But then again, isn't agile supposed to be iterative? Measure, cut, measure, cut, measure, cut.. repeat?

How much value do you get from putting 20 engineers in a conference room for 2 hours, 2-3 times per week? What if this is mostly just a head strong manager who enjoy monologuing his captive audience team?

Note I said "spent 30% of our time talking at high level management view about doing work rather than just technically planning & doing it" This doesn't really help prevent building things that don't fit together at all. It barely allows you to surface technical dependencies and order of operations.


> How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one?

Keep in mind that in most "jira-oriented" places (or probably all of them), that task isn't attributed to developers at all.

If you are doing this and development, like a healthy place, yes, 30% of the time evaluating your work sounds sane. But that evaluation time must not be interleaved with development time at all. Any interleaving will destroy the value of both tasks.


Stipulated: many companies suck at engineering management.

But in companies that are good at engineering management, you will often find:

- weekly planning sessions

- daily standups

- work ticketing and backlog systems (sometimes Atlassian ones!)

- prioritization discussions

So I would suggest that anyone who assumes that those activities correlate with bad engineering management, is falling into a base rate fallacy.

P(is badly managed | Jira) is high, but that’s because P(is badly managed | tech company) is high.


> Oh, I see... I just assumed people read tickets and did the work and updated the ticket?

There are a LOT of Professional Scrum Masters and Product Managers who want to constantly review the state of tickets, make update/status comments and communicate simple questions and answers via the ticket system.

Did you mean 'x'? Yes, I meant 'x'.

Our slack bot channel exploded when we hired a new Product Manager who communicated strictly via ticket updates, literally dozens of alerts per day. They got upset when they found out every single developer had unsubscribed from all the ticket channels because of the noise.


Make everything, even a 1 min fix a ticket and insist it's under right category and right project, the time is accounted for, and each developer have to report 8h time worked a day and you can have plenty of time wasted on ticketing


If you're making a change without saying what it is or how to test it, and not writing an automated test to cover it then that would be a problem. It might be 1 minute in code, but that doesn't mean it's a 1 minute fix.


It depends. Maybe the 1 min fix is to add a missing test case for something that already works. Spending 20 mins creating a templated Jira for that is a waste of time imho, but it depends on what you do. In some places that have externally audited traceability requirements that would be necessary.


Yes, I agree with that. I'd say that changes to the running codebase would need (slightly) more formality than changes to the test codebase, but yes, if tests are a feature e.g. because they feed into regulatory output, then they should also be ticketed.

I don't find that a Jira ticket takes more than 2 minutes to write though, so maybe there's a difference in terms of number of mandatory fields.


2 minutes? That's barely enough time to load the Jira ticket creation page...


Hah! Hit create and the popup opens. Unless you have a load of plugins installed, in which case tell your IT department off.


The commit or comment is enough for that.


There are definitely corporate cultures where updating ticket status at regular intervals is higher priority than actually working the problem in the ticket.


Of course it is. That means that you work on the problem, but when a regular interval arrives, you stop working on the problem to update the ticket instead. Once updated, you go back to working on the problem. That's how status updates are supposed to work.

Inverting the priority would mean that you never update tickets until you're done fixing the problem. That might be possible in small organisations or for small problems. Everywhere else, it's necessary to provide updates from time to time before the problem is solved.


If you want daily updates on normal tasks, you're just wasting a bunch of people's time. Under ordinary circumstances, that stuff cannot possibly be actionable, and tracking data that's not actionable is just wankery. I don't mean keeping people directly working on the tasks in-the-loop with one another and surfacing blockers, which shouldn't need formal process beyond at most a five-minute daily standup, I mean up-the-chain status updates. Wanting to watch the little Jiras move through the flow chart on a daily basis is just PMs and managers wishing they were playing Starcraft or something instead of doing work.

Given that, if your tasks are taking long enough that any but very-rare outliers span more than a couple status updates (which shouldn't be needed more than about weekly, under normal circumstances) then your tasks are too big or you've got some serious process issues making everything take far longer than it should.


From the project manager's point of view: I think it depends on the urgency/priority of the bug. If it's a production outage that's costing $N million a microsecond, yes, I want status updates multiple times daily. If it's a nice-to-have bugfix, update it whenever you can, I don't care. If it's somewhere in between, I'd expect an update frequency proportional to the seriousness of the problem.

Bottom line is that in any remotely serious business, status has to be written and communicated to the executives. It's not optional. There's the easy way: use the ticketing system, leave comments, mark things as resolved, so the managers can just read the ticketing system's reports and leave you alone. And there's the hard way: don't use the ticketing system, and have an annoying guy like me "pinging" you for updates and what's the progress on this and what's the status on that. We both like the easy way so let's settle on doing that!


> If it's a production outage that's costing $N million a microsecond, yes, I want status updates multiple times daily.

That's what one has sev/incident response procedures for. Put everyone in the entire management chain on a conference call with execs/comms/legal for as long as it takes - and make damn sure the line manager is shielding the actual engineers from this process so they have time to fix the bug.


> From the project manager's point of view: I think it depends on the urgency/priority of the bug. If it's a production outage that's costing $N million a microsecond, yes, I want status updates multiple times daily.

Right, that's why I specified "normal" and "ordinary" tasks. Outages are another matter.

> Bottom line is that in any remotely serious business, status has to be written and communicated to the executives. It's not optional. There's the easy way: use the ticketing system, leave comments, mark things as resolved, so the managers can just read the ticketing system's reports and leave you alone. And there's the hard way: don't use the ticketing system, and have an annoying guy like me "pinging" you for updates and what's the progress on this and what's the status on that. We both like the easy way so let's settle on doing that!

Devs aren't in the ticketing system all day. They close it because they're all bloated as hell and eat system resources like mad, only opening it when strictly necessary, which then takes forever. They take longer to navigate it than you do, because they're not in it all day. They dread it because ticket workflows are often convoluted and hard to understand for anyone who's not in the ticketing system all day, and because they're all designed in such a way that it's weirdly-easy to accidentally press a button or drag something and mess things up in ways that can be tricky to fix or even to understand what's happened, sometimes without even noticing one has done that—it usually feels like trying to collaborate by using the PM's RDP-shared Windows desktop, covered with directories and text files arranged just so.

It is not the "easy way" to them, it's easy for you, and only you—otherwise, they'd use it! If your devs are any good, I guarantee they're communicating a lot, just not where you want them to, because it is not easy for them. Slack, email, git logs, PRs, quite possibly a shadow-ticketing system that's not a resource-hogging, confusing pile of crap in really pathological cases (probably the one attached to any Web-attached source management system you're using)

I agree that status needs to be communicated, but if that's more than about weekly under normal circumstances then it's because someone's screwing up, and it's worth remembering that your "easy" as someone who's in Jira (or whatever) all day isn't someone else's "easy".

Their "easy" would be you letting them use a ticket system they find actually-usable, and then reading that and translating anything that's happened there, into the one that you like but that doesn't work well for them. Or just figure out a way to use the one they like—you're one person, they're several.

[EDIT] It's also worth considering that those kinds of high-visibility-to-managers systems are always going to be a bit bullshitty. People will omit things or even lie on them at higher rates than they will on purely-internal communication tools, which is part of why people don't like to use them for their actually important communication within a team. Letting the team communicate where they like and then translating that into Manager in the high-visibility system will get you more-accurate information, and you can decide what to do with it.


That really depends how short your management chain thinks the intervals are


I found the scrum master


Ha. No.


Do Linux kernel developers do that?


I recently pushed back on discussing if an already-completed ticket was really a bug, or a feature to work around a limitation in the browser.

I mean, that ticket was messing so hard the tech debt statistics! Or so that claimed the PM.


You’ve never wasted a few minutes on whether a ticket was “critical” or merely “high?” or truly a blocker?


> whether a ticket was “critical” or merely “high?” or truly a blocker

Wait until they start adding additional categories like critical blocker, high blocker, severe blocker, exceptionally severe blocker, etc. etc.


Now apply that category soup to tracking both priority and severity.


Infinity blocker, infinity + 1 blocker


I certainly have, but I have rarely regretted spending the time to prioritize my work before starting my work and/or discussing the same with my team. Like pretty much all work of all kinds, there is variance in how long it takes and how effective the outcome is per person-minute.


These categories on ticket have little to do with me prioritizing my work. There are thousands tickets in each of those categories.

>spending the time to prioritize my work before starting my work and/or discussing the same with my team

And in the past, I did regretted opening unnecessary discussions quite a few times. I learned not to do it, because it ended in endless bike shedding or conflicts and there were no special gained insights. Turns out, I can do trivial decisions by myself.


This seems like a highly dysfunctional state of affairs. Maybe I've never worked at an organization big enough to suffer from this kind of thing.


Exactly, there’s a fine line between prioritization and bikeshedding.


If ticket priority does not matter, then why do you care? Set them all to single priority and don't think about it.

If priority does matter, then why "waste"? Lets say you get rid of tickets.. then your statement becomes:

"You've ever wasted a few minutes on whether a bug you found is worth mentioning in release notes? Or if it truly should cause revert of deployment?"

When said this way, doesn't seem like "waste" to me, rather a regular part of the job. If the person working the bug doesn't know how bad it is, then who does?


> If ticket priority does not matter, then why do you care?

Because when you have a ticket priority system, there is often someone external who cares deeply about ticket priority. And reporting requirements around ticket priority. And metrics about ticket priority over time.

If you've never been pulled into a meeting with Comms and Legal to discuss retoractively whether a (completed) ticket should have been labelled High or Severe... count yourself lucky


> You’ve never wasted a few minutes on whether a ticket was “critical” or merely “high?” or truly a blocker?

Calling "deciding on how to spend your time" a waste of time seems a misnomer.


But ... that person is not deciding how he will spend time. He is deciding which labels to put on ticket. What he will do is not directly related to that.


What's a priority but a way to decide what to do next? The fact it's stored as a label on a ticket doesn't seem particularly relevant.


The discussion over what priority label to put on a ticket has very rarely changed my opinion on what the actual importance of the ticket is, and I'm generally going to pick what to work on based on that, not based on the label.


It is a way to categorize tickets. It somehow influences what is going to be done next, but it is only one of many factors.

One project manager in our company started to actually use it for prioritization, the higher the priority the sooner it was done. Soon after, literally everything ended to labeled critical.


People shouldn't be able to label their own bugs/features' severity or importance. They should be able to label it with severity or importance to them, and the team responsible should be allowed to triage accordingly.


Absolute priority quickly becomes washed out - everything gets shoved to one end of the range.

A useful priority scheme might be, insert the ticket in the list of open tickets by urgency and importance. Something like that, that you can actually make arguments about and compare.


Almost every software company I've ever worked with had this insidious "priority inflation" that couldn't be stopped. It works like this:

We start out with some sensible definition of priority for bugs: P3 = nice-to-have, P2 = low-priority-but-ship-blocking, P1 = emergency-fix-this-now. Bug intake goes on for a while under this system. Some bug filers don't feel their P3 or P2 bugs are getting worked on, so they "promote" those bugs to P2 and P1. That'll show those engineers my bug is important! Now we seem to have more and more P1 emergencies going on, and the team is struggling to just get through those. Nobody knows which ones are actual emergencies, and which ones are just "somebody being passionate about a bug".

Soon, we get an actual pants-on-fire production emergency. This emergency is more urgent than any P1, so we call it P0! Now we finally have a way to mark real emergencies, because the bug database is now overflowing with P1s. Soon people realize they can deem their favorite bugs as really-really-important, so they promote them to P0. Eventually, the database is now overflowing with P0s, and nobody knows what's really urgent. Then another real pants-on-fire production emergency happens...


I worked at a shop with P0, and then there were too many P0 tickets, and then you just worked on whatever the CTO told you was the _actual_ highest priority ticket when he stopped by your cubicle for a chat.


No one got fired for making something a P0. That's the problem.


Seems like an easy fix.

1) Allow developers to change the priority, i.e. downgrade P0 to P1 or P2, with all subscribers notified. Optionally, always downgrade to the lowest possible priority.

2) Shame people for inappropriately using P0. After a few strikes, remove their ability to do so.


    How long do your legs need to be? Long enough to reach the floor. 
How much Jira (or other tool) is needed is a very subjective thing, but when you focus on the outcomes it can become clear if you need more or less.

Does any of your manager, Product Manager, Project Manager, skip level, or teammates create unneeded communication overhead asking what the status of something is and when it will be done? A planning tool should communicate that.

Are deadlines being missed or visibility into what is actually being done missing? Planning tools should help with estimation and revealing how much complex work is being done.

In a lot of ways these tools are not going to make the work faster, but instead make it so that the human side is appeased. It reduces anxiety of managers, it creates an understandable evidence of work (most non-technical folks cannot tell the difference between a good and great implementation just by observing the app, but they can understand a ticket that explains a refactor). It drives alignment, communication, and buy in.

The fastest a developer can go is alone in a dark room with no interruptions. But that doesn't scale. Even if that engineer is a 10x engineer, you still need a different system when you want 11x development. That's when planning, communication, coordination, allocation etc. all come into play.


I don’t know. Tickets can still be busy work depending on when you demand them to be done. Sometimes a ticket might best be handled at a different stage in the project to give it the time and context it deserves. If you are just closing out tickets, sometimes out of context and as fast as possible, you are doing busy work.

This could just be bad ticket management with where I work. Or we use tickets in a less standard way. I’m not sure, I work in fpga design so it’s not like a user submitted bug, it’s a request from one of the 1000 review meetings.


Yeah, in my experience writing complete tickets forces people to actually think through designs and trade-offs. It also has the nice benefit of exposing their thinking to others in the organization, who can weigh in and go, "Oh, if you're doing that, we have to do this on our project."


It really depends on if tickets are being written as an input to the work product, or as an agile mandated box ticking exercise.

Do you spend more time wrangling over the ticket content or the format? Do you spend more time discussing context & requirements, or story points? Etc


These examples imo are often sources of added fluff to process. The goal of the presentation is to get the point across. Unfortunately, I see too many people make these terrible powerpoints, where its clear they spent too much time making the template sexy and not enough time considering what content the content is. My favorite powerpoints are the ones where people use the default white background and text, and just put up a single figure per slide and describe them versus talking off bullet points with a bunch of junk imagery. If I am reading a sentence on your slide, I am incapable of listening what is coming out of your mouth at the same time. Basically, the slide deck should only take you as much time to make as pasting your figures over to it.


Everyone is different. The key is not forcing people into your own worldview.

Some people do better with documentation or tickets or code or meetings.

The point is that forcing people to do shit they don’t want to do will backfire and make teams unhappy and unproductive.


Everyone is different, but it doesn't matter that much.

When you have a small team, you can often organize the work the way people prefer. Then you'll find that people who can be incredibly productive under ideal circumstances are actually quite common.

But as the organization grows, you have to focus more on the process and the structure. Individual productivity doesn't matter if you can't channel that productivity to advance the organization's goals. You rely increasingly on people who can work productively within the system. People who thrive in a wide range of environments, even when they would prefer having things organized in a different way.


Why does the organization need to grow?


Yes but I've also been buried in presentations, diagrams, and ticket management that don't contribute to communication. That's doubly wasteful because not only is time wasted making all these artifacts, but even when produced they still don't improve understanding. Might as well have a chatbot write them, they couldn't be worse. Ticket management fails to keep anyone updated when it's just a performative way to make managers and execs believe they are seeing progress when in fact the ticket board is a fiction unrelated to real effort.


I've discovered that this can be a deflection tactic for some. Usually it happens in a situation where I try my best to explain a part of an app or system. The other person is overwhelmed or confused but doesn't just say that, and instead kicks the can down the road by saying there is a lack of documentation to reference or are in need of diagrams. When I then take the time to add info to a wiki or spend time diagramming concepts with those developers, it seems to not help aid understanding at all. Then I realize I just wasted a lot of time.


I think there is a balance but yeah it isn't good if no record of "where we are" exists.


Yes but I think people overestimate how automatable this actually is. Where we are context depends on if the audience is -

* The next developer to pick up the task where you left off

* Your technical lead asking for update

* Your manager needing an update for his manager

* Product management wanting to know where we are on some feature

* End users wanting to know when the bug fix / feature they asked for will be in their hands

Everywhere I have worked, we had multiple apps/ticketing systems/etc all trying to roll up / slice & dice data to get to the above.

In the end it just turns into talking to management pinging the next level below them for adhoc status.

Why? Because product is too ignorant to open Jira nor maintain status themselves. Because management above the line manager level is apparently incapable of opening Jira either, let alone 2-3 levels up. Also no one wants to hire real project managers anymore to maintain all the different views & send the weekly updates they demand to receive.


And remember, all of the above is a symptom of being in an organization where someone more important than you says "I don't have time to look at <insert reporting system>, tell me what the status of <deliverable> is".

Fixing this from the bottom up is better accomplished via updating ones resume & LinkedIn profile.


Are your tickets even designed/written for consumption by product/management?


Well they were more rigidly formatted for product consumption with Acceptance Criteria, Milestone->Epic->Story hierarchy creation to roll up to larger efforts, tags, Ready For Sprint criteria, standard story point sizing,

But very little detail on how one was technically to do the task, or time spent discussing technical options & tradeoffs.


I’m a big fan of putting more time and effort into communication.

I just think that there’s an incredible set of decreasing returns after about 30 minutes into building any diagram or presentation, for most people and most use cases.

That’s why quick whiteboard or lucidchart or Miro sketches are so powerful - and are designed to communicate in the moment! - and most PowerPoints, swimlane diagrams etc which have tens or hundreds of hours of work are like polished turds.

Very few diagrams or presentations show history and almost none are ever updated to show the status of things today. Which means that they just cause confusion. Generally, someone starts again and creates something with new blind spots and which takes about as much time again to create, and is out of date before others see it.

Drawing and presenting is mostly interesting if the people who are present for the drawing or description process can go forth and explain, draw or present it in their own words or images, and therefore communication has been achieved; this seems to be very uncommon in most drawing and presentation-heavy environments I’ve been in though.


Had many times where I saved a company months of work by forcing a meeting to lock in UX requirements. Basically go through screen to screen on a whiteboard what should happen.

This almost always leads to major changes to the whiteboard during the meeting.

Had many times were I couldn’t get company to do this exercise. First time leadership sees UX is on completed project.

Team then spends months rewriting application. Everyone generally pissed.


The only 10X engineers I have ever worked with were the ones that helped get 2X out of the five normally 1X engineers they worked with.


> Ticket management is not busy work, it's a necessity for everyone to keep updated.

Yes and no. If I oversimplify one of the important Lean points, you can divide activity into 3 buckets: 1) value-creating, 2) necessary waste, 3) pure waste. It's important here that "value" is always measured from the customer perspective.

For example, imagine a hamburger joint. You have ordered a cheeseburger. The person at the grill cooks a patty for you, puts some cheese on it, and assembles a burger. Then somebody else walks that burger to you. Except they get distracted after they've picked it up, so they end up walking to the back before coming up to give it to you.

Making the burger is value creating. You wouldn't want a raw patty, and you want it put together right. Walking the burger to you is necessary waste, in that moving the burger does not increase its value, but we have to do it to deliver value. The little stroll to the back is unnecessary waste in that you could receive the same value without it. Make sense?

With that framework, let's think about software. Ticket management is not a value-creating activity. If I do an extra hour of ticket management, that does not guarantee increased value. At best, it's necessary waste: I just can't figure out how to get you what you want without N hours of ticket management. But quite often it's unnecessary waste, labor performed for some purpose other than customer value. For example, a lot of planning activity is about making high-status people feel important. Or part of somebody's ongoing battle for increased status. Or the downstream consequence of previous unaddressed failures causing distrust.

So can ticket management be necessary waste? Sure. But it's often pure waste. I've done whole companies with no more ticket management than you get out of a bunch of index cards on the wall. [1] And we got there by relentlessly cutting the waste of heavier processes, something that a lot of companies won't even think about, much less attempt, because there productivity is relatively unimportant.

[1] e.g.: https://williampietri.com/writing/2015/the-big-board/


If the ticket is a direct conduit to the customer, I think you could argue that ticket management in the form of asking clarifying questions so that you build the right thing (or fix the right bug) is creating value?


People argue all sorts of things here. People argue that building large specs so as to get approval of the grand poobahs to fund the project to build the thing is creating value. But the easy rule of thumb is "If you do more X, does a customer receive more value?"

Another way to look at it: If I put the customer at the bottom of a well and the only way to communicate is by cranking notes up and down in a bucket, does turning the crank constitute a value increase? Mainly I think it's focusing on the wrong thing. Why is the customer in the well? Maybe we should let them out. Maybe if we have a question about how they work or what's good for them, we should visit them and study them as they work and then maybe ask them a question or two. And then, most importantly, ship something and see if it really does make things better.

So no, even in that narrow and unfortunate case, that is not creating value. It is at best necessary waste. Building the thing and giving to them, if it turns out to be valuable, is creating value (probably with some waste mixed in). The fact that communication is through a constrained and stilted channel is just a sign there's pure waste in the necessary waste that we can try to remove.


These idiot, overpaid engineers don’t understand how important tickets & tracking metrics are.

As if turning a measurement into a target could make it cease to become a good measurement!


Yeah, these things are all part of being a team of 1x engineers rather than a team of .5x engineers. If you have a single 10x (and I've worked with some) then it's not important but those guys have their own issues.


1000%. A lot of this stuff seems like busy work to junior engineers and bad senior/staff engineers. But this is how you spend a few days to save months of wasted effort.


The important part is that you do it for something that's not all that important then make sure to get the project dumped before any real progress is made.


Engineer who implements correct, comprehensible code but doesn't manage ticket statuses is more valuable than one who manages ticket statuses but scatters the codebase with technical debt and confusing abstractions/code. If "better communication" means spending an extra 10 hours with the latter dev to correct/re-teach them, then yes, communication is the problem. The most time I've lost at work is correcting/teaching engineers who eventually got let go due to low performance.


I don't really think the first part of your comment is true, at least not in my experience. All other stakeholders would prefer someone that updates their tickets and communicates what they are doing effectively, even if they produce absolute garbage, bug ridden software.

I've personally only ever seen someone removed from a team for having poor technical skills once and it was under pretty extreme circumstances. While I've seen many good (from a technical perspective) developers removed because they thought they were somehow above doing the everyday "busy work" like ticket management.

Unless you work alone, then refusing to do non-technical work is just saying you're going to let the rest of the team do it. You're much more likely to be removed or have your contract ended if the team doesn't want to work with you.


Without going into anything identifying, what exactly were those circumstances? I'm imagining something like this happening, but at the same time I can't help but think if its a technical skill issue, handing them a book on the relevant technology and telling them studying this book is their job for the next two weeks would be better than trying to roll the dice again, put out a new job ad, interview, vet, rehire, and hope they aren't somehow just as technically incompetent as the original engineer.


You have never seen JIRA properly configured then.


It's busy work if you do it more than 1 hour any given week. If you do it full-time, you're something like a -10x engineer.


Yes. Disorganization is the largest cause I’ve seen of preventable waste.


But at what point does that communication cost more than just hiring somebody else who needs less hand holding and less "communication" to understand what is going on and figure out what to next.

I say this because there always seems to be those who don't need this. And it's the ones who need this who never seem to produce as much or are able to solve the problems on their own.

So I ask. If you could hire people who need this "communication" or hire people who don't need the "communication" and they both can get the job done, why would you hire those that require time consuming processes.

Good teams don't need Jira, good teams don't need power points, good teams don't need all the hand holding. These are tools to include those who can't and often bring minimal usefulness to the table.

Poor communication is code for "I have no clue what I am doing and am going to blame others for why I am not useful, but I don't want to admit to others I have no clue what I am doing.". Next time you find your self thinking somebody is poorly communicating, try this in stead. Say "Hey, I don't know what I am doing, I am lost, where can I start? More often than not this "poor communicator" is going to be able to direct you to a task that will not only make you useful, but also not require much more than 5 minutes of exchange and as a result you will probably learn something that will make you more useful in the long run.

> in my experience it has been the sub-par employees who are the ones that don't do this.

To directly call this out, the sub-par are often the ones doing all this stuff, because they simply can't do the actual work. Sub-par is probably not fair, as a good manager will build a team with a few of these folks to tend the toil. So they are useful in a way.

Also you all can think back on the time that you hired somebody and they knew more than just about everybody about how the product works and should work within just a few weeks. This person clearly did not need the documentation, they simply read the code -- the code is the documentation -- and the quicker folks stop thinking like tis anything else other than a big manual the faster they will be able to learn new code bases and become useful. The constant translation between weird human social ideas of what is good communication and a solid structured communication such as code its an incredible waste of time.

Just remember, your job is to write code to tell a computer what to do, and if you can't also read that code to figure out what the program should do, you might be computer illiterate which makes you less valuable than somebody who can both write and read code in the same manner as the systems that will consume it.

If you have ever had somebody tell you "it's like you compile the code in your head" you will know what I am talking about.


I think you are confusing communication and competence.

How do you even know what to work on without communication? Most real systems are used by real people who aren't the developers themselves. Product owners, business development, customer support, and a myriad of other people all usually sit outwith the developer teams. Are you talking directly to customers for feedback on feature development?


I think I am saying those with out competence need the extra communication.


A lot of toxic negativity in that post.

Sure bad engineers exist, but you know what is even worse than the -10x engineer: the contagious jerk.

https://www.inc.com/jessica-stillman/studies-being-a-jerk-is...

Yep being an asshole spreads like a disease within organizations. Avoid these guys like the plague.


I disagree.

For me this outlines the caveats and pitfalls of software development and management.

There is real truth to some of the authors points showing real paths that emerge naturally.

If you're going to gaslight him by inferring anyone who is critical is an asshole, maybe you should ask yourself why you're taking the article so personally...


Am I saying that anyone who is critical is an asshole? Where? Seriously?

I find that the article hides a deep aggressivity towards overall mediocrity behind a thin veil of office-space-like humour. And I think that aggressivity is contagious and so not a good thing to spread.


You didn't say it outright, but it was exactly what I inferred from your comment as well. You said "toxic negativity" which comes across as a moral judgement, and anything that follows comes across as the result of that judgement.


It was a judgement. I do think the author is being a jerk here. But people can be critical without sounding like jerks.


I don't think it's reqlly fair to read a person's frustration piece and assert they probably have a character flaw. I don't even see your issue with the article, really. I don't think it's targeting anyone specifically and it seems to be about doing things in excess. Maybe just the idea of people who are consistently negative contributors rubs you the wrong way.


Maybe avoiding to use pejorative wording would make a more convincing argument to promote a view still accepting meaningful advises through criticism, while judging unethical any form of essentialism view which reduces some people to despicable traits, rather than presenting a situation where some people are entangled in abject behaviors.


I agree. Be professional. Assume good intent and keep your opinions for yourself when nobody is asking for it.


>I find that the article hides a deep aggressivity towards overall mediocrity behind a thin veil of office-space-like humour. And I think that aggressivity is contagious and so not a good thing to spread

The post came off to me as frustrated not aggressive. I think you are overreaching here, and this can create very toxic environments as well. Disagreements, frustrations, and stress are just part of being a human. They're part of getting work done. Being toxically negative or positive is not a good thing both in the workplace and out of it, and this post was not aggressive, just being frustrated. Frustration can be good! It signals things that we need to talk about, so we can focus more on them. Hiding them only makes the problem worse.


You're going to have to be more specific at this point.


I agree with most of the author’s points, but the post is overly negative in my opinion. It’s blaming other people for the problems instead of digging into why these problems come up in the first place. Why do managers waste time with busywork? They need insight into the process. If you look to criticize without understanding you’ll always find plenty of material to blog about, but you’ll just create new problems and never fix anything.

The author probably thinks these issues are caused by bad people instead of bad processes, which is why he doesn’t suggest realistic fixes.


> The author probably thinks these issues are caused by bad people instead of bad processes

Author here.

This is an excellent way to phrase a subtle point that I couldn't figure out how to fit in the piece.

I think that -10x engineering is not someone you are, but something you do. And even more commonly, it's something that organizations do for periods of time.


I think this is something that would've been great to include as an intro, and would've completely removed the negative atmosphere that some people (including myself) got from the article.


how to become..


The title makes a lot of sense because of the meme “10x engineer”. That is also wrong - being 10x more productive is also something you do, not something you are — but I see the point in following that template.


Gaslighting is a pretty serious accusation, its weird to see you use it so casually.


Very overused in online discussion. It requires intent which there is virtually never evidence of. Without that it might as well just be a difference in opinion. Its prevalence speaks to how intolerant people have become.


That’s not what he said about anyone critical is an ass, he’s say rather than -10x, worse for a company are assholes and they do exist


I can deal with assholes who get stuff done. Developers who are consistently making negative progress are harder to deal with.

-10x developers can get the just by promising things people depend on but never deliver.


Usually is easier to deal with -10x devs than assholes because they are likely devious is not easy to handle. A crapy dev can be dealt with when you present their git commit to the manager/lead


Well put.


I worked with one person who weaponized pedantry. He thought he was educating everyone by being a complete stickler for his specialized vocabulary and would never just answer a bloody question, wasting everyone's time. He thought he was Socrates but he was the hemlock. Similar to a good project manager he was like a chain-saw: very effective, but you always want the tool pointed away from you. It also meant you really thought about whether you could get what you needed done with any other tool rather than pull out the chainsaw. Ultimately this kind of behavior is a productivity sink; forcing everyone into your rules because it'll be so much better when everyone just complies with how you need the world to be means getting worked around and giving the pedant's work to someone more pleasant to work with.

Please note: I'm not dinging people who sincerely need structure to help them function. This was a conscious choice just to be a jerk because in that person's opinion everything would be great as soon as we all thought exactly like he did.


The contagious jerks are often results of working with -10x engineers. At some point you become as such, if you don't quit the company before that. There are "bad engineers" and then there are -10x engineers, it is a real problem if the company keeps such engineers

You should try working with -10x engineers and see how your feedback is being ignored as tech debts are piling up, products are continue to under deliver and missing deadlines.


This hits close to home, but unfortunately Occam’s Razor will get applied.

It’s an unfortunate reality that engineers (not their managers) are responsible for knowing how to handle themselves in the worst of situations so they don’t become the scapegoat at the cost of their health and security. Trust me, I’ve been through this situation and have been burned out by the [apparent] low standards and [apparent] double standards.

The prodigal charismatic leader can save the day but become a crutch too much relied on. And I get it, with all the shit we deal with in life, things ought to work out that way. But eventually that leader won’t be there for you (or even in the picture at all) and you’ll be in big trouble, especially if you spent many years relying on them for help.

Working remote for a high pressure early stage startup is a good recipe for this kind disaster if you aren’t great at managing stress or conflicts at work.


I'm going through this at the moment at a startup...

I thought I could count on the charismatic leader to save my bacon by only calling on them for help when when things are visibly on fire and my own minor charisma hasn't been enough. In the end the leader didn't show up and now I've got a HR complaint against me for following up consistently when the fire didn't get put out. The whole thing has been fairly stressful because I'm struggling to understand the particular social dynamics, my best guess is it's just power protecting power, but I am naive/delusional enough to want to believe there is more to it. Now I'm taking a month off from work to try and unwind a bit.

All of that was just a long way of saying that you never know when you'll need to call on your stress/conflict managing skills, so best to keep them sharp at all times. I thought my skills were already good, but that was quickly revealed as false when challenged by tougher opponents :).


Step 11: Call out any attempt to make engineering more productive as toxic negativity.


Step 12: have a meeting about it

Step 13: have a blogpost about how inclusive and equitable your company is.


Step 14: Hire an entire team who’s only job is increase office drama and reduce colleagues trust


Step 15: Make absolutely sure your team and any prospective hire knows you will hire to fill quota vs get them the most competent co-workers, ensuring mediocrity.


Step 16 skip step 16.

step 17 Recognize that questioning the status quo is a critical part of progress and growth, and that "toxic negativity" is often a label applied to dissenting voices to silence them.

step 18 Acknowledge that engineering, like any other field, can benefit from improvements in productivity and efficiency.

step 19 However, also acknowledge that a singular focus on productivity can lead to shortcuts, neglect of quality, and burnout among engineers.

step 20 Question any proposal that seeks to boost productivity without considering its potential drawbacks or unintended consequences.

step 21 Encourage open and honest discussions about the tradeoffs involved in increasing productivity, and welcome feedback and criticism.

step 22 Remember that criticism is not the same as negativity, and that constructive criticism can help identify problems and find solutions.

step 23 Avoid dismissing criticism as "toxic negativity" or labeling critics as "problematic" without engaging with their ideas.

step 24 Recognize that diverse perspectives and voices are essential to a healthy engineering culture, and that dissenting opinions can lead to innovation and progress.

step 25 Cultivate a culture of respect and openness, where all voices are heard and valued, and where criticism is welcomed as an opportunity to improve.

step 26 Challenge assumptions about what constitutes "productivity" and explore alternative approaches that prioritize quality, sustainability, and employee well-being.

step 27 Remember that engineering is a human endeavor, and that the well-being of engineers and the communities they serve should be a top priority.

step 28 Take a shortcut and jump directly to step 42 for your surprise.

step 29 Recognize that productivity gains should not come at the expense of ethical considerations or compromises in safety standards.

step 30 Encourage ongoing learning and professional development among engineers, so that they can remain up-to-date with the latest technologies and practices.

step 31 Ensure that engineers have access to the resources and tools they need to be productive, without sacrificing their mental or physical health.

step 32 Celebrate successes and learn from failures, without casting blame or assigning fault.

step 33 Remember that productivity is just one aspect of a successful engineering organization, and that teamwork, collaboration, and communication are equally important.

step 34 Foster a culture of trust, where engineers feel empowered to speak up and share their concerns without fear of retribution.

step 35 Recognize that engineering productivity can be influenced by external factors, such as economic conditions or resource constraints, and that some challenges may be beyond an individual's control.

step 36 Encourage interdisciplinary collaboration and cross-functional teams, to break down silos and encourage a diversity of ideas and approaches.

step 37 Always be open to feedback and criticism, and recognize that even the most successful organizations can benefit from continuous improvement.

step 38 Emphasize the importance of work-life balance, and support policies that allow engineers to take breaks, recharge, and avoid burnout.

step 39 Encourage knowledge sharing and collaboration across teams and departments, to foster a culture of continuous learning and improvement.

step 40 Seek to understand the root causes of any resistance to productivity improvement, and engage in constructive dialogue to address those concerns.

step 41 Consider the long-term consequences of any productivity-enhancing measures, and make decisions that promote sustainable growth and development.

step 42 Realize that in this message only steps 16, 28 and this one where not generated by ChatGPT.


Ah, step 42. Well done.

I was wondering why all these steps were generally GOOD things to do instead of the BAD things that all the previous steps were (1-15). And I was wondering why they all sounded the same.


They sound exactly like the stuff the people from step 14 write, while doing the exact opposite.


This.

I've seen the behavior OP calls out more commonly associated with toxic behavior than the reverse.

The suspect the people who manufacture make work for others to justify their existence are often aware of their redundancy on a deep level. That frequently manifests in the form of toxicity when their make work is challenged. You're challenging their meal ticket and house-of-cards identity all at once.


He isn't saying that. Maybe you've never had the misfortune of working with someone who is just always negative but it is really draining. Those people aren't trying to make engineering more productive, because that would involve being positive and looking for solutions instead of just constantly complaining which is what they actually do.

Fortunately they're relatively rare in my experience. I've only worked with one or two.


Author here.

I don't want to empower jerks.

Anything particular I should change? Or is the structure of the essay too cynical overall?


Software needs to be used by users. It’s unlikely your developers are so innately talented that everything a user wants to do is obvious and intuitive. So docs, etc matter.

Other teams like marketing need to make schedules because they spend huge amounts of money doing things to make your product successful, that have nothing to do with code. For example, launch events, advertising, conferences, executive briefings for key customers, etc. Planning, dates, progress reports, etc are all needed because unless you are a lone open source developer, you have to work with others.

Users will use your software in unexpected ways. Hackers will try to break it. And users will expect it to work flawlessly when they need to use it to generate their report for their VP meeting in 5 minutes. Testing is critical to ensuring that your software doesn’t suck for your users and make them hate you.

The business you work for probably doesn’t exist with the mission to leave you alone and let you code. They want to solve a customer problem by creating, marketing, selling and/or supporting a software product. Your management wants to know that all the money they are spending on your salaries is getting them a positive ROI. Letting them know what you’re doing and providing them with content about capabilities and features that can be used in marketing, makes them want to keep paying you. Missing deadlines, failing to deliver non-code deliverables, failing to provide status, and being jerks in general make management want to cut your project (and maybe your job) and do something else with cooperative people.

Yes, there are pathological extremes to all of these things and to the points you raised in your post, but I see too many developers who think that developing software is just about coding and that everything else is extraneous. In reality, the vast majority of your time is probably best spent NOT coding.

[ed] spelling, paragraph break


> "They want to solve a customer problem by creating, marketing, selling and/or supporting a software product. Your management wants to know that all the money they are spending on your salaries is getting them a positive ROI."

This is all true for the somewhat narrow field of commercial software development for the consumer end-user where profit margins determine success or failure in terms of paying off the capital investors, but many organized engineering efforts have other goals, e.g. replacing some organization's decrepit internal data storage, archiving and retrieval system where robustness matters more than anything else, or designing a research program aimed at solving a complex technological problem, writing software that controls an electrical grid, and so on. Applying the maximize-short-term-profit mentality to such problems generally doesn't end well.


Well said. I work on engineering stuff but I spend a huge amount of time encouraging people to understand the other parts of the business and their needs.


No changes needed, it grabbed my attention and stood out. You clearly know what you are talking about.

But assuming your goal is to make a positive impact in the industry, managers need to be able to read this and get actionable takeaways.

You’ve got my attention as an engineer, but a follow up post for each of these examples would be the place to close the deal. They of course would have to be written with a different (and dare I say more constructive) slant. It needs to be something someone can take to a manager and get a chance of some good conversations. It can still be persuasive, but in order to be actionable I would expect specific examples, clear definitions of the issue, and recommendations that tend to be familiar or standard.

I would do plenty of research too. Because for one thing you need to ensure you are giving correct advice. But it will provide a massive boost to your credibility to include that research in the posts. It will also save your reader the trouble of doing independent research (which they likely would not have done in the first place but still require it for actionable change, or the idea gets shelved). -10x engineers can leave managers no time to do that kind of diligence, but the managers still know better than to blindly trust what someone says on the Internet. Back up your arguments with evidence where possible.

I know it’s a tall order but if you have the time to put that much quality into a series from this, it could be great. I only say this because from what I can see, you do know what you are talking about, and clearly have passion about this.

I look forward to reading anything you do come up with, whatever the approach :)


I've been writing software for 20+ years. I think that article is pretty funny and on the nose. I'm currently in the midst of fixing an issue we just discovered added by a -1x engineer 17 months ago. He's the gift that keeps on giving.

If you're offended, this article is probably for you.


It's brutal.

You want to sound like an Office Space character. But in Office Space, there is no mission, there is no good engineering to do. So all the douche-y people who get in the way of work are more pityful than enemies.

But here, you believe in good engineering yourself, and the -10x engineer you encounter get under your skin. So you're venting online about why you hate their guts (in a funny way, for sure, but still the aggressivity transpires)

It's understandable. I met many bad engineers. They're a nightmare to work with. And yes, many will have a net negative impact on overall productivity. Still, coining the term -10x engineer and making an aggressive piece about all the ways they can screw your work life is not exactly healthy.

Yes, I think your post is going to be empowering jerks. What did you think? That this was just a "funny, haha" post? There are many people who are angered by bad engineers in their daily lives. This is just adding fuel to their anger. This is the Jerk effect taking place. This article reads like a jerk venting, and that language will spread to frustrated people. You can already see it in the comments here.


There's a lot of projection going on here, as far as I can tell. The author is about as neutral as possible in describing these traits / behaviors. None of these traits are mutually exclusive with being a jerk, and in my experience, more often than not the people that exhibit these traits tend to also be jerks to compensate for their inability to get high quality work done!


If you can't see the negative bias in calling anyone a "-10x engineer", I just can't discuss the matter with you...


If it were directed at a particular person, sure. Otherwise, the author is describing negative traits and behaviors. Have you ever taken any management training? This is the quintessential way of discussing these sorts of things neutrally. Yes, you'd never want to call an individual a -10x engineer, but this is a random article on the internet. It's okay to be a bit headline-attention-grabby and stylistic so the article isn't dry and corporate.


You know what. I do agree with most points in the article. And I do find them funny.

Yet, I also met an awful lot of terrific engineers who were brutally aggressive towards anything they felt was stupid. And in my opinion, those people cause at least just as many problems as people who perform really poorly.

I think the tone of the article (cynical, exagerating bad traits, etc.) promotes that kind of toxic culture, while not bringing much to the table in terms of fighting mediocrity. That is all.


Fair enough, thanks for clarifying. I haven't run into too many of those people (brutally aggressive and terrific engineers). The toxic people I've run into spent all their time trying to look smart to cover their incompetence.


It's fine. It's clear the purpose is to list a bunch of traits and observations you've made over the years. It's concise. Trying to fluff it up would only make it less readable.


The only thing you should change is your expectations.

No matter what is written, someone will find something wrong with it. Expect those people to show up and sometimes be very loud.

I appreciate your efforts to receive feedback. In this case, you'll find the majority of people aren't complaining, just a few are. So be happy that you wrote something that so many engage with!

The only thing worse than writing something that people are critical of is writing something that's completely ignored.


I don't think it's too cynical overall.

I can't recall the quote verbatim, but somewhere in "The Glass Bead Game" a great teacher says that it's difficult to work with intelligence--you have to be lucky to identify it and then the best you can do is get out of its way. Stupidity, on the other hand is easy to identify and easy to correct on a case-by-case basis.

There's value in inverting a problem like you've done in the article. It might not be symmetrical. Things that might not have been obvious in the original become obvious in the inversion.


Huh, that's cool. I would say:

- if you can't define "jerk" well, you're playing into office politics. Who decides who the jerk is?

- there's a typo: "A blog post by the studies authors" should be "A blog post by the study's authors"

- the "studies" linked to seem fairly dubious. Most people who are rude are not so because their boss is. Only 25% said they were. Also, it's qualitative survey data, which it's rarely a good idea to draw anything but first order conclusions from (e.g. yes Donald Trump won the 2016 election, so we can conclude that he got the most votes, but we can't infer from that that voters like candidates with orange skin). And as self-reported data, it's hard to base much on it at all.

- the implication is that removing all this would be the best thing, and that's probably true: having some wonderfully polite geniuses is no doubt the best option. However that doesn't mean we should necessarily prioritise politeness over raw ability, as at least for some tasks, a solitary person who's very smart can do things that even teams of others can do.


don’t let the -10Xers get you down it’s a delightfully funny and insightful piece


You could have really shortened your list by just starting off with 'Use JIRA'

Also, the thing about wasting 10 weeks of wages on cloud computing was confusing because it mentioned buying exotic hardware and in my experience the options via cloud computing are never exotic, and never have a decent amount of RAM.


I'm surprised you don't stress more on the habit of always picking the popular google-scale tools even for in smaller companies. Or the language or framework of the month lol.


I think it's great and on point. No need to change anything.


The article is good at making a point of what is bad and for the fun of it. However, it is not successful at compassionately explaining what one should strive to instead as there is no simple negation of the points being made.


It is not the responsibility of a person pointing out problems to also solve them.

Granted, pointing out problems is generally much easier than solving them, and correspondingly less valuable. As I like to say, stand up, spin around, and point at something randomly. You're pointing at a problem of some sort.

But that still does not incur a responsibility to someone pointing out a problem to also solve it. It's a popular idea for some reason but not one that can stand up to scrutiny of any kind.


If anyone actually had the solution to this problem, they'd probably be a billionaire with the most productive software company in the world, by a large margin. Solving this problem is basically the holy grail of software development. Personally, I'm not sure this problem can be solved, since it's a product of flaws in human psychology: fixing it would mean changing humans into something non-human, or just eliminating humans altogether and having AIs do these jobs.


No but it is their job to understand it, otherwise you’re not contributing anything valuable, you’re stirring up drama. If I point to a light switch and call out it’s a problem that does you no good unless I tell you why, and why it’s like that in the first place.

The problem with the article is even though it’s right it makes no attempt to explain why, and blames bad people for the problems instead of understanding why they might be acting like they are.


"No but it is their job to understand it,"

No, it isn't their job to understand the problem before pointing it out either. That also does not stand up to scrutiny in the slightest.

If I call my township to report a big pothole, I am not required to submit an explanation of how the pothole came to be. This is a ludicrous standard only deployed when situationally convenient for someone, not an actual principle.

Again, the value of a problem report without an understanding may be less than one that has it, but there is no obligation to have an understanding or present one in order to talk about a problem at all.


>No but it is their job to understand it, otherwise you’re not contributing anything valuable, you’re stirring up drama

Frankly, this sounds exactly like toxic management where people are not allowed to raise issues which then blames everybody but themselves for consequential infectivity.

> If I point to a light switch and call out it’s a problem that does you no good unless I tell you why, and why it’s like that in the first place.

I I point to a light switch and say that it does not work, I do not need to be able to fix it by myself. For that matter, it is good example, because we are not even allowed to fix electric devices by ourself (workplace safety).


Taking the bare minimum of time to understand a problem before complaining about it isn’t toxic, it’s human decency that respects other people’s time. If I called out every problem with all the code I work with no one would ever get anything done, because everything is tradeoffs.

I don’t think you’re saying that you couldn’t explain why the light not working is a problem. No one said you have to know how to fix it.


Except that, demanding that people have solution, which is what parent did and "taking the bare minimum of time to understand a problem" are two massively different standards. The original article definitely clears the "taking bare minimum time to understand a problem" standard. Neither parent nor you are content.

> If I called out every problem with all the code I work with no one would ever get anything done, because everything is tradeoffs.

Obvious difference is that article did not complained about trivial issues. It complained about very real issues that waste massive amount of time.

> I don’t think you’re saying that you couldn’t explain why the light not working is a problem.

Adding "I do not see without light" is completely unnecessary when complaining about broken switch. There is zero need for it. Similarly, it is no mystery why issues in article are problems.

If you are unclear about why any of listed issues is a problem or disagree, you could have made that claim. But, neither parent nor you claimed not understanding that. All you want is to prevent people from talking about these issues.


I never said the article should have solutions, or that the issues in the article are not problems, or that they shouldn’t be talked about. If you want to assign a point of view to me that I don’t believe then this is a pointless discussion.


No. I enjoyed the article and your sense of humor. Kudos


Nothing. Your essay exists solely to be criticized, and honestly you’re on a bad / useless path and should get out now and completely rethink your life.

We are HN. We are legion. Expect us.

When I got on the site, btw, I immediately saw your choice of font and I didn’t actually read your essay.

PS: This is satire (https://en.wikipedia.org/wiki/Poe%27s_law)


>A lot of toxic negativity in that post.

Yeah, or as it's scientifically called: "realism"


I read the post, saw this comment, then re-read it again. I did not get the impression that author was trying to be negative. I think they were just trying to write in an "edgy" style. I've seen most of the things on the list happen (at least to a degree).

On the topic of contagious jerks, my experience has been that these people often suck at engineering.

For example, a few years ago, one of the product managers was super excited to recruit an engineer they had worked with before. The engineer was talked up. A real genius. Someone who would come in and do things right. He would lead a new sibling team working on a new product. I was excited. We could use the help as we were going through hyper-growth.

The engineer seemed smart, but had a very sarcastic and negative attitude. The existing architecture was garbage. Everyone's code was terrible. Even the choice of language was wrong. While he was respectful towards me and the work I had done, I saw him put down most of the people around him. I kept my distance and let him do his thing. It wasn't my place in the organization to interfere anyway.

The end result was he drove half his team to quit, delivered an absolute disaster of a system, and then left.

I've seen versions of this play out a few times. My experience has been that the smartest people are often the nicest because they are smart enough to recognize the value in lifting everyone. I know its not always the case and I have worked with difficult people who genuinely were incredible engineers as well, but they tend not to actively put everyone around them down.


It's not 0/1 problem. Obviously being asshole for no reason is bad.

But bending over backwards for bad solutions just coz you "don't want to rock the boat" or "don't want to argue" leads to mediocre product driven by whoever happens to be least polite in the team. Tiny bit off stubborness and assholery on stuff you know is right (as in when nobody can provide actual sensible arguments for other way) can be very helpful.

Also I did worked with "toxic but brilliant" ones and honestly I vastly prefer it over nice useless people. Toxicity can be managed, uselessness can not.


What's more, the contagiousness aspect isn't the only issue here. Jerks tend to cause problems for organisations for other reasons too. Such as:

1. They scare away a lot of competent workers, since many smart and talented employees won't want to be stuck working alongside an asshole, regardless of how 'talented' they might be. And given that the best employees tend to have a plethora of options for where to work, and well... you can guess how that affects the talent remaining.

2. They discourage newer and less experienced employees from learning/improving, and instead encourage them to leave. But folks who aren't necessarily the most talented developers now can very much turn into such with the right environment and incentives, which these types of people don't provide.

There really aren't any benefits to keeping around jerks, and a whole lot more downsides than people think.


Did you find yourself on that list? Because besides this explanation, there is 0 toxicity.


I find it's context dependent. Sometimes everyone is working hard and doing their best and someone's being a toxic jerk. Sometimes things are going badly wrong and you need someone to actually stand up and say "Hey, how come these requirements keep changing we've wasted months doing something that was totally useless" or "Hey, how come our AWS bill is $100,000, and hang on a second, why isn't anyone monitoring our AWS bill?" or "Hey, the core premise of this project turns out not to be true, maybe we should really re-evalaute rather than ploughing on".

Sometimes requirements are unclear and you just have to learn as you go. Sometimes the AWS bill is the last of your porblems. Sometimes you find out something you had assumed at the outset is wrong, but you still believe in the project. It's context dependent.

Also, it's often more difficult to be the person asking the hard questions than the person who just goes along with things.


I get the sense that this is an investor/bankroller that fancies themselves as an engineer, or a manager that has done a terrible job of hiring so far.


Why do you believe the traits and behaviors outlined in the article are mutually exclusive with being a jerk? In my experience, most of the toxic people I've worked with were toxic because they exhibited a number of these traits and were thus ineffective and using toxicity to compensate.


the "contagious jerk" is simply the result of a bad environment

the first one to denounce it encourages other colleagues to speak up, like it happened with the metoo movement.

http://www.quickmeme.com/img/13/13d4f6f146baa91dbc0946651ca0...


Stupidity is a moral failure. Derision of the stupid is morally justified: https://www.youtube.com/watch?v=ww47bR86wSc

The study you linked assumes the actors are not stupid.


Let me guess, everyone who criticizes you is a jerk?


People here are irked because HN is the home of CV-driven development.

EDIT: ...as proven by the rain of downvotes...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: