6 ms·

Only Debate The Non-Linear

107 points by digb 4y ago

flockonus 4y ago
Love this article, hope it becomes a foundational piece in some tech org cultures, that reward engineers to focus on "better than linear improvements", vs. pedantic debates I've seen teams that strive for improvement grow so used to for the cheap feeling of improvement they provide. nit: (so I don't lose the habit) that flashing gif in the middle causes a more than linear nuisance while I'm trying to read the article, otherwise LGTM!
- readthenotes1 4y ago
  There's some project management guru who wrote a book on managing projects that helped keep people micromanaging them. Years later I read that he really regretted it because he realized that project shouldn't be even started unless they're too important to be micromanaged... It is, don't start linear return projects...
l33t233372 4y ago
To me it seems like the author is saying “An important decision is a nonlinear one, where a nonlinear decision is one that might have a big impacts.” So this whole post boils down to something like: “only debate decisions that might have big impacts.” I don’t really see what’s interesting about that idea.
- deleted 4y ago
  [deleted]
- nextaccountic 4y ago
  > So this whole post boils down to something like: “only debate decisions that might have big impacts.” I don’t really see what’s interesting about that idea. And yet, many people might agree with it but still debate trivial matters
  - nvader 4y ago
    Yes, but when you say "trivial", I think you actually mean "pedantic". This is an important distinction because... Click to read more (28 min read)
- civilized 4y ago
  Tech writing could do with less "this is technical" signaling and more actual precision. Use ordinary words to express ordinary concepts ("big impact") and technical words for technical concepts ("nonlinear", "exponential"). Don't use technical words to fluff up ordinary ideas.
  - blt 4y ago
    Sadly, it seems that people absolutely love doing this.
- haimez 4y ago
  It’s not only uninteresting- it’s wrong. Linear costs of bad decisions can kill a business in so many ways.
- svnt 4y ago
  The author stops at an intuitive leap before developing the idea into something easily put into practice. Actually doing what the author describes is often impossible except in an intuitive way. How could you know a priori which decisions might have big impacts? On a project of any complexity you need either deep specific experience or a very accurate working model of the entire project. You aren’t likely to have either. This has been previously covered in depth, even in software, although of course it could possibly be improved. Painting the bikeshed is one example: http://phk.freebsd.dk/sagas/bikeshed/ http://phk.freebsd.dk/sagas/bikeshed/
sublinear 4y ago
> I would rather implement a self-service e-commerce platform for a company’s merchandising team, rather than make it easier for engineers to service a ticket to build a /products/hat/:id endpoint every 6 weeks. Sounds like the author is trying to justify building new stuff without being responsible for any of it. Whatever delusions they have about the "non-linear", the big ideas are almost certainly not going to come from an engineer who doesn't have a seat at the table with the people actually running the business. If one did they would hear all kinds of stuff that would not only wreck their self-esteem, but not have any obvious technical solutions. Engineers are not smarter than anyone else. Imagine that. It's not so much about finding the non-linear but about finding what actually matters to the business you work for first. It's almost never going to be more software.
- btown 4y ago
  > It's not so much about finding the non-linear No matter who you are in a company, there is, with probability one, someone who has specific context on something that is non-linear... that you, from your context, think is just linear. (If you're in leadership, this is even more important to understand!) And if you're arguing that something else is non-linear and thus more important, you're de facto arguing on whether the thing you want to deprioritize is linear. As CTO at a relatively-early-stage startup, one of my most important jobs is to give both technical and non-technical colleagues the benefit of the doubt that they've spotted something that I didn't know was a critical non-linear opportunity, and juggle expectations so that the non-linear thing they discovered can be addressed before it becomes either a problem or a missed opportunity. For instance, "customer X filed a ticket that they will need Y" can be easy to dismiss as a linear improvement-per-unit-work that's out of scope... but I need to keep my door open to hearing from our Customer X quarterback that Customer X is the nexus for an entire consortium of partners who all need Y and will adore us for it, in ways that might outrun the incremental improvements we'd already had planned. And, similarly, if an engineer discovers that Z is a non-linear drag of technical debt, that could be equally vital to our ability to move in an agile manner in the near future. But I do hope each person allocates their advocacy-time (or prickliness-allocation, or communications bandwidth, depending on who you ask) towards the things they believe are the most non-linear, so we can make the right decisions as a team without getting bogged down in meetings and debates. And they know I'll try to do the same. So the mental model, "only debate the non-linear," is very useful up and down the stack.
conformist 4y ago
> “optimizing for the first derivative” played well with this approach That's... still linear? If the concept of non-linearity is supposed to add anything to this article, arguably this should be at least the second derivative!
- taneq 4y ago
  Only if the first derivative is constant. ;)
- svnt 4y ago
  Unfortunately as it is used in science and maths/engineering, non-linear popularly has two meanings: one is that it is continuous (the one you seem to be using), and one is that it is proportional: i.e. the derivative is fixed (which is what the author is using).
camgunz 4y ago
I'm generally fine with this principle so long as I get to pick all the linting rules.
- VectorLock 4y ago
  "Anybody who cares about linting rules shouldn't be picking the linting rules." - Vector's Razor
- quickthrower2 4y ago
  In my ideal world, `lint --fix` on file save, every time.
  - planede 4y ago
    In my experience linter suggested fixes are good enough for suggestion, and it's probably worth setting up a key binding for accepting them in your IDE, but should absolutely never be applied blindly and automatically. This quality possibly varies from linter to linter, YMMV.
booleandilemma 4y ago
Most engineers will tell you that the transition from a junior engineer to a senior engineer, or the truly transformational work in our careers, does not come from just crushing tickets non-stop for extended periods of time. Of course it doesn't. And that's because "the transition" he refers to is an illusion at best, and a lie we tell ourselves at worst. It's all about politics and getting on your boss' good side. Toot your own horn and you'll move up the ladder of made up titles. Congratulations. It's not more complicated than that. Most managers don't look at code, and even when they do, they can't distinguish good work from CRUD boilerplate. Most managers don't know what it is you do, only what you say it is you do. And the reason why we're in this situation in the first place is because our management class is filled with people who just want things to work without issue so they can collect a paycheck off of someone else's labor and provide for their families. Managers don't care about your work, and you are being tricked into caring about your work so that managers don't have to.
- GenerocUsername 4y ago
  4/5 managers from my career fit this description. I've had 2 managers who were better than this, and they were prior programmers who still understood the code but had moved up. The best managers are good coders who realize that by directing they can actually accomplish more across many areas than they could have as a individual contributed. But 4/5 are disconnected paycheck collectors who need to be told stories
  - Spivak 4y ago
    I wanna push back on this. > Good coders who realize that by directing they can actually accomplish more across many areas. This isn't a manager, this is a director. Great to have but not the person you want directly managing teams. The people you want directly managing teams are "servant managers", "shit umbrellas" or because it's silly there's even terms for these just "non-shitty managers." Managers should be people who enable the devs not because of their coding talent but because of their non-coding talent. They organize all your work into a nice little streams so you don't have to carry the mental load, advocate for the needs of your team by translating tech speak into product management speak, dealing with all the external requests to your team (i.e. saying no), handling on-call schedules, coordinating with the release managers and support, helps you with career development, the list goes on. A good dev manager lets you turn off brain to all annoyances and distractions not related to your technical work.
narag 4y ago
I usually don't like this kind of article with too abstract or general advice. But this one's nice: the good old "choose your battles wisely" + useful heuristic.
kazinator 4y ago
That fits audiophile discussions to a tee. :)
aaron695 4y ago
[dead]
peter_d_sherman 4y ago
My key takeaways: >"Only debate the non-linear. If there is a strong case to be made that a proposal will create some non-linear [positive] impact, then it is worth debating at some length. [...] As a concrete example, I would rather implement a self-service e-commerce platform for a company’s merchandising team, rather than make it easier for engineers to service a ticket to build a /products/hat/:id endpoint every 6 weeks." Reminds me of the Joel Spolsky story about one of his employees, Noah Weiss: "Thanks or No Thanks - A young employee came up with an idea that added a million dollars to our bottom line." (Inc. Magazine, Jan 2009) https://www.inc.com/magazine/20090101/how-hard-could-it-be-thanks-or-no-thanks.html https://www.inc.com/magazine/20090101/how-hard-could-it-be-t... Apparently Noah debated creating a job board with Joel (Joel was originally against it) -- until he eventually got his way... and added a million dollars to Joel's company's bottom line... Related: "Pick your battles"
xeyownt 4y ago
TL;DR; summary from ChatGPT: The author reflects on their struggle to discern whether a debate is worth having in a work context, leading them to identify the need to find an equilibrium level of conflict, which can increase efficiency and morale of a team. They argue that this level is rooted internally in an individual's confidence level and emphasise the importance of periodic debates, which can outweigh occasional critical discussions. To find this equilibrium, the author advises a personal principle to only debate the non-linear, i.e., issues that can have a non-linear impact on the organisation, as opposed to those that add incremental value.
lazyasciiart 4y ago
I spent the weekend trying to decide if I should bother trying to change a technical decision recently made at work, and this piece was useful because it gave me a new categorization to think through. The phrase from the article that jumped out at me was "eliminate whole swaths of work". I'm coming in to the project at a point where a couple of dev-months have already gone into learning and spinning up [the unsupported infrastructure we will have to maintain that has nothing to do with our actual app], and I'm confident nobody wants to scrap it all - but that sunk cost is nothing compared to maintaining everything for the next x years. There are zero functional challenges or business costs from using [the existing supported infrastructure from another department], and it would immediately eliminate the six highest items on the project list of risks. And it's not that they thought about this and decided not to: as far as I can tell from specs, design docs, etc., it has simply not occurred to anyone on the project.

107 points by digb 4y ago

Love this article, hope it becomes a foundational piece in some tech org cultures, that reward engineers to focus on "better than linear improvements", vs. pedantic debates I've seen teams that strive for improvement grow so used to for the cheap feeling of improvement they provide. nit: (so I don't lose the habit) that flashing gif in the middle causes a more than linear nuisance while I'm trying to read the article, otherwise LGTM!

readthenotes1 4y ago
There's some project management guru who wrote a book on managing projects that helped keep people micromanaging them. Years later I read that he really regretted it because he realized that project shouldn't be even started unless they're too important to be micromanaged... It is, don't start linear return projects...

l33t233372 4y ago

To me it seems like the author is saying “An important decision is a nonlinear one, where a nonlinear decision is one that might have a big impacts.” So this whole post boils down to something like: “only debate decisions that might have big impacts.” I don’t really see what’s interesting about that idea.

deleted 4y ago
[deleted]
nextaccountic 4y ago
> So this whole post boils down to something like: “only debate decisions that might have big impacts.” I don’t really see what’s interesting about that idea. And yet, many people might agree with it but still debate trivial matters
- nvader 4y ago
  Yes, but when you say "trivial", I think you actually mean "pedantic". This is an important distinction because... Click to read more (28 min read)
civilized 4y ago
Tech writing could do with less "this is technical" signaling and more actual precision. Use ordinary words to express ordinary concepts ("big impact") and technical words for technical concepts ("nonlinear", "exponential"). Don't use technical words to fluff up ordinary ideas.
- blt 4y ago
  Sadly, it seems that people absolutely love doing this.
haimez 4y ago
It’s not only uninteresting- it’s wrong. Linear costs of bad decisions can kill a business in so many ways.
svnt 4y ago
The author stops at an intuitive leap before developing the idea into something easily put into practice. Actually doing what the author describes is often impossible except in an intuitive way. How could you know a priori which decisions might have big impacts? On a project of any complexity you need either deep specific experience or a very accurate working model of the entire project. You aren’t likely to have either. This has been previously covered in depth, even in software, although of course it could possibly be improved. Painting the bikeshed is one example: http://phk.freebsd.dk/sagas/bikeshed/ http://phk.freebsd.dk/sagas/bikeshed/

sublinear 4y ago

> I would rather implement a self-service e-commerce platform for a company’s merchandising team, rather than make it easier for engineers to service a ticket to build a /products/hat/:id endpoint every 6 weeks. Sounds like the author is trying to justify building new stuff without being responsible for any of it. Whatever delusions they have about the "non-linear", the big ideas are almost certainly not going to come from an engineer who doesn't have a seat at the table with the people actually running the business. If one did they would hear all kinds of stuff that would not only wreck their self-esteem, but not have any obvious technical solutions. Engineers are not smarter than anyone else. Imagine that. It's not so much about finding the non-linear but about finding what actually matters to the business you work for first. It's almost never going to be more software.

btown 4y ago
> It's not so much about finding the non-linear No matter who you are in a company, there is, with probability one, someone who has specific context on something that is non-linear... that you, from your context, think is just linear. (If you're in leadership, this is even more important to understand!) And if you're arguing that something else is non-linear and thus more important, you're de facto arguing on whether the thing you want to deprioritize is linear. As CTO at a relatively-early-stage startup, one of my most important jobs is to give both technical and non-technical colleagues the benefit of the doubt that they've spotted something that I didn't know was a critical non-linear opportunity, and juggle expectations so that the non-linear thing they discovered can be addressed before it becomes either a problem or a missed opportunity. For instance, "customer X filed a ticket that they will need Y" can be easy to dismiss as a linear improvement-per-unit-work that's out of scope... but I need to keep my door open to hearing from our Customer X quarterback that Customer X is the nexus for an entire consortium of partners who all need Y and will adore us for it, in ways that might outrun the incremental improvements we'd already had planned. And, similarly, if an engineer discovers that Z is a non-linear drag of technical debt, that could be equally vital to our ability to move in an agile manner in the near future. But I do hope each person allocates their advocacy-time (or prickliness-allocation, or communications bandwidth, depending on who you ask) towards the things they believe are the most non-linear, so we can make the right decisions as a team without getting bogged down in meetings and debates. And they know I'll try to do the same. So the mental model, "only debate the non-linear," is very useful up and down the stack.

conformist 4y ago

> “optimizing for the first derivative” played well with this approach That's... still linear? If the concept of non-linearity is supposed to add anything to this article, arguably this should be at least the second derivative!

taneq 4y ago
Only if the first derivative is constant. ;)
svnt 4y ago
Unfortunately as it is used in science and maths/engineering, non-linear popularly has two meanings: one is that it is continuous (the one you seem to be using), and one is that it is proportional: i.e. the derivative is fixed (which is what the author is using).

camgunz 4y ago

I'm generally fine with this principle so long as I get to pick all the linting rules.

VectorLock 4y ago
"Anybody who cares about linting rules shouldn't be picking the linting rules." - Vector's Razor
quickthrower2 4y ago
In my ideal world, `lint --fix` on file save, every time.
- planede 4y ago
  In my experience linter suggested fixes are good enough for suggestion, and it's probably worth setting up a key binding for accepting them in your IDE, but should absolutely never be applied blindly and automatically. This quality possibly varies from linter to linter, YMMV.

booleandilemma 4y ago

Most engineers will tell you that the transition from a junior engineer to a senior engineer, or the truly transformational work in our careers, does not come from just crushing tickets non-stop for extended periods of time. Of course it doesn't. And that's because "the transition" he refers to is an illusion at best, and a lie we tell ourselves at worst. It's all about politics and getting on your boss' good side. Toot your own horn and you'll move up the ladder of made up titles. Congratulations. It's not more complicated than that. Most managers don't look at code, and even when they do, they can't distinguish good work from CRUD boilerplate. Most managers don't know what it is you do, only what you say it is you do. And the reason why we're in this situation in the first place is because our management class is filled with people who just want things to work without issue so they can collect a paycheck off of someone else's labor and provide for their families. Managers don't care about your work, and you are being tricked into caring about your work so that managers don't have to.

GenerocUsername 4y ago
4/5 managers from my career fit this description. I've had 2 managers who were better than this, and they were prior programmers who still understood the code but had moved up. The best managers are good coders who realize that by directing they can actually accomplish more across many areas than they could have as a individual contributed. But 4/5 are disconnected paycheck collectors who need to be told stories
- Spivak 4y ago
  I wanna push back on this. > Good coders who realize that by directing they can actually accomplish more across many areas. This isn't a manager, this is a director. Great to have but not the person you want directly managing teams. The people you want directly managing teams are "servant managers", "shit umbrellas" or because it's silly there's even terms for these just "non-shitty managers." Managers should be people who enable the devs not because of their coding talent but because of their non-coding talent. They organize all your work into a nice little streams so you don't have to carry the mental load, advocate for the needs of your team by translating tech speak into product management speak, dealing with all the external requests to your team (i.e. saying no), handling on-call schedules, coordinating with the release managers and support, helps you with career development, the list goes on. A good dev manager lets you turn off brain to all annoyances and distractions not related to your technical work.

narag 4y ago

I usually don't like this kind of article with too abstract or general advice. But this one's nice: the good old "choose your battles wisely" + useful heuristic.

kazinator 4y ago

That fits audiophile discussions to a tee. :)

aaron695 4y ago

[dead]

peter_d_sherman 4y ago

My key takeaways: >"Only debate the non-linear. If there is a strong case to be made that a proposal will create some non-linear [positive] impact, then it is worth debating at some length. [...] As a concrete example, I would rather implement a self-service e-commerce platform for a company’s merchandising team, rather than make it easier for engineers to service a ticket to build a /products/hat/:id endpoint every 6 weeks." Reminds me of the Joel Spolsky story about one of his employees, Noah Weiss: "Thanks or No Thanks - A young employee came up with an idea that added a million dollars to our bottom line." (Inc. Magazine, Jan 2009) https://www.inc.com/magazine/20090101/how-hard-could-it-be-thanks-or-no-thanks.html https://www.inc.com/magazine/20090101/how-hard-could-it-be-t... Apparently Noah debated creating a job board with Joel (Joel was originally against it) -- until he eventually got his way... and added a million dollars to Joel's company's bottom line... Related: "Pick your battles"

xeyownt 4y ago

TL;DR; summary from ChatGPT: The author reflects on their struggle to discern whether a debate is worth having in a work context, leading them to identify the need to find an equilibrium level of conflict, which can increase efficiency and morale of a team. They argue that this level is rooted internally in an individual's confidence level and emphasise the importance of periodic debates, which can outweigh occasional critical discussions. To find this equilibrium, the author advises a personal principle to only debate the non-linear, i.e., issues that can have a non-linear impact on the organisation, as opposed to those that add incremental value.

lazyasciiart 4y ago

I spent the weekend trying to decide if I should bother trying to change a technical decision recently made at work, and this piece was useful because it gave me a new categorization to think through. The phrase from the article that jumped out at me was "eliminate whole swaths of work". I'm coming in to the project at a point where a couple of dev-months have already gone into learning and spinning up [the unsupported infrastructure we will have to maintain that has nothing to do with our actual app], and I'm confident nobody wants to scrap it all - but that sunk cost is nothing compared to maintaining everything for the next x years. There are zero functional challenges or business costs from using [the existing supported infrastructure from another department], and it would immediately eliminate the six highest items on the project list of risks. And it's not that they thought about this and decided not to: as far as I can tell from specs, design docs, etc., it has simply not occurred to anyone on the project.