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

I’d love to be more at ease on uncomfortable situations. Any tips?

Whenever I find myself in an anxious or uncomfortable situation, the thing that I need to remind myself is that things are going to turn out okay for me, whatever happens. I do this by working my way up a version of Mazlowe's hierarchy:

1. Am I physically safe? Can I breathe? Can I move my body?

2. Do I have access to shelter? Do I know where my next meal will come from?

3. Are my loved ones safe? Do I have friends and people who care about me?

4. Do I have skills that I care about? Can I do work that I'm proud of?

5. Do I have a job that gives me money? That I like to do?

In pretty much any uncomfortable situation you're in (at least in the context of career improvement), almost all of these things are totally unaffected. The sun will rise tomorrow, even if I bomb this programming interview. My friends will still be my friends, even if I do a bad job networking at this event.

And the fact that so many of the good things in my life will still be good, even if an uncomfortable situation goes as badly as it can, gives me a lot more confidence.

And then, like anything else in the world: practice, practice, practice. The more uncomfortable situations you put yourself in, the more you practice reminding your brain that "everything is okay, actually," the less uncomfortable you'll feel in any given situation.

A big part of learning to deal with anxiety is understanding that an anxiety attack is rooted in a chemical, physiological response that you can't control; sometimes what you need to do is just ride it out, and let your body get back to normal.

Math problems, loud music, singing songs -- great ways to "get out of your brain's way" as my therapist used to put it.

There's a reason people keep pictures of their family at their desks; it's not just for decoration :D

I make it a point to count my many blessings (most of which you enumerate there) every day.

If you went to the gym and did a really easy workout that was comfortable.. that would be a bad gym session. The goal is to push yourself. Not to injure yourself but to go until failure.

We don't learn in the comfort zone. We learn and grow by pushing ourselves where we feel like we might fail and then pushing until we fail.

Success isn't a game of avoiding failure. Success requires learning and growing from repeated failure. Failure isn't the opposite of success, it's part of it.

Feeling dumb, not knowing where to go, having difficulty even reading and comprehending material is when we know we are engaged in building ourselves.

The same goes for work. I'm a hard worker, but I'm not gonna bust my balls at some startup so the CEO and his buddies can make a billion. Not unless I'm one of the founders.

Some people have already done a shit ton of learning and growing, and maybe they're at a different stage in their lives. Like the stage where their 30+ years of experience are extremely valuable without grinding 50 hours a week.

You should, as a person, work to grow and be stronger no matter your age, whether that's squatting 400lbs or doing your water aerobics. Work the correct weight for you.

You should not bust your balls at some startup so someone else can get rich. That isn't helpful. Don't do that, regardless your age.

Regardless, everything has a cost. If you are in a place where you can spend time at your leisure then that is something to be admired. You likely paid the cost for that (by grinding 50 hours a week) up front.

For the younger crowd here, perhaps they should grind 50 hours a week so they too can build their "fortress of solitude".

But if they can do it at half the cost, that would be ideal wouldnt it?

Umm. Actually, as far as I know, that's completely false. What you're describing is a bad way to train your body. If you're failing reps, you're training your body to fail. I.e. "one more rep" culture is misguided. You don't want stress or exhaustion hormones in your system. If your goal is enhancing your body, that is. Looking at my notes, my source is Pavel Tsatsouline #1399 episode on Joe Rogan's podcast. If you can get a hold of that podcast, it's very informative.

I won't comment on what you said about the mental aspect of failure.

You don't "train your body to fail". You may be training bad form - and form failure is failure.

For what it's worth, I'd say that it's about being at ease with being uneasy. I find it unproductive to try to get rid of uneasiness.

Mainly playing music with a group, sometimes writing and occasionally drawing or painting. It focuses me on the emotional experience and response to entering the unknown and finding flow there

There's a book called Art and Fear that nails the tao of it.

"Art & Fear: Observations on the Perils (and Rewards) of Artmaking"

It's surprisingly relevant to what folks like us go through, and how we relate to our creations, intangible though they might be (at least if you're purely in software).

Their most noticeable effect on me was a dramatic decrease in anxiety, and an accompanying increase in comfort in social contexts and far less catastrophizing about challenging life situations.

What are some tools to do this? When I feel I don’t know something, I feel very anxious, stupid and unhappy. How did you develop the skill to be okay when ignorant?

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 interest/try to sprint to the finish.

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 usually find someone else with a problem that they’re struggling on, pair up with them, and help them get over whatever is in their way. This makes the team as a whole significantly more productive.

As a bonus, I often find that focusing on a problem of short duration helps me overcome the mental barriers to becoming engaged in my work and lets me get done what I was struggling not to avoid doing in the first place.

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.

This sounds 100% like me.

I currently work for a healthcare company in the mental health space. We’re definitely hiring. Shoot me an email, and we’ll see if we can’t get you into the interview process.

nominallyanonymous@protonmail.com

Those of us who are like this are a “good value” to them - both in terms of relative pay, and because we tend to be VERY loyal when we find a “home.”

So the productivity multiplier advice is this: learn to cope and be productive at doing the kinds of work where flow is impossible/unfeasible!

(This way you'll not be already tired and behind when you get to the work for which "flow" is possible...)

Flow happens during fun.

Sometimes there are shortcuts to grinding that can only be discovered during "flow" (usually for me, it's to identify better tools)

- SAT modeling languages & SAT solvers

- same for SMT (satisfiability modulo theories)

- Constraint programming

- MIP (mixed-integer programming) and its special cases, like

- TSP (traveling salesman problem)

The latter is maybe more anecdotical (as in: fewer direct applications), but it is emblematic of the whole phenomenon. We see a steady stream of claims that NP-hard problems are "impossible" or take "billions of years to solve". We also see blog posts with the latest ML approach "doing the impossible" and providing reasonable (not optimal) solutions to 50-city TSPs. All this while ignoring that with proper maths, we could solve 50-city TSPs to optimality by hand in the fifties, and now Concorde routinely solves 100k-city instances in seconds on an iPhone.

About half the people I have worked with when faced with the task of writing a 40 character line of code will do something like find a similar line and copy and paste it, and then change a character or 2, and then go find a 6 character variable that they need to type and instead of just typing the 6 characters, they highlight another copy of the variable with the mouse and then copy and paste the 6 characters. The whole thing is really frustrating to watch when you're pair programming with them. I'd be surprised if they're getting more than 10 WPM through all of this. It's got to be a huge mental burden for them as well; I mean, getting a few characters on the screen shouldn't be a mental exercise, you shouldn't be thinking about where you can find a similar line you can copy/paste, and you shouldn't be thinking about where else you can copy/paste variable names from. Getting a line of code onto the screen shouldn't be a creative endeavor.

I know being able to type 100 WPM isn't a great advantage when programming, but a minimum of typing skills, a mere 20 or 30 WPM, is important.

"Here's the industry's dirty secret: Programmers who don't touch-type fit a profile. ... Here's the deal: everyone is laughing at you. Or if they're your close friend, they're just pitying you. Because you suck."

* Micro-optimizations: e.g. a shortcut that saves you a few seconds several times a day.

* 'Mid'-optimizations: e.g. writing an script that saves you an hour once a week.

* Macro-optimizations: e.g. pushing back against building a useless feature that saves you several months in a year.

Most developers focus in the micro level, but I believe 10x productivity lives in the macro level. Also the macro level doesn't need as much tech skills as it does soft skills and domain knowledge.

As an exhibit, in my career I've seen two projects that

a) never launched

b) took several people several months to build

c) would have never been built had someone pushed back and asked the right questions at the start.

So much effort is spent on building the wrong things for the wrong reasons.

- fully specify the problem before jumping in. Write what you know, the context and the unknowns.

- Write the steps of the solution before jumping into a problem.

- If writing a report, create the outline/heading structure before doing any other writing.

- If you want to do something non-trivial, quickly search the web to see if someone has written a library or has a one-liner to save you time.

- 80% of your results will come from the first 20% of the total time you spend working on something. Anything after that is polish. This helped me to overcome perfectionism.

- If you don’t know something, ask a colleague or peer. They will be thankful for the opportunity to teach you something.

- If you’re ‘stuck’ on something, completely switch context for an hour or even a day. The subconscious mind does serious heavy lifting, it just needs time (and rest!).

- if you’re learning a new concept and struggling, don’t write detailed notes straight away. Your notes at this stage reflect a naïve understanding. Letting an idea ‘ferment’ before writing about it will result in primo notes.

- Don’t spend too much time buggering around with tools and tech. If you’re spending more than 30% of the total task time on ‘ceremony’ or ‘config’, it’s a hindrance.

There’s more but these are the main ones.

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.

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.

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.

I always wondered, if he thought this trough a little bit further, he'd independently reinvent the arabic number systems.

https://en.wikipedia.org/wiki/Natural_sort_order

I think by "physicists" I should have said, Heisenberg. I'm talking about this: https://en.wikipedia.org/wiki/Matrix_mechanics#Heisenberg's_... https://en.wikipedia.org/wiki/Heisenberg's_entryway_to_matri...

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.

This is how Jon Bentley starts his classic Programming Pearls

"What are you doing...and why?"[0] is almost always the best place to start when tackling requests from customers

------------

[0] my review/reference in relation to this exact problem, of asking the right question

---

I'm putting this down here because, even though it seems obvious, it's not; if you spend 10 or 20 hours really thinking seriously about what happens if people write early reports or late reports - the initial conclusion was just count how many they wrote into how many they sent, and tell if they need to send more, but that's not the way life works. Or people work. And it's going to create impossible bottlenecks if the last report is the most important one. The insight I had and what's going to drive this thing is: How many reports were due since the last one you sent. Again, that seems simple but it's not. Technically it doesn't mean they just skip them; it means if one was due Monday and one Wednesday, and you send one on Tuesday, that covers Monday's report; but if you sent it on Wednesday it covers both, the idea being to discard the missed ones without explicitly saying so, and drive them to do what's important today, and more important if it's the final day.

It also covers the situation where they filed Monday's report early, but only if they've filed all the needed reports prior to that; otherwise they'll need another one for Monday.

That's why this is so hard. It's not the code. It's the number of possible scenarios.

So the rule is, we start counting again from when the last report was written, in terms of priority. And when you're looking at 50 reports a day per franchise, you'd better know what the priorities are.

For myself personally, I think this is writing software that will lead to absolute catastrophe. I've always tried to align the way my software works with how I think people will be able to use it, to push them to do the right thing. Anyone can write the software I write, it's the thinking about this process that is extremely difficult if you're dealing with, like, hundreds of [redacted] and thousands of customers spread out over time, and have to figure out how to make reasonable suggestions. This is such a thing.

What I'm saying is that this is marching into creating a thing that will cause total chaos and I don't think this is the right way. We have the chance now to re-imagine the frequency and rearrange the expectations of the customers and the expectations placed on the staff, and I think we need to do that. The algorithm you asked for is done, but it will not be good for people. And it is extremely hard to understand, even for me, if you asked me why one should take priority over another, when dozens are urgent on the same day. I wrote an "urgency" algorithm on top of it to try to deduce that. The best I can say about it is that it will cause less misses and damage than any other way of looking at the list, and it took me a long time to get to. But I think you're asking for something that is going to be so inefficient, and create such high customer expectations, it's going to be negative on both sides.

The scene keeps going through my head from "Casino", where De Niro tells the chef in the hotel to make sure the same number of blueberries are in every muffin, and the chef just drops his hands and goes, "do you have any idea how long that's going to take?" This is a blueberry muffin situation. We need to think of a better way.

A closely related skill is the ability to cut through all the abstractions and interfaces to get to the root cause of what is broken or needs changed. A technical and organizational debt buster if you will.

Edit to add that the course was “Time Management Fundamentals (2016)” by Dave Crenshaw. I completed it on LinkedIn learning. For those of you who’d like to give it a try, my advice is: do all the exercises. You won’t get the full value out of the course unless you actively incorporate the whole routine into your workflow. There’s a learning curve, but it’s absolutely worth it. Also be warned that the presenter’s personality is a little off-putting (to me, anyway), but he absolutely knows what he’s talking about, so listen to him.

The "time management tips" one is a kind agglomeration of his advice on managing your time, your relationships, your reports, etc., and is a good follow-up. He has a course on having productive meetings, as well, which is well worth the time. It may make you hate meetings at your work, though XD.

Honestly his courses provided a lot of relief and validation to me, as well as hope for a future working in companies. I can't recommend them enough.

I might watch it ... later :p

The course doesn't offer anything novel - for example it has elements of Getting Things Done. But it's presented in a more accessible way that resonates with me. It also focuses on making good habits, something I already discovered in another book recommended on HN, Tiny Habits.

Thanks for the recommendation. I really appreciate it.

You rarely, if ever, need Leetcode. What you need is to understand deeply what you should be building so you don’t waste everyone’s time!

As compared to places like tesla/shopify/etc where the Steve Jobs quote rules the roost:

    It doesn't make sense to hire smart people and tell them what to do. We hire smart people so they can tell us what to do.

After a couple of years and several such reporting options someone asked, "Can't we just generate a spreadsheet and then your business analysts can do whatever reports they want from that?" and the customer responded, "You can do that?! That would be so much easier for us."

Imagine the weeks or even months of human life (both implementing but also using the less efficient reports) that could have been saved if the right solution had been implemented from the start.

That's literally time taken out of someone's life that they could have used to be with family or whatever they wanted instead of transcribing ridiculous reports.

(Of course, those reports were probably only generated to be looked at once in some recurring management meeting, only for the executives to feel good about having seen data. I don't think the reports were ever used to support any decision.

This means the entire reporting theatre was completely bullshit and the customer could have paid the business analysts to sip drinks on the beach instead with no loss of productivity. But that's just my cynical view.)

Only if the product is run by one or two people who give each other that much time off. *Much* more likely, this work not commissioned by the client, leaving space for other work to be done.

This "automation will lead to more free time" is a utter utter myth, because those with the power to pay staff will just sell their staff's time+skills to someone else/some other problem.

(There's a tiny chance the void would be filled with useful work, and that's also a good outcome in my book.)

These are unlikely to be technical issues, and more people/process issues. SPAs are popular because they optimsie for developer productivity (so arguably the opposite). Others have talked about them, but examples like focusing on the wrong problems to solve (if you're a startup making a video game, do you really need to build your own chat app? [0])

[0] https://nira.com/slack-history/

How much of that waste would you attribute to 1x programmers and how much would you attribute to 0x managers?

And I mean, who is responsible for curating those 1x engineers in the first place?

Failed projects are inevitable though, even if you do everything well. Good teams don’t look for people to blame, which results in no one sticking their neck out to advocate for stuff. Instead they look to learn from each experience and hone their processes.

What are you referring to?

As an aside, from a developers perspective, all of the work is clearly valuable, I mean they got paid 300k+. But from a true definition of value perspective, the change increment is just not valuable to the users as evidenced by the lack of use.

    Value:  Reliable fulfillment of needs

Midwestern US salary caps are more like $90k-$150k.

"There is nothing so useless as doing efficiently that which should not be done at all."

https://en.wikipedia.org/wiki/Peter_Drucker

Damned, I had to search for the author and... it's also from Peter Drucker !

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.

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 or months for what is otherwise an MVP.

Obviously you have to take security into large consideration when doing things like this - but this is what qa/sandbox environments are for.

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.

I'll say. It does not sound like you'd be very fun to work with, as a teammate or a stakeholder.

If you saw what I write you'd say I was a 20x coder, but that's just from a youngin's perspective. I've been writing code since 1988. The basic value proposition for my clients is that they know I'll die at some point, but it's way cheaper and more efficient to pay one guy they know will get it done, and take the risk they'll have to scramble for someone else in less than 10 years (at which point they'll likely have to rewrite anyway). Also, the shit I write mostly maintains itself. I'm proud to say that my software in 24/7 production has had no actual crashes in years other than the occasional forced server upgrade. If I died, it would take awhile to notice if they didn't keep asking me for new features.

You can have bigger changes as proof of concept first, but select, properly design and launch the most important one.

At one time he was scared of the problem of scheduling the fleet. Yup, if describe the problem in complicated terms, then the scheduling problem gets wildly complicated, e.g., in NP Complete, etc. -- could have a big team working months on just the first version. But he needed answers right away and, to satisfy concerns of some investors on the Board, needed the answers also to apply to the whole, planned company (eventually it grew to something much bigger than the initial plans).

I was in a meeting looking for a solution with several people, and it was all confused. Finally I just announced that I'd solve it.

I was teaching computer science at Georgetown and had 6 weeks to go to the end of the semester. So, I wanted to be done in six weeks. How'd I do that? Sure, just concentrated on what the business actually needed and threw out the rest. So, in six weeks had the software putting out nice schedules.

Our two representatives of BoD member General Dynamics and major investor evaluated the schedule and announced "It's a little tight in a few places but it's flyable.". The BoD was thrilled.

At one point Smith stated that my work "solved the most important problem" facing the company. The 10X, maybe 1000X, difference was essentially just in delivering what the business needed and dropping the rest.

"Landing the plane" as they sometimes say.

- Exponential backoff

- Jitter

- Consistent hashing

- Gossip algorithm

- Basic “Functional” aspects of a language (map, flatMap, reduce, filter, some, find)

- Putting things in a queue and using a “serverless” consumer

But some of the more day to day productivity boosters: know your development tools (including all keyboard shortcuts, including multi line editing, refactoring, grow shrink AST based selection, know all git / bash commands without googling…)

Know your programming language / framework deeply is also a supposedly simple one that just needs practice and dedication.

Basic skills like this should be at the top of the list, including fast typing, using all available keyboard shortcuts, avoiding using the mouse but nevertheless being fast and accurate with it when required.

The amount of time people spend typing and using the mouse dwarfs any other time investment and if you improve your speed with these basic skills, the productivity multiplier can be enormous.

- Once you learn how to code, learn how to automate. Design everything you can to be declarative.

- Learn how to speak and write well.

- Learn how to negotiate and influence people (read the "classics", eg "Never Split the Difference...", "How to Win Friends...", and so on.)

- Work to increase your EQ/Emotional Intelligence.

(Yes, these are all actually productivity multipliers.)

Wikipedia defines Declaration programming as "In computer science, declarative programming is a programming paradigm—a style of building the structure and elements of computer programs—that expresses the logic of a computation without describing its control flow." [1]

By decoupling a user from the low level imperative understanding of the system and focusing on the high level abstractions, if the interface is well designed, it enables the user to think at a higher level of abstraction and expands their boundaries in expressing what they want to achieve using the higher level constructs.

One of the most famous declarative interface is "React.JS" which allows to think at the level of the "components" [2], while in acuity, it's abstracting the DOM from the user as a virtual DOM [3] level and performing reconciliation[4] internally for rendering to the actual DOM. But, as an end use, they don't really have to think about these implementation details and can just work with the "components" abstraction.

Most user interfaces I have seen are abstracted in a declarative / markup language. The most famous declarative interface is SQL.

In relation, I would also recommend reading this wonderful article about leaky abstractions by Joel Spolsky to understand the flipside of abstractions, in general: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

--

1: https://en.wikipedia.org/wiki/Declarative_programming

2: https://reactjs.org/docs/components-and-props.html

3: https://reactjs.org/docs/faq-internals.html

4: https://reactjs.org/docs/reconciliation.html

Eg declare dependencies and have Make build things, specify SQL query and have the optimiser fetch the data

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 probably the single biggest fundamental multiplier, is unfortunately the g factor. General intelligence.

The only 10x differences that genuinely exist are between people who are 2x faster than average and people who are 5x worse. Not because they learned a trick, but for a complex combination of reasons, including having been handed down two or three standard deviations in general intelligence.

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

And brain plasticity, and the characteristics of high performing groups or institutions.

Changing the way your group works together is going to have a more profound difference on the outcomes than focusing on individual performance.

I intuitively don't like the idea of the 10x programmer, my core argument is actually that you should not try to become a 10x programmer, and that there's no order of magnitude productivity you can gain in a vacuum, ignoring group dynamics. So you shouldn't focus on individual performance too much! There's not much you can do about it, anyways

Managing groups of people is hard, and there's often big inefficiencies that are going to be obvious to some people (engineers love to complain about management!) but that have a true multiplier effect when fixed. Because for the time invested, you have an effect on the whole team. That's a true multiplier.

I don't know what specifically you think I should learn about the fallacy of reification, but please feel free to elaborate.

The original idea of a 10x developer was between best and worst, not best and average.

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.

The first I sort of already touched on below is that gaining a whole order of magnitude productivity, not just on a single task where a cool pattern applies but on average, is a really big effect size. If your colleagues start completing tasks that should take a month in 3 days, you would definitely notice.

The second order effect is that if we had discovered any method that reliably let an average person gain 10x productivity, it would have generated tremendous profit for companies and spread like wildfire. We haven't seen that, so we should be very suspicious when people claim a single bit of knowledge, method, or pattern is going to improve your performance by 10x.

(The other response, which is also annoying and unsatisfying, is that I'm making the boring claim that there is nothing interesting, so the burden of proof is actually not on me. If someone thinks there exists any intervention that can increase an arbitrary developer's performance by 10x, it's up to them to collect data and reject the null hypothesis)

I actually like those little patterns a lot, there are problems where you might absolutely take 10x longer because you didn't know the algorithm or the right machine learning concept.

The OP talks about becoming "significantly more productive when solving a large class of problems", and where my interpretation differs is what you mean by large class of problem.

What's large for you is really going to be relative and will vary based on your personal experience, so I can't say you're wrong. I know I speak at least for myself I when I say that in my day to day, most of what I do is not leetcode-type problems, so despite knowing many algorithms I don't think I would be 10x slower if I didn't know them.

If your interpretation of OP is that these boosts will on average give you 10x more productivity, that's the only place where I really disagree.

The 10x productivity boost I get with regexes is being able to effectively automate out a lot of text manipulation on a large scale. A couple examples. Say I get a file with a bunch of junk in it that contains some IDs that I need to use as input to other commands. I write a simple regex in a text editor, find all, delete everything else, then use other regexes (or multiline editing) to wrap those IDs with the commands I actually want to run. A more impactful example. Several years ago I was writing a new loadtest suite, when I realized that it would look A LOT like some existing load tests we had. They weren't close enough for composition or inheritance to solve the issue completely (we were already both in a few places in the codebase to help out), so I used a similar process that I laid out above to write the new loadtest suite. I barely wrote any of the code manually, I was doing most of the work from a level of abstraction above, making broad code changes with regexes. I did it all in an afternoon.

To get the 10x multiplier from regexes you've got to basically bake them into everything you do.

I'm not trying to deny your experience, so I can accept your word for it that it would take you 10x longer to complete tasks if you weren't able to do this.

At this point the core of the argument becomes more what sort of mix of tasks your daily work consists of, I think. I agree that there are patterns that solve some problems very efficiently, but in my daily life if I try to look at people who complete projects 10x faster than average, I can't point at any single method or bit of secret knowledge.

So I think the twofold response is first that the average developer is actually able to use search-and-replace and already has some vague notion that regexes are a tool they could reach for, so this is really saying that "0.1x" productivity exists in a way. And I think that's uncontroversial: if you imagine an hypothetical programmer who is still using the `ed` text-editor and hand-writing machine code to address business problems, in a world where people throw together microservices running in K8s in 100 lines of code, they're going to be a lot slower than average.

But I think the question is really about whether starting from an average (or if you want, median) dev there's any single thing that will give you a 10x productivity boost, that's not already something normal the average person knows about.

The second answer I have, and that I keep coming back to, is that if we had such a thing it would be more popular than coffee and morning meetings. It would automatically and very quickly have become something that companies rapidly adopt and that becomes the new normal (like search and replace!).

So finally the point is not that there aren't thing like regexes that slow you down a lot if you don't know them, it's more that there aren't any such things that are also well-kept secret. If the effect size is a whole order of magnitude, you won't have to scour forum threads for secret methods that turn you into a Mythical 10x Programmer, it will just quietly already be on its way to being the new 1x, and it will most likely be a gradual improvement over time.

If the 'single thing' is really a whole compendium of integrated skills, then you can't easily teach it to people the same way that you can teach them regular expressions or parser combinators.

This sort of nebulous skill that very productive people have is also especially hard to transfer. You can spend a week taking math lessons from Terrence Tao and seeing how he works, but you will still not be Terrence Tao at the end of the week, no matter how many interesting mathematical tools and methods you learn.

My point is that there is No Silver Bullet that will consistently turn your 10 hour days in 1 hour day, or if there is one I have never seen it, and evidently no company has found one. Otherwise all of their employees would follow the same method and become 10x programmers. This has not happened.

It helps to learn popular patterns and algorithms, but I don't think learning more patterns will achieve the kind of order of magnitude improvement you're looking for.

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 important parts you want to convey, even in incomplete sentences

* improve the ideas into sentences

* rearrange the paragraphs/parts/sentences into proper order (written language rarely comes out in the correct order).

* cut unnecessary talk

* iterate on the above 3-8 times, depending on the importance of the email.

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.

I've also found a lot of useful discussion around these and similar skills on LessWrong, a site dedicated to the art of recognizing and correcting errors in reason and cognition. That site is full of 10x multipliers, particularly in their "Best Of" collection[3].

[1] https://www.metaculus.com/questions/

[2] https://manifold.markets/home

[3] https://www.lesswrong.com/bestoflesswrong

Software developers are notoriously terrible at estimation and lately I've been thinking that we should look to Superforecasters[1] for inspiration about how to improve.

[1] https://en.wikipedia.org/wiki/Superforecaster

1) https://hubbardresearch.com/

2) https://www.howtomeasureanything.com/

I feels a bit like watching a chef, that has all the theoretical knowledge about food composition and such, but takes 5 minutes to chop an onion.

Usually this comes down to simple math and a bit of black boxing. It's amazing how often people miss the big picture and therefore don't see problems, losses, hidden costs or even opportunities because they're not looking at how the inputs and outputs balance.

A related skill is developing a feel for (or be able to quickly estimate) the appropriate order-of-magnitude of something.

Nothing saves time and effort like being able to scan some numbers and immediately identify a problem.

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 many different industries tells me that curiosity, logical thinking, and emotional intelligence win the day. And these are not pieces of knowledge, but personal characteristics and skills to develop. And they apply to many careers, including software engineering.

I think that more important than knowledge accumulated is your ability to conceptualize and recognize the concepts in a different context. Knowledge is just a side effect of this.

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.

There is knowledge you can acquire, and then there are skills that can allow you to acquire the right knowledge at the right time. For example, having a baseline understanding of logic and mathematical reasoning could help you to understand when a problem area might already be formalised, and to find that area and understand the work therein.

I am thinking specifically about programming in pyhton/javascript/etc. and the act of requesting web pages, reading files, or databases and parsing this to quickly gather lots of available information about something. This could be a weather data scraper, reading all files from a directory to transform them, checking repeatedly if some signup for something important is open yet, pushing receipt pdfs from emails to an archive, ...

The examples all have in common that you need to know how e.g. REST/file/database access works and you can use these to gather information quickly and automatically. Knowing how to interface with common systems can save you lots of time, therefore I would see this as a productivity multiplier.

Everything else on your list is highly domain specific and mostly useless outside of their domains.

> Calculus for solving all sorts of problems

I even like calculus, but the number of times i have used it in the tech industry is precisely zero (not counting big-oh notation which can be defined in terms of limits,because obviously that is not what is meant). There are specific domains where calculus comes in handy (i assume AI and graphics, im not really involved in either) but if you dont do that stuff its super useless.

(2) End of list.

But seriously, "10x" aside, there are some techniques that have come up surprisingly often and been surprisingly effective during my career. A lot of them are around caching, cache coherency, memoization, etc. and I see many of those have already been mentioned. How to write a simple parser is another one, likewise.

The one I haven't seen mentioned (and don't expect to) is "poisoning" of data or requests. Sometimes it's not very convenient to delete a piece of data or turn a request around with an error at the very moment when the need for that is detected - often because of locking or reentrancy issues. Just marking something as invalid, until some time when removal is more convenient, can be a very powerful technique. It can also make monitoring such events easier.

I've brought this idea into a codebase at least a dozen times, and more often than not it has gotten a "wow, that makes things so much easier" reaction. I can't take credit, of course. Like many things around caching or state machines, I got it from the hardware folks where it's a standard technique. In general, software folks can learn a lot from looking at how hardware folks have solved similar problems in an even more challenging environment, and "bring back" those solutions to their own domain.

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

Is also quite commnon to go back to some tasks to copy some code or pattern which you used, this will save you a lot of time.

If you have ADHD, us it to keep focus, you can easily manage tasks inside an org document, even go to the point of using just the console for work if too many things distract you.

Also check where you waste more time, optimisation should be focused, trying to increase your performance in some task which is not a bottleneck will cost you more time than if you just don't do anything.

Most of the time I asked myself "what is the next step?" and "what I was doing?", as well creating small pieces of code which require a of plumbing/debugging to later on fit into a bigger system. So org is the most productive thing for me.

But consider what you want to improve, before trying to improve any/everything.

Lambdas, async and Linq. Somewhat related to the previous point, but combining these three helps with writing expressive and powerful declarative and functional code.

I'm not sure if I've ever used calculus thinking for anything as a full stack developer. Never done much with calculating the rate of change of a rate of change or determining the area of an N dimensional shape. I've used many different packages and tools that are inspired by the basic ideas of calculus. But I've never had to consult a calculus text to write a given method.

In my experience, calculus and most forms of advanced mathematics are more "mental tools that might come in handy one day" than a 10x force multiplier.

Among those, I can also recommend: Relational Databases. Unix tools for text manipulation, like awk, grep, and sed. Make. Architecture patterns.

* Recursion - most complex problems seem to have a recursive solution which you can actually implement in a language like Scheme or Haskell that does not limit stack size.

* State machines.

* Monte Carlo methods.

* Unification - see SICP.

* Hand-rolled parsers instead of regular expressions for debug-ability and readability.

The biggest force multipliers what a friend described to me as a young teenager as "be an and" - don't just be a programmer, be a programmer and a lawyer

Don't just be a welder, be a welder and a baker

Don't just be an engineer, be an engineer and a writer

Etc

You may have heard Scott Adams call it a "talent stack"

Same concept

Be exposed to as many ideas as possible (both good and bad), so that you can draw metaphors and connections between them - and know when you're seeing yet another example of a bad idea, so you don't waste more time than necessary moving to a good idea

"Jack of all trades, master of some." That's been my goal for most of my life.

Too often, we cut the first part off, and it sounds horrible!

The whole quote is highly insightful

The best bit is some of the groups use languages like Haskell so the work itself, from a purely programming perspective, is interesting too!

Real innovation in art software for example could only be done by someone who is highly skilled and experienced in both artistry and software engineering and has an very open mind when it comes to design.

You get get things like Sonic Pi from people who are both musicians and developers.

It's one of the best things I've ever done for my career. I enjoy casually listing that on my resume under volunteering. :)

Understanding how your organization works: This is not about sucking up to 'important' people (atleast not when it concerns productivity). This has got to do with understanding which how the different organizational parts work, so that you can be most effective. e.g. There's tons of planning for resources/budgets that happen once in a year and if you are aware and can put in your requirements into that list, it would help.

Making connections across teams: In large and complex organizations/products, a lot of knowledge is tribal. It helps to have friendly relations and people whom you could chat with informally in teams that you depend on. Many conflicts can be resolved faster.

Automation: Coding automation, test automation, devops, Ci, cd; hopefully goes without saying these days, but it wasn't in your list and ought to be x10 at least.

Knowledge Transfer: be x10 while on holiday.

Delegation: for many its harder than learning something new.

There are tricks that make you personally more productive, but the key to overall productivity is effective team work, or all your productivity is x1.

My contribution to your list is a skill that I would really really like to have: the art of approximation. Specifically, in the style of Sanjoy Mahajan's book, Street-Fighting Mathematics: The Art of Educated Guessing and Opportunistic Problem Solving.

http://web.mit.edu/sanjoy/www/

After reading that book I have been slowly trying to accumulate approximation methods and metrics in whatever I read, in order to estimate and validate quickly.

I started each of these around 9 years ago now, and can't imagine going back. The greatest impact isn't even literally on "getting things done", but on the time when I'm not working. I don't have to hold things in my brain. When I'm not working, I can forget about all that stuff and actually rest, or focus on other things. And when it is time to work, it's all right there. (And by work, I don't just mean the 9-5, but essentially anything that needs to get done, vs recreation. Although I do also use it to remember things I'd like to do someday for fun—everything from books I'd like to read and movies I'd like to watch to things like taking golf lessons, or buying a new helmet.)

We also of course use project tracking software for work, but I find it extremely beneficial to have my own personal system as well. Everything goes in there, from large, ongoing projects to 'remember to switch the laundry over'.

I wrote a blog post a few years back describing what works for me[1]. For the most part it still applies. I use Evernote, but would probably look at something like Joplin if I were setting it up today. (And will probably migrate, someday.) About the only other significant difference is I do a lot less sending emails to evernote now, since the gmail 'snooze' feature is pretty convenient. I'll still do it in cases where I want to add some notes though.

One thing to be aware of is if you're used to a less structured system (a written agenda, sticky notes, marked-unread emails, etc.) this will take significant time to adapt to. It was my primary focus for the better part of a month just to get things set up in a way that felt good to me, and then another couple of months before it stopped feeling like extra work to make myself use the system. But in the years since then, I can't imagine having lived without it. (And I built a fairly successful company and had kids over that period.)

[1] https://www.tempestblog.com/2017/08/16/how-i-stay-organized-...

The spacing effect demonstrates that learning is more effective when study sessions are spaced out. This effect shows that more information is encoded into long-term memory by spaced study sessions, also known as spaced repetition or spaced presentation, than by massed presentation ("cramming").

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

Spaced Repetition Software (like Anki) allows you to learn more things in less time – and remember them better, too. It's especially useful if you want to learn a large amount of things over a longer timeframe.

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)

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.

Do things like teaching and mentoring, build consensus around decisions, involve people in your thought process early, actively seek out feedback on your ideas, alleviate people's concerns, help out where you can, be empathetic, work freely with anyone in the organisation as needed, gather data to support your opinions.

You'll soon be at a hub in the informal "attention network" that truly decides who calls the shots. Handle it with care and use it for good.

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.

Wasn't this Alexander the Great's approach: divide and conquer?

Every problem gets solvable if you break it into enough pieces

Someone needs to just sit down and break P vs NP into enough pieces.

And close enough, as the adage goes, is almost always "close enough"

I cannot for the life of me figure out what he means by this

No clue if that's it though. Wonder if this "Pat" explained it to OP and OP is just keeping us hanging....

This is go against the grain, but ignoring these kinds of generalized list. These things are very non-contextual and can be bad advice without the context they were meant for.

It's better to:

- Find people who are experts at things

- Find ways to talk to them on an informal level

- Learn how and why they are suggesting what they're suggesting

- Write and communicate what you learned/keeping a journal

Long term and deep learning will take you places. Quick trivia is a waste of time.

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 for best practices, and what I call "decustomization", the art of removing any unusual technology from actual production systems.

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.

Any one of these things might not be a big time drain. But the general mindset of DIYing and building "just right" systems all together takes a lot of time.

Learning how to work "inside the box" with standard issue tools, and how to guess ahead of time how much maintenance work anything new will require, and to think in terms of how things fit ecosystems, rather than evaluating things separately, has probably been the most important thing I've learned in tech.

Every time I've done something "unusual" I've been convinced that the core design was better than what's out there. And almost every time, I've regretted it, because a great idea doesn't always make up for a lack of polish and compatibility.

The challenge of course is actually finding anything else you want to be doing with the saved time.

CVEs are almost always patching in hours to days on mainstream software, it's rare to just leave doors open, the difference seems to just be in how much people tolerate things that might possibly have an unknown risk, just because they are big or use dependencies, or because they allow a user to do something that might be a bad idea in some contexts(Like have an unencrypted hard drive).

If you need extreme security, or some other specialist requirement, you're total right, mainstream ecosystems can be unsuitable.

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.

Innovation beyond the random toys level is really hard. At best most things can become a proof of concept that inspires some corporate dev. Unless you really enjoy that kind of random garage project, it seems reasonable to just leave it to the people who do.

There's a lot to learn in the world of boring unoriginal software. You learn how to take a task and do it with high level building blocks, and the minimum possible custom code. You're essentially designing a "Plugin" for a system made of the entire current software ecosystem, treating dozens of unrelated apps in a workflow as if they were a suite, taking into account the fact that you know people will want to look at data in Excel or control your thing with a MIDI keyboard.

I've done lots of random side projects, but I'm not sure I learned all that much, other than to really appreciate the value of the off the shelf thing I later replaced them with.

It's hard to objectively measure that kind of general learning, so maybe I am better off for them, but I also think I picked up some bad NIH type habits that I later had to unlearn, and caused some of my biggest tech related regrets.

Then again, if I was in a field where we actually did real "Paradigm shift" type stuff, I'd probably feel differently. But even then I'd imagine learning Haskell and linear algebra might be a better use of time, rather than implementing a window manager.

All architects needs architecture knowledge; you can't just say "knowing architecture makes architects 10x more productive".

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.

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.

If I'm wrong, show me I'm wrong and post a substantive comment. Snarky comments like that are not inline with HN guidelines.

The insights from these topics: https://en.wikipedia.org/wiki/List_of_dynamical_systems_and_...

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 logic, not 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

This is calculus, not logic, not philosophy.

Again, any evidence this is not logic or philosophy? Simply saying it isn't, is not a valid argument. Just because you assert a concept exists calculus, does not mean a similar one doesn't exist in another domain/context. Any response to the majority of my comment, especially around context of use? Or are you just trolling by repeating the same line in multiple comments with no substantive support for your claims? Honest question.

To your point on system dynamics, queuing theory pairs really well with calculus on that as well. Being able to somewhat predict how a system is going to behave under load based on measurements and an understanding of how the queues work is super super valuable for decision making.

To understand basic financial concepts, like the present value of an annuity, or implied volatility, requires calculus.

In boring software, simple questions like, how often will a workload miss cache, and what optimizes the cost there, can be modeled... if you use calculus.

Also, in the past, I've casually been thrown into a couple of jobs where calculus was directly applicable to the work I was doing.

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?

In another instance, I got a summer job working at a company that made an optics-related product, and that involved a bunch of numerical integration, Fourier transforms, some optimization problems in stuff like calibrating equipment. So naturally, there was calculus.

Fun-related, recently, I noticed that a long-term call option I was holding seemed surprisingly expensive compared to just buying the stock on margin, given current and expected future interest rates, and comparing against the option's theta and delta values. Then I realized I was assuming the stock only goes up, ignoring short-term vs. long term taxes, etc. To get a general sense of how an alternative strategy of just buying the stock and adjusting position sizes at a few price points might work out, in a back-of-the-envelope calculation, I considered this problem: on average, how many times will a Wiener process W(t) completely cross the small interval [a,a+h] in the time interval 0<t<T (for some T)? What's its asymptotic behavior with respect to h, T, and a? (This problem of hedging options with stock, surely, is studied much more in depth, but I wanted to understand the general picture.)

Edit: I'll add, that's also taking for granted a lot of stuff with infinite series in comp sci that is also part of calculus. Like, if you want to pick a random number from 1 to 5, you know you can pick from 1-8 and retry if it's too large, and with calculus you know it will average a finite number of tries (8/5, specifically) because the infinite series passes the ratio test.

What I realized a couple of days ago is that even earlier in the tournament, you don't want to optimize expected value -- you always want to give some of that for higher variance. Why? Because in the variance/EV trade-off curve, the slope of the curve is zero at the maximum value, which means to add h units of variance, you give up o(h), realistically, O(h^2), expected value. So there is some value of h where the trade-off is worth it.

(Concrete example: Golf tournaments could be modeled as a coin-flipping contest, where you get +1 point for flipping heads, -1 point for flipping tails, with 72 coin tosses. Suppose you could pay a 0.01 point cost to double the point value, i.e. you get +1.99 or -2.01 as a result of the coin toss. Then you should, because doing so on the first coin tosses will increase your chance of winning.)