For me setting up my dev tools was always part of orienting myself. It’s foreshadowing of what’s to come. Oh we’re installing this tool I bet that means yada yada.
If you want to install and set up Office, Chrome, a virus scanner, backup and VPN software then more power to ya. Having dev tools automated might not save all that much time overall.
That’s when they hire “yes-code” people to simplify their setup.
Snark aside though; do whatever floats your boat. Tools that allow non technical folks to start building useful products is still a win (even if I personally wouldn’t make that tradeoff).
Obligatory quote from that XKCD about automating things. Remember, most of these tools simply automate what you already do. If you don't spend much time performing certain things, you don't need the tool. The cargo cult of "I should use Packer to create my Vagrant boxes, so I can have dev/prod parity" only works to a point. Instead, look at where you spend lots of time, and then look for tools that automate that task.
Personally, I try to be pretty conservative with tools that I start relying on. I know by painful experience that some tools get abandoned, some change drastically, making it impossible to upgrade, and some just turn out to be very buggy and horrible once you start putting them through their paces. In lots of cases, it's better to be critical than permissive when it comes to your infrastructure (and that's what these tools are aimed at). In almost all cases, your edge is in knowing the tools you use, and knowing about other tools. It's not in knowing all and using everything under the sun.
This is productivity porn for programmers. While obviously these tools are deep and powerful, there is also a learning curve and experimenting wether you can adapt your workflow to them or vice versa. Next year we will have another 5 shiny command line tools, and so on.
My point being: only replace your weapons of choice once you are confident you are using them to their full potential and you identify needs that these known tools wont solve.
I’ve never sold dev tools, but this resonates with me as a buyer.
The other thing that I want to know, where I’ve had remorse in the past, is how much effort it’s going to be to integrate the tool with my current processes and workflows. I don’t want to change my processes, and I don’t want to find that I cannot get that wow because I’m using this homebuilt process over here or this specific third party tool over there or because we’re migrating to cloud in 3 months.
As a guy who writes software who doesn't write much html (because web is hard) I can't help but feel that having all these devtools built in by default, while nice for developers, seems silly to have wasting space on the hard drives of millions of users. They will never use the source viewers, live editing, page heuristics, etc, and it reeks of feature creep to me, and one product trying to be too many things at once.
The "once configured" is the problem for me. I would rather be working on the task, not the tool. And at this point in my life, my "tinkering" time is done in other areas.
This take is correct IMO - it's only worth building a tool if it saves you more time than it takes to develop. This is why Retool exists - if building/changing an admin tool takes about as much time as assembling a Keynote presentation, then the economics of using custom software to solve small problems start to work out in your favor.
why? i seem to have managed many such projects without such tools before and after 6 years ago... i'm not sure what benefit they would realistically have.
I've heard a similar commentary about Microsoft millionaires founding startups and having absolutely no clue how hard logistics is.
Because if you have a guy showing up on Monday, there's an office already set up and ready for him by close of business the previous Thursday.
I like to solve problems at work with openly available tools. I will often file patches or add comments to tickets or StackOverflow so that when I am at a new place all of that information is still documented somewhere I can get at it.
In house tools are a siren's call. And the fact of the matter is that if you wrote a tool because you had a need for it before anyone else did, that eventually others will want it too, and there will absolutely come a day when their version eclipses yours. You have to have a way to run your systems without tying them that tightly to a specific tool. And you have to accept that the 4 years of utility you got out of that tool was money well spent and you can retire it now with a clean conscience.
I have the feeling that most developers these days suffer from too much tooling in every area. And would be 2 to 10 times more productive without it.
Most friends that I watch doing their deployment would be way more productive by simply using rsync for file changes and raw database queries when the DB needs a change.
Same for me, a custom configured environment has often become yet one more thing that can break and needs maintenance. I make sure I have basic emacs keybindings but that’s almost it.
In my experience, the people that spend most time on customizing the tools have mostly been junior developers.
Though if you asked me on productivity tools we’d have an interesting discussion. I guess it’s just a matter of focus.
Furthermore, there are very diminishing returns in obsessing about your tools themselves. Sometimes, tinkering with your emacs config (or whatever) is just procrastinating.
For whatever automation a new tool gives you, you get new maintenance on that tool, other languages will want a tool that gives those features, systems running older versions will want upgrades in order to support the tool, 20% time will be spent on getting it running immaculately on Emacs, security researchers will find bugs in the tool so everyone has to fix, patch and upgrade, web sites for showing off the tool need designing and hosting, support forums have to be staffed, blogs have to be written, some novel use of the tool requires integration with various other systems, enterprise asks for a powerbi version that can integrate with oracle (it ends up being 5x slower, but does lead to more jobs in maintenance and meetings), more research is produced etc. etc.
Well, the expectations in terms of delay and scope grow to match the ease you gain by having better tools.
Sure 30 years ago you could waste hours on a trivial problem because you didn't have Google and Stackoverflow, but your boss was happy when you spent a month on something you would have a week to do nowadays.
If you want to install and set up Office, Chrome, a virus scanner, backup and VPN software then more power to ya. Having dev tools automated might not save all that much time overall.
reply