4 ms·

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

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 )

piercebot 7y ago
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 :)
jerf 7y ago
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.)
derefr 7y ago
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?

piercebot 7y ago

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 :)

jerf 7y ago

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

derefr 7y ago

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?