To the contrary, it gets easier. Many of the new things are older things I've seen in different contexts. Some of the new things are a welcome relief from shortcomings if old tools.
I can't speak for others, but I'm currently going through a very painful time tools-wise. We've switched to a new workflow with all new tools and there are several objective ways in which they make my life harder. There was, of course, the learning curve that any new tool has in the first few weeks/months. It's been 2 years, and I'm still getting slowed down every damn day by these horrible tools. It's not that I haven't learned them, it's that they are objectively worse than what we had before. (And what we had before had a number of issues, too.) I will fervently let others know of the potential pitfalls of the tools I'm forced to use by my employer. It may make me sound like I'm being religious, but really, I'm just trying to warn others what they're getting themselves into.
As with most things there's a balance. I've found if I try to learn one or two new features or shortcuts every couple weeks with the tools I use extensively, eventually I do get a sharp axe.
Typing speed is nice but not an important metric I don't think. It's like someone speeding past you on the road only for you to see them at the next red light. Other things will slow you down like code review or needing to wait until a set time to deploy. Also things like copilot and advanced auto-completion are making it less relevant.
There are different use cases that demand different tools. For personal projects the simpler tools from before were totally fine but now they are longer accessible. I think that's a loss.
On the flipside, I see a lot of tools pushed that are more complicated, less flexible, and far buggier than the old tools. And then inevitably in a few years they're deprecated in favour of something newer and shinier and the old tools are still perfectly fine (e.g. Make).
You don't ever lose productivity or knowledge on a tool when a new one comes out though. A new thing that people like becomes popular and people start using it, old one becomes less used but it doesn't dissapear.
You only really "switch" to a new tool if that's what you like the most, not because that's what people like now.
Or the opposite: after 15+ years with one tool, you'll master it to a level that is very hard to give up. All the annoyances by now have workarounds, all the problems are accounted for, all the monitoring and hardening is in place (and for openbsd in particular: all the code has been audited and reviewed several times). Why lose all that in name of some abstract productivity gain that will likely be offset by years of pain getting up to speed with the new tool?
Anyone not working alone, not working on his own projects only, will end up having to use tools created ages ago, but refined gradually, how ever clunky the usage feels along the usage journey.
I guess most hobbyist would be pretty content with 2006-era solidworks if it were readily available: look at how Eagle was used without updates for years, as a shareware.
I expect that most of the new features cater to professionnals, except for basic maintenance and a few simple features. The workload necessary to match hobbyist expectations is nowhere near a single full-time dev.
But these products are monstrously complicated for wat they are, in part due to the company looking for ways to extract value at every point it can (forcing cloud mechanisms: they cost money for sure, but are mostly used for locking customers in and as an excuse to require a permanent connection). And for every possible revenue stream, it seems...
I'd say this is a good thing if it makes FLOSS alternatives a bit more attractive. Hobbyists are usually hard to switch to alternatives once they find something "good enough". In turn, they tend to produce lots of documentation, tutorials, and training material. Just look at the number of people you can ask for help with, say, plotting a graph in Microsoft Excel vs doing it in LaTeX.
I think the comment still stands though, if you can't master the new tools including for reasons like the company not giving you time to learn them then maybe you (the company) should stick to the old tools.
Doesn't apply if the new tools are forced by management, but often it's the developers driving new tech.
The fundamental trade-off for any new tool is that devs have finite capacity to learn new tools. That's why we like to learn a few tools really well and then reuse the heck out of them. However, we are open to warning-stories - that if you do it the naive way, at some point you'll get bitten by X, Y and Z. And even then we might not acre until we actually get bitten!
For those who have never used these tools, they are very good but have an _extremely_ steep learning curve. If you just want to make stuff but see this software as a roadblock, you can still accomplish a lot with good old pen-and-paper.
Don't feel that way. Very few tools like this stand the test of time.
I avoid using new tools in production. I wait a few years first to see if they last - after all I'm going to have to support the system for years, I don't want the tools to be the weak spot.
Also, if you're using a tool that was built more than a year ago, you risk ridicule. Definitely a lot more work figuring out what the hottest new tools are than in traditional or backend development.
The problem is how much time do you HAVE to sink into just to learn a tool? If you have a tool with the same functionality and requires less time sink, then the previous tool is obsolete and should be tossed away.
When you switch to something different, you see that a bunch of your problems and annoyances simply went away. You may not see yet the new problems and annoyances that you acquired. You're in the honeymoon phase.
With time, you will see the problems with the new language/tool/environment. Is it better than what you had before? Maybe, maybe not. But you are not in a position to accurately evaluate it while you're in the honeymoon phase.
On the getting old part, there's definitely a point where someone has enough bagage thay most additional tools are solving a problem they already worked around or solved a different way. For someone new to the field, this tool is on the same footing as the rest and could fit them better.
As an aside, the part I like the most about our field is the ability for a single or two devs to build themselves the tools they exactly need, and potentially share it to the community with low friction.
reply