Live data from Hacker News

Ask HN: What bits of fundamental knowledge are productivity multipliers?

news.ycombinator.com

191–200 of 424 posts

Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?

#192
The ability to rapidly context switch. So much of my day is filled with meetings with 30 minute breaks in between. I pretty much do nothing with those 30 minute gaps because I cant refocus on code fast enough to be productive. So most of my coding is done in the last quarter of the day and I probably waste 1.5 hours a day on just waiting for the next meeting.

Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?

#193
System bounds/invariants, ie things that you know can or can't be true. They can be about hardware, os, algorithms, networks, etc.

They allow you to quickly pinpoint problems, and avoid exploring places you shouldn't explore ( which is very handy when designing a new system) .

Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?

#194
post #24

"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.

Just for personal investing I've used calculus amidst some basic modeling to estimate probability of getting certain outcomes under certain assumptions and compute an expected value. This is just to sanity-check my thinking, or to see what the market's thinking. To understand basic financial concepts, like the present value of an annuity, or implied volatility, requires calculus. In boring software, simple questions…

I took calculus in high school and did really well in it - but I honestly can’t say whether I’ve used it or not as an adult, because all of my mathematical knowledge kind of runs together in my head.

I realize it’s a big ask, but is there any way you’d be willing to put together an example of when and how you’ve used calculus for a specific purpose where it really shines?

Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?

#195
post #5
post #4

Earlier quoted context omitted.

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.

True, as I wrote the calculus example I remembered this post about a medical researcher rediscovering integration - https://news.ycombinator.com/item?id=26384357 But it still feels more like unknown unknowns causing you to put in a lot of extra effort; I wouldn't classify these as productivity multipliers.

That's actually not so bad. Physicists in the 20's reinvented matrix math.

Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?

#196
When I code and have an idea or when I spot a non urgent bug, I write a FIXME and forget about it. It allows to concentrate on going forward and leaving alone "details".

(of course, from time to time I debug and fall on one of those FIXME's :--))

Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?

#197

I 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…

The main thing is to keep the main thing the main thing. --Steve Covey

Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?

#198
> * Regular expressions > * Parser combinators > * Parser generators

I sometimes forget how I take regexes for granted, and how some people don't know them.

I would replace the combinator/generator stuff with "how to cleanly make a hand-written parser." Developers frequently stumble through that quite badly.

Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?

#199

Earlier quoted context omitted.

How so? The comment clearly states that they aren't doing any formal calculations, not using numerical methods, and just getting approximate insights. If I'm wrong, show me I'm wrong and post a substantive comment. Snarky comments like that are not inline with HN guidelines.

It's not a snarky comment, it's literally, not actually basic logic. You had no factual basis for saying it was. Basic logic is here: https://en.wikipedia.org/wiki/Mathematical_logic Dynamical systems has stuff that is not basic logic such as this topological concept which is applicable in understanding how stuff works without doing an actual calculation: https://en.wikipedia.org/wiki/Limit_cycle That's calculus. Not…

You misunderstand. This is the basic logic I was talking about. Note my comment mentioned philosophy.

Same for limit cycles - they make no mention or this type of calculation. The concept can exist in other domains such as systems thinking.

So concepts do exist outside the context of pure math. If you look at everything from a hard math perspective, then that is what you will see. You have to look at the context of the comments to understand. It's not necessarily calculus because the commenter might not be looking at it using those strict theories. There's no support for your assertion that it's not philosophy or not logic. It could coincidentally be similar to a calculus concept, but that doesn't mean that one is using calculus if they are approaching it from a different context that shares a similar concept.

https://en.m.wikipedia.org/wiki/Philosophy_of_logic

Re: Ask HN: What bits of fundamental knowledge are productivity multipliers?

#200

The ability to rapidly context switch. So much of my day is filled with meetings with 30 minute breaks in between. I pretty much do nothing with those 30 minute gaps because I cant refocus on code fast enough to be productive. So most of my coding is done in the last quarter of the day and I probably waste 1.5 hours a day on just waiting for the next meeting.

I think the opposite of this would be 'the ability to manage time'. No matter how good or fast you are at context switching, there is still an inherent inefficiency in it, and it does take a mental toll, whether you admit it or not.

People might say that 'I can't avoid the 30 minute meetings' but you can certainly set expectations, learn when to say no, etc...

Post reply on HN