When you consider that “fail fast” is a mantra of the lean startup movement, a silicon valley catchphrase, its own book, and thirty-six thousand google search results, the term must be right … right?
Well, sort of. To the extent that fail fast enables people to experiment, to try new things, to learn from them instead of continuing to bang their heads against the wall in the hope of getting through — sure. Fail fast is good.
And we can do better.
In the ITKE Discussion forums, a question was posed that I felt compelled to answer.
“Can someone explain the benefits of my life after completing my Java courses?”
I am no stranger to course work related to programming. In the mid 1990s, I earned a Certificate for UNIX Programming through the University of California at Santa Cruz. While I completed the Certificate program, much of the advanced C language work I focused on was never used again. The shell scripting I learned, however, I still use today. Why? The shell scripting skills had an immediate and tangible effect on my work.
It’s great to learn a new language, or get some time experimenting with a new framework, but experimenting with it alone isn’t going to help us keep those skills. In fact, the speed in which we lose skills that we develop but don’t use can be frighteningly fast. What can we do to make sure that we actually use what we are learning?
Learn in Public
Whether you have a formal blog or just a dated journal, write out what you learn. Imagine that someone with no experience will be reading later. What would you want to show them? What pitfalls did you run into? Making your learning a public document allows you to capture the learning as it happens, including your frustrations. Those interactions are valuable. They will help you solidify concepts in a way that just writing code will not do.
Make It a Daily Habit
Many friends of mine have had the opportunity to spend two years in a foreign country, and all of them have said the same thing when I asked how they became fluent in the local language. They didn’t do it by studying grammar rules. They went out into the community with other native speakers. They fumbled around to make themselves understood. They repeated this every day. At some point, it became automatic. They just communicated in that language. Had they not had that daily interaction, it would have never happened. They had to interact, they had to communicate, and it became part of who they were and what they could do. Programming is the same.
Work on Things That Matter
When all we do is the sample problems, copying the answers, we may get a cursory understanding, but we will not develop true proficiency. When it comes time to do something different, we will likely flounder and get frustrated that we don’t know how to make that example we learned work in another context. Everyone goes through this phase, and everyone feels the same level of frustration at this point. Make yourself change contexts. Find different ways to use the examples you are working on, and do so with projects that actually matter to you. Find a problem that is keeping you from accomplishing a task. Use the programming language you are using to help you solve that task, even if the solution is rudimentary. As you learn more, continue to apply it to your original problem. Share your solutions with others. See if they can come up with additional problems you can help solve.
In the end, any skill we learn is only as effective as the work we put into it and the regular practice we do. When it comes to programming, the mantra “use it or lose it” is painfully accurate. You may understand what you are learning, but implementing what you learn, regularly, in real situations that you personally can use, will spell the difference between a passing surface knowledge and an actual skill that you can call on regularly and reliably.
Last week I went to snowy Columbus, OH for a regional software / quality assurance conference called QA Or The Highway. QA Or The Highway is a one day conference, this year, it was preceded by a one day workshop on teaching software test design.
The workshop and conference were fantastic, but the conference keynote was particularly interesting to me. Gareth Bowles did the closing keynote on his experience working at Netflix and why they do a lot of testing in production rather than the normal pre-release testing we see.
Lets take a closer look at his keynote.
I’ve had both the pleasure and the challenge to lead an initiative over the past five years called Weekend Testing. It’s a loose model based on the idea that a session is announced, a mission is declared, and people are invited to participate over Skype. It takes place over the course of two hours. The sessions are informative, fun and, in my opinion, very organic. While I may have a general idea of a topic or a goal, where the session will go or how it will be received is anyone’s guess.
The biggest challenge for me personally is to try to come up with topics that are unique and interesting. I’m not alone in this initiative, I have a couple of other facilitators that help with developing sessions as well (my fellow Unchartered Waters writer Justin Rohrman being one of them). It was during a recent conversation with Justin, as we were discussing how to propose new sessions, that we started talking about how difficult it can be to make something that is “new”. As we were talking, I shared with him what I call the “Becker-Fagan Effect”. What is that, you ask?
This term comes from the 70s era band Steely Dan and their principal songwriters, Walter Becker and Donald Fagan. Fagan once said about their partnership “Walter (Becker) can’t start a song, and I (Fagan) can’t finish one, so we work well together”. I’ve come to realize over the years that this is a valuable insight to creative work of any type. In my everyday work, the biggest problem for me is getting started. I’m very much a “Becker”. I confess to often being stymied by trying to come up with something off the cuff. Put a blank sheet of paper in front of me and ask me to write, and I will struggle. However, if someone prompts me with a question, or with a kernel of an idea, then I’m off to the races, and I can pull together lots of ideas and initiatives. I contrast this with a variety of “Fagans” that I know. They are wonderful at getting things started, but have difficulty carrying them through to completion.
Our culture tends to credit the originators of ideas. We look to people who wow us with new products and inventions. We honor them with patent protections and copyright to protect their creations. This is understandable, but it hides the fact that, often, others helped them get that idea from a seed to a fully realized idea or product. The final version of an idea is rarely the brain-child of one person. The spark of creativity may come from another place, or the implementation of an idea may be spurred by someone else’s suggestion. In the end, we don’t really know where the start or finish motivation came from, we just know that the product or project crossed the finish line.
I’ve come to appreciate that I often need an initial spark from outside to get my ideas flowing. To that end, Weekend Testing now has an open call out to our participants, where we are asking those who regularly attend what areas they would like to see us address. Examples are:
– It would be great if we could look at free methods of managing projects.
– Could we look at this new utility?
– Are there ways we can simplify performing repetitive tasks?
Each of these is a kernel of an idea, and each of these allows me some latitude to explore, and ultimately come up with a finished session. Sure, I can bring the idea across the finish line, but without that initial idea, I have nothing to finish. Likewise, many people have the kernels of great ideas, but they may not know how to move forward from there. Starters and finishers, we need each other.
Last week, I talked about a way of thinking about thinking of social classes in software companies. The less obvious it is that we make money for a company, or the more often we have to deliver bad news, the less likely it is that we are part of the ‘it’ crowd.
How does the model effect us in a practical sense, and how do we change it from a dart board with defined boundaries, to more of a swimming pool where everyone is mingling?
I just came back from vacation to 212 priority-one email threads in my inbox. I have two days to hit the high notes on replies, get two proposals in, write an article or two. Then I have two days of technical work, Daddy Daughter Camp, then I drive three hundred miles to help organize a workshop, then speak at QAORTheHighWay, drive Three hundred back, consult for two more. On the weekend I see the family I haven’t really seen since vacation, then dive back in just about the time that program work is due for two conferences and tax season gets serious.
I just emailed Emma Armstrong, a friend of mine at RedGate Software, telling her I had time for a conversation … in about a month.
My work in progress is too high.
When work in progress is too high, you get stressed. The quality of your work goes down. You take shortcuts, and everything takes longer.
One task that takes ten hours can be done in ten hours. With ten tasks, performing one hour at a time, the average task now takes close to a hundred business hours to complete. And those numbers assume that you have no loss in focus as you switch between tasks.
It Gets Worse
Network theory tells us that when a transportation channel gets overloaded, things don’t just slow down to number of tasks*duration — instead, movement slows to a halt. You’ve likely experienced this when there is an accident on a four-lane highway when there is an accident blocking on lane under moderate traffic — you don’t go 75% of normal speed, you drop to 5%. Or less. We call this a congestion collapse event; the less-fancy term is gridlock.
I even had an assignment in graduate school to calculate the speed at which the network would degrade after 75% of capacity was reached – (we used Tanenbaum’s Computer Networking Book) — the short answer is never run your Ethernet network at over 80% of capacity.
When your work in progress is too high, you end up telling people you’ll call them next month … if you’re responsible. If you won’t, or can’t say things like that, you end up doing everything poorly. The system collapses.
The fix for excess work in progress is finish what you’ve started and not take on new work until you’ve finished. It sounds easy, but a consultancy that does that without ever considering the future will quickly find itself with no work in progress, a very different, and not so good, problem to have.
What Matt Is Going To Do
With some great personal pain I’m going to have to go back to two wonderful conferences and suggest we talk about 2016, not 2015. I’m going to have to tell the folks at TvForTesters and TestingCurator.com “not now.” I am going to let a draft proposal go unsubmitted and tell a friend from another continent, that no, I do not have time to build a talk together, as valuable and fun as it would be, and as much of a slam-dunk, easy-peasy work it sounds like.
Because my work in progress is too high.
I do not want to do these things. I have to do them in order to provide the quality of work my friends have come to know and expect. When I begin to dig out from all this, in early March, things will be a little better, and by April, better still. And yes, I will continue to refine my early-warning systems so they kick in a bit earlier, and yes, I will still need new work – though my ratio of paid to pro-bono may need to go up a bit.
Sadly, too many employees, teams, and divisions, feel they can not do this. Work is pushed onto the team, shuffled around in priority, and people feel they can not say “no” or even “maybe.”
There are a few things you can do, but in the meantime, I’d like to ask the readership: Is your work in progress to high — and what are you doing about it?
Companies can be modeled in all different ways. The Gervais Principle, mentioned here a couple times before, slices up companies based on who stays at the bottom and who rises to the top. I have been thinking about a different model lately, one that slices companies into layers based on social classes and social value. Or at least, perceived social value.
Scrum: The Art of Doing Twice The Work in Half The Time isn’t just a book about scrum. It’s also a book about Jeff Sutherland’s incredible life, a story about how scrum came to be, a touch of Lean and Toyota Production Systems, and some insights about why scrum works.
The first paper on scrum was published in 1995, but Jeff was experimenting and creating the foundation of Scrum before that while working at Easel Corporation. Twenty years have passed now, it’s pretty crazy.
Lets take a look at Jeff Sutherland’s latest feelings on Scrum and productivity.
It’s review time in my part of the work world. Once again, it’s time to sit down, examine the year that has past, and objectively determines what it is I have done over the course of the year. Along with this is the question of how this can be reported upwards to managers and HR.
This can be frustrating. It is a process where I need to look at what it is I am doing in my everyday work, and somehow show that I am doing more than just “doing my job”. The bigger question, however, comes down to “what does it mean to actually do more than my job?”
Planning is a polarizing topic in software development. The reality is that all different types and amounts of planning will get the job done, and software made it into production long before people were arguing about when and how a plan was created.
In more traditional waterfall organizations, every bit (or so we thought) of the work is planned out ahead of time, sometimes months ahead of time. Before the programmers go to work, something akin to a small novel will be handed over explaining each little detail of how the software should look and work.
At the opposite end of the spectrum is the agile crowd where the perception is that no planning occurs at all.