Re:Ask HN: How do you, as a developer, set measurable and ac...
by Jugurtha on Tuesday August 29, 2017 @02:35PM
(#15126542)
I have carte blanche for the first project I'm working on which involves "customer" premises devices I will not be able to connect to, to be deployed in unreachable places, interacting over flimsy connections of different types, so there are considerations on power consumption and data plans (scrounging for bytes and milliwatts).
What I lack in experience I make for in other ways: I daydream all the time about the ideal scenario regardless of skill, and write the code to make that happen ramping up the skill. Then I daydream all the time about the worst scenario to ruin the perfect scenario, and write the code to prevent that from happening.
After a daydreaming session, I have a bunch of behaviors to be exhibited by the code to deal with different triggers, where the absence of a trigger can be a trigger.
Murphy's law states that things that can go wrong will go wrong. There's another law that states: "Even things that can't go wrong, do". Having that mindset makes me think of a lot of actionable goals to make real, and potential bugs to kill in the egg.
A flyback diode and the dying gasp are some of the most beautiful things I've seen. Designing, whether in hardware or software, for power outages is a thing.
I also think about space probes all the time and I try hard not to fall into Nietzsche's "admiration for a quality or an art can be so strong that it deters us from striving to possess it."
It sucks to know of software that brushes off solar flares for 40+ years like it's nothing and have mine die because of unicode.
Not dying because of unicode is a measurable, actionable, goal.
What I lack in experience I make for in other ways: I daydream all the time about the ideal scenario regardless of skill, and write the code to make that happen ramping up the skill. Then I daydream all the time about the worst scenario to ruin the perfect scenario, and write the code to prevent that from happening.
After a daydreaming session, I have a bunch of behaviors to be exhibited by the code to deal with different triggers, where the absence of a trigger can be a trigger.
Murphy's law states that things that can go wrong will go wrong. There's another law that states: "Even things that can't go wrong, do". Having that mindset makes me think of a lot of actionable goals to make real, and potential bugs to kill in the egg.
A flyback diode and the dying gasp are some of the most beautiful things I've seen. Designing, whether in hardware or software, for power outages is a thing.
I also think about space probes all the time and I try hard not to fall into Nietzsche's "admiration for a quality or an art can be so strong that it deters us from striving to possess it."
It sucks to know of software that brushes off solar flares for 40+ years like it's nothing and have mine die because of unicode.
Not dying because of unicode is a measurable, actionable, goal.