To-do lists.
Ask HN: What bits of fundamental knowledge are productivity multipliers?
51–60 of 424 posts
Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?
#52Most of these aren't really productivity multipliers, they just enable you to do the thing you need to do. It's unlikely that someone is doing task A without any calculus but another person who uses calculus is 10x more productive on the same task.
You may want to NOT underestimate one's ability to add TONS of if/elseif/else (or switch/case) statemens in order to put things on track... There are various cases of „programming hoorrors” stories where you have a calculator implementation that, instead of doing the ... you know, math, will actually go through all X combinations.
I just had a recent situation like this which initially presented as a simple calendar / due date list, but then spiraled into some dreaded fuzzy set of if/then cases as the client began to add requirements for due dates of certain items in a certain order that would take priority over other items due on the same date, or missed items, or future items that could be done in advance.
After two weeks of increasing horror, and four attempts to write the algorithm, I sent the client something I called the "Blueberry Muffin Problem" email, as a reference to that scene in Casino. But there is no logical way to do this, I said. Anyway. This led to a series of conference calls in which we finally were able to see a clear strategy.
End result: 40 lines of immaculately clean code, roughly $10,000 at $200/hr, problem solved.
I obviously wasn't paid for writing the code in this situation; it was for spending enough time with the problem to find all the edge cases, and figure out the right questions to ask to get to the solution they needed.
Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?
#53* Don't get too hung up on computational complexity. A lot of times O(n^2) is gonna be perfectly fine. Write it the simple and easy to maintain way first, and only worry about fancy optimizations if it's too slow.
in these days of modern CPUS with cache and branch prediction, O(n^2) often beats O(logn) because your data is tiny compared to the cost of all those cache misses and branch misses the seemingly faster algorithm creates. This doesn't apply when you data is large, but then you need parallel algorithms, and not in memory data (or just punt all your data to the sql server)
Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?
#54When not to use all those tricks. I can work with regular expressions, but they are write only code so I don't. Sure it takes me a little longer to parse text, but the next person to come along can understand and modify my text processing code for whatever tweaks are needed.
Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?
#55- understanding your tools: what are you using day in, day out. are there "tricks" or efficiencies you can gain by learning them better? can spending time improving or perfecting your abilities here offer marginal improvement that will pay back and compound over the long run?
- understanding your domain: having breadth and depth of knowledge in what you are building. what is the "pattern language" of your work? can you set up the scaffolding for your project faster/more efficiently each time because you have seen it before? are there common "gotchas" in your line of work that the uninitiated might not know?
- understanding yourself: how do you work best? times of the day, locations but also personal nutrition, sleep, exercise, etc? how can you remove obstacles to get into flow state when needed?
- understanding others: who are you working with? what unique relational aspects might improve the flow of discourse and work between them? can you cut through bureaucracy? can you word things for more effective impact? much like your own working preferences, what are the timing/style/mode/etc dynamics within a group that you can tweak to improve upon?
Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?
#56There is no list. It's not possible to say, "I know these 5 things, and they'll make me more productive." Feynman solved all his physics problems with Calculus. That's it. One tool. Part of is is knowing your tools. The other part is being able to see a problem, break it down, and understand how to manipulate it into something that's attainable. That's it.
I worked with this guy Pat several years ago, and he was on a different level than the rest of us. PhD Mathematics etc. I remember the day that I understood what made him different than me. We were standing in the hallway to our suite in the office building, and the first time visiting he says "This will be easy to remember. Lots of 3's." I looked at him for a moment puzzling his response. He says, "2745, lots of 3s." Pat was better than me at programming, because he saw things in a fundamentally different way than I did. He did things like that all the time. He wasn't better because he knew C++ or Java more than I did. He was better, because he would approach a problem and find a shortcut, or an optimization that the rest of us just didn't see. If something just seemed off even if he didn't know the technology, he could go figure it out, because his grasp of what to look for was much greater. That is what makes someone 10x better.
Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?
#57"Calculus for solving all sorts of problems." Is this really common? I know I'm not in a top tier job, so maybe they don't give dummies like me the hard problems, but I've never had to use calculus to solve a real world problem.
“ Chances are, every time you used your credit card, filled a prescription or pumped gasoline, a calculus formula was used to calculate it.”
https://study.com/academy/lesson/calculus-in-the-real-world....
Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?
#58I think the true 10x multiplier is not a technical skill at all. It is the ability to quickly cut through irrelevant tasks and actions to focus on the thing that will move the business goal forward fastest. It is enshrined in the concept of the MVP and the short iteration cycle. Quicky building something that does not solve a business problem is not productive. Work=force*displacement. No movement, no work. A closely…
This is the right answer. The proof is that a good coder spends about 10x as long thinking about it before actually committing any code. In a sentence: Be able to visualize the problem in your head first. The actual code, if it's elegant and succinct, is incidental.
Exactly I'm living proof that seniority comes with the ability to spend more time on problems to understand all the details before committing stuff which no idea how that works.
Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?
#59[deleted]
Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?
#60Earlier quoted context omitted.
This is the right answer. The proof is that a good coder spends about 10x as long thinking about it before actually committing any code. In a sentence: Be able to visualize the problem in your head first. The actual code, if it's elegant and succinct, is incidental.
> The proof is that a good coder spends about 10x as long thinking about it before actually committing any code. This seems antithetical to the post above yours. Or at least how I'm reading it. In bigger tech co's this looks a lot like massive design documents with a dozen reviewers, all giving enormous amounts of time and thought to the idea in the pursuit of "building it right". Design processes that can take weeks…
I've been thinking about this idea a lot recently. I'm decently new to the big-tech-co space, but it does seem like a huge amount of resourcing goes into design and defense of projects. I wonder what y'all think about someone doing a timeboxed MVP (a sprint or less?) as a way of susing out design, and THEN getting reviewers/etc?
Obviously you have to take security into large consideration when doing things like this - but this is what qa/sandbox environments are for.