Content is not good enough

I have been fortunate enough to have a job that I was truly excited to go to every day.  I loved what I was doing and who I was working with.  Before that I was content at many of my jobs, but wasn’t truly happy/truly in love with the job.  Since then I have been more picky about where I work.

This is going to sound hokey, but just bare with me.  When I work somewhere that I really enjoy and do something I really enjoy, I get energy back from it.  I don’t dread going to work and rarely come home feeling drained.



Since we spend so much of our lives at work, why wouldn’t you find a place that you are truly happy?

I think I have said this before, but when you are interviewing at a company, it is not just an opportunity for them to learn about you, but an opportunity for you to learn about them.  See if you can talk to some of your potential colleagues.  Ask them what they like about the company and what they would change.  This can give you some good insight into whether you would be happy.

Take some time and look at you current job and previous jobs.  What worked well at each place?  What didn’t work well?  What made your life easier?  What were your biggest pain points?  Now you have a good feel of what your ideal job would look like.  Now when you are looking for a new position, you can use this information to help you decide whether it is right for you.  Good luck!



Should I apply?

Recently, I have not been very happy at work, so I was keeping my eye out for another position that looked interesting.  I hadn’t applied to any of the listings I saw simply because they hadn’t piqued my interest quite enough.

Now, I am laid off and I am applying to some of those positions I passed on previously.  As I have been looking at listings, I ask myself if I really want to apply to this position.

Sometimes, after a little research on the company it is obvious that I do not want to apply ( is your friend, they have employee review of the company).  But, often I am still left wondering whether I would be happy there…should I apply, or just walk away now?

While being laid off may be influencing my thought process, I have realized that the best way to determine if a place is going to be right for me is to actually apply and interview there.

Nothing can replace the experience of visiting a workplace and talking to the people who work there.  You get a chance to see the workspace.  I have visited workplaces and decided I was not interested after visiting.  Remember, this is where you are going to be spending 8 hours a day.

The interview is a chance to get a feel for some of the people you will be working with.  Your colleagues can make or break a job.  Pay attention to who interviews you and what sorts of questions they ask.  You can get a good feel for their culture.

Remember, even if the company offers you a job, you are not required to say yes.  It is your decision whether this is the right position for you.  The interview process is not just a chance for the company to find out if you are a fit for them, but also an opportunity for you to determine if they are a fit for you.

Code Coverage

We all want to achieve 100% code coverage.  If we have 100% of our code executed in tests, we can feel confident that we are testing our code well. Right?

Not so fast!

We wanted to share some examples of tests that, while they may boost your code coverage, aren’t testing much.  Below are some examples we have actually seen (code has been changed to protect the guilty).

Trust, but verify

This is a code snippet using Mockito.

public void testSomething() {

For those of you unfamiliar with what verify does in Mockito…it will pass if the method in question was called.  That’s right…this test is verifying that we called the “doStuff” method…which we did in the previous line.

Unfortunately for us, our code coverage tools will look at this and see that we executed lines inside the doStuff method and count them as covered, even though we didn’t actually test anything!

Preparation is key

public void testStuff() {
  .... lots more setup ....



That’s right…they took the time to do a whole bunch of setup and even called the method in test…but forgot to actually test anything!  There are no asserts or verifies.  Again, our helpful code coverage will show that lines inside of methodInTest were covered since they were executed in a test, even though we didn’t test a single thing.

Green means Go

public void testTest() {
  ... improper setup ...
  ... call method ...
  ... assert the wrong thing ...

Sometimes we make mistakes in our setup code and when we run the test, it fails, even though we are sure that the code is working correctly.  That leaves us with two options.  1) Figure out why our test is failing…step through, debug, print stuff out, etc.  See if it is a bug in the production code that we hadn’t noticed or if there is an issue with our test.  OR 2) Change the expected values in our test.

Option 2 is obviously the easier answer.  Yes, we’ve seen this.  No, this is not correct.  Tests are supposed to give you confidence that your code is working correctly.  It can also act as a sort of documentation for future developers.  Do you want future coders to look at the test and think that what you are testing is expected behavior?

What have we learned?

Code coverage is not actually telling the whole story.  As we have seen above, if you have poorly written tests lines of code covered don’t mean anything.  Anyone can be clever and find ways to execute more code in their tests…the smart programmer figures out how to actually test the code.

Please be vigilant in writing your tests and actually ensuring that your code is doing what you expect it to.  When doing code reviews, if you see any blunders like we show above, or other not so great tests, please help the other person write better tests.  You, your team and your code will be better off for it.

photo credit: <a href=”″>Facepalm</a&gt; via <a href=””>photopin</a&gt; <a href=””>(license)</a&gt;


Starting an agile project with a new team

At the first job where we were trying to do agile, none of us knew a lot about what that meant.  We didn’t break down our work into stories, therefor we didn’t estimate any stories.  We simply divided up work that needed to be done among the pairs and did pair programming and test driven development.

Then, the next job where I was doing agile, we didn’t estimate our stories using story points.  We estimated in hours, kind of.  We used a set of hours that we could pick from, it was either 1,2,4,8,16,32 or 64 hours.  This allowed us to stop fooling ourselves that we could be very accurate in estimating a task that was going to take longer than a couple of hours.  In order to determine how much a pair could accomplish in a sprint (which were one week long), we simply found 32 hours worth of work and BINGO.

In my current job, I am trying to bring more agile processes to bear.  I am in charge of a new project at work and have decided to run it in a completely agile manner.  I am the scrum master (which I have only kind of done before, mostly for myself).  The project has only one developer resource.  We have access to a QA resource as well as our user experience designer, though neither of them have any dedicated cards.

The developer on this project is a contractor who is not familiar with the code base, nor with the system that we will be integrating with.  We have not worked with him before.

Our first task was to introduce him to the project and then estimate the cards that we had created.  Rather than going with hours, I decided I wanted to use story points.  Our scale is 1,2,4,8.  Anything that is sized over an 8 needs to be broken down.

After a long estimation session, we needed to determine what work would go into our first 2 week sprint.  In an existing team this is fairly easy…just look at the average velocity and put that many points in the sprint, adjusting for any absences.  But, what do you do when you have a new team and have no idea what the velocity is?

You guess.

That’s right.  Look at the cards that you want to play and start adding things to the sprint until the team says stop.  Then, make sure your backlog is groomed well so if the team guesses wrong and can pull more work in than they thought, they can pull from the top of the backlog.

If the team doesn’t get all of the work done that they committed to in this first sprint, don’t hold it against them.  The first couple of sprints are learning sprints.  The team is learning the code base.  The team is learning the process.  The team is learning what their velocity is.

After a few sprints you can take the average velocity and start using that to plan out the work.  If your team is consistent with their estimation, and is fairly consistent in their velocity, you should be able to fairly accurately estimate when different features will be complete.