I've seen all sorts of humor, tips, and ideas from folks as we all
learn to cope with these strange times, but somehow I don't feel like
I've had a lot of insight into the practicalities of family life for
folks in a similar situation to us. So, five days into our new
situation, I thought I'd share.
Who are we? We're a family of two adults with full-time jobs, two
young girls (9yo and 4yo), and a recent addition of a 4 month old
Miniature Schnauzer. We live in Dublin, in the coastal village of
Usually, our kids are looked after Monday-Friday between 8.30am and
6.30pm each day (school, creche, childminder at home) and we have some
outside help with housework. Lucky us! Starting Friday, March 13,
we're learning to cope without any of that help, while continuing to
work our two busy and responsible jobs from home.
So, last Thursday evening, we found ourselves in front of a whiteboard
trying to come up with a plan. Our basic idea was:
We needed a predictable daily routine to keep everyone sane
We'd experiment with keeping that routine 7 days per week, and not
adjust much at weekends - this was to avoid putting ourselves on too
much daily work pressure with a strict 5 day work week
Each of us would get a uninterrupted chunk of 4-5 hours work time
every day, either in the morning or afternoon
One parent at a time looking after the kids, not attempting to get
any work done at the same time
Start every day with one of us leaving the house by 9.30am with the
kids and dog, to visit any one of the local parks and beaches
Early to bed, early to rise - no compromising on sleep!
We'd carve out uninterrupted time alone for short at-home workouts
The key question each evening for the next day is which of is working
in the afternoon (Parent A), and which of us is working in the morning
(Parent B). With that decided, we know the routine.
Wake up, coffee, email
Kids up, prep breakfast
Get everyone ready, housework
Adventure with kids and dog at a park or beach
Housework, free time for kids, ideally 4yo naps!
Arts & Crafts
Family play time
Kids: screen time, and off to bed Parents: email on the couch?
National evening news
This has been working reasonably well, with some caveats:
The "uninterrupted" chunk of work time is your main opportunity to
do anything that would be difficult to do with the kids -
e.g. workouts, grocery shopping, etc.
We're not robots, so the schedule does flex - e.g. the snooze button
is as tempting as ever, and I'm probably playing too much Minecraft
with my eldest!
It can be hard to organize all work meetings in your chunk of work
time, so we do adjust a bit for super important meetings that don't
It's only day five!
Reading back through this, it's clear this will be quite a grind if it
continues for more than a few weeks. But we have so much to be
grateful for, and there will be many others with far worse to deal
with. Take care of yourselves!
As part of switching gears at work from a hectic management role back
to an "individual contributor" role as a software engineer, I've read
a couple of books based on recommendations from friends. First, It
Doesn't Have to be Crazy at work by
Jason Fried and David Heinemeier Hansson (thanks Paschal!) and,
second, Deep Work by Cal
Newport (thanks Fred!). Below is my attempt to summarize some key
points I'm taking away from these books, if only to prove to myself
that I was concentrating!
Why "deep work"?
The ability to quickly master hard things, and to perform at an
elite level in terms of qulaity and speed, will set you apart
On choosing what to work on:
Deliberately work on getting better at picking what to do
Don't simply work on things that are easiest in the moment
Understanding what really matters - embrace "good enough" for the
less important things
Drucker - "There is
nothing so useless as doing efficiently that which should not be
done at all"
Downtime helps recharge the energy needed for deep work -
Attentional Restoration Theory
establishes that - like willpower - we have a limited store of
"directed attention" that needs to be recharged
The work that would replace downtime tends to be shallow and
unimportant - if you have the capacity for, say, a maximum of 4
hours per day of intense concentration, you're not going to squeeze
more focused time out of downtime
On the type of co-worker you aspire to being:
Aim to leave a lasting positive impression on people
Be a good person that others can rely on and enjoy working with
Set an example for others to follow
On living a good life though depth:
Aspire to a craftsman's work ethic - finding a connection between
deep work and meaning in your life, as a path to living a good life
Add a "shutdown complete" ritual to end your workday
Put a hard constraint on your work day - e.g. finish consistently at
Managing distraction, and thoughts on social media:
Make a daily mental practice of weaning your mind from a dependence
on distraction - got a free moment? Don't pick up your phone,
essentially begging it to distract you
Take a complete break from social media (or "distracting services",
more generally) and only re-enable them as you find you need them
Avoid taking an "any benefit" approach to how you consider the value
of these services - consider the opportunity cost, what else you
could be doing instead
Schedule the use of these distracting services
Networking tools are just tools - they can be used to enhance your
professional work, but you should assess their impact in terms of a
small number of goals and activities in the vein of "the vital few"
or the 80/20 Pareto
Try bringing your attention back again and again to a pressing
problem as you are occupied physically - this requires practice
Avoid distractions from the problem at hand, and avoid looping on
information you already know
Structure your deep thinking:
Identify the variables, identify the next step question, and then
consolidate your gains
Set yourself a "shallow work budget":
What proportion of your time is acceptable to spend on "shallow work"?
20%? 50%? 80%?
This gives you a heuristic for saying "no" to shallow work
Evaluate the shallowness of your activities by how long it would
take to train a bright, recent college graduate to do it
You should aim to reduce the amount of time spent not using your
Fixed deadlines, but allow the scope to be reduced - "narrow as you
Break big projects up into smaller chunks - "scope hammer"
Use time budgets, not time estimates - "what's the best widget we
can build in 2 weeks", not "how long will it take to build a
Realtime sometimes, async most of the time
If it's important, slow down
If everyone needs to see it, write it down
Become hard to reach:
Make people who send you email do more work
Avoid making it easy for people to rob big chunks of your time with
little investment of their time
"Process-centric approach to email" - with your reply, consider what
will bring the project represented by the email to a
conclusion. Avoid bouncing back and forth
Develop the habit of accepting that small, bad things happen, for
example if you don't reply to email. If you don't allow small, bad
things to happen, then you won't leave room for good, big things
Reject crazy, distracted, and shallow. Embrace calm, focused, and deep
Deep work is important simply because it enables you to get useful
"I'll live the focused life because it's the best kind there is".
Disclaimer: Relative to my expertise in something like OpenStack, or
relative to the expertise of folks who are working daily on driving
advancements in the fundamentals of Blockchain and related
technologies, I know next to nothing about Blockchain. However,
relative to the average member of the public, I believe I have enough
understanding as a technologist to help demystify the subject for
The context for this post is that I attended the recent Climate
Innovation Summit in
Dublin, which primarily focused on the challenge of financing
solutions in the area of Climate Change mitigation and adaptation. To
my surprise, the subject of Blockchain seemed to be the main pure
technology topic that came up again and again.
Before this event, and without exploring the area too deeply, I had a
suspicion that Blockchain is all too often "a solution in search of a
problem". This all too common tendency of technologists makes me
grumble at the best of times, but when the subject is a technology
that is impenetrable to many people, and the problem space is what I
believe to be an existential threat to our way of life ... I have
grave reservations, to put it mildly.
Blockchain is designed to be an alternative to centralized
systems. What does that mean? Well imagine:
A database with no central administrator
A currency with no central bank
A contract that is enforceable without recourse to a judiciary
and you start to get a sense of this problem space. This is quite
appealing, on the face of it. A decentralized system should be more
fault tolerant and attack resistant because there is no single point
of failure, and it should also be more trustworthy and resistant to
abuses of power because of the transparency it offers.
Scaling human traditional institutions in a reliable and secure
manner requires increasing [the number of] accountants, lawyers,
regulators, and police, along with the increase in bureaucracy,
risk, and stress that such institutions entail."
Solving problems without needing any more lawyers? Hurrah!
Why is Decentralization a Hard Problem?
The Climate-KIC report does a nice job of explaining the 5 components
of this solution to the decentralization challenge:
Cryptography - public key encryption and hashing functions allows
protecting the privacy, integrity, and even the anonymity of data in
the system. This is familiar technology used in secure websites with
HTTPS, for example.
Hash tree - this is
simply a list of records whose integrity is protected by a
cryptographic hash on each record which combines the hash of the
previous record, a timestamp, and the transaction data. This is a
well-understood concept that is used to good effect in systems like
the Git Version Control System
Peer-to-peer networks -
this is allows you to build resilient storage by having peers in a
network replicate data to other peers. Heard of Napster and
mechanism - how can you authenticate and validate a transaction
in a peer-to-peer network without appealing to a central authority?
Take a look at the Byzantine General's
Problem. It's difficult.
Sybil control mechanism - how do you protect against an actor in
the system generating a large number of fake identities, known as a
Sybil attack. This too
is hard. Bitcoin's answer is to make it prohibitively expense to abuse
the system this way, with its "Proof of Work" system known as mining.
The first three components - cryptography, hash trees, and
peer-to-peer networks - are well established, and it would be possible
to use them to build an effective, highly-distributed database with
the aid of a central authority (to e.g. decide who can be trusted to
write to the database).
However, to make that database fully decentralized - especially with
anonymous actors writing to the database - some really difficult
challenges are introduced, and that's where the consensus and Sybil
control mechanisms come in. These are much more challenging problems,
and Blockchain is one relatively recent foray into this area.
Note - in the report, the "Do you need a Blockchain?" flowchart
highlights the idea of a "Permissioned Blockchain" suitable for a case
where all actors are known but untrusted. That does eliminate some of
the difficult problems in this space, but catering for untrusted
writers is where much of the complexity remains.
Note also - the report also references an excellent article called
The Truth About Smart Contracts by Jimmy
which highlights the challenge with attempting to specify and enforce
the rules of a contract using (potentially buggy) computer code
without allowing for appeals to a central authority to interpret the
"spirit" of the contract. And also the challenges of attempting to
link such decentralized contracts with the physical world.
Given the challenges that full decentralization brings, it's not
surprising that Blockchain has some drawbacks. To quote some of the
points that jumped out at me in the Climate-KIC report:
DLT is a highly inefficient database technology that is up to 1
million times less efficient than a centralised database, which in
turn leads to much higher energy consumption and GHG emissions.
Given that we're talking about Blockchain in the context of Climate
Change mitigation, that seems important to consider!
the trade-off between low energy efficiency and higher levels of
decentralisation is the key question in the DLT for climate action
ecosystem and needs to be addressed for each potential DLT solution
Blockchain's inefficiency and higher emissions should be weighed up
against a need for decentralization.
To determine whether DLT is the right tool to solve a given problem,
it should be validated that DLT is the only solution to the given
problem. If DLT is not the only solution, also a more efficient
centralised database can solve the problem.
In other words, you should only consider Blockchain if you've already
eliminated the possibility that a centralized system could be
A more entertaining take on whether Blockchain is a good fit for your
application, from James Mickens:
How Important is Decentralization To Addressing Climate Change?
This is the key point. As Kirsten
Dunlop said in her keynote at the
Climate Innovation Summit:
We have 12 years to set in place profound structural change in
almost every system of cause and effect in our society
Some of "Climate Action" use cases and examples for Blockchain listed
in the Climate-KIC report includes:
Energy - peer-to-peer energy trading
Supply chain management - reduce paperwork, fraud, and errors
Carbon trading - a more transparent carbon marketplace
Transportation - decentralized ride sharing
Open government - increased transparency and accountability in
Measurement Reporting and Verification (MRV) - more transparency
in carbon tracking
Finance - new ways of financing climate projects
More or less implied here is that the problems associated with
centralized systems are on the critical path to effectively addressing
these use cases.
The Climate-KIC report says:
While climate change is a truly global problem, it is well
recognised that it requires a decentralised, multi-stakeholder,
bottom-up approach to be solved
And that's hard to argue with! I'm a big proponent of bottom-up
innovation guided by a unifying mission, and certainly such a huge
problem space can't be tackled top-down. Mariana Mazzucato's report on
Mission-oriented research & innovation in the European
looks like an excellent framework. And when it comes to Climate
Change, we are all stakeholders.
But ... does that really imply that the technology platforms we use
must be decentralized? For example, a crowd-funding platform hosted by
a single legal entity can still be effective, without itself being
decentralized. Can a sufficiently high level of trust and transparency
be achieved without fully decentralizing the platform? I believe that
is often the case.
To quote the Climate-KIC report again:
DLT’s main power lies in decentralisation. It currently is unclear
how the physical centralised world can be decentralised. [...] As
many climate action solutions are more valuable when synchronised
with the physical world, this barrier is a key barrier to overcome.
Decentralization and anonymity brings up some pretty fundamental
questions about how human society is organized. And undoubtedly,
tackling Climate Change effectively is going to require fundamental
changes in our society. As Naomi Klein put it, This Changes
But are the problems that Blockchain claims to solve really the key
problems getting in the way of effective Climate Change mitigation and
adaptation efforts? Even if they are, are there other "good enough"
solutions without the drawbacks of Blockchain that can be deployed
What I really worry about here is the danger that Climate Change will
be perceived by some as a smokescreen for people pushing pre-existing
agendas that aren't strictly related to the challenges posed by
Climate Change. To take a more extreme example, how likely are we to
mobilize the sort of action needed if people sense they are also being
asked to buy into Anarchism as a political philosophy?
There is no doubt that Blockchain is a super interesting technology,
and it has opened the door to exciting advances in some truly
difficult computer science problems.
If you are motivated to explore how technology can be used to move
towards a more decentralized society, by all means you should go down
the Blockchain rabbit hole!
However, if you are primarily motivated to rapidly implement Climate
Change mitigation and adaptation solutions in the real world, I would
suggest that you can safely focus your limited resources on
technologies other than Blockchain.
The usual disclaimer applies - this my informal recollection of the
meeting. It’s not an official record.
Foundation Events Update
We began with an update from Lauren, Jonathan, and Mark on the events
that have happened so far this year, the Project Teams Gathering (PTG)
in Denver this week, and the coming OpenStack Summit in Sydney.
Lauren outlined some details of the recent Pike release, emphasizing
the positive media coverage of the release, with the "composable
Jonathan talked about the many OpenStack Days events that happened
over the summer, including Melbourne, Tel Aviv, Budapest, Korea,
Taiwan, Japan, and China. Jonathan has attended all of these, covering
13 countries since the OpenStack Summit in Boston and he spoke about
the many new users and new use cases that he learned about over the
course of these events. More OpenStack Days are
including Benelux, UK, Italy, Turkey, Nordic, Canada, France, and
Mark spoke about the OpenDev event held
the previous week in San Francisco. The goal was to bring in people
who are experts in different domains, and the important and emerging
use case of "Edge Computing" was chosen for this first event. The
keynote from Dr Satya of Carnegie Mellon
University was mentioned as one
particularly inspiring contribution.
An particularly interesting conclusion from one of the
was a simple definition of what Edge Computing actually is:
Edge is the furthest boundary that separates application-agnostic
scheduled computing workloads within the same operator's domain of
control, from applications or devices that can't schedule workloads,
and are outside the same operator's control.
The PTG was touched on next - more
than 400 contributors in attendance from 35 project teams, with the
first two days focused on the strategic goals of simplification,
adjacent technologies, onboarding new contributors, etc.
Back in March, at the Strategic Planning Workshop in
we developed a set of 5 strategic focus areas and formed working
groups around each of these. For each of those focus areas, the
working group presented their findings and progress, followed by some
Better communicate about OpenStack
Thierry Carrez and Lauren Sell lead the discussion of this topic with
a set of
We began by discussing progresson developing a map of OpenStack
deliverables. The idea is for the map to make it easy for users of the
software to make sense of what OpenStack has to offer, and one key
part of this mapping effort is to categorize deliverables into
openstack-user: Things an end user installs to consume the IaaS
openstack-operations: Things an operator uses to manage an openstack
cloud once installed
openstack-lifecyclemanagement: Things that help deploy/upgrade
OpenStack or standalone components
openstack-adjacentenablers: Things that other infrastructure stacks
can use to leverage individual OpenStack components
Some of the outstanding questions include how to represent projects
which are coming down the line, where various types of plugins should
live, and whether Glance is tied to Compute or should be represented
as a Shared Service.
Next, we discussed at some length how OpenStack has been affected by
"Big Tent" concept where we welcome collaboration, experimentation,
and innovation on "infrastructure things" beyond the core OpenStack
technology. We've know that users have found it difficult to make
sense of the breadth of project teams, and we have created further
confusion around "what is OpenStack".
Our discussion on this revolved around the idea of separating the
technologies directly related to the deliverables map above (which we
could call "OpenStack IaaS and friends"), the "software forge"
infrastructure project, and the
free-for-all project hosting area previously known as
Stackforge. There was broad consensus that we should give each of
those its own identity, which is particularly exciting when you think
of the potential for "Infra" to have an identity that isn't so closely
tied with OpenStack. We also discussed the potential to extend this
model to other projects in the future, but also our desire to not
become a "Foundation of Foundations" or a collection of entirely
The focus of this discussion was on the creation of OpenStack Special
(SIGs) as a mechanism
to have cross-community collaboration on a given topic, without the
work being under the umbrella of any one governance body.
The SIGs created so far are:
a Meta SIG to discuss how to improve SIG processes
a still-forming Ansible SIG, with the goal of facilitating
collaboration between Ansible and OpenStack projects.
On this topic, Steve Dake talked us through some efforts to help grow
the next generation of leaders in the OpenStack community, supporting
people who wish to become a core contributor or PTL. Steve
particularly highlighted efforts along these lines within the Kolla
Increase complementary with adjacent technologies
Steve Dake again took the lead on presenting this
focusing on success stories of collaboration between OpenStack and
other communities - Ansible and Helm, in particular.
For Ansible, it was observed that OpenStack has built upon Ansible's
highly reusable technology in many ways, and OpenStack members have
contributed significantly to the Ansible modules for OpenStack based
on Shade. The conclusion was that the success was down to (a)
building releationships between the communities, (b) leadership
endorsement, and (c) the simplified collaboration process adopted by
For Helm, the collaboration has been focused in areas where Helm is
being used to deploy OpenStack services on Kubernetes.
For our final strategic focus area, Mike Perez gave an
update on progress. He
described projects which have recently been retired, the OpenStack
manuals project migration, and the status of a number of projects who
are seeing low levels of contribution activity.
Clarifying and communicating where help is needed
Next up, Thierry walked us through the TC's mechanism for exposing
areas where help is needed in the community. We talked through this
"top 5 help wanted
and had a good discussion on the two items currently on the list -
Documentation and Glance.
The first item of business was to approve the 2017.09
guideline. Both the compute and
object components gained some new capabilities in this update.
As discussed in the previous
the working group proposed the creation of "add-on" programs which
would focus on interoperability between different implementations of a
given service, without having to add that service as a requirement in
the core OpenStack Powered programs. As a starting point, it was
proposed to create advisory add-ons for DNS
(Designate) and Orchestration
(Heat). After some
discussions on the implications of these additions, they were formally
approved by the board.
The topics of the discussion are laid out in the working group's
with Egle covering the upcoming 2017.08 guideline, Mark covering the
proposal for extension programs, and Chris covering version 2.0 of the
The extension programs proposal
resulted in the most discussion. Mark described how the proposal
explains how the OpenStack Powered trademark programs work today, the
history of those programs, and how the additional programs would work.
The first type of program is a "vertical" program - examples given
include "OpenStack Powered for NFV" or "OpenStack Powered for
Containers". These would add requirements for additional capabilities
specific to these use cases, provided those capabilities are already
widely deployed in the context of those use cases.
The second type of program is an "add-on" program - for example,
"OpenStack Powered DNS". This would require capabilities specific to
that service, and ensure interoperability between implementations of a
given service. It is anticipated that individual project teams would
be responsible for definining the interop requirements.
Anni asked how these programs would relate to the idea of
"constellations" as a way of describing OpenStack components, but the
working group didn't see any immediate overlap with that idea.
I raised a concern that if obscure projects are free to define add-on
programs of their own, it could dilute the value of the OpenStack
Powered programs overall. However, it was clarified that, while the
individual project teams could define interop requirements, each
individual new program would require board approval.
Anni also raised a concern that vertical programs should not be
exclusive - i.e. it should be possible for a single product to qualify
for all vertical programs at once, so these programs need to not have
conflicting requirements. The working group agreed with this, and
explained that they had already taken this feedback into account.
Finally, the working group explained that their goal is for the board
to approve this framework at our Fall meeting.
The last topic for the board to consider was some membership changes
and applications. Put simply, Canonical wished to move from being a
Platinum member to being a Gold member, and Ericsson wished to apply
for Canonical's Platinum member slot.
Chris Price presented Ericsson's case for Platinum
membership. Interestingly, this was the second time that Ericsson had
applied for Platinum membership in the past year. The previous time,
at the March 9 board
Ericsson and Huawei applied for the slot left vacant by HPE. Huawei
was successful with their application that time around.
Chris explained Ericsson's vision for OpenStack, and how they plan to
continue developing and driving forward the OpenStack ecosystem. He
also explained Ericsson's role in working with adjacent communities
like OpenDaylight and OPNFV, as well as their role in related
Next up, Mark Baker described how Canonical felt that with several
"industry giants" looking to take up Platinum membership, that the
right thing for a smaller entity like Canonical to do from a community
perspective, was to take a step back and allow others with greater
resources to take their Platinum member slot. However, he also
emphasized how OpenStack remains at the core of Canonical's business.
After some brief questions, the board went into executive session and,
on return, both applications were approved.
The board's next meeting is a 2 hour conference call on Tuesday,
August 22. Our next in-person meeting will be in Denver on Sunday,