Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Only solve one new problem at a time

bennadel.com

Post reply on HN
Print view View original

51–60 of 73 posts

Re: Only solve one new problem at a time

#51

Post by CodeWriter23 »

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.

Re: Only solve one new problem at a time

#52

Post by michaelcampbell »

Archelaos wrote: post #38

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

I'd be hard pressed to find any "rule" in any creative endeavor that _always_ applies, past obvious absurdities.

Re: Only solve one new problem at a time

#53

Post by zelphirkalt »

edw519 wrote: post #14

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…

That can be a horrible time sink as well though. Imagine if only changing one thing means, that you need a test cycle of 15 minutes or even if it is only 5 minutes. You will need 5 minutes per change then. If you know multiple things you still need to change ahead of time, you might also go ahead and fix them all, and then fix resulting or remaining issues after only running one test cycle.

I think it depends on the situation, what the best approach is. Is it a system, which is running in production and you are operating an "open heart"? Well, better only change one thing and check. Is is a newly developed thing, which you develop on your own dev machine? You can easily fix many things and many more will still remain for further iterations.

Re: Only solve one new problem at a time

#54

Post by DenisM »

edw519 wrote: post #14

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…

You can also bisect your commit history to find the problem source in log time.

Re: Only solve one new problem at a time

#55

Post by 100011_100001 »

edw519 wrote: post #36
100011_100001 wrote: post #28

Earlier quoted context omitted.

Ed, I'm glad you are still here :) - A fan

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!

In this thread: https://news.ycombinator.com/reply?id=33384309&goto=item%3Fi...

You talked about having a positive mental attitude being really helpful in overcoming shortcomings. This implies you didn't start that way and you learned the behavior.

Can you explain the thought process you adopted? I sincerely struggle with having a positive mental attitude (see I did it again) but I have recognized it's a huge indicator of a better life (social, work, family etc)

Re: Only solve one new problem at a time

#56

Post by randyrand »

DenisM wrote: post #54
edw519 wrote: post #14

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…

You can also bisect your commit history to find the problem source in log time.

If you have separate commits for each thing, then you’re only changing one thing at a time, code wise.

Re: Only solve one new problem at a time

#57

Post by arise »

zelphirkalt wrote: post #53
edw519 wrote: post #14

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…

That can be a horrible time sink as well though. Imagine if only changing one thing means, that you need a test cycle of 15 minutes or even if it is only 5 minutes. You will need 5 minutes per change then. If you know multiple things you still need to change ahead of time, you might also go ahead and fix them all, and then fix resulting or remaining issues after only running one test cycle. I think it depends on the…

A notable historical example was NASA's "all-up" decision to launch all stages of the Saturn V on the first test: https://appel.nasa.gov/2010/02/25/ao_1-7_f_snapshot-html/

“In retrospect it is clear that without all-up testing the first manned lunar landing could not have taken place as early as 1969,” von Braun wrote. “It sounded reckless, but George Mueller’s reasoning was impeccable.”

Re: Only solve one new problem at a time

#58

Post by d4mi3n »

zelphirkalt wrote: post #53
edw519 wrote: post #14

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…

That can be a horrible time sink as well though. Imagine if only changing one thing means, that you need a test cycle of 15 minutes or even if it is only 5 minutes. You will need 5 minutes per change then. If you know multiple things you still need to change ahead of time, you might also go ahead and fix them all, and then fix resulting or remaining issues after only running one test cycle. I think it depends on the…

I think this may be a misattribution of what soaks up time: is it the change itself or the friction of the process of making that change?

e.g. code changes are easy but merging and build procedures take a log of time, encouraging larger batches of concurrent work.

Re: Only solve one new problem at a time

#59

Post by edw519 »

100011_100001 wrote: post #55
edw519 wrote: post #36

Earlier quoted context omitted.

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!

In this thread: https://news.ycombinator.com/reply?id=33384309&goto=item%3Fi... You talked about having a positive mental attitude being really helpful in overcoming shortcomings. This implies you didn't start that way and you learned the behavior. Can you explain the thought process you adopted? I sincerely struggle with having a positive mental attitude (see I did it again) but I have recognized it's a huge indicat…

Interesting question. Thanks 100011_100001.

I always had a positive mental attitude. Not really sure why. Difficult childhood? Last kid picked in kickball? Couldn't get a date? Knew nobody was ever going to give me a thing so I would have to do it myself? Who knows? Way too much to think about for an answer now, but that's OK because...

My problem wasn't that I didn't have a positive mental attitude.

My problem was that I didn't know I had a positive mental attitude.

I was a typical nerd who found solace in math and programming but somehow worked my way up into a dev / project management / digital rainmaker position. My customer wanted me to do something he knew I could do that no one else had been able to do (something boring sounding like "implementing a factory shop floor control system").

He became so exasperated at my pushback (I can't. It can't be done. It's too hard. etc) that eventually yelled at me something like, "You know the business! You know the tech! You're good with people! You have PMA! So what's the f*in problem?) I asked, "What is PMA?" He said "Positive Mental Attitude!"

That conversation changed my career (and my life). And he became my major mentor. (That's why I thought of him in that "Advice that changed your life" thread last week.

This may sound bizarre and counter-intuitive but I think the short answer to your question may be, "You have PMA when you decide you have PMA."

Over the years, I've witnessed countless counter-examples to this: people don't have PMA because they don't know they have PMA so they never "breakthrough" like they could.

I'm so glad I met that mentor. Thanks for reminding me.

Hope this helps.

Re: Only solve one new problem at a time

#60

Post by flappyeagle »

edw519 wrote: post #14

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…

  - It works. You need to add 16 things. You add 1 thing at a time. 16 operations later you are good but the deadline has passed. Fired.

  - It works. Add 16 things. It doesn't work. Remove 8 things. It works. You've eliminated 8 culprits. 4 operations later done. Delivered on time. Get a promotion.

  - One donut left. 2 programmers went into the break room. No donuts left. Who ate it? Not any of the 30 programmers outside of the break room. Ask the 2 programmers who did it. Prisoner's dilemma. Fun had by all.
Post reply on HN