Month: July 2017

How to spot a heart attack

How to spot a heart attack

I keep these notes sellotaped to a packet of aspirin.

I did a three-day St John’s Ambulance First Aider training course, and there I learnt that there is only one type of medicine I was allowed to give someone in need: If I suspected someone was having a heart attack, I could give them 300mg aspirin (checking first for allergies), to chew slowly or dissolve under their tongue.

Here is the crucial info to know about heart attacks. Worth printing out and keeping somewhere handy. It’s also worth keeping aspirin handy.

More info here.

  • Signs of heart attack:
    • Not always chest – can be radiating jaw pain
    • …or high abdomen, or arms / shoulders
    • Sense of impending doom
    • Gasping for air
    • Going grey
  • What to do:
    • Don’t move them
    • Put in Lazy W position (see below)
      • Put support under knees
      • Give something to lean against
      • This might have to be you! Sit on your knees and let them lean against you.
    • Give 300mg of aspirin
      • Chew slowly
      • Or dissolve under tongue
      • Check for allergies first
      • Get defibrillator ready (if poss)

LazyW

The “Lazy W” Position

Why pairing and other XP practices can mean that developers can move between teams with minimum disruption

Why pairing and other XP practices can mean that developers can move between teams with minimum disruption

A colleague and I had a conversation about moving developers between teams, and associated worries about causing disruption and losing knowledge / expertise.

I told the colleague about the book I was reading – Joy, Inc by Richard Sheridan, about a company in America called Menlo Innovations. Richard describes how at Menlo, they can easily move engineers between projects with minimum disruption. This is because they are used to pairing and knowledge sharing, they all adopt the same working practices, and no one person has code-base knowledge that isn’t shared by others.

Below are some extracts from the book that I think are relevant to this conversation. The basic premise is that pairing, a culture of learning and a focus on joy in the workplace all help to ensure that there are no towers of knowledge or lone genuises, and everyone can easily switch from one team to another.

I should add that I emailed Richard to ask for his permission to post these extracts, and he was extremely helpful.

Joy, Inc. excerpts are Copyright 2013, 2015 by Richard Sheridan. Used with permission. All Rights Reserved.

Chapter 12, Scalability (starts p194):

Brooks’s law is the motto of a broken hero-based culture that still largely exists in software development today. It states that the onboarding cost of a new person, particularly to a late project, far exceeds the potential contribution of that new person within the first few weeks or months of joining an effort. If a project is already late, then adding someone to it will make it later. The only alternative to a missed deadline then is an eight-hour-per-week death march for the current team.

… If you have no systematic means of transferring knowledge in a way that can quickly lead to mastery and autonomy for the new person, Brooks’s law applies to you, too.

…At Menlo, we have defeated Brooks’s law so many times that its premise is but a faint reminder of a quaint time in our industry’s history. Our entire process is focused on breaking this law. Pairing, switching the pairs, automated unit testing, code stewardship, non-hero-based hiring, constant conversation, open work environment, and visible artifacts all topple Brooks’s assertion with ease.

…Our pairing system, particularly the part where we switch the pairs every week, gives us a chance to practice scalability even when we don’t need it. We borrowed this concept from the airline industry (there it is called cockpit resource management). By switching pairs every week, we practise onboarding a new team member into a project even if the project stays the same size. We also practise onboarding new team members by bringing in four to six international interns annually.

…As the basic planning and coding practices are consistent across all projects, there is no need to train these new team members in any project-localized or personality-based methodology. The fact that everyone on the team has a shared belief system in our approach ensures there is no friction around these shifts in project assignment.

…Because the team is not based on towers of knowledge, because no one developer owns part of the code, because everyone has been working in all sections of the code, and because the people who have moved to another project are still in the same room and within eyeshot and earshot of one another, there is no meaningful loss of information about the project.

…How does a team get back up to speed when the project has been placed on the back burner for months at a time? … This falls back to documentation and standard work process. The automated tests provide the first foundation. They catch misunderstandings as new coding changes happen. If a programming pair returns to the project, makes a change they believe is okay, and one or more of the unit tests fail, the automated tests inform the programmers immediately that a mistake was made. This begins to refresh their memory of decisions made in the past. Code stewardship is also a big part of this, as the code has been viewed and adapted by so many different people over time that it has evolved into a body of work that reflects a commonly understood expression of intent, not a convoluted expression understood only by the hero originator and no one else.

…At Menlo, we measure cost against the final product: joy. We want the end users of our work product to thank us someday and tell us they love what we created for them. Most software teams never even get close to this effect. Can you measure something as intangible as joy? Perhaps not exactly, but you can measure usage, long-term quality, market share, customer satisfaction, market dominance, end user delight (at least anecdotally), and a lack of support calls. If we establish the team’s accountability to get these kinds of results every time, we get to joy.

Chapter 3, Freedom to Learn:

p52:

Assigning pairs and switching them each week helps avoid a variety of typical team ills that could interfere with learning outcomes. For example, it prevents team members from feeling alienated by another team member who may not have a particularly outgoing personality. It may not be a personality problem at all, just normal human shyness. We avoid cliques forming, as everyone gets a chance to work with one another.

We’ve found that people are more likely to engage in a casual pop-up conversation with others whom they’ve previously paired with for forty hours. This time spent together dispels a lot of misconceptions about one’s fellow teammates. Once you spend forty hours in conversation with another human being, you are going to get to know that person in a deeper way than a general impression could ever accomplish.

Working in pairs also provides an emotional safety net for our employees. As much as they are stretching the boundaries of what they know, they are also testing the edges of what is ‘safe’ in a work environment. When a new technology or process or domain is introduced, there’s always the prospect of fear creeping in, a natural human response to the unknown.

Imagine a six-year-old child on an unfamiliar walk near the edge of a deep, dark forest. The child will stand frozen and frightened, unable to move forward. But place an equally frightened six-year-old friend beside him and together they may confidently travel this unknown space together, hand in hand. Just like the buddy system we learned in childhood swim classes, pairing helps us move into the unknown with confidence and courage, comforted by the safety such a system provides.

p58:

We don’t tolerate towers of knowledge or lone geniuses at Menlo

p59:

The hidden benefit of giving your team members the freedom to learn is that, eventually, they will embrace the idea of taking the time to teach. Knowledge isn’t kept away in secret personal vaults like the crown jewels of little kingdoms. The workers on your team become more valuable as they learn new practices; they also become more flexible. Some conclude that this diminishes each team member’s unique value and turns each one into a cog in our little software factory machine. Usually, in the very next breath they tell us how amazingly valuable each of our team members is because of his or her mastery of so many different technologies and domains. This can happen only when you truly believe your team members are equally valuable and equally able to learn and carry certain knowledge.

Pairing is the atomic element of our learning organization. It produces a joy in learning that most of us haven’t experienced in years, perhaps since elementary school, when everything was new and all we had to do was absorb it.

Joy, Inc. excerpts are Copyright 2013, 2015 by Richard Sheridan. Used with permission. All Rights Reserved.

Use a Spoon!

Use a Spoon!

[My birthday cake] started life as a chocolate + coffee cream cake. But then it fell apart. Now it’s sort of a trifle. Use a spoon!

The only reason this is here (apart from being a note recently written by me) is that this pic went viral on imgur. 78,500 views and 1078 likes! Whoop!

(sorry)

Excel: Don’t insert rows above a frozen pane (aka “Why can’t I scroll down??”)

Excel: Don’t insert rows above a frozen pane (aka “Why can’t I scroll down??”)

Yes, I’m Mrs Spreadsheet this week.

If you too are spreadsheeting, don’t do what I just did.

“Freeze panes” is a wonderful piece of functionality. It basically allows you to get column and row headings to “stick” to the top or side of a sheet, so that when you scroll through the data you can still see those headings. It means you don’t have to scroll back and forth to find what data you’re looking at. To make it work, place the cursor below and/or to the right of the headings, then select View | Freeze Panes | Freeze Panes. To turn it off, it’s just View | Freeze Panes | Unfreeze Panes.

But if you’ve done that, don’t insert new rows above your freezing point. Everything goes a bit pear-shaped. You can’t scroll down to the actual content bellow the freeze point.

That’s what I just did. I don’t recommend it. Luckily the fix is simple: View | Freeze Panes | Unfreeze Panes.

You’re welcome. 🙂

 

 

Excel and the flippin’ arrow keys!

Excel and the flippin’ arrow keys!

Coincidentally, I’ve encountered two problems in the same day to do with the arrow keys in Excel.

This one I’ve seen before, but I still had to look the answer up again.

This is about trying to use the arrow keys to move between cells (eg use the up key to move to the cell above the one you are in) (coincidentally this is the opposite of what I wanted to achieve before, which is move around the text inside a cell).

Problem:

Sometimes you get stuck – you click up, down, left, right, but you can’t seem to leave the cell you’re in.

Solution:

Press the scroll lock key.

This lives in various locations, but on most Microsoft keyboards I think it’s top right, next to the Prt Scn (“Print Screen”) button.

I know of no other application where this is an issue. But this isn’t the first time it has happened to me. I suspect my cat Crunch, who has taken to sitting under my laptop stand and stretching her paws out luxuriously across my keyboard, has been pressing my scroll lock key. She also likes to lick my fingers while they rest on my trackball mouse. This is half cute and half annoying. Above is a picture of her claiming to have no knowledge of any such thing.

Moq’s Setup, Verify, Verifiable and Callback Methods

Moq’s Setup, Verify, Verifiable and Callback Methods

(The code here is C#)

When trying to verify parameters passed to a method on a mocked object:

Method 1:

• Use Setup (which has taken the place of Expect)
• Use It.Is(x => x == ExpectedParameter)
• The lambda expression can be as complex as you like, as long as it returns a Boolean
• !! Important !! Mark it verifiable!

Like this:

mock
.Setup(x => x.Method(It.Is(y => y == "expected")))
.Verifiable();

mock.Verify();

Method 2:

Use callback: This allows you to store the parameter in your own variable and then make assertions on its contents.

Like this:

string actual = String.Empty;
mock.Setup(x => x.Method(It.IsAny()))
.Callback((param) => actual = param);

Assert.Equal(“expected”, actual);

Home Made Press Studs!

Home Made Press Studs!

Ha. This is quite funny really. I started this blog thinking I would use it to store all the gazillions of notes I make about code-related matters. But I make notes about EVERYTHING.

I can’t resist posting this one here. Just in case some random person finds it useful (see image above).

I bought a kit from Amazon, but the instructions were pretty woeful and at first I was rather mystified. But eventually I pieced it together made that image (^^), printed it out and put it in the box with this press stud kit:

Machine-Learnt Algorithms and Unconscious Bias

Machine-Learnt Algorithms and Unconscious Bias

I attended a web foundation lunch a couple of weeks ago, around many issues related to data and ethics. I have to confess a lot of it went over my head. Since then I attended a talk by Cathy O’Neill which made some things a lot clearer to me. I’ve bought her book Weapons of Math Destruction, so hopefully I’ll have some more cogent notes after I’ve read that.

But in the meantime, here’s one small thought I had about algorithms and patterns:

As human beings we’re very good at identifying patterns, without thinking about it. So, if my experience is that the vast majority of women I see in technical meetings are admin staff, then whenever I encounter a woman in that context, I will guess that she is non-technical.

In a similar way, the machine-learnt algorithms are making assumptions and developing decision-making processes based on patterns identified in existing data. As human beings, we can train ourselves and each other not to make assumptions based on previous experience, and to be open to new possibilities. Is this also something which is / should be / can be built into machine-learnt algorithms?