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

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

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.

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.

Had worked someplace for a short stint. There was a guy who'd started a couple months before I did. His work was 'revolutionary' and 'groundbreaking' - he'd been trying to build some sort of AOP-style PHP system - PHP4, mind you - without any extensions or internals work. It was just 'program this way' - undocumented patterns that encouraged copy/paste to half-way almost get you something usable (except, not really). "Build a form to take a few fields input and store in a database" example took days to develop, because... he was just winging it. Session management? nope - we'll need to roll our own, and that'll take a few weeks.

About half the team (20ish folks) were enraptured by this guy. Someone rambled about great this guy was, said something along the lines of "you know those sorts of geniuses that are so far ahead of everyone else that they can't even explain things, and no one else can quite understand it? that's where we're at, and it's just so awesome - I can't wait to learn more!"

This guy saying that was, at the time, like... the #2 guy on the team, had been there for years, and was the defacto 'team lead' for that work, and he was taken in by a huckster. The aop guy was there for about 10 months, then left abruptly - left on a friday, sent an email on monday with "i resign, i got another job". somehow, some folks were "shocked" at his "unprofessionalism". The entire tenure had been unprofessional, but few cared to label it that.

You're so good and smart that you built something we all need to use, but you can't explain it (let alone why it's good/better), everyone else plainly admits they don't understand much about it, and use the lack of understanding as evidence that they're so bad this must be genius-level work. Insane...

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

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

Having used the product (which would not-infrequently manage to make keyboard input lag by full seconds on strong hardware, ate hundreds of megabytes of ram and tons of processor cycles while idle—even worse than your average webshit "app") and putting 2 and 2 together, I'm pretty sure I could have written a list of things they'd failed to take into account, and reasons the results were so poor. It was a fun read thanks to all the details, like "oh, that's why this is so awful, I see exactly what's wrong now".

[EDIT] Though to be fair—and why I hesitated to name them—I haven't used their product in four or five years, and it may be much better now. Looks like the framework they created is called Luna.

We fired our top talent. Best decision we ever made. - https://www.freecodecamp.org/news/we-fired-our-top-talent-be... ( https://news.ycombinator.com/item?id=15474893 125 comments; https://news.ycombinator.com/item?id=32211953 30 comments)

> “You will never be able to understand any of what I’ve created. I am Albert F**ing Einstein and you are all monkeys scrabbling in the dirt.”

> And so our resident genius, our Dr. Jekyll, explosively completed his transformation into Mr. Hyde.

> He declared this in front of the product design team, developers, management, and pre-launch customers. One of our project sponsors had the temerity to ask when the problem crippling our product would be fixed.

And then follow up:

A team reborn after the fiery departure of its misanthropic guru - https://blog.solha.co/life-after-rick-our-team-reborn-after-...

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

There is also the type of "genius" who creates an overcomplicated framework as a foundation for a new project, and then leaves the implementation details to lesser minds trying to understand his work, while he moves to start another new project. He is always too busy working on a new project, doesn't have time to answer questions about the old ones. (The problem is sometimes solved by gradually removing his code. In extreme case, the library remains included, to avoid a political conflict, but the code is actually never called.)

Ah yes, if the wrong people become aware that the code is never called, better to claim that it happened as too many people had their hand in the pot, and hey, the code is still working, and the tests are passing, so you didn't realize anything was wrong, rather than ruffle feathers and say you didn't want to touch the "genius" code because it was stuck up its own ass.

I've come to think it's the biggest existential risk to doing Haskell in industry - it's red meat to org-chart climbing sharks. And the people who tend to be willing to learn and do FP in prod tend to not be politically-minded (usually due to strong principles and values), making them even weaker to these attacks.

A significant part of choosing a technology is economics of people available to hire. Who can work with that technology 5 years later, when original authors will be long gone.

Is it really cheaper to rewrite an entire working system (that took a year+ to build in the first place) than to just learn something new? I have learned a new language in order to inherit a working, hardened, well-made system before. But I am finding for certain senior engineers, the answer to "can I learn a new language" is a resounding no. The cost is infinite, so of course it's cheaper to rewrite. Plus they are incentivized to rewrite thanks to political reasons (i.e. it's a great way to get promoted).

The last time it happened, I was lucky enough to be accidentally shielded from accountability due to the organizational quagmire that resulted from the team blowing up. I basically got to do nothing for a year and make $200k. And I got to be less than useful to the principal who made the powerplay (not -10x level but I did get to spend time maintaining the existing FP system due to it having a single production consumer left). That dude did not like that I never turned my camera on. My manager also seemed pretty checked-out, so that was extra buffer.

So to summarize, I'll say that it's easy to have be prescient when you make self-fulfilling prophecies. That's one skill I've learned from senior management over the years.

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

Also it's not hard to hire Haskellers or Haskell-adjacent devs. Haskell in fact makes you stand out. Those sorts of people don't need months. I've seen people new to Haskell make their first commits within a week. And they weren't geniuses or anything. But they also didn't have an attitude about it.

Seriously, what important industrial problems does it solve? Explain it to me like to a manager you met in an elevator. If you say e.g. lower bug rate, then be prepared to show some evidence (and no, please don't compare it to Python or other dynamic languages).

But I will say that bugs in Haskell tend to be easier to diagnose (helpful at 2am) and aren't usually bad (although they can be). I have debugged Other People's Code while on-call in Haskell way easier than any other language.

And finally, the vast majority of bugs can be prevented or curbed by the type system. I find every time a Haskell company runs into a nasty bug or annoying issue, libraries that make use of the type system are made that reduce or remove that class of bug entirely. This sounds like you can do it in every language, but really what can be made a "library" in Haskell dwarfs what you can reasonably library-ify in most other languages.

Now, I can't give quantitative evidence of this because I don't even know how I would begin to measure it. But these qualities are definitely a big reason why I don't even listen to job offers that aren't Haskell anymore (going on 10 years of that soon) and I have and will promptly quit a job if the company moves off Haskell.

And then you lose 50k whenever the app crashes in production because someone forgot a nil/err check and your tests didn't catch it. Or you pay extra 50k whenever the whole team needs to spend a week on finding a race condition caused by someone accidentally mutating a shared slice, 20 layers below the place the corruption was seen for the first time. Or you spend extra 50k over the year for fixing all the resource leaks caused by missing defers. Or you spend 50x50k to rewrite everything in a more performant stack because of GC pauses (Discord) ;).

There are multiple ways a project can fail or add unexpected costs, and likely there's no silver bullet. There are trade-offs.

And, btw, as for simplicity, there are dozens of languages easier to learn than Go. E.g. scratch, basic, brainfuck. Why not use them? ;)

Simplicity of a language has it costs. Programs written in simpler languages tend to be more complex to compensate for lower expressive power.

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

It was only when a drive-by principal engineer got wind of it that there were problems. "We don't use Haskell here" was literally the only argument for rewriting it. Nobody left before then. We were hiring people fine. The problems you are FUDing around didn't exist.

In fact, the rewrite was so slow and off-target that I had to maintain the Haskell project through a peak season with a skeleton crew of two other people who didn't leave. And we didn't even have an outage - I didn't even get paged! The project got to make the company millions of dollars yet again.

When the rewrite finally started to form, it actually had significantly less functionality than the Haskell implementation. The internal users complained so much about that. And it took just as long to create. What a failure that rewrite was.

In the end, it was the attitude you are espousing that killed the project, not anything technical or hiring-/team-building-wise. It was literally just an opinion not to use Haskell by a guy who couldn't be bothered for the life of him to try to understand it.

Only choose technologies that are popular for production stacks -> more people using those technologies professionally(implying less using others) -> only choose popular technologies -> etc.

From a "making a quality product" standpoint it would make more sense to me to choose the technology intelligently according to the needs of the product. Anything less is just a business mythology about trying to deliver a lower quality product for a lower cost.

The "needs of product" should include "long term maintenance cost".

If software stopped pandering and coddling developers who cannot be bothered to read code we would not need conversations like these. We also wouldn’t need a bunch of superficial nonsense most developers believe they cannot live without. Most companies drastically over spend on finding and retaining developers that aren’t qualified to be there in the first place when really in most cases it’s just about trying to put text on a screen. These companies would save so much money finding people off the street, evaluating them against minimally required intelligence and just training them to read and write code in house.

It's not "super subjective" when something super niche like Haskell[1] is chosen.

There are pragmatic reasons to choose a tech stack, the biggest of which is "can we find people to maintain it?". If you cannot, then it's unmaintainable.

[1] That's the example that was chosen upthread.

It never ceases to amaze me how far you can get with going back to basics of solid software engineering and the manifestations of those basics, mainly:

1. OOP to prove that you have a good grasp of the domain and problem space. Show me you know what's actually happening through code and tests. 2. Build relations - it's far, far, FAR easier to go from BCNF/3NF to a denormalized state than the opposite when you've got lots of data. It's also far easier to perform operations on that normalized state with certainty that your change will fucking work. 3. Focus on APIs first. Whatever the bounded context, focus on the APIs and how they'll be consumed.

He saw DB.Users.Where(a => a.Id == 1) on the screen and launched a tirade of "Are you retarded? You're downloading the whole Users table when you do that!"

It was fun watching our boss explain how LINQ worked and seeing the shame in the engineer's face.

LINQ allows you to use the same syntax for both local arrays and in an ORM, or any data source really, if you implement its IQueryable interface. You implementation can "parse" the AST and generate an SQL query, like a regular ORM.

If a developer working on that sort of task A) matches the coding conventions of the underlying framework and B) employs basic use of docblocks to describe things like function signatures, they're 90% of the way to decent, understandable code that someone else can pick up and work with.

It's amazing, though, how many developers will not do those two things unless you drive home that they're mandatory.

They are pretty objective guidelines that I use to "grade" code in my head and it's pretty rare that anyone who follows them produces code that isn't at least a B, and that other people are able to pick up and extend later on without too much trouble.

And now we have problems A through E.

Personally, through decades of experience, I've learned that when this impulse hits me, I need to consciously remind myself of these truths:

1) The engineer(s) that wrote the offensive code were almost certainly not idiots. The code is probably that way for a reason, even if that reason isn't obvious to me.

2) If I embark on rewriting it "correctly", the odds are very good that I will learn why the code was as it was in the first place, and my rewrite will undoubtedly have my own style, but will not likely avoid whatever issue it was that made me think it should be rewritten.

While I agree with #1, that "offensive" code is offensive for a reason (no time, no experience, no tooling, no hindsight), I don't really agree with point #2. With enough hindsight and careful study, it is entirely possible to avoid the offensive characteristics while doing the same thing.

IMO: bad code is often due to accidental complexity, often brought in by the programmers themselves. And very rarely due to essential complexity.

> With enough hindsight and careful study, it is entirely possible to avoid the offensive characteristics while doing the same thing.

You're right. I should have been more expansive. The rewrite may not reproduce the same issue (although the odds are good you'll see what the issue was!), but it will have its own issues, and is also likely to eventually also become "offensive" code that a future dev will have the urge to rewrite.

I use the word "offensive" here in a technical sense, not in a judgmental sense. Great code can become offensive with time as requirements, environments, and development methodologies change.

The main thing is that rewriting code is very expensive in both the monetary and risk sense. In the end, it's a question of cost/benefit. If the benefit of a rewrite is less than the cost, then rewriting is the wrong decision.

> bad code is often due to accidental complexity, often brought in by the programmers themselves.

Yes, I agree. And the majority of it turned out bad because of maintenance. Too much duct tape and bubble gum has accumulated over time.

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

Truth is, the cost of “just rewrite it” is as large as your unit of software architecture. Prefer loosely coupled, cohesive small parts and rewriting to accommodate changed requirements becomes preferable to the alternatives that tack on complexity as landscape evolves.

The world and our model of it both evolve all the time; the current version is not a work of an idiot but a necessary step towards a better solution and a lesson.

Often, you pick "just rewrite it" when the complexity of a module seems to have grown too high and refactoring to reduce complexity or to hit new objectives seems difficult.

The problem is, a lot of that complexity there may be necessary because of subtlety. Or, we may not do all that much better the next time around.

There's a strong bias in software engineering in particular to underestimate inherent difficulties and overestimate our own capabilities. Sometimes a rewrite is a win, but this bias causes us to select rewrites in times when it ends up not being son.

Once bitten, twice shy.

The example that I had to deal with most recently used a "clean architecture" approach in an api. The incoming calls went through three layers of redundant code - of which each layer had its own set of unit tests - before hitting the db and then passing up the response back through the stack.

It deeply annoys me to have to deal with people who have some pattern like this that they read about and, I assume mostly due to its relative obscurity, they feel ... smart? ... when applying it and forcing whomever comes after to deal with it.

To say that I want to viciously rip out the redundant layers is an understatement.

Something something memory allocating llamas cough.

Whether an architecture is objectively excellent doesn't really matter. The question is whether the people who are going to maintain the thing can work well with it. A tribe of OO partisans will produce a very different system than a tribe of FP ones. Each could find their own system highly maintainable but find the others' incomprehensible enough that they'd rather rebuild it than take it over.

What I think really matters is close, respectful collaboration among a group of people in a context with frequent iteration, so that the team can learn to make good choices together. And, over the longer term, enough continuity in that team so that new people can absorb enough context that the culture is transmitted for as long as the code lasts.

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

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

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

This is my biggest pet peeve of them all. I tell wet-behind-the-ears engineers "always strive to make the life of the next person to touch the code easier, even if only because the 'next person' will probably be you."

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

I have dealt with opposite - a monolith-based company grew to a point where more complexity was required, but none of the engineers there seemed to have been equipped with an iota of distributed systems knowledge.

The "senior" and "staff" engineers obviously built something, and everyone was still monkeypatching out all the consistency issues 5+ years later, and some of them were still around declaring that there are no issues.

I don't believe 10x engineers actually exist. Maybe 1.5x, 2x, or 3x engineers exist at most. 10x is a huge exaggeration of human capability.

Get this, say a project takes a year to complete. The concept is saying a 10x engineer can do this in about month. If such a person exists it will be so rare I estimate that most people haven't ever encountered an actual "10x" engineer. Even a 3x engineer is super rare. I can see something like 2x happening where a project that takes a year is done in 6 months. That is rare but plausible.

You also might get a lead who can ramp up the effectiveness of an entire team by say 3x at most. If the size of the team was N, then it's N*3X. If N is like 4 then it's a 12x increase. This is the closest thing to an actual 10x engineer. But it's not actually a 10x engineer here it's just better management.

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

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

You've really never met this person? Feels like more or less everyone with real expertise should be able to do this in the right job.

The statement that every engineer can be a 10x engineer is recursively paradoxical. If a 10x engineer existed, in my mind, he would immediately be able to identify this logical error.

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

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

Neither have you.

i've built in two weeks something that took another guy 5 years to not even quite finish. with better performance, reliability and extensibility across the board.

that's a factor of 130x (or more!). how do you want to divide that up between the two of us? if he's 0.01x, how rare must he be for the "average" to still be sitting at 1x?

Remember, for every Bellard, Carmack or jart: there's at least 100,000 glue engineers who are just trying to cash in some easy VC checks - can't blame them at all.

The true 10x engineer looks at the project, sees the inherent needless complexity, goes back to the sponsor and uses his business knowledge to renegotiate the specs. Leading to a reduced scope with 98% of the business value and 10% of the work.

I think the reason so many people have doubts on the existence of 10x is that they might have never encountered one.

I recall a story someone told me a while ago. Software business that did local CoL/prevailing wages. Hired an intern one summer that was just running around in circles around the other, more senior devs. Useless to say they loved him and the next summer they tried to get him back, even offering a signing bonus for an internship (something they considered unheard of) but he was already at a large search engine company down in the Bay. You can guess the comp was probably already 3x what his previous job was offering. Of course, he wouldn't return.

There's a whole class of engineers were completely invisible to most companies, even if they are in the same "local market" [0][1] (Some use the term "dark matter devs" but I know it has another meaning [2]). These guys tend to fly under the radar quite a bit. If you are in a tier 2 market or company, your chances of attracting one are close to nil. Because they are extremely valuable, they don't interview a lot and tend to hop between companies where they know people (or get fast tracked internally). When hiring is red hot, they might completely disappear from the hiring pool by junior year.

> Get this, say a project takes a year to complete. The concept is saying a 10x engineer can do this in about month. If such a person exists it will be so rare I estimate that most people haven't ever encountered an actual "10x" engineer. Even a 3x engineer is super rare. I can see something like 2x happening where a project that takes a year is done in 6 months. That is rare but plausible.

That's thinking in terms of bricklaying. 10x, like Carmack or Woz for example, bring completely new ideas and paradigm shifts. Think of the engineering happening at Xerox PARC for instance.

[0] https://blog.pragmaticengineer.com/software-engineering-sala...

[1] http://danluu.com/bimodal-compensation/

[2] https://www.hanselman.com/blog/dark-matter-developers-the-un...

All of that are arbitrary numbers. 10 is arbitrary and not actually measurable, but your 3, 4 are as well.

But I think you're on the right track with this thinking. "10x engineer" does not make things 10 times as fast as "1x" engineer does, they do qualitatively different things

Take an example of an engineer who sees through the bullshit of a "cloud architect" who specifies a complicated architecture with novel technologies to pad his resume. Cutting down on this can easily save the project / deliver much faster.

This is kind of an interesting view - 10x engineer does not make projects run 10x faster, but they prevent mistakes which would slow down the project by factor of 10.

If mean = 1x (by definition 1x should be the mean) and the std is the maximum possible value (also 1x). Then 10x would be 10 std past the norm.

This makes my numbers not arbitrary. 2x or 3x would only be 2 or 3 std past the norm. Which is reasonable (only if the std = 1x which is likely not the case and is most likely lower).

If a 10xer existed, That's like saying you found a human who runs 10x faster then the mean (10mph) or you found a human 10x taller than the mean (5'10"). 10 is arbitrary but 2 or 3 is less arbitrary. Ever heard of the company 3sigma? The name represents Rarest non arbitrary anomaly from the norm.

It is actually fundamentally illogical to think of human ability in terms of a multiple of the mean because no other measurable human quality follows that kind of distribution. Almost all of these measured things follow the normal distribution.

You are therefore highly highly unlikely to find a 10x engineer or a -10x engineer. This applies even to things like engineering leadership.

When viewed from this lens you can actually see that it's actually very unlikely for even the best leader to improve the productivity of every member of his team by even 2x. So I take that back. Likely what we are seeing is something like a 1.1x.or 1.2x increase and our minds are exaggerating the effect like an optical illusion.

The concept of measuring any human trait along multiples of the mean via 1x or 2x or 3x or 10x is fundamentally unrealistic when you take a data driven viewpoint of normal distributions. Everyone on this thread is erroneously following this model and while my instincts were more tempered, to a certain extent even I'm following this erroneous model as I declared 3x to be within the realm of reality.

We are all going about this all wrong (including me), the data driven conclusion is that at best you can find 2x engineers and they are freaking rare (because the actual std is nowhere near 1x). The maximum likely delta between the best engineer and worst engineer is 4z, where in this case the z represents 1/2x or an engineer half as good as the average.

Likely people are anecdotally seeing this 4z delta and their mind is exaggerating the delta to 10x. From what we know of statistical reality an actual 10x is unlikely to happen at all.

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

So for IQ, or height, no one can have negative or zero height. This limit effectively limits the std. It is not arbitrary. Try it.

For a distribution of integers on a range from 0 to infinite, let's say the mean is 1. The std will also have a maximum value of 1.

If you add extreme data points to change std, you will also change the mean.

This makes sense right? If you add say 9999999 to a distribution of numbers to keep the average the same you have to counterbalance it with a -9999999 or something like that. But however because the domain is limited from 0 to infinite you can't do that. So effectively the maximum value of the std is the mean itself assuming that the system is normally distributed.

For height, sure, but since IQ scores are defined by the standard deviation of 15, a negative score is possible (you’d expect a single-digit number of people in the world population to have such scores.) Not sure if the typical test resolution is sufficient to distinguish that, though.

In other words the statistical model is not an entirely accurate model of the IQ test. Which to me is what IQ is.

That's just my interpretation though. Regardless of this though, it is highly highly unlikely for engineering productivity to go that deep into the negative. It's also fundamentally impossible to have infinite productivity too. The real domain is for sure some fixed range of numbers which makes the std for sure limited by the distance of the mean to the first number in the range.

By this logic, A 10x engineer is analogous to someone with 1000 IQ or 58 feet in height. We have intuitions about this that is inline with the statistical outcomes I outlined above... and it makes sense to apply these intuitions to the concept of 10x engineers.

You can now define the std to be whatever you want up to 1x. So I take the most ludicrously large std then interpret what the term 10x means in terms of the maximum std.

10x is 10 std from the norm. So the 10x is ludicrously improbable. The real std is likely much lower than this making the concept if 10x even less likely.

And it's wrong. Read the title of this discussion again, "How to be a -10x Engineer" and think about what it means for max. std value.

No one and I mean no one has seen a project accelerate backwards by negative 10. It's akin to -1000iq or -58 feet in height. A "10x" engineer would find this obvious if such a thing existed.

The entire point of my post on statistics is to say 10x or -10x are both fundamentally impossible. Additionally the scale should be 0 to infinite, it does not actually scale negatively. The idea of even -1x is ludicrous. -1x means the project is rapidly disassembling itself and engineers are losing knowledge and intelligence.

Have you read the article? -10x is not about "accelerating backwards", it's about bringing the project to stand still / significantly slowing it down.

And I have seen this multiple times. People who in one way or another managed to slow down other people. Toxic people can create such an environment that the productive people quit. They don't bring smaller value, not even zero value, they bring negative value to the team/project.

> -1x means the project is rapidly disassembling itself and engineers are losing knowledge and intelligence.

I don't know where you come with this arbitrary interpretation of exactly -1, but yes, that happens to projects.

I know the article is generally just talking about bad engineers. However the topic I started here is more about the term 10x.

>And I have seen this multiple times. People who in one way or another managed to slow down other people. Toxic people can create such an environment that the productive people quit. They don't bring smaller value, not even zero value, they bring negative value to the team/project.

Sure but negative progress or -10x progress or 10x progress is just not realistic. The 10 in the term 10x is the thing that is arbitrary. Not only is it arbitrary it's completely inaccurate.

>I don't know where you come with this arbitrary interpretation of exactly -1, but yes, that happens to projects.

Arbitrary definition of 1x? 1x is default -1x would be the default but backwards. It's anything but average. The 10 on 10x is again the arbitrary constant here. Also, Losing knowledge and intelligence is the equivalent of brain damage so are people banging their heads against walls and shooting up on brain damaging drugs? Doubt it. Productivity stops at zero, negative progress is so rare it's basically non-existent.

Pick one. Can't be both.

> 1x is default -1x would be the default but backwards

Not backwards. In terms of value, 1x is a value produced by 1 typical developer. -1x is a decrease of value.

> Also, Losing knowledge and intelligence is the equivalent of brain damage so are people banging their heads against walls and shooting up on brain damaging drugs?

Organizations lose knowledge all the time because people quit because of e.g. toxicity in the workplace (brought by -10x employees).

I guess I'm done with this conversation, it no longer interests me.

Pick what? I didn't pick anything. I'm just laying out examples.

>Not backwards. In terms of value, 1x is a value produced by 1 typical developer. -1x is a decrease of value.

Yeah so my point is -1x is Not arbitrary. You said it is. I simply said it isn't.

>Organizations lose knowledge all the time because people quit because of e.g. toxicity in the workplace (brought by -10x employees).

That's one way of looking at it. It's valid. But by itself I was referring to an honest employee acting to the best of his capability. Like IQ this part cannot be negative. Things like side effects of a bad actor deliberately damaging the company is not something I was referring to. Overall though this type of thing is hard to measure.

>I guess I'm done with this conversation, it no longer interests me.

Sure. That's fine. The conversation is getting into the nitty gritty of interpretation of words which is pointless imo. I think you're pretty clear about what I'm talking about. All in all though my statistical interpretation is still ultimately correct.

> Pick what?

Arbitrary or unrealistic. Utterly obvious from context; you said "arbitrary and unrealistic", they replied "pick one or the other".

Somewhere else you write about "if you only understood what I wrote". Honestly... This shows that the problem there wasn't with someone else's understanding of English, but yours.

At the end of the day it is 10x what, tasks closed (features, bugs, etc) at same or higher quality? Terrible metric but those people exist.

But you can also be a 50/100x engineer if the metric becomes value rather than tasks closed. E.g. convincing key stakeholders their project is a bad idea can save millions, years and companies.

There's plenty of such moments to make huge differences and they compound.

The most spectacular example of this I've ever seen was a developer writing Java that only ever used single-character identifiers.

As in the following style:

    class D {
        public A foo(B b, C c ) {
            D d = b.x( c );
            return new A(d.f(1));
        }
    }

You might be wondering: what happens when he gets to "z" and runs out of identifiers? No problem! He just kept going thus: aa, ab, ac, ad, etc... I saw code up to "dh" or somesuch.

He had perfect job security... right up until the startup he was working for imploded because nobody could collaborate on that code.

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

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

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

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

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?

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.

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?

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.

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

Iterative development is a how, not a what.

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.

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

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.

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.

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?

15% seems very excessive. Almost a whole day a week and two days lost of deep work. Try to aim for 1.5%.

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.

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!

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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!

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

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

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.

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?

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

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

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.

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

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.

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.

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

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

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.

    How long do your legs need to be? Long enough to reach the floor. 

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.

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

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?

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.

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.

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.

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.

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

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

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

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"

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.

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!

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.

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.

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.

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/

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.

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.

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.

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.

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?

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