Only when we are no longer afraid do we begin to live. - Dorothy Thompson

One of the greatest obstacles for learning is fear. It can be the fear of failing, fear of being laughed at, or just a fear with no apparent reason. Usually I’m a person that doesn’t fear many things and it’s quite hard to come up with something that I wouldn’t do because of fear. But I have my share of fears as well. One example has long been my fear of phone calls. For some reason I really don’t like calling people on the phone. I have no idea why, but even the thought of placing a call has been something that has made me nervous.

Today I’m happy to say that although calling people still isn’t one of my favorite passtimes, I can call people if I need to, and it’s not a problem to me anymore. And here’s the secret:

You gain strength, courage, and confidence by every experience in which you really stop to look fear in the face. You must do the thing which you think you cannot do. - Eleanor Roosevelt

You must do the things you think you cannot do. - Eleanor Roosevelt

These two quotes from Eleanor Roosevelt say it perfectly: If you’re afraid of doing something, you should do it. It’s the only way to overcome fear. By doing the thing you’re afraid to do you notice that it actually wasn’t so bad: after all you were able to do it quite easily. And the more times you do it again, the more your fear dissappears.

The same goes for all kinds of fears: If you’re afraid of public speaking, give a speech. If you’re afraid of heights, climb on a mountain. If you’re afraid of selling your product, create a web site and enable people to buy. The worst thing you can do is to let go of your dreams because of fear. Give a few thoughts to the following quote:

Too many people are thinking of security instead of opportunity. They seem to be more afraid of life than death. – James F. Bymes

Then think about any sucessful person that comes to mind. If Bill Gates would have been looking for security, he wouldn’t be the richest man alive. If Martin Luther King wouldn’t have stood up for his beliefs, what would be the racial situation in the world today? If I wouldn’t have started this blog, you wouldn’t be reading this post today. Well, the last one is in a quite different league than the first two, but it’s a big deal for me personally.

It’s true that some of our experiments fail – actually many of them do. But that’s why they are called experiments: even if they fail, we learn from them and know where to go next. As Louisa M. Alcott nicely puts it:

I’m not afraid of storms, for I’m learning how to sail my ship. – Louisa M. Alcott

When your sail gets torn or you lose a few weeks of time fixing an experimental solution that didn’t quite turn out the way you wanted, it’s usually not wasted time. Through your experiment you have learned a valuable lesson, something that makes you more of an expert on your area. And definately something that you wouldn’t have learned without trying.

And many times you succeed!

So, I’m encouraging you: be it in software development, business or any area of life, embrace your fears and do the very thing you’re afraid to do. As Franklin D. Roosevelt once said:

The only thing we have to fear is fear itself.

For my whole adult life I’ve been hearing buzz-talk about how the Internet will enable people to work from their homes or from wherever they choose without having to enter their workplace at all. The technology is there, but for some reason the motivation to start doing it is missing. For some reason almost all of us (myself included) travel to their workplaces for another 8 hours of work five times every week, Monday to Friday.

Now it’s time to stop talking and start doing. And here’s why:

1. You can decrease your CO2 pollution by 1,31 tons: Let’s do a quick calculation. I live at 18 kilometers from my workplace so the distance I travel each day is 36 km. In a year it makes 8480 km and 560 litres of gasoline. That’s almost the same distance as traveling from New York to San Fransisco and back – can you imagine it? With the current gas prices it would cost me 760 Euros in Finland and roughly 440 dollars in the US. The price of course depends on your country, but I can assure you, it’s going up. Most importantly however, the amount of CO2 that I would be putting in the atmosphere would be 1,31 tons every year. Based on Wikipedia the labour force in the European Union is 221.5 million, so if we assume that they all would go to work by car together they would be creating 290 165 000 tons of CO2. That’s huge. And it’s Europe alone. Using public transportation helps already quite a lot. The same number of kilometers would be creating “only” 0,47 tons of CO2 for me (this is what I’m actually doing) and for the whole EU it would be 104 105 000 tons. A huge difference. But compared to zero it’s still quite a lot.
2. You can gain two weeks of extra time: This is not an environment issue, but it’s good to keep in mind that getting rid of your office is not only a thing you do to save the Earth, it’s also something that makes your life more enjoyable. For most people commuting isn’t anything more than time away from doing something they enjoy. I spend 1,5 hours in a bus or a metro every day. In a week it makes up one full working day (7,5 hours). In a year 352,5 hours. That’s more than two weeks! And 1,5 hours of commute per day isn’t even a lot. I’ve heard that many people commute for 2-3 hours or even longer.
3. You can save in heating (or cooling): When you’re at work, your home is usually empty. Kids are at school, parents are at their work places. However, you still need to keep the heating on, otherwise you’ll be freezing when you come back from work. And the same works the other way round too: During the night when you’re at home, you need to keep the heating on at the office.Assuming your office is quite small, let’s say 100 square meters, its heating can produce 1 ton of CO2 per year. A bit more than half of it is unnecessary. And at the same time you’re wasting a similar amount of CO2 at your home as well. So, this means around 1 ton of extra CO2 in heating per person. Again, for the whole European Union it grows to 221,5 million tons. This estimate is not very accurate because there are more than one people per office and home, but you get the picture.

In total if everyone in the European Union would start working from our homes (hypothetically – I know it’s not possible in every profession) we could reduce our carbon footprint by 500 million tons!

I suggest you calculate your own CO2 footprint and then close your office door for good. If you’re not in a position where you can make that decision, at least use public transportation instead of your own car. That’s what I’m currently doing, while thinking about how I could take the next step and start working from my own balcony.

Have you ever been in a situation where you honestly don’t know if you’re doing what you’re expected to do or not? You don’t have a clear picture about what you boss wants you to do, or what are the criteria he’s using to track your successes and failures. Chances are that they are a mystery for him as well.

Or maybe you are a boss thinking about whether you dare give honest feedback to your developers. Maybe they’ll get mad and quit? Let me reassure you (although this is a subjective opinion from just one developer – it would be nice to hear about other people’s experiences in the comments too), giving feedback will make your people feel more relaxed and more interested in their work. And they will appreciate you more.

1. Clear expectations: One of the biggest demotivators related to feedback is that people don’t know what is expected from them. Or they know it on a superficial level, but when it comes to real everyday decisions, it becomes much fuzzier. If the developer knows the expectations, and they fit into her own career goals, she’ll work hard to meet them and make you happy. If the expectations don’t make sense, she might be more motivated if you kept the expectations secret. But then again, only a fool would set expectations that don’t make sense. Right?
2. Positive feedback: I think that positive feedback is important for two main reasons. I’m sure that psychologists would come up with many more, but here are my reasons: First, positive feedback creates a sense of security. It assures that you’re doing pretty well, and therefore you can take some risks and it makes you better prepared for negative feedback. And secondly, when correctly used, it improves the status of the leader. When the leader gives positive feedback at the right time he shows to the developers that he actually understands something about the nature of the work that is being done.
3. Constructive criticism: If the foundations are in a good shape (clear expectations and plenty of well-timed positive feedback) constructive criticism is the single most effective tool for either making or breaking the motivation of a talented software developer. Imagine a top notch software engineer called Lisa. Every day she gets to work, does pretty good work – maybe even outperforming some of her work mates. She gets lots of positive feedback, but deep inside she knows that she could be so much better, that she’s actually only giving 70% of her performance to the job. Because no one gives her negative feedback, slowly a moral dilemma grows in her mind: “why should I try to do my best when this much is already enough?” And once she decides that she actually shouldn’t, she starts to get demotivated.

So, if you are a boss in charge of software developers (or other creative workers) make sure you make your developers feel that in general they are doing a great job. Then whenever you notice that someone is not using her full potential, let her know that. Don’t just accept it thinking that she’s already doing as well or better than her colleagues. She will appreciate you for noticing.

Like just about everyone I need to get a hair cut every now and then. No matter how hard I try to slow down the growing of my hair I always find myself sitting in the barber’s chair a month after the last time. And I always get the same unnerving feeling that I have no idea how to explain my needs.

I see lots of people with nice hair all around me: at work, on the streets and in TV. My hair is OK, but it’s not exactly like I’d like it to be. Although I have some ideas on how I’d like my hair to look like, I don’t have the words to explain my ideas to the hair dresser. And because of that the moment when I enter the barber’s shop is always a bit embarrassing. The conversation goes somewhat like this:

- What do you want me to do with your hair this time? She asks.
I think for a while about the image I have inside my head but end up lightly shaking my head and mumbling:
- Let’s do the same as last time. Just… well, just don’t cut too much…

Today, once again thinking about my next visit to the hair dresser it dawned to me: The hair dresser and I are basically in the same business. The business of finding out what people need and delivering it.

Our customers who come to us for software probably feel exactly the same when we ask them the daunting question: “So, what did you have in mind?” as I do at the hair salon.

This brings us back to the question about how we can read our customers’ minds and make them feel comfortable. Maybe what they are missing is a vocabulary. What if instead of asking me what I want the hair dresser would start by suggesting different alternatives by showing photos of different hair cuts and then I could say over and over “not like that, more like this one” and slowly we’d find the solution that best suits me?

I’d love that.

I would feel like I had a say in how I want my hair to look like, but I would also know that my hair became better than I could ever have asked for myself.

That’s what I’d call an approachable way of getting a hair cut.

And I think we can apply the same approach to software development.

I’m a big fan of Scott Ginsberg, the guy who wears a name tag 24/7 to make people friendlier. His ideas about maximizing your approachability and thus improving your odds of getting to know people, find new business opportunities and to make a name for yourself resonate very well with me.

Lately I’ve been thinking a lot about how I could improve my work as a software developer by being more approachable. It’s still an ongoing process and I’m slowly learning more and more about the topic, but in this post I’m sharing some of the key points I have found so far.

A big question when combining approachability and software development is: “how approachable can a software developer be?” After all, we’re in the business of making software and as we know, it’s the kind of work that requires quiet moments of concentration. I have found some clues for balancing between the two extremes, but I’d be happy to hear your thoughts as well.

So, how do you make yourself more approachable?

1. Be positive: Nothing turns people away from you more efficiently than a negative attitude.
2. Say yes: Or say yes more often than no. But make sure that you explain what yes means, for example “Yes, I can start working on this new project tomorrow, but that means that the previous project will be delayed by three months. Should I finish the previous one first?”
3. Be friendly: Make the people around you feel appreciated. Clients, colleagues, subcontractors – friends and strangers alike.
4. Listening is the key: Listen for real and leave your work aside while talking with people.
5. Concentrate in one person at the time: If you have a queue of people waiting for your attention, finish with one person before starting to talk to the next one. The person waiting will appreciate it because she knows that when you talk to her, she gets your undivided attention as well.
6. Smile: Show that you enjoy being you and doing your work. A smile is a really powerful thing.
7. Be trustworthy: Show people that you really want to help solve their problems and not just try to find an excuse for them. If you want to portray yourself as a lazy corner cutter, that’s fine. But for the rest of us, I would suggest that you concentrate on the question and work hard to find a solution.
8. Be brave: if necessary, break some rules. Show some leadership by taking action. But take this with a word of caution: You should be open with your rule breaking (and have a good reason for it) so that people don’t think you’re sneaking before their backs.
9. Keep people aware of what you’re doing: Your boss, clients, team mates or even the whole world. But don’t overwhelm them with information: find out how much information they want and deliver that – nothing less, nothing more.
10. Help people get to know you: use different forums like blogs, discussion forums, presentations, discussions over lunch. Make sure people know who you are and how you can help them.
11. The door is a bit problematic: A closed door helps you concentrate, but it also makes you seem harder to reach. What do you think? Should your door be open or closed (assuming you have one – I don’t)?
12. Be honest: If you’re working on something with a tight schedule, people can probably wait for you to get back to them without getting mad if you’re honest and precise. Instead of saying “Just a sec, I’ll get this thing done and then we can talk”, you should say: “I’m really busy right now, but let’s talk in an hour” or “Let’s talk tomorrow” or maybe you can say “I have five minutes now, let’s keep it short”.
13. You don’t always need to solve the whole problem: Being approachable doesn’t mean that you should spend your whole working time helping out other people. Usually if your colleagues come to you for help, they are more than happy already if you just point them to the right direction.
14. Answer your e-mail: I think it’s OK to batch process and not reply immediately. But you should still reply in 24 hours.
15. Say thanks: Thanks. You’re welcome. Please. These small words make a huge difference.

This was just the tip of the iceberg and in future posts I’ll be digging deeper to the questions of combining approachability and software development. To end this blog post, I would like to ask you a few questions:

1. How well have you been able to balance your work between approachability and actual development?
2. Do you have any everyday examples about approachability at your work place? Who’s the most approachable person you know?

Learning is at the same time one of the most natural things and one of the most difficult things there are. Organizational learning is even harder. It’s easy to learn things when you want to learn them, but it requires a tremendous amount of work to get someone learn something when the inspiration doesn’t come from himself.

One of the biggest obstacles to learning is fear. The fear of changing, the fear of leaving a safe area and going out to the wilderness. And the scary thing is that without changing there is no learning. When you learn something, something inside you changes.

But learning can also be an exciting adventure in which you experiment with your limits, your interests and your life.

Here are some ideas to start your experiments with. Don’t try them all, but maybe by doing a few of them already makes you enjoy change, and thus enjoy learning a bit more. After a few more changes, learning becomes fun, and you become more curious.

1. Change your working hours
2. Change the way you talk
3. Change the way you drive
4. Change the way you wake up
5. Change the way you listen to people
6. Change the way you sleep
7. Change the way you set your professional goals
8. Change the way you write
9. Change the way you read the Bible
10. Change the way you treat your family
11. Change the way you look at the world
12. Change the way you look at deadlines
13. Change the way you market yourself
14. Change what you eat
15. Change what you appreciate at work
16. Change the way you treat your customers
17. Change the things you’re teaching to your children
18. Change the way you view the human race
19. Change the way you think about déjà vu
20. Change the way you plan projects
21. Change the way you code
22. Change the way you collect requirements
23. Change the way you decorate your office
24. Change the way you use the library
25. Change the way you look for information
26. Change the way you sketch

A few posts ago I talked about finding out what your customer really needs. But there is more to it: When choosing a product, most people rely more on emotions than rational thinking. We use rational thinking to justify the decision, but usually it’s the decision that comes first and not the other way round (although we’d like to think it happens like that).

And if there are many products for the same purpose, it’s not rare at all that we choose a more expensive alternative over a cheaper one. That might seem a bit counter-intuitive: if all of the products do the same thing, why do we choose the expensive one?

The answer lies in our emotions. Somehow that specific product and its marketing has touched a part of you and created emotions, made you feel that it’s better than the rest. To illustrate the point, let’s look at an example product and the reasons why I would choose it instead of some other, cheaper alternative.

Values matter (The Moleskine notebook)

I enjoy journaling my thoughts and writing down ideas that pop into my mind. To do that I need to have a notebook. There I have the need, so is that all there is to it? Do I go with the cheapest basic notebook and a regular ballpoint pen?

No.

Although the cheapest notebooks fill my need on a rational level I’ve noticed that they don’t work for me. When writing on a cheap notebook I feel that my writing is cheap and written to be thrown away just like the notebook. But when the notebook itself looks and feels valuable I pay more attention to what and how I write. The thoughts written on a notebook like that are meant to be saved for years.

Moleskine goes one step further: it tells you that you should be proud of writing your thoughts to a notebook, going as far as quoting Oscar Wilde:

I never travel without my notebook. One should always have something sensational to read in the train.

Wow! They are saying that my writing is sensational. How does that make you feel? It makes me feel that they appreciate me and want to support me in my writing. And by doing that they get me thinking that our values match, they appreciate me and put me in the same league with authors like Oscar Wilde… And then the only reasonable thing for me to do is to go and get one of these notebooks, right?

What about us?

Let’s end this analysis with a few questions:

1. What are you doing to make your customers feel that you appreciate them?
2. What do you value most? And then even more importantly: are you presenting your values to your customers?
3. Are you selling just products or do you also sell your world view and values?
4. Why should your customers choose you over the competition?

Now I’m off to think about my own answers to these questions.

For the past few days I’ve been struggling with a moral dilemma: I’m attracted to the idea of test driven development (TDD) and writing unit tests before actual code, and it’s great whenever I do excercises to try it out. My problem is that although I’d like to work in a completely test driven way, I have problems actually practicing the methodology to the letter. So, “good that I have a blog”, I thought and decided to ask my readers (that’s you!) for help.

The ideal procedure presented in TDD literature and for example eXtreme Programming is that you start with a minimal piece of functionality that you want to add to your code, then you write a test for that. First the test of course fails because there is no code available. But once you’ve written enough code to make the test pass, you move on to the next test. And so on.

I get stuck at the first step. When I start a new application and need to write that first test for it, I just don’t know what to write. I don’t want to do big up-front design because it’s against the Agile principles, so how do I know what my first test should be?

My solution so far has been to start with some design and a prototype of some kind. For example a mock up of the UI, some screens laid out in HTML or even some Rails controllers. Slowly I start to see the application and how it should be designed, and then I write my first test. That’s when my prototype starts to evolve into a real application. One test at a time, I create the model class and move functionality where it should be instead of the place where I dumped it in the first place when I didn’t know what I should be doing.

This violates a few principles: first, some people say that you should only use your prototype during design and then start from scratch again. Instead of doing that I’m evolving my prototype into this fully functioning piece of software. Second, as I said, it’s not really test first: I’m doing kind of a coding phase before I know what I should start testing. And sometimes it’s not only in the beginning. And I’m not prototyping only at the beginning of the project: When I’m done with the clear part and again start to work on something I’m not sure how it should be done I go back to prototyping mode until things get clear again.

So, I have a few questions that I hope you could help me solve:

1. Is it OK to go to a prototyping mindset every now and then and still think that you’re being test driven?
2. How strictly are you, other developers, following practices like TDD? Do you think they should be practiced like a religion, or should we be using our common sense and create our own mixes of practices? Why?
3. And if you’re able to do completely test driven development, what’s your secret? Where do you find the first test? And so on…

And now, the floor is all yours.

A paper free office is a great idea. It’s friendly for the environment, it’s less cluttered, it’s “web 2.0″ and it makes us feel like early adopters. Unfortunately the modern computer based tools are not always as efficient or user friendly as their old-fashioned paper based alternatives. So (this may sound strange coming from a software developer) although I’m usually in favor of using computers to help us as much as possible, there are some things that I rather use in analog format instead of the digital alternative:

1. Calendar: There are so many digital alternatives available that there must be something wrong about me if I cannot find any that suits my needs. I’ve been using Outlook, Google Calendar and Backpack Calendar and tried a few others during the past few years. All of them have some good features and most of them are pretty solid packages, providing me with lots of useful and some unnecessary features. But they all miss the one most important thing about a calendar: I can’t carry them with me all the time. If I want to simply check an appointment, I have to start my computer, and that takes at least 5 minutes. To fix this problem I have tried using my mobile phone. It has this one thing right, but about everything else is wrong. The user interface is clumsy, the screen is small, and synchronizing the calendar with Outlook is too much work. So, I’m opting back to paper. Although I haven’t yet bought my new paper calendar, here’s my new calendar of choice.
2. Diary: Following Scott’s advice I’ve started writing my thoughts down every morning. I also write any small idea that pops to my mind as soon as I think of it. In order to achieve these goals I have three notebooks: a tiny one that I carry in my pocket all the time for quick ideas, another one for my daily diarying and a deliberatePeople diary for writing down things learned from reading the Bible. I have tried diarying on a computer before, and the problem is that when you open your computer, you’re surrounded with so much distractions that you cannot concentrate to the diary anymore. A paper diary is quick to open to write a few words and close again. And the same way as the paper calendar, you can use your note book anywhere. One more thing to consider is that when your diary or note book looks nice you feel like writing more. That’s why my next diary will be a Moleskine.
3. Sketchpad: When working, I clear my head by writing down every idea that runs through my mind. I draw diagrams, mind maps and sometimes even just a few words here and there. In order to clean my desk from all the paper I have around me, I have tried doing this with Notepad, some graphics programs, even online mind mapping software. Although I think that online mind mapping and Backpack are pretty cool for stuff like this they are not perfect. Paper has one thing extra which is really important for creative thinking: the freedom to draw over the lines, cut off a piece of paper and so on. Basically you can do anything you want with your piece of paper.
4. Task cards: This is something I came up with a couple of months ago. It might not be a new idea, but what I’m doing is that I’m using my old business cards as task cards. On each card I write one clearly defined task and some additional information on what I need to keep in mind when working on the task. I have three piles of cards: empty cards waiting to be used, active task cards (in prioritized order) and used cards. Once a task is completed I take the card and put it in the used pile. It gives me visual feedback about getting something done. This approach needs still some more polishing, but even like this it seems to work much better than the Backpack task list or the Excel templates that I was using before switching to this system.
5. Books: There is one good thing about e-books: you can download them fast – you don’t need to go to a bookstore, a library or wait for the mailman to deliver your Amazon orders. But that’s about the only positive thing I can think of. Regular books are just so much better: You can easily take a book with you on a bus, in bed, in the toilet or wherever you need it. When working on your computer, you can keep the book open on the table next to you so you can look at it whenever you have something you need to check. If you were reading an e-book, you’d have to switch windows every time you need to look at the book. Also, book shelves look good and browsing books in a library or book store is a great feeling.
6. Time tracking: I’m currently using an Excel based time tracking, but the problem with it is that I always remember it only after I’ve turned off my computer. If I would have a note book on my desk for writing down my hours, I wouldn’t have to worry about that, opening the note book wouldn’t take long and I could write down my hours right when I remember to do it.

Now it’s your turn. Are there some paper based tools that you like better than their electronic counterparts? Or do you disagree with my list? Do you think there are improvements coming in the near future?

In software engineering communication plays a very big role. It could even be argued that software work is more about communication than it is about programming or design. The biggest reasons for software project failures lie in the communication between the team members than in any technical aspects.

Usually when talking about communication problems people tend to think about not having enough communication. Most of us would say that it’s bad if people don’t talk to each other, and suggest that the more we talk the better we work. But it’s not that straightforward. People can go overboard with communication, talking so much that their days are spent writing, reading and waiting for e-mail, talking on the phone, talking in person and so on. And in the end no productive work is done. When there is more talking than doing, it’s time to change something.

1. Trust your co-workers: Your team mates are professionals, so you don’t need to make every decision together with them. You don’t even need to know about every decision they are making, and you definitely don’t need to know the rationale behind their every decision. If their code works, trust that it’s good and do your part.
2. Trust yourself and be brave: Another common reason for too much communication is the fact that we are looking for others to back us up. But remember: You were chosen to your position because of your skills. You’re a professional, and your employer trusts you to know how to do your work. So should you. Just make sure you know what is expected from you and then just do your work.
3. Ask and guess: In some cases you have to ask, but it takes time to get the answer. This happens to me a lot because many of my team mates are living on a different time zone (we have a 10 hour difference), so I don’t get an answer to my questions until the next morning. If I just sit and wait for the answer, I spend many days in some unproductive work. If you’re in a similar situation, I suggest that you send the question, then take a guess and continue based on your intuition. In most cases you guess right and receive a confirmation on the next day.
4. Do unit tests: Documentation helps a lot, but documentation takes time to maintain. Test driven development provides a different tool to do testing and documentation at once: Write good unit tests that test every piece of functionality you’re writing, and suddenly you have documented your code. Unit tests also back up your guesses: when you try to work based on your hunch, the unit tests will tell you when you’re going wrong.
5. Kill meetings: This is a common advice on the Internet, but sadly most companies still don’t get it. In a meeting in most of the cases at least half of the people present aren’t really needed for more than 10% of the duration of the meeting. So, if instead of calling the people in a meeting you talk to them individually, you’ll end up saving many people’s time, including yours.
6. Prioritize: Only ask the important questions, because if you don’t you’ll be not only spending a lot of your own time writing e-mail, making phone calls or chatting with your coworkers, but also spending their time. Also, often people might answer to your easy questions first, so by prioritizing your questions you’ll make sure you get an answer to your most important question and not some less important ones.

Remember that time is the most valuable asset you have. If you want to finish your projects on time you don’t want to go spending your time on unnecessary discussion. So, optimize your communication, trust yourself and your team mates and be brave. Guessing isn’t always as bad as it might sound.