Category Archives: Engineering

Some More Management Roles

A few years ago, I talked about some management roles, specifically how the traditional ‘Team Lead’ role could be de-convolved into five different roles:

Performance Manager (Worker Evaluation)
Estimatrix (Estimator)
Product Owner (Prioritization)
Scrum Master (Removing Obstacles)
(People) Development Manager (Development Conversations)

At the time, while I’d been running important teams in my organization, it was still a relatively small organization (each CEO knew me by name), so the role and significance of each team was more clear (or at least had been justified by someone before me).

Since then, I’ve learned a little more about what is important in a large organization, and I have some more roles to add. The above management roles have more to do with day-to-day management of a team, and assume that managing upwards and managing long-term are taken care of elsewhere. (Theoretically, they are probably most likely part of the ‘Product Owner’, but most likely they would be part of the ‘reserve power‘, and would devolve to whomever was considered ‘highest’ in whatever organizational hierarchy was present.)

I had also been blessed with excellent technical leads on all of my teams at all of the places I’ve worked, enough so that I didn’t think to explicitly call out ‘Technical Lead’ as one of the ‘traditional’ management roles.

(So now, we have six):

Technical Lead (Software Architecture & Implementation Decisions)
Performance Manager (Worker Evaluation)
Estimatrix (Estimator)
Product Owner (Prioritization)
Scrum Master (Removing Obstacles)
(People) Development Manager (Development Conversations)

(There are also some questions about the exact line between ‘roles’ and ‘skills, for example: ‘Running a Meeting’ ‘Presenting engaging presentations’), so I will include them for completeness, even though they bleed into many of the other ‘roles’.

As mentioned above, the roles below would fall under some combination of:
– ‘Product Owner’ (because they involve working with people or groups outside/above the team in question)
– ‘Scrum Master’ (because the team would notice that they were blocked or impeded by not paying attention to a certain type of issue, and might be perceptive enough to up-level the discussion to a more general/role-based one)
– ‘Reserve Power’ (roles or tasks that are automatically put under a traditional ‘Team Lead’, but no one really considers them separately, even though they take real time and effort)

Anyways, here are some other longer-term and/or more upward-facing roles to add to the above:

Milestone setter
Team Vision & Planning
Recruiting, Interviewing, & Hiring
Team compositions planning/Team Development (this is development of the team as a whole)
Building relationships (travel, phone, random 1:1s)
Running Meetings
Preparing & presenting engaging presentations
Tech architect (Longer-term decisions about code structure)
Code reviews (this would likely fall under ‘Tech Lead’ above, but ‘what is good enough’ would likely fall under the next line, ‘Quality decision-making’)
Quality decision-making (how good is ‘good enough to ship’?)
Quality Assurance & testing
Asking for resources
Team Champion, in charge of Dog & Pony shows[1] (Why is the work that the team does important?)

Some of the above roles are systematized, automated, or otherwise circumscribed by processes in larger organizations, for example, they may have specific processes for project planning, or for recruiting or development conversations.

But still, there are a lot of these. This suggests that either teamwork is super-complex, and requires too many different things to easily handle without tools[2], or there must be some way of grouping them into meaningful ‘roles’.

So, how do we group them? We could group them into the familiar Agile ‘Technical Lead’, ‘Scrum Master’, and ‘Product Owner’, but that just really puts us back where we started, shoehorning roles into boxes that don’t quite fit, or with a bunch left over.

Fundamentally, all of the above roles are some combination of tasks and making different kinds of decisions.

I’ll do what I can to define, codify, and group them tomorrow.

[1] I am somewhat flip in my naming here, but in any large organization, any team should have a story for how they are planning to remind the management structure of why they are important. This serves a number of functions:
0) The obvious ‘remember who we are and what we do’
1) It’s a good check-in, to make sure that what they are doing is actually perceived as important
2) It’s good practice for the inevitable re-orgs in any large organization, or even if one’s boss changes because they leave for another position or organization

[2] Like checklists, or more advanced tools like JIRA and wikis.

On the Importance of ‘Technical Debt’

A couple of years ago, I was talking with a good friend of mine, we were talking about the difficulties of prioritizing the maintainability of software in a large organization development context.

And so, logically, the concept of ‘Technical Debt’ came up. Interestingly, he had never heard the term before[1], although as soon as he heard it, he grasped the importance.

(I remember it as being a really inspiring conversation, but sadly, my notes from that day don’t well capture what I found so inspiring about it. 🙁 )

Although the concepts of ‘clean up after yourself’ and ‘do it the right way’ are likely as old as human civilization, it was likely only after systems reached a certain level of complexity that the concept of ‘Technical Debt’ was really useful. There is a limit to how complex a mechanical system can get[2], and most other systems are amenable to human factors and psychological safety solutions.

It’s also interesting to think about what is different about software, that makes it: A) possible to make a working product with large (including conceptual) defects, B) Useful to ‘go into debt’ to get a product out the door faster (or more cheaply).

One wonders how much it is the sheer complexity of software systems, the number of interacting modules, or perhaps the number of layers involved, from OS to dev_tools, to language, to standard libraries, to 3rd party libraries, to user-made helper functions. Perhaps it is just that one can ‘go into debt’ in the uppermost layer, because there exists a good foundation.

It could also simply be that software is an automation of so many smaller tasks, that any human system as complex would have similar useful concepts of debt[3].

Doing a little bit of digging, it seems that the concept was first termed ‘debt’ sometime in 1992[4], but it was not until later that it was termed ‘Technical Debt’.

Articulating the concept of ‘Technical Debt’ has a number of important benefits:

1) It puts a name on the category of ‘things we want to clean up in our code’, adds an urgency, and calls out more precisely why this is important.

2) It links the concept of ‘do things the right way’ with ‘Business’ concepts of money. This enables much better CTO-CFO conversations, allows better and more informed project funding decision making, and (hopefully) enables better and more structured funding for Technical Debt reduction[5].

3) It enables conversations in the moment, during architecture conversations and code reviews (and everything in between), where the parties involved can directly weigh/balance the time/resource costs of proper implementation with the opportunity costs of delaying time to market (or MVI/MVP[6]).

It will be interesting to see how organizations (and organizational decision-making) change as this concept spreads from ‘pure’ software companies.

[1] We theorized that this was because he had grown up in Hardware companies.

[2] I am not a Mechanical Engineer, and I’m happy to hear counterexamples, as well the conceptual frameworks used to address this… 🙂

[3] Such as ‘Organizational Debt‘.

[4] https://www.martinfowler.com/bliki/TechnicalDebt.html “As far as I can tell, Ward first introduced this concept in an experience report for OOPSLA 1992. It has also been discussed on the wiki http://wiki.c2.com/?ComplexityAsDebt.”

[5] My favourite label for this is the ‘FBI’ list[7], as in ‘Can you F****** Believe It?’, passed down to me by an executive from a famous Canadian software company.

[6] ‘Minimum Viable Increment/Minimum Viable Product‘, from various implementations of Agile theory.

[7] Things that might linger on a list like this include things filed ‘Too Dangerous to Fix’, which are often interesting memoir fodder.

One Way to Run a Hackathon

A place that I used to work ran periodic ‘Hackathons[1]’. After trying to describe them to various people it became clear that there were a number of different definitions of what a ‘Hackathon’ could (or should) be, so here’s my description, with some thoughts as to why structuring it this way might be a good idea.

Definition?:
What is a ‘Hackathon’? It’s a lot of different things to different people. Most definitions I’ve seen see it as an opportunity to spend a day (often 24 hours, or a weekend) building something that they wouldn’t normally build. The thing built is not necessarily a ‘thing’. It could be a website, and app, some other type of computer program, it could even be an organization. The important thing here is that whatever is created/built is taken from the concept stage to working prototype with at least some useful feature(s) by the end of the hackathon.

Purpose:
Why do you want to have a Hackathon? The ones that I’ve been involved with were an opportunity for people in a software organization to try something a little different for a day. Some reasons they did it:
– Learning a new skill or programming language by building something ‘real’
– ‘Scratching that itch’, solving some problem that they never quite get the time or priority to solve in their day-to-day
– Working with people that they don’t normally work with
– Building a full product (instead of working on a tiny piece of a huge system)
– Building a visualization tool
– Doing something totally different

Those involved generally seemed to greatly enjoy the experience, the chance to work on something different, to push themselves in a new and different direction, and perhaps the chance to receive the acclaim of their peers.

How did it work?:

There was a committee formed to organize the Hackathon. They were responsible for:
– Publicity
– Getting buy-in from management (this had already happened, so this part was relatively easy)
– Convincing judges to judge the competition (These were usually senior people in the organization who were not part of a ‘hack’)
– Organizing the various parts of the event
– The ‘pitch’
– The presentations
– The prizes
– The voting for the ‘Audience Choice’
– A/V and some method for telling presenters their time was up (we used a stop light)
– Finding sponsors for any ‘Sponsored Hacks’
– All of the various other small things required to run an event like this
– Buying the pizza for the party after the presentations

How often did they happen?
– The Hackathons happened once per quarter, generally in the middle of the week

Schedule:

During the weeks before:
– Publicity, book rooms, perhaps plan food, plan A/V, location, etc.

A couple of days before:
– Run the ‘Pitch Session’
– Provide a place (usually a wiki page) for people to join groups following the pitches

The first day of the hackathon (The hackathon would run noon to noon, with presentations 3-4pm the following day):
– Start the hackathon, giving any support where necessary

The second day of the hackathon:
– Collect presentations, so they can be presented in a timely manner
– Collect the judges, so they can judge the competition
– Run the presentations
– Run the ‘Audience Choice’ vote
– Count the ‘Audience Choice’ votes
– Distract the people with pizza while the judges are deliberating
– Help the judges present prizes

Some more details:

A ‘Pitch Session’ is:
– Each person gets one minute to talk about their idea, in the hopes that they can attract a group of people to work on it with them. There was a rule that teams had to pitch something if they wanted to win ‘best hack’, to encourage them to participate in the pitches and include others

How are teams formed?
– Teams can be of any number of people, but we never saw a team of more than 12 people or fewer than 1 person[2].
– To encourage different parts of the organization to work together, each team would be awarded points for each group represented in the team. Including someone from ‘Customer Experience’ or ‘Marketing’ would be worth three points, while including people from Engineering (the expected default for a hackday) would be worth 1 point
– Teams, once formed are added to the hackday webpage, for posterity, and so people can coordinate (and so the organizers can coordinate collecting all of the presentations)

What happened during the 24-hour Hackathon period?
– During the 24 hours of ‘hacking’, people generally put their project work aside and work on their hacks. Some people were given more or less time to do so, depending on their particular management chain and the urgency of their specific work at hand. Of course, if a production issue cropped up in the middle of the day, that would have priority.

How did presentations work?
– Each team was given 3 minutes to present. Luckily, we had a traffic light that was repurposed to give an easily visible signal to presenters when they were running short of time.
– There was generally an audience, of the other people hacking, the judges, and whoever else wanted pizza later

How were they judged?
– ‘Best Pitch’ (a friend of mine routinely won this part, due to his uniquely hilarious presentation style)
– This was generally awarded based on presentation originality and style
– ‘Most Productizeable’ (Which hack was easiest to productize for customers, either internal or external?)
– ‘Best Hack’ (this is the ‘best overall’ category)
– Not necessarily the one that won any other category, but the best overall
– ‘Best Presentation’
– Similar to ‘Best Pitch’, but generally a higher level of polish (and humour) is expected
– ‘Best Sponsored Hack’
– This is like ‘Best Hack’, but restricted to the specific sponsored category
– Hacks would be graded on the criteria above by the judges, IIRC on a 1-10 scale. (There may have been other criteria which were then rolled up into the categories above. That would be up to any event organizers, should someone wish to take these instructions and run with them.)

How did ‘Sponsored Hack’ work?
– This was a later innovation after some people saw the power of the various hacks that had taken place.
– A person or persons within the company would put up money for prize(s) for the best hack that would fulfill certain criteria. There was one hack to link a system to a particular enterprise solution, and one hack to use a new internal API that had been developed
– There was generally only one ‘Sponsored Hack’ per hackathon, and it was a bidding contest to determine which one would be the official ‘Sponsored Hack
– We found that having super-clear criteria about what constituted a ‘successful hack’ was extra important when the prize money for ‘Sponsored Hack’ greatly outweighed the prize money for ‘Best Hack’

What were the prizes?
– Generally gift cards of some type, glory, and a trophy
– The gift cards would be in the $50-100 range for first place. The glory was the really important part.
– Part of the trophy process was the expectation that each group would modify the trophy in some way before presenting it to the next team at the next hackaton
– We had some issues with one of the sponsored hacks when the prize money reached into the hundreds of dollars, because we had not clearly defined ‘When is a hack good enough to be considered a successful hack?’, and the difficulty of the particular hack

What types of ‘hacks’ did you see?
– There were a number of visualizations of various parts of the system
– There were a number of creative front-end interfaces for various parts of the system
– There was a one-line fix to a bug, in a effort to win ‘most productizeable’ by already being in production
– There was a musical number
– Once, the entire team of interns worked together on a hack
– We had an issue with not being able to tell whether our non-bookable meeting rooms were occupied, so one group made some lights with door sensors to quickly communicate down the hall that a room was occupied or not
– And many others…

Pleaes drop me a line if you want to run one of these. They’re a lot of fun, and can really help people get to know others and build an ‘esprit do corps’ in an organization.

[1]Unrelated: ‘Stupid Hackathons‘, which have a *totally* different ethos…

[2]Even the ‘Automated PowerPoint Presentation’ hack required someone to give the presentation.

Energy Efficiency and the ‘Rosenfeld Effect’

Art Rosenfeld passed away two weeks ago. Most people would not remember him, but they have been affected by his simple observation in 1976 that a “proposed nuclear power plant would not be needed if refrigerators were required to be more efficient.”

Here you can see the effects on the energy efficiency in the state of California:

"The Rosenfeld Effect."
“The Rosenfeld Effect.”

Note how the energy expenditure per capita flatlines from the time he made the observation above. It was never one thing, but a lot of little things Turning off lights at night, higher efficiency furnaces and fridges and stoves. Higher efficiency lighting. Better windows.

These are the kinds of things which make a huge difference in aggregate (and he was a master at expressing how much of a difference each of them would make singularly, such as spending 20mins with light switches saves 100 gallons of gas over the weekend). These are the kinds of incremental changes which are slowly reducing the scourge of cancer[1]. These are the kinds of things which can reduce changes to the climate.

Thanks, Art. Let’s keep working and doing things a little more intelligently every day.

Art Rosenfeld, California’s Godfather of Energy Efficiency, Dies at 90

[1]This is a fascinating topic. Check out these graphs: https://www.google.ca/search?q=cancer+mortality+rate+historical

1997: The year they made Contact

20 years ago, I watched Contact in the theater with my family[1]. Tonight, I watched it again, with S.

To me, it held up well as a movie. All the characters were believable, and the science and the effects were well within the normal parameters of suspension of disbelief.

What struck me[2] was how hopeful a movie it was, that our better natures would win out, that our endless curiosity would take us places we’ve never imagined.

[Note that spoilers follow]

It’s always interesting the things you remember 20 years later. “Why not make two, at twice the price?” The destruction scene. The prime numbers sounding so ominously alien from the aether. The speaking through her father. The 18 hours of static[3].

Interestingly, I had remembered that 18 hours of static as being the vindication at the end of the movie, that she was not crazy, that something had indeed happened, but I had forgotten how much it was covered up.

The one (gaping) plot hole I had missed the first time around was the absence of study and testing before a human was sent through the machine. If you look at the history of the Apollo program, you see that it was preceded by Mercury and Gemini, with dozens of sequential missions, each testing new parts, to make sure that each part of the system and plan were well-enough understood to ensure successful missions. The idea that they would build a half-trillion-dollar system in Contact and not fully study it (especially if it’s generating strange EM radiation) before sending a human through it ‘strains credulity’. Even the EM it’s radiating would be a fantastic discovery for humans.

But I can understand how they would cut out things to make a move that was watchable, and which was able to spend its time focusing on the humans in the story.

The alternative view of events that the NSA directory was trying to convince people of at the end of the movie was reminiscent (for me) of the big con[4] at the end of ‘Watchmen’, albeit at the opposite end of the hope-fear axis.

Apparently, like Bladerunner, the ending was supposed to keep your doubt alive as to whether the events she experienced had actually happened. To me, it didn’t, as 18 hours of static (and whatever metallurgical data they could get from the sphere) would be enough to prove the story.

I laughed, I cried, I am full of hope. A new year dawns. Time to use that hope to build something meaningful, starting with some words.

[1]We immediately followed it with Men In Black. I’ll leave it to you to enjoy this juxtaposition.

[2]If you’d read or watched any Carl Sagan, this would probably not be surprising. “The sky calls to us. If we do not destroy ourselves, we will one day venture to the stars.”

[3]I had remembered it as 18 minutes.

[4]In ‘Contact’, it was posited that a billionaire had faked first contact to inspire humans to push themselves outwards. In ‘Watchmen’ (the graphic novel[5]), Adrian Veidt fakes an alien invasion to scare humans into working together against a common foe.

[5]’Watchmen’ the movie simplified the plot to have Doctor Manhattan be the scapegoat. this lead to a much tighter movie, but slightly less appropriate for my analogy, however much he played with space and time.

Why the Headphone Jack Must Stay

Yesterday, we had a date night, and over dinner, we thought “Wouldn’t it be nice to watch Contact? Neither of us have seen it since it came out, almost 20 years ago.”

First, we opened up Netflix, and searched for ‘Contact’. It wasn’t available there, but Netflix said it could show us movies similar to it. (It also showed us ‘Star Trek: First Contact” as an option, more on that later.)

So, we try iTunes. We’re trying it on my computer, because S’s Mac has mysteriously stopped talking to our USB speakers. Fast-forwarding through the standard iTunes bad user experience[1], we eventually figure out how to rent ‘Contact’, the movie, in HD for $4.99. It starts downloading. We hook up the projector, start the movie, and we see the following screen:

This is what happens when you try to use iTunes with your projector.  (Not shown: Our USB speakers stopped working just then, too.)
This is what happens when you try to use iTunes with your projector. (Not shown: Our USB speakers stopped working just then, too.)

The movie that we just paid money to rent will not play on a display that iTunes was more than happy to play on just a couple of years ago.

Think about what just happened here. We went to the extra effort of purchasing a movie rental, and it is treating us like we’re trying to pirate it.

Doing some quick googling, we determine that we might be able to get the SD version to work with our setup, but iTunes won’t let us change from HD to SD (and keeps trying to download the HD version, despite the fact that this will overfill the hard drive).

So, back to Netflix. We eventually settle on Firefly (a really interesting concept, more on this in a later post). Netflix just works.

Or at least Netflix tries to work. Somewhere during this process, my Mac has silently decided that it should no longer talk to the USB speakers. There being no useful way to debug this in the ‘System Preferences’ menu, we end up lugging my sound system from my computer, which has a headphone jack connector like so:

Headphone jack to RCA adapter.  The best way to get sound from your computer to serious speakers.
Headphone jack to RCA adapter. The best way to get sound from your computer to serious speakers.

The headphone jack connect works. We finally start to relax, I start watching Firefly for the first time, then we watch the masterpiece which is Star Trek: First Contact, and go to sleep happy.

Apple has a lot of power, through its massive market share and avid user base. This power can be used for good, such as when it is used to push for selling DRM-free music, but it can also be used for evil, such as when Apple Music deletes music that you have composed.

With the iPhone 7, Apple is using this power to no longer include a standard headphone jack. Now all music, audio, Stripe payments, what have you, will be streamed digitally. It will probably work, it might even work perfectly and for a long time. But at some point, someone will decide to add DRM to that stream, and all of a sudden your music will stop working.

All because Apple decided to remove your headphone jack.

Cory Doctorow also has some thoughts about this.

[1]iTunes standard bad experience:
– You have to search twice in the search bar for it to actually search
– The search function has a pre-defined list of types of media, and it will always show them to you in that order. Compare with the Google search for ‘Contact’.
– If you start downloading a rented HD movie, you can’t switch to the SD version, even if you realize you don’t have enough hard drive space, or the HD movie won’t play because of the HDCP DRM.
– And don’t get me started on how slow it always is.

Burning Man in Pictures 2015 XLVIII: ‘Edal Bump’

When we last saw our heroes, they were flying towards their fiery demise and keeping Curiosity company.

Today, we follow them on their random-walk journey through an eclectic assortment of things that Burning Man has to offer.

First, the (slightly creepy) dancing bears! They seemed just a little *too* happy…:

The (slightly creepy) dancing bears!
The (slightly creepy) dancing bears!

Found! A public service for all of those lost items. Remember, only MOOP[1] is truly lost (and all lost items are MOOP):

Found!  (Only MOOP is truly lost at Burning Man.)
Found! (Only MOOP is truly lost at Burning Man.)

As you may guess, Mad Max is a common decorative theme:

Another example of Mad Max-like architecture.
Another example of Mad Max-like architecture.

This structure seemed to serve as a warning. Our heroes shied away, after being burned by objects like this in the past[2]:

But what it trying to warn you about?
But what it trying to warn you about?

Needing a breather, they stopped at the Steampunk Saloon:

Steampunk Saloon!  (Tents like this are marvelous shade structures.)
Steampunk Saloon! (Tents like this are marvelous shade structures.)

On their way again, they biked along the Esplanade, marveling in the experience:

Riding along the Esplanade, trying to capture the feeling.  (Also, wide 'playa tires' in the foreground.)
Riding along the Esplanade, trying to capture the feeling. (Also, wide ‘playa tires’ in the foreground.)

Along the way, they passed a strangely-named structure, ‘Edal Bump’:

'Edal Bump'.  'What does "Edal Bump" mean?'
‘Edal Bump’. ‘What does “Edal Bump” mean?’

Going slightly further, it made much more sense[3]:

'Ah.  "P-Edal Bump".'
‘Ah. “P-Edal Bump”.’

“Bad Advice”, or “Really Bad Advice”? Which would you choose? Which one would you be more likely to follow? Which would be worse?

Stay clbutty, Burning Man.
Stay clbutty, Burning Man.

And then, in the distance, our heroes spot the destination they didn’t even know they were heading towards, The THUNDERDOME!:

Like a rain god, S spots the Thunderdome off in the distance!
Like a rain god, S spots the Thunderdome off in the distance!

Next time, THE THUNDERDOME! Also, up close and personal with Serpent Mother! Stay tuned!

[1]’Matter Out Of Place’, the reduction of which is central to the ethos of ‘Leave No Trace’, a fundamental ethos of Burning Man. Painstaking inch-by-inch MOOP search and removal is a part of every camp’s responsibility. (Another important part of the ethos is avoiding MOOP, and picking it up anywhere you see it during the festival.)

[2]It does bear an uncanny resemblance to the ‘nuclear waste spike field‘, a hypothetical structure to deal with the very real problem of warning future generations about the problems of nuclear waste.

"‘Spike field’: An early idea from the US Department of Energy in the 1990s. The spikes and their shadows would communicate danger, as would warning signs bearing Edward Munch’s 'The Scream' scattered across the site" - http://www.ft.com/cms/s/2/db87c16c-4947-11e6-b387-64ab0a67014c.html
“‘Spike field’: An early idea from the US Department of Energy in the 1990s. The spikes and their shadows would communicate danger, as would warning signs bearing Edward Munch’s ‘The Scream’ scattered across the site” – http://www.ft.com/cms/s/2/db87c16c-4947-11e6-b387-64ab0a67014c.html

[3]Not to mention why there were so many bicycles in the area (although there could be many reasons for that at the Burn).

Trolley Problem Memes

Trigger warning: Conversation and possibly dark humour about fictional (and possibly not-so-fictional) people dying in car and train accidents.

How do you design a self-driving car to appropriately value human life? Can you use a Facebook group to speed the development of philosophical discourse?

The ‘Trolley Problem‘ is a problem in ethics, first known to be described in its modern form in the early 1950s. Basically, it boils down to the question:

If you have a choice between action and inaction, where both will cause harm, but your action will harm fewer people, is it moral to perform that action?

Interestingly, people answer this question differently, based on how active the action of harm is, the ratio of people hurt between the choices of action and inaction, and other reasons.

The astute will notice that this type of decision problem is a very common one, the most obvious being in military applications, but also vaccines (and invasive health procedures in general), firebreaks, and perhaps the canonical example, automobile design and manufacturing.

This type of decision making has become even more important with the advent of self-driving cars:

Would you drive a car that would choose to drive you into a brick wall rather than run over five pedestrians?

Overall, you would think that this would reduce your risk of fatality, but few people would choose that car, likely because it is a classic prisoner’s dilemma[1][2].

What is your self-driving car's ethical system?
What is your self-driving car’s ethical system?

Personally, I think that much of this conversation is sophistry[3]. If one is truly interested in preserving life, the solution is not to convince self-driving cars to kill different people, but perhaps to have more stringent driving training requirements, to invest in fixing known problem intersections, to invest in better public transit.

So, if these conversations are not useful for anything else, they must be useful in and of themselves, and therefore must be Philosophy[4]!

One of the places that these conversations are occurring is the ‘Trolley Problems Memes Facebook page‘[5].

Now, you can argue that this page is purely for entertainment, but I think there’s a lot more hidden there. There is a fomenting and interchange of ideas, much faster and more fluidly than at any time in history. The person who writes the next book[6] on the ethics of decision making could well be influenced by or be an avid user of a site such as this one.

They may have started with Rick-rolling, but image macros are helping the advancement of human knowledge. Stew on that one for a while.

And while you’re thinking about that, something which ties it all together[7]:

"The creator might argue that his robot is an 'individual', capable of his own decisions, while the opposition would say that he (the creator) is responsible for the algorithm that led to the action. Imagine this happening - it would give birth to one of the greatest on-court debates ever." From Patrice Leiteritz via Trolley Problem Memes
“The creator might argue that his robot is an ‘individual’, capable of his own decisions, while the opposition would say that he (the creator) is responsible for the algorithm that led to the action. Imagine this happening – it would give birth to one of the greatest on-court debates ever.” From Patrice Leiteritz via Trolley Problem Memes

[1]If everyone cooperates, overall they will receive a better result, but if any one of them betrays the others, they get an even better result, but everyone else’s result is much worse. This theoretically leads everyone to betray everyone else, leading to everyone having a worse overall outcome.

[2]People also like the feeling of control.

[3]Check out the article. Apparently, the Sophists were the first (recorded) right-wing think tanks.

[4]My undergrad Philosophy 101 prof. made the argument that because philosophy was not useful for anything else, it must be inherently be useful (and that that was better).

[5]Dark humour. You have been warned.

[6]And it might not even be a book! A blog post, even! 😀

[7]Not a deliberate pun.

How do You Think Before You Speak?

I’ve talked a lot about the speed involved and possibly required for retorts and humour, but not all conversation is retorts and counter-retorts[1].

For example, you’re giving a speech or lesson, and someone asks you a question. Many of the same tactics are helpful. It’s helpful to know your audience, to have an idea of their background(s), which types of words will work best for explaining things, and to have an idea of what they perceive the relative level of hierarchy is between you and them.

But once you have an idea of these things, what do you do?

This trigger for this post was an article reporting on Jon Stewart talking about how Hillary Clinton pauses for a few seconds between a question and when she answers[2]:


…“It’s — look, there are politicians who are either rendering their inauthenticity in real enough time to appear authentic, and then their are politicians who render their inauthenticity through — it’s like, when your computer … if you have a Mac and you want to play a Microsoft game on it …”

AXELROD: Yes, yes.

STEWART: … and there’s that weird lag.

AXELROD: Yes. No, I mean …

STEWART: That’s Hillary Clinton.

AXELROD: … that’s a big problem. There’s like a seven-second delay and all the words come out in a perfectly …

STEWART: Right.

AXELROD: … politically calibrated sentence.

STEWART: Right. Now, what gives me hope in that is that there’s a delay, which means she’s somehow fighting something. I’ve seen politicians who don’t have that delay and render their inauthenticity in real time, and that’s when you go, ‘That’s a sociopath.’

So, when you’re answering a difficult question, do you pause? Why? For how long?

For me, it depends on the type of question. For emotionally difficult questions, some of it is finding a neutral[3] perspective from which to address the question, to speak to the person(s) asking the question in a positive and useful way. Sometimes it’s choosing the appropriate emotional outlet[4] for whatever I’m feeling at the time.

For technically difficult questions, it feels much more like assembling a mental model in my head, or choosing between different visualizations/places to start. Parts of this can feel similar to emotionally difficult questions (perspectives vs. visualizations), but to me they feel quite different[5].

So, how does this work for you?

[1]No matter how much bash.org would want you to think so. (Note that outside that page, bash.org is quite unfiltered internet. You have been warned.)

[2] Article is here. In a footnote because the editorializing in the article is outside the scope of this post.

[3]In the emotional perspective sense.

[4]This is often laughter for later when I’m alone. I mean, really, we’re just ape-like creatures who don’t know the first thing about ourselves. Why are we getting all angry about minutiae? This can only be funny.

[5]Now that I say this, I’ll have to watch next time. But something getting my back[6] up really feels different from trying to focus and assemble a visualization. Maybe being able to relax for all types of questions would make them more similar.

[6]Back hackles?

Slide Rule Accuracy and F=ma

Earlier this week, we were talking about drawing a Large diagram as one of the lasting and important things I learned in Prof. Collins’ Structure & Materials course.

Here are some of the others:

‘Slide Rule Accuracy’

This is the idea that in the real world[1], you’re never going to use more than three digits of accuracy (or four if your number starts with a ‘1’)[2]. Beyond that, things will get lost in the noise, or other inaccuracies, whether it’s budget contingencies, manufacturing defects, or whatever. (It would be interesting to see whether this has changed for manufactured parts with increased automation.)

The ‘3 laws of engineering'[3]:

1) F=ma

Simple, yet profound. When you’re dealing with non-relativistic systems (pretty much all of them), you push on something, it will move or react proportionally. This is not limited to physical systems.

2) You can’t push on a rope.

Also simple, has a number of applications for mechanical systems, but is probably the most ‘Engineer-y’ useful statement for dealing with other people.

3) In order to solve an engineering problem, you must first know the solution.

This one doesn’t really make sense on first blush, but I’ve experienced it. I mentioned earlier that the brain is often a structure that problems flow through, and in a sense this is a statement of that. You’re going to try to fit a new problem you’re looking at into the structure(s) of all the problems that you’ve seen before, and you have a huge advantage if you’ve seen similar problems before, or seen other problems you can apply by analogy.

We also had a ‘notebook’ that we put all of our class notes in, including cut and pasting from technical sheets, and this ‘notebook’ was our open book for the exam. It was a great exercise in focusing note-taking and coalescing your thoughts onto a medium-small piece of paper.

“When someone is paying you $100 for an hour of work, it’s worth paying a few extra cents for a good sheet of paper to give it to them on.”

The course had special ‘engineering notepaper’ that they wanted us to hand problem sets in on. There wasn’t any penalty for not doing so, but the lesson was that a little bit of professional presentation went a long way.

[1]This is when you’re dealing with things of reasonable size. I’m guessing when you’re looking at gravity waves or Higgs bosons, you might be using somewhat more accuracy. But at the same time, you’re probably not really looking at more than the last few digits…

[2]This is one of those subtle things which is actually quite important and powerful. On a slide rule, the portion which starts with a ‘1’ is fully 30% of the length (log10(2) ~=0.301), so unless you use the fourth digit here, you’re losing a substantial portion of your accuracy. There is a better explanation of this here:

[3]For a slightly different set of three Engineering laws, look here: