Hacker News new | past | comments | ask | show | jobs | submit login

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.




Tooling is great for job security. You can be absolutely shit at writing code and designing systems, yet make yourself indispensable because you know Framework X and most other people don't. All it takes is time to memorize trivia of the framework and a bit of trial-and-error to figure out how to work around framework's pitfalls.

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.


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

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.


Yeah it's much better to list a dozen tools/frameworks that you must be expert at than just making it clear about the current requirements.


The more experience I have, the more I appreciate good tooling.

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.


I use great software with subpar tooling all day long, and it is not a good feeling. It feels like sawing of your own arm to feed your hungry customers.


It's a bit disturbing how much people in this industry are focused on tooling.

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.


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

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.


I see your point, but I think you can't ignore the power of tools.

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.


Eh, I'm not really seeing the analogy to an author, whose final product is the words on the page, so in that you are right that the kind of typewriter wont help much. But a developer's code isn't the final product, it' an input to an output, and good tooling can potentially make a mediocre dev better (within limits), by catching compile time bugs, by enforcing constraints, maybe, by exposing functionality (autocomplete), enabling profilers or debuggers, etc...


Geeze... the contemporary Internet, man. Ten years ago, we flamed each other over our personal preferences, and others' views were "stupid". Today, we flame on about our personal preferences, and others are implied to be "immoral". Both exercises are admittedly immature, but at the least the former was more cheeky and not so up its own posterior.

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


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

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.


I think the focus on tooling is more because: (1) developers understand it, since they use it full-time; (2) they're motivated to write it, since it will make their life easier. Understanding business needs takes work, and writing software you will never use is uninspiring.


I'm not sure I disagree with you, but I think the counterpoint is worth stating: that a compiler is the beginning, not the end, of a productive software engineering toolkit, and that there is no software stack that has achieved perfect tooling—quite on the contrary, I think it might be fair to say that most languages lack a great deal of tooling.

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.


It's also a product of ambitious orgs. One way to out compete a competitor with more resources is to have better development, ops, and release tooling. It's not a silver bullet but it can make a large positive impact when done properly.


Not sure what specifics you mean by tooling but in the context of build/deploying tooling, I really enjoyed learning about it. Beyong the knowledge to be able to develop at both front/backend, setting up the CI/CD pipeline and seeing it all work seamlessly, is useful. Understanding it end-to-end is quite satisfying too.


It seems more likely that an industry that makes and uses software tools would have a stronger than average appreciation for software tools.


Or maybe we don't understand the field at a level where we can objectively say which tool is right for a particular problem domain.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: