Work – Page 4

Data

5 March, 2019

I had a Routine Medical Thing yesterday which required me being hooked up to a bunch of monitors for heart rate, blood pressure, etc. for a while. All very good. I don’t know for sure, but I assume that all that data was filtered down and then streamed into my digital medical record at the hospital. (If it wasn’t, that is a terrible waste, but not germane for the moment.)

Anyway seeing the monitors collecting “bedside data” as it is apparently called put me in mind of a presentation I saw a few weeks ago at a management meeting for Red Hat. The presenter had developed an alerting system that looks at bedside data and guesses whether a patient might be starting to develop sepsis, the often-fatal blood infection that is one of the big risks of spending any time in the hospital. If you catch sepsis early it’s easy to treat, but in a matter of a half a day it becomes life threatening. So an automatic alert to the nursing station not only saves nurses time, but also patients’ lives.

Of course systems like this have to run inside of a hospital’s network, because patient data has to be kept private (due to HIPAA, and also common sense to be honest). So the sepsis alert system has to run inside each hospital and be hooked up directly to whatever data stream the vendor who supplies the bedside systems makes available. This of course makes it difficult or even impossible to correlate any of this data across hospitals for research. It also means the hospitals themselves, who are in fact in the business of collecting huge amounts of this kind of data — MRI scans, DNA sequences (soon), bedside data logs — are completely overwhelmed. They are generating huge amounts of data and have nowhere to put it.

We are doing a whole bunch of work at Red Hat Research and Boston University in this area — there is lots of good thinking on ways to gain useful knowledge from data, without breaking the privacy of the data’s owner. Ultimately though I think what will happen is a shift in thinking about data ownership, data encryption, and data use. I think this will be generational, to be honest. So-called “Millenials” famously do not care who knows what about them, or so it is claimed. My nephew Sam, however, who is at fifteen part of the generation after that, refuses to get a Facebook account. Why? “They collect everything about you, it’s creepy AF,” he says. (I’ll let you work out for yourselves what “AF” means.) I’m told his opinion is common among his peers, and if it is it means that we will shortly run into a real demand for personal encryption, anonymity, and control over what can be collected and released. The days of services randomly collecting whatever tracking data they like, by whatever means they wish, will seem as naive in twenty years as cars without seat belts do today.

There are practical issues to be dealt with here, of course — if my bedside monitoring data belongs to me, how do I control who gets to see it? What if I’m unconscious? In reality though we need to deal with all these kinds of things anyway. As with all technology, the ability to do things leaps well ahead before society catches up.

Routines and Deadlines

28 February, 2019

Parkinson’s Law holds that work expands to fill the time available for its completion.

(C. Northcote Parkinson also was the first to accurately describe the phenomenon of bike-shedding, a particularly nasty plague in the software industry.)

There are many ways to combat the effect that Parkinson’s Law has on your time and your stress level. One way, which my father-in-law Ron Rowe discovered when he led the J.W. Pepper company many years ago, was to reduce the time available to do the work. He did this by giving everyone thirty-two hours to do what had been their forty-hour jobs, except in the company’s two fairly short peak seasons. Salaries and everything else remained the same, there was just one less working day most weeks of the year. He found that Pepper staff got more work done in the 32 hours he gave them than they had in the 40 hours they worked previously.

I would love to pull off something like this with my team at Red Hat, but it would probably require more institutional buy-in than I could muster at this point. There are other ways to push a team to focus and get things finished though. One obvious one is to create a deadline, ideally one that will result in public shaming if it is not met. I’m fresh off giving a major presentation to 500 people at the company, and I was surprised how much work got done in advance of this simply because everyone knew we were going live.

But, deadlines were made to be broken. I find routine is really a much more powerful way to prioritize what you really want to do over the tyranny of the day to day. The more of my morning I can devote to working on the same things — that I want to work on — in the same order, the happier and more productive I feel. (This blog is a good example. I do it the same time every morning, because if I don’t, I won’t do it at all.)

Ultimately I think this is because decisions about what to do next take a ton of energy and effort and we get them wrong most of the time. The fewer decisions you have to make, the more effective you are… and routine takes away decisions.

I just wish I could find a few more hours in the morning for my routine… unless it is expanding to fill the time available?

Hire The Developer Today

23 February, 2019

Lizbeth Webb as Sarah Brown in the original London production of Guys And Dolls at The Coliseum Theatre 1953. Private collection, Public Domain, Link

Hiring, it is said, is the most difficult thing one can do as a manager. Managers who are good at hiring can’t tell you how they do it, and the literature is filled with tales of the horror that befalls managers who do it badly.

I don’t know exactly why it should be so hard to determine whether a candidate will fit well in your team and become a net addition, but it clearly is, and the more senior the person is the harder it gets. There is every possibility that the person who seems so easygoing and willing to learn in an interview, will turn out to be difficult and set in their ways once they get on the job. It is also nigh on impossible to evaluate someone’s skill as an engineer from a test or a transcript or a few code samples. This is especially true in an open-source context, where the definition of “skill” includes everything from “Writes the right code cleanly and quickly” to “Is able to convince unknown and probably cantankerous peers in the community that this patch should get in.” These two abilities, in particular, rarely appear in the same person, at least not when they walk in my door.

(If you are among those who believe that in open source the best ideas always win, I have another conversation to have with you, but for now you can read this post).

You would be right to ask me at this point why I think I’m so smart — what legendary track record do I have in hiring that allows me to pontificate on it? It’s a worthwhile question. I feel like I’ve built a few solid teams over the years, and I’ve taken them through some godawful wrenching changes — “We’re discontinuing your product because we acquired a startup with a competing product, so you all have to learn a new language and work on something completely different in a new community” — multiple times with a very low attrition rate. But I can’t claim any special ability to evaluate people in an interview and I doubt my ability to select the right person is any better than anyone else’s. Certainly, I have hired some great people, but… well, this is public, so I shouldn’t be any more specific than to say I have made a few mistakes too.

I do have one secret, however, and it is summed up in some very bad advice from a song from the ’50s musical Guys And Dolls: “Marry The Man Today.” The song holds that women are better off marrying an imperfect man and then reforming him into what they want him to be, than holding out for the perfect mate to come along. My mother, who had some experience with this theory (sorry Dad), told me early on “This is very very bad advice! Do not follow it!” She is right, of course — in the context of a marriage, it’s a terrible idea, a recipe for unhappiness or worse. In the context of a well functioning team, though, with a strong and healthy culture, it’s not necessarily wrong, especially if you are in the position we all find ourselves in now of having to recruit inexperienced folks straight out of college.

What does this mean in practice? It means I tend to interview people, especially young people, on non-technical criteria. Do they speak clearly and thoughtfully? Do they appear to be self aware, perhaps with a refreshing trace of irony? Did they take the time to find out who I am, what I do, what Red Hat does? If I’m lucky enough to find someone who meets these criteria, I will usually hire them, whether they have any experience in the area I’m hiring for or not. I can teach them to code, and I have a whole team with a whole culture that will teach them how to work the way we work, but I probably can’t teach them to give a crap.

So, instead of spending your time interviewing hundreds of candidates, spend your time building an organization with a culture that will make them into what you need. Hire the developer today, I say, and train them subsequently.