Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

271–280 of 424 posts

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

#271

Post by rawgabbit »

edelans wrote: post #225
futureshock wrote: post #21

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…

Amen. or as Peter Drucker puts it (he is dubbed as "the founder of modern management" on Wikipedia) : "There is nothing so useless as doing efficiently that which should not be done at all." https://en.wikipedia.org/wiki/Peter_Drucker

"If you don't know where you are going, it doesn't matter how fast you get there."

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

#272

Post by FL33TW00D »

1. Deep deep knowledge of your text editor. I am biased towards Vim, but many others can work if you know them inside and out.

2. Learning multiple programming paradigms, bare minimum 1 declarative and 1 imperative language. Build something substantial.

3. Understanding yourself, what times you work best, diet, fitness etc. I find where and the setting of where I am working is extremely important.

4. Broad (but not necessarily deep) knowledge of DS&A. Knowing a thing exists is enough to search it.

5. Broad (and preferably deep) knowledge of computers on a fundamental level. An approximate understanding of what the statements you are typing into the machine are “translated” to at each stage.

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

#273

Post by giraffe_lady »

Ancapistani wrote: post #186
adampk wrote: 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…

As someone who struggles with ADHD and depression, this isn’t always possible . At 38 years old, what I have discovered are ways to make myself valuable to my employer even when I’m not at my peak. The move to a more “architectural” role has been a Godsend for me. It means that I’m a let to serve to some degree in an advisory capacity for others. When I’m not able to enter “flow” with my primary project, I can usuall…

ha, lucky. I have a similar constellation of problems and never found an employer willing to tolerate it long term. I can put large volumes of high quality work for 3-5 weeks at a time followed by 2-4 weeks of a low output slump. I usually get fired on the fourth or fifth cycle, freelance for a while, then try again.

Always hoping to find somewhere willing to accept the inconsistency in output but haven't found it yet. Anyways it's cool to hear someone in one of these threads acknowledge this reality for a lot of people. The general HN consensus seems to be that anyone who isn't a top 10% technical star and an incredible productivity machine doesn't deserve to touch code.

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

#274

Post by warrenm »

ozim wrote: post #238
warrenm wrote: post #113

Earlier quoted context omitted.

It always amazes me the number of people - especially programmers/developers - who absolutely can NOT read a stacktrace of any kind

Especially devs who have years of experience are surprising me when it turns out when I take over that error was abvious and right there in the exception with stack trace.

Sometimes it's the problem of not being able to see what's there because you already [mentally] eliminated it

But I agree - SO many times the error's hanging out right there in the stack trace, often to within a few characters or lines of the "real" error in the source!

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

#275

Post by Ancapistani »

fn1 wrote: post #84

Solving problems iteratively in the same way progressive jpegs render: Start with essential parts, quickly assemble them to a usable draft and iterate on the entire thing by improving quality where it needs to be improved. This is applies to programming as well as to writing, drawing, making music etc. Applying this to writing emails can definitely improve your business communication 10-fold: * write down the importa…

> Solving problems iteratively in the same way progressive jpegs render: Start with essential parts, quickly assemble them to a usable draft and iterate on the entire thing by improving quality where it needs to be improved.

This is something that I feel I’m really good at, and I like this explanation a lot.

I’ll add that while being able to look at problems at a high level and then slowly increase “resolution” is a huge advantage, the key in my experience is the ability to switch between those levels of abstraction quickly.

The more complex a system, the more important this ability can be.

Let’s say you’re building out a large new feature that can be implemented in three parts: Service A, Service B, and the communications between them. That’s the highest level of abstraction: we are dealing with three components, each of which has a very high-level purpose/domain.

Once each component has a defined domain, we can disregard the other components when drilling down into each one. This works very well, but invariably we’ll reach a point where we discover than an assumption that was made at a higher level is no longer valid.

At that point, there are two options: we can stay this level of abstraction, leave our component domains unchanged, and “work around” the issue. Sometimes that’s fine and leads to relatively minor hacks or technical debt. Other times, it’s not fine, because the violated assumption can be much more easily remedied by going up a level of abstraction and changing the domains of our components. Often, the assumption that didn’t hold in Service A also impacts Service B, and doesn’t hold their either.

Maybe that will result in splitting the problem into one more service; maybe it will mean that the domains of each service need to be adjusted so the issue is isolated into one of them; maybe it means that we chose to split the problem up along the wrong boundaries to begin with and need to reconsider them entirely.

My point is - starting at the most abstract level and working your way down is powerful, but you don’t always have all the information necessary the first time you walk down that complexity tree.

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

#276

Post by rmbyrro »

loves_mangoes wrote: post #29

All those little bits of knowledge are nice tools and patterns, they're definitely good to have. And if you have curiosity, you will naturally keep learning dozens of those over time. But they are not applicable everywhere, so you should not expect your 8 hour days to turn into 48 minutes because you started using regexes, dynamic programming, and search algorithms everywhere. The unlikable and unhelpful answer, but…

> The harsh reality is that there is no single thing a 1x person can do to become 10x.

Any evidence for this? You may say there's no evidence that a 1x person can work up to 10x its performance, but stating it's impossible without evidence lacks merit.

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

#277

Post by monksy »

eternityforest wrote: post #219

A lot of those are pretty domain specific. Calculus is 10x only because it lets you get into fields where calculus is 10x. I have no idea what a general everyday coder would do with it. I could list tons of design patterns, like separate mutable and atomic readonly copies of the same data, but they wouldn't be universal, although patterns are wonderful. The closest thing to a real 10x I know is laziness and respect f…

> Riced desktops? Gone. Custom made productivity apps? Gone. Simple bash scripts to move files around and do backups? Gone. Distro hopping? Extra gone. New JS frameworks? Gone but with napalm. Making your own programming language? Not gone because it never even started.

This sounds more like depression rather than something that helps you grow. Yes, in production and production like environments, be boring. It helps. But discorgaging people from getting into that is a path to dis-encouraged engineers. People experimenting with weird things leads to innovation and learning.

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

#278

Post by giraffe_lady »

gjvc wrote: post #38
jorgeleo wrote: post #20

I would like to challenge the underlaying idea: Asking "what fundamental knowledge" is like asking what telescope makes the best astronomers. The problem with knowledge is applicability. You can know a lot of fundamental things, but if you cannot recognize the patterns were they are useful is dead knowledge. My personal experience through my life (30+ years in the field) and observing and interviewing developers in m…

this is an unhelpful response: the guy asks a straight question and the response is to "challenge the underlaying [sic] idea" It would be better to answer their question, rather than attempt to knock it down. (good example of zero-sum bias.)

It is actually pretty astute and on the topic to me. Skimming through here, a lot of people mention the fact that as they grow into their careers, one of the biggest gains is judgement about what sorts of problems even should be solved.

Or like. If someone came in asking "I'd like to make my car go faster, should I paint it green, or blue?" it's not unhelpful to point out that that's a solution to a different problem.

Plus anyway the audience is greater than just the person who initially posed the question. Conversations around this and other similar answers are vibrant today, so clearly they're helpful to someone.

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

#279

Post by amboo7 »

rmellow wrote: post #252

Making assumptions & cutting down on scope are immensely powerful tools. There is a tendency among engineers to create systems that are universal and work in all sorts of environments, when in fact, this is not what is absolutely immediately needed, or is closer to a "nice to have". A widespread example of this is linear regression analysis. Mathematically, it only works because we make assumptions about the data (an…

If only such assumptions were ever written down.

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

#280

Post by heyflyguy »

jdauriemma wrote: post #240
heyflyguy wrote: post #42

Employ a virtual worker that schedules meetings and replies to low-level emails. Disconnect yourself from real-time communications during those hours and allow your VA to contact you in cases of urgently needed replies. I employ a lady 20 hours a week for this, so I get core time about 4 hours a day to do whatever I want. Even if it's pc gaming. Costs me $15,000 a year and is well worth it.

Can you elaborate on how this "virtual worker" works in practice? I'd love to learn more.

She logs in remotely on my email. To get her up to speed she watched what and how I replied to things for about a week, until I had her start drafting emails as replies that I would approve (or edit) and reply. After a while she just got it. She's based in the Philippines and works from 11p - 3a her local time. I proactively schedule my conflicts and times in my calendar, and then she can schedule anything in the open space.

I could just not answer for a few hours a day, but I have alot of people who expect a quick response. This solves that and gives me back my evenings to spend with the family.

Post reply on HN