Millard 060001WYSU 348 Visits
I chose this profession on purpose -- and in a moment of desperation.
I had started college as a journalism major after a successful run as editor of my high school’s newspaper (which won its first state-wide awards under my direction). I liked doing it, was successful at it and was attending a real School of Journalism at a decent university. And things were going well. I started questioning my choice as journalists were starting to be jailed (in the United States, believe it or not) for refusing to disclose their sources. I wondered if I could protect some criminal source at the cost of being ripped from my family and imprisoned for an unknown period of time. Then a visiting professor who had taught my news editing and headline writing class told me at the end of the semester that “you really have a career in this if it’s what you want to do”.
Chalk it up to being young and inspired to become a member of the fourth estate -- I had not really thought of it as a choice up to that moment. It was just the path I was on and what I (thought I) was meant to do. Sitting here in 2012 with many newspapers dead or dying and many news organizations generally in difficult times (or not really “news” organizations any more), I’m glad it was a choice (and one that I could remake).
As that young, inspired journalist I knew that I’d be called upon to write about all sorts of things and it would help if I knew something about them. Having grown up in a rural area in the 1970s, I knew almost nothing about computers so I decided to learn about programming during my freshman semester. I loved the class and finished at the top of it, ticked it off as “knowledge acquired” and moved on. Until that fateful December when I realized I needed to choose a different major. As I cast about my brief life’s experiences looking for something that I enjoyed doing and might support me (and the family I didn’t have yet), I recalled that programming class. Could I really get paid for something that just seemed fun to me? Would someone pay me to solve technical puzzles and build software? [Those sound like crazy questions now, but back before personal computers and the Internet and smart phones the answers were not as obvious.]
Thus began my journey to this moment, this Sunday morning in early 2012, with decades of solving technical puzzles and building software behind me (and hopefully many more in front of me). Knowing that my career was a choice and I made it well. Waking up most mornings wanting to go to work despite having done it until bed time the night before. Using those skills to fuel hobbies and community activities and house and feed and support my family.
Also at this moment, I find myself in Hillsboro, Oregon working at the IBM Lab in Beaverton helping develop the next version of IBM Rational Team Concert -- a tool that helps people and companies (including me, my team and IBM) build software better. Given how I feel about my career choice, I can’t imagine a better job -- building software that helps people build software (and getting to use that software myself for that purpose).
Thanks for reading this first post. Hopefully you’ll find value in the ones that follow. I expect to write a bit about software development in general and sometimes about RTC in particular. Because of my journalism background, I can chase tangents and write for hours -- doesn’t mean anyone would want to read it. So unless the topic requires deep explanation or lots of pictures, my personal post size limit is one page (and this one just breached).
Part of what makes software development a perfect career choice for me is that it never stales. At least during my lifetime so far, technology hasn’t sat still for more than a few years at a time. The next layer of capability, the next opportunity, the next whatever is always incubating. I can safely say I’ve rarely had the same year of experience twice.
And I love that about it. I love that I need to keep learning and reinventing myself as a technical professional, that what I know is only a little bit more important than what I’m learning. We are served well if we can maintain a “Beginner’s Mind”. [I first learned of the Beginner’s Mind from Zen Guitar by Philip Toshio Sudo but a quick search will provide many references.]
One of my favorite stories (perhaps even a parable) related to the Beginner’s Mind (cobbled together from a couple different versions) goes...
A university professor comes to visit a famous Zen master. While the master quietly serves tea, the professor talks on and on about Zen. The master fills the visitor’s cup to the brim and keeps on pouring. The professor watches the overflowing cup until he can no longer restrain himself. “It’s overfull! No more will go in!” he blurts out. “You are like this cup,” the master replies, “full of your own opinions and speculations. How can I show you Zen unless you first empty your cup?”
Following up a bit on the last topic (where I talk about how much I love the field of software development because I always have to be learning new things), a college professor friend of mine who teaches software development shared a disappointing story...
As he’s chatting with some students after class, they ask him which language or technology they can learn so that they don’t have to learn anything else once they get their degree.
This blew me away on several levels: (1) These are university students participating in a largely optional learning activity (college) and they are already trying to figure out how to stop learning?! That doesn’t bode well for their lives in general, much less their future as software developers, (2) They are studying a technology field and are old enough and smart enough to get into college, yet they’ve missed the fact that technology has done nothing but change their entire lives? There’s a chance that some of the specific technologies they learn in college won’t even be relevant by the time they graduate, (3) They think they’d actually want the job they are describing. [That last one is wrapped up with some personal bias, for sure -- I can’t imagine any period in my career where I would have been happy doing just that thing for the remainder of it.]
Yet, somehow I fear I may be the odd one here. One of my favorite interview questions (sorry, no bizarre thought puzzles like “how do they make M&Ms”) was “What was the last book you read and what magazines do you read regularly?” I rarely got a decent answer. Often I’d get quizzical looks and would have to eventually follow up with “Software development is a rapidly changing field. You’d like to come work for us as a software developer. I’m trying to figure out how you go about keeping up with change and staying abreast of new technologies and practices.” Unfortunately, they often now understood my question and still had nothing satisfying to say.
BUT, here’s the answer that I hated the most: “Yeah, you’re right, doing that’s a good idea but my company doesn’t pay for books or magazine subscriptions.” So you know it’s a good idea, that it would be valuable to you as a software developer and by extension make you more valuable as an employee, but unless someone else pays for the book or magazine subscription, you’re not going to do it? [imagine several more paragraphs of crazed ranting here -- it’s harder than I thought to not include them]
I’m afraid to ask this question any more. It’s so easy to follow folks on Twitter or Google+ or read their blogs or get entirely free magazines sent to you in email or buy even cheaper e-book versions of books that the interviewee’s quizzical stare would cause me to tilt.
To help fight this phenomenon I will occasionally curate a useful set of links or list of books that I personally find valuable. If you know of equally good or better books or links, please post in the comments -- I can’t read everything and I won’t post about something I haven’t actually read or used and found value in.
Getting StartED with Dojo by Kyle D. Hayes with Peter Higgins. A gentle yet useful introduction, nicely organized and presented.
Dojo: The Definitive Guide by Matthew A. Russell. As I searched for a really good Dojo book, this one kept appearing at the top of people's lists. While based largely on dojo 1.1, it focuses on fundamental aspects of Dojo that I expect remain the same today. I understood things after reading this that I only thought I understood before reading it.
Agile and Scrum
Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck. This book "made it click" for me, providing a vivid description of how you can deliver high quality software of value to the customer while eliminating waste and constantly improving your team.
Succeeding with Agile: Software Development Using Scrum by Mike Cohn. I very much enjoy Mike's writing style and I give this book an edge over Ken Schwaber's original treatment, but either will suffice.
Agile Estimating and Planning by Mike Cohn. If you want to really understand how Story Points are meant to work and how Agile Planning seeks to mitigate risk, this is the book. If you're more into Cliff Notes, Mike provides lots of useful material at his web site: http://www.mountaingoatsoftware.com
I personally have a Safari Books Online (http://safaribooksonline.com/Corporate/Index/) Individual subscription. For $23 a month I can read any book I want, up to 10 at a time on my personal "bookshelf". You also earn credits that allow you to download books permanently to your computer, often in a variety of formats (PDF, .mobi, .apk, etc.)
You don't have to look around much to find articles decrying how few American students are choosing engineering or technical professions. It has been feeling like an annual set-piece for years. Hiring managers wonder why more American students don't choose these high paying and professional career paths. Is it because they aren't properly prepared by our education system? Are they too lazy? Too interested in video games or rap music or marketing?
I'll suggest it's our fault. You and me.
I don't have a lot of data, but I have some that's poignant and personal.
My son is a smart kid. He does well in most subjects if he cares to. He's in college and certainly could be studying a technical discipline if he wanted. I've been a software developer my whole career (and as you could tell by past posts, I enjoy it). As a profession it has supported our family well including some private school education for the boy, quite a few glorious vacation experiences and many of life's amenities that we could have done without (and many do).
While enjoying one of those fun-to-do-but-somewhat-expensive outings with my son (and a couple co-workers), I had to step away from the group to pay for parking. [I learned of this discussion later, but confirmed it with all parties involved.] My teammates were politely chatting with my son about his plans now that he was in college. And the somewhat obvious question came up: "Have you ever thought about working for IBM and doing the sort of stuff your dad does?". Without needing to reflect much on the topic, my son replies "No. I see how much he works -- all the nights and weekends. That's not the sort of life I want."
I feel the need to defend us momentarily. By all accounts, I've been a very good father. I never miss an event (and I'm not late to them nor distracted at them, either). I read to him at bed time every night until he was almost a teenager. We did Tae Kwon Do together. I've been involved in all sorts of volunteer activities in support of him (I was a Cub Master and Assistant Scout Master for many years and ran fund raising for the wrestling team). I was his Statistics tutor. In my son's defense, he's not lazy nor unmotivated -- he's an Eagle Scout and has worked tirelessly and without complaint many times and in many situations. We work side-by-side in support of our local food bank and Habitat for Humanity organizations. He's been on the Dean's list or Honor Roll more than once and his first full year of college isn't quite over yet. And I know he thinks I've been a good father because he brought a large room full of people to tears (including me) during the speech he gave at his Eagle Court of Honor recently.
So what gives?
It's not me complaining about my job (most of the time) as I'm the first person to tell you I love what I do for a living. [I'd rather play bass for Lynyrd Skynyrd, but that job was taken.] It's not him being incapable of doing the work. As he's playing XBox on the large HDTV with explosions coming from the surround sound speakers while posting to his Tumblr on his Mac Book, it's not because he's unaware of what earning a good living makes possible.
Part of it is politeness on my part, failing to provide a complete context. At least some of those evenings or weekends I was working were caused by not-working so that I could attend the school play or teacher's meeting or wrestling match or drive a car load of kids to a campout on a Friday. Fortunately, the work I do makes it possible to have that flexibility. But you don't want to say very often "Daddy's working tonight because he took time to be with you today." These activities were never a burden and I refused to give him any reason to think they were.
Part of it is a personal achievement complex I've never been able to shake. I don't want to do good work, I want to do great work whenever the situation allows. If I can swap a couple hours of relaxing in the evening for an impressed customer, I'm usually happy to make that trade. I'm a maker at heart and want to make things worthy of my time and effort (and other people's attention).
But I think the larger part of it is how we run this business of software development (not necessarily at IBM, I've worked a few other places during my career): Plans that were never achievable unless everything went perfectly (and when is the last time that happened?). Customers that want more because they know you could give it -- and if you don't maybe they won't give you the next job. Teams that want to do more than they promised because that's just how they roll. And all of this comes at a personal cost to those involved -- and it may be convincing their children to look for other kinds of work.
I hadn't heard of Agile Fluency until a few days ago. I had recently joined AgilePDX (our local Portland group of folks interested in all things agile) and the email reminder came in about the monthly evening talk. Jim Shore and Diana Larsen were going to discuss their Agile Fluency model as part of the group's annual Agile Tune-up where everyone comes to think about what good goals might be for their teams for the coming year.
The fog was thick outside. As bad as I'd ever seen it (and it proved to be as difficult to drive in as I feared). I thought about not going to the meeting, but then I googled “agile fluency” and started to read a bit about Jim's background (I hadn't realized InfoQ had named him one of the most influential people in agile for 2012: http://www.infoq.com/news/2012/04/agile-influential-people). Then I read the article. Then I realized I really needed to go – this was going to be interesting.
I won't recap the article, you can read it here: http://martinfowler.com/articles/agileFluency.html. I won't recap the meeting, Moss Drake did a great job in his blog the next day: http://mxmossman.blogspot.com/2012/01/agile-levels-of-fluency.html (though I'll mention to him that it's really 2013 now). I'll presume you've already popped those links into a new tab and skimmed them. No? Go ahead, I'll wait.
Okay, just in case you didn't go read, I'll recap a little bit (most of this is in the article, some of it embellishments from the meeting): Jim and Diana discuss a team's path through agile fluency (based on their extensive experience in the space and with many teams), giving each level a star:
What struck me most about the article is the use of the word “fluency” and how it is defined by Shore and Larsen. They draw a bright line between proficiency and fluency. Proficiency means you understand the set of practices and are capable of following them. In their words, “Fluency is how a team develops software when it's under pressure. Anyone can follow a set of practices when given time to focus...true fluency is a skillful, routine practice that persists when your mind is distracted with other things.” Like broken builds and disgruntled customers (or, here in the Pacific Northwest, the first sunny day in weeks).
I'm reminded of a saying about musicians: Amateurs practice a piece until they get it right; professionals practice a piece until they never get it wrong. For me that sums up the difference between proficiency and fluency in this context.
Having been involved in several team's attempt at agile transformation, I've seen a lack of understanding of the need for fluency disrupt the transformation. The team has had some training and faltered in their early sprints (as is common and generally expected) but they are using the retrospectives and honestly looking at what needs improvement. Then, before they reach a point of fluency, something distracts them, some disruption in the force tries to throw them off their game. And it is successful. Before they can get back on track, their manager decides (problem #1) that the retrospective meeting is worthless because nothing seems to get better – and it just sort of crumbles from there. They are now a Scrum-but team and may always remain one. Had they been given the space to reach fluency at their current level, the could have weathered this storm. Lacking that fluency, they could only return to what they used to be fluent at.
Reminds me of another saying from a different field: Under stress, you will not rise to the occasion, but default to your level of training. So your level of training needs to bring you to fluency at the things you care about and your product and team depend on.
Models like CMMI tend to focus on practices that you adopt – so perhaps you are proficient. But the Agile Fluency model's focus on fluency, not just being capable of the practice but having adopted it so completely that it's just what you do makes a lot of sense to me. I also like the model because it is not about some set of practices you have adopted or a particular metric you've hit but about who you are, how you behave. Your fluency allows you to “be” at that level – it's what your team has become, how it's focused, what behavior feeds its soul.
The article includes a nice diagram of the path as well as a discussion of the benefits, investments and core metrics at each level. It's frank about the type and size of investment required at each level. Two stars can be hard because of the breadth and depth of skills required and the level of practice to become fluent. If you work in an organization that cares about agile development, go read and share the links (and this blog if you are so inclined). The ideas are valuable and I expect you'll hearing more about them.
It's mostly my fault for being optimistic and hoping that this time will be different, trying not to let a bad experience with someone else in a different context prejudice me against you and your situation. But it has become such a predictable pattern that the only thing to do was either
Only once in recent memory has this worked the way it should:
This happened with an early draft of The Practical Guide to Distributed Scrum. Elizabeth Woodward, the lead author, asked me to review it. I didn't particularly care for the structure of some of the content -- the hardest sort of thing to fix. But she asked early enough and we worked through the issues and the book turned out much better because of it.
Usually, it works like this:
When I agree to review something, I accept partial responsibility for the end product. I become a partner, even if a minor one. I will not skim the material and give you a winking thumbs-up. I will ask questions, some times lots of them. More than one person over the years has been shocked, I think, to get a detailed set of suggestions (from outline adjustments to copy-editing) rather than a "looks fine to me" reply.
I do this for one simple, perhaps egotistical, reason: If you are going to tell people that I reviewed it, then I want it to look like something I would publish, present or approve of. I'm going to treat it as partly mine and put the same level of effort into reviewing your work as I would put into reviewing my own. But that seems to almost never be what you want (or at least not something you can use). You want me to say it's okay so you can be done with it and claim to have had it reviewed. I'm never going to do that.
Just like changing code, fixing demonstrations and tutorials after they have been written is costly. Just like code, you are probably up against a shipping date and you've waited too long. So let's promulgate proper planning for handling reviews, particulary if you are using reviewers outside of your team who have their own projects to worry about:
If this seems like too much effort for your project, then don't do your project -- it's probably not worth doing. My father (and I'm sure many parents) always said "If it's worth doing, it's worth doing well." If time is too tight, talk your team or management out of doing it. If they think it's too important to drop, ask them why it's not important enough to do well.
Before I get to the closing fun, it's important for me to state clearly that I LIKE reviewing things. I like being able to add value to something I didn't have to build from the ground up myself. I like that someone trusts my opinion enough to ask for it. I just can no longer afford the time, effort and frustration it costs me if you aren't actually going use the feedback (part of the Lean mantra: Identify and remove waste).
I have a new set of questions I will be using before agreeing to review anything:
ME: I'm imagining it's fine, go ahead and use it.
YOU: But you didn't even look at it!
ME: You just told me you wouldn't have time to fix it if I found something worth fixing. What's the point of me looking at it?
YOU: But maybe you won't find anything big that needs fixing...
ME: Maybe not. But given the rush you've put this together in, it's almost certain.
YOU: Well, why don't you review it anyway and we'll fix the big things in the next version.
ME: Why don't you just publish it and when you are ready to start work on the next version, I'll review it then?
YOU: Because I need at least one reviewer to sign off or I can't publish it.
ME: Sorry. Let me refer you to this blog post I wrote.
I'm not being difficult. Like most of us, I can fill my days (and evenings) with my own work. I've read that learning to say "no" can improve your productivity by avoiding wasted effort and distractions. This is how I start.
Case Study: How social interactions changed my life (or how seeing rock god guitarist Eric Johnson made me a bluegrass fan)
Millard 060001WYSU Tags:  medicine music old media adrienne connection show secor ketch crow bluegrass social young 1,067 Visits
For me (and I imagine many others), social media and the opportunities it brings enrich my life. Everyone is more interesting than we probably give them credit for and if you listen to their story it will be hard not to like something about them. But that's not where this story begins...
Shortly after seeing Old Crow Medicine Show (pictured above sans one member too far left to fit in the frame) at the opening of the Oregon Zoo's 35th annual concert series, my wife and I were on a short road trip, reminiscing about the concert and the series of events that brought us there. I grew up on 60s hippie music (wearing out that Woodstock 3 record set) and came of age listening to 70s progressive rock of Yes, Emerson, Lake & Palmer, early metal from Black Sabbath (no one really appreciates Sabbath bloody Sabbath as much as it deserves) and the hard-edge rock of early Grand Funk Railroad. I've played in a band the singer not-very-jokingly referred to as "post Roman death metal".
So I'm still surprised that I now seek out bluegrass and Americana and these are the live shows I'm most likely to attend. What the heck happened? It all started at an Eric Johnson concert. [Eric is considered one of the most respected guitarists on the planet, though I'm not sure he's strayed into my new genre much.]
This is where it gets social, where one thread leads to another until you are no where near where you started. I find this sort of thing happening a lot when I have the time to follow links from one place to the next -- though not always with such dramatic life changes. My wife and I put this chain together as we were riding along the Columbia river.
Tony Furtado opened the Eric Johnson show. I never heard of him before that night (but I'm one of those people that comes for the whole show, not just the headliner). He was amazing (and the main thing I remember from that evening). I went home and searched for more about him because I wanted to share it with my wife. I found a link to a performance he did for the Woodsongs Old Time Radio Hour. Given the name and my musical background, I was a bit dubious, but watched it anyway. Also on the same program was Adrienne Young and Little Sadie. I fell in love both with one of the songs they played (Home Remedy) and their upright bass player's amazing smile.
This led to two subsequent actions: purchasing the album the song was on (the Grammy nominated Plow to the End of the Row) and attending the Live Oak Music Festival near Santa Barbara, California where they would be performing. The Live Oak Music Festival turned into an annual trip, introducing us to many other artists along the Americana, bluegrass and Celtic path.
My wife gets all the credit for the next link in the chain that brought us to Old Crow Medicine Show (OCMS). While we were enjoying the song Conestoga from the album, she heard a guy singing background vocals whose voice was interesting to her. A bit of research in the liner notes turned up the name Ketch Secor. Along with being a generally talented multi-instrumentalist, he's also the front man for OCMS (he was also Adrienne Young's banjo teacher). This, of course, brought us to OCMS who we saw for the first time at Stubbs BBQ in Austin, Texas (wonderful outdoor concert venue if you ever get the chance). Pretty sure this video was taken at the show we attended. Yeah, there were a lot of people there -- a lot of young people very into the high energy music of OCMS. We were hooked.
What has kept me hooked, weird as it may sound, is the teamwork of a good bluegrass band. Many bluegrass groups work around a single microphone, moving in and out to raise their volume when it's appropriate. You can tell that they are listening intently to each other, feeding off clues, reacting to what they hear. There's a case study in teamwork there that I may chase down some day. On the Americana front, the often deep and meaningful lyrics of the singer-songwriters keep me listening and wanting more. It's a shame everyone hasn't heard of Slaid Cleaves (we own all of his albums and have seen him at least a half-dozen times).
I'm hooked on social media and the opportunities it opens for everyone to find new things to learn about and cherish. Follow lots of different people, listen to their stories and see where it takes you.
This time I'm going to make your life better in a most delicious way (unless you are vegetarian/vegan). There's going to be some useful but gratuitous technical design stuff and some links, but the meat of the post is after that.
Importance of simplicity
KISS. Keep it simple,silly.
But why? Because people don't like to learn and won't bother to when they can avoid it: http://www.nngroup.com/articles/stagnating-expertise/ If you force cognitive strain on your users you will lose their trust and this has many downsides: http://www.nngroup.com/articles/navigation-cognitive-strain/.
When we look at great designers who have done simple well, it's hard not to see Steve Jobs at the head of that group (these quotes are from http://blogs.wsj.com/digits/2011/08/24/steve-jobss-best-quotes/, which includes many others if you like this sort of thing):
“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”
“Look at the design of a lot of consumer products — they’re really complicated surfaces. We tried to make something much more holistic and simple. When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can often times arrive at some very elegant and simple solutions. Most people just don’t put in the time or energy to get there. We believe that customers are smart, and want objects which are well thought through.”
Simplicity tells your audience that you care. Even if they are smart enough to use your complicated product and even if they are inclined to do so, they won't forget that you didn't try harder to build them what you should have.
If you are jonesing for some more technical discussion of why simplicity matters in software design, here's Rich Hickey's 2012 Rails Conf keynote: http://www.youtube.com/watch?v=rI8tNMsozo0. Some folks prefer his talk from Strange Loop the year before: http://www.infoq.com/presentations/Simple-Made-Easy Either way, you win.
Winner, winner, chicken dinner
We cook at home often. After a while, we got good enough that the results were better than going out in just about every way (except the cleaning up part afterwards). This of course leads to experimentation, different styles of cooking, using different approaches, etc. Some times these can get quite involved and use small amounts of difficult to find or expensive ingredients (and you always need to find the recipe to recreate it).
This post is a result of a recent chicken dinner at home. Everything I wrote above was just to get us here. I was surprised that such a simple recipe regularly produced some of the most delicious chicken I'd ever enjoyed. But as I pondered that, I realized that the simplicity may be the reason it was so reliably good.
Having prepared chicken many ways over the decades, we've settled on this recipe: http://www.epicurious.com/recipes/food/views/My-Favorite-Simple-Roast-Chicken-231348 because it is simple, easy to follow and yields the same delicious result every time. It's literally as simple as (1) rinse and dry the bird, (2) salt and season the cavity, (3) truss the bird, (4) rain salt on the outside, (5) cook it for about an hour. Sit down to a delicious dinner -- if that sounds too easy, just try it.. If the trussing-the-chicken part has you worried, it's also dead simple -- here's a 90 second video that will have you doing it in no time: http://ruhlman.com/2010/07/how-to-truss-a-chicken/
Simplicity isn't just about the quality of the result but also in how you get there. Thomas Keller is a phenomenal chef and could have written pages worth of directions (that people would have slavishly followed), but they weren't needed. He had a simpler way that worked perfectly every time. After you have done this once, maybe twice, you won't even need the recipe any more -- the simple steps will just stick in your brain. That's perfect instructional design. Enjoy!
Addendum: "Winner, winner chicken dinner" was stuck in my mind and I couldn't remember where it came from. So I had to Google it: http://www.urbandictionary.com/define.php?term=Winner+Winner+Chicken+Dinner