It's a bit disturbing how much people in this industry are focused on tooling.
It's a biproduct IMO of working on boring problems or supporting morally ambiguous corps. That thing that you need to keep yourself busy and keep going in the rat race.
It's a biproduct IMO of working on boring problems or supporting morally ambiguous corps. That thing that you need to keep yourself busy and keep going in the rat race.
Unfortunately, this creates a whole host of long-term issues. For example, it create the situation where complex tools have their fervent advocates, while simple tools do not (because they don't provide job security). It also create an incentive to start a sort of complexity Ponzi scheme: you add tools to manage tools to manage other tools and so on. Each new layer reinforces the job security of people working on the previous one.
It's important to keep in mind that stuff like Java 8 and C are also tools, susceptible to the same problem.
The first time I seen a job title of "Kubernetes Keeper" I died a little inside. It's not that these jobs didn't exist before, and sysadmin is a perfectly good role which I personally don't have the skills or desire to do, but we keep pretending that we've build a way of replacing some of the effort which just moves it around a little.
Why? Because the tooling is what ends up being used every day in so many ways. A minor improvement in tooling can lead to drastically better quality of life. It's like getting a fancy but expensive office chair - no, I don't need it, but my back will thank me at the end of every day.
The catch here is that this applies across the board. For example, many new languages try to sell you on a better language design that is more convenient - and it may well be, but it doesn't matter when there's no good IDE, no good debugger, no smooth deployment story etc. PL and API design is important, but it's not more important than everything else. The languages that are the best for "quality of coding" are the ones that balance it all, and usually they have to dial some advanced aspects down to enable other areas to work. Or at least move slower with language evolution, so that new fancy features get full support across the board. It's no coincidence that languages like Java and C# - which lag behind on bleeding edge language features - have the best code completion and refactoring in the industry.
That strikes me as such an odd critique, and I can't make it work for any other industry; you certainly wouldn't apply it to something like dentistry, or oil refinery, or plumbing.
If I went in for a root canal and the dentist said "We're gonna kick it old school today, sniff this rag of ether, I'm bored with all these tools!" I would grab the nearest scalpel and slowly back away. But yeah, if you're working on boring problems the tools won't do much to mask it.
A software developer's job is to create software. Almost like an author. Some more than others. At the end of the day, no matter how good your pen is, it will not write a great book for you.
Most software created itself is a tool, a tool which typically leverages the speed of computing to perform a task hundreds, thousands, or millions of times faster than a human could. Think making a bank transfer - I can do this in 5 seconds on my phone now, which would take me over an hour to physically head into a branch and do it in person, and even then we are relying on computing power at the branch itself.
Why would we, as software developers, act like we aren't going to use tools ourselves? For productivity, for a more pleasant (or even just less frustrating) experience?
I initially was a vim + printf debugging stalwart, but having been in a Java environment grew to realise the immense power of an IDE like IntelliJ and how beneficial it is. You can detect errors in the code almost immediately, so spelling mistakes and missed semicolons aren't a thing. You can fix them in a fraction of a second. If I write a function that could be written in a clearer way, or I'm not sure what type I should write for a variable, it will suggest it immediately and I can follow that suggestion with a press of a key.
Yes, it cannot write great software for me. But if you have worked with software where there is no autocompletion, poor debugging and profiling tools, then I find it hard to believe that you don't think that the addition of these tool can help you write at the least MORE software, and probably even BETTER software.
It is not the same as writing a novel, as much as I would like to romanticise that it is. It is about organising and coordinating components to work together, and for this tools can be a tremendous help.
Yes, tooling is a huge deal in day-to-day life. When I think about drains on my time and productivity, I've never been too setback by having to deal with a "for" loop instead of something more monadic. However, I HAVE spent days doing painful refactoring work, that could have been done in minutes with a few right-clicks in an IDE. Build tools and CI/CD pipelines, profiling and troubleshooting tools, etc etc etc.
I can't believe that any of this stuff requires defending oneself from having "sold out to The Man".
I think your examples betray your inexperience with what you're criticizing. A for loop isn't somehow corresponding to "something monadic" and safe refactoring (actual refactoring, not just renaming things, though that's obviously trivial as well) is extremely easy to do and produces great results in languages like Haskell, OCaml, etc.. Primarily this is because moving grouped things is nowhere near as sensitive as in a language like Java or the like.
But yeah, you can right-click rename all day, for sure... Never mind that other languages can let you safely re-architect the very bones of the solution with almost zero fear of coming out on the other side in failure.
Java has great tools, but let's not bring up refactoring as a real strength. It's kid's level stuff in comparison to languages that allow you to do that and more without tooling.
Haskell et al. have crap tooling and that has real consequences, but refactoring isn't one of the casualties at all. They're still better at refactoring, re-architecting and repurposing than any of the big name languages.
At least bring up debugging, system interaction or something.
There's every reason to think that software engineers and system administrators do their job much more quickly and correctly when they have the support of rich editor support, understandable compiler errors, usable interactive debuggers, profilers, dependency management that won't set your hair on fire, etc. For whatever reason, it seems like businesses often aren't interested or successful in creating these products, so frustrated developers step in to create the tools they dream of in their own work after too many days spent refactoring with regex.
It's possible that people might be drawn to tooling projects because of some kind of internalized revulsion in response to the social impact of their employer, but I think you'd expect to see developers working on tooling regardless of whether or not this is the case because of how a lot of development tooling just wouldn't exist if it weren't for individual FOSS contributors' efforts.