Toddler disruptions; morning rituals edition

Like many (but by no means all) technology professions I am a functional caffeine addict. Not an abuser these days: this relationship is mediated by actual thinking when the questions “Should I have another coffee?” comes up.

My tipple of choice is espresso, and I only adulterate it with milk or sweetners when I want the milk or calories as well as my upper. Mostly I drink it straight.

Morning rituals

Of course I own a machine for preparing the stuff (not a high-end one by any means, but pump driven). And a burr grinder for preparing the beams.

And while I can run through the steps in about a minute, I prefer to take a bit longer about the task. Grind the beans. Fill the cylinder to just the right level—I know what level of loose grounds will tamp to the right height. Tamp it firmly and level without letting a single stray ground escape; feel the resistance firm up as the block locks in to the breach.

It’s a little moment of meditation and anticipation.

“I help”

The issue is that my toddler wants to help (and she is now explaining with the phrase that form the title of the sections as well as with a full voiced tantrum if I don’t let her). And, unlike six months ago, she isn’t content to be given a job or two (“Push the button. Good pushing!”). She know what the steps I go through are and wants to do them all.

She plays a stochatta rythmn the grinder’s go button. She scoops in half again as many grounds as I need (spilling a lot). The tamper goes in willy-nilly and scoops out some grounds (more spilliage) leaving too few, too loose, and unlevel; then the tamper lands on the counter-top with a frightful thump. She may or may not get the block into the breach mechanism straight and even if she does it may not seal well. Finally, she knows that my dimunitive cup means the 1-shot button if she stops to think about it, but in her excitement she may hit the 2-shot button instead.

It’s anything but metatative for me and the “anticipation” I feel while this goes on has bit of kinship with dread.

She loves it.

And I usually get a pretty bad shot of espresso.

Written with StackEdit.

Shhhh!

I recently encountered a programming situation where two needs were in conflict.

1. I needed to run some code in a separate process and collect data from it as structured text (as if I was calling a the program with popen).
   
2. The program in question used a library that wrote notification of unexpected events to the standard output.
   

Any output from the library will break the desired output, even if my code handles the exceptional state.

Of course you could argue that a well designed library wouldn’t spew trash into the a resource “owned” by the calling code like that (and you’d be right). But this is a legacy tool that lies outside my control: I have to take it as it comes and find a way to deal.

I used an approach at work that relied on details of the context and the fact that offending output was all on the standard error. But my subconscious worried the general problem until the approach discussed herein occurred to me.

Go Talk in Another Room

I’d like to simply re-direct the output of the library to some harmless place (possibly /dev/null or possibly a log of some kind).

But I also want to be able to restore the stream assignment we had when I’m done calling the code with the issue.

And I want it to work with output generated by both stdio.h and iostreams. (I could probably find out which one this offending library is using, but this might as well be a general facility.

And I want it to be safe, convenient and easy.

Programming to standard

 

The actual C and C++ standards provide surprisingly thin and weak abstraction for files. I mean C provides an opaque type FILE and a set of interfaces for opening, reading, writing, seeking, and closing them, but it also provides three special FILE* objects for your programs to use that generally can’t be set up using the open and close primitives in the API.

To manipulate with stdin, stdout, and stderr we need to bring in some OS API. I’ll be programming against POSIX as expressed in unistd.h (and I’ll try to provide support for windows systems by using some POSIX compatibility calls provided by that system).

Using RAII and scope

 

This code to acquire a resource, wait for stuff to happen and then give it back without caring exactly what is going on in the middle step as long as the resource is in the expected state when the “give it back” code runs.

This is a suitable use case for RAII (Resource Acquisition Is Initialization). We’re going to mute the selected stream in the constructor of a class and unmute it in the destructor. Then we control when the stream is muted using the lifetime of objects of the class.

If we call the class that does this Muffle a typical application might look like

operationWhoseOutputYouWantToSee();
{ // scoping brace control the object's lifetime
   Muffle o(stdout);

   someOperationWhoseOutputNeedsSuppressing();
} 
anotherOperationYouWantToLetOutput();

This same is also seen in classes like std::lock_gaurd and Qt’s QSignalBlocker.

RAII is not automatic

Used consistently RAII can be a bit magical, because as long as all the members of your class are fundamental type or also implement RAII you don’t have to worry about them: you construct them in your constructor and let your d’tor call theirs and they take care of themselves.
But in this case we’re interacting with a resource (OS file descriptors) that are handled through a C library. We’re going to have to pay attention to make sure that we aren’t leaking file descriptors.

The code

Written against C+±11 as that is what I’ve been using at work recently. (I know it’s getting long in the tooth but we are required to support some pretty antique platforms; with this standard we only have to construct a custom build environment for one of them…)
Header file (muffle.h):

#ifndef MUFFLE_H
#define MUFFLE_H
// A RAII class that redirects an output stream to the a file (the bit
// bucket by default) during it's lifetime.
#include <cstdio> // For FILE*

#include "ext.h"

class Muffle
{
public:
  Muffle(int fd, const std::string & fname = os::bitBucket() );
  Muffle(FILE * stream, const std::string & fname = os::bitBucket() );
  ~Muffle();

private:
  int m_origFd; /// File descriptor associated with original state; gets temporarily re-written
  int m_tempFd; /// Holds the a clone of the original to restore
};

#endif//MUFFLE_H

(The function os::bitBucket is defined in ext.h and return "/dev/null" or "NUL" on Unix-alike and Windows systems respectively.)
Source file (muffle.cpp):

#include "muffle.h"

#if defined(_WIN32) || defined(_WIN64)
#include <io.h>
#define close _close
#define dup _dup
#define dup2 _dup2
#define fclose _fclose
#define fileno _fileno
#else
#include <unistd.h>
#endif
#include <stdexcept>

Muffle::Muffle(int fd, const std::string & fname)
    : m_origFd(fd)
    , m_tempFd(dup(m_origFd)) // +1 fd
{
    FILE * bitBucket = fopen(fname.c_str(), "w+"); // +1 fd
    if ( ! bitBucket )
      throw std::runtime_error( std::string("Muffle: Error: "
         "Failed to open '") +
    fname + "' to recieve redirected output.");
    // In principle we could manipulate the buffering here (setvbuf() or
    // similar)
    
    dup2( fileno(bitBucket), m_origFd ); // closes then re-opens m_origFd
    fclose(bitBucket); // -1 fd
}

Muffle::Muffle(FILE * stream, const std::string & fname)
  : Muffle(fileno(stream), fname)
{}

Muffle::~Muffle()
{
    dup2( m_tempFd, m_origFd ); // closes then re-opens m_origFd 
    close(m_tempFd); // -1 fd
}

BTW, the Windows support code there is just a guess. I haven’t tested it.

Seeing it work

You can see what it does with a simple scaffold:

#include "muffle.h"
// Test the blocking behavior on both c stdio and c++ iostreams, covering both
// the standard output and the standard input. Also check that everything is
// properly restored.
#include <cstdio>
#include <cstdlib>
#include <iostream>
#include <string>

// Simply attempt to output it's argument on (both standard streams) x (both
// standard library mechanisms).
void testStreams(const std::string & word)
{
    fprintf(stdout,"\tstdio: stdout: '%s'\n",word.c_str());
    fprintf(stderr,"\tstdio: stderr: '%s'\n",word.c_str());
    std::cout <<   "\tstreams: cout: '" << word << "'" << std::endl;
    std::cerr <<   "\tstreams: cerr: '" << word << "'" << std::endl;
}

int main(void)
{
    std::cout << "\n" << "Check initial function ..." << "\n" << std::endl;
    testStreams("Before blocking");

    std::cout << "\n" << "Block stdout ..." << "\n" << std::endl;
    {
 Muffle o(stdout);
 testStreams("stdout blocked");
    }

    std::cout << "\n" << "Block stderr ..." << "\n" << std::endl;
    {
 Muffle e(stderr);
 testStreams("stderr blocked");
    }

    std::cout << "\n" << "Block both ..." << "\n" << std::endl;
    {
 Muffle o(stdout);
 Muffle e(stderr);
 testStreams("stdout/stderr blocked");
    }
 
    std::cout << "\n" << "Check full restoration ..." << "\n" << std::endl;
    testStreams("After blocking");

    return EXIT_SUCCESS;
}

On the Mac and Linux system where I’ve tested it it spits out:

Check initial function ...

 stdio: stderr: 'Before blocking'
 stdio: stdout: 'Before blocking'
 streams: cout: 'Before blocking'
 streams: cerr: 'Before blocking'

Block stdout ...

 stdio: stderr: 'stdout blocked'
 streams: cerr: 'stdout blocked'

Block stderr ...

 stdio: stdout: 'stderr blocked'
 streams: cout: 'stderr blocked'

Block both ...


Check full restoration ...

 stdio: stderr: 'After blocking'
 stdio: stdout: 'After blocking'
 streams: cout: 'After blocking'
 streams: cerr: 'After blocking'

BTW, I do know that I don’t need the flushing behavior of std::endl all over the place like that. Too bad. I prefer to have belt and suspenders until I know I’m IO limited to an unacceptable degree.

Is it watertight?

Early versions of the code leaked file descriptors. Not good. Another simple scaffold tests for that.

#include "muffle.h"
// Attempt to detect if we're leaking file descriptors, by simply cycling the
// class a lot.
//
// Accepts a single, optional command line argument specifying how many times to
// cycle (defaults to 1025 to break default-configured Linux if we lose one per
// cycle).

#include <cstdio>
#include <iostream>

int main(int argc, char**argv)
{
    size_t max = 1025;
    if (argc > 1)
 max = atol(argv[1]);
    
    for (size_t i=0; i<max; ++i)
    {
 Muffle e(stderr);
 std::cout << i << std::endl;
    }

    return EXIT_SUCCESS;
}

This output is boring as it simple counts up to one less than it’s argument.

Discussion

I had to take some care to follow the acquisition and relinquishment of file descriptors and have left a trail of bread-crumbs from that investigation in the form of end-of-line comments. The upshot is that the class claims a single net fd for most of its lifetime, but need to grab two briefly during the c’tor.

Deficiencies

This code is not thread safe as it relies on a LIFO structure of calls (which is enforced by the scope stack in single-threaded programming).

Written with StackEdit.

On nerds and not ruling the world, after all

Warning: wild, rambling, and only vaguely supported opinion ahead. Take it as you will.

Also, some of this addresses the reader in second person; in doing so I am envisioning my peers: people who have mastered (or are in the process of mastering) some arcane technical art but might have to work up a head of steam just to manage a proper mingle at an office social.

---

I have always been a geek/nerd/strange-introverted-kid. My high school experience sucked (it was both better and worse in various ways than is depicted in popular media, but that story is probably more interesting to me than to my readers). It didn’t help that I was uninterested in the kind of socializing that most of my peers enjoyed and inept at what socializing I did participate in, but it was also a simple fact that I was an outlier in a system ill equipped to do much for such people (despite real effort and interest on the part of some of my teachers.¹) and didn’t have a lot in common with most of my school mates.

Unsurprisingly I resented the “cool kids”. Somehow I convinced myself that knowing how to “do things” I was going to end up running their world.

Right. Sure, kid. Good luck with that.

In reality, of course, it is mostly a lucky few of the cool kids that run the world² and the geeks are just the most able of the henchpeople. The geeks are valuable to the bosses because they are harder to replace than some other job descriptions, but all it buys you is a higher salary and a looser dress code.³

Tech skills run the infrastructure, but people skills run the world.

So it’s high school forever, then?

God, what an Orwellian image, eh?

No, for a couple of reasons. First and foremost, you are not bound to the artificial community of your school. You can (and should, and for the most part naturally will) find a set of social settings where you fit in.⁴

And secondly because your intellectual and personal development is not circumscribed by the program of the institution, and you have the personal where-with-all to take it as far as you care to go.

Where am I going with this?

Geeks don’t run the world, but they do run the infrastructure, and when you do that there are consequences. Some of them are good: the infrastructure knits the economy together and makes us all richer. Some of them are bad: some of the bosses are (intentionally or not) driving toward a slightly different Orwellian future in the name of glory or riches.

You may be bound to the wheel of life as a keyboard poking wage slave, but you don’t have to do it for anyone in particular. And many techies are in a better position to change jobs than other office workers.

You have, to some degree, a choice about who your work for. It may take some time to get away after you make the decision, but the option is there. Polish up your paper and get it on the street.

I decided some time ago to not work for jerks; call it my long delayed and largely ineffective revenge on the cool kid’s table. In any case, it is why I am a not doing Stack Exchange right now: I concluded that I had good reason to think that the managers were treating their top-flight technical talent badly, and that is good enough that I won’t do any free work for them.

But … hope!

Now, we just had the most promising smoke-signal from the secret lair in weeks, and I’m trying to not be impatient because I know these things take time. But … we’ve had previous reasonably promising smoke signals that presaged what appears to be highly jerkish behavior.⁵

Not sure what I will have to say if they send me the promised survey.

---

¹ I wish I could find and apologize to a few of them. And in one case I also owe props to a woman who played my youthful resentment like a virtuoso and led to my markedly reduced suckage in her field despite my best efforts.

² Of course many of them don’t make the grade and end up even more expendable and less respected than the geeks. For a unlucky few high school might really be their glory days, but I wouldn’t wish that on anyone.

³ If you are thinking about tech giants and thinking that the geeks really did end up in charge, think again. Those guys had to develop the same “people” skill set of the popular kids. They’re might have been too late blooming to have a seat at that table in the lunch room, but they have as much in common with the cool kids as they do with the nerds.

⁴ If you are unfamiliar with the concept of a “third place”, look it up.

⁵"Appears to be" is as good as it’s going to get. The company isn’t telling and those most affected are too professional to tell tales out of school. But they don’t get to blame us for making do with what we have., because it is what we have.

Written with StackEdit.

Moderation, quality control and being "welcoming"

There exists a large disconnect between the culture of some Stack Exchange sites (I'm particularly familiar with Stack Overflow and Physics Stack Exchange) and the expectation of a lot of people out on the web.

I'd like to propose a categorization that might let us talk about the conflicts, and agree on what we can and should work on. And perhaps on where we simply don't agree.

The categories  I propose (and which I will discuss in more detail lower down are)

1. The fact of rules.
2. What is in the rules.
3. How the system notifies users of violations and enforcement
4. How other users explain the rules and act to enforce them
5. Cultural differences
6. People being jerks and how moderation of these behavior presents to other users

That is a lengthy list which means that minor annoyances can add up, so we also need to consider

7. The gestalt experience.

Nomenclature of this post

For the purposes of this post, "quality control" mean voting posts up or down and making decision about what content should is on- or off-topic (so open/close decisions) or constitutes a duplicate, while "moderation" means action to control or remove conflict that is not remaining civil (the removal of comments and deletion of post, suspending users and so on).

This distinction isn't always clear, but it might be good enough.

Taking the points of conflict one at a time

I'd like to propose a categorization that might let us talk about the conflicts, and agree on what we can and should work on. And perhaps on where we simply don't agree.

The fact of moderation and quality control.

Let's face it, quality control is a process of making and acting on quality judgements about content and moderation is a similar process where the judgement in on behavior and adherence to site expectations or customs.

Saying "This content does not meet out standards" no matter how nicely praised it not going to make the hearer feel good, and many will take it as a personal attack. You can make an ethic of "vote the content, not the user", but even if you get your indoctrinated users to live it newcomers may not believe it.

In my opinion this is non-negotiable for a successful sites of any kind that should run on a Q&Aish engine, but it is a place where you necessarily lose people who don't believe it.

Nature of the rules about topicality

My impression is that many users come to Stack Exchange with expectations that the scope of the sites will match their experiences elsewhere on the internet, and are surprised to learn about the rules circumscribing the opinion-based contents and polls and largely banning jokes. In other words they are surprised by the fun-hating nature of the network.

To understand where these rules came from you need to know something about the early history of the network (they weren't announced from on high or part of the original ethos of the Stack Overflow beta, we had to learn that they were needed and invent them (or at least the version used by Stack Exchange). Nor are the uniform across the network which offers a window into how variations on these rules might affect the resulting culture of a site.

Well, at least you can let us have a little fun

The place of fun (meaning polls, surveys, joke questions, and so on) was a matter of great contention in the first few years of Stack Overflow. Joke questions and polls were around during the beta, and as you would expect they attracted a lot of attention and votes. Which was the problem.

As a compromise a site (called Not Programming Related after the title of the closing category) was spun off as a place where the new, strict rules of Stack Overflow wouldn't apply and fun could flourish. However, in time the regulars of the site became dissatisfied with the way that site was going too. Not Programming Related underwent a major overhaul and tightening of rules to become Programmers and later after another iteration the Software Engineering we know and love today. In my opinion it is much more useful in its current form.

A counterpoint is Code Golf and Programming Puzzles which started life with a strict requirement for an "objective" winning conditions (meaning not "most votes wins"). But the site didn't really take off until that condition was relaxed.

I favor strong rules limiting polls and opinions stuff on technical Q&As.


Well, you shouldn't exclude absolute beginners


Early in Stack Overflow's history founder Joel famously proposed a "No question too basic" ethic and backed it up by asking a particularly basic example question. In time the notion was dropped.

My personal take is that Q&A is a bad format for getting newcomers over the hump simply because they don't yet know what questions they should be asking. What complete newbies need is an interactive and focused tutoring sessions provided by a sufficiently experienced mentor. In any case the internet doesn't need a permanent record of their exploratory efforts: it just clutters up the search space without being discoverable for people with the same misconceptions.

In principle the necessary mentoring can happen in a chat environment, but on Stack Exchange the user would either need to have enough rep on some site to qualify for the association bonus or somehow score a up-voted post before they begin. Either of which is tricky for someone completely new to the network.

It is not obvious to me that this decision needs to be made any particular way. For a compare and contrast in the Stack Exchange network consider the differences between Mathematics (welcomes very basic stuff), Physics (excludes some basic stuff on a basic that is hard to explain to beginners), and Math Overflow (research level by designed and has a slightly different history than the others). All three can reasonably be described a "successful", but they have very different feels.

I prefer the Physics model to that of Mathematics, but I don't think it is necessary.

The way the system presents quality-control or moderation actions

So a quality control or moderation action has been taken, what does the user on the receiving end see? How clear are they on what they did that triggered the action? How easily can they get more detailed information or help understanding? Do they know where to take questions, and what kind of reception will they get?

This is partly a technical issue and partly a communication one (and see the point on cultural differences), Stack Exchange has been banging away at the technical end of the problem with some small success, but it remains a problem for the network.

This stuff needs to be watched. Sites need to hear users complaints and take them seriously in aggregate, but I don't think it will be possible to satisfy everyone.

The way other users inform newcomers about rules and  expectations

Separate of the actions (like closing) that are presented as system actions users may receive comments and downvotes. These actions are necessary, but they contribute to the experience of new users. I mostly want to address this in the section on overall experience.

Differences in cultural expectations

Technical culture in the United States has a fairly direct and terse style of communicating (though my observation is that some of my Dutch, German, and Swiss colleagues are even more blunt), and people with different expectations may read communications in that style as unnecessarily harsh.

If I write a comment "You should provide a MCVE." as a response to a beginner's question and then wander off to more interesting posts (even without down-voting or voting to close) they may feel that I'm sending an exclusionary message by using insider terminology and not explaining why that would be a good idea. Non withstanding that the link explains both what is meant and why it is a good idea.

Differences between regional cultures (Asian versus European, for instance) generate a similar level of frictions. Heck, even differences in idiom between dialects of English can generate troubling misunderstanding. To take a personal example, it took me time and deliberate effort to stop getting my hair up when a speaker of Indian English wrote that they had a "doubt" (that is to say a question) about basic physical theories of long standing.

These days Stack Exchange has an automated (machine learning driven) process that flags potentially troublesome comments for human review and has arguable made significant progress with it.

We can write codes of conduct that press people to presume good faith, encourage a encouraging rather than discouraging frame for comments, and provide comment catalogs which have the desired tone (thought this means an on-going effort to maintain the catalogs...), but again you can't please everyone.

People actually being jerks

For some people that's just a way of being. Others lash out after too many hours of trying to make some headway on the quality control front. And sometimes well meaning people just don't understand the way they are coming across.

Whatever the cause the site has to moderate this stuff efficiently.

It may not be apparent that anyone is taking the victim's side

While I am generally in favor of the impersonal and unannounced nature of most Stack Exchange moderation, I suspect it may contribute to new users sometimes getting the impression that people are being allowed to be mean to them and no one is defending them.

I don't know a good way to handle this in general. As a moderator I would sometime leave

I've deleted some comments that were infringing on the "Be nice" ethic.

type comments, but I don't think that scheme is sufficient.

The whole experience taken as a package

But here is the rub. I've broken these issues into a bunch of categories but when I read the many blog posts around the internet about how much people disliked their introductory experience of trying to be an active user of Stack Overflow the thing that stands out to me is the way they react to the combination.

They get downvotes, and negative comments, and the question gets closed, and the automated message is the wrong one or is not helpful, and no one offers helpful answers to their questions about the whole affair. Then, if they are persistent, they go to meta and things usually don't get any better.

Not sure where to go about this.

Little surprises #1

Systems that are complex can have surprises, and so can those that are subtle. So it is no surprise that systems that are both complex and subtle will have surprises.

Consider this code sample

In c++11.

#include <cstdlib>
#include <map>

class NonTrivialClass
{
public:
  NonTrivialClass() : m_a() {}

  // As it stand this code won't compile.
  //
  // Which of the following lines can be added (individually) to the class to
  // make it compile?
  //
  // NonTrivialClass(int a) : m_a(a) {}                              // (A)
  // explicit NonTrivialClass(int a) : m_a(a) {}                     // (B)
  // NonTrivialClass(const NonTrivialClass &) = default;             // (C)
  // NonTrivialClass & operator=(const NonTrivialClass &) = default; // (D)
  // NonTrivialClass & operator=(int a) { m_a = a; }                 // (E) 
  
private:
  int m_a;
};

int main(void)
{
  std::map<int, NonTrivialClass> m;

  m[42] = 1; // <== Error here

  return EXIT_SUCCESS;
}

The situation abstracted here into a minimal code sample actually came up for me today.

Answer

Lines (A) and (E) will do it.

• The difference between the first two tells you why (A) works: it is implicitly constructing an object.
• (C) and (D) are distracters. They don’t do anything in this case and there is no particular reason to expect that they should.
• The reason that (E) works is complex (or at least multi-stepped). The value 42 is not currently a key to the map, so the compiler can default construct a new object, and return a reference to it. With that reference in hand NonTrivialClass::operator=(int) can be applied.

In the case of the code I was looking at this afternoon, the header was lengthy enough that while I was staring at the constructors trying to figure out what was going on the declaration of the assignment operators was off the screen.

Written with StackEdit.

Phone case suggestions?

The snap-in belt holster for my iPhone 8 is worn out. The phone falls out at undesirable moments several time a week. The phone itself has been fine as the case (an OtterBox defender) is pretty sturdy, but I don’t want to lose the fool thing.

I’m looking for recommendations on a new holster (or a whole new case).

Upgrade woes and another thing to walk away from

I finally let my MacBook Pro upgrade to Catalina a couple of days ago and got a rude surprise.

Some arrogant snot at Apple (I know, not exactly an uncommon breed over there) thought it would be a good idea to make the Desktop and Download folder special.  As in most application aren't allowed to touch them. Apparently this is a "security" measure.

Now, you can manually assign permission to applications you want to have access.

But I do most of my work from the command line (everyone thinks a Mac is just a convenient Unix box, right?), which is to say that I use dozens of different "small sharp tools" (i.e. applications) that aren't on Apple's blessed list. Who wants to add them all by hand? And especially who wants to discover another one you need to add right in the middle of your next tricky operation?

And I store active projects in folders on the Desktop, so this affect stuff I use all the time.

Used by permission of the creator Randall Munroe

I guess I'll spend a little time installing Linux on that spare laptop this weekend. I'm told that Elementary OS often just works (though my first attempt was thwarted by the TPM).

Scrapers and non-particpation

I'm trying very hard to not support Stack Exchange until I see where they are going. Where they are really going. I mean, they made nice sounding noises in a meeting with a highly regarded user recently to match the ones they've made online. Which ought to be encouraging, but I'm not getting my hopes up. Time will tell.

In the meantime I stumbled across a site scrapping Stack Exchange content without attribution today. (I know that link is Stack Overflow content, and a cursory search brings up a couple more candidates.)

Which leaves me in a bind: I am not working for them right now, but I feel strongly that open source licenses need to be publicly defended to establish a strong social norm around them. Strong legal precedents exist, but sufficiently widespread violation could undermine that.

Anyone who is still participating want to take it?

For your programming sanity

... type_traits or template specialization, but not both.

That is all.

On leaving Stack Exchange

I'm one of a rather large number of moderators who have left the site in recent months. After more than eleven years.

To brag a little on one hand and establish the moment of this decision on the other I'll recite a few facts. My Stack Overflow user number is 2501 and I have the beta badge to go with it. I was also active on UserVoice in the era before meta was a thing. I have around 200,000 "worthless internet points" on subject sites around the network and more than 30,000 on Meta Stack Exchange. My Physics StackExchange user number is 520 and I served as a moderator for more than nine years.

Think about that.

So why did I feel it necessary to step down?

First of all, if you haven't been following the drama you might want to think twice before you dig into it, because there is little positive to be found. Keeping ones blood pressure on an even keel is valuable, after all.

But the short version for me was after months of drama which the company seems unwilling to address I read between the lines of a tweet Shog9 sent out to understand how those in charge are running the company.

I concluded that I would not willing stay employed by the pack of clowns currently running Stack Overflow and Stack Exchange fine ladies and gentlemen in the C-suite for any longer than it would take me to find a new job. (One can't and shouldn't expect people with responsibilities to just say "Take this job and shove it!".)

But if that is the case why in the world would I work for them for free??

I can actually answer that question.

Presumably the reasons that other people are staying on are varied but include things like

• Doing it for the community which remains valuable in and of itself.
• Holding out hope that things aren't as bad as they might look.
• Just haven't noticed because much of the serious drama is internal to the company and hasn't been made explicit, and they either didn't notice the drama on the metas or aren't moved to care.
• Waiting for a viable alternative. 

Whatever the reasons I won't criticize. People have to meet the world on their own terms and those may not be the same as mine.

What do I expect walking away to achieve?

Short answer: nothing anytime soon.

The current executives will remain in charge. They will achieve their stated goals of increasing the user base, and for a while at least it will result in increased ad revenue. The investors will be happy. It will be some time before the damage to the utility and value of the sites is evident to unbiased observers and people with an vested interest in not noticing will be able to deny it even longer than that.

But I won't personally contribute to extra value to people who seen bent on destroying something I worked so hard to build. And that means something to me.

In time, however, the results will be clear. Before we get to that point, the internet needs a viable alternative (or more than one). There are several project out there and I'm looking at them as I find time. More on that later,  I suspect.

The 2nd Law of Thermodynamics, toddler versions

Anyone who has taken more than a casual attempt at learning thermodynamics will have noticed that the 2nd Law can be (and is) stated in many different ways. By my count there are at least six conventional statements built on several different foundations

1.  The performance of heat engines or refrigerators
2.  The natural direction of heat flow (arguably equivalent to item 1, but it may not be obvious at first)
3. Classical concepts of entropy
4. Statistical (and even information theoretical) concepts of entropy.

Toddler versions

My daughter keeps encountering phenomena which to my professorial eye look like physics teaching moments. To her they just represent disasters.

In any case, I'd like to codify some of the toddler statements of the 2nd Law:

• You can't put your banana back together again,
• You can't separate your play dough colors after you've mixed them.

(And yes, I recognize that as stated these are incomplete. She's two.)