4 ms·

Being a programmer is not about configuring your development environment. It never has been. I know a relatively accomplished programmer whose preferred devel

by kragen 1y ago

Being a programmer is not about configuring your development environment. It never has been. I know a relatively accomplished programmer whose preferred development environment is Unix with the ex editor, and plenty of beginners whose whizbang IDEs completely fail to compensate for their lack of understanding. That's not to say that tooling doesn't matter at all. Just that, historically, it's been a relatively minor factor. Maybe LLMs have changed that, or are about to. An athlete with shoes for a different sport might run 5% slower. In a winner-takes-all competitive environment, that's fatal; a sprinter that ran 5% slower than the gold medalist is just another loser. Most programmers, however, win by collaboration, and on a relatively smooth fitness landscape, not a winner-takes-all spike. Even in winner-takes-all regions like startups, failure always results from bigger errors. I think nobody has ever said, "My startup would have succeeded if we'd used Dvorak keyboards instead of QWERTY", or vim instead of VSCode, or vice versa. It's always things like feuding cofounders, loss of motivation, never finding product-market fit, etc.

deafpolygon 1y ago
Refreshing to see logic among the sea of your shell "bros".
smlavine 1y ago
Being a programmer is absolutely about knowing how to configure your development environment, though.
benreesman 1y ago
I find this line of argument really weird. Obviously mastering his tools is only one of many things required of a master craftsman, but the relentless pursuit of excellence in all dimensions of ones craft is the minimum possible criteria for ever attaining it, almost tautologically. It's like when people complain that leetcode is nothing like the job: yeah, it's a pretty bad test, but you're making a bad argument about that because CS knowledge is extremely relevant to the job, unless the job is assembly-line library composition. I've consulted for companies that had all their dev boxes on coder or something, and you get really good at vscode really fast or you don't have much luck. It's more than 5%, but even stipulating that it's 5%, whoa, 5 percent?! By installing a bunch of stuff off a list on GitHub and dropping some aliases in your bashrc or zshrc? in a few weeks you're five percent more effective? Anyone in any field from banking to bioinformatics would think you were joking or a scam artist if you offered them 5% more efficient outcomes at that price. Regarding OG editors like ed and ex and sam and stuff? I can absolutely believe that someone with a lifetime mastery of one of those tools could smoke a VSCode user, it's not at all obvious that VSCode is an upgrade to vim/etc. along any dimension other than low barrier to entry. ditto emacs which is about 1000x more powerful than vscode and the difference in library/extension ecosystem is not measured by size: the emacs one is identical to the vscode one with bottom 90% by quality sliced off the vscode one. And this stuff compounds, you get a bit better at the tools and you can read more code faster, read the right code faster, start moving the derivative of the derivative. It's also extremely non-obvious that collaboration at the kinds of scales and complexities that make exceptional skills or experience in it a top 3-5 core competency for people doing most software. Study after study going back to Fred Brooks and the Mythical Man Month have demonstrated that relatively small teams of people who get along very well coordinated by a relatively small number of highly technical managers who take the offload on the high-complexity cross-org collaboration is the golden ticket. It's the same reason computers have dedicated routing tables in the NIC and that those things talk to even bigger and more specialized machines that do all routing all day: you don't want to scale O(n^M) with the communication overhead. A hacker needs to work really well with their immediate team, and have a good dialog with a manager who is both technical (to understand the work) and who devotes a lot of energy to complex collaboration.
- imiric 1y ago
  > I can absolutely believe that someone with a lifetime mastery of one of those tools could smoke a VSCode user > And this stuff compounds, you get a bit better at the tools and you can read more code faster, read the right code faster, start moving the derivative of the derivative. I think you're overestimating how much tool choice impacts developer productivity. Yes, using good tools is important. Being comfortable with and knowing your way around your toolset will make your life easier. But it won't make you a better programmer. It won't "smoke" anyone else. It's not a competition. The time we spend reading and writing code is relatively minor compared to the time we spend thinking, designing, communicating, and collaborating with others. Reading and writing code is not the productivity bottleneck. It's understanding what you're reading, making a mental model of the system, and thinking about how to translate your thoughts into working code. The mechanical aspects of it are relatively insignificant. Especially nowadays when we have LLMs to automate those mechanical parts, for better or worse.
  - abletonlive 1y ago
    > It's not a competition For professionals it's absolutely a competition, but I'll also agree that engineers overvalue their environment setup.
  - skydhash 1y ago
    the activities with the highest ROI for me has been into better navigation and searching, then executing some commands on the result. The gap from thinking about doing something to having the thing done has been reduced greatly.
  - benreesman 1y ago
    If the time a programmer spends collaborating is more than the time they spend reading and writing code, they are optimizing for something other than software outcomes. And I appreciate that this is one of the lowest points for employment and advancement on the basis of demonstrated merit in the history of the business, maybe that's a smart play for people with certain priorities. Not my cup of tea. I'm trying to become the absolute best I can be every single day at the absolute limit of my abilities and hopefully just a little bit past them as measured yesterday. I think competence as criteria is going to make a big comeback fairly soon.
helloplanets 1y ago
All completely true. But I also wouldn't voluntarily run a marathon in tennis shoes.
iLemming 1y ago
> Being a programmer is not about configuring your development environment. You sure? Programming is an act of creation. Any [good] creative worker - artists, sculptors, novelists, potters, bakers, et al. would agree that being an artist means finding joy in refining your technique, investing in your tools, searching for new recipes, and experimenting. Being a programmer is not about achieving better productivity percentages. As far as I know, most of the best-known programmers have never participated in competitive programming challenges. Tooling may not matter to building a product, yet the product is built by programmers, and tooling is very much everything to them. Good programmers do invest in their tooling, not because it's a universal rule they have to follow or because it gives them a competitive edge. They do it simply because they enjoy the process. Though it's challenging to determine whether someone who loves exploring and refining their tools will excel in a specific team, one truth remains: those who don't engage with their tools likely aren't strong programmers, as they most likely fundamentally lack passion for programming itself.
- williamdclt 1y ago
  Meh. You can spend hundreds of hours honing your programming environment to get a slight edge on others, or you can learn a few basic (or not so basic) soft skills and blow most other engineers out of the water because they’re all obsessed with tech and don’t realise it’s not their bottleneck
  - iLemming 1y ago
    I'm sure you're not talking "soft skills vs. tools", that's a false dichotomy trap - great programmers often excel at both, and tooling mastery can itself develop problem-solving skills that transfer elsewhere. We are in a better world today specifically because of legendary programmers who invested heavily in tooling, and even created their own from scratch. Prof. Knuth spent decades perfecting typesetting, made TeX/LaTeX, METAFONT, and literate programming tools. Linus built Git and maintains his own terminal emulator and scuba diving log app among many other things. Ken Thompson is famous for building tools to build tools. Rob Pike created text editors, window systems and numerous Unix tools. Carmack built custom level editors and dev tools for each game engine he created, he is known for obsessing over development workflows. Can you name one person who "blows most other engineers out of the water" while not "being obsessed with tech", using nothing but "the soft skills"? I dunno about you, I, as a software developer, rather want to be like these guys, and I think any aspiring software dev would. I spent my last weekend figuring out my new WM. Not because I had to, forced to do it, offered money for it, or because I perceive it as my "bottleneck". I don't fetishize over my tools to "get a slight edge". I do it purely out of enjoyment for the process, nothing else. And I have watched many of my peers going through their career ladders. Sure, many of them might be perceived as more successful because while I was busy "sharpening my sword," they went into "the real world" and "touched grass" and "talked to people." Most of those are no longer doing engineering. If the goal is to "grow out" of being a software engineer, sure, then focus on the tooling might be overrated. That's not for me though; I'm happy where I am.
macspoofing 1y ago
>Being a programmer is not about configuring your development environment. I know what OP is referring to. Back in the day, a programmer was expected to have built their own toolbox of utility scripts, programs and configurations that would travel with them as they moved from project to project or company to company. This is akin a professional (craftsman, photographer, chef, electrician, etc.) bringing their own tools to a jobsite.
- kragen 1y ago
  Sure, I have ~/bin and a .emacs.d that I've been working on since last millennium, and various other tools I've written that I use regularly. It's certainly a handicap to work in an environment that's unfamiliar, especially for the first day or two. And sometimes spending five minutes automating something can save you five minutes a day. Making grep output clickable like in Emacs, as demonstrated here, is a good example of that. But, on the other hand, time spent on sharpening your tools is time not spent using them, or learning how to use them, and the sharpest tools won't cut in the hands of the dullest apprentice. And sometimes spending five hours automating something will save you five seconds a week. All the work I spent customizing window manager settings in the 90s, or improving my Perl development experience early this millennium, produced stuff I don't use now—except for the skills.
  - pantulis 1y ago
    > All the work I spent customizing window manager settings in the 90s, or improving my Perl development experience early this millennium, produced stuff I don't use now—except for the skills. If you enjoyed the process it was time well spent.

by kragen 1y ago

deafpolygon 1y ago

Refreshing to see logic among the sea of your shell "bros".

smlavine 1y ago

Being a programmer is absolutely about knowing how to configure your development environment, though.

benreesman 1y ago

I find this line of argument really weird. Obviously mastering his tools is only one of many things required of a master craftsman, but the relentless pursuit of excellence in all dimensions of ones craft is the minimum possible criteria for ever attaining it, almost tautologically. It's like when people complain that leetcode is nothing like the job: yeah, it's a pretty bad test, but you're making a bad argument about that because CS knowledge is extremely relevant to the job, unless the job is assembly-line library composition. I've consulted for companies that had all their dev boxes on coder or something, and you get really good at vscode really fast or you don't have much luck. It's more than 5%, but even stipulating that it's 5%, whoa, 5 percent?! By installing a bunch of stuff off a list on GitHub and dropping some aliases in your bashrc or zshrc? in a few weeks you're five percent more effective? Anyone in any field from banking to bioinformatics would think you were joking or a scam artist if you offered them 5% more efficient outcomes at that price. Regarding OG editors like ed and ex and sam and stuff? I can absolutely believe that someone with a lifetime mastery of one of those tools could smoke a VSCode user, it's not at all obvious that VSCode is an upgrade to vim/etc. along any dimension other than low barrier to entry. ditto emacs which is about 1000x more powerful than vscode and the difference in library/extension ecosystem is not measured by size: the emacs one is identical to the vscode one with bottom 90% by quality sliced off the vscode one. And this stuff compounds, you get a bit better at the tools and you can read more code faster, read the right code faster, start moving the derivative of the derivative. It's also extremely non-obvious that collaboration at the kinds of scales and complexities that make exceptional skills or experience in it a top 3-5 core competency for people doing most software. Study after study going back to Fred Brooks and the Mythical Man Month have demonstrated that relatively small teams of people who get along very well coordinated by a relatively small number of highly technical managers who take the offload on the high-complexity cross-org collaboration is the golden ticket. It's the same reason computers have dedicated routing tables in the NIC and that those things talk to even bigger and more specialized machines that do all routing all day: you don't want to scale O(n^M) with the communication overhead. A hacker needs to work really well with their immediate team, and have a good dialog with a manager who is both technical (to understand the work) and who devotes a lot of energy to complex collaboration.

imiric 1y ago
> I can absolutely believe that someone with a lifetime mastery of one of those tools could smoke a VSCode user > And this stuff compounds, you get a bit better at the tools and you can read more code faster, read the right code faster, start moving the derivative of the derivative. I think you're overestimating how much tool choice impacts developer productivity. Yes, using good tools is important. Being comfortable with and knowing your way around your toolset will make your life easier. But it won't make you a better programmer. It won't "smoke" anyone else. It's not a competition. The time we spend reading and writing code is relatively minor compared to the time we spend thinking, designing, communicating, and collaborating with others. Reading and writing code is not the productivity bottleneck. It's understanding what you're reading, making a mental model of the system, and thinking about how to translate your thoughts into working code. The mechanical aspects of it are relatively insignificant. Especially nowadays when we have LLMs to automate those mechanical parts, for better or worse.
- abletonlive 1y ago
  > It's not a competition For professionals it's absolutely a competition, but I'll also agree that engineers overvalue their environment setup.
- skydhash 1y ago
  the activities with the highest ROI for me has been into better navigation and searching, then executing some commands on the result. The gap from thinking about doing something to having the thing done has been reduced greatly.
- benreesman 1y ago
  If the time a programmer spends collaborating is more than the time they spend reading and writing code, they are optimizing for something other than software outcomes. And I appreciate that this is one of the lowest points for employment and advancement on the basis of demonstrated merit in the history of the business, maybe that's a smart play for people with certain priorities. Not my cup of tea. I'm trying to become the absolute best I can be every single day at the absolute limit of my abilities and hopefully just a little bit past them as measured yesterday. I think competence as criteria is going to make a big comeback fairly soon.

helloplanets 1y ago

All completely true. But I also wouldn't voluntarily run a marathon in tennis shoes.

iLemming 1y ago

> Being a programmer is not about configuring your development environment. You sure? Programming is an act of creation. Any [good] creative worker - artists, sculptors, novelists, potters, bakers, et al. would agree that being an artist means finding joy in refining your technique, investing in your tools, searching for new recipes, and experimenting. Being a programmer is not about achieving better productivity percentages. As far as I know, most of the best-known programmers have never participated in competitive programming challenges. Tooling may not matter to building a product, yet the product is built by programmers, and tooling is very much everything to them. Good programmers do invest in their tooling, not because it's a universal rule they have to follow or because it gives them a competitive edge. They do it simply because they enjoy the process. Though it's challenging to determine whether someone who loves exploring and refining their tools will excel in a specific team, one truth remains: those who don't engage with their tools likely aren't strong programmers, as they most likely fundamentally lack passion for programming itself.

williamdclt 1y ago
Meh. You can spend hundreds of hours honing your programming environment to get a slight edge on others, or you can learn a few basic (or not so basic) soft skills and blow most other engineers out of the water because they’re all obsessed with tech and don’t realise it’s not their bottleneck
- iLemming 1y ago
  I'm sure you're not talking "soft skills vs. tools", that's a false dichotomy trap - great programmers often excel at both, and tooling mastery can itself develop problem-solving skills that transfer elsewhere. We are in a better world today specifically because of legendary programmers who invested heavily in tooling, and even created their own from scratch. Prof. Knuth spent decades perfecting typesetting, made TeX/LaTeX, METAFONT, and literate programming tools. Linus built Git and maintains his own terminal emulator and scuba diving log app among many other things. Ken Thompson is famous for building tools to build tools. Rob Pike created text editors, window systems and numerous Unix tools. Carmack built custom level editors and dev tools for each game engine he created, he is known for obsessing over development workflows. Can you name one person who "blows most other engineers out of the water" while not "being obsessed with tech", using nothing but "the soft skills"? I dunno about you, I, as a software developer, rather want to be like these guys, and I think any aspiring software dev would. I spent my last weekend figuring out my new WM. Not because I had to, forced to do it, offered money for it, or because I perceive it as my "bottleneck". I don't fetishize over my tools to "get a slight edge". I do it purely out of enjoyment for the process, nothing else. And I have watched many of my peers going through their career ladders. Sure, many of them might be perceived as more successful because while I was busy "sharpening my sword," they went into "the real world" and "touched grass" and "talked to people." Most of those are no longer doing engineering. If the goal is to "grow out" of being a software engineer, sure, then focus on the tooling might be overrated. That's not for me though; I'm happy where I am.

macspoofing 1y ago

>Being a programmer is not about configuring your development environment. I know what OP is referring to. Back in the day, a programmer was expected to have built their own toolbox of utility scripts, programs and configurations that would travel with them as they moved from project to project or company to company. This is akin a professional (craftsman, photographer, chef, electrician, etc.) bringing their own tools to a jobsite.

kragen 1y ago
Sure, I have ~/bin and a .emacs.d that I've been working on since last millennium, and various other tools I've written that I use regularly. It's certainly a handicap to work in an environment that's unfamiliar, especially for the first day or two. And sometimes spending five minutes automating something can save you five minutes a day. Making grep output clickable like in Emacs, as demonstrated here, is a good example of that. But, on the other hand, time spent on sharpening your tools is time not spent using them, or learning how to use them, and the sharpest tools won't cut in the hands of the dullest apprentice. And sometimes spending five hours automating something will save you five seconds a week. All the work I spent customizing window manager settings in the 90s, or improving my Perl development experience early this millennium, produced stuff I don't use now—except for the skills.
- pantulis 1y ago
  > All the work I spent customizing window manager settings in the 90s, or improving my Perl development experience early this millennium, produced stuff I don't use now—except for the skills. If you enjoyed the process it was time well spent.