31–40 of 73 posts
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.
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".
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.
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 e…
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…
Ed, I'm glad you are still here :) - A fan
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!
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…
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…
For example, there's a bug in the login system, again. Ok, we could probably fix it, but this is an old system built by outside contractors (aka "built cheaply, but expensive to maintain"). It's not the first bug, and won't be the last. There's some technical debt in the way it stores unsalted sha1 passwords, password resets work in a way that allows an attacker to effectively lock out accounts and do a DoS. Looking forward we have customers asking about MFA and SSO support that this system just can't do.
"Solve only one problem" philosophy says to just fix the bug. This is a case where replacing the system (whether buy or build) might make more sense. You have to be pragmatic about this of course, because if you can't live with the bug for however long it takes to replace the system, it isn't going to fly.
I'd still advocate some constraint, though: iteration 1 should fix the bug(s) and underlying tech debt, but shouldn't be adding anything new.
Some of the most productive work I do is this style because it's often only a bit more effort. I used "login system" only as an easy to understand example, it's often more subtle, along the lines of: refactor a class so it has unit tests and fixes 3 other related but low priority bugs at the same time, instead of just patching. Instead of a day, it takes a week, but more value was delivered (other bugs fixed), there's significantly lower chances of bugs in the future (as future dev work happens), and we can reduce or eliminate manual QA on that component. The extra 4 days have saved dozens we'd spend over the next year if we dogmatically stick to "one thing at a time".
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.