The Nader syndrome and the Regulatorium

I really like Bob Frankston’s essay about The Regulatorium and the Moral Imperative which links to stuff that the first pages of Technologies of Freedom (which I am currently reading) touch on. But when I read the following, I couldn’t help linking it to both the Regulatorium and Pournelle’s Law:

“In a series of valuable reports, [Ralph Nader] and his associates have confirmed dramatically what earlier studies had demonstrated less dramatically – that governmental agencies established to regulate an industry in order to protect consumers typically end up as instruments of the industry they are supposed to regulate, enabling the industry to protect monopoly positions and to exploit the consumer more effectively.”^*

Or as a good friend once pointed out: It is hard for them to press hard their (most likely) future employers.

Continue reading “The Nader syndrome and the Regulatorium” →

Somewhere to begin from

We were interviewing someone for a DevOps position. They were working at a managed network / security services company and needed to change a life and career. Their work was pretty much summarized as “A client files a change request; we implement it at the network device and we’re done”.

No provisioning, no automation, no versioning of configurations was in place. The candidate was not in a position to write code also. Since they were clearly more junior than the position required, we were saddened and in a way gave them some subtle advice to improve on their skills in order to have better luck next time they knock on a door:

Learn to program in Python.
Do that because you can learn to code with paramiko and Netmiko.
Learn some basic git usage.
It does not matter that your employer does not require you to automate stuff and practice version control. You will write a program in Python that will ssh into the client’s equipment, backup the configuration in git and push the requested changes back.
You will have automated your work and will have more free minutes per day to read about stuff.
You will have more to talk about in your next interview.

When you’re not pushed by the environment, you need to begin from somewhere. Oh and understand some basic statistics, because you will need to understand what you graph. It should not only be pretty. It should be useful.

Beyond Blame

That went away fast. You can finish it in one shot. Especially if you are in one of the most thankless professions, with lots of responsibility and zero authority. The narrative, however thin, feels close to heart because this things happen. Or may have even happened to you or someone you know.

cynefin_framework2c_february_2011_28229 — The Cynefin model

While this is no Phoenix Project, the first sixteen chapters serve to lay the playgound for implementing a proper postmortem process, where no one is afraid to withhold critical information. This along a very useful bibliography is presented in the last chapter.

As always, the hard thing is to make people who think that “rolling heads” improve morale and performance, to see the error of their ways.

Yesterday’s Kin

Why are you here?

To make contact with World. A peace mission

I first learned of Nancy Kress via the IEEE Spectrum podcast. Since Yesterday’s Kin was not published yet, I read the Beggars in Spain. This week, it was Kin’s turn. It read fast, less than two nights in a row. Science fiction and genetics is Kress’s playing field and she handles it well.

So what do you do when an alien race, advanced in Engineering comes your way? How do you proceed when they reveal an incoming threat for both races and request for scientific assistance? How do you deal with information sharing? With conspiracy theories that arise worldwide? How do you build trust?

I really do not know what to write without revealing the plot. This is a fast paced story, the genetic science “computes” (well at least if you are not a biologists, then maybe it does not, but I remember she does a lot of research prior to writing anything). It is one of those stories that when reading them I think “It runs so good that I do not see a perfect ending”. Indeed the ending is not the best of endings, but at least it is plausible within the novel’s context and its sub-arcs.

A really nice piece for when on holiday.

sudo apt-get install hugs #haskell

Eight years ago I began a draft of this post with:

I (re)discovered this tutorial on Haskell and Hugs, while cleaning up some old (circa 2001) email.

And it just stayed there. Until tonight; my n-th restart on understanding Haskell. I may be late, but I do not quit.

1% better than yesterday

I am a >Code supporter. In the latest episode, guest Jerome Hardaway said something along the lines of:

Each day I want to be 1% better than the last

I don’t think that even he understands the power of the message. Let’s make a simple graph out of it, where on day 1 we have a value of 1 for a certain skill:

What this means is that in less than a year you aim to be x7 better than when you started. Granted this is only a rough estimate and depending the subject, the difficulty, other issues and any other kind of ceiling a x7 result won’t come, but still, the result won’t be linear.

As the days go by, you’re becoming extremely more competent than you thought, even if today you did not make it to be 1% better than yesterday, but only 0.1% better.

The point is that you do not stop.

Small Prolog

A small post just to break the blog hiatus. Once upon a time there was a Prolog interpreter that was used in the Windows NT kernel. You can read about it here. The code is in the public domain and years ago I had downloaded from the net. It seems that it took me close to 8 years to put it on GitHub, for software archaeologists to dig into if they like.

https://github.com/a-yiorgos/smallprolog

The 22 minute meeting rule

This is a nice trick for running your 30 minute meetings. I found it during listening to the latest episode of The Engineering Commons. 30 minutes are the standard slot for a meeting it seems. So plan for a 30 minute slot, but plan to run the meeting in 22 minutes. Why? Because if you are in a series of meetings, chances are that you’re going to be on time only in the first one (and even that is debatable). So delays accumulate and you can forget ever making it to the last meeting.

So why 22 minutes? My guess is that if you have planned for 5 meetings in a row, this 22 minute window slides enough within each 30 minute slot so that you can make it in all of them.

For longer meetings you can always multiply appropriately.

APL

Today it was my fourth (I believe) encounter with APL:

First, too many years ago when skimming through Tim Budd’s “The Kamin Interpreters in C++” (and the Kamin book afterwards). For the hardcore fans, Tim Budd has a book on implementing an APL compiler.
Next was a Dr Dobbs issue about the J programming language.
Some years a ago a comment on this blog about Dyalog.

Today it was Functional Geekery’s Episode 65 where I found out about the most interesting (to me) implementation of Conway’s Game of Life.

Live

Here is an experiment: today instead of watching the news for the night, I picked up a record I had not listened to for years, Live by Jean Michel Jarre.

I had gifted it to a friend who passed away 10 years ago and I do not believe I had listened to it since then.

The kids were impressed by the music τo the point that they wanted to learn more about Jarre. So I headed over to YouTube and played the whole of the Huston 1986 concert (another album which I had not listened for years since I only have it on cassette). They were really fascinated by what they saw also. The laser harp and the circular keyboard made an impression.

Dad, he must be a super cool engineer!

I do not know about engineering, but design-wise he won their hearts out. We even got to listen to Ron’s piece (from Ronald McNair who was supposed to play this in space) which led to discussing about the Challenger.

Funny what feelings, forgotten memories and processes a forgotten CD can spark.