Somewhat related aphorism: only break one law at a time.
[deleted]
Only solve one new problem at a time
11–20 of 73 posts
Re: Only solve one new problem at a time
#12Regarding 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 e…
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.
Re: Only solve one new problem at a time
#13To me, it's more about doing CONCURRENTLY is the key. Concurrency also means solve one problem at a time, but in multiples timestamp instead.
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.
Re: Only solve one new problem at a time
#14As 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?
Re: Only solve one new problem at a time
#15I 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
Re: Only solve one new problem at a time
#16Ben 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...
Re: Only solve one new problem at a time
#17This 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.
Re: Only solve one new problem at a time
#18This 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 th…
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.
Re: Only solve one new problem at a time
#19This 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.
Re: Only solve one new problem at a time
#20Earlier quoted context omitted.
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.
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"…
> 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.