this is problematic, and the problem is made obvious when you take this fact to its natural conclusion.
are you juggling credit cards to simultaneously maximize the benefits of opening new cards with promotional offers, limiting your interest rates, and maximizing your credit score?
have you investigated the air quality of your working and living spaces? do you know the optimal concentrations of O2 and CO2? do you have plants around you that provide other benefits besides air quality? do you even know what those compounding benefits are?
what about your spinal posture? do you know about wrist shoulder hip and knee angles? do you know how this impacts bloodflow and neuromuscular activation? maybe you just run and/or stretch for 30 minutes a day and call it good enough?
> I have co-workers like this: people who don't bother to learn
no matter how smart you are, youve got finite bandwidth and a finite time to spend it. everyone picks most things they dont bother to learn.
For example I worked on an Angular project and invested a bit of time to learn the framework and certain libraries. I completed the project and it was successful, but my new projects aren’t to be done in angular anymore and I can’t apply all this knowledge, at least for the time being. Am I glad I learned this? Sure. But, this theme has repeated so much in my career that I am reluctant to jump onto a new thing. Instead I doubled down on F# and started learning scheme.
Plus, Angular comes with a bunch of tools in itself. If you take a break for a while you'll have to re-learn the new ways of doing things a few versions later. This is not only taxing, but makes one reluctant whether to invest the time in it or not, and the learning process is a bit encumbered by the idea that it all may go to waste soon-ish. The reality was that even older tools proved to be useful to me as I had to pick up and maintain older projects and having learned that it made it easier. But this may vary from case to case.
Moreover, when something new comes out, everybody is hyping it and when we start using it in my work place, my gut feeling tells me to wait for v2 or v3 or so, such that I don't have to deal with the many confusing changes that take place in the few iterations. But I do that just because I had some bad experience in the past. Others break their teeth with the same frustration that I had. They too may build their reluctance as I did.
Plenty of people choose not to learn their tools, and would not choose to do so even if time were unconstrained. The inability of people to maximally use all tools available to them is a separate issue, and not an especially important one.
Not everyone shares your concerns. They may well be concentrating on posture, because _that is a very important thing to concentrate on_ if one has certain issues. Or they may just not consider their job taking them 5 more minutes to perform to be a problem, and they'd rather think about what they're building in their garage, or their kids.
"Why doesn't everyone care about the things that I care about" is a very good, very difficult, question to try to answer for yourself.
You're saying people don't need to care about X, which is true. However, if you choose to spend 10 hours building a pile of blocks, every day, rather than spending 10 minutes learning how to turn on the BLOCKMASTER 9000, you're just being obstinate. Hyperbole and arguments to your personal choice of block building aesthetic aside, there's a large class of problem for which the effort required to both improve one's capabilities and execute the task is much lower than the effort require to execute the task to begin. No matter how much you care about your kids, and how little you care about building blocks, if you must build that tower, it is beneficial to learn how to use the BLOCKMASTER 9000.
Pursuing the latest and greatest tooling mastery for incremental gains usually doesn't fall into this category. You don't need to pursue improvement endlessly. But say, people who refuse to learn how to use a debugger, but spend a great deal of time debugging? People who only share code over email while the team tells them to use git? People who only use global variables in painfully uncomfortable circumstances? If you're coming to work and refuse to invest in such things... it's fully plausible that you are a 0x or -1x programmer. Same for almost any other domain of work.
You don't need to care about anything. The reason you improve is because you want to be better. If you don't want to be better, and are currently bad, there's at least going to be a large social reason why you may want to change.
I can see why people should improve their productivity at work in the abstract, but I have to admit there isn't much tangible in it for them. They will work 8 hour days however productive they are. Less productive workers are if anything more likely to clock out on time.
Doing "just enough" to get paid is the optimal course for the majority of jobs.
Finding jobs that extrinsicly reward continuous improvement is hard, probably because rewarding continuous improvement is hard to do - measuring, expectations, reasonable demands, etc. Are not easy.
the number of things that affect your job performance are endless and it is arbitrary where you choose to stop improving. not only is it arbitrary where you draw the line, its arbitrary that you chose to optimize your job in the first place. these things are non-self-evident choices based on personal and societal feelings rooted in first-principle thinking about the meaning of existence.
"invest in your exponential job growth" glosses over some pretty significant life choices that are more important to recognize than saving 30 minutes a day at the office.
E.g. doctors spending no time to learn about new drugs and prescribing them.
Simply staying focused on work at work, solving whatever the current issues are, and going home is fine. Languages, tools, and best practices are constantly evolving, staying current is already a significant treadmill adding mastery of everything is an endless time sink.
For example, I installed a personal weather system on the house so we could dress appropriately without needing to check outside first. Or, bought a Keurig coffee maker to reduce the time and effort required to make the morning joe.
I call these hacks, "lifestyle upgrades."
I mean, I'm not personally doing that, because that's a bunch of manual work; but if I found about an API that I could use to automate doing that, I'd probably budget myself 30-or-so man-hours to trying to set something like that up on top of such an API.
> have you investigated the air quality of your working and living spaces?
Yes; I even bought a CO2 meter. I was feeling ill whenever I closed the windows or when there was no wind, and I wanted to eliminate obvious potential causes. Toxic mold was another possible cause.
As a tech lead and then as a technical manager though... my team members who spend (sometimes endless;) time optimizing their tools and typing fast, are not necessarily more productive than the senior experienced experts who type slowly, with two fingers, and OMG I can't even stand to watch them resize a window, if they bother... but tend to sit back, ponder, and then slowly, excruciatingly type effective, efficient, working code that safely satisfies clients' requirements.
It took me years if not a decade to see beyond their slowness with tools, and notice the overall effectiveness of their output.
(This is not to say there aren't tons of people who are slow with both, of course :P )
A better text editor might make you faster at typing; but that only matters if your work was "typing-speed bound." Programmers generally aren't bound by typing speed; they're either bound by identifier lookups (figuring out what function or variable they need to use here, possibly using a library documentation or language reference, or checking elsewhere in the codebase); or they're bound by the speed at which they make decisions about the architectural design of what they're programming.
Things that solve those two problems—IDEs with auto-complete and inline documentation display, in the former case; and "convention over configuration" frameworks and uniform syntax normalization linters, in the latter case—can have much greater effects on productivity than just speeding up how fast you can input the code.
But even beyond that, I find the most powerful productivity boosters in engineering are the ones that entirely obviate a particular thinking task. What is a compiler but a tool for avoiding the thinking task of figuring out how your pseudocode properly translates into machine code? You could certainly go without one—but we all agree that that'd be ridiculous to choose to do, when you don't have to, right?
I'm 41 now. I still don't mind learning new skills and do it fairly often. But I am getting increasingly crabby about having to learn an entire new skill that I'm not going to clearly be able to exploit enough to make up for learning it, e.g., I get tossed somebody's old project X written in $YESTERDAY'S_FAD_FRAMEWORK and now I have to go learn a dead framework just to see what's going on. I'm not going to get to exploit that enough to make up for the cost of learning it.
When I was younger, I worried more about sampling a lot of things rather than whether I'd get to exploit any given one of them that much. I don't regret it. I think it was the right choice at the time. But as you get older I do think you want to be a bit more selective, if for no other reason than you need to exploit those skills at some point or the acquisition costs are just a waste.
(I'm doing a personal project right now that involves some front-end stuff. I've been doing website development since 1997; clearly JS has changed a lot over the years. I decided to just go with straight JS, rather than spending a lot of time learning a new framework, because I don't anticipate having enough front-end work to do to exploit the time it would take to learn a new JS framework, and while it seems to have stabilized a bit lately (not literally turning over every year anymore), they still seem to be a bit frothy compared to everything else. Meanwhile, modern JS basically has jQuery built in, and template literals can be used to set up an escape-safe client-side template system in about 5 lines of pure JS. So, basically, due to the constraints on this project, I've chosen to learn the handful of things I haven't used (knew about the "fat arrow" syntax and template literals for a while, never had a chance to use them in a detailed way) and then exploit my existing skills, rather than spend a lot of time learning a new framework. Even if I could hypothetically do the actual work faster, learn+use time >> exploit time. And learning more about pure JS has an extremely high probability of being exploitable in the future; even now, learning "React" or one of the other handful of clear winners has only a much lower probability because I could still be dropped onto a project that uses something else.)
I have been working for my own businesses for about 8 years now. I learned to value my time, so any improvement in efficiency is welcome. But sometimes you just need to get the job done and not invest time upfront in improving a process. It's always a trade-off in time.
This is a failure of forethought on their part. It's true that their _current_ job might not pay more for that knowledge, but it absolutely pays off in their career and during interviews as they develop their professional network and people begin to recognize them as a source of in-depth knowledge.
For many (most?) people the main factor in life is happiness. If you like your job, and it pays good enough, then why invest all the work into a future job that may pay better?
Also, there are many factors that come into play during interviews. How well you are able to combine complex Vim commands to shave 10 seconds of a particular task is probably very, very low down the list of competences the interviewer is looking for.
Not that I would blame anyone for settling into a life where you CRUD from 8:30 to 5:00, then go home and enjoy your life. There are many jobs out there that are more interesting and better paying with the exact same quality of life trade-offs. If anything, I've found that more challenging workplaces hire people who are more interesting to be around.
It usually doesn't fare well for you.
VS2005 inside an XP VM? To build WinCE 4? In 2015? No sane person would choose that environment today, but it had been a valid choice in the mid-2000s and the hardware was still working, so I rolled up my sleeves and fixed the bugs. Customer was satisfied and we all got paid.
The only person I've ever worked with who could concievably be a 100x engineer did some of his best work on paper. But then he was a heavy-caliber mathematician.
I have co-workers like this: people who don't bother to learn the tools of* their trade and waste dozens of minutes every day.
Taking the time to master your tools is a COMPOUNDING benefit and, at the risk of sounding inflammatory, is the type of activity that creates "skill gaps" between regular and "10x engineers."