The Three Signs of a Miserable Job

In the book “The Three Signs of a Miserable Job”  Patrick Lencioni outlines that many working people are in a miserable job. In this post I want to share the basic idea behind his book.

The cost of people not liking their job is staggering. Productivity collapses greatly when employees are unfulfilled. It does not end at work. There is also a great social cost. Even emotionally mature employees share their work misery, frustration, cynicism, weariness into the lives of others. It becomes impossible to appreciate the joy of life. The emotional and psychological damage can be profound and irreversible.

The following three factors will make any job miserable. They seem obvious and maybe even easy to resolve. However, they remain unaddressed in most organizations.

  1. Anonymity – People need to experience that they are known for their work. We need to feel understood and appreciated for our qualities by someone in an authority position. When we don’t feel heard or think we are invisible, generic or anonymous within the company we will not love our job.
  2. Irrelevance – We need to know that our work matters to someone. When we cannot make a connection between what we do and someone else’s satisfaction we simply won’t find lasting fulfillment in our job.Someone needs to appreciate it and we need to know about it.
  3. Immeasurement – It is important that we can gauge our personal progress and contribution. We cannot be fulfilled when our succes depends on the opinions or whims of another person. Our motivation heavily depends on our ability to self assess success or failure. When we perceive that we cannot control our own fate our motivation quickly deteriorates.

Patrick tells us that we will feel miserable with even one of these factors present. What I read is that we our job needs to be meaningful to us and that we need a way to know how we are doing. How about you? Are you in a miserable job? How can we take ownership of these three factors?

Red Flag – There is no customer

In agile development we value customer collaboration. That requires a customer to collaborate with, agree? The first principle of the agile manifesto is:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Let’s focus on the first sentence of this principle. This clearly states that we want to satisfy “the customer”.

Who is “the customer”? Very often teams only deal with a project leader. The project leader’s role is to play the role of the customer. To me that is a clear smell. Yet, it is reality for many teams.

Everyone who’s ever been to a decent agile introduction training has been told that we work in close collaboration with the customer.

Now why do we consider real user access important? Well, we want to make sure we actually build software that our users love and are happy about. The answer is actually in the last part of the above principle: “delivery of valuable software”.  By talking to a real user you avoid building stuff they actually don’t need. You are not wasting your or someone else’s money and time and you avoid damaging your reputation.

So what are your options if you don’t have access to a real customer at the moment?

  • Keep things small. Small teams have a better chance to get closer to a real customer.
  • Use other ways to get access to real user feedback. Dropbox allows users to post feature requests and have other users vote on features they want. The advantage of such a strategy is that you even get a prioritized backlog.
  • Collect usage data from your application. Monitor what parts of your application are used most. Try to monitor how users use the software and when. You can maybe ask for in-app feedback. Make sure your users know and have an option to participate in this though. People may dislike it when they find out and did not know you where collecting data.

Even these options may be hard to implement for you. Eventually, it boils down to if your organization is able to understand the value of real customer feedback. That requires a humble attitude. An attitude where we don’t assume that we know what the user wants. We often confuse what we want ourselves with what the user of your software product might want.


Agile Dysfuctions

Agile development has been around for maybe close to 15 years now. Tim Ottinger and I started talking about “Take Back Agile“. My incentive for this was frustration and shame with what we have achieved in all those years.

The success stories about agile development often seem exaggerated. Most implementations of agile do not come close to what the stories tells us.

Joshua Kerievsky moved to Anzen. With Anzen we are looking at software development from a safety perspective. Safetely for customers, users, investors, developers, basically anyone who deals with software.

The advantage of being in the agile development professional for so many years is that it is easy to see patterns of success and failure. Unfortunately the latter still prospers despite agile development.

This post is the first in a serie that I am about to write.

I will start posting about red flags, problems, failure modes and defenses we have come to know over the years. My intention is to share this knowledge so you can use it to practice safer software development.

Using PostgreSQL with Ruby on Rails (and RubyMine)

Everything when I start a new Ruby on Rails project on a new machine I am running into issues getting everything to work with Postgresql. This is not a Postgresql issue, but simply a memory problem. I don’t do this that often, so I simply forget. This has lead me to write this blog, because it will be my ‘extended memory’ next time I need it.

This blogpost was written while using the following tools:

  • Postgresql 9.3 configured on localhost on port 5432
  • Ruby 2.0.0-p0
  • Rails 3.2.13 (nope… not the latest)
  • RubyMine 6

The purpose of this blogpost is to give you a workflow that will help you do the least amount of work to get your new Rails app working with Postgresql. My assumption is that you have installed Postgresql and are sure it is properly running. I use pgAdmin to check that.

Step 1 – First create a new role in Login Roles. In this example we’ll call the role TestProject.

Step 2 – In the tab Role privileges check Can create database


Step 3 – Create a new Ruby on Rails project in RubyMine. This step will also run rake and try to create databases. This will fail for three reasons:

By default RubyMine does not have the Postgresql driver installed. You’ll need to do that manually using the database menus in RubyMine. Later more about that.

Postgresql allows you to create new roles without setting a password, but this is misleading, because it won’t allow connections without a password login. You have to set a password  in the Definition tab. Warning: once you do that the Account expires field will be set to the current date. As a result of that you may still not be able to use the new role. Make sure to set the date to a future date.


You may receive this error:

could not connect to server: Permission denied
Is the server running locally and accepting
connections on Unix domain socket "/var/pgsql_socket/.s.PGSQL.5432"?

Using Google Search you’ll find suggestions that require messing around with file system soft links or moving files. Don’t do that! That won’t be necessary. Just add host: localhost to each database configuration  in database.yml and that will do the job. Your configuration should now look something like depicted below.


Step 4 – Run rake db:setup followed by rake db:migrate. This will create both your development database and your test database. This will leave the production database untouched for obvious reasons.

You are now set to go and start developing your application and use the regular database migration steps from Rails.

Skype Premium – Is it worth it?

I make regular international calls to both land lines and cell phones. Additionally I heavily use video conference calls with often five or more participants. This combination seemed to make it worth an experiment with a one year Skype Premium subscription. I was well aware of the Google Hangout alternative at the time, but I had not yet ran into many business people using a Google account..

Some context

I think it is relevant to know that I have a business internet connection with a bandwidth of 150 Mb/s downstream and 15 Mb/s upstream. I have been using this internet service for many years now and seldom found my internet connection to be the cause of trouble. For those occasions where my connection was the problem, I have an SLA that assures it gets fixed without hours.

About video conferencing

I can be pretty direct about this. Besides that Skype Premium claims that you can have video calls up to five people I can’t say it ever worked properly. This was the biggest disappointment right from the start. It is clear that a good video call depends on the quality of the connection of all participants, but I did not expect it not to work at all most of the time. Even when those with a poor connection limit the call to just voice, it did not work properly for me.

Phone calls

Phone calls to any of the countries, even cell phone calls, work fine. Even calls to India that regularly can be a challenge have always worked out fine for me.

The final verdict

This won’t be a surprise. The answer is: “No”. I have cancelled my subscription during the subscription period. Besides that I have tried to convince business people to use Google Hangout with reasonable success. Google Hangout is also not perfect, but if you rely on video conferencing for collaboration like I do, it is a much much better alternative to Skype Premium. And the best thing is, it is for free!

Take Back Agile

I have been an agilist for a long time. Approximately 15 years now. In the early days people just laughed at us. It started of as a thing for developers. Only the past four or five years it has grown to become something big. It’s considered mainstream now by many.

I can’t tell it has done the name ‘agile’ much good. Consultants and certificate horny people got attracted to it and that got worse when management bought into the some of the ideas. Some people really know what they are talking about and what they are doing, but many if not most don’t. The values that brought humanity to software development have been scrapped for mechanics, processes and certification.

We can do better. I value the agile manifesto over building a consultancy. I value real craftsmanship over certification. You get my point. I want our agile back.

Tim Ottinger (@tottinge – and some other folks and myself started Take Back Agile. We’ve created a domain, claimed the twitter, created a Google Plus community and group. We are ready to discuss this and see where it will take us. It’s free. We do not start this discussion with the intention to make any money out of it. Let that be clear. We just want our agile back.

Learning new programming languages and technology makes TDD and BDD hard (for me)

Today I find myself struggling. I have always been a backend server developer, c++, java, c# developer. I am trying to learn web development and mobile (web) development. I have never done any web development with javascript, html, css and that kind of stuff.

For over fifteen years I am a big fan of TDD and BDD. What I want is to development an application for a friend using Ruby on Rails for the backend server development and using Sencha Touch for the mobile web application. One of the reasons I stayed away from web development for a long time is the vast amount of technologies involved. As an eXtreme Programmer I love the idea of keeping things simple and I just never saw how the web development world was keeping things simple. And as a matter of fact this event of wanting to develop a web application for a friend has reminded me in not such a gentle way that this has basically never improved over the past ten year. I believe it only got worse.

Anyway… this is not what this blog is about. Forget about my whining about web development.

This blog is about an interesting phenomena that I ran into the last few weeks. While learning new programming languages, scripting languages and what else I find myself thinking time and again that it is just much easier and much faster to just write the damn code than to fiddle around and writing a proper unit test and applying TDD and BDD. Not only do I have to learn the language I also find myself struggling and learning how to write test for the new languages and technologies I am using.

This makes me wonder if this is a similar experience most people learning TDD and BDD have when they are completely new to these concepts. This probably even worse when you’re actually not an expert in the programming language that you have to use for your work.

I consider myself quite an expert on TDD, but I find myself struggling doing TDD in the new environment that I am working in. I am simply overwhelmed by the vast amount of other things I also need to learn.

I once was an agilist

Agile is hot. Hotter than ever. I have been an agilist for over ten years. Last year I got the privilege to start working with Joshua Kerievsky founder of Industrial Logic.

Last year Joshua found the overarching principle that we all at Industrial Logic believe is the one key element that has not received a lot of the attention, but has always implicitly been build in in most of the agile practices. That key element is safety. In Japanse this word translates to anzen.

Our job has changed from teaching and coaching people agile practices to protecting peopleWe are now anzeneers.

You can find Joshua’s blog about anzeneering here.

The social aspects of Pair Programming

Pair Programming Illuminated describes a number of social aspects that can influence pair programming. I have been pair programming for more than a decade now and have experienced its pros and cons.

Pair programming is often sold as a way to improve code quality. I can assure you this is not always true. Lauri Williams and Robert Kessler have written a book that is one in its kind. They explain how differences in skills of programmers can influence the working atmosphere.

I have experience that not only the working atmosphere is influenced by the differences in skills, but also the code quality and that this can lead to low quality code even when very experienced and skills programmers are pairing up.

I have noticed that pair programming is not for every programmer. I have been studying social psychology for several years now and I believe I have found a confirmation of this thought.

Concepts from social psychology

There are two social psychology jargon concepts I want to introduce here: social facilitation and social loafing.

Social facilitation refers to tendency of an individual to show better performance when in close proximity of other people. The individual will more likely be stimulated to perform a task then when working alone. Even passive presence of other people can be enough to get into action. The task will also be executed with better performance. The opposite effect can also occur when then task is perceived as too difficult. In this case the task is likely to be executed less well than in the individual case.

Social loafing refers to the tendency of an individual to perform less well when he/she is part of a group compared to when working alone. This particularly happens when it is less clear what the individual contribution to the task is for that individual. This can be eliminated by adding elements that clearly identify the individual contribution.

There are two known effects of this: the free-rider-effect and the sucker-effect. The free-rider-effect occurs when an individual will put in less effort, because he believes someone else will probably put in more effort. The sucker-effect goes even one step further and occurs when an individual has the feeling that others in the group are behaving like free-riders. Why on earth would I put in more effort when others don’t?

What does this have to do with pair programming?

My personal perception is that it is better to perform simple programming tasks on your own. Individual team members will be more motivated and are more likely to do a good job when simple programming work is split and divided over the team. I have noticed that the lead time is usually higher when an easy programming job is done by a pair. In such a case pair programming is too expensive. The same job may easily cost twice as much than when performed by an individual.

Complex programming tasks on the other hand can better be performed by a pair. In this case the individual performance is of less importance and the combined performance will be better. The cost for performing a complex task will be lower compared to individual cost. When a complex task is performed by an individual he may experience pressure from the group and this can negatively influence the end result.

From this I conclude that pair programming for easy programming jobs can be better performed by an individual and that complex programming tasks (that may involve design and architecture work) can better be performed by a pair.