For HTML Day 2025 [1], I made a web service that displays the current sky at your approximate location as a CSS gradient. Colours are simulated on-demand using atmospheric absorption and scattering coefficients. Updates every minute, without the use of client-side JavaScript.
Source code and additional information is available on GitHub: https://github.com/dnlzro/horizon
This is why specifications are important, and why design is important.
The reality is that we have certain conventions that are immediately understandable, and that too much visual complexity results in confusion rather than clarity.
If the sky is hazy white when I expect it to be blue, I'm confused as to whether it's the sky or if the map is still loading. It's adding cognitive complexity for no reason. Stars similarly serve no functional purpose at night.
What you built sounds great for an actual planetary view like Google Earth. And it sounds fun to build. But it's an anti-feature for a navigation view. When you're navigating, simplicity and clarity are paramount. Not realism.
> This is why specifications are important, and why design is important.
Also the phrase "know your audience". No sense in casting pearls before the swine.
Though sometimes the higher ups might not be the same as (or understand) the actual audience.
In this case the higher ups may have been confused due to, say, looking at the app while indoors (and from the perspective of "let's judge this developer's work"), while the actual users would see it in a vehicle alongside the real sky (and from the perspective of "let's see how easy this is to match up with reality").
Ah, I see the confusion. You think the users are the dev's audience! /s
I suppose this is the lesson OP learned!
I wish more people knew it. So many times frustration of the system is directed at devs. They couldn't figure out X? Why is Z feature so shit? Etc.
That's a management thumbprint on the deliverable.
Also, any fanciness you add in your product is something you need to then maintain. Even after the developer that built it leaves the company.
It takes thousands of years for the stars to have changed positions in a noticeable way, and my best guess is that the customers will not use their car GPS for so long that this will bother them.
Very funny, but in case you're serious, it's not the stars changing...
...it's the software frameworks. A new screen size. A different color depth. A bug when the graphics library is upgraded for antialiasing. Etc.
That's not going to be an issue with devices already sold. And if developers of future devices can't handle it they should probably be fired from their job.
It's not a question of whether future developers can "handle" it. It's a question of whether the additional time required to maintain it is worth the cost. Maintenance isn't free. It takes time, and every little bit adds up.
Also, devices already sold often get updates, so it's not even just about future devices.
Oh come now. You are being no fun.
A past coworker who worked on Cobalt[1] told me that they spent entirely too much time implementing stars in the sky of the game with some amount of real(ish) star system physics behind them.
I can understand people removing polish things like that if there are usability concerns, but those small things add up to a lot in an end product and are a joy to find and explore.
1: https://en.wikipedia.org/wiki/Cobalt_(video_game)
The last thing you want is to receive a message from Neil Degrasse Tyson about how wrong your sky was
https://duckduckgo.com/?t=ffab&q=neil+degrasse+tyson+gives+j...
And pointed out Jon Stewart's globe spinned backward
Cobalt was a really interesting game, too bad it never got any fame
Whipping down the innovator with the stupidity whip. Great management
It sounds like the developer spent a lot of time implementing something that nobody wanted. Drawing the sky accurately may be cool, but it wasn't required in this case. It's also not innovation. It's been done before.
This is like if you were renovating your house and the drywall guy spends a huge amount of time building up round corners, but you just wanted regular square corners. Then on some drywall forum they're bitching about how "all clients are stupid" or something.
And, from the sound of it, the developer confused truth with beauty. Sometimes we’d prefer to see the sky the way we wish it were rather than the way it is.
That’s an aesthetic call, not a “who can do the math” call.
“Good news, I accurately simulated the particulate load in the local atmosphere—so now you authentically can’t read the text on a given smoggy winter morning!”
(FWIW, grace for management decisions notwithstanding, I think what gp did is awesome, and would switch on full realism mode every time :)
This is a wildly unprofessional attitude. Programmers are craft(wo)men. They employ their craft toward creating things people pay them to create.
We aren't painting sistine chapels, we are running the plumbing in the sistine chapels basement. The job doesn't exist to give you emotional fulfillment. A mason doesn't insist that a client who needs a warehouse must pay him to spend a week detailing corbelled brick cornices. He makes a CMU wall, in the cheapest and most efficient way that still gets the job done.
It's profoundly disrespectful when we build monuments to our own ego instead of just getting the work done and it speaks to a professional immaturity of the highest order. That was one of the hardest lessons I learned as a fresh engineer and I see so often others that are just learning it. Sometimes people never learn it.
> We aren't painting sistine chapels, we are running the plumbing in the sistine chapels basement.
Sure, but in plumbing - or any trade - there is a huge spectrum of quality of work. Tons of little details add up that confer the person’s skill level to anyone checking it out in the future.
> It's profoundly disrespectful when we build monuments to our own ego instead of just getting the work done and it speaks to a professional immaturity of the highest order.
When I insist that something must be done a certain way, it’s not for my ego, it’s because I know that a year from now, I will be called upon to fix it during an incident if I don’t do it right this time. I am so absolutely sick of hacky bandaids being thrown on the ever-increasing pile of tech debt. To me, it’s profoundly disrespectful when product tells engineering that yet again, they will not yield time to fix the backlog, and to ship New Feature X.
I've been in the developer's shoes. I've also been in the manager's shoes.
It's not that simple. There's possibly better ways to deal with it, but for safety-critical stuff (like a navigation display in a vehicle), simple is much, much better. In many cases, there's actually laws and liability stuff involved.
I once spent six months, developing an "un-asked-for" WiFi control app for a digital camera, and had it nuked. It worked much better than the shipping app (which was enjoying a richly-deserved one-star rating in the app store).
The considerations had a lot to do with the corporate Process (note the capital "P"), which I sidelined. I thought I could do better, but the people with the hands on the brake, thought different. I didn't kiss the right rings. That's a very real consideration in any corporation.
As a manager, however, I did go to bat for employees that displayed initiative. In some cases, I was successful. In some cases, not so much.
There's so much decision making in companies that comes down to some dingus in management decided that it would Be Bad On Purpose. Fighting that battle is something you can try a few times in your career if you want, but it usually leads to burnout or a resume generating event.
A foundational, core theme about making commercial software, that repeats over and over and I slowly got accustomed to is: companies really don't want these kinds of micro-innovations. 90% of companies are just looking at their competitors, making a checklist out of those products, and asking engineers to check the boxes and go home. They don't care about little details, about craftsmanship and polish, about lint warnings, about "oh, that's a nice touch," or even quality beyond "will the customer return the product?" They just want people to poop out software as fast as possible so everyone can get bonuses and drive around on their jetskis on Saturday.
If you're the kind of developer who likes to "sand and finish the back side of the cabinet," either you need to find a very rare, special company, or do it at home as a hobby.
But it's exactly the thing that makes software "delightful". It's also a huge boost to the developer's appreciation, motivation, productivity, care for the product.
But yeah, if you only care about checking the feature boxes.. Go ahead, make shit software with miserable people, but be sure to prepare to go out of business.
The point is a real skybox is not great for satnav software. It's probably actually worse than a stylised mode, with a predictable colour background for anything that's going to sit on top of it.
That's exactly not the point. Where do you think innovation comes from?
It comes from tinkering.
It comes from all sorts of different things. Massive capital investment into R&D processes also. Depends on the thing.
> They don't care about little details, about craftsmanship and polish, about lint warnings, about "oh, that's a nice touch," or even quality beyond "will the customer return the product?"
I worked at large companies, and there are reasons beyond that. I've been on the both sides of this fence.
Senior engineers feel the pain of supporting all these features. You created a new streaming API prototype that provides a gradual response, progressively displaying details of the 3D model? Great. But it's 15000 lines of dense code without a lot of explanation. Who is going to support it once you leave the company? Is it secure? How does it work with kiosk-type browsers? Can you write a formal proposal so we can start the review process?
Oh, I see that you're already leaving the company :(
And that's also why startups are often so much more successful initially. They just don't care about the long-term support and YOLO a lot of functionality.
Sure.. but all there prototypes don't have to be released. It's part of innovation. And maybe you'll even find a new product or a competitive edge.
You should have added a duck.
I understood that reference
Not even as an easter egg?
You could've sold it with telling them Vincent Van Gogh's paintings had the location of stars accurately, you were inspired by those paintings to reproduce the sky color accurately.
Ironically, I'm in the South of England wih clear blue sky, and the site thinks I have a much darker and beautiful reddish sunset. Im fairness, it's probably only out by an hour if that.
Maybe it is out by an hour due to BST.
The thing here is programming the job can be much more dull than programming the hobby. Occasionally (twice a decade) there can be a collision where you get to do something really cool like that at work. The higher ups want a realistic sky because their market research said it'll boost an OKR by 10 basis points. And then you are in luck!
That said there are niches where jobs let you do cool stuff all the time. Hard to find. Probably why gaming jobs are notoriously underpaid and overworked.
I’ve had similar issues at work where people really overdo something and it’s difficult. On one hand you never want to kill that joy and passion someone has. That’s a great characteristic. But projects have scopes and too often instructions like “just draw a blue rectangle” get ignored.
Totally. It was a harsh but needed lesson on the realities of getting work done in a commercial environment.
Yep, if you have to draw the Sun, you better draw it yellow. If you have to draw a cloudless day sky, you better draw it blue.
That doesn't apply to every single instance of those, but if the sky isn't the focus of your application, a realistic one is just a distraction.
> Yep, if you have to draw the Sun, you better draw it yellow.
This one always gets me in how dirty the sky must have been "back in the day" in order for people to see a yellow sun. I've never looked into what gas would be needed to make the sun look yellow, but it must have been hell to breathe.
Nah, the ancient Egyptians, and other cultures, depicted the sun a lot, and never made it white. Red, quite often, gold, very frequently - warm colors. If you paint a white sun people say it's the moon.
The walls were black for a reason in big cities. All those chimneys and coal everywhere.
That sounds really cool but I have to reluctantly agree with the senior: a cartoonish day/night sky is better than a half-implemented realistic one. I say “half-implemented” because it sounds as though yours didn’t account for local weather and cloud cover, which is reasonable but then incomplete. Even if you did, well, it’s turn-by-turn navigation. I expect the sky color to be selected for ideal contrast with the important UI elements to reduce the time spent looking at it while driving.
To be honest I don’t think anyone wants that kind of functionality - maybe in the satellite view but not in the vector map.
Fun (but not fun) story :)
Haha it sounds you applied the opposite of the YAGNI principle building this.
I identify so much with your sentiment and this type of overthinking overbuilding .