We are getting into the details of what is copying. If you can find someone with the identical voice who is a different person, is that all it takes? It seems to me the intention was to hire someone who sounded like the character from Her.
I went the other way and pivoted to being a dev when I turned 30. Before that I was in IT which basically meant fixing computers, which meant replacing power supplies and reinstalling Windows.
How did you break through? I've been trying to land a dev job for years but I keep getting passed on due to my heavy IT infra experience and they seem to think I'm overqualified, but in the wrong area. "Hm, why would you want an entry level dev job? It says here you have years of director level experience." I don't want to be in management but they seem to think I'm a flight risk or something.
Similar background, what worked for me was taking a somewhat unglamorous job that was as close to dev as I could find, in an industry that has a hard time attracting talent. In my case, I got a job as an admin/developer for a hospital's ServiceNow instance. I spent as much time as possible on the dev side of the job, then moved to dev full time for a year, then transfered internally to a developer role in the engineering department.
The hospital bit was key for me both in getting started, and maybe more importantly for the transfer from admin that scripted to developer in engineering. They have a huge demand for people who can program, but the pay is "goodish" at best, and the culture is...slow and crufty. Lots of room for growth, and they are more willing to accept non traditional backgrounds. Best of luck.
I pivoted from tech consulting (logging user issues, basically) to dev by taking a contract programmer role. It was in a non-profit org that didn't really understand software, and I built them a prototype in my own time which got me in the door. Then I worked up to engineering manager, a move I would not recommend (back to logging user issues).
Look for backend style work. Your infra experience is an asset, look towards cloud infra and all the programming stuff around that. Dev work ain't no panacea, there's a lot of CRUD work, and even when you get to do cool stuff like build data warehouses it's still just fancy CRUD work.
Dumb down your resume. Mine's currently missing an entire decade, leaving out entire details for the things that are there, etc.
If you keep running into an "employment experience" issue but you actually do know what you are doing, a dev I know used to be a maths teacher, created an LLC with a dumb name and created a consulting website. Then after a couple of years of no leads, simply listed themselves as an employee at said LLC on their resume. They are also one of the best devs I've ever had the pleasure of working with.
I had a somewhat similar experience moving from science to data science/engineering. A PhD meant I fit your description of "overqualified, but in the wrong area". Those days were hard and hugely demoralising. Until my résumé landed on the desk of someone who'd made the same career change, I was SOL.
I had to start again from the bottom. I found a 2 person startup consultancy that needed someone who knew computers but also could program a bit. I had been coding since I was a kid but knew nothing about it besides how to make little stuff. You need to imagine you are just starting your career again out of school (with no degree). I worked at that startup for over 3 years, then moved to a slightly bigger company that was even more focused on software and on good practices. Then jumped again a few years later, and finally made it to working at Microsoft where I have been for 2+ years. So it was a nearly 7 year journey before I was doing software at the place I wanted to end up.
Learn Ops. All operations in decent orgs these days _is_ software engineering, and a large swath of those who do it lack deep infra experience and rely a lot on trial and error in more complicated configurations.
Thanks to Sharepoint and Windows 11 things seem to deal less and less with drive letters. Mac users already have no drive letters. It all seems to blur and look alike.
Users don’t care that much, as long as they can do their job on the magic screen thingy without any problems. They HATE all the problems. They do not care about Mac or Android or Microsoft or Linux. They want to put data in things and machines so other users take that data and put it in their things and machines.
So make all the connections super stable, give excellent user support (which is not telling users to read man pages), let them connect to all their devices seamlessly and instantly and you will have your century of the Linux.
So much of it is completely unnecessary breaking changes too. A good example is the config file, out of the box they no longer support using `.eslintrc.*` (you can still get this behavior back with a config flag), you're now expected to use `eslint.config.js` instead. So in short, they're just making every single project out there that relies on ESLint go and either add a flag or rename one file — for what?
I'm not really seeing the argument, right now they're also pushing unnecessary work onto everyone who uses `.eslintr.js` which already is a js config file. Yes, it is a small amount of work to fix, but it still means you have to go and read the changes and figure out what the breaking changes are to begin with.
My qualm isn't really that it's hard to fix it once you know it's broken, or to find it in the release notes, but rather that this change doesn't need to be breaking to begin with. I can understand changing the docs and changing the default value, I can also understand dropping the plaintext config file, but why also break every project that currently relies on `.eslintrc.js`? From the tooling side, it's one extra line to stat two file names rather than one.
It’s a hard thing to balance. One thing first, I’m not sure the config is (or always will be) the same across versions, so it could be that eslintrc configs can’t be parsed in the first place, even if they’re js.
I can also understand wanting to move entirely to one standard. Leaving remains of the old one, with over a decade of documentation about it all over the internet, could make remaining functioning artifacts harder to debug when searched for. For example, someone is using eslint v11 and they search something like “eslintrc.js not registering”, and heaps of the results they get pertain to irrelevant versions of the software. Sure there are ways around this for the searcher (and something like copilot will surely catch these things quickly), but that doesn’t mean eslint’s GitHub issues wouldn’t risk being inundated with this type of problem for years.
I agree with you too, though. I imagine they felt they’d given it enough time and warning, and they’d prefer to keep their internals cleaner and more consistent, and their documentation simpler as well. Weird gotchas like “oh also this really old type of file we don’t technically support can still be loaded” are a bad noise when people want signals.
E.g., faster and simpler file access from removing tree-walking for multiple `.eslintrc.*`; better defaults in line with modern JavaScript; better compatibility with modules and Node.js's own file loading.
(And I suspect there's an element of "As long as we're having to introduce a breaking change, let's make it explicitly breaking by also changing the filename.")
Err... isn't the whole point of a big number release to introduce big, breaking changes? All major projects have breaking changes... but only the nice ones do us the courtesy of saving breaking changes for major release milestones
Not saying every project can do it, but some of these ESLint changes seem rather unnecessary.
React always adds warnings in 1 major release and then removes in the following major release, meaning if you have no warnings you can just upgrade without fear, which is quite a nice way of doing it.
> So in short, they're just making every single project out there that relies on ESLint go and either add a flag or rename one file
Not every project. Many people switched to the .js format a long time ago since it’s more powerful. I understand the inconvenience though, especially since I don’t remember them deprecating the rc format when they introduced the js one.
Updated a React Native project a month ago through 3 major versions and updating ESLint (to v8) was the most annoying and tedious part. I've just updated the main package and not the rules because something was broken constantly and it was spouting errors nonstop. Dealing with ESLint is the definition of "not fun". Ironic because it should make my life easier.
https://dustinbrett.com/