I just had body work done on my Model Y and Hertz had only [a few at that] Model 3s. They rented me a Kia EV6 and I didn't like it. But can one modify the settings on a Hertz Tesla rental?
In March I was in Savannah GA and rented an M3. I was there last month and they had none available. I rented a M3LR late spring from SNA, but they were out and gave me a MYLR. I think there is an EV setting in the app, I don't remember. But location and availability affect what you can get quite often. I always try to rent a Tesla every time I rent a car (often) for the experience, research, and just plain fun. (fart mode ON) I can't always get one, or even the one I want. I saw a couple large rental locations that had a MS in the luxury category. But the price...
“Lazy coders”? Do you work in the software industry developing human-safety rated systems or national defense systems?
I worked in government IT for 38 years, interacting with other government offices and private industry for decades. The safety related teams are very small and very specialized. National defense teams are smaller and compartmentalized for national security reasons. No one coder knows the whole picture. The three letter agencies prefer it that way.
Yeah we hired one off Turo, was great, even a decent day rate and it was fairly new too. They normally have heaps, especially in CA. Overall I petered using Turo, let alone the pricing for Teslas seemed much better, even in Texas.
I was concerned about range, damage to the tires, and just breaking down, but mostly range. We were staying near Oakhurst and there was a supercharger there so after the first day we knew that we were only using 100 miles of range from Oakhurst->Yosemite->Oakhurst and the range issue went away. It snowed and rained for a day of the trip and I decided not to drive down to Yosemite that day because I just didn't know how the MY would drive on a slippery, possibly icy road, and I didn't want to find out just then. In the end, like you, I found that the MY handled everything very well. That trip was the springboard for a longer trip to Denver in the winter and that introduced new range-anxiety issues but that is another story.
My degree is in this field. Much of my time with the government was working on "Safety of Life" system designs. Your assumption is not correct, coders are not lazy. The issue is not with lazy or not, but with whether or not you can think of every single possibility, and plan for it. This is why FSD was so time consuming and difficult when they were trying to write code for every possible scenario. This is why AI is a far better solution, because it learns "situations" not "rules". I had a "decision maker" in a system design meeting with me one day. He had commented that I was wrong for trusting the motivation of the team. I tried, to no avail, to explain how incredible the team was, and that their goal was, in fact, to make the end user happy. He didn't believe me. Later that day, the software team was giving their presentation. I leaned over and said "watch this". I then gave them a real goofy idea that they wouldn't understand why we would want this feature, but I explained we really needed it. And I mean, to the user, it was about as goofy and stupid an idea as ever existed. For the next 5 minutes we watched the team wrestle with how to implement this and make it the best idea since sliced bread. When I saw the decision maker start to laugh at how hard they were working on this harebrained feature, I fess'd up and explained it was a joke. They all laughed, and then said; "we kinda like it and want to do it!" I said no, please don't, please no no no no no. The decision maker later said "I see why you trust them."
Ok, I'll bite. There is probably no difference in a software developers mind between "lazy coders" and "lazy coding". It is an insult, and incorrect, either way. There are certainly variations across developers, huge variations, but lazy is not one of them. By and large they are very passionate about what they do and take it very seriously. Here is the bite. The problem with software always traces back to management. Always. Someone lying to some customer about what software can do. Someone forcing a milestone that is impossible but no one listened to engineering. Someone forcing a deadline that engineering said couldn't be met. Someone releasing software that engineering said wasn't ready. The list goes on. If you want an argument, just say something about developers, or about managers, and you will get it. These are completely different camps with completely different values and focus, and they rarely see eye to eye. I was a technical specialist, architect, chief architect, CTO, research scientist, etc. for more years than I care to admit to. I do not trust people in sales or management. I had to deal with them, but it was always difficult. You can point your finger at engineering all you want but you will never be right.
"IT" is a term used for various kinds of technical work, but usually it is procuring and installing commercially available data processing systems or supporting installed systems, rather than designing or writing functional software for new systems or products.
I managed large projects of this type for 25 years. Your statement isn't true for the teams on those projects or typical for large projects in that industry. Our large project teams typically had over 100 and as many as 300 engineers, about one third to half software developers (coders), all with free access at work to all design requirements, development code and supporting data - there was no compartmenting within the project, project teams or across related projects. All coders' work was reviewed in detail - every line of code - by their team peers and team leader, usually about 5 to 10 people in total. Test engineers and systems engineers performed detailed code reviews for any wrong/unusual test outcomes. There were no "lazy" coders - at least not for very long.
With regards to your first question: yes to all of the above.
