The Evaluation of My Software Sabbatical

Erik Schlyter - Tuesday, 14 August 2012, 23:43

Inspired by Stefan Sagmesiter, Rick Hickey and Richard Hamming, I decided to try a software sabbatical and devote one full month of unpaid leave to simply ponder on the wider puzzles of our software industry. Even though the practical results were meager, it gave me an opportunity to concretize some of my visions and I learned a lot about my own needs for creativity. This article will be a summary of this way too short journey, along with some thoughts on the process of innovation itself and what attitude we should have towards it.

Tuesday, 14 August 2012, 23:43

First of all: one single month is a very short time to do anything at all. I started out with three simple projects in mind, and the general assumption was that since I had spent plenty of time pondering hazily about some general concept, this sabbatical would provide me a month to make them happen. I realized afterwards that this approach was somewhat misguided to the notion of using a sabbatical for creative thinking, since hammering down code doesn't really require the same disruption from the everyday routine to be productive. Instead of spending a month with the aim of producing code, I should have focused completely on just creative thinking and leave the actual hacking to the evenings of rest of the year. Luckily for me, my initial ideas quickly turned out to be very abstract and vague when I actually sat down, so much of the month was actually spent on exploring new approaches anyway.

Most of the practical work during the sabbatical was spent on studying compiler technology, since that turned out to be the common denominator of my ideas anyway. I was hoping to produce some kind of measurable results, but in practice there wasn't much done other than some prodding experimentation. This was of course was very valuable to me, but it didn't really spawn anything to show off. This realization was kind of dejecting to face in the middle of my leave, but I also had to accept that it's quite naive to expect one to cover what essentially is a five week university course during the whim of a few days.

On the positive side, I learned a lot about compiler technology (I really should have taken that course when I actually was studying at the university) and I feel essentially more confident about my ideas and how to proceed with them. I am also happy to mention that I'm currently working on a framework for modelling and transformation that I'm very enthusiastic about. I hope to use it in the future to demonstrate alternative programming principles that are more focused on actual problem solving rather than just telling a machine what to do. My visions of these principles are getting more solid, and I got some articles on the way that I genuinely believe will provide real value for people interested in improving the efficiency in their production environment.

Beyond the compiler studies, I also spent plenty of time pondering about the concepts of creativity and innovation itself. It was very refreshing to analyze my own experience very thoroughly and reflect upon what needs I have myself when it comes to creativity. Even though a month was a very short time it was rejunivating to just try the experience, and I learned a lot that will benefit me greatly the next time (yes, there will be a next time, as soon as circumstances allow it). Just to get something straight; the sabbatical is not a revolutionary recipe for all the world's complexities, and there is certainly nothing magic about it. It is simply a different approach in the sense that it is aimed to find new ways to solve problems.

Simply speaking it is an attempt to be more innovative and creative. When you sit in front of your computer and try to fix bugs in your code, the solutions are often in the sum of the details in front of you. Leave that kind of thinking to the production environment and devote your time off to the more the abstract visioning. If you consider doing something like this yourself, I have a set of personal realizations I would recommend you to consider.

  • Focus on the big and abstract issues. You want to start at the highest possible abstraction but still have a sense of direction. Use your imagination and explore how things could be different. Ask yourself why, why, why to make sure you actually identify the real problem instead of getting stuck in someone else's preconceived idea. Once you have identified the real problem, focus on creating visions, not solutions. Let the solutions come afterwards. The point now is to allow your thoughts to be fed into your daydreaming mind where they can grow and intertwine subconsciously. With enough inspirational input, your brain will start making association between useful chunks of information while you eat, sleep, exercise or do whatever you find recreational. When you got enough goodie in the back of your head, you can start picking down possible approaches, do some experimentation and try to proceed more focused and structured.

  • Try to get some friends to join in. When you devote plenty of time for creative thinking it is very productive to get some simple feedback once in a while. Friends and like-minded will quickly point out flaws and difficulties with your ideas, and they might provide new perspectives that you haven't considered. This is a resource I admit was severely underused during my sabbatical. There is plenty of opportunities to find fellow enthusiasts if you consider what is possible with blogs, forums and communities these days.

  • You don't have to deliver. You should remind yourself about this continuously. People will tell you to set up schedules and quantifiable goals, and yes, you will benefit greatly with some structure, but don't set the expectations to have something do show off. That's the production way of thinking, not innovation. Remember, the purpose of the sabbatical is to plant the seeds, not to grow the actual trees. The anxiety and pressure that inevitably comes from deadlines will bog your thinking down. Do the thinking now, save the work for later.

  • Organize your thoughts. This point might sound like a no-brainer, but I would still like to mention it because it is very easy to forget (I did, several times). Always keep a notepad and a pen with you whenever you're out hiking or doing whatever, because when elusive thoughts suddenly crystallizes (and they will) you want to note them down in some kind of persistent medium before they turn to vapor. It is probably good to keep them in some kind of organization, although I admit I don't know which approach is best. If you have any good suggestion on this I would be happy to hear about it.

  • Sort out the social and emotional issues before you begin. Consider Maslow's hierarchy of needs. Make sure you have the financial situation covered so you don't have to worry about food or rent the upcoming months. If you consider moving to a new place or getting a new job, make sure you decide upon these things before you start—or better yet, have them done before you start. It could also be good to evaluate the stability of your family situation. It's not like you should cancel your sabbatical because you had an argument with your spouse, but if you have a sick relative, emotional remnants of a bad breakup or other personal issues that probably won't go away for a while, you might want to consider if it's worth postponing your sabbatical. You can most likely still do useful work, but anxiety and external stress factors will severely impair that background mind of yours that you aim to utilize.

  • Context switch when you get stuck. Getting stuck is boring and painful. Remember, you don't have to deliver anything, so spending time being stuck is just waste of time and energy. It might be good to keep several different projects or ideas on your desk at the same time. Once you get stuck on something, try to context switch and let that part of your mind settle for a while as you ponder on something else. Get back to it later when you are refreshed.

  • Take breaks, exercise or simply do something just for fun. Don't be afraid of taking breaks and do things just for fun, even if it means dressing up in a gorilla suit or play MacGyver with your newly bought kitchen decoration. A happy spirit is a prerequisite for a creative mind. I also recommend you exercise regularly. As it turns out, aerobic exercise is apparently pure gold for your cognition. I got really inspired by the first chapter (although I recommend the entire book) of John Medina's Brain Rules, which I highly recommend if you are interested in the subject. I frequently went out jogging when things got stale, and I actually made some of my revelations while on the track.

  • Learn new things. Read and read some more. Read books, articles, blogs or whatever you can find that provide insight and reflections in the area you are researching. There's plenty of free and inspirational talks on the Internet from various conferences. I found to my joy that the Norwegian Developer's Conference published their talks this year as well. It is a gold mine of knowledge and experience, free for you to indulge. Don't just watch, act as well. Do some code katas in a new programming language, or hit any of the many thousands of fun programming problems you'll find on the UVa Online Judge site.

Incorporating creativity and innovation

The ambition is to find ways to incorporate the principles of innovation into the production environment of everyday office life. Preferably on all scales, from the small start-ups to the big machineries of big corporations. Obviously my experience is not mature enough to give any real pointers, but as I was given time to scrutinize my own experience I have some realization based on my own needs for creative situations.

First of all, you can't make people innovate, you have to let people innovate. Innovation is dependent on creativity and inspiration, and people are creative at different times in different environments. As Rick Hickey states in Hammock-driven development when he talks about the background mind: you can only feed it, not direct it. Like a gardener, you can only provide the right conditions. You put the seeds in the soil, provide water and sunlight, then you guide the process along the way. You can't pull the flowers from the ground, you have to let them grow. Sometimes they flourish, sometimes they die.

Brainstorming workshops

I think there's many of us who have stumbled upon this approach once or twice in our careers. You arrive in the morning, and after some hyped power point presentation you get bumped into team A and assigned to solve problem X. You spend some hours disputing back and forth, you summarize it in a couple of notes, then you forget all about it while you stumble back to your bug fixes and code reviews. Some days/weeks later your manager posts an "evaluation" and people expect results to act upon.

The biggest problem I see with these problem solving workshops is that they are too focused on actually solving problems. There might be value in this if the problems aren't too complex or significantly life changing, but to me this approach misses the key points of creativity completely. People look at the gathered notes at the end of the meeting and expect them to be the end results. These notes are not the results, they are barely the seeds. People have very individual and very specific needs when it comes to being creative (at least I have), and these meetings simply presupposes that those needs are synchronized at that specific location at that specific time. Personally I have never managed to contribute any substantial value from a meeting like that. Have you?

This is why I believe these brainstorming workshops where people are locked up in a meeting room are a bit misfire, even if they are done casually. You can't just stick a bunch of people in a cabin somewhere, armed with a fixed list of issues, a whiteboard and a case of beer, and hope they will eventually reach the Balmer peak. Events like these are of course precious opportunities for collaboration, team building, getting people to reflect upon the problems and constraints, but in my experience people (including myself in former days) tend not to realize that this is only the first step. Once you crammed all the details in your head, you need the actual incubation time in your background mind, but people skip this part and run right back to the office treadmill.

Public conferences

In contrast to the brainstorming workshops, I believe the more generic conferences (I really enjoy the ACCU conferences) have so much great value because you actually get to meet people outside your own box. I have noticed that the attitudes towards these conferences are quite dispersed. Some people think they are awesome while others think they are just a waste of time, and I think most of the negative opinions come from misled expectations. In similarity with the brainstorming workshops, you shouldn't consider the content to be the end-value. The seminars and presentations shouldn't be considered to be instruction videos (although they often do contain very solid chunks of knowledge), they should be considered as diverse sources of inspiration.

To me the real value of these conferences is the opportunity to engage in discussions and debate issues with other people, some of them the oldest and most experienced gurus of the industry, others more young but from a completely different professional background than you. Maybe developers in the finance industry perceives some problems different than the developers from the media industry. Maybe developers from the small start-ups sees other difficulties than those faced in the big international conglomerates. Can they learn something from each other? Of course they can! Each evening at the hotel bar provides wonderful opportunities to exchange ideas with your fellow attendees. The fact that each conference day is packed with thoughtful conversation starters from morning to evening is for me just a bonus.

X% off for personal projects

The approach of giving employees a certain amount of time off for their own projects—hoping it will spur innovation and new product ideas—has been around for some decades now. Although it seems the concept was made famous by Google, the idea was apparently realized at 3M where Arthur Fry invented the Post-it note. Hewlett-Packard is also well-known for this approach.

The success stories certainly seems grand, but I must remain skeptical even though I see great potential in the approach. As I stated earlier, you can't make people innovate, you have to let them, so just throwing free hours at people will probably not yield automatic miracles unless you have a very unique work environment. Scheduling time for these personal projects has also been shown to be difficult for social reasons when deadlines and release dates are closing in. I don't have experience of this myself, but the consensus seems to be that it's a good idea but hard to implement in practice.

Personally I believe a more healthy approach is to focus more on personal education and development of new skills rather than just cracking fun hobby projects. I noticed that Itemis, the main developers of xtext, adopts this principle with their 4+1 approach. It seems more down to earth since you will need skills and deliberate practice to grease the wheels of your current development anyway, regardless whether you are innovating new products or not. An environment that doesn't encourage its developers to read, study and learn new things seems to me to be the best recipe for turning its projects into boiling frogs by bad habbits and inefficient procedures. Worse yet, if you don't get continuous input on how the rest of the world is tackling their problems you will probably never realize it either. Not even when the frogs are dead and buried ages ago.

Self-awareness and the need for innovation

I must admit I haven't found any substantial evidence that one month of continuous thinking really is more productive in terms of new ideas compared to the same time chopped into afternoons and distributed over the year. I do however feel there's definitely more to explore with this approach, and I have realized one thing: It's hard to think outside the box when your spend your days chained into one. I can't claim that a sabbatical is the magic formula, but I am very confident in the idea that you need to back off a bit if you are to conceive any original ideas, and doing that is a lot easier if you are on a continuous leave.

So, to the big questions: Is it really worth it? Do we really need to spend this time goofing off on side-projects, sabbaticals and conferences? Are we really in such a need of innovation when it comes to software development? Can't we just stay in the office and write code as we always have done, without succumbing to these hippie methods? Maybe, maybe not. Truth is, your organization will probably not completely stop being "creative" just because you don't let your developers loose. You will most likely continue to earn some money even if you don't throw your employees at conferences. Your competition will probably not kill you in an instant just because you didn't give your team Friday afternoons off for informal discussions.

In the long run however, it is my personal conviction that a bright future of our industry is completely dependent on people taking charge of creativity and innovation as serious concepts, thus taking actual steps towards it without leaning back on the cushions of empty words. I am also convinced it is extremely important to be self-aware of the current situation, and to cherish the ability to evaluate and acknowledge problems even if you don't have any immediate visions of how it would work otherwise. If you live in Antarctica, you shouldn't need a postcard from Saint-Tropez before you realize "wow, this place sucks". Given that, you should also consider that there is one thing to acknowledge you're in an undesirable situation and a different one completely to do something about it. You might down-prioritize the wider problems because you have others more present issues, but do not accept mediocrity in your development environment for the sake of comfort and simplicity.

If you're hauling rocks to the pyramids, you might look at the river and think "hmm, it should be a lot easier to transport these rocks if we moved them on the river on top of some kind of flotation device". Your slave driver might yell "that's preposterous, we don't know anything about boats. Now carry that rock and taste my whip *slash*slash*". It is certainly true, you might not know anything about building ships, but that doesn't change the fact that those rocks should be carried on water instead of people's backs. Newton basically invented calculus on a whim because he needed some framework to describe the planet's elliptic orbits. What's your excuse? If you don't know how to do it, then learn. Go figure it out.

To sum it up; Why are you still here? Go innovate! Go! Now!

Erik Schlyter
My name is Erik Schlyter, and I'm a software development enthusiast and a professional programmer. I work as a freelancing consultant, trying to make the world of software a better place. I'm passionate about clean code, automated testing, autogenerated specs and documentation, efficient use of distributed revision control, and making those bits and bytes dance to my whims.

Other thoughts, ideas and articles

Some of my spare projects