For example,
* Regular expressions for simple text processing.
* Parser combinators for parsing.
* Parser generators (esp. packrat variety) for parsing.
* The concept of fuzzing and property testing for testing code.
* Calculus for solving all sorts of problems.
* MCMC for solving a huge class of probability problems.
* Search algorithms for solving a variety of problems (e.g. all NP-hard problems, sudoku, HTNs, scheduling, planning).
* Gradient descent for solving a variety of optimization problems.
* Vector Space embedding as a conceptual tool for a variety of complex AI problems.
* Effect composition (Haskell's IO or Scala's ZIO) as an incredibly powerful paradigm for concurrency and parallelism.
What are some examples of 10x multipliers that come to your mind? Fundamental ideas without which you would be drastically less productive.
- 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.
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.
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.
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.
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...)
- 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.
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.
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!
How much of that waste would you attribute to 1x programmers and how much would you attribute to 0x managers?
What are you referring to?
"There is nothing so useless as doing efficiently that which should not be done at all."
https://en.wikipedia.org/wiki/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.
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.