4 ms·

This is a bit of a departure from the question you asked, but I'm always amazed how much people tend to hyper-tune their dev environments, when in reality, most

by bbarn 6y ago

This is a bit of a departure from the question you asked, but I'm always amazed how much people tend to hyper-tune their dev environments, when in reality, most of my time is spent thinking how not to write code. I get just as much work done on a completely vanilla macbook with VS code installed on it as my editor-obsessed peers with obsessively optimized setups can. How much actual code are you writing? I'd be really concerned with myself if I am putting out so much code that I need to be concerned with my text input speed.

SimonPStevens 6y ago
I spent quite as few years as a contractor and I quickly discovered the best way to be effective was to learn how to be effective with everything in the default settings. At every new place I went I could just jump right in. No need for any time spent fiddling with settings or tweaking and installing pluggins. Although a slight counterpoint is that I also used to have my git settings file stored in a github gist so I could just grab my latest one and every new environment would have the same set of aliases I was used to.
jmchuster 6y ago
Your tooling isn't just about writing code, it's also about reading, analysis, debugging, research. You think about the code, have an idea, need to look up how something works, think some more, have this constant back and forth. Optimizing your environment minimizes the friction, and allows you to immediately get answers as soon as you have a thought about something, so you don't lose your train of thought. You also want to be able to run quick experiments, same idea, get the answer to a question you're thinking about as fast as you think of it. And then once you actually know what you want to do, don't you want to have as smooth an experience executing your fait accompli? The primary focus is minimizing friction, and speed is just the observable side effect. And then of course you can't ignore the natural human enjoyment that comes from customizing things to exactly how you like them.
ExpiredLink 6y ago
IIRC, the average developer output is 10 lines of code per day.
jonnypotty 6y ago
For the most part I agree with you, but it got to the point at work where I could regularly type faster than eclipse (usually some shitty background tasks messing things up but still) this actually slowed me down as well as making me angry, which is probably the way to make me least productive and ranty. Like, how can this be the case that in 2020 I can type faster than a computer displays text in a professional IDE. Jesus christ. Oooo calm. Using sublime text now and just using eclipse for the debugger. Calm. Calm.
joatmon-snoo 6y ago
It isn't so much the total LOC that I write (and delete) in the process of making a change so much as it is the friction and mental overhead of the change. The more I can focus on making the semantic change that I care about, the better. Admittedly my vim setup doesn't even have YCM because I don't care enough to do it. But there are other minor things (swapping : and ; in control mode, mapping jk as <ESC>) that I've done that I hate working without now.
fragmede 6y ago
Lines of code are the wrong metric and turning dev environments isn't going to get you to type faster. If you're happy with VS code on OS X with zero customization, more power to you :) The "obsessively optimized setup" isn't the results of a single week-long binge, which may lessen how obsessive that seems. A setting here or there, after a few years, results in a comfortable dev environment. The comfort of this environment extends the ability to make code happen. Coding is, as you've noted, rarely about typing speed. The larger a program gets, the longer the files get, the more spread out across different files and directories it gets. (Consider yourself very lucky if the programs you work on can fit entirely inside your working memory! Others have bigger programs to work on, or differently shaped working memory) Being able to find "that thing you saw that one time" is paramount. How you find it, is an entirely personal choice, but being able to find it, quickly, and without breaking out of flow state, is the goal. Whether it's by learning VS code (which has a expansive collection of settings and extensions to "obsessively" tune), or by installing ag. (And yes, for the obsessive, the merits of ag vs ripgrep/other is a fun rabbit hole to fall into.) Still, between from when you start coding, to when you share the diff with anybody, coding is an intensely private activity (that some choose to share with others). As such, whatever works. If trying to open a file while traversing a tree view is distracting enough that it takes couple tries, and you don't mind taking a couple times, great. If I've got my dev env setup to so I can open the file from the command line where I've already got the filename, that's cool too. If I want to learn VS code's command bar syntax so I can open it from there, that also works. And if you can open that file first try, while simultaneously navigating a stream of code, good for you. End of the day, comparing "just as much work done" with two independent variables (the configuration, and the person using the setup) and no control, is as foolish as managers trying to quantify programmer output by counting lines of code.
therealdrag0 6y ago
I donno. I use IntelliJ and when I pair-program with someone who knows how to use its features vs someone who treats it like a basic text-editor/compiler, is night and day difference. If I am 'riding shotgun' and say stuff like "look up that definition" or "find all the implementations of that method" or "go to ABC" and they just look at me like a deer in the headlights, or start clicking through the file tree, or do "find text in project", then they are going WAY slower than they could be going. So if "obsessively optimized" includes learning your tools, then it returns rewards.

by bbarn 6y ago

SimonPStevens 6y ago

I spent quite as few years as a contractor and I quickly discovered the best way to be effective was to learn how to be effective with everything in the default settings. At every new place I went I could just jump right in. No need for any time spent fiddling with settings or tweaking and installing pluggins. Although a slight counterpoint is that I also used to have my git settings file stored in a github gist so I could just grab my latest one and every new environment would have the same set of aliases I was used to.

jmchuster 6y ago

Your tooling isn't just about writing code, it's also about reading, analysis, debugging, research. You think about the code, have an idea, need to look up how something works, think some more, have this constant back and forth. Optimizing your environment minimizes the friction, and allows you to immediately get answers as soon as you have a thought about something, so you don't lose your train of thought. You also want to be able to run quick experiments, same idea, get the answer to a question you're thinking about as fast as you think of it. And then once you actually know what you want to do, don't you want to have as smooth an experience executing your fait accompli? The primary focus is minimizing friction, and speed is just the observable side effect. And then of course you can't ignore the natural human enjoyment that comes from customizing things to exactly how you like them.

ExpiredLink 6y ago

IIRC, the average developer output is 10 lines of code per day.

jonnypotty 6y ago

For the most part I agree with you, but it got to the point at work where I could regularly type faster than eclipse (usually some shitty background tasks messing things up but still) this actually slowed me down as well as making me angry, which is probably the way to make me least productive and ranty. Like, how can this be the case that in 2020 I can type faster than a computer displays text in a professional IDE. Jesus christ. Oooo calm. Using sublime text now and just using eclipse for the debugger. Calm. Calm.

joatmon-snoo 6y ago

It isn't so much the total LOC that I write (and delete) in the process of making a change so much as it is the friction and mental overhead of the change. The more I can focus on making the semantic change that I care about, the better. Admittedly my vim setup doesn't even have YCM because I don't care enough to do it. But there are other minor things (swapping : and ; in control mode, mapping jk as <ESC>) that I've done that I hate working without now.

fragmede 6y ago

Lines of code are the wrong metric and turning dev environments isn't going to get you to type faster. If you're happy with VS code on OS X with zero customization, more power to you :) The "obsessively optimized setup" isn't the results of a single week-long binge, which may lessen how obsessive that seems. A setting here or there, after a few years, results in a comfortable dev environment. The comfort of this environment extends the ability to make code happen. Coding is, as you've noted, rarely about typing speed. The larger a program gets, the longer the files get, the more spread out across different files and directories it gets. (Consider yourself very lucky if the programs you work on can fit entirely inside your working memory! Others have bigger programs to work on, or differently shaped working memory) Being able to find "that thing you saw that one time" is paramount. How you find it, is an entirely personal choice, but being able to find it, quickly, and without breaking out of flow state, is the goal. Whether it's by learning VS code (which has a expansive collection of settings and extensions to "obsessively" tune), or by installing ag. (And yes, for the obsessive, the merits of ag vs ripgrep/other is a fun rabbit hole to fall into.) Still, between from when you start coding, to when you share the diff with anybody, coding is an intensely private activity (that some choose to share with others). As such, whatever works. If trying to open a file while traversing a tree view is distracting enough that it takes couple tries, and you don't mind taking a couple times, great. If I've got my dev env setup to so I can open the file from the command line where I've already got the filename, that's cool too. If I want to learn VS code's command bar syntax so I can open it from there, that also works. And if you can open that file first try, while simultaneously navigating a stream of code, good for you. End of the day, comparing "just as much work done" with two independent variables (the configuration, and the person using the setup) and no control, is as foolish as managers trying to quantify programmer output by counting lines of code.

therealdrag0 6y ago

I donno. I use IntelliJ and when I pair-program with someone who knows how to use its features vs someone who treats it like a basic text-editor/compiler, is night and day difference. If I am 'riding shotgun' and say stuff like "look up that definition" or "find all the implementations of that method" or "go to ABC" and they just look at me like a deer in the headlights, or start clicking through the file tree, or do "find text in project", then they are going WAY slower than they could be going. So if "obsessively optimized" includes learning your tools, then it returns rewards.