| [HN Gopher] Ask HN: What bits of fundamental knowledge are produ...
___________________________________________________________________
Ask HN: What bits of fundamental knowledge are productivity
multipliers?
I recently realized that certain kinds of knowledge allow one to be
significantly more productive when solving a large class of
problems. 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.
Author : stardustpie
Score : 304 points
Date : 2022-03-30 11:40 UTC (11 hours ago)
| VirusNewbie wrote:
| Monads and monadic comprehension and recognizing when to use
| such. The fact that so many tricky things are simplified when
| boiled down to map/flatmap/join/ (along with laws) is so fucking
| powerful it's astounding. That you can model state transitions,
| concurrent computations, callbacks, dealing with 'happy path'
| short circuiting all with the same 'pattern' (and syntactic
| sugar!) seems like a cheat code.
| FL33TW00D wrote:
| 1. Deep deep knowledge of your text editor. I am biased towards
| Vim, but many others can work if you know them inside and out.
|
| 2. Learning multiple programming paradigms, bare minimum 1
| declarative and 1 imperative language. Build something
| substantial.
|
| 3. Understanding yourself, what times you work best, diet,
| fitness etc. I find where and the setting of where I am working
| is extremely important.
|
| 4. Broad (but not necessarily deep) knowledge of DS&A. Knowing a
| thing exists is enough to search it.
|
| 5. Broad (and preferably deep) knowledge of computers on a
| fundamental level. An approximate understanding of what the
| statements you are typing into the machine are "translated" to at
| each stage.
| dijit wrote:
| There are few productivity boosters greater than _spending time
| learning the tools you use_ in and out. This goes for hotkeys in
| software all the way to quirks about a language.
| warrenm wrote:
| It works in the digital world because it comes from the
| physical: I owned a powertool that sat unused for 5+ years
| because I _thought_ I didn 't have an application for it
|
| Was shown how to use it effectively, and improved my efficiency
| by more than double on the task it's good for
| genewitch wrote:
| Out of curiosity, was it a variable speed oscillating tool?
| warrenm wrote:
| No, it was my impact drill
|
| I was under the fallacious understanding you only needed an
| impact drill if you were trying to remove really stuck-on
| nuts/bolts (like rusted lug nuts)
|
| As it turns out ... they're _AMAZING_ for driving deck and
| roofing screws :)
| genewitch wrote:
| Oh, cool, 100% agree, too! I switched to using star or
| square drive screws for putting the 1x4s on porches and
| stuff, that coupled with even a cheap impact driver means
| no more snapped screw heads, and i usually don't have to
| use the countersink bit i have.
|
| I wonder if your logic was because of the larger
| pneumatic "tire gun" style things. Anyhow, sorry for
| going off topic!
| hknapp wrote:
| Not only that, but spend time learning your tools as you use
| them. If you're like me, reading about a tool for four hours
| then trying to recall that information while using it is a
| wasted effort. You have to be continuously learning in
| increments over weeks, months, and maybe even years. Never stop
| learning.
| lanstin wrote:
| Also standing behind people and watching them do stuff is
| good at showing you things ypu didn't know you didn't know.
| qorrect wrote:
| It's painful at first, learning something while doing it,
| because it breaks your flow, it's like constantly being
| interrupted.
|
| But it's so worth it in the end, +1 for learning while doing.
| pjerem wrote:
| This. Know your tools. Try other tools even if you finally
| decide to keep what you are used to. But you should master any
| software (including your OS), any programming language, any
| keystroke of actions that you use everyday.
|
| By mastering I mean, not knowing everything, but knowing more
| than you knew yesterday.
|
| A pretty underrated hint about learning keystrokes : _print
| Cheat Sheets_ (they are available in pdf for most tools) and
| keep them somewhere on your desk. You will discover tons of
| cools tricks while waiting for things.
| somethoughts wrote:
| Could be useful
|
| MIT - The Missing Semester of Your CS Education
|
| [Most] Classes teach you all about advanced topics within CS,
| from operating systems to machine learning, but there's one
| critical subject that's rarely covered, and is instead left to
| students to figure out on their own: proficiency with their
| tools. We'll teach you how to master the command-line, use a
| powerful text editor, use fancy features of version control
| systems, and much more!
|
| https://missing.csail.mit.edu
|
| Topics include:
|
| Shell Tools and Scripting, Editors (Vim), Data Wrangling,
| Command-line Environment, Version Control (Git), Debugging and
| Profiling, Metaprogramming, Security and Cryptography
| eatonphil wrote:
| I don't think parser combinators or parser generators should be
| included in a list of productivity multipliers, personally.
| copperx wrote:
| Are you implying that they are more work in the end than
| manually coding a parser? Has that been your experience?
| eatonphil wrote:
| Yes in my experience it's absolutely easiest just to write
| your own from scratch.
| vivegi wrote:
| Relational algebra, set operations and SQL. I learnt the power of
| parallel queries on massive datasets when directly manipulated
| with relational algebra, set ops and SQL. For eg: Create Table XX
| as Select a, b, c from YY, ZZ where ...
|
| Lambdas, async and Linq. Somewhat related to the previous point,
| but combining these three helps with writing expressive and
| powerful declarative and functional code.
| dmos62 wrote:
| - Writing as form of (or tool for) thinking; Leslie Lamport said
| (maybe quoting someone) that if you're thinking, but not writing,
| you only think that you're thinking;
|
| - High tolerance for feeling ignorant, confused, silly,
| inadequate, a novice: none of these states should phase you: you
| should not have a comfort zone: let your mind feel at ease in not
| understanding something: go to the eye of the storm and weather
| it: you'll come out being more capable;
|
| - Formal specification (maybe TLA+) when doing something
| unintuitive, like non-trivial concurrency; or, simpler put, think
| before you do;
|
| - Functional programming, immutability, state machines, reactive
| programming: whatever you can do to make your systems more
| declarative and their state easier to reason about;
|
| - I'm a geek for tools, and I know that not everyone is like me,
| but for me choosing the right stack for the job is a big deal,
| and when saying stack, I mean every tool I'll be using, from the
| programming languages, to deployment tech, to testing setup; a
| good tool can effortlessly solve a host of problems.
| kalev wrote:
| > 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;
|
| I'd love to be more at ease on uncomfortable situations. Any
| tips?
| dmos62 wrote:
| This isn't really an answer, but I'd say that everyone's
| different. What works for you might be wildly different than
| what works for me.
|
| 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.
| abirch wrote:
| Read Richard Feynman. The man was a genius and would ask as
| many simple questions early on. If he can check his ego, all
| of us should be able.
| Frummy wrote:
| For me, it's closing my eyes, taking a few deep breaths, and
| then continuing. It's okay to be nervous and feel ones heart
| pounding and just notice all those physiological reactions,
| but keep going despite that. My old tendency was to switch
| task to something more comfortable, but just take a silent
| minute without switching tasks and then keep going.
| ketzo wrote:
| I will give you a fairly specific answer that comes from my
| history of going to therapy for anxiety and depression.
|
| 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.
| aj7 wrote:
| During stressful times, I'd have agoraphobic attacks in the
| car. They were pretty terrifying. I'd open all the car
| windows and blast the radio. But you know what worked much
| better? Solving math problems in my head.
| ketzo wrote:
| I like this one too!
|
| 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.
| virgil_disgr4ce wrote:
| This is great, and it made me realize I had started doing
| something similar recently: when I become anxious about
| something, say money, I ask myself: are my kids healthy and
| safe? The answer, so far, has always been yes, and that
| calms me down immediately.
| ketzo wrote:
| That's awesome! Glad to help you put a concrete framing
| to it. The more intentional you make it, the more
| effective it is, I think.
|
| There's a reason people keep pictures of their family at
| their desks; it's not _just_ for decoration :D
| vorpalhex wrote:
| I'm going to go a different advice route then other
| commenters here.
|
| 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.
| raffraffraff wrote:
| There comes a point in your life where this may not still
| be true. At 70 I doubt I'll be pushing "to failure" in
| training sessions. In fact, I'll probably consciously
| reduce the intensity of my training sessions and use them
| to maintain muscle mass for as long as possible into
| old(er) age.
|
| 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.
| bbertelsen wrote:
| Learn a new language! Be fearless when speaking it even when
| you know you're wrong. The results are humbling often
| hilarious and get you accustomed to frequent failure. This is
| also a good approach for people who are socially awkward or
| want practice just speaking to people. There are literally
| millions of people interested in doing "language exchange"
| sessions, where you do x minutes in your native tongue in
| exchange for x minutes in their native tongue. Not only will
| you learn a new language, but asking questions about idiom
| you do not understand is amazing practice for "anything" you
| don't understand.
| pmayrgundter wrote:
| For me it's practicing art.
|
| 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.
| imranq wrote:
| Use Vimium: https://vimium.github.io/
|
| In other words, use the keyboard as much as possible. Simple but
| its 2x'ed by productivity
| eranation wrote:
| Some less mathematical / core CS and more cloud / system
| engineering:
|
| - 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.
| JacobThreeThree wrote:
| >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...)
|
| 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.
| eternityforest wrote:
| A lot of those are pretty domain specific. Calculus is 10x only
| because it lets you get into fields where calculus is 10x. I have
| no idea what a general everyday coder would do with it.
|
| I could list 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.
| rockemsockem wrote:
| This is an interesting comment. I found myself alternating
| between your sentences with strong agreement and strong
| disagreement. Sometimes even alternating statements within
| sentences.
|
| Laziness? +1000 Best practices? -1000
|
| Work inside the box? -1000 Think ahead about maintenance and
| things fitting together? +1000
|
| Unusual choices? -1000 Polish/compatibility over great ideas?
| +1000
|
| I think the common thread between my "-1000s" might be driven
| by a lot of experiences I've had where the boxes, default
| choices, and "best practices" (I cannot express how much I hate
| this term) have been dressing put around awful ideas. Maybe if
| I'd been in more scenarios where "best practices" really were
| good choices I'd agree with you 100%, but I've just seen too
| many cases where bad decisions are the default :/. I assume
| you've seen otherwise?
| thrower123 wrote:
| How to use grep effectively
| softwarebeware wrote:
| And Unix tools in general
| PennRobotics wrote:
| And vim in particular: _free, vast availability, no GUI
| needed, regex, macros, plugins, folds, block editing, syntax
| highlighting, drop in your vimrc and go, runs shell commands,
| etc._
| thrower123 wrote:
| If I ever find myself in vim, I just powercycle the
| machine.
|
| It's easier.
| hypefi wrote:
| this
| adampk wrote:
| Not technical but the self-knowledge of how to put yourself in a
| productive state. Knowing how to sleep well, eat well, exercise
| well to allow yourself to perform at a sustained high-level.
|
| Someone may be more technically competent at a problem-space (at
| the start), but if you are able to work diligently at the problem
| over a sustained period, you will have 10x better results than
| those who crash/burnout/lose interest/try to sprint to the
| finish.
| Ancapistani wrote:
| As someone who struggles with ADHD and depression, this isn't
| always _possible_.
|
| At 38 years old, what I have discovered are ways to make myself
| valuable to my employer even when I'm not at my peak. The move
| to a more "architectural" role has been a Godsend for me. It
| means that I'm a let to serve to some degree in an advisory
| capacity for others. When I'm not able to enter "flow" with my
| primary project, I can 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.
| giraffe_lady wrote:
| ha, lucky. I have a similar constellation of problems and
| never found an employer willing to tolerate it long term. I
| can put large volumes of high quality work for 3-5 weeks at a
| time followed by 2-4 weeks of a low output slump. I usually
| get fired on the fourth or fifth cycle, freelance for a
| while, then try again.
|
| Always hoping to find somewhere willing to accept the
| inconsistency in output but haven't found it yet. Anyways
| it's cool to hear someone in one of these threads acknowledge
| this reality for a lot of people. The general HN consensus
| seems to be that anyone who isn't a top 10% technical star
| _and_ an incredible productivity machine doesn 't deserve to
| touch code.
| goodoldboys wrote:
| What type of work do you do? I run a small consulting
| company that builds web apps for biotech, and we're always
| looking for help. I suffer from similar problems so I'm
| sympathetic to the situation you described.
| pnutjam wrote:
| Larger enterprises should tolerate this better.
| diatone wrote:
| Came here to say this. The library of Alexandria fell into
| disrepair. Try not to let the same thing happen to you, or all
| that knowledge will be for nothing.
| brianhorakh wrote:
| The mental model for this state is known as "flow" or atheletes
| sometimes call it "the zone"
| catchclose8919 wrote:
| ...lots (most?) of the actual work that needs to be do is
| "grinding" or "working against tons of hard/impossibly to
| remove friction": you'll _never_ achieve any kind of flow
| doing this kind of work!
|
| 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...)
| brianhorakh wrote:
| You can gamify anything. Gamify makes the toil of grinding
| fun.
|
| 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)
| softwarebeware wrote:
| To-do lists.
| warrenm wrote:
| ..insomuch as they can be converted to "now-done lists"
| dandigangi wrote:
| Definitely agree that getting good at Regex over the years and
| more recently AWK/SED has helped me significantly.
| w10-1 wrote:
| As others have said, "productivity multipliers" can be "waste
| generators", so meet the (business?/user?) need, etc.
|
| 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.
| kodeninja wrote:
| Developing a good memory.
| shiv86 wrote:
| Learning small amounts everyday. Accumulation of knowledge
| provides compounding return E.g. reading books, curated twitter,
| https://getsuperpower.com/, https://www.blinkist.com/
| guillem_lefait wrote:
| Learning and not forgetting. Or learning more than you're
| forgetting.
| lanstin wrote:
| There is nothing more useful than learning what to forget. At
| least I manage myself for rapidly reshaping my mind to fit
| the tasks of the year. Despite my postings here, the gcc
| options for gcc 2.72 don't help much compared to my curre t
| muscle memory for terraform.
| warrenm wrote:
| the problem I have with services like Blinkist (or any book
| summarizing offering) is that you get what the _summarizers_
| think is the "point(s)" of the material
|
| You can read, for example, a Christian Apologetics work and
| come away with tools for public speaking and rhetoric that
| would be completely missed if you only got the "summary" of the
| apologetic argument in the religious context
| Bostonian wrote:
| The general concept of regression -- it can be linear or
| nonlinear and have one or more continuous or discrete outputs.
| It's good to understand that a multi-layer neural network and a
| simple linear regression are similar in some ways. Related to
| regression and gradient descent (which you mentioned) is maximum
| likelihood estimation.
|
| Some knowledge of a command line, whether it's bash on Linux or
| even Windows CMD, can aid productivity.
| graycat wrote:
| (1) Linear algebra. E.g., part of it is part of the crucial, core
| math of my startup. Also as we see today, Jack J Dongarra just
| won a Turing Award, and one of his best accomplishments is what
| he did for LINPACK, numerical linear algebra.
|
| (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.
| rmellow wrote:
| Making assumptions & cutting down on scope are immensely powerful
| tools. There is a tendency among engineers to create systems that
| are universal and work in all sorts of environments, when in
| fact, this is not what is absolutely immediately needed, or is
| closer to a "nice to have".
|
| A widespread example of this is linear regression analysis.
| Mathematically, it only works because we make assumptions about
| the data (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.
| amboo7 wrote:
| If only such assumptions were ever written down.
| don-code wrote:
| Basic debugging knowledge is helpful, but I've found the ability
| to think about distributed, networked systems all the way down at
| the system level to be extremely helpful. We all encounter
| systems that are ill-documented, or complete black boxes, but
| peering at them with tools like `strace` / `jstack` (when a
| service is doing something itself with data) and `tcpdump` (when
| a service is asking another service to do something) opens up all
| sorts of possibilities.
|
| 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.
| warrenm wrote:
| It always amazes me the number of people - _especially_
| programmers /developers - who absolutely can NOT read a
| stacktrace of any kind
| ozim wrote:
| Especially devs who have years of experience are surprising
| me when it turns out when I take over that error was abvious
| and right there in the exception with stack trace.
| warrenm wrote:
| Sometimes it's the problem of not being able to see what's
| there because you already [mentally] eliminated it
|
| But I agree - _SO_ many times the error 's hanging out
| right there in the stack trace, often to within a few
| characters or lines of the "real" error in the source!
| possiblydrunk wrote:
| Patience.
| sriram_malhar wrote:
| Your list appeals to my inner geek. However, I suspect they are
| not the 10x multipliers in my practice. I may make an exception
| for knowing regex's and perl very very well.
|
| 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.
| JohnDeHope wrote:
| This is going to vary wildly by niche. My neighborhood is line of
| business apps for small to medium sized teams and departments in
| corporate settings. - Knowing as much SQL as you can learn. -
| Being enough of a project manager to at least handle your own
| business. - Being enough of a public speaker to be able to
| evangelize your own work. - Being enough of a meeting and event
| planner to contribute to those sorts of things. - Having no real
| interest, maybe even an actual aversion, to the latest fads. -
| Being enough of a administrator to at least be able to build
| servers, set up a server's OS, install important software like
| web and database servers, and generally keep them running. -
| Basic corporate communications, technical writing, documentation.
| - Being able to manage everything so that the release cycles are
| tight. Maybe more than anything else, how quickly you can turn a
| business conversation into production code deployed to end users
| seems to determine a lot of success. - Being engaged and
| interested in your team, helping with staff meetings,
| contributing to things the boss is trying to do, generally being
| a "team guy". - Having a good working understanding of the entire
| life cycle of your software. For me that means understanding most
| of what happens when web browsers, the client OS, drivers,
| networks, network protocols, web servers, application code, and
| databases all operate smoothly to render HTML on peoples'
| screens.
| notacoward wrote:
| (1) There are no magic bullets.
|
| (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.
| mejutoco wrote:
| As of recently I would say IMO Mathematics is the ultimate
| multiplier. It is thinking clearly, and it can be 10x, 1000x, or
| the difference between something being impossible or possible.
|
| 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.
| fn1 wrote:
| Communicating sequential processes for multithreading (usable in
| all languages that support threading and blocking data-transfer-
| structures).
| bluGill wrote:
| When not to use all those tricks. I can work with regular
| expressions, but they are write only code so I don't. Sure it
| takes me a little longer to parse text, but the next person to
| come along can understand and modify my text processing code for
| whatever tweaks are needed.
| chrisseaton wrote:
| > Parser generators
|
| Controversial opinion!
|
| I think most people these days generally think parser generators
| are a bad idea.
| wiz21c wrote:
| When I code and have an idea or when I spot a non urgent bug, I
| write a FIXME and forget about it. It allows to concentrate on
| going forward and leaving alone "details".
|
| (of course, from time to time I debug and fall on one of those
| FIXME's :--))
| hooande wrote:
| > * Calculus for solving all sorts of problems.
|
| 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.
| baby-yoda wrote:
| - understanding your _tools_ : what are you using day in, day
| out. are there "tricks" or efficiencies you can gain by learning
| them better? can spending time improving or perfecting your
| abilities here offer marginal improvement that will pay back and
| compound over the long run?
|
| - 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?
| [deleted]
| qorrect wrote:
| * Abstract Algebra, for when you need to create an Algebra
|
| * 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 ).
| keiferski wrote:
| The spacing effect:
|
| _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.
| kemiller2002 wrote:
| There is no list. It's not possible to say, "I know these 5
| things, and they'll make me more productive." Feynman solved all
| his physics problems with Calculus. That's it. One tool. Part of
| is is knowing your tools. The other part is being able to see a
| problem, break it down, and understand how to manipulate it into
| something that's attainable. That's it.
|
| 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.
| stnmtn wrote:
| > 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."
|
| I cannot for the life of me figure out what he means by this
| aghillo wrote:
| (3^3)3.3.5 ? Maybe...
| rockemsockem wrote:
| Best guess I have is that 27 = 9 * 3 = 3 * 3 * 3 and 45 = 9 *
| 5 = 3 * 3 * 5
|
| No clue if that's it though. Wonder if this "Pat" explained
| it to OP and OP is just keeping us hanging....
| vqrs wrote:
| The number is divisible by three I guess.
| warrenm wrote:
| >being able to see a problem, break it down, and understand how
| to manipulate it into something that's attainable
|
| Wasn't this Alexander the Great's approach: divide and conquer?
|
| Every problem gets solvable if you break it into enough pieces
| copperx wrote:
| > 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.
| warrenm wrote:
| Traveling Salesman is "solved" basically this way with
| modern map apps: it may not be "optimal", but it's _close
| enough_
|
| And close enough, as the adage goes, is almost always
| "close enough"
| jorgeleo wrote:
| I would like to challenge the underlaying idea:
|
| Asking "what fundamental knowledge" is like asking what telescope
| makes the best astronomers.
|
| The problem with knowledge is applicability. You can know a lot
| of fundamental things, but if you cannot recognize the patterns
| were they are useful is dead knowledge.
|
| My personal experience through my life (30+ years in the field)
| and observing and interviewing developers in 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.
| gjvc wrote:
| this is an unhelpful response: the guy asks a straight question
| and the response is to "challenge the underlaying [sic] idea"
| It would be better to answer their question, rather than
| attempt to knock it down. (good example of zero-sum bias.)
| ant6n wrote:
| Unhelpful response (is indempotent)
| gjvc wrote:
| "idempotent"
| wittycardio wrote:
| Most people on hn don't have deep technical knowledge and
| don't like to be told that it matters
| beaconstudios wrote:
| I have deep technical knowledge on some subjects, but how I
| got there is through curiosity and reasoning, like the
| parent commenter said.
|
| 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.
| giraffe_lady wrote:
| It is actually pretty astute and on the topic to me. Skimming
| through here, a _lot_ of people mention the fact that as they
| grow into their careers, one of the biggest gains is
| judgement about what sorts of problems even _should_ be
| solved.
|
| Or like. If someone came in asking "I'd like to make my car
| go faster, should I paint it green, or blue?" it's not
| unhelpful to point out that that's a solution to a different
| problem.
|
| Plus anyway the audience is greater than just the person who
| initially posed the question. Conversations around this and
| other similar answers are vibrant today, so clearly they're
| helpful to _someone_.
| machiaweliczny wrote:
| Seems like you vote for vector space embedding :) I've seen
| interesting paper about finding unknown embeddings and I think
| it's important skill that AI also will poses.
| kqr wrote:
| Never think you need permission to do your job well. If you are
| absolutely confident you have a great idea, then just go ahead
| and execute smoothly. Since you know the idea is good, it will be
| easy to defend later if someone calls it into question.
|
| 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.
| dougmwne wrote:
| I think the true 10x multiplier is not a technical skill at all.
| It is the ability to quickly cut through irrelevant tasks and
| actions to focus on the thing that will move the business goal
| forward fastest. It is enshrined in the concept of the MVP and
| the short iteration cycle. Quicky building something that does
| not solve a business problem is not productive.
| Work=force*displacement. No movement, no work.
|
| A closely 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.
| replyifuagree wrote:
| This. Which isn't to say that technical knowledge doesn't
| matter, it truly does. But, the primary problem in the industry
| right now is that the majority of finished code generated by
| professionals goes unused. The amount of waste is staggering.
| Working on the right thing is way more than a 10x multiplier.
| copperx wrote:
| > the majority of finished code generated by professionals
| goes unused
|
| What are you referring to?
| replyifuagree wrote:
| I'm referring to how companies ignore the thorny problem of
| what to build and instead focus on getting "Something
| done", which results in delivery of product increment that
| users at best say "meh" to, and don't use.
|
| 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
| 9wzYQbTYsAIc wrote:
| > The amount of waste is staggering. Working on the right
| thing is way more than a 10x multiplier.
|
| How much of that waste would you attribute to 1x programmers
| and how much would you attribute to 0x managers?
| replyifuagree wrote:
| 85% in favor of managers being the problem. I pulled that
| number from the Ford Motor Company turnaround where Deming
| said management was 85% of the problem.
|
| And I mean, who is responsible for curating those 1x
| engineers in the first place?
| nilsbunger wrote:
| I would attribute most of it to poor customer development
| or product management. If you can't find the demand for
| your product, it doesn't matter how good the engineers or
| managers are.
|
| 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.
| mountainriver wrote:
| Yes! I often tell people this in interviews and they act like
| I don't have enough technical knowledge. The cult of Leetcode
| has made this so much worse.
|
| 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!
| mediaman wrote:
| Part of the issue is that they often don't want you to
| decide what to build. They've separated out the "building"
| from the "deciding what to build", so hearing from a
| candidate that it's important to focus on what to do is
| off-putting to an organization that just wants you to munch
| through JIRA tickets all day and find technical solutions
| to whatever somebody else wants, and then keep a smile on
| as they change their mind and discard the feature.
| replyifuagree wrote:
| 100%. Legacy company management finds software engineers
| who engage in the very relevant question of "what to
| build" extremely threatening. In my experience they
| actually treat software engineers who behave that way as
| disloyal.
|
| 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.
| kqr wrote:
| And it's not only about features that go unused, but also
| features that are used but only in support of workflows that
| improves nobody's life. Or functionality that's used but is a
| wildly inefficient version of what could have been.
| breckenedge wrote:
| I'm curious about what you'd consider concrete examples of
| these inefficient solutions? The biggest thing that comes
| to my mind are SPAs that don't need to be SPAs.
| maccard wrote:
| > The biggest thing that comes to my mind are SPAs that
| don't need to be SPAs.
|
| 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/
| kqr wrote:
| One example from my employment history was a customer
| that kept asking for (and unfortunately getting) one
| special reporting feature after another in a data
| processing system.
|
| 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.)
| the_other wrote:
| > 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.
|
| 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.
| kqr wrote:
| You're right, of course. In practise, the organisation
| would likely make up some other bullshit work to fill up
| the time, because God forbid people get to enjoy life!
|
| (There's a tiny chance the void would be filled with
| useful work, and that's also a good outcome in my book.)
| escapedmoose wrote:
| Absolutely this. I was a chronic procrastinator prone to
| intense anxiety and breakdowns just before deadlines. Then I
| took a really good ~3 hour course on time management, and it
| seriously changed my life. I can't even describe how much more
| productive I am. It's changed how I approach every task,
| professional and personal. I can't even remember the last time
| I felt any sort of stress or anxiety about my to-do list. A big
| part of it is figuring out what doesn't have to be done right
| now ("positive procrastination").
|
| 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.
| bayofpigs wrote:
| Curious what course you took and if you have time, a summary
| of the most valuable skills you learned?
| hyshai wrote:
| Can you share this resource?
| escapedmoose wrote:
| Sorry about that--edited the original comment to include
| more info :)
| knckl wrote:
| Could you share any tips or the name of the course?
| escapedmoose wrote:
| Sorry about that--edited the original comment to include
| more info :)
| HomeDeLaPot wrote:
| I'm also interested in what you learned and which class you
| took!
| tpoacher wrote:
| What course was this, may I ask?
|
| I might watch it ... later :p
| CalChris wrote:
| The main thing is to keep the main thing the main thing.
| --Steve Covey
| noduerme wrote:
| This is the right answer.
|
| 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.
| mertnesvat wrote:
| Exactly I'm living proof that seniority comes with the
| ability to spend more time on problems to understand all the
| details before committing stuff which no idea how that works.
| rco8786 wrote:
| > The proof is that a good coder spends about 10x as long
| thinking about it before actually committing any code.
|
| This seems antithetical to the post above yours. Or at least
| how I'm reading it. In bigger tech co's this looks a lot like
| massive design documents with a dozen reviewers, all giving
| enormous amounts of time and thought to the idea in the
| pursuit of "building it right". Design processes that can
| take weeks or months for what is otherwise an MVP.
| xiphias2 wrote:
| The fact that launching any kind of work in production in a
| big organization makes it even more important to just focus
| on tiny changes (sometimes a few lines of code) with huge
| benefits.
|
| You can have bigger changes as proof of concept first, but
| select, properly design and launch the most important one.
| hagridaaron91 wrote:
| I've been thinking about this idea a lot recently. I'm
| decently new to the big-tech-co space, but it does seem
| like a huge amount of resourcing goes into design and
| defense of projects. I wonder what y'all think about
| someone doing a timeboxed MVP (a sprint or less?) as a way
| of susing out design, and THEN getting reviewers/etc?
|
| Obviously you have to take security into large
| consideration when doing things like this - but this is
| what qa/sandbox environments are for.
| cyberge99 wrote:
| A pot of big corps have Hackathon weeks for doing just
| this. A free-for-all to build something you want and that
| you think will be helpful to the org from your
| perspective.
| rco8786 wrote:
| And as soon as those weeks are over everyone goes right
| back to their previously scheduled work.
| noduerme wrote:
| Hell, wait till you find out how much time is wasted in
| Dev/Ops just changing the tooling every year or two,
| literally tearing down and rebuilding everything you
| already have in the name of staving off another couple
| years of technical debt. It's silly.
|
| I'm a bit of a rarity in the modern world (and here in
| the corporate space that is HN), in that I'm the sole
| programmer on a bunch of large software projects in
| production that I also maintain and sysadmin 24/7. The
| only meetings needed are to understand what the clients
| want and bitch at them that what they want makes no
| sense, until they start making sense, and then trust me
| to build it. If something comes up from a design
| perspective that I think could go one of several ways, I
| usually have that thought in the shower and mumble to
| myself for awhile before framing it in terms they would
| understand as a series of yes/no choices.
|
| This is generally _way_ more efficient than hiring a
| team, and I know, because I 've tried to hire teams to do
| it. There's a limit to what one coder like me can do, but
| it's a lot higher than what 4 people bickering can do.
| I'd say it's around what 8 bickering people can do.
|
| Design and defense of design, though, is _not_ just about
| ego. Not if it 's done properly. The best design/code
| people will come to you and say _this is why this is the
| only way to do X_ and lay out the chain of logic that led
| them to that conclusion. That 's not because they'll be
| personally hurt if you don't go that direction; it's that
| they're annoyed they'll have to do extra work to make an
| inferior product if you don't take their advice. _Promote
| those people_.
| rco8786 wrote:
| > I'm a bit of a rarity in the modern world
|
| I'll say. It does not sound like you'd be very fun to
| work with, as a teammate or a stakeholder.
| wing-_-nuts wrote:
| What happens if you get hit by a bus or just want to take
| a vacation? I think this is more about your inability to
| work with other people than it is about you truly being a
| 4-8x coder.
| noduerme wrote:
| Well, thanks for the confidence; you did hit the nail on
| the head. I haven't taken a real vacation in 20 years,
| although I did live in vans and hostels for 10 of those
| years. For peace of mind, I maintain a set of PGP files
| signed and keyed to each of my clients which I flippantly
| tell them to open "if I get hit by a bus", that contain
| all the SSH keys and details needed to get to their
| source files / DBs / webservers, extra code hints and
| lots of juicy advice for whatever unfortunate developer
| takes over after my demise. (Including shit like, this
| software is way too old, rewrite it).
|
| 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.
| dougmwne wrote:
| I would say analysis paralysis: no. Strategic
| thinking/designing: yes.
| lanstin wrote:
| Take the time to distill it down to a powerful but small
| concept.
| graycat wrote:
| Nice: Ah, FedEx founder F. Smith just booted himself out of the
| CEO slot and to just Chair of the BoD.
|
| 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.
| edelans wrote:
| Amen. or as Peter Drucker puts it (he is dubbed as "the founder
| of modern management" on Wikipedia) :
|
| "There is nothing so useless as doing efficiently that which
| should not be done at all."
|
| https://en.wikipedia.org/wiki/Peter_Drucker
| saidajigumi wrote:
| And likewise, this theme shows up in Tom DeMarco's classic
| book _Slack_ , which contrasts "efficiency" (the rate at
| which an organization is moveing towards _some_ goal) vs
| "effectiveness" (the ability of the organization to choose
| and steer towards better goals). An important theme of the
| book is that an organization running full-tilt (maximum
| "efficiency") intrinsically reduces/eliminates its needed
| human "slack" to reflect and iterate towards the correct
| goals. DeMarco also digs into into the many organizational
| and management anti-patterns, with supporting research, that
| harm both effectiveness and efficiency (and just plain human
| well being...)
| edelans wrote:
| "Efficiency is doing things right; effectiveness is doing
| the right things."
|
| Damned, I had to search for the author and... it's also
| from Peter Drucker !
| rawgabbit wrote:
| "If you don't know where you are going, it doesn't matter how
| fast you get there."
| edelans wrote:
| nice one as well !
| lowbloodsugar wrote:
| SOLID.
| csallen wrote:
| Computer literacy. Simply just being a fast typist, quick and
| accurate with a mouse, familiar with common paradigms and menus
| and shortcuts, etc.
| Buttons840 wrote:
| The ability to type 30+ WPM. This is a pretty low bar to cross.
|
| 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.
| pnutjam wrote:
| copy and paste can be a good tool to avoid typos. But I see
| alot of people who don't know basic keyboard shortcuts or word
| autocompletion with tab...
| faangiq wrote:
| This is an absurd and silly list. You list a bunch of obscure and
| not widely useful pieces of highly specialized knowledge. Time to
| rethink what fundamental means.
| jonas_kgomo wrote:
| I would argue that computational complexity helps you branch out
| on many problems and fields. In terms of thinking models I would
| say basic understanding of theories like Moore's Law, Pareto
| Principle, Uncertainty principle and Matrix Multiplication go a
| long way.
| geocrasher wrote:
| A multiplier: Knowing what you're bad at and abstracting it or
| outsourcing it. Focus on what you're good at.
| ncmncm wrote:
| In programming, in general, the single most valuable concept is
| the invariant.
| SamReidHughes wrote:
| > * Regular expressions > * Parser combinators > * Parser
| generators
|
| 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.
| screye wrote:
| You don't even need to know how to use regex well. If you know
| what to look for, tools like regexr.com practically create the
| regex for you.
|
| I have often found that the ability to identify : "hey I can
| use regex here", is more useful than actually knowing how to
| use regex.
| ZeroCool2u wrote:
| I'm actually just about to run into making a somewhat complex
| parser and haven't done it since school.
|
| Any recommendations resources you'd recommend as a refresher?
| SamReidHughes wrote:
| By basics I really mean extreme basics. The level of
| instruction I'm thinking is: A parser is a function
| that looks something like "optional parse_foo(const
| std::string& data, size_t *pos)", which increases the value
| of *pos. It chews off objects from the front of the string
| and returns std::nullopt upon error. It's easy to recursively
| invoke smaller parsers this way.
|
| Just that alone would really help people out and avoid
| problems I've seen encountered, where a dev needs to parse
| something, and just kind of spastically traipses around the
| string.
| ZeroCool2u wrote:
| Ah, well I've got that bit covered at the very least :)
| nunez wrote:
| knowing how to effectively run a meeting.
|
| 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).
| iamhamm wrote:
| Become a leader, hire great people, sell your vision, delegate.
| Seriously, I have 3 teams under me and I can't keep up with the
| virtual high fives because they are so productive.
| warrenm wrote:
| You're _way_ too over-focused on tech trivia in your list
|
| 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
| exdsq wrote:
| I love this idea. You don't need to be at the top 1% of a field
| to do cool innovate stuff, just be good at two or three
| different fields and see what happens when you combine them.
| Currently going down this rabbit hole with computational
| archaeology and having a whale of a time :)
| npsimons wrote:
| > just be good at two or three different fields and see what
| happens when you combine them.
|
| "Jack of all trades, master of _some_. " That's been my goal
| for most of my life.
| warrenm wrote:
| The 300+ year-old quote is "A Jack of all trades is a
| master of none, but oftentimes better than a master of one"
|
| Too often, we cut the first part off, and it sounds
| horrible!
|
| The whole quote is highly insightful
| wittycardio wrote:
| This is complete bs, real innovation happens exclusively in
| the top 1 percent of the field. This is just coolaid that
| some people like to drink to de emphasize the value of real
| skill and inflate their own egos.
| JJzD wrote:
| Some of the innovation indeed happens at the edges of what
| we know, and we learn as human species collectively. But
| most innovation is about combining multiple fields, and
| cross pollinate new ideas. Especially in the business
| world, where there is no unsolved problem, everything has
| been seen before, and most of us are just paid to get to
| the solution fastest. Applying knowledge from other fields,
| can be a great benefit.
| exdsq wrote:
| I'd be interested to know how many interdisciplinary
| engineers you know who are the top 1% in two fields at the
| same time :)
| dr_awkward wrote:
| *Kool-aid, you 1%-er.
| warrenm wrote:
| guess it depends on whether it's the Jim Jones version,
| or the stuff that aids you in being cool ;)
| [deleted]
| pcmoney wrote:
| They aren't talking about innovation but productivity. The
| OP asked "what bits of fundamental knowledge are
| productivity multipliers" this should hold true at whatever
| percentile of a field you chose, top 1%, 10% etc. However,
| it should be noted that the top 1% of innovators in a given
| field often do not understand the impact of their
| innovation on a multi-disciplinary or business context.
| throwaway684936 wrote:
| It depends.
|
| 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.
| amatic wrote:
| Computational archeology sounds great, what do you do? Is
| there more demand?
| exdsq wrote:
| It's pretty fun! The field goes from ML image analysis on
| artifacts, such as trying to identify artists in pottery,
| through to satellite image analysis, LIDAR scanning,
| ancient DNA analysis. My friend does underwater archaeology
| in Japan and spends his time scuba diving and writing code
| to analyze the images he gets. I was keen on the field
| because it lets you get out the office for a few months a
| year for fieldwork. However I'm new to this so there's a
| lot more for me to learn still! Starting an archaeology
| undergrad (distance learning) while working with a few
| research groups helping them with code in exchange for
| archaeology experience atm.
|
| The best bit is some of the groups use languages like
| Haskell so the work itself, from a purely programming
| perspective, is interesting too!
| graycat wrote:
| I agree: Computing is terrific stuff, an historic opportunity,
| but by itself is like an ingot of steel -- needs an
| application. So, need steel AND something else. So, need
| computing AND something else. My something else is some
| pure/applied math that is an advantage in my startup.
| kayodelycaon wrote:
| This. I learned a lot of business and management skills on the
| side... sales, marketing, accounting, vendor negotiation,
| inventory, merchandise ordering, policy enforcement, staff
| training, firing people (and how much it sucks), etc... by
| helping run a furry convention for 5 years.
|
| It's one of the best things I've ever done for my career. I
| enjoy casually listing that on my resume under volunteering. :)
| zaphod12 wrote:
| I appreciate this concept, but I'll need someone to tell me
| what the baker/welder is producing. At this point I NEED TO
| KNOW
| warrenm wrote:
| I'd bet they can put a down a mean bead of fondant, or frost
| their joints well :P
| sharadov wrote:
| I completely agree, you need to be good and 2 or more areas,
| not necessarily an expert at each of them. The combined effect
| is insane, and makes you very valuable.
| Kelteseth wrote:
| This so much. I started doing UX and web design as a teenager
| and only later learned to code. This now helps me tremendously
| because I learned valuable lessons: In UX/UI design, you
| usually do like 10 variations of your design if you're not
| satisfied. This fixation on details often forces you to forget
| about the hole picture. In the end, you have to take a step
| back and try out other completely different approaches.
| tomrod wrote:
| You hit most of mine!
|
| I'd add formal logic and argumentation and logical fallacies.
| teknopaul wrote:
| Echoing sentiments expressed...
|
| 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.
| eternityforest wrote:
| A lot of those are pretty domain specific. Calculus is 10x only
| because it lets you get into fields where calculus is 10x. I have
| no idea what a general everyday coder would do with it.
|
| I could list tons of design patterns, like separate mutable and
| atomic readonly copies of the same data, but they wouldn't be
| universal, although patterns are wonderful.
|
| The closest thing to a real 10x I know is laziness and respect
| 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.
| monksy wrote:
| > Riced desktops? Gone. Custom made productivity apps? Gone.
| Simple bash scripts to move files around and do backups? Gone.
| Distro hopping? Extra gone. New JS frameworks? Gone but with
| napalm. Making your own programming language? Not gone because
| it never even started.
|
| This sounds more like depression rather than something that
| helps you grow. Yes, in production and production like
| environments, be boring. It helps. But discorgaging people from
| getting into that is a path to dis-encouraged engineers. People
| experimenting with weird things leads to innovation and
| learning.
| angarg12 wrote:
| I roughly divide these skills into three tiers:
|
| * 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.
| noduerme wrote:
| I mean, this sounds narrow, but going off of what _you_ think are
| 10x multipliers, in terms of getting more bang for your hour
| /buck:
|
| * 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.
| brianhorakh wrote:
| Replacing the cat with a obedient well trained dog, may
| increase happiness. Seriously, well trained dogs are perhaps
| the biggest life hack a person can do.
| bluGill wrote:
| > Fully understanding how SQL prepares queries; optimization
| strategies
|
| That might be very useful for me, but my career has taken a
| different track, and I have never needed that. I almost never
| touch SQL, and never in a situation where performance matters.
| However I know that I can look that up if I need it (or more
| likely find someone else - I expect looking it up will take
| months)
| rawgabbit wrote:
| Understanding the architecture of your database engine is
| important. I've had numerous "I told you so" moments in my
| career when devs didn't believe me, and when ahead and do
| things like:
|
| a) Let's speed up the SQL processing by creating 40K
| connections and each connection running a stored procedure.
| Unless your particular SQL instance has enough memory and cpu
| to support 40K connections, you are performing a denial of
| service attack on your own server.
|
| b) I hate stored procedures and scripting; I am going to
| write a big ass SQL query that is 200 lines long. Your giant
| SQL query is too complex for the SQL engine to create an
| optimize query plan. It will effectively reduce your database
| engine from using set based logic to one row at time. One
| time, a developer complained SQL sucks and blow big time blah
| blah blah. It took me four hours to figure out his ungodly
| query. I was able to performance tune the query by breaking
| it into many small steps using temp tables and putting it all
| into a stored procedure. Execution time improved from 10
| minutes to 9 seconds.
| noduerme wrote:
| eh, I only brought it up because SQL is a funny beast. You
| have to _think_ like the optimizer in some cases. I recently
| found a report query that was taking >90 seconds to execute.
| It was looking at something like 2 billion records, but it
| shouldn't have taken that long. It really tangled my mind.
| Each of the records had a `start` and `end` timestamp, and
| were being collated in a join on a separate key and sorted by
| MAX(`end`). So there's a joint key on the table that is
| start+end, but not a separate key for each. I figured out the
| query could be speeded up by about 80% if I _added_ a
| parameter for `start`, a meaningless WHERE `start` >0 even
| though I didn't need one. Basically any start would be OK, I
| just had to have it there because even forcing key on the
| start/end index didn't kick the optimizer into realizing it
| needed to search that as a hash space. I don't know. It was a
| _feeling_. This is just in the vein of someone asking, "what
| is jujitsu to you?" But no, don't learn it if you don't need
| it.
| warrenm wrote:
| reminds me of helping a friend at work years ago (the
| halcyon MySQL 3.23 days)
|
| they had a query that ran every 5 minutes, but on non-
| trivial data sets (network monitoring data for more than
| ~200 devices on a network), the query would take more than
| 5 minutes to run ... throwing hardware at the problem
| didn't help noticeably (double the CPU speed? run time
| would drop by ~5%)
|
| converting their query from OR form to IN() cut runtime by
| 90%
|
| All because of how the SQL engine thought it should run
| comparisons (MySQL, at the time, at least, used the IN() as
| functionally equivalent to a jump table, whereas the OR
| format was treated as a series of it...then...elseif...else
| statements)
| fn1 wrote:
| Solving problems iteratively in the same way progressive jpegs
| render: Start with essential parts, quickly assemble them to a
| usable draft and iterate on the entire thing by improving quality
| where it needs to be improved.
|
| This is applies to programming as well as to writing, drawing,
| making music etc.
|
| Applying this to writing emails can definitely improve your
| business communication 10-fold:
|
| * write down the 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.
| Ancapistani wrote:
| > Solving problems iteratively in the same way progressive
| jpegs render: Start with essential parts, quickly assemble them
| to a usable draft and iterate on the entire thing by improving
| quality where it needs to be improved.
|
| This is something that I feel I'm really good at, and I like
| this explanation a lot.
|
| I'll add that while being able to look at problems at a high
| level and then slowly increase "resolution" is a huge
| advantage, the key in my experience is the ability to switch
| between those levels of abstraction quickly.
|
| The more complex a system, the more important this ability can
| be.
|
| Let's say you're building out a large new feature that can be
| implemented in three parts: Service A, Service B, and the
| communications between them. That's the highest level of
| abstraction: we are dealing with three components, each of
| which has a very high-level purpose/domain.
|
| Once each component has a defined domain, we can disregard the
| other components when drilling down into each one. This works
| _very_ well, but invariably we'll reach a point where we
| discover than an assumption that was made at a higher level is
| no longer valid.
|
| At that point, there are two options: we can stay this level of
| abstraction, leave our component domains unchanged, and "work
| around" the issue. Sometimes that's fine and leads to
| relatively minor hacks or technical debt. Other times, it's not
| fine, because the violated assumption can be much more easily
| remedied by going up a level of abstraction and changing the
| domains of our components. Often, the assumption that didn't
| hold in Service A also impacts Service B, and doesn't hold
| their either.
|
| Maybe that will result in splitting the problem into one more
| service; maybe it will mean that the domains of each service
| need to be adjusted so the issue is isolated into one of them;
| maybe it means that we chose to split the problem up along the
| wrong boundaries to begin with and need to reconsider them
| entirely.
|
| My point is - starting at the most abstract level and working
| your way down is powerful, but you don't always have all the
| information necessary the first time you walk down that
| complexity tree.
| onlurking wrote:
| What strikes me, is that everything you listed is under the
| "Lindy Effect", if it has been around for 30 years, you can
| expect to be around for the next 30 years.
|
| Among those, I can also recommend: Relational Databases. Unix
| tools for text manipulation, like awk, grep, and sed. Make.
| Architecture patterns.
| kqr wrote:
| Learn how to lead from any position. You don't need to be
| promoted to lead.
|
| 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.
| catchclose8919 wrote:
| Learn to delegate/outsource at all levels from technical to
| mathematical: the best kind of delegation is to
| tools/systems/languages/type-systems (eg. "outsource your
| attention to the type-system") since it's always cheap enough to
| be in-budget...
| thunkshift1 wrote:
| Why is delegation important?
| cloverich wrote:
| Because otherwise you are solving problems someone else can
| solve just as easily. It doesn't mean be lazy, it means be
| selective about what you choose to do yourself. Its a big one
| in the seven habits book: Do, Plan, Delegate, Eliminate.
| [deleted]
| jstx1 wrote:
| Most of these aren't really productivity multipliers, they just
| enable you to do the thing you need to do.
|
| It's unlikely that someone is doing task A without any calculus
| but another person who uses calculus is 10x more productive on
| the same task.
| bmj wrote:
| I think it's also possible that some of these lead to a I've-
| got-my-hammer-and-everything-is-a-nail approach to problem
| solving. You may then find yourself parsing HTML with regexps (
| https://web.archive.org/web/20111009133402/http://stackoverf...
| ), which is never a good idea.
| brianhorakh wrote:
| This is called "law of the instrument"
| noduerme wrote:
| I'm a big fan of `for (x of y)`, skip the functional version,
| manipulate variables in and out of scope, hell, use globals.
| Sometimes you show up wearing a tux, other times you just
| have to rock the party in a hoodie.
| i0nutzb wrote:
| You may want to NOT underestimate one's ability to add TONS of
| if/elseif/else (or switch/case) statemens in order to put
| things on track...
|
| 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.
| jstx1 wrote:
| True, as I wrote the calculus example I remembered this post
| about a medical researcher rediscovering integration -
| https://news.ycombinator.com/item?id=26384357
|
| 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.
| SamReidHughes wrote:
| That's actually not so bad. Physicists in the 20's
| reinvented matrix math.
| Qem wrote:
| Interesting? What would be a good reference on this?
| SamReidHughes wrote:
| I most recently encountered this fact in _The Man from
| the Future_ , a recent biography about John von Neumann.
| (The first half of it, the first 5 or 6 chapters were
| good, but it goes off the rails after that.)
|
| I think by "physicists" I should have said, Heisenberg.
| I'm talking about this: https://en.wikipedia.org/wiki/Mat
| rix_mechanics#Heisenberg's_... https://en.wikipedia.org/w
| iki/Heisenberg's_entryway_to_matri...
| hyperman1 wrote:
| Back in the day, I saw someone ripping a CD to MP3s. He
| lazily named the first one 1.mp3, the seconde one 2.mp3
| etc. After 9, he found he ran out of numbers. So the next
| one became ... A1.mp3 !
|
| I always wondered, if he thought this trough a little bit
| further, he'd independently reinvent the arabic number
| systems.
| brimble wrote:
| Some interfaces will sort 10.mp3 so it's directly under
| 1.mp3, instead of under 9.mp3. This could be a totally
| sensible hack to evade that problem.
| aix1 wrote:
| It even has a name: natural sort order.
|
| https://en.wikipedia.org/wiki/Natural_sort_order
| noduerme wrote:
| I just had a recent situation like this which initially
| presented as a simple calendar / due date list, but then
| spiraled into some dreaded fuzzy set of if/then cases as the
| client began to add requirements for due dates of certain
| items in a certain order that would take priority over other
| items due on the same date, or missed items, or future items
| that could be done in advance.
|
| 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.
| warrenm wrote:
| >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
| noduerme wrote:
| Yeah, it's kind of meta-coding at a certain point.
| Business people are great with the logic of making money
| and keeping customers happy, but they are bad at
| translating those operational requirements into pure
| logical processes. Particularly if they expect their
| employees or customers to use software that they expect
| to guide them to do things in a set order, they aren't
| good at thinking about the order from the software user's
| perspective. So just putting yourself in the shoes of
| both those people is really the job. It's understanding
| the desire of the business and seeing where that's going
| to run up against problems in the real world.
| brianhorakh wrote:
| Can you share or summarize the blueberry muffin email?
| noduerme wrote:
| Uh, if you really want. This is probably boring as fuck
| until I get emotional around the third paragraph ;)
|
| ---
|
| 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.
| sanderjd wrote:
| This is well put. It gets to my ambivalent response to this
| list. Understanding parsers is important ... if you're parsing
| things. Etc.
| tempestn wrote:
| For me the most notable one is the adoption of a GTD system for
| task tracking, which I did in concert with two related changes:
| starting inbox zero, and switching from bookmarking-and-
| categorizing to clipping-for-search reference material.
|
| 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-...
| carabiner wrote:
| This is literally all knowledge. You've got to narrow it down.
| Literacy, numeracy, knowing how to use a dishwasher, knowing to
| hire a housekeeper if you suck at cleaning etc.
| meheleventyone wrote:
| Being able to ask questions, ask for help and keep track of what
| you need to be doing each day. A surprising number of people are
| terrible at getting their ego out of the way.
| MrWiffles wrote:
| One thing that I've been focusing on lately is "the little
| things". Does the interface look nice? Is the font big enough to
| read 2ft away? How easy is the command to update the software?
| Have we tested both the backup AND restore workflows? Are they
| all _buttery smooth_? Does everything work the way you'd expect
| right away, out of the box, by default?
|
| 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.
| JoeyJoJoJr wrote:
| Yes, all this. I apply this mentality mostly to presentation.
| If the design and code present well, team members are much more
| likely to contribute in positive ways and help "tend to the
| garden".
| mwattsun wrote:
| Sometimes inaction can be a form of paralysis, so I like the OODA
| loop concept for acting based on your best information then re-
| evaluating as new information comes in.
|
| https://www.techtarget.com/searchcio/definition/OODA-loop
| disambiguation wrote:
| my 2c, I think 10x vertical (better individuals) is not viable
| for everyone, but 10x horizontal (better teams) is more
| accessible. Things like good documentation, testing, and
| collaboration tools and practices go a long way in 10x'ing a
| team.
|
| my only 10x personal practice is: take notes on everything. build
| a knowledge base. it doesn't have to be presentable, they can be
| scratch notes, dumps of important links and details. over time
| this accumulates, and when a given topic comes up again you'll be
| prepared to seamlessly pick up where you left off.
| warrenm wrote:
| you've just described the zettelkasten :)
| thenerdhead wrote:
| Knowledge doesn't make you productive. Wisdom does. Wisdom
| applies your knowledge.
|
| 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
| neoneye2 wrote:
| * Automated testing. While implementing an algorithm, also make
| tests. Years later, if the program begins crashing in a test,
| then it can be fixed. Without tests, the crash may happen
| sporadic in production and be hard to fix.
|
| * 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.
| btschaegg wrote:
| Since you mentioned regex, I'd add:
|
| - 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.
| 28304283409234 wrote:
| Knowing in which problems pace you are and which solution
| strategy works in that space. Basically: "cynefin".
| jyu wrote:
| No code is faster than no code.
| brianhorakh wrote:
| Do you use any zero code?
| ToJans wrote:
| Only 2, with IRL examples from this month:
|
| * 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.
| beamatronic wrote:
| Spreadsheets such as Microsoft Excel and Google Sheets. Any time
| I want to do a "what-if" scenario that involves math, I create a
| new spreadsheet, and I set up a series of cells as the input
| parameters, and then I start creating formulas. You can try out
| anything math-based very quickly (algorithms, tax calculations,
| etc)
| perceptronas wrote:
| Having business invariants be part of system design. It makes
| sure that system prevent invalid states by design. An incredible
| multiplier in both productivity and complexity management further
| down the road.
| throwaway6734 wrote:
| Cd -
| brianhorakh wrote:
| Return to the previous directory
| stragies wrote:
| alias c-='cd -'
| smoe wrote:
| Knowing how to use your tools. Operating systems, window
| managers, editors, debuggers, cli&gui tools in general, keyboard
| shortcuts etc. I often find the lack of this pretty jarring,
| watching how slow and ineffective some people are when using
| their basic tooling, even though they are a couple of years into
| their career and have written a todo app in a dozen currently
| cool languages/framework on the side.
|
| 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.
| heyflyguy wrote:
| Employ a virtual worker that schedules meetings and replies to
| low-level emails. Disconnect yourself from real-time
| communications during those hours and allow your VA to contact
| you in cases of urgently needed replies. I employ a lady 20 hours
| a week for this, so I get core time about 4 hours a day to do
| whatever I want. Even if it's pc gaming. Costs me $15,000 a year
| and is well worth it.
| jdauriemma wrote:
| Can you elaborate on how this "virtual worker" works in
| practice? I'd love to learn more.
| heyflyguy wrote:
| She logs in remotely on my email. To get her up to speed she
| watched what and how I replied to things for about a week,
| until I had her start drafting emails as replies that I would
| approve (or edit) and reply. After a while she just got it.
| She's based in the Philippines and works from 11p - 3a her
| local time. I proactively schedule my conflicts and times in
| my calendar, and then she can schedule anything in the open
| space.
|
| I could just not answer for a few hours a day, but I have
| alot of people who expect a quick response. This solves that
| and gives me back my evenings to spend with the family.
| mianos wrote:
| Never parse a data file with regex or string functions. Always
| spend the small extra time to at least write a state machine.
| belkarx wrote:
| Could you elaborate on how this might be done?
| wallscratch wrote:
| Why? Aren't all regular expressions equivalent to some finite
| state machine?
| rockemsockem wrote:
| Never is a strong word. If I have a data file that I'm not
| going to use very much I'm definitely going to write 10 lines
| of python using re.find and string.find to get what I want out
| of it.
|
| Unless you have some nice way to quickly create a state machine
| besides using regexes?
| icedchai wrote:
| Knowing how to use Google (or another search engine) is probably
| the biggest multiplier of all. Odds are _someone_ has done
| _something_ on the sort of problem you are trying to solve.
| ncmncm wrote:
| Those are exactly the things that anybody else could do just as
| well as you. What makes you valuable (if you are) is exactly
| the things that nobody can just as well look up on Google.
| icedchai wrote:
| They could, but generally they don't. There is some truth to
| what you say, but if you've worked anywhere for very long,
| you'd also realize most people are very, very bad at looking
| things up on their own! They'll try to reinvent the wheel
| when the wheel already exists (or almost.)
| clavalle wrote:
| Googling well is an underrated skill.
| ant6n wrote:
| > Search algorithms for solving a variety of problems (e.g. all
| NP-hard problems, sudoku, HTNs, scheduling, planning)
|
| 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.
| chasd00 wrote:
| know the tools available in your industry/field. For example, if
| you're working on some embedded system controlling hardware don't
| get out your old differential equation and linear algebra book,
| instead, use matlab/simulink and leverage all the work everyone
| else has done already.
| briggers wrote:
| Before you start optimizing runtime performance: measure, trace,
| inspect, or whatever is appropriate to understand current
| performance.
| oxff wrote:
| Process knowledge, ie. how do you effectively contribute to the
| organizational body of work, and how you can make it more
| effective etc.
| aj7 wrote:
| Being able to walk into a machine shop and make a part, right
| then and there.
| wobbly_bush wrote:
| Where can one learn such skills?
| carabiner wrote:
| Community college or a guy who knows how.
| JacobThreeThree wrote:
| General machining skills are excellent and they're being lost
| thanks to the shift to a CAD-based workflow.
| thrwyoilarticle wrote:
| So the 10 10x multipliers you know make you 10000000000X more
| productive than a normal software engineer?
| mkl wrote:
| That would only follow if the 10 multipliers each covered every
| aspect of the job, but they don't. I agree with the thrust of
| your argument though, as the only (occasionally) 10x multiplier
| I can think of for my work is programming (I'm not employed to
| write code, but sometimes it helps, and sometimes a lot).
| giantg2 wrote:
| "Calculus for solving all sorts of problems."
|
| 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.
| lanstin wrote:
| calculus is irreplaceable for understanding system dynamics.
| Every meta-stable computer system is an incarnate approximarion
| of some differential equations relating the different parts of
| the system and the way changes propagate from here to there. I
| don't often use numerical methods, but analysis of stability,
| classification of fixed point types, topological limits to what
| small changes to the system can do to the behavior do all come
| into play. The people enforcing backoff for retries,
| randomization or careful analysis of fatal vs. temp errors, are
| using those sorts of insights. while you can take ten years of
| industry experience to get a feel for these flows, you can also
| take a good DiffEq/Dynamic systems course and start out
| understanding the possible shapes at the start.
| tonyarkles wrote:
| I realize that I'm in a less common industry, but I often end
| up using calculus and DiffEqs in my day-to-day work working
| with drones.
|
| 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.
| giantg2 wrote:
| I mean, you could call that basic logic and just take a
| philosophy course. That would provide formal and informal
| methods of evaluation without the need for actual calculus.
| This informal understanding and balancing is more closely
| aligned with philosophy than it is to calculus.
| rockemsockem wrote:
| How does logic help you understand what system dynamics
| will arise from choosing a particular exponential backoff
| or making a choice about picking some method with a
| particular known error rate, as the original commenter
| mentioned?
| SamReidHughes wrote:
| Nope. You could call that basic logic... and you'd be
| wrong, because it's not basic logic.
| giantg2 wrote:
| How so? The comment clearly states that they aren't doing
| any formal calculations, not using numerical methods, and
| just getting approximate insights.
|
| If I'm wrong, show me I'm wrong and post a substantive
| comment. Snarky comments like that are not inline with HN
| guidelines.
| SamReidHughes wrote:
| It's not a snarky comment, it's literally, not actually
| basic logic. You had no factual basis for saying it was.
|
| 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.
| giantg2 wrote:
| You misunderstand. This is the basic logic I was talking
| about. Note my comment mentioned 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
| SamReidHughes wrote:
| Limit cycles are a concrete example of "analysis of
| stability, classification of fixed point types,
| topological limits to what small changes to the system
| can do to the behavior."
|
| This is calculus, not logic, not philosophy.
| giantg2 wrote:
| Did they say they're using limit cycles? They could be
| using less formal methods that are not calculus, like
| most people do. You have not spoken to the context or
| approach they are using. Similar concepts can exist in
| multiple domains with varying levels of formality.
|
| 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.
| brimble wrote:
| I had the same reaction. I've forgotten most of it, but that's
| _because_ there have been zero times in the ~18 years (oh
| god...) since I had a calculus class that I 've seen anything I
| could use it for, without just making up a reason to use it.
| softwarebeware wrote:
| " Chances are, every time you used your credit card, filled a
| prescription or pumped gasoline, a calculus formula was used to
| calculate it."
|
| https://study.com/academy/lesson/calculus-in-the-real-world....
| giantg2 wrote:
| Looks like a paywall.
|
| Yes, a calculus formula might have been used somewhere in
| that process, and was used by the finance person and dev.
| That doesn't mean I, or any other person, needed to know it.
|
| As a dev at a financial institution, I've never needed to
| implement calculus formulas. Most calculations and formulas
| I've dealt with are algebra and stats. These usually are just
| a matter of using standard libraries too. So most devs aren't
| implementing formulas themselves, but just utilizing standard
| libraries.
| softwarebeware wrote:
| > Looks like a paywall.
|
| That's odd. It loads up just fine for me with no paywall.
|
| Check this out for more:
| https://allusesof.com/math/51-amazing-uses-of-calculus-in-
| re...
|
| The point is that calculus is used to solve all sorts of
| problems. Sure, you can say "...not in my experience" but
| that's one experience and not representative. You just
| happen to a) not work in a realm where Calculus is used
| and/or b) work within that realm only on problems without
| Calculus.
| giantg2 wrote:
| I'm not saying it doesn't exist. I'm saying that it isn't
| commonly used. Objectively, a great majority of people
| can live their lives without even thinking about or
| performing calculus outside of the classroom.
|
| That is why I questioned whether knowing calculus is
| really a piece of fundamental knowledge that allows a 10x
| performance increase. For the majority of people it's not
| going to help them. Even if they deal with calculus in
| their field, I don't see it providing a 10x increase
| because unless one is mathematician, the calculus portion
| of their job will be inconsequential and likely be
| automated or computed for them.
| softwarebeware wrote:
| > Objectively, a great majority of people can live their
| lives without even thinking about or performing calculus
|
| OK no argument there. The OP statement was "For example
| ... Calculus for solving all sorts of problems" so it
| appeared you were taking issue with the idea that
| Calculus can be used to solve all sorts of problems. Your
| argument is clearer now: even if Calculus can be used to
| solve all sorts of problems that doesn't mean that it is
| "fundamental knowledge" for most people.
| sanderjd wrote:
| The way I would put this is that it's important to be
| _familiar_ with calculus, to know that it exists and have
| a sense of where it tends to pop up. From that
| familiarity, you can look up the details on demand. But
| being entirely unaware of the techniques of calculus
| would probably be hindrance.
| SamReidHughes wrote:
| Just for personal investing I've used calculus amidst some
| basic modeling to estimate probability of getting certain
| outcomes under certain assumptions and compute an expected
| value. This is just to sanity-check my thinking, or to see what
| the market's thinking.
|
| 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.
| Ancapistani wrote:
| I took calculus in high school and did really well in it -
| but I honestly can't say whether I've used it or not as an
| adult, because all of my mathematical knowledge kind of runs
| together in my head.
|
| 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?
| SamReidHughes wrote:
| Work-related, I built a backend of a database engine on top
| of a transactional distributed key-value store. When
| building a secondary index, suppose you traverse the
| primary index in a series of transactions, reading a batch
| of key/values and updating the secondary index. With the
| scheme that was used to build the index, this has the
| chance of conflicting with an incoming write, which will
| also try to update the secondary index. You'll have some
| kind of backoff/retry strategy. What is the optimal batch
| size? Treating it as a clean calculus problem with static,
| homogeneous workloads, you could model the probability of
| getting a conflict, the performance of a given batch size,
| set the derivative to zero and find the maximum. (In
| reality instead of modeling the probability, you can
| measure it.)
|
| 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> Do you use it for text transformation?
|
| Mostly, yes. How often do you search and/or replace and/or
| extract text? Now imagine doing it while being able to specify
| patterns instead of just fixed text.
|
| A couple examples:
|
| - find all occurrences of some text only when near some other
| text, no matter the intervening text;
|
| - transform calls to a routine to calls to another routine,
| while swapping arguments.
|
| As for other tools, once you know them, you will find ways to
| use them.
|
| Yes, their syntax can be difficult to remember, but most of the
| time you are going to use just a few patterns and will learn
| them by rote memorization. They will become second nature, and
| indeed I myself am sometimes surprised by the complexity of
| patterns that I write without thinking about it. Anyway, I
| recommend that you have handy a plugin for your text editor
| that highlights matches, to help in troubleshooting buggy
| regexes when they get convoluted.
| bawolff wrote:
| Regex has been very useful in my career. I would also add SQL as
| well.
|
| 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.
| spdaly wrote:
| Saying "No."
| whoknew1122 wrote:
| There are three things that help me:
|
| 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.
| rsync wrote:
| Here's one that can be widely applied - from inside the cpu to
| your daily commute:
|
| _context switches are expensive_
|
| ... and yes, sometimes so expensive that not knowing this might,
| indeed, have a 10x penalty.
| jp42 wrote:
| Can someone care to elaborate more on this?
| cosmojg wrote:
| Learning to adequately estimate probabilities and make decisions
| based on those probabilities is extremely powerful, and that's
| true whether you use those skills in your investments, your
| career, or your relationships. You can get a lot of practice on
| sites like Metaculus[1] and Manifold Markets[2].
|
| 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
| gadders wrote:
| Excel and VBA
| benstrumental wrote:
| Knowledge growth is exponential. Rather than focusing on specific
| topics/tools, focus on trying to gain some form of knowledge,
| insight, or skill from whatever task you are working on.
|
| 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.
| sideproject wrote:
| Learning how to talk well sounds.. simple but it was a big eye-
| opener for me. A more formal way of putting it would be "How to
| communicate effectively".
|
| 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.
| jcranberry wrote:
| Sleep 8 hours a day.
| syngrog66 wrote:
| work expands to fill the time you allow it to fill. thus: timebox
|
| dont let perfect be the enemy of the better
|
| iterate
|
| many many others
| brianhorakh wrote:
| 1. Super learning techniques Srs, memory palace, speed reading or
| time shifting video/audio
|
| 2. Model based thinking: Big book of mental models is a great
| place to start.
|
| 3. Learn how to train your dog properly (perhaps the single
| biggest life hack a person can do imho)
| rockemsockem wrote:
| I'd be interested to hear you elaborate on 3 more. I think
| you're probably onto something with that, but it's hard to say
| without more details.
| alangibson wrote:
| - Finish at least as much as you start.
|
| - Focus like a maniac on tasks that generate value. Busyness has
| nothing to do with productivity.
|
| - Agressively reduce all coordination overhead (emails, meetings,
| etc)
| mym1990 wrote:
| Not sure I agree with business not having anything to do with
| productivity. The best businesses are able to get ahead by
| being able to produce more or better quality products through
| higher productivity, which keeps those businesses competitive
| with the rest of the market.
| alangibson wrote:
| What I mean is you can be flat out busy every waking hour and
| not produce anything of value. Everyone on HN knows at least
| one coworker that is negatively productive.
|
| if you look at businesses instead of individuals, there are a
| great many businesses that are full of hustlers which end up
| with a value <= 0 (i.e. bankrupt).
| monksy wrote:
| Fundamental Knowledge that are productivity multipliers:
|
| 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.
| IAmYourDensity wrote:
| * Dynamic Programming and the related concept of Memoization.
|
| * 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.
| esbeeb wrote:
| Meditation. The more wisdom one gains over which avenues of
| pursuit in life are unwise, and cuts them out entirely through
| better decision making, that's a giant gain in productivity. It's
| a giant gain in productivity to have the mindfulness, and
| emotional and spiritual maturity to nip in the bud bad choices
| before they turn into a big waste of time.
| erdos4d wrote:
| Graph Theory is definitely a secret weapon I've used on numerous
| occasions. I would recommend Python's Networkx module if you find
| yourself staring at a graph problem.
| jupiterelastica wrote:
| In the software development world I would suggest: knowing how to
| interface one's own software with existing systems to automate
| tasks.
|
| 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.
| TheHideout wrote:
| Design of Experiments + ANOVA for characterizing and optimizing
| systems
|
| Edit for typo
| TheHideout wrote:
| Another good one is to get comfortable with drawing to improve
| your ability to communicate ideas visually.
| mooreds wrote:
| Knowing how to use the command line.
| trevormcneal wrote:
| If you are doing too many parallel things and context switching
| become a PITA, have an org document for each of your tasks, write
| your thought, experiments with code and output, your decisions,
| keep a references list with links and other important things.
|
| 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.
| biased_coin wrote:
| Understanding of your organizations ways of working and making
| connections across teams.
|
| 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.
| wonderwonder wrote:
| The ability to rapidly context switch. So much of my day is
| filled with meetings with 30 minute breaks in between. I pretty
| much do nothing with those 30 minute gaps because I cant refocus
| on code fast enough to be productive. So most of my coding is
| done in the last quarter of the day and I probably waste 1.5
| hours a day on just waiting for the next meeting.
| mym1990 wrote:
| I think the opposite of this would be 'the ability to manage
| time'. No matter how good or fast you are at context switching,
| there is still an inherent inefficiency in it, and it does take
| a mental toll, whether you admit it or not.
|
| People might say that 'I can't avoid the 30 minute meetings'
| but you can certainly set expectations, learn when to say no,
| etc...
| syngrog66 wrote:
| CLIs > GUIs
|
| automate > manual
|
| many many others
| nojito wrote:
| Communicating with other human beings.
|
| You'll be surprised at how many "great developers" never move
| anywhere in terms of productivity because they lack fundamental
| communication skills.
| stncls wrote:
| If you deal with computationally hard problems, I think there's a
| whole toolbox of utilities with unbelievable performance, in
| which millions of PhD-holder-hours have been poured, but that get
| ignored more often than not.
|
| - 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.
| sidpatil wrote:
| Mathematical programming (LP, (M)IP, etc.) feel like
| superpowers to me. Working with them also helped me realize
| that many optimization problems are actually just closely-
| related variations of the same problem.
| pdhborges wrote:
| Maybe because Linear Programming is P-Complete.
| mw888 wrote:
| I could certainly read more about this, it sounds fascinating.
| Will appreciate more of your knowledge or a thoughtful hyper
| link.
| knodi123 wrote:
| the concorde reference:
| https://www.math.uwaterloo.ca/tsp/concorde/DOC/index.html
| mw888 wrote:
| I'm aware what the TSP entails and have written algorithms
| for it myself, but the mathematical approach to
| programming, so explicitly, is new to me.
| runjake wrote:
| - Learn to code. (not everyone here codes)
|
| - 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.)_
| cmetzger4 wrote:
| Will you explain what you mean by "Design everything you can to
| be declarative"?
| haihaibye wrote:
| I think they mean if you can, don't define the execution
| yourself. Rather, specify what needs to be done, then have
| the machine work out what to execute.
|
| Eg declare dependencies and have Make build things, specify
| SQL query and have the optimiser fetch the data
| brianhorakh wrote:
| Also build tools in compositional scripts with good names
| AlexCoventry wrote:
| Automate figuring out how to do things from a machine-
| readable specification of the desired result.
| Agingcoder wrote:
| System bounds/invariants, ie things that you know can or can't be
| true. They can be about hardware, os, algorithms, networks, etc.
|
| They allow you to quickly pinpoint problems, and avoid exploring
| places you shouldn't explore ( which is very handy when designing
| a new system) .
| loves_mangoes wrote:
| All those little bits of knowledge are nice tools and patterns,
| they're definitely good to have. And if you have curiosity, you
| will naturally keep learning dozens of those over time.
|
| But they are not applicable everywhere, so you should not expect
| your 8 hour days to turn into 48 minutes because you started
| using regexes, dynamic programming, and search algorithms
| everywhere.
|
| The unlikable and unhelpful answer, but 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.
| Izkata wrote:
| > The only 10x differences that genuinely exist are between
| people who are 2x faster than average and people who are 5x
| worse.
|
| The original idea of a 10x developer was between best and
| worst, not best and average.
| lelele wrote:
| The OP is not about 10x more productive, it is about 10x
| productivity boosts. Using regexes can easily be 10x faster
| than manual editing, and property-based tests can easily be
| written 10x faster than a more or less equivalent battery of
| tests.
| loves_mangoes wrote:
| I agree with you :)
|
| 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.
| rockemsockem wrote:
| On the point of regexes, I think you might be
| misunderstanding OP. Regexes have absolutely given me a 10x
| productivity boost over the years, but not because I write
| production code that relies on regexes to parse things,
| extract things, etc.
|
| 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.
| loves_mangoes wrote:
| That's entirely fair. I do the same, a lot. I like
| writing macros, using regexes, or even short awk scripts
| to automate any manual text workflows.
|
| 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.
| rmbyrro wrote:
| > The harsh reality is that there is no single thing a 1x
| person can do to become 10x.
|
| Any evidence for this? You may say there's no evidence that a
| 1x person can work up to 10x its performance, but stating it's
| impossible without evidence lacks merit.
| loves_mangoes wrote:
| Two answers to this.
|
| 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)
| bckr wrote:
| There's no _single_ thing.
| brianhorakh wrote:
| Respectfully disagree. The compendium of skills integrated is
| the "Single thing"
| loves_mangoes wrote:
| Sure, but I feel like that's trying to argue semantics
| without really changing the nature of the problem.
|
| 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.
| lanstin wrote:
| You may wish to read Gould's Mismeasure of Man, and about thw
| fallacy of reification.
|
| 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.
| loves_mangoes wrote:
| I think you're right that focusing on group effects will be
| more productive, but I probably reach the same conclusion for
| different reasons :)
|
| 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.
| chadcmulligan wrote:
| I would recommend to any developer who wants to be an expert
| learn assembler and C, then OS fundamentals and networking. If
| you don't know these things then it makes it difficult to ever
| make other things efficient if you don't know what's going on
| under the covers - imho.
| earth_walker wrote:
| Stepping back and balancing the numbers: e.g. Mass balance,
| energy balance, balancing the books, balancing your schedule,
| profit analysis, etc.
|
| 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.
| Turing_Machine wrote:
| * Don't get too hung up on computational complexity.
|
| 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.
| bluGill wrote:
| in these days of modern CPUS with cache and branch prediction,
| O(n^2) often beats O(logn) because your data is tiny compared
| to the cost of all those cache misses and branch misses the
| seemingly faster algorithm creates. This doesn't apply when you
| data is large, but then you need parallel algorithms, and not
| in memory data (or just punt all your data to the sql server)
| AnimalMuppet wrote:
| Yeah. n = 3 more often than you expect. n <= 12 _far_ more
| often than you expect. If you don 't work at a FAANG, don't
| automatically assume that your data and algorithm need to
| squeeze the last O(logn) possible out of the algorithm.
| chadcmulligan wrote:
| And if it is too slow a hash table or two will probably fix it.
| BobbyJo wrote:
| Optimize for humans first and computers second. Computers can
| read the crappiest, most spaghettified code on the planet as
| long as it is syntacticly and functionality correct. Humans
| cannot, and their time costs several orders of magnitude more.
| delecti wrote:
| For me it's got to be learning some basic command line tools, and
| how to link them. One commonly used operational tool on my team
| is a simple chain of command line commands (curl, into jq, back
| into curl), and it has saved every member of my team countless
| hours of manually clicking buttons in a third-party web-ui. I
| threw it together in 5 minutes.
| danabrams wrote:
| Understanding the system of work in which you exist. Your
| company, your industry, your society.
|
| 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.
| noduerme wrote:
| Isn't the measure of that how much you get paid?
|
| If we assume you get paid $100 to make a button, I think OP's
| question is how to do that in 1 minute instead of 10 minutes.
| You know, so you have 9 extra minutes to watch youtube.
| danabrams wrote:
| The measure of how much value YOU generate for YOURSELF is
| how much you get paid.
|
| But generally, if you can generate a lot of value for the
| company, and demonstrate it, you will go far, and you will
| make much more money, especially if you can do it
| consistently and threaten to leave.
|
| Doing a jira ticket in 20 minutes instead of 2 hours, then
| spending the extra time watching youtube is fine, but how
| about becoming a manager, making 3x as much money, and
| spending 100% of your time watching youtube? Or better yet,
| watching movies in first class on the plane to the "strategic
| conference" in Hawaii.
| noduerme wrote:
| ;) heh.
|
| I can't relate because I've been freelance since 2001, but
| I do remember how much I hated the fact that my bosses
| bought new cars and took trips and took credit for my work
| while I was making $8.50/hr as a junior webmonkey. Guess I
| never saw the future in it. _But_ if I knew I 'd be flying
| first class now, maybe I would reconsider...
|
| In all seriousness, though, aren't people mostly paid what
| they're worth if they know how to demand it?
| otoburb wrote:
| >> _In all seriousness, though, aren 't people mostly
| paid what they're worth if they know how to demand it?_
|
| Yes, but the caveat is that most people don't know how to
| calculate their worth relative to the organization(s)
| they work with/for, and of those that do, the majority
| probably don't know how to negotiate/ask.
| beaconstudios wrote:
| > In all seriousness, though, aren't people mostly paid
| what they're worth if they know how to demand it?
|
| No - effectively all employees are paid less than their
| value to the company. This is where profit comes from.
| [deleted]
___________________________________________________________________
(page generated 2022-03-30 23:01 UTC) |