7 ms·

Only solve one new problem at a time

189 points by rmason 4y ago

ArcMex 4y ago
Regarding learning a new paradigm and having to build an application with it, I think it’s possible within a reasonable time. My approach, ironically was the incremental approach mentioned in the article. So the first step was for me to view it as one problem - build app using X. Then the steps might have looked like 1. Learn ABC 2. Apply ABC 3. Refine ABC I always know enough to build something. Eventually, I know enough to refine it. Now the author said this is slow and I agree but at the end of what would be a learn-first-build-later approach is an actual, built system. You can now solve the next problem, enhancements. To any new developers, I should mention that a good foundation of fundamentals is key to this kind of approach and I admit, there are much better ways to learn and build.
- _def 4y ago
  I have to agree with you. Since there are infinite things to learn and infinite projects to build, it's nice if you can combine it from time to time. Surely you shouldn't only do that, but it can be very exciting and fruitful in my experience.
- GrumpyNl 4y ago
  I would refine that to, learn A, apply A, refine A, then start with B.., then C.., then refine ABC.
cpursley 4y ago
I slightly disagree with one point. There's not a better time/way to learn a new language than on a new/real project.
- datatrashfire 4y ago
  Any language I tried to pick up just to learn for is own sake never went anywhere. The stuff I just started running with a new project or job... Still use those today.
- willnonya 4y ago
  It depends on whether you're the one paying for someone's learning curve. You'll be much better off if you learn the fundamentals then use a real project to polish your skills than trying to learn from scratch with a deadline looming.
  - sanitycheck 4y ago
    The _fundamentals_ of most new languages one might typically use take a pretty short time (weeks, not months) to learn, for experienced developers. Most significant real projects will need at least a couple of prototypes/POC's at the beginning. Thus a brand new project is a great time to learn a new language, you can make your beginner mistakes in code which will never ship. This goes back to that "innovation tokens" thing though, a new language is one innovation and you don't want too many others at the same time.
    - nicoburns 4y ago
      > The _fundamentals_ of most new languages one might typically use take a pretty short time (weeks, not months) to learn, for experienced developers I'd even say days, not weeks if the language is similar to one(s) you already know.
  - Sakos 4y ago
    Something has gone wrong if learning on a live project is putting deadlines at risk. I've learned the most working on live projects, but it was important that the things I worked on weren't crucial for meeting those deadlines. This has a lot to do with how tasks are broken down and how responsibilities and tasks are delegated and what support there is from the rest of the team to maintain an acceptable velocity. That ensures that you're not, say, getting stuck on something for a week longer than necessary. As for "learning the fundamentals", it's incredibly difficult to know what you don't know or understand and what you need to know/understand until you're trying to solve real problems. It's so inefficient and unmotivating. I knew the absolute basics of Spring Boot when I started working as a Java developer, but it wasn't until I started working a job with Spring Boot that the real learning started and I felt the motivation and drive to learn everything I could. Frankly, businesses need to adjust and learn to be okay with paying for learning curves, instead of expecting people to know and have experience with everything under the sun. There are long-term benefits that aren't easily quantifiable.
- Cthulhu_ 4y ago
  I kinda hear what you're saying, but if it's reimplementing existing business logic you can spend less brain power on solving a business problem and more on a technology problem. I don't believe there's a 1:1 straight translation from (in this case) Ruby to Go without a lot of extra work in the form of re-evaluating features, flows, performance, etc; the problem they solved wasn't the business feature, and a programming language should never be a problem.
willnonya 4y ago
This is presented as if this is sage advice that no one has heard before rather than tired cliches that only work in specific circumstances. Maybe I'm just jaded. I cant count the times I've been handed projects where worked 'incrementally' meaning the original team mistook that for use all the time and budget yet not deliver the product. Or the times I've been handed projects where everything from the language to the os had changed without changing the timeline. Absolutely only one one change at a time if you can. The real value comes in being able to take a situation with multiple changes and still make it work.
- lightbendover 4y ago
  I agree, I feel absolutely blessed if I can identify new tasking that can be done truly incrementally without relying on highly orchestrated changes. Most of the time, my value comes from identifying how to organize multiple work streams that come together at once to solve complex problems against tight deadlines.
revskill 4y ago
To me, it's more about doing CONCURRENTLY is the key. Concurrency also means solve one problem at a time, but in multiples timestamp instead.
- bunderbunder 4y ago
  As long as you are paying very careful attention to what you are doing, and have a very clear idea of why you’re doing it. Pausing between iterations on a thing can be an opportunity to sit back and collect the observations you need to know what to do in the next iteration. But pausing between iterations of a thing simply because there is some other thing you want to start on and you just can’t wait to get started, even if it means pausing work in something that isn’t actually done yet, is how vaporware is made.
williamcotton 4y ago
Somewhat related aphorism: only break one law at a time.
- deleted 4y ago
  [deleted]
edw519 4y ago
As a general rule, successful programmers have been doing this forever: - It works. You added 2 things. It doesn't work. Which thing broke it? - It doesn't work. You changed 2 things. It works. Which thing fixed it? - It works. Two people changed it. It doesn't work. Who broke it? - One donut left. 2 programmers went into break room. No donuts left. Who ate it? Now change "2" to "1" in all of the above examples. See how much easier?
- deleted 4y ago
  [deleted]
- 100011_100001 4y ago
  Ed, I'm glad you are still here :) - A fan
  - edw519 4y ago
    Thank you 100011_100001! I got so excited by your response, I figured what the heck and turned my original response into a code-generated, html-driven, svg-drawn comic strip and put in on the front page of my portfolio here: edweissman.com. (Hit the 2 big arrows to surf the other 18 comics. For me, this is way more fun than anything else I ever did on that page.) Enjoy and thanks again!
    - ml_giant 4y ago
      How did you make those comics? Is there something that just generates the html for you?
      - edw519 4y ago
        Is there something that just generates the html for you? Exactly. I rolled my own CMS just for this. No images, just html and superfast svg built from database parameters. I'll be launching a full webcomic only site by the end of the year. I hope to include source at some point. I'll keep you posted.
    - 4y ago
stewx 4y ago
I love Ben Nadel because: - I have ended up on his site numerous times after searching unrelated topics (amazing SEO?) and the content is generally very useful - He has all these happy photos on his site of meeting people at conferences
- throw1234651234 4y ago
  SEO is definitely great. Pictures are memorable. Name recognition is there. Content has been useless every time. His blog hasn't helped me once, despite stumbling on it 20 times a year sometimes.
preezer 4y ago
Ben Nadel, the king of selfie. Some time ago, I had a project where I searched a lot for ColdFusion, because I was new at this topic. I ended so often on Nadels website that I blocked his selfie section in ublock...
lightbendover 4y ago
This post actually doesn't resonate with me at all (and I've always respected Ben). I feel like I'm constantly solving a multitude of problems and actively look for opportunities where I can introduce new tech that hits on multiple disparate streams at once (I have neither the bandwidth as an org or the personal time to operate in a different manner), typically coupled with other new tech; even that is orthogonal to running dozens of work streams concurrently, which isn't exactly outside the gist of the article. Even getting a sufficiently complex product/program off the ground necessitates solving countless problems at once, otherwise the architecture has no chance of supporting growth. Perhaps I'm at the stage where advice like this doesn't apply, but looking back over my career, I can't really identify a point at which it did. To change my phrasing -- If someone manages a large team, let's assume that they are responsible for all that the team does and can be viewed as a single entity, synonymous with a single engineer working at high bandwidth. That entity is absolutely not solving singular problems at once. Individual engineers within that team are not working in isolation from one another and they all have interconnect impact unless their delivery is absolutely rote. In order to move at a speed necessary for on-time results on complex problems, the advice proposed in the article must be violated.
- shove 4y ago
  I think the advice is fine if applied to one context at a time. You can paint one room in your house and replace the carpet in another "simultaneously" without too much risk, but doing both at once in the same room is asking for disaster.
  - lightbendover 4y ago
    It really depends on the congruency between orthogonal tasks. Painting walls and laying carpet are diametrically opposed and are mutually exclusive. There are other mixed contexts that don't attribute this trait, e.g. I can make updates to multiple disparate ad products in tandem which independently have impact on a central ad server while also introducing new caches to the ad server without exceeding the risk threshold of making such changes at once. This kind of thing happens every day.
- 4y ago
amoghs 4y ago
This post resonates a lot! I think finding a clear focus and going deep on it takes you places no one (even you) can anticipate in advance. It's how you can create something amazing. I felt that personally working on eesel [1]. We kept a tight focus on the problem (making it easier to refer back to your work more easily) and it's become far more than we could've expected. Ironically, the classic "is this a company or a feature" question might actually be a validation of keeping scope. The only caveat I'd add to the post is that you should try to solve only one problem, but you should spend time exploring before hand to discover the broader set of problems and prioritise carefully. [1] https://eesel.app https://eesel.app
pkoird 4y ago
As a grad student, it seems like a pipe-dream. I've come to acknowledge that maybe I'm not the multitasker I thought I was but sadly, with tens of deadlines to juggle around, no respite for me.
- sicp-enjoyer 4y ago
  If you're early in the program, I assure you it will get better.
pickingdinner 4y ago
To me this is just a matter of scope for the abstraction you named "problem", because ultimately we can only solve one problem at a time, and everything we achieve is achieved incrementally. Whether you explicitly break up your "problem" into smaller problems by organizing your workflow that way, or implicitly break it up by simply biting off bits as you work seems to be the difference. The former being more planned, with the latter requiring greater mental tracking and ad lib task management. The greatest disadvantage regardless of how you work is task switching. If you're doing push-ups and sit-ups, it's easier to do 50 each x2 than 1 set of 2 each x 50. So if you include switching tasks as a task, you're doing 3 exercises, not 2, and your work becomes 150 instead of 100.
8organicbits 4y ago
At the team level I've liked the advice to only deploy one novel tech at a time. Similar to the article, if a problem happens between subsystem A and B, you'll struggle if A and B are too new to your team. Which subsystem is broken? Can A be patched to fix an unsolvable problem in B? You could end up with a very unusual config for B that would have been cleanly solved in A.
martin_drapeau 4y ago
Making an incremental single change is great advice especially if wrapped in a single Pull Request (or commit). Benefits: A) Easier for your colleagues to review and understand your change B) You can undo your change easily without affect other changes Now, if you do 2 changes per PR, A and B become a lot more complicated and just take more time.
spudzz 4y ago
I remember reading once that Steve Jobs only assigned his engineers one project at a time to optimize focus. A potentially apocryphal story because I later read his biography and didn't find any mention of this. I personally have a tendency to cherry-pick easy tasks and procrastinate on the gnarlier ones. Single-threading projects would force me to confront those difficult tasks and "eat the frog".
hliyan 4y ago
This strongly resonates with recent experience. I've come to realise that a lot of problems in software engineering are a result of either having one thing achieve two or more goals, or having two or more things to achieve one goal. The thing may be a function or a person. If the thing is too big for one person, don't add a second person. Break the thing down until you have enough smaller things to assign to people exclusively.
bazoom42 4y ago
This is one of the reasons “rewrite everything from scratch” so often fails.
Archelaos 4y ago
Although I agree with the general view of the article, the rule "If It Can't Be Done Incrementally, Don't Do It" does not always apply. I once had to refactor a large application from non-currency-aware to currency-aware. This means every single database field and every single operation involving prices had to be touched. Of course, I did not randomly jump around the code and instead tried to do it systematically. But the whole refactoring took several weeks and had to be rolled out all at once.
- valbaca 4y ago
  > instead tried to do it systematically Exception proving the rule. Yes, sometimes for something as deep as adding currency you do just need to fully refactor BUT I think you're still doing it in the spirit of "One Problem At a Time" You were adding currency, not adding currency AND updating the date library AND touching up the unit testing mocking AND adjusting that CSS for the checkout button (or whatever equivalent).
  - Archelaos 4y ago
    Hm. All your examples depent heavily on the circumstances. For instance, if you have a team of coders working on the same code base, it might be preferable to do all these things in parellel and role them out together. I just think that "Do things incrementally" is not so an important advice as the formulation "If It Can't Be Done Incrementally, Don't Do It" suggests. I would rather say: "Prefer to do things incrementally unless you have a good reason to do it differently."
- michaelcampbell 4y ago
  I'd be hard pressed to find any "rule" in any creative endeavor that _always_ applies, past obvious absurdities.
UI_at_80x24 4y ago
This also applies to the (often over-quoted and miss-quoted) "unix philosophy" of: Do one thing and do it well. It's a different side of the same coin. As a Sysadmin this methodology is CRUCIAL when it comes to troubleshooting. Make one change. Test. Test again. Ask Bob from accounting to test it. (Bob will break it. Dammit Bob, thank-you.) Rinse, lather, repeat.
cainxinth 4y ago
There is a corollary to this advice: only try one solution at a time. If you throw everything you have at a problem all at once you might solve it without figuring out which of the things you tried worked.
das_keyboard 4y ago
There is nothing more exstatic than the feeling of having solved 4 problems at once with one changeset - there is also nothing more devastating than having to figure out which of the 4 changes caused problem number 5.
CodeWriter23 4y ago
I think viewing this within the domain of the count of problems one is attempting to solve at once isn't the proper perspective. I work on the basis of Risk Containment, which often ends up meaning "solve one problem at a time", or "develop list of problems and solve one problem at a time". But often there is risk choosing that approach. Example: a couple of years back, I needed to do a new web app. I could have relied on my tried-and-true jQuery and HTML 5 skils. But with all I had read about Vue and the examples I saw led me to the conclusion I might do better timeline-wise (thus, reduced risk) by using the web app as a vector to learning Vue. I wasn't wrong, things went much faster once I get the hang of how to Vue. My client was so impressed with the work, he asked if I was just middle-manning a white-labeled tech solution from a third party. (Thanks bootstrap-vue!) How would that have turned out if I did jQuery / HTML 5 then a rewrite into Vue to keep it "one problem at a time"? It might have taken 2.5-4x as long. Anyway I look at the "solve one problem at a time" as a useful tool in the tool belt. But it is not an overriding principle. Risk Containment is that principle. A few years back, this was a peripheral tactic, even an afterthought. I've been working with some Risk Containment Ninjas for a couple of years, and the key lesson for me, the iterations are shorter in duration, the cost is less, and the idea evolves to a better end result. It forces you to think about every tiny piece of a project as driving home a MVP.
deleted 4y ago
[deleted]
hbarka 4y ago
Local: Transaction failed. Notified offshore team. Offshore(next day): I see. Local(next day): Process ABC threw an error. Offshore(next day): We will look at A. Serialize as much as possible. Take advantage of time zone opposition and asynchronous communication.
collyw 4y ago
Sounds like a variation on the "Choose boring technology" presentation. I agree with this idea, but there are far too many resume driven developers out there. https://boringtechnology.club/ https://boringtechnology.club/

189 points by rmason 4y ago

Regarding learning a new paradigm and having to build an application with it, I think it’s possible within a reasonable time. My approach, ironically was the incremental approach mentioned in the article. So the first step was for me to view it as one problem - build app using X. Then the steps might have looked like 1. Learn ABC 2. Apply ABC 3. Refine ABC I always know enough to build something. Eventually, I know enough to refine it. Now the author said this is slow and I agree but at the end of what would be a learn-first-build-later approach is an actual, built system. You can now solve the next problem, enhancements. To any new developers, I should mention that a good foundation of fundamentals is key to this kind of approach and I admit, there are much better ways to learn and build.

_def 4y ago
I have to agree with you. Since there are infinite things to learn and infinite projects to build, it's nice if you can combine it from time to time. Surely you shouldn't only do that, but it can be very exciting and fruitful in my experience.
GrumpyNl 4y ago
I would refine that to, learn A, apply A, refine A, then start with B.., then C.., then refine ABC.

cpursley 4y ago

I slightly disagree with one point. There's not a better time/way to learn a new language than on a new/real project.

datatrashfire 4y ago
Any language I tried to pick up just to learn for is own sake never went anywhere. The stuff I just started running with a new project or job... Still use those today.
willnonya 4y ago
It depends on whether you're the one paying for someone's learning curve. You'll be much better off if you learn the fundamentals then use a real project to polish your skills than trying to learn from scratch with a deadline looming.
- sanitycheck 4y ago
  The _fundamentals_ of most new languages one might typically use take a pretty short time (weeks, not months) to learn, for experienced developers. Most significant real projects will need at least a couple of prototypes/POC's at the beginning. Thus a brand new project is a great time to learn a new language, you can make your beginner mistakes in code which will never ship. This goes back to that "innovation tokens" thing though, a new language is one innovation and you don't want too many others at the same time.
  - nicoburns 4y ago
    > The _fundamentals_ of most new languages one might typically use take a pretty short time (weeks, not months) to learn, for experienced developers I'd even say days, not weeks if the language is similar to one(s) you already know.
- Sakos 4y ago
  Something has gone wrong if learning on a live project is putting deadlines at risk. I've learned the most working on live projects, but it was important that the things I worked on weren't crucial for meeting those deadlines. This has a lot to do with how tasks are broken down and how responsibilities and tasks are delegated and what support there is from the rest of the team to maintain an acceptable velocity. That ensures that you're not, say, getting stuck on something for a week longer than necessary. As for "learning the fundamentals", it's incredibly difficult to know what you don't know or understand and what you need to know/understand until you're trying to solve real problems. It's so inefficient and unmotivating. I knew the absolute basics of Spring Boot when I started working as a Java developer, but it wasn't until I started working a job with Spring Boot that the real learning started and I felt the motivation and drive to learn everything I could. Frankly, businesses need to adjust and learn to be okay with paying for learning curves, instead of expecting people to know and have experience with everything under the sun. There are long-term benefits that aren't easily quantifiable.
Cthulhu_ 4y ago
I kinda hear what you're saying, but if it's reimplementing existing business logic you can spend less brain power on solving a business problem and more on a technology problem. I don't believe there's a 1:1 straight translation from (in this case) Ruby to Go without a lot of extra work in the form of re-evaluating features, flows, performance, etc; the problem they solved wasn't the business feature, and a programming language should never be a problem.

willnonya 4y ago

This is presented as if this is sage advice that no one has heard before rather than tired cliches that only work in specific circumstances. Maybe I'm just jaded. I cant count the times I've been handed projects where worked 'incrementally' meaning the original team mistook that for use all the time and budget yet not deliver the product. Or the times I've been handed projects where everything from the language to the os had changed without changing the timeline. Absolutely only one one change at a time if you can. The real value comes in being able to take a situation with multiple changes and still make it work.

lightbendover 4y ago
I agree, I feel absolutely blessed if I can identify new tasking that can be done truly incrementally without relying on highly orchestrated changes. Most of the time, my value comes from identifying how to organize multiple work streams that come together at once to solve complex problems against tight deadlines.

revskill 4y ago

To me, it's more about doing CONCURRENTLY is the key. Concurrency also means solve one problem at a time, but in multiples timestamp instead.

bunderbunder 4y ago
As long as you are paying very careful attention to what you are doing, and have a very clear idea of why you’re doing it. Pausing between iterations on a thing can be an opportunity to sit back and collect the observations you need to know what to do in the next iteration. But pausing between iterations of a thing simply because there is some other thing you want to start on and you just can’t wait to get started, even if it means pausing work in something that isn’t actually done yet, is how vaporware is made.

williamcotton 4y ago

Somewhat related aphorism: only break one law at a time.

deleted 4y ago
[deleted]

edw519 4y ago

As a general rule, successful programmers have been doing this forever: - It works. You added 2 things. It doesn't work. Which thing broke it? - It doesn't work. You changed 2 things. It works. Which thing fixed it? - It works. Two people changed it. It doesn't work. Who broke it? - One donut left. 2 programmers went into break room. No donuts left. Who ate it? Now change "2" to "1" in all of the above examples. See how much easier?

deleted 4y ago
[deleted]
100011_100001 4y ago
Ed, I'm glad you are still here :) - A fan
- edw519 4y ago
  Thank you 100011_100001! I got so excited by your response, I figured what the heck and turned my original response into a code-generated, html-driven, svg-drawn comic strip and put in on the front page of my portfolio here: edweissman.com. (Hit the 2 big arrows to surf the other 18 comics. For me, this is way more fun than anything else I ever did on that page.) Enjoy and thanks again!
  - ml_giant 4y ago
    How did you make those comics? Is there something that just generates the html for you?
    - edw519 4y ago
      Is there something that just generates the html for you? Exactly. I rolled my own CMS just for this. No images, just html and superfast svg built from database parameters. I'll be launching a full webcomic only site by the end of the year. I hope to include source at some point. I'll keep you posted.
  - 4y ago

stewx 4y ago

I love Ben Nadel because: - I have ended up on his site numerous times after searching unrelated topics (amazing SEO?) and the content is generally very useful - He has all these happy photos on his site of meeting people at conferences

throw1234651234 4y ago
SEO is definitely great. Pictures are memorable. Name recognition is there. Content has been useless every time. His blog hasn't helped me once, despite stumbling on it 20 times a year sometimes.

preezer 4y ago

Ben Nadel, the king of selfie. Some time ago, I had a project where I searched a lot for ColdFusion, because I was new at this topic. I ended so often on Nadels website that I blocked his selfie section in ublock...

lightbendover 4y ago

This post actually doesn't resonate with me at all (and I've always respected Ben). I feel like I'm constantly solving a multitude of problems and actively look for opportunities where I can introduce new tech that hits on multiple disparate streams at once (I have neither the bandwidth as an org or the personal time to operate in a different manner), typically coupled with other new tech; even that is orthogonal to running dozens of work streams concurrently, which isn't exactly outside the gist of the article. Even getting a sufficiently complex product/program off the ground necessitates solving countless problems at once, otherwise the architecture has no chance of supporting growth. Perhaps I'm at the stage where advice like this doesn't apply, but looking back over my career, I can't really identify a point at which it did. To change my phrasing -- If someone manages a large team, let's assume that they are responsible for all that the team does and can be viewed as a single entity, synonymous with a single engineer working at high bandwidth. That entity is absolutely not solving singular problems at once. Individual engineers within that team are not working in isolation from one another and they all have interconnect impact unless their delivery is absolutely rote. In order to move at a speed necessary for on-time results on complex problems, the advice proposed in the article must be violated.

shove 4y ago
I think the advice is fine if applied to one context at a time. You can paint one room in your house and replace the carpet in another "simultaneously" without too much risk, but doing both at once in the same room is asking for disaster.
- lightbendover 4y ago
  It really depends on the congruency between orthogonal tasks. Painting walls and laying carpet are diametrically opposed and are mutually exclusive. There are other mixed contexts that don't attribute this trait, e.g. I can make updates to multiple disparate ad products in tandem which independently have impact on a central ad server while also introducing new caches to the ad server without exceeding the risk threshold of making such changes at once. This kind of thing happens every day.
4y ago

amoghs 4y ago

This post resonates a lot! I think finding a clear focus and going deep on it takes you places no one (even you) can anticipate in advance. It's how you can create something amazing. I felt that personally working on eesel [1]. We kept a tight focus on the problem (making it easier to refer back to your work more easily) and it's become far more than we could've expected. Ironically, the classic "is this a company or a feature" question might actually be a validation of keeping scope. The only caveat I'd add to the post is that you should try to solve only one problem, but you should spend time exploring before hand to discover the broader set of problems and prioritise carefully. [1] https://eesel.app https://eesel.app

pkoird 4y ago

As a grad student, it seems like a pipe-dream. I've come to acknowledge that maybe I'm not the multitasker I thought I was but sadly, with tens of deadlines to juggle around, no respite for me.

sicp-enjoyer 4y ago
If you're early in the program, I assure you it will get better.

pickingdinner 4y ago

To me this is just a matter of scope for the abstraction you named "problem", because ultimately we can only solve one problem at a time, and everything we achieve is achieved incrementally. Whether you explicitly break up your "problem" into smaller problems by organizing your workflow that way, or implicitly break it up by simply biting off bits as you work seems to be the difference. The former being more planned, with the latter requiring greater mental tracking and ad lib task management. The greatest disadvantage regardless of how you work is task switching. If you're doing push-ups and sit-ups, it's easier to do 50 each x2 than 1 set of 2 each x 50. So if you include switching tasks as a task, you're doing 3 exercises, not 2, and your work becomes 150 instead of 100.

8organicbits 4y ago

At the team level I've liked the advice to only deploy one novel tech at a time. Similar to the article, if a problem happens between subsystem A and B, you'll struggle if A and B are too new to your team. Which subsystem is broken? Can A be patched to fix an unsolvable problem in B? You could end up with a very unusual config for B that would have been cleanly solved in A.

martin_drapeau 4y ago

Making an incremental single change is great advice especially if wrapped in a single Pull Request (or commit). Benefits: A) Easier for your colleagues to review and understand your change B) You can undo your change easily without affect other changes Now, if you do 2 changes per PR, A and B become a lot more complicated and just take more time.

spudzz 4y ago

I remember reading once that Steve Jobs only assigned his engineers one project at a time to optimize focus. A potentially apocryphal story because I later read his biography and didn't find any mention of this. I personally have a tendency to cherry-pick easy tasks and procrastinate on the gnarlier ones. Single-threading projects would force me to confront those difficult tasks and "eat the frog".

hliyan 4y ago

This strongly resonates with recent experience. I've come to realise that a lot of problems in software engineering are a result of either having one thing achieve two or more goals, or having two or more things to achieve one goal. The thing may be a function or a person. If the thing is too big for one person, don't add a second person. Break the thing down until you have enough smaller things to assign to people exclusively.

bazoom42 4y ago

This is one of the reasons “rewrite everything from scratch” so often fails.

Archelaos 4y ago

Although I agree with the general view of the article, the rule "If It Can't Be Done Incrementally, Don't Do It" does not always apply. I once had to refactor a large application from non-currency-aware to currency-aware. This means every single database field and every single operation involving prices had to be touched. Of course, I did not randomly jump around the code and instead tried to do it systematically. But the whole refactoring took several weeks and had to be rolled out all at once.

valbaca 4y ago
> instead tried to do it systematically Exception proving the rule. Yes, sometimes for something as deep as adding currency you do just need to fully refactor BUT I think you're still doing it in the spirit of "One Problem At a Time" You were adding currency, not adding currency AND updating the date library AND touching up the unit testing mocking AND adjusting that CSS for the checkout button (or whatever equivalent).
- Archelaos 4y ago
  Hm. All your examples depent heavily on the circumstances. For instance, if you have a team of coders working on the same code base, it might be preferable to do all these things in parellel and role them out together. I just think that "Do things incrementally" is not so an important advice as the formulation "If It Can't Be Done Incrementally, Don't Do It" suggests. I would rather say: "Prefer to do things incrementally unless you have a good reason to do it differently."
michaelcampbell 4y ago
I'd be hard pressed to find any "rule" in any creative endeavor that _always_ applies, past obvious absurdities.

UI_at_80x24 4y ago

This also applies to the (often over-quoted and miss-quoted) "unix philosophy" of: Do one thing and do it well. It's a different side of the same coin. As a Sysadmin this methodology is CRUCIAL when it comes to troubleshooting. Make one change. Test. Test again. Ask Bob from accounting to test it. (Bob will break it. Dammit Bob, thank-you.) Rinse, lather, repeat.

cainxinth 4y ago

There is a corollary to this advice: only try one solution at a time. If you throw everything you have at a problem all at once you might solve it without figuring out which of the things you tried worked.

das_keyboard 4y ago

There is nothing more exstatic than the feeling of having solved 4 problems at once with one changeset - there is also nothing more devastating than having to figure out which of the 4 changes caused problem number 5.

CodeWriter23 4y ago

I think viewing this within the domain of the count of problems one is attempting to solve at once isn't the proper perspective. I work on the basis of Risk Containment, which often ends up meaning "solve one problem at a time", or "develop list of problems and solve one problem at a time". But often there is risk choosing that approach. Example: a couple of years back, I needed to do a new web app. I could have relied on my tried-and-true jQuery and HTML 5 skils. But with all I had read about Vue and the examples I saw led me to the conclusion I might do better timeline-wise (thus, reduced risk) by using the web app as a vector to learning Vue. I wasn't wrong, things went much faster once I get the hang of how to Vue. My client was so impressed with the work, he asked if I was just middle-manning a white-labeled tech solution from a third party. (Thanks bootstrap-vue!) How would that have turned out if I did jQuery / HTML 5 then a rewrite into Vue to keep it "one problem at a time"? It might have taken 2.5-4x as long. Anyway I look at the "solve one problem at a time" as a useful tool in the tool belt. But it is not an overriding principle. Risk Containment is that principle. A few years back, this was a peripheral tactic, even an afterthought. I've been working with some Risk Containment Ninjas for a couple of years, and the key lesson for me, the iterations are shorter in duration, the cost is less, and the idea evolves to a better end result. It forces you to think about every tiny piece of a project as driving home a MVP.

deleted 4y ago

[deleted]

hbarka 4y ago

Local: Transaction failed. Notified offshore team. Offshore(next day): I see. Local(next day): Process ABC threw an error. Offshore(next day): We will look at A. Serialize as much as possible. Take advantage of time zone opposition and asynchronous communication.

collyw 4y ago

Sounds like a variation on the "Choose boring technology" presentation. I agree with this idea, but there are far too many resume driven developers out there. https://boringtechnology.club/ https://boringtechnology.club/