4 ms·

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 everyd

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 5y ago
> 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.
- eternityforest 5y ago
  It's true, you can't discourage it too much in people's free time, because a lot of them seem to love tinkering and that's the whole reason they started, but we also don't need to make it an industry standard expectation that everyone writes a parser generator at some point. Innovation beyond the random toys level is really hard. At best most things can become a proof of concept that inspires some corporate dev. Unless you really enjoy that kind of random garage project, it seems reasonable to just leave it to the people who do. There's a lot to learn in the world of boring unoriginal software. You learn how to take a task and do it with high level building blocks, and the minimum possible custom code. You're essentially designing a "Plugin" for a system made of the entire current software ecosystem, treating dozens of unrelated apps in a workflow as if they were a suite, taking into account the fact that you know people will want to look at data in Excel or control your thing with a MIDI keyboard. I've done lots of random side projects, but I'm not sure I learned all that much, other than to really appreciate the value of the off the shelf thing I later replaced them with. It's hard to objectively measure that kind of general learning, so maybe I am better off for them, but I also think I picked up some bad NIH type habits that I later had to unlearn, and caused some of my biggest tech related regrets. Then again, if I was in a field where we actually did real "Paradigm shift" type stuff, I'd probably feel differently. But even then I'd imagine learning Haskell and linear algebra might be a better use of time, rather than implementing a window manager.
xmodinfinity 5y ago
I agree, it’s not usually a good use of time to reinvent the wheel, but what if there are unacceptable (e.g.) security risks with all the existing solutions? Then “just right” means “adequately addresses realistic security risks, where core fails to do so.” Developers correctly focus on building things, these aren’t often solid from a security perspective, and sometimes that matters. Abstracted, my point is that your point is correct in one domain, and there’s probably always another, peripheral domain where that’s not true: underlying assumptions mean whole ecosystems are flawed when used for a specific purpose: security, high availability, parallelism, etc
- eternityforest 5y ago
  I think developers almost always do address security, it's just that security is insanely hard and most aren't dedicating security specialists. CVEs are almost always patching in hours to days on mainstream software, it's rare to just leave doors open, the difference seems to just be in how much people tolerate things that might possibly have an unknown risk, just because they are big or use dependencies, or because they allow a user to do something that might be a bad idea in some contexts(Like have an unencrypted hard drive). If you need extreme security, or some other specialist requirement, you're total right, mainstream ecosystems can be unsuitable.
jll29 5y ago
I would say either a field requires calculus or not. If yes, then you need to know it, full stop. And if it doesn't you don't need it, full stop. It's not the case that if you need it, it makes you 10x more productive. All architects needs architecture knowledge; you can't just say "knowing architecture makes architects 10x more productive".
- eternityforest 5y ago
  If the field is just general programming then you could say calculus is a 10x career boost, because you can take on calculus related projects as opposed to being limited to mathless stuff.

monksy 5y ago

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

eternityforest 5y ago
It's true, you can't discourage it too much in people's free time, because a lot of them seem to love tinkering and that's the whole reason they started, but we also don't need to make it an industry standard expectation that everyone writes a parser generator at some point. Innovation beyond the random toys level is really hard. At best most things can become a proof of concept that inspires some corporate dev. Unless you really enjoy that kind of random garage project, it seems reasonable to just leave it to the people who do. There's a lot to learn in the world of boring unoriginal software. You learn how to take a task and do it with high level building blocks, and the minimum possible custom code. You're essentially designing a "Plugin" for a system made of the entire current software ecosystem, treating dozens of unrelated apps in a workflow as if they were a suite, taking into account the fact that you know people will want to look at data in Excel or control your thing with a MIDI keyboard. I've done lots of random side projects, but I'm not sure I learned all that much, other than to really appreciate the value of the off the shelf thing I later replaced them with. It's hard to objectively measure that kind of general learning, so maybe I am better off for them, but I also think I picked up some bad NIH type habits that I later had to unlearn, and caused some of my biggest tech related regrets. Then again, if I was in a field where we actually did real "Paradigm shift" type stuff, I'd probably feel differently. But even then I'd imagine learning Haskell and linear algebra might be a better use of time, rather than implementing a window manager.

xmodinfinity 5y ago

I agree, it’s not usually a good use of time to reinvent the wheel, but what if there are unacceptable (e.g.) security risks with all the existing solutions? Then “just right” means “adequately addresses realistic security risks, where core fails to do so.” Developers correctly focus on building things, these aren’t often solid from a security perspective, and sometimes that matters. Abstracted, my point is that your point is correct in one domain, and there’s probably always another, peripheral domain where that’s not true: underlying assumptions mean whole ecosystems are flawed when used for a specific purpose: security, high availability, parallelism, etc

eternityforest 5y ago
I think developers almost always do address security, it's just that security is insanely hard and most aren't dedicating security specialists. CVEs are almost always patching in hours to days on mainstream software, it's rare to just leave doors open, the difference seems to just be in how much people tolerate things that might possibly have an unknown risk, just because they are big or use dependencies, or because they allow a user to do something that might be a bad idea in some contexts(Like have an unencrypted hard drive). If you need extreme security, or some other specialist requirement, you're total right, mainstream ecosystems can be unsuitable.

jll29 5y ago

I would say either a field requires calculus or not. If yes, then you need to know it, full stop. And if it doesn't you don't need it, full stop. It's not the case that if you need it, it makes you 10x more productive. All architects needs architecture knowledge; you can't just say "knowing architecture makes architects 10x more productive".

eternityforest 5y ago
If the field is just general programming then you could say calculus is a 10x career boost, because you can take on calculus related projects as opposed to being limited to mathless stuff.