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.
Only solve one new problem at a time
21–30 of 73 posts
Re: Only solve one new problem at a time
#22I 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
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.
Re: Only solve one new problem at a time
#23To 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.
Re: Only solve one new problem at a time
#24I slightly disagree with one point. There's not a better time/way to learn a new language than on a new/real project.
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.
Re: Only solve one new problem at a time
#25As 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…
[deleted]
Re: Only solve one new problem at a time
#26At 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.
Re: Only solve one new problem at a time
#27This 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…
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.
Re: Only solve one new problem at a time
#28As 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…
Ed, I'm glad you are still here :)
- A fan
Re: Only solve one new problem at a time
#29Making 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.
Re: Only solve one new problem at a time
#30This 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…
I think the post is discussing building software/product not managing teams of people.
Also a manager is not synonymous with a high bandwidth engineer.