00:00:29.720
I am going to introduce Ernie, since that’s why he’s here. Thank you so much for coming. Some of you may not know Ernie.
00:00:36.239
He was a childhood television star with his best friend, Bert. Some people got the reference. I’m surprised by how many of you have never seen Sesame Street. Ernie also wrote Active Record and MySQL, if you’ve ever used those.
00:00:44.719
He invented the SELECT statement, which is pretty useful, I don’t know if you know that. Ernie is one of the best database people I know.
00:00:51.000
So, you should come up and say hello to Ernie and follow him on Twitter. Just remember, first try tweeting him your database questions, and then Google for the answer. Alright, this is Ernie Miller; can we get a round of applause?
00:01:23.400
Good morning! You all look bright-eyed and bushy-tailed. I have some important business to take care of first. Terrence made a request yesterday, and I want to honor that.
00:01:30.079
I have 154 slides in 35 minutes and got a late start because someone had to change into their space suit.
00:01:36.720
So, I just want to make sure everyone remembers that as I go over my slides. I’m trying to get a sense of whether or not I can frame you all without doing a panorama, and I think I actually can.
00:01:44.719
Can we all stand up for a moment for a Friday hug? Alright, you all look beautiful, you’re awake, blood is flowing, your arms are extended.
00:02:01.840
On the count of three... one, two, three... ha! You’re beautiful. Alright, we’ll post that later; I suppose I don't really have time to post it at the moment. Silly me.
00:02:08.239
Okay, with that out of the way, I work for a company called Inviseum. I started there back in October. We are an application security consultancy, which basically means we do security audits on applications for people that I would love to tell you about, except they would probably kill me.
00:02:30.200
So, they hired me as a director of engineering. As it turns out, neither a fancy chair nor a megaphone comes with that job. What does come with that job, however, is an astounding amount of pressure.
00:02:44.719
You see, in every job I’ve ever held up to this point, I could look at myself and say, if I was unhappy with a position, it wasn’t really my fault. I could leave and feel like I didn’t make things rough. I’m not proud of that. I’m actually a bit ashamed.
00:03:07.879
But I also don’t think I’m necessarily alone. As I understand it, it’s not very common for us to stay in a position for very long, right? How many of you have been in your job for less than a year? Wow! Okay, less than two years? Yeah, okay, so I don’t even need to keep going with that.
00:03:29.400
Basically, nobody here has worked the same place for more than about two years. When you left your previous job, you took yourself with you, right? So you probably didn’t think you were the problem, either.
00:03:58.920
You probably felt it was impossible to fix, and it was just easier to move on. Here at Inviseum, the problem is they wanted me to build software, to build the team, and to build the culture, which means it absolutely is totally my fault if I’m not happy there.
00:04:13.760
So, that put a lot of pressure on me. I started to think about what makes me stay at a company, or, looking at it the other way, what makes me leave. I want to share a story with you about a former employer.
00:04:40.160
I want to make it very clear: it’s not important who this employer is. For one, I’m sure they’re not running things this way anymore, and if they are, they probably won’t be around for much longer anyway.
00:05:03.320
I was brought on to lead a team of technical folks, and I was going to report to the CEO. When I talked to the CEO about coming over to work there, I was concerned that I would end up just managing.
00:05:22.280
I really wanted to write code; I wanted to remain technical. I was assured that wasn’t going to happen, and he made it worth my while to take the risk. So, I decided to make the jump.
00:05:42.920
Fast forward about half a year, and I wasn’t spending much time writing code—imagine that! Instead, I was spending a lot of time wrangling a Kanban board or some variation thereof.
00:06:05.360
Nobody's Kanban board is actually that simple. I was triaging a Kanban board full of more urgent tasks than we had time to do. I was checking on overworked, stressed-out employees and doing my best to shield them from the wrath of that jovial CEO.
00:06:28.480
I went to the CEO and told him, 'This is a little bit messed up; this is not what I signed on for.' He told me something I kid you not: 'You're thinking of this all wrong. Think of it as another development task; your team members are objects in the system. You're just doing engineering, just like you would with software.'
00:06:48.800
And he sent me on my way. It was then that everything became crystal clear to me. Though it probably wasn’t how he’d hoped it to be, this guy had no idea what he was doing. He was a former engineer, and he really wanted to treat the company like software.
00:07:06.840
He was comfortable with software, but there may be a world where the result of this statement is true; however, it is not the world we live in. People aren't objects—that’s really messed up, right?
00:07:20.760
It should come as no surprise that I was really miserable there. I was working at a company whose leader had actually told me he was trying to dehumanize the employees, and the employees were pretty much overwhelmed.
00:07:36.840
We were putting too much load on them; they felt like they didn’t have the time. They felt that if they weren’t spending time documenting everything they were working on, it really wasn’t happening, and therefore they wouldn’t get credit for it. Surprisingly enough, we had a hard time hiring in this environment.
00:08:18.840
It was like my CEO had his own reality distortion field; the polarity was inverted, and it only affected him. I don’t know if part of it might be that for about six years now, I've been a volunteer counselor. I talk to people a lot, and even before that, I’ve always been kind of a sensitive guy.
00:08:46.240
So, I was miserable. I made multiple attempts to counsel my CEO on the issues I perceived, but eventually, I walked away. You might say this situation was kind of extreme, but I don’t think it’s terribly abnormal.
00:09:04.960
I’ve seen this pattern in most jobs where I’ve been really unhappy. The business has different values than I do. They value things like predictability, and I understand why; they value things like measurability and control because they believe that having control over situations gives them those other two things.
00:09:35.440
Understandably, the business wants things to be neat and organized. I get it; it makes sense. But businesses are made of people, and people are messy, no less beautiful for it. We need to remember that people aren't always going to fit neatly into the molds that companies want.
00:09:53.920
So, how does a company cope with messy reality? They cope the same way that we developers do: they use abstractions. They try to make us fit whatever mold they want and reduce humans to resources to be mined.
00:10:07.000
Think about this: companies actually reduce and try to abstract away humans as resources when the only corporeal thing about a corporation is the humans. So, I decided that, first and foremost, any company I wanted to work for would have to recognize that we are humans working with humans to develop software for the benefit of humans.
00:10:20.480
You’re probably thinking, 'Well, that’s great—that’s a real insight. Thanks for that.' But just stick with me; I swear I'm going somewhere with this. Other things arise from that realization. First, I decided to call it 'humane development,' because it literally puts the human back in development.
00:10:48.920
More importantly, 'humane' conveys the kind of values that I want to hold. Here's a definition of humane: it’s compassion and benevolence, and inflicting the minimum of pain. Aren’t these things you'd like to have where you work? You don’t want pain.
00:11:07.400
How many of you do Agile in some way, shape, or form? Most of you, right? Now, I don’t pretend that that term means much these days, but there was a great talk by Uncle Bob a few years back called 'The Land That Scrum Forgot.' I stumbled upon it while researching for this talk and want to share some insights. This is a history lesson about where Agile came from.
00:11:54.720
Uncle Bob got together with Martin Fowler and wanted to create some kind of an organization. They sent a bunch of invites to what they ended up calling the 'Lightweight Process Summit,' where they coined the term Agile. Nobody was terribly happy with the name, but since everyone disliked it, they went with it.
00:12:23.840
Anyway, Bob said that Cunningham had stated they needed a manifesto, something that would say what they valued more than other things without discounting the previous things. So, we ended up with the Agile Manifesto. You might be familiar with it; if not, you can go to agilemanifesto.org to read it.
00:12:50.240
It states some things that seem patently obvious: the things on the left are more valuable, but it also wanted not to alienate the corporations they were essentially trying to sell this idea into. Therefore, they continued to say that those other things were also valuable—just not as valuable.
00:13:09.840
Bob went on to say that Kent Beck had reiterated that it really should be about healing the divide between business and development, and everybody agreed. A little later, Ken Schwaber came up with the idea to start offering a certified Scrum Master course.
00:13:40.639
Uncle Bob thought that was stupid, and every developer he talked to also thought it was stupid. Yet, project managers didn’t think it was stupid, and they sold tons of these courses and certifications, which ended up being what put Agile on the map for corporations.
00:14:11.679
The problem was that it made its way into organizations by certifying project managers as Scrum Masters, but a Scrum Master was not supposed to be a manager. The role was supposed to rotate between people and eventually fade away.
00:14:41.920
But the project managers who took the certified Scrum Master course did not like that interpretation, and we gradually see the transformation from the things on the left shifting back to the right. Now, most of us use some kind of special process or tools to manage our so-called Agile.
00:15:22.600
We’re not focusing on the things on the left as much as we’d like to. One of the aspects of the Agile term is speed; it sounds speedy, it sounds fast. In fact, you can go fast with Scrum or any Agile methodology, and that plays nicely with another core business value these days—hustle.
00:15:50.160
This is a Google image search for hustle. It looks like some kind of messed up wall of motivational posters. The only place greatness comes before hustle is in the dictionary. I absolutely hate this word, except for this image right here; it’s the only allowed image to use the word hustle.
00:16:37.080
Now, look at the dictionary definition of hustle. Does anything in that list look remotely laudable? Is it something we should virtue consider a virtue? You might argue that the definitions of words change all the time, but I think we’re fooling ourselves.
00:17:03.440
Hustle still means what it meant before. Our values have changed, and we’ve tried to treat hustle as a virtue. We’ve adopted this in startup culture, especially this wonderful motto: 'Move fast and break things.' First made popular by a tornado.
00:17:33.880
This is a horrible motto; it’s so stupid—move fast and break things. That’s a real problem. The notion that moving fast is somehow virtuous is damaging. You need to be moving in the right direction, and we forget about that sometimes.
00:18:04.240
We get obsessed and play games like planning poker so we can assign points to measure velocity because we’re always sprinting. It's a great analogy: sprinting, because we do a sprint, and then take a recovery period. We even have weekends!
00:18:35.440
I asked people on Twitter if they do recovery after they sprint, and they said, 'Isn’t that what weekends are for?' Well, you see, I am not really that familiar with most sprint interval training.
00:19:03.760
Most of what I found indicated it typically has more rest than work, however, I am familiar with the Tabata protocol by Dr. Izumi Tabata, which involves a two-to-one work-to-rest ratio. You can see in this little chart, each block is 10 seconds, resulting in a sprint.
00:19:31.480
With Tabata, you have this work followed by a long active recovery period, but with Tabata, you’re doing two-to-one work recovery, meaning you’re doing less—and we may be tooting if we count the weekend, but we're definitely not getting the recovery we need.
00:20:02.800
It’s the wrong analogy anyway because none of these are about sustainability. You're not meant to sustain these paces for any long period. A better analogy, if we're going to stick with one, is a marathon.
00:20:22.640
The finish line is an abstract idea for a long time; you know it's coming but don’t focus specifically on it. You concentrate on maintaining a sustainable pace and following markers, knowing that your training will pay off.
00:20:49.600
In a marathon, an unsustainable pace isn’t just worthless—it’s less than worthless. It will cause you not to finish the race and probably hinder your performance in the next one.
00:21:18.480
So, it’s important to realize that the big picture can’t be a need-to-know basis. If you don't know where you're going, how can you possibly plan a sustainable pace?
00:21:36.520
Whenever companies try to feed you one sprint at a time without letting you focus on the bigger picture, it eliminates your flexibility to help plot the course. All of this is geared towards measurability.
00:22:05.640
Estimations are critical, and I want to discuss them. Just a few weeks ago, I had a big snowstorm which, for Louisville, means anything over three inches, and we had about seven inches of snow. I was relying on the weather estimate for when the snow would stop.
00:22:31.560
When I went out to shovel the drive, the snow was still coming down, and it was harder than I thought, requiring multiple passes to clear it. While I was out there, I was already tired and projected that it would take around an hour to shovel.
00:22:52.040
In reality, it took me two and a half hours. I’ve shoveled my drive before; there is nothing really different about this case. So then, if I can’t estimate a simple task that I’ve done many times, what makes me think I can estimate something abstract and creative?
00:23:22.680
That’s why I think estimates are lies. Thankfully, we’re buffered from the consequences of those lies because most deadlines are also lies. We let them slide, and oh, we just adjust the deadline.
00:23:52.600
Was it really a deadline? Most urgent things aren’t really urgent, and so it usually works out, and we don’t realize how much we’re lying. I think it's really important that we ask why.
00:24:16.000
We need to question every requirement, every deadline, and every task. What exactly are we trying to accomplish? That's what helps you transition from a requirement to the underlying reason. It’s something people want to skip, but it’s vital to dig deeper.
00:24:50.720
We might think it's crazy to question why, but it’s worthwhile. We all have stories of applications we’ve developed to solve problems that never existed because no one asked why. For example, if the site is down, that is urgent, but it’s still important to ask why.
00:25:25.160
The bad answer is, 'Because it’s down,' but the good answer involves figuring out what’s lost while it’s down, which helps to understand urgency differently. Also, this approach can prevent hasty decisions that may lead to even more significant issues.
00:25:55.800
When I first started working as a sysadmin for an ISP, a customer contacted us because their mail spool had corrupted. In my urgency to fix things quickly, I executed a command one directory higher than intended. I created a substantial problem that took all afternoon to resolve.
00:26:38.800
Misplaced urgency causes similar situations, especially with deadlines. They create a cycle where people give non-answers—someone says they need a feature by a date, and upon asking why, you get—'So we can meet another date.'