Live data from Hacker News

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

news.ycombinator.com

61–70 of 424 posts

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

#61

Earlier quoted context omitted.

Isn't the measure of that how much you get paid? If we assume you get paid $100 to make a button, I think OP's question is how to do that in 1 minute instead of 10 minutes. You know, so you have 9 extra minutes to watch youtube.

The measure of how much value YOU generate for YOURSELF is how much you get paid. But generally, if you can generate a lot of value for the company, and demonstrate it, you will go far, and you will make much more money, especially if you can do it consistently and threaten to leave. Doing a jira ticket in 20 minutes instead of 2 hours, then spending the extra time watching youtube is fine, but how about becoming a m…

;) heh.

I can't relate because I've been freelance since 2001, but I do remember how much I hated the fact that my bosses bought new cars and took trips and took credit for my work while I was making $8.50/hr as a junior webmonkey. Guess I never saw the future in it. But if I knew I'd be flying first class now, maybe I would reconsider...

In all seriousness, though, aren't people mostly paid what they're worth if they know how to demand it?

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

#63
1. Super learning techniques Srs, memory palace, speed reading or time shifting video/audio

2. Model based thinking: Big book of mental models is a great place to start.

3. Learn how to train your dog properly (perhaps the single biggest life hack a person can do imho)

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

#65
post #15

Not technical but the self-knowledge of how to put yourself in a productive state. Knowing how to sleep well, eat well, exercise well to allow yourself to perform at a sustained high-level. Someone may be more technically competent at a problem-space (at the start), but if you are able to work diligently at the problem over a sustained period, you will have 10x better results than those who crash/burnout/lose interes…

The mental model for this state is known as "flow" or atheletes sometimes call it "the zone"

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

#66
post #46

Earlier quoted context omitted.

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

A pot of big corps have Hackathon weeks for doing just this. A free-for-all to build something you want and that you think will be helpful to the org from your perspective.

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

#67
- Writing as form of (or tool for) thinking; Leslie Lamport said (maybe quoting someone) that if you're thinking, but not writing, you only think that you're thinking;

- High tolerance for feeling ignorant, confused, silly, inadequate, a novice: none of these states should phase you: you should not have a comfort zone: let your mind feel at ease in not understanding something: go to the eye of the storm and weather it: you'll come out being more capable;

- Formal specification (maybe TLA+) when doing something unintuitive, like non-trivial concurrency; or, simpler put, think before you do;

- Functional programming, immutability, state machines, reactive programming: whatever you can do to make your systems more declarative and their state easier to reason about;

- I'm a geek for tools, and I know that not everyone is like me, but for me choosing the right stack for the job is a big deal, and when saying stack, I mean every tool I'll be using, from the programming languages, to deployment tech, to testing setup; a good tool can effortlessly solve a host of problems.

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

#68
post #46

Earlier quoted context omitted.

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

Hell, wait till you find out how much time is wasted in Dev/Ops just changing the tooling every year or two, literally tearing down and rebuilding everything you already have in the name of staving off another couple years of technical debt. It's silly.

I'm a bit of a rarity in the modern world (and here in the corporate space that is HN), in that I'm the sole programmer on a bunch of large software projects in production that I also maintain and sysadmin 24/7. The only meetings needed are to understand what the clients want and bitch at them that what they want makes no sense, until they start making sense, and then trust me to build it. If something comes up from a design perspective that I think could go one of several ways, I usually have that thought in the shower and mumble to myself for awhile before framing it in terms they would understand as a series of yes/no choices.

This is generally way more efficient than hiring a team, and I know, because I've tried to hire teams to do it. There's a limit to what one coder like me can do, but it's a lot higher than what 4 people bickering can do. I'd say it's around what 8 bickering people can do.

Design and defense of design, though, is not just about ego. Not if it's done properly. The best design/code people will come to you and say this is why this is the only way to do X and lay out the chain of logic that led them to that conclusion. That's not because they'll be personally hurt if you don't go that direction; it's that they're annoyed they'll have to do extra work to make an inferior product if you don't take their advice. Promote those people.

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

#69
post #17
post #3

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

I think it's also possible that some of these lead to a I've-got-my-hammer-and-everything-is-a-nail approach to problem solving. You may then find yourself parsing HTML with regexps ( https://web.archive.org/web/20111009133402/http://stackoverf... ), which is never a good idea.

This is called "law of the instrument"

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

#70
my 2c, I think 10x vertical (better individuals) is not viable for everyone, but 10x horizontal (better teams) is more accessible. Things like good documentation, testing, and collaboration tools and practices go a long way in 10x'ing a team.

my only 10x personal practice is: take notes on everything. build a knowledge base. it doesn't have to be presentable, they can be scratch notes, dumps of important links and details. over time this accumulates, and when a given topic comes up again you'll be prepared to seamlessly pick up where you left off.

Post reply on HN