Yet Another Morning Entry

*sips some instant coffee from cup*

Well, here we go again, a morning blog entry. I'm not sure when I started to make morning entries a ``thing'', considering that for the most part, I do prefer to write in the evening when the day has ended---there's at least some thing that I can write about from the whole twelve hours or so that I had been awake then.

Writing morning entries have a way of requiring some kind of spark of inspiration, or some kind of [strong] stimulus, or even basic laziness in the sense of trying to get things done so that it can be checked off the check list and there will be no need to worry about it later on. That last habit is something that I use almost everywhere, and it has served me well for the most part; I see no point in delaying the starting/completion of a task just because the deadline isn't anywhere near it just yet, especially if the effort needed to complete it is minor. As an engineer in practice, Murphy's Law holds really strongly, and starting on things early when able is a great way to allow the things to go wrong to go wrong and still have time to rectify things. This is particularly true when working with other people; the inter-dependency of tasks means that the requirements can be sketchy even in the best of times, and the best way to get those correctly committed to is to start as early as possible on the task according to the requirements to surface issues early enough for rectification.

I mean, all time estimates are extrapolative in nature, and my personal take on extrapolation (or determining future behaviour from past behaviour) is that the longer the time horizon, the higher the divergence. So starting early gives a longer time horizon to correct for the divergence, either through re-planning of the timeline/milestones, or adjusting the requirements to fit into the feasibility region of the solution space, or to commit more manpower/resources if that is the true bottleneck. Time is the most valuable resource in all the world, even as compared to gold and other precious materials, and in another blog post, I talked about its value too. The most important part of any project (defined as a set of related tasks to achieve some defined goal) is timeliness, hence the great focus on the ``fast'' attribute out of the engineering motto of ``cheap, fast, good---pick two out of three''.

But the second attribute to choose depends on the risk appetite of whoever is choosing to do so. The risk takers would rather go for ``good'', since ``goodness'' means that it may command a higher value than ``cheap''. More conservative types would rather go for ``cheap'', since it means that they can get returns on investment earlier, which expands the amount of resources that they have at their dispoal earlier, which in turn increases the number of options that they can go for.

Argh. I digressed again. Thing is, start stuff as early as they can be started, so that problems that may arise can have a chance to do so while there is less time constraint, which improves the chances of having them nullified and thus not impacting delivery. It also helps the personal psyche since it is one of those many small ``wins'' that one can clock in to keep up the positivity and associated motivation.

The only times where it did backfire on me was when I started on something earlier than I could understand it. That ended up with extra effort required to rectify, but the benefits of it was that I ended up learning more, which made subsequent forms of the task more manageable in the future.

Well, that's about it for now. I originally wanted to write a bit more about more adventures in cooling following the latest one, but I'm still running experiments. A quick summary of what has happened: −80.1 mV was tried across the board, lowest Core VID measured was 0.486 V, Intel graphics driver was unstable when YouTube videos of multiple hours was watched causing an eventual BSOD crash; one reboot with new drivers later, things seemed working, but a new WHEA error of ``CPU Cache L0 Error'' was raised over the 10+ hours of non-active (i.e. I was asleep and not using Eileen-II) run-time later; −78.1 mV is tried now, with observation of the experiment taking place.

I'll talk a bit more about that last bit of technical experimentation on success or something. The new aggression is necessary because I decided to try using the full potential of Eileen-II's CPU through thermal velocity boost to get better average behaviour while keeping temperatures less annoying for native keyboard use.

Alright, this is the true end of this blog post now. Till the next update.