I've always been at a complete loss as to why and how we ended up with the archaic and clunky in-car systems we have today.
If you look at a smartphone from 5 years ago and a vehicle from 5 years ago, the capability of the phone is going to dwarf that of the in-car infotainment system. In all honestly, that 5 year old phone will likely out perform most of the infotainment systems in vehicles rolling off the assembly line right now. I don't even want to think what consumers are being charged on a line item basis for the outdated hardware in vehicles.
I still can't figure out why car companies are even attempting to build these systems themselves (besides profit, I suppose). Pretty much every American has a phone in their pocket that is much more capable than any infotainment system, and it specializes in the things we mainly want from an infotainment system (music, maps/gps, txt, calls).
Wouldn't it be so much better if vehicles just had a barebones screen in the dash with a connector for smartphones to power the system? You could even have the screen size mirror the resolution of the phone so it's just scaled up and rotated. Doesn't seem like much else would have to be done.
I'm sure I'm over simplifying things to some extent, but it still seems like a setup like this would be much easier to produce and much better to use than anything coming from car companies who are typically pretty terrible at software and UX design.
*of course not all vehicles are for Americans and not everyone has a smartphone.
> Wouldn't it be so much better if vehicles just had a barebones screen in the dash with a connector for smartphones to power the system? You could even have the screen size mirror the resolution of the phone so it's just scaled up and rotated. Doesn't seem like much else would have to be done.
Don't most new cars these days support Apple Carplay and Google Android Auto? That's basically what they are, (h264 video cast of the screen and a back channel for touch/button input)
My newest car is a lousy old 2015 model. I rented a small (2018?) SUV recently and it allowed some of the apps on my phone to take over the screen. I discovered this by accident because my goal was to have the phone connected to the USB for power while I ran the navigation app on it. It was great for navigating to a known destination. It was not so great for finding the nearest Starbucks.
My 2015 piece of junk requires a $500 p.a. subscription to receive traffic data for the navigation system. That is about 5 new Garmins a year, or 1.25 Pixel 3a's, a phone I don't own but have heard good things about.
That's all nice and well, as long as you are in cell tower range. I drove mine cross-country through places where you get 0 cell coverage. Having a navigation system that actually works is pretty nice.
That at the very least presumes that you remember to do that in advance. And that this functionality is actually available to do. Last time I tried, e.g. Google Maps would not download offline maps in some countries.
Slapping a tablet in place of the infotainment system is possible, but you make serious compromises on reliability. A tablet was never designed to sit in a 120 degree Fahrenheit car for days on end, Tesla has felt this issue acutely.
Most tutorial writers are terrible at what they are trying to teach. They may have a vague grasp of a concept, but that's about as far as it goes. If they were more capable they wouldn't be writing tutorials.
There are of course exceptions to this, but it covers at least 90% of the people who create courses for sites like Udemy.
Comes back to the old saying, "Those who can, do. Those who can't, teach."
It's interesting to watch people make inferences about the capacity of individuals to develop software based on the utterances of a 19th century Irish playwright.
My theory is that exposition is hard. Most people are shit at teaching.
These HN comments are pretty disheartening. What a dreary bunch.
To summarize them, people write free tutorials because they cannot do (they're bad developers), because they reap some sort of financial gain, or because they actually want to ruin an HNer's day who demanded amazing, free content.
I encourage all of you to try and write a tutorial. You'll see that it's simply hard. You have to decide on what level of skill to aim at, you need to think what this hypothetical person already knows vs doesn't know, you have to keep your tutorial aimed at this balance, you have to resist the temptation to yak-shave, and you have to resist the temptation to adulterate your tutorial with production concerns.
It's not clear-cut at all. Do you add this package because it's how you do it in production? Or do you show how to do it without it? And if you go for the latter, you probably want to at least point out that the package exists. And while you're there, why not include a quick example of how that package can sponge up some of the tutorial code? Maybe that would be more encouraging/illuminating? Are you going to help more people with this example than you're going to confuse? Is someone on HN going to call you meandering and incompetent because you chose to?
It's like trying on an item of clothing and concluding that the manufacturer is rubbish at making clothes because they don't fit you. A such uncharitably odd conclusion to come to.
The old saying is designed to make those who cant teach feel good and superior on expense of those who actually spend time to do something useful.
Teaching is a skill. Criticism can help people to learn how to do it better, devaluing everyone who even tries leads to culture where people won't put effort into it even if they could be good. All that because someone needed to feel superior for doing nothing.
Thanks for mentioning exceptions. I've found that Stephen Grider's courses on Udemy are outstanding. He's clearly found his calling in life. (I don't know him personally - have just taken many of his classes).
I was recommended Stephen from a colleague and now I've also enjoyed Stephen Grider's courses. I also really like them and his style! So far I've only done Vue JS essentials and Complete React Native. If I could be selfish for a moment I wish he would do at least one more Vue course with some more advanced concepts and tackling managing a large project with Vue.
This is exactly right. When I was an absolute beginner I tried learning things from tutorials and I even made a few myself but now in know more I learn everything from the documentation and posts on stack overflow.
Not just writers, most tutorials are objectively terrible.
Trying to find a reasonable example on how to get something moderately complex off the ground is a humbling reminder of the Dunning-Kruger effect. The probability of an internet resource being highly ranked and visible has a near-linear correlation with the resource's unsuitability.
In fact, when it comes to technology, it appears to me that the most prominent authors are barely novices themselves. To make things worse, the instructions and "guidelines" they come up with are invariably as competent as encouraging to use SSL_NO_VERIFY flag because passing CA path is too difficult.
My mechanism for coping on the internet is simple: whenever I see a tutorial on anything non-trivial, I just assume it's been written on Sunday afternoon, after the author discovered the software on Friday night. These tutorials should be considered the modern-day equivalent of their author smiling from ear to ear and shouting "look ma, no hands!".
Which traditionally has been the augur of "look ma, no teef!"
In the back of my mind I always hope that a new technology I'm using will fail in a spectacular, obvious fashion as soon as I use it wrongly, because that means that a great number of resources will soon appear to cover all the gotchas.
It's the ones where spotting and debugging the source of the problem depends on fine-grained conceptual understanding, that leads to documentation that gives you a metaphorical blank stare and shrug.
Adventures in Game Development is the perfect example of the risks of giving assholes your money for crowdfunded projects.
The guy that runs it spent years bragging about doing drugs and drinking to all hours of the night with nothing to show for it and then shits on his backers for asking about the progress of the project (none).
While it's frustrating if taken at face value, Sensor Tower's numbers aren't totally valid. They get the number for a few of my apps really wrong. The download stats are more or less true, but the revenue can be way off.
The healthcare industry almost always looks better from an outside perspective, but once you're on the inside you become just another part of the problem.
Lowering costs is a good example, but once you're inside you realize that the entire industry has been built from the ground up to create high profits and gains, and trying to change that leads to a quick exit. So once most people are on the inside they just go along with it and play ball because it's the safe and profitable thing to do.
Everyone wants change with healthcare, but short of the industry collapsing and being re-built, I don't see way that it's going to happen, though I'd love to be wrong.
That's why I think Apple should give it a shot. They are big enough to basically rebuild healthcare, create an integrated user-focused product including a chain of hospitals, clinics, web and mobile apps, health smartwatches, DNA sequencing, maybe even research.
The idea of solving any problems for an industry that you haven't worked in for at least a couple of years is ludicrous.
I'm sure there have been examples of this happening a few times, but it's almost always the exception rather than the rule.
This is especially true when it comes to high level problems in most industries. In most cases there are a few hundred or more smaller issues that add up to create the bigger high level problems, and those issues are almost never even considered when the startups try to disrupt the industry.
Every industry, no matter how small is going to have issues the derive from third parties and outside players that can't be solved by a twist of the business model.
There are a lot of old timers using very old dos era applications in their day to day business, and if you really spend time with them and learn their business you'll learn there is almost always a very valid reason that they haven't switched the latest greatest web-app software that startup founders tend to think can solve all of their problems.
The moral of the story is, founders need to stop trying to swoop in and disrupt industries where they don't even have a clue of the real pain points, and their SaaS solution would just be a new coat of paint on on old issue that isn't solved.
If you look at a smartphone from 5 years ago and a vehicle from 5 years ago, the capability of the phone is going to dwarf that of the in-car infotainment system. In all honestly, that 5 year old phone will likely out perform most of the infotainment systems in vehicles rolling off the assembly line right now. I don't even want to think what consumers are being charged on a line item basis for the outdated hardware in vehicles.
I still can't figure out why car companies are even attempting to build these systems themselves (besides profit, I suppose). Pretty much every American has a phone in their pocket that is much more capable than any infotainment system, and it specializes in the things we mainly want from an infotainment system (music, maps/gps, txt, calls).
Wouldn't it be so much better if vehicles just had a barebones screen in the dash with a connector for smartphones to power the system? You could even have the screen size mirror the resolution of the phone so it's just scaled up and rotated. Doesn't seem like much else would have to be done.
I'm sure I'm over simplifying things to some extent, but it still seems like a setup like this would be much easier to produce and much better to use than anything coming from car companies who are typically pretty terrible at software and UX design.
*of course not all vehicles are for Americans and not everyone has a smartphone.