1. We can see the corners that were cut and have either been forced to do the same or know how it could have been done better.
2. Having to use some piece of tech because of some external requirement. Especially when there's a preferred alternative.
3. Genuine desire to not use tech for something. If you spend all day working on and with tech, you don't really need a toaster telling you the weather in the morning.
In short, I find myself less hating technology directly, but the half assery that is a symptom of a lot of other things I hate.
Three soldiers wander into a town and watch as the townspeople shutter themselves into their homes.
The first two soldiers, out of rations, start to knock on doors and asking if anyone has any food, but no one answers.
The third says: "I have an idea, start a cooking fire in the town square and get some water boiling. I've got to find the right ingredient."
They do as they were told, and the third makes a show of trying to find just the right stone. Making sure the town hears and sees them. They bring the "perfect" stone back, and place it in the pot of boiling water.
The other two soldiers start to question, but the third tells them to just shut up and watch.
After boiling a stone for 10 to 15 minutes, one of the villagers comes out to ask what the soldiers are doing. "Making stone soup." replies the soldier, "Though it is usually better with some potatoes or carrots."
The villager lights up, "I have carrots!" They run to their home, come back with a handful of carrots, and add them to the soup.
Seeing this, other villagers begin to emerge from their homes, and each suggesting a new ingredient.
Over and over this happens until someone tries to put raw salmon in and is thrown out of the town.
I mean, until they have a full and hardy stew going, with more than enough to feed the entire town.
The morale of the story being to always have enough rations.
Take a look at GitHub's Copilot.
I used the technical preview and if you're already paying for gh it may be included.
It actually helped keep me more focused on the solving aspects then the, what is the correct spelling, format, etc.
I'm developing a product based on the esp32. Once I got my mind around the IDF, it handles a lot of the productization element.
Specifically it has a means for handling config at compile time, allowing for more flexibility without the need for a new version of the code per update.
My focus is usually from a game dev standpoint.
I might see how quickly I can put together an A* algorithm on a 2d array.
Or Conway's game of life as a similar, how easily can I process these things.
Happy to see things like CDK acknowledged as a next step, and being adopted.
Though I've been fighting for that in my SRE teams.
Something that is forgotten with CDK is that you can do anything else with your code. Importantly that might mean inspecting the current AWS region for the number of AZs (a use case we were looking at years ago).
Couple other use cases that had come up in our discussions:
- Reach out to real time config
- Setup prerequisites (VPCs and networking)
- Play tetris while waiting (immediate followed by "ok we're reviewing your infra setup next")
As a hiring manager, the certs are ok, but the experience is what matters.
I always ask engineers this "What do you think about the AWS documentation?"
If you've had to actually parse through it yourself to learn how to get something working, that's more valuable.
You'd be surprised how much efficiency an engineering team can squeeze out of their games with time and motivation. A lot of bloat happens just to get the game out the door and is then good enough.
Nintendo didn't make any money from the PC sales, so it needs to have revenue from this launch.
And for Factorio itself, the effort of porting to the Switch, and then the effort of going through validation with Nintendo.
Even if they didn't want to charge you again, the company would need to cover the cost of dev kits, extra engineers, and a whole extra channel for development/release.