> Isn't it amazing that someone could do something for 100 hours and not think about obvious improvements, and not even wonder if they've been setup?
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."
> Taking the time to master your tools is a COMPOUNDING benefit
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.
When those tools’ lifecycle is 2 years at most fewer people are willing invest the effort to master them and instead learn on a need basis. If there was a guaranteed lifecycle the benefits would indeed compound and pay off handsomely.
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.
I'd argue that Angular is just a framework and the tool is whatever you use to hammer your angular code together. Your text editor/IDE of choice will probably outlast your use of Angular and therefore OP would be suggesting it is worth the time learning how to maximize your effectiveness with the IDE.
The way I see frameworks is as tools in themselves, but I do see your point, you're probably technically right. But the example doesn't diminish the idea. The ever changing software landscape makes it hard to master things that come and go.
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.
If you asked 10 years ago why I am going backwards by learning Scheme and Lisp today I would answer it is pointing forwards instead. Forwards is definitely a subjective to me.
This reads pointlessly pedantic to me. You're throwing out examples of things that might actually be important, but most people probably don't think is that important. This is very different from things which people know are important and do frequently, but don't care to learn how to do it properly.
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.
But that is precisely the point. You're complaining that people don't meet some arbitrary level of expertise in their tooling, which is your personal metric.
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.
That is a separate point. The point I was saying was not relevant was "no matter how smart you are, youve got finite bandwidth and a finite time to spend it." This implies that people are not improving on things because of finite capacity to do so, which is sometimes true, but really just an edge case.
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 agree that people have finite bandwidth but we are talking about people investing in skills that are useful for the primary function of their job. It’s the first thing to consider if you want to improve your productivity at work.
I'm a very enthusiastic worker most of the time, but I have never been rewarded for improving my own productivity at work. Usually improving my own productivity is because of a certain stubborn and personal distaste for intent that can't be backed by action.
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.
Maybe you've never been extrinsically rewarded, but surely you've derived some kind of intrinsic reward for improving your productivity? A sense of pride or joy? :)
Resentment and contempt for the system that does not reward such self improvement which, by the same virtue, means those who do not self improve are the ones rewarded with not expending the effort to improve. So finding a new job is usually the order of the day.
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.
This reads to me like someone telling you that you could shave 30 minutes off your commute, and then justifying that you don't have time to look at a map. Plenty of things are very easy to learn with large payoffs; some of which are so basic and so necessary that it is criminally negligible to proceed with such vast incompetence for someone in the trade.
E.g. doctors spending no time to learn about new drugs and prescribing them.
This is a useful reminder; thank you. It's true that my original comment was made in the context of having virtually all of my needs already met, and being far along the path to self-actualization.
I don’t put a very high priority on my job. As long as I stay better than average that’s enough for me. I am not trying to make top tier income as the median income for an experienced developer is plenty to hit diminishing returns.
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.
Pain in your spine, constant headaches or lung problems would also hurt work productivity. Focusing on first-order problems could lead to gains both at work and home.
In a similar vein, I try to hack my lifestyle for possible upgrades. Anything I can change that will improve the experience for my family and myself is game.
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.
Thank you for this comment. I often have trouble articulating why I would rather not put any time into certain things, and this "limited bandwidth" argument is exactly the right one.
> 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?
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.
I spent most of my life as a techie in complete agreement with you. My best friend and I are "optimizers" - we type fast, we have macros and tools and utilities that make us more productive.
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 )
In engineering disciplines, there's a a difference between optimizing the tools you use in the process of "putting out" what you've already essentially engineered; and multiplying your productivity at engineering things in the first place.
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?
There is a balance to be had between skill acquisition and skill exploitation. Your team members endlessly optimizing are probably not exploiting enough. Their productivity could improve spending less time optimizing endlessly and actually exploiting some of those skills to do real work. Your senior experts who can't type would probably still benefit from learning how to actually type, because it'll be something they can exploit a lot.
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.)
This is an excellent point! I personally subscribe to Rich Hickey's "hammock driven development" approach to problem solving, and I think how we approach problems, like our tools, is something that can be optimized with practice :)
It takes a certain discipline to do that. Not everyone has that discipline, and not everyone cares about being the '10x engineer'. Especially not when they work a 9-5 job which pays the same regardless of being a 1x or 10x.
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.
> Especially not when they work a 9-5 job which pays the same regardless of being a 1x or 10x.
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.
That was exactly my point: not everyone cares about that.
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.
Before assigning failure to other people’s beliefs, you should examine your own assumptions. Not everyone views life success through the lens of career.
I agree with the sibling comment, that "10x"ness is only weakly related to tool usage. I've done some of my best work in ludicrously awful environments because that was the only feasible as a result of a whole stack of previous tech choices made by other people, usually for valid-looking business reasons.
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.
Except that the benefit is not yours, but your employer's. Let's take a look at the frontend landscape where every framework lasts 2-3 years at most. By the time you master something, you can start it over. And most employer does not support learning on the job. So you have to learn it in your spare time. The benefit is the employer's, the cost is yours. I can understand when people say f*ck it and they simply protest by not playing by their employers' rules. If they get the salary without investing time, they also reap some benefit at least.
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."