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.
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.
- 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.
* 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.
- 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.
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.
- 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.
- 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.)
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.
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.
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/
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.
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
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.
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.
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.
What the question might be after is how to develop insight. As others have mentioned, transferring patterns across domains, using the right tool (i.e., the right mental model), etc. And be patient with difficulty: interesting problems are usually hard.
To see these aspects in an integrated context, read Plato and Aristotle sympathetically. The divided line and syllogism underlie law, medicine, mathematics, etc. Focus on how the text goes from confusion via contention/elenchus to clarity by understanding how others think. It's a good model for the social and personal aspects of "knowing thyself" being the virtue of virtues.
So, yeah, if you really want to change your life and those around you, work up through a 10-day silent meditation retreat. After all, if everyone is always living in their head, so you might as well learn how to see what your head is doing.
context switches are expensive
… and yes, sometimes so expensive that not knowing this might, indeed, have a 10x penalty.
I sometimes forget how I take regexes for granted, and how some people don't know them.
I would replace the combinator/generator stuff with "how to cleanly make a hand-written parser." Developers frequently stumble through that quite badly.
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.
Yes, distributed tracing tools do a much better job of this, but it's not always a given that a service will be instrumented. The generic tools (almost) always work.
* Linear Algebra, a matrix can represent lots of different things and lots of great tools around LA.
* Tree searches, 60% of all traditional AI is some sort of tree manipulation ( I made that number up ).
my only 10x personal practice is: take notes on everything. build a knowledge base. it doesn't have to be presentable, they can be scratch notes, dumps of important links and details. over time this accumulates, and when a given topic comes up again you'll be prepared to seamlessly pick up where you left off.
That usually requires you to realize that productivity is a trap. That doing more is a fundamentally flawed idea because you will always have more to do. Rather, you should aim to do more with less, which is better idealized as being effective or efficient.
The best ways to 10x that? Four old ideas:
1. Have the courage to try something new. 2. Find the right amount of doing it. 3. Research new techniques or tricks. 4. Use your judgement whether you can apply it to your current ability. 5. Repeat
For example, if you are working on implementing a regex expression for your job, spend the additional time and effort (if you can spare it) to learn a little more about regular expressions and/or the tools associated with them. These small incremental improvements to your knowledge base over time will have a significant impact on your overall trajectory.
- Vim bindings and macros
- AWK
…and, if you'd like to generalize that, I'd say "throwaway programming" is generally a good skill to have. Many programmers don't get that not every problem should be solved in an elegant, robust and maintainable way. The important part is that you recognize when that isn't the case and that you are able to improvise in these situations.
There are, of course, also situations when you absolutely don't want to go the quick & dirty route, and recognizing those is just as important.
(2) Integer linear programming set covering. A super nice way to get likely very close to optimal solutions to some really nasty real world problems in combinatorial optimization.
(3) My favorite text editor, Kedit. It is a PC version of the IBM text editor XEDIT, written by an IBM guy in France, apparently on his own time. It used Rexx as a macro language, and Kedit uses Kexx, its version of Rexx, as its macro language. XEDIT and Kedit are elegantly designed; the macro languages are also elegant. Kedit is my most important tool.
(3) Hierarchical file systems, e.g., Microsoft's NTFS (new technology file system). I just find the hierarchy in the file system as a natural a taxonomic hierarchy for organizing information.
(4) Yes, once I used Monte Carlo simulation of a continuous time, discrete state space Markov process to estimate the surviveability of the US SSBN fleet under a special scenario of global nuclear war limited to sea. So, it was potentially an enormously complicated calculation but due to the simplification of the Markov assumption, how the continuous time was handled with a Poisson process, and the Monte Carlo to do the numerical part, I got the whole project done in just two weeks.
Do you use it for text transformation? How do you use it exactly? Do you use it as code itself or as a tool to help you explore/write code?
I am a huge fan of Macros, I 100% understand their role in text transformation, but what problem does regex solve? I spend so much time trying to remember the correct syntax, it only ever works for me when solving a specific code problem, but Ive never used it in one-off workflow problems.
Curious if I have missed some huge place where it is helpful.
A widespread example of this is linear regression analysis. Mathematically, it only works because we make assumptions about the data (and even these can be relaxed) & limiting the scope of the problems it can solve.
This also applies to delivering projects. A fully engineered & robust project could possibly require a great deal of human, physical resources and time. But if we start iterating over a list of problems your system solves (sorted by decreasing value), the project suddenly costs only a fraction of what it would otherwise.
This doesn't come for free though: your MUST understand the limitations & assumptions of your systems, otherwise you or someone will pay dearly. Look at Zillow & failure to understand its forecasting system. Look at so many other startups applying ML where it has no place.
Zillow's failure is the best case (though catastrophic): the principal paid the cost. But take something like Google, applying a fully automated system to make decisions about banning accounts. These are real world decisions that have a huge effect on people & businesses. In this case, Google saves money on providing human support & offsets the costs to third parties who often can't afford it.
* The ability to challenge a proposal and figure out you don't need "an xxx with yyy but just a zzz should be enough"
F.e. merging seperate repos to monorepo, simplifying development & CI/CD enormously for a tiny team.
* The ability to understand which solution matches best with your whole context (environment, capabilities, skillset, risk, ...)
Don't go for integrating a rules engine in an MVP with a tight deadline, but just setup a monthly alignment between Product owner & back-end dev.
You'll be surprised at how many "great developers" never move anywhere in terms of productivity because they lack fundamental communication skills.
- Focus like a maniac on tasks that generate value. Busyness has nothing to do with productivity.
- Agressively reduce all coordination overhead (emails, meetings, etc)
* Fully understanding how SQL prepares queries; optimization strategies
* Embracing garbage collection in JITted runtimes, mainly JS for now
* Being able to diagnose and replace a squeaky belt in your car
* Know what a cat is saying when it meows at you and indicates something in the vicinity of its food / water / the door / a dead mouse.
These have all saved me a ton of time.
On the flip side, if you are not absolutely sure (and you generally should not be!) then ask as many people as feasible to criticise your idea so you can work out the best possible version of it before you execute.
A more prosaic answer, in terms of tools, would be to know your editor well (assuming programming), since you will spend a lot of time in it. Even if typing speed is not the limiter, it can help focus and keep bursts of input uninterrupted.
I could list lots of design patterns and mini patterns, like having a mutable copy of something that you copy under lock to an atomic copy, and lots of random software tools, but someone would probably say they never needed any of them.
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.
W. Edwards Deming said over and over again that the system in which an employee works puts a ceiling on how much output they can produce.
But you should take it a step further than just trying to maximize your output, and instead understand how your work creates value for your boss, your company, for society. Productivity is not a measure of how much you can output, it's a measure of how much value you can create, or how much closer you can come to achieving your goals.
If you can come in, spend five minutes and change the label on one button and increase sales 200%, you've been much more effective than if you spend years optimizing the performance of a component that isn't impacting overall performance of the system.
* Gradient descent for solving a variety of optimization problems. * Vector Space embedding as a conceptual tool for a variety of complex AI problems.
considered fundamental knowledge?
Personally, I think of fundamental knowledge as something that is covered in a school/college curriculum?
What am I missing?
- shell scripting + Linux commands. Not having friction when writing a shell script is amazing, it's extremely productive.
- awk. I rarely use it (I use cut, sed, or perl one liners in priority), but to make some non trivial changes it's great to be able to keep a state between parsed lines.
- git. I've never had to delete/re-clone a repository since I've read the Git Book.
- SQL querying. Same thing, I have no friction when I need to write group by, CTEs, or other intermediate stuff.
If you do frontend stuff:
- CSS. It's a quirky language so you need to learn how it works properly, not hacking stuff here and there. I've never had any issues doing anything in CSS since I learned it for real.
The nicer the workflow, the more vanilla the tooling, the more self-evident the naming conventions and related patterns, and the more pleasant the workflow, the more time you avoid wasting. And while it may not sound like much, over time that shit adds up.
We’re talking, cumulatively, about DECADES worth of recovered productivity here, on a small team, over the course of maybe a year or two, tops.
It’s the little things, y’all.
They allow you to quickly pinpoint problems, and avoid exploring places you shouldn't explore ( which is very handy when designing a new system) .
1.) Task prioritization. 'nuff said.
2.) Delegating non-priorities, or things that I can but also can be done well by a junior member. Just because I can do it, doesn't mean I should be doing it. This is a hard one for me.
3.) Really understanding the underlying tech before writing code.
I literally just had someone ask for SCIM help when they're dealing with authorization issues. We decouple authentication and authorization, and SCIM only updates user and group information. SCIM, for us, doesn't have anything to do with authorization. I don't know how long this person has been staring at SCIM docs trying to solve their issue when SCIM won't help here.
1. Knowing keyboard shortcuts. The most powerful one is to flip between screens on my computer (Alt+Tab for Windows, CMD+Tab for Mac).
2. Having a pipeline for AutoML such as Tpot in Python (http://epistasislab.github.io/tpot/) where it will automatically go through a bunch of ML algorithms and tell you which one did the best on your data.
That's a big topic. But one of the key things I learned is when to stop talking. Get to the point, deliver it and then stop. Enjoy the awkward silence and let others fill the space.
I have met so many countless people who couldn't stop or know when to stop but just kept waffling, diminishing the effect that they could have otherwise.
- Logbook of your work, plans, thoughts; use whatever tool that you know will be around the longest. Be it git, apple notes, or any other. Make sure it has a search, and keeps track of dates. - Somewhat related; an infinite terminal history. You may have the best one liners, but you don't want to keep rewriting them. Also, know your unix tools. - Computer Science; as covered in GRE computer science; those are just fundamental, if you try to find your way around learning them, you'll just waste time and effort; just go through the learning. This is assuming you are a software engineer. - Competent peers and good ways to review work, and collaborate in general. Code reviews are great, but they are just a small fraction of what you can achieve with a team. Retros, design reviews, pair coding, planning for common objectives are all productivity multipliers. - A focus on objectives; this is a basic one, but not an easy one. You'll be making many decisions when you code, design, review, discuss, communicate, argue, negotiate, etc. if you don't keep track of the various objectives, you'll waste time and effort either immediately or in the long run. In a time crunch, stop and think about your objectives, and whether you can work towards them more effectively. - Basic drawing and handwriting; you need to get comfortable with using a pen or a marker, and the ways of putting your ideas on a piece of paper or whiteboard. I've witnessed many impenetrable computer science theory or just basic design problems turn to dust when beaten down on a whiteboard by clear minds. - Regular breaks, walks and occasional coffee. Being tied up on a (hard) problem for many hours without breaks is usually a waste of time, also unhealthy for your body. - Knowing your data; if you are trying to solve a problem with ML and you don't know what your data looks like, you are wasting your time. Understand your data first. This requires experience, looking is not seeing or understanding. Also, know your objectives, see above. - Know your sources of wisdom; these could be people, books, or search tools. You are unlikely to be the first to run into the same problem. If you are looking for a novel problem or solution, it is mandatory to check what has been done before. If you are dealing with a tough problem, you might get insights from others. If you are looking for better documentation, maybe it's out there somewhere. Don't forget to check before you get lost.
Some knowledge of a command line, whether it's bash on Linux or even Windows CMD, can aid productivity.
* Metrics on a dashboard (Grafana+Prometheus). See whats going on in a program. How many times is there a cache hit or miss. What are the most frequent occurring errors.
I generally use integer linear programming for most discrete optimization. It gets me good results, often optimal ones, if it gives me a result at all, but boy is it a rabbit hole of lost productivity.
(of course, from time to time I debug and fall on one of those FIXME's :--))
In other words, use the keyboard as much as possible. Simple but its 2x'ed by productivity
if you can create meetings that are engaging, informational, and have actual actionable outcomes at the end that people are accountable for, you'll have a much easier time meeting people and getting things done.
a technical 10x that I've found is knowing infrastructure (if you're a software dev) or knowing how to write software (if you're an infrastructure person).
* Quantum theory
* String theory
* Lenin's works except The State and Revolution
* Muqaddimah of Ibn Khaldun (by Ibn Khaldun)
* Vienna Circle's works especially Language, Truth, and Logic (many skip this one)
Controversial opinion!
I think most people these days generally think parser generators are a bad idea.
- “10x developers” require 10x pay - this is wanky as shit
I'd add formal logic and argumentation and logical fallacies.
Edit for typo
dont let perfect be the enemy of the better
iterate
many many others
automate > manual
many many others