I've noticed those kinds of posts. I mean, actual work can be hard, and work situations can vary a lot depending on the work environment, but, at least in my case, that's completely different to "programming". I wish I had more time for "programming"... I enjoy it a lot, I've always enjoyed it, you can do so many interesting things in a creative kind of way. So many different complex things to understand... If I didn't have to work, I'd have a lot of spare time and I'd probably invest it in, well, programming. There are several source codes I'd like to understand better and analyze, just for intelectual curiosity. I'd have the time to study the source code of several operating systems, implementations of programming languages, and tools that I really would like to know more deeply. I'd have more time to review the source code of videogames, demos, and other interesting programs, and create my own just for fun. I would have more time to create interpreters, read old documents on programming theory, contribute to open source initiatives, learn new programming languages... Programming can be fun. It's a pity to see people burned out. In any case, it's also true that there's more to life than this. :) Try surfing, pottery, yoga, horticulture, real-life drawing or calligraphy instead!
I think that experience is good. My personal opinion: I don't think you should hide it.
Perhaps try to ensure that the resume is attractive and focused on the relevant areas that will help you. Leave less detail in older jobs or less relevant positions?...
Add things like certifications, projects, or other things that could make you stand out. With these added, years of experience shouldn't be a problem IMHO.
This is just my opinion of course. It's not a great job market right now, so it could be that.
I've talked with hiring managers from a FAANG that told me that they just skim the resumes - they care more about performance during the actual interview. So hopefully this gives you some hope. Good luck in your job search.
Sonar doesn't seem to really work in my limited experience. It adds a lot of of time to builds, at least in the cases I've seen, while there are alternate linters or code quality tools capable of doing the same at a fraction of the time. Build times and development speed matter!... They matter a lot. You need a quick feedback loop.
I use Sonar all the time, but not during build. It runs live while I'm editing a file. I've not noticed any slowdown at all, and it's certainly a quick feedback loop (it runs when I save the file).
I've found the majority of its suggestions helpful, and the ones that are not I simply ignore.
It adds about 2 minutes to our gitlab pipelines but the major issue with it is when organizations decide failures should prevent merging code to master or even deploying to a QA environment.
That's the real time sink - figuring out how to get past it. It's a lot more than 2 minutes, sometimes even days if it's something you can't work around and have to go through the red tape if your team isn't empowered to take charge of your own pipelines.
I should have mentioned that I was referring actually to the continuous integration pipeline, not actually to the build itself. Not very well explained on my side. I've never used it locally myself. I don't really know why the CI setups that were using Sonar I've seen in the past were that slow, to be honest.
That's why software development teams are bigger in Chicago than in Rome or Naples. The size of the crust is bigger in Chicago-style pizzas, whereas italian pizza has a thinner crust.
The blog post series author then did an online playground [1] that lets you create systemd examples and experiment with systemd in the browser. It's really interesting.
