You absolutely can. We do it all the time by paying others to do simple jobs for us. When I pay someone else to mow my lawn I am buying time. If I didn't mind spending time mowing the lawn I would just do it myself.
While I understand the significance, I find these nuances exhausting. As a senior experienced engineer I am also supposed to provide guidance and show some authority, especially in design meetings and code reviews. Being too humble comes off as lacking knowledge and confidence and people question (not ask) whether you really are a senior engineer. But the moment you try to show some strong opinions and authority, people get put off.
It depends on why you want to switch. If you want to switch because you love the new line of work then go for it but understand that you will start as junior and most likely make less money than you do currently for several years. But if you like your new line of work then you will get good at it and make more money in a few years. If you want to switch for any other reason, think hard about it. It may not be worth it. Often grass seems greener on the other side but when you get into the weeds, you realize it's all, well, weeds. (I fantasize about becoming physicist, rancher etc. but I am gonna stick to writing CRUD apps. Those jobs are way harder and pay way less.)
Static methods are a pain for unit testing though. I have started avoiding them for that reason alone. For stateless objects, you can always have a singleton and invoke all the methods on that object giving effectively static behavior without the baggage.
Syncing passwords is a bad idea and is really a legacy case for applications that don't support SSO. The correct way to do provisioning + auth is to use SCIM just for provisioning users and groups (with password based auth disabled in the downstream app) and use SSO (SAML / OIDC) from Okta to actually do the auth for the user. Also configure your SCIM API to never taken in the password if Okta sends it and never return it in case some user decides to set the password on the downstream app anyway.
Of course the one I wrote few months ago! When I re-read it today I realize how good I was at foreseeing all the problems that would eventually arise. The code has descriptive comments that explain not just what the code is doing but what it is supposed to do. I was very impressed with not just 100% line coverage but also complete branch coverage by rock solid unit tests. Sorry can't share the link because code is proprietary.
Companies give tiny raises to loyal employees. If hiring is so expensive why don't companies make effort to retain employees by giving them raises that make their compensation at least at par with that of the new hires.
Off-topic - I highly recommend watching the show "The Man in the Highcastle" on Amazon. It depicts a future in which Germany and Japan won World War II.
On Linux you can just use "SimpleScreenRecorder". It allows recording video of a single window (with audio from mic). I use it at work to create demos. My video demos are better than most others' because the video does not contain the whole screen (unlike many other demos) and my videos are accompanied by audio narration so demo can be watched independently later. Mac users often ask me how I create my demo videos.
It's not about being territorial, it's about ownership. I assume you work for a small company. At Big Co. there are thousands of services and APIs. You can't give default permissions to everybody to call every API. That would be a giant security lapse. Other teams let you modify their code but only after they thoroughly understand what you need to modify and what is it that that you are tying to do. They own the code and run in production. So it makes sense for them to critically evaluate whether you should be allowed to do what you are trying to do. All of that takes time and hence multi-day blocker.
>> Any blockers that do occur are dealt with at the time, leaving nothing unaddressed by the time the next day rolls around.
You must not be working with micro-services then. It can take a week just to get permission to call another team's API or a month to get an external vendor to respond to some critical question. Now obviously I am not sitting idle while blocked, but assuming that blocker will be removed by next morning seems quite unrealistic and rarely happens in my world.
You must not have kids / spouse then. You can get a call from school / daycare any time that your kid is sick or hurt and needs to be picked up immediately. Or your spouse can call you that their car broke down and (s)he needs help. I want to be notified immediately of such situations.
Daily rotation seems too frequent to me. Sometimes you need 2-3 days to really deep dive and fix the core issue after the alarm has gone silent. Also, with daily rotation it is tempting to wait it out and punt the problem to the next person.
Job provides Windows or Mac but I prefer to use Linux. So I installed Linux in VM and do all the work in it. VMWare Workstation is rock solid with great performance. I boot Windows, then Linux in VMWare Workstation, go full screen and never look at Windows again for the whole day.
Seriously. You would think smart people who write such software would understand the importance of naming things properly and uniquely. Imagine trying to google to troubleshoot any "Text Editor" issues. You will get a bunch of unrelated stuff.
There is no shortage of opportunities to go into management. Good managers are hard to come by. So any time you can demonstrate that you have the skills and willingness to be a manager, most employers would welcome that. You can try to find management roles in other smaller companies who might be more open to your lack of management experience. Please don't mind but it seems to me that you are being jealous of your former colleague. It seems you were OK being an IC for 25 years and now that you have seen a peer succeed in management role you hate being an IC. Do not base your happiness on what others have. Know what makes you happy and try to get that regardless of what other people are getting / have gotten. If it helps, I have been an IC for 18 years and plan to be until I retire because I don't like management and I am quite happy with that. I know I'll never make executive salaries but I am ok with that. I optimize for happiness and less stress instead of money.
The problem with this approach is that any real task requires a lot of internal knowledge (functional and technical) of the system which an outside candidate will not have. The pairing employee will have lots of it though and it is likely the candidate will appear inadequate even if the employee is aware of the internal knowledge difference. It is not straightforward to be productive on an alien code base from the get go.
Most tech companies now do around 4-5 interviews. It has been like that for at least 7-8 years (probably more) but I just found out that not all companies are like that. After being subjected to these demeaning Leetcoding interviews I went through a refreshingly pleasant experience. It was an interview with just one person. They gave me a technical open-ended problem and two weeks time. After two weeks I had to do a presentation to them how I would solve that problem. Not much more was required. I could choose to do as little or as much as I'd like. I did have to spend around 30 hours researching that problem as it was an unfamiliar problem space for me. The presentation was just 1 hour session with the hiring manager where he and I had a technical discussion about my solution. No more interviews of any kind (not even behavioral). I had an offer three days later. I thanked the manager for his meaningful and humane interview process. I can't believe I have wasted hundreds of hours doing LeetCode when there are companies out there that treat candidates respectfully rather than code churning machines.
No job will be perfect. There will be some of what you described in most jobs. It is important to figure out what matters to you the most and optimize for that while looking for job. For example - I am currently in the process of quitting my FAANG job for slightly less compensation mostly because I am tired of countless meetings, HR trainings and glacial pace at which software development works at large corporations because of the sheer number of approvals and dependencies required. I am going to smaller company to do interesting work with hopefully less red tape and less meetings where I can build stuff rather than sit in meetings all day and rubber stamp a bunch of stuff. You can do something similar. Be upfront with the interviewing company about what matters to you and interview with companies that offer you that. Also, try not to tie your self worth and happiness to your job. If you have a good and happy life outside of work, you will start to see your job as a means that makes that outside work life possible and it won't be as frustrating.
You haven't described what is it that you hate about your jobs so much. Bureaucracy? Office politics? Type of work you get assigned? Meetings? Tech debt? Obsolete tech stack? Hard to suggest something without knowing.
Lack of reliable service from plumbers, HVAC, appliance repair people. There are many people available but the quality and consistency of service is highly variable and chances of getting ripped off are high if you don't do your due diligence. I wish there was more standardization in these services where I don't have to worry about getting ripped off and can expect a decent quality of service without spending too much time on looking up vendors, reading reviews etc. If I want get a leaky washer fixed I don't want to spend my entire weekend to try to figure out if it can be DIY or not. I should just be able to call a reliable service, pay a reasonable price and get if fixed.
>> it is hard for us tech oriented people to build a great social life.
This stereotype needs to die. For some reason, tech people have a superiority complex about their intelligence and inferiority complex about their social intelligence (neither of which is true from what I have observed). Tech people are normal people.