Stupid things I used to say

Back in the day (roughly 4 years ago) I was doing Windows development. That was all I had done for about a decade of my professional career. If you add in my coding back before I turned pro, it was all I had ever done for about 15-20 years. I knew, more or less, how to write software for a Windows machine, or at the very least, a desktop.  My languages of choice were C++ and C#. Both of those are compiled, static languages.

At the time I was working on an IT team with 3 other developers. They were all web developers doing ColdFusion. I knew next to nothing about ColdFusion (not much less than I know now.)  I was the only Windows developer so a lot of times I was an outsider looking in. I didn’t really get to participate in too many conversations, after all, my medium had built in state that they didn’t get to play with.

However, every once in a while, one of the developers would get desperate and ask me a question, or have me look at their code. Usually this was either really early in the morning or really late in the evening when I was the only other developer at the office and they were stuck.

I knew literally zero JavaScript. I’d heard of JavaScript, but that was about it. I kind of had an idea about what it did, or why you’d use it, but that was about it.  One of the times I looked at someone’s code it wasn’t working because of a simple typo. After that was fixed, the code took off and worked perfectly. I remember going back to my desk and thinking, possibly even muttering to myself, “Why would anyone write using a language that doesn’t even catch simple things like typos until you go hit the page?” The concept was just baffling to me. I knew that compiling my code was no guarantee of accurate development, and that even after compiling I still needed to test it. But it was nice to know that it at least passed the “compile” test.

Fast forward 4 years and I’m neck deep in JavaScript. I spend my entire day for the past 5 months doing nothing but writing JavaScript, and I’m really enjoying it. What I didn’t realize back then was you can’t judge a language purely by how you see it being used.  There are a lot of ways to make sure things like typos don’t mess up your code, even when you’re using a dynamic, and/or interpreted language. For example, we have tools like JSHint which allow you to define rules to verify that your code is written correctly. For example, you can define a rule that states if a variable isn’t defined then it should return an error. In this case, defining a variable and then typoing it when you go to use it, would trigger this error.

But JSHint wasn’t around back when this code was being written. However, other static analysis tools were (according to Wikipedia JSLint, ClosureCompiler were both around back then.)  But you don’t have to rely on a static analysis tool. Writing tests would also detect these issues much faster.  Without writing tests, you wind up spinning up your server, launching your browser and navigating to the page that has the error, and then doing any actions on that page as setup conditions to hit your code. With a test you can write a few lines of code that will execute the exact lines you need to. These tests can then detect errors, like typos, or bad assignments etc.

At my job this week I’ve written quite a bit of JavaScript, but I haven’t worried at all about missing a reference, or a typo or calling a function on a null object. We use a lot of tools to make sure the code is correctly written, and it’s not any slower than a compiler.

My ignorance of other languages and paradigms has made me say some things that looking back now were down right foolish. Sometimes a large group of people are misguided or stupid. However, that doesn’t mean it’s always the case. In my situation, it had more to do with the approach to coding (more like wild west, everything goes) than it was the language. I want to think that I’ve matured since then and would ask more questions when I don’t understand something, like why someone would choose a particular language.

The “Best Tools” Dilemma

A popular phrase in the software industry is “using the best tools for the job.” That sounds really great. It makes software developers seem on-top of things, wise beyond their years. After all, why would you NOT use the best tool for the job? Why would you use the worst tools for the job? That would just be foolish.  To be honest, this is kind of a buzzword phrase that developers use to try and end a discussion or argument. In my almost 15 years of professional development, I have never heard anyone argue with this statement.

What is the Best Tool?

However, there are a couple problems with this statement (and also, with the mentality). First of all, it is incredibly vague. It can be used at the start of a project, when people are discussing how to start a project. Someone will say, “We should use the best tools for the job.” Everyone will nod their head, verbally agree, and have a feeling of relief, because finally, a project is going to be done right.  But what really got established there? Absolutely nothing. There was no discussion of what IS the best tool for the job, only that the best tool will be used. There was also no discussion in what constitutes best tool.

What if the best tool for the job is on a different platform? How likely is it that you’ll convince the people in charge of money that you need to scrap all your servers, because they won’t run the OS that you need for the very best tool? Most companies that’s not very likely.  So we’re willing to put constraints on it, and that’s not bad. It might not make sense for the scope of work to have a team learn a brand new language, especially if it’s only slightly better than the one you’re on.

The problem here isn’t the assumptions or constraints. The problem is that the assumptions and constraints rarely, if ever, get spelled out. In a room with 3 or 4 senior developers, there are 3 or 4 ideas of what the best tool for the job is, and what constraints there are.

How is the Best Tool Determined?

The next issue with the “Best tools for the job” mantra is how are those tools determined? This is different that assumptions and constraints above. Let’s imagine for a minute that everyone is very vocal about the assumptions and constraints. The new project absolutely cannot buy new hardware. It will have to run on the existing servers. Instead, the focus here is on tool evaluation.

The phrase “use the best tool for the job” is a corollary of another common phrase “If all you have is a hammer, every problem is a nail.” Personally, when I hear this phrase, I often think of someone trying to hammer in a screw. In fact, that’s been the follow up example that people use probably 7 out of 10 times. But I’m not sure that’s the best example. When I was in my mid-20s, I played around a little bit with woodworking. It was a fun hobby, but I’m kind of a cheapskate, that meant more often than not, I’d try to make do with what I had. I won’t go into all the details here, because it’s a software blog, not a woodworking blog, but there are saws that all perform the same basic function (cutting a straight line) but have vastly different approaches.  By the time I stopped woodworking, I had a circular saw, table saw and compound miter saw.  Each of these 3 saws could cut a piece of wood square, they could also cut at an angle. But they each had their advantages. The compound saw is sometimes called a chop saw, because it comes down from above. Before I had this, if I had a piece that was a bit too thick for my circular saw I’d have to cut one side, flip it over and cut the other side, and hope that the cuts met in the same spot. It was very frustrating. Then I got a chop saw, and cutting thicker pieces was now a breeze.

How does this relate to software development? It is not enough to say “this should be a single page app.” Even if that’s true, it’s completely insufficient. There are numerous client side MV* frameworks. Should it use Backbone, Angular, Knockout, Ember? What about the back end, should it use Spring, WebAPI, Sinatra?  Just as it’s not enough to say “I need a saw to cut this piece of wood” it’s not enough to say “I need a client side MV* framework.”

This is where I think analysis ends up falling short the majority of the time in software development. We consistently say we should use the best tool for the job, but most people don’t have a structure in place to evaluate the options. In order to have a shot at knowing what the best tool is, developers have to be exposed to a lot of tools. The time to do comparative analysis on what the database technology should be, is not in the midst of the project.  That’s when the decision should be made, but a developer needs to have already done the analysis. What is a use case for using a NoSQL database? What’s the case for an RDMBS? What things can an RDBMs uniquely solve and how do you know if your project has that case? The same can be said for front end technology. Single Page Apps are all the rage these days, all the cool kids are doing them. But what makes a SPA a good approach? Are there times when using a more traditional approach such as Java’s Spring or ASP.Net’s MVC makes more sense?  These are not questions that can be asked and answered when you’re starting a project.  They have to be issues you’ve wrestled with in the past, and now have experiential knowledge to share.

The sad state of affairs is that most people are completely uphold the statement “we should use the best tools for the job.” They simply haven’t used and experimented with other languages and frameworks than the one they are most proficient in. They can’t express their thoughts on why they like Zend Framework better than Bootstrap, or why they don’t like Knockout’s observables. They can tell you that they’ve always used Bootstrap, Angular and WebAPI, with SQL Server as the back end. And to them, that’s the “best tool for the job.”

In the end, the phrase “Best tool for the job” loses almost all value and it quickly devolves into meaning “The tools I’m most familiar with.”

TDD: The Vegetarian at the Party

There’s a joke that asks “How do you find a vegetarian at a dinner party? Don’t worry, they’ll let you know.” This past week I’ve thought about how, to a large extent, that’s true about TDD practitioners as well. If you’re wondering who in your community or office or friends writes code using TDD, you don’t have to worry, they’ll tell you.

This lead me to wonder if there are other parallels between TDD and vegetables and I found a few.  First, eating vegetables is much harder than eating junk. I used to have almost an addiction to fast food, I enjoyed it. I knew it wasn’t good for me, but the ease of hitting a drive through and having something that tasted ok and didn’t cost a lot of money was just too much. Should I have gone home and ate some vegetables instead? Absolutely, but did I? Not as often as I should have.  TDD is a lot like this. It’s so much easier to think “I can just create this form, it’s not that hard” or “I’ve done authentication a ton of times, let me just whip that up real quick.” The problem is, however, just because something is quick and easy doesn’t mean it’s right. Sometimes we have to fight against our nature to do what is right, instead of what is easy.

Secondly, a steady diet of junk food leaves your body in bad shape. Over the past 12-18 months I’ve started taking my health more serious. I’ve exercised more and pushed myself physically. After doing that for a little bit, I realized that I needed to adjust my diet as well. As the saying goes, “You can’t out train your fork.”  (I’ll be honest here, I’m still not on a very good diet, but it is quite a bit better than what it was.) What I found during this time is that it was hard to see changes physically. It was hard to not feel completely miserable after a rough week of training. Why? Because for most of my adult life I hadn’t really been eating that well. I’d been putting junk into my body and now expecting it to perform like a well oiled machine. My friends and teammates who didn’t go through a “junk food phase” have a much easier time maintaining a good weight and diet.  The same is true with our code. If we continue to choose the easy way, the junk food way, of just trying to get stuff done as fast as humanly possible, replacing quality with speed, our projects are going to in a bad spot.

When I first started training, I experienced physical debt. The debt of too much time on the computer, not enough time off my  butt. The debt of too much junk in, not enough good food.  It meant I was sluggish. With our code, we call it “technical debt” but really, that is just a fancy way of saying “We were doing things we shouldn’t have been doing in the first place.”  The library you have that is so fragile that every time you touch it, it breaks, or the the application that is so full of spaghetti code that nobody wants to work on it. Both of those are a direct result of having a steady diet of junk food (bad coding) and not eating enough vegetables (TDD.)

The third way that I saw TDD parallel vegetables is that I’ve yet to find someone who said vegetables are bad for you.  Sure, I’ve met plenty of people who say vegetables taste bad (I have lead that charge myself), but I can’t remember the last person that told me that they were actually bad for you.  So too with TDD. Very few people argue that it’s bad to do TDD. Almost everyone I’ve ever talked to agrees that testing is good, that clean code (a by product of TDD) is good. The problem becomes that there are numerous objections that don’t have to do with TDD being good or bad, but other factors. For example, will it slow us down? Won’t I be writing more code? How do you test GUIs? The list goes on and on. In the end, they answers sound a lot like me objecting to eating more vegetables. They don’t taste good, they take too long to cook, I can’t get them in a drive-thru.  In fact, at one job we went to a new gourmet pizza place and the boss ordered the table a brussel sprouts appetizer. If I remember right, it was bacon and brussel sprouts. I didn’t eat any, and I was asked by the boss’ wife if I was a vegetarian. I thought about replying “Just the opposite, the sprouts are ruining the bacon.”

The problem is, none of my objections really dealt with the root cause. I wasn’t eating healthy. I can’t fill out a life insurance policy with slightly elevated blood pressure and say “But vegetables don’t taste good.”  I can’t not go outside and play with my kids by saying “I really wanted to eat a bunch of Swiss Cake Rolls today.”  By reasons for not eating vegetables weren’t weighty enough. And so too objections to TDD.

So to paraphrase the opening joke, “How do you find a TDD developer at a conference? Don’t worry, they’ll let you know.” TDD is a lot like eating vegetables. It takes some getting used to. It’s not as quick and easy as just slamming some code in the IDE, but in the end, your project and your team will be much happier if you write code doing TDD, than if you constantly hit the drive-thru of software development.

The Power of Doing

Today my beloved Kansas City Chiefs were on the wrong side of the second biggest comeback in NFL playoff history. They were beating Indianapolis 31-10 at half time. The very first pass of the second half was intercepted and Kansas City went on to a 38-10 lead.  From that point on, they were out scored 35-6 and lost 44-45.  It was their chance to break their playoff drought. They haven’t won a playoff game in 20 years (1994 was the last victory.) They set the record for most consecutive NFL playoff losses at 8.  Like I said, they were on the wrong side of an amazing game (more amazing if you’re a Colts fan or really a fan of any team besides the Chiefs.

I’ve been a Chiefs fan my entire life. I’m somewhat used to these feelings. I remember heart wrenching losses when I was growing up. Times where I would be literally upset after a loss. I’d be mad, not want to talk to anyone, angry etc. I remember getting upset thinking that they weren’t really trying very hard.  All of this was around the time I was in middle school.

To be honest, I didn’t have a lot going on for me in middle school. I wasn’t very good at sports, I did good academically, but that wasn’t a big deal. I wasn’t really all that popular. I honestly think I was living through my favorites sports teams, if they were good, then I was good. My identity was in being a fan of the Chiefs.

But tonight I’m experiencing none of that. Am I disappointed? Sure. But I went upstairs and lamented to my wife (who is a Broncos fan, by the way) and then ate supper. I then got on reddit and was cracking jokes about the game.  As I was reading twitter after the fact, I had this exchange with another developer:

This gave me pause to think about why I might be less upset about this than thousands of Chiefs fan across the country today who were cussing, yelling or fighting because of the loss.  One thing that dawned on me is that I’ve got a lot more going on in my life now.

I’m married with 2 kids, I have a job that I really enjoy and I’m learning Brazilian Jiu Jitsu (BJJ).  I think each of these contributes to me having a more balanced view of sports. But one of the main reasons, I think, is because I do things now. I compete in Brazilian Jiu Jitsu, so my actual progress in that sport has more impact on my mood than a group of grown men playing a game.

But this isn’t a blog about BJJ, for that you have to check out my other blog. This is a blog about coding. So how does coding effect my mood and attitude about sports? When I’m coding I’m being productive and creative. I’ve written apps that help track diet and nutrition, help learn Biblical Greek vocabulary, are to-do lists, or track the amount of time I’m training in BJJ. I could sit down right now and write an app that does something. I can create something with my ability to code.  Will any of these apps make me financially independent? I seriously doubt it. But it will improve either my quality of life, or someone’s that I care about. It will make a difference in someone’s life.

If I wanted to, I could do some work for my 9-5 job that has a real impact on real peoples lives. Some of the projects they work on directly effect a persons quality of life.  I have the ability to do all of that right now. And chances are if you’re reading this you can as well. You could sit down and improve your JavaScript, learn functional programming, writing a library to make others lives easier, or writing an app to solve a real problem.

What I’ve found is when I do things, instead of just consuming activities (like watching sports or movies) those other activities are balanced out by my ability to accomplish meaningful tasks.

Two Weeks with a Dynamic Language

When I started my new job, I actually didn’t know what I would be doing. My resume is very .NET focused (and C++ 6+ years ago.) In my interview we didn’t really talk specific technology stack. We talked about technology in general and some specific projects they were working on. However, the projects were exciting enough that my wife commented that I had never been excited to go to a company before. What she meant by that, was that the actual project I was working on was never what primarily stoked my fire.

So when I started 2 weeks ago, I figured the learning curve would be with the types of projects they were doing, and there is definitely something to that. However, the past 2 weeks have thrown me into a new world. The primary language they’re using on the 2 projects I’ve been exposed to is nodejs. I had looked at a little nodejs earlier in the year. I had also played with Ruby in the past when I wrote a Sinatra app. But all of my experience with a truly dynamic language could all fall under the category of “hobby projects.” That is, apart from some jQuery work on a website, everything else had been done over a weekend or two.

So far, it’s been a lot of fun. It’s not that there aren’t some rough points for me, it hasn’t all been unicorns and rainbows, but it’s still been fun.


The first thing I realized is that I depended a lot on my compiler/IDE. I mean A LOT. For programs written in Haskell (another hobby language for me) getting the program to compile typically means that it will run without problem. That’s not true in C# or C++, but that didn’t stop me from relying on it.  For example, I never worried about typos because the compiler would always catch that for me.  Simply hitting F6 let me see that I typed a variable name “mission” one time and “missoin” the next time.

However, reliance on the IDE goes beyond simply compilation.  When I want to see where a method is used, I would either go to the definition or “Find all references.”  That would show me the 3-5 places that a class was used in. I could then click through that code and see how other consumers were using that.

With nodejs, I’m not using Visual Studio or another big IDE, I’m using SublimeText, and there is no way of knowing who is using this method apart from searching. I’ve still been able to search the code and find examples of how an object is being used, but it’s taken me a little bit longer.

I’m not sure if dependence on the compiler & IDE is good, bad or neutral. In some cases, it’s bad, because I’m giving over control from the code to the IDE. In some ways, though, it’s good because it’s one less thing I need to worry about. I can consult the IDE.


The next thing I noticed about working with a dynamic language is the importance of testing. Now, to be completely honest, I think doing TDD is pretty important regardless of static or dynamic language. However, writing some features using a dynamic language the past week has highlighted that need.  In some ways this blends with the previous point. I no longer have an IDE that exists to check that I typed everything correctly or that I’m using things in the right manner. However, if I write a test before I write my code, my test will help me to see problems in my code. For example, a simple test will tell me that I mistyped a variable name because it will give me an error stating that it can’t find my mistyped variable.

Additionally, one reason I love doing TDD is because I love refactoring code. I’ve been quoted as saying I’m happiest coding when I’m deleting code. Doing that with a dynamic language can be a bit scary if you don’t have good tests. How do you know that there is no code depending on what you’re deleting? Perhaps you missed the one line in the search results that shows the dependency. With a compiler I can always delete the code and rebuild it, no errors typically means no problem deleting it.  (NOTE: This is NOT how I would refactor code. My point is simply there were some safety nets in place.)

Finally, testing a dynamic language is a lot more fun (at least for me so far.) I know “fun” is not a quantitative way of judging the language, but I don’t worry about mocks. For example, this past week I was testing something that wanted to check if a model had a list of properties, it had a method like hasAddresses.  Now in C#, I could create a mock that simply returned true, or could create the object then add a bunch of addresses so that when the call was made it would be true. But with node, I simply “overrode” the model I was passing in so that the hasAddresses() function simply returned true.


Nothing super dramatic so far about the differences between dynamic and static language. I’m sure I could find some things I hate about dynamic languages right now, but that’s not the point of this post. Instead, I’ve taken on this challenge not wanting to do things in the static way — that is I don’t want to force my paradigms onto another language, instead, I want to use the idioms of the language that I’m working on.

Do you challenge your assumptions?

On Monday I’ll be starting a new job as a Senior Software Engineer. The title can sound impressive, but in my experience, it’s more of a generic title that if you’re not a new college graduate, you’ll probably have that title. In fact, the only time in the past 6 years that I haven’t been a senior software engineer was when I was the only developer on my team.  So I’m not sure what actually makes someone a Senior software engineer, by that, I mean when someone says they’re a senior software engineer, I cannot say with any reasonably certainty anything about their skill level. I have some thoughts on what being a senior developer should entail. One of them is that a senior software engineer should challenge his/her assumptions on a regular basis.

Sadly, this isn’t a common practice. I’ve worked with  more people than I can remember who do things the same way they’ve always done things. If you ask them why, they probably can’t answer you. Typically, they’ll tell you it was how they were taught 15 years ago when they graduated college, but they won’t have a reason why that company did it that way.

I’m reminded of a story I heard several years ago. A mom was cooking for a special extended family dinner. As she was preparing the roast, her daughter watched her cut off the end of the roast before she put it in the pan. The daughter asked her mom why she did that. Her mom replied, “Well honey, that’s how your grandma taught me to make it.” So the daughter went to the grandma and asked “Grandma, why do you have to cut the end off the roast before cooking it?” To which the grandma replied, “Because my pan was too small to cook an entire roast.”

The granddaughter asked a simple question because she wanted to learn. She wanted to be like her mom and make nice meals. That simple question revealed an unnecessary step. It would have been really easy for her to see her mom cut off a chunk and figure that you had to do it. It also would have been easy for her to not go ask her grandma, figuring “Well, if this is how it’s been done for the past 2 generations, who am I to challenge that?” But that’s not what happened. Also note, she wasn’t questioning her mom in an intimidating way, she wasn’t challenging her. Instead, she was curious about something and wanted to learn more.

That same attribute is something that I think should be required for someone to call himself/herself a Senior software developer.

So what made me think of that today?  As I was thinking about my new job I started doing some reading about project structure. Part of the reason I was doing this is that I know this new job has both Java and .Net developers.  As much as I like to joke about the main difference between Java and C# is where you put the curly brace, I know that’s far from true. But this got me to thinking about how I’ve done things in .Net.

My first .Net solution had 1 single assembly. It was a WinForms app that had forms and code behinds and logic and DAL all shoved into one application. After that application, however, every single .NET app I’ve written has had no less than 3 assemblies. One for the UI, one for the logic and often one for the DAL.  One project I worked on had 40 separate assemblies. The last template I used at work had a default (not including testing assemblies) of at least 4 assemblies.  Often this is done to try and separate concerns. I’ve been guilty of that myself, if I create a separate assembly, it’s easier for me to not allow my domain model to be displayed in my view, for example.  But there are definite trade-offs. Each assembly has to be built, each assembly has to be maintained and versioned (if you’re doing things correctly.)

There are some advantages of having separate assemblies. For example, if you wrote a service that would hand data to your Android, IOS and web clients, then it would make sense that it should be separated. But honestly, that happens FAR less than everyone thinks. In fact, the last time I can remember that happening on a professional level was about 9 years ago. We had a service tool at Caterpillar and we had some architects take an entire 6 month release cycle and refactor out a large portion. It was no longer going to just be used by dealers, it was going to be used in the factories as well. Rather than writing a tool for the factories to use, they refactored and created a separate COM assembly that now both the factory and end user would consume.

That project has shaped my thinking, in both positive and negative ways. I’m more aware of the pain it takes to split out functionality once it’s baked into something. However, realizing that’s only happened once in the past 9 years also lets me know that I don’t need to go to drastic measures to prevent something that in my experience happens about once a decade. So the next time I start a project, I’m going to deliberate over every assembly. The same as I try to do about deliberating over functionality. New project creation will now be a tangible reminder that I need to challenge my assumptions. Just because the last project worked a certain way doesn’t mean this next project will be identical.

The Job Hunt


I’m in a bit of a strange situation, for me at least. For the first time in 14 years, I’m unemployed. Splinterworks, the company I was working for, decided to close its doors.  As I wrote that day, I immediately started going down my “Oh No! List.”  That day I had a meeting with a company that I knew was interested in having me join their team. That evening, I sent off a bunch of emails. I contacted 2 developer friends, more as friends, than really prospecting for jobs. I ended up having good conversations with both of them, and also some good advice from them.

I then went to the gym for my normal Wednesday night class of Brazilian Jiu Jitsu. I actually talked to a class mate who is a recruiter. By the time I talked to him, he’d already heard about the company closing (it’s a small community in Omaha.)

When I got home I reached out to a recruiter. I had worked with her about 2 ago, when I used their agency to help staff our team.  I included a resume with that email.  I also contacted a former coworker who worked at a consulting company, and he had expressed interest in the past about me joining their team.  I included a resume for him to forward on to their HR recruiter.  I then posted a facebook status asking if anyone knew of any places looking for a .NET developer. One friend did, and gave me his email for a resume.  Finally, I reached out to someone that I had helped launch his start-up. He’s still in a fundraising mindset, so I didn’t think there would be a job opportunity there, but I knew he knew people in town.  Finally, I went to be Wednesday night at about 9:30 (normal time for me.)

I woke up to a couple of emails, one was a meeting invite for 9am (I was up by 6am as usual.) The other promised to get in touch with me later in the day with a recruiter friend of his.


My day Thursday looked like this:

8:45am Called by the recruiter from the gym. Set up a meeting at 2:30 pm

9-10:15 am Coffee with a recruiter

10:30am called by another recruiter.

11:30am called by HR recruiter from the consulting firm that the former coworker is at.

12:00pm Lunch with the company that I met with Wednesday

1:30pm phone call from the recruiter friend of the start up guy

2:30pm Met with recruiter and account execs from the gym.

4pm Consulting company emails with a time for an interview

8pm – Went and bought some khakis and a nice shirt for the interviews the next day.  I have lost enough weight since the last time I had to dress business casual that most of my slacks are obviously baggy on me.  I also made sure I found out the expected attire for the interviews. As bad as showing up in jeans to an interview where they expect business casual, showing up in a suit when they expect jeans is almost as bad.

End of day 1 – Interview scheduled with consulting company, the 1:30 phone call lead to my resume being submitted to client. The 2:30pm meeting lead to my resume being sent to 3 more companies. The 9am meeting with the recruiter lead to scheduling a meeting the next day to meet with all their account execs.

9:30pm – Went to bed like normal

Friday (October 11, 2013)

Woke up at 5:30 to get to my morning gym class

8:45am – Call from recruiter to schedule an interview with a client downtown (same recruiter that I talked to at 1:30 the day before)  Less than 20 hours after submitting a resume to them, an interview is scheduled.

9am – First offer arrives via email from the company I met on Wednesday and had lunch on Thursdsay.

10am – Had a meeting with the recruiter and all the account execs at the firm I talked to at 9am the day before.

1pm – Interviewed with consulting company (HR, director of development and 3 different account execs.)

4pm – Went to the gym for “open mat.” While there, received an email that another company wants to do a phone screen on Monday.

Saturday & Sunday

I watched a lot of football, opened some presents (Saturday was my birthday) watched my daughter play volleyball, ate some good food and went to bed just like any other night.

It took me well into the afternoon Saturday to stop checking email. It wasn’t that I was expecting an email, but after the previous 48 hours, I was receiving an email just about every time I checked. The recruiters and companies took the weekend off, but I was still used to getting a ton of email. It was a hectic 48 hours.


I was supposed to have a phone screen with a potential company on Monday. However, Monday morning while I was doing some things around the house, I got a call from the recruiter that said they agreed to bypass the phone screen and do an in-person interview on Wednesday.

Later in the day Monday, a contact from a former coworker reached out and set up an interview at his company. The interview was for 3:30 Wednesday.


Tuesday started bright and early. I had an 8:30 interview at a company not far from the house. I met with the CTO and we mostly just talked. There weren’t a lot of technical questions, but he gave me a good understanding of the history of their company and where they were trying to go. It was a small company of about 30-40 people, primarily doing software development.  It was definitely an interesting place.

After the interview I went into the splinterworks office and did some work on one of the projects. Even though we were free to never come back, we were also able to do a set amount of work to try and wrap up a couple things.

At 1pm, I left and headed downtown for the second interview of the day. I met with a group of 4 people from a large insurance company. Everyone was super nice and as I walked into the conference room, I saw coding questions on the whiteboard. In some ways it reminded me of interviews at Infogroup. It was relaxed and conversational, but they very obviously were interested in making sure someone knew at least some code.  We were supposed to only have 45 minutes, but we ended up talking for about 1 hour 15 minutes.

As I drove home from the interview, I got a call from the consulting company, and she informed me they were extending a contingent offer (contingent on a clean background check, and on my ability to provide 3 people who can talk nice about me as a reference.)

I got home and hung out for a couple hours before I headed to the gym for my jiu-jitsu classes and sparring.  While I was relaxing, watching Netflix, I got a call from the recruiter for the 8:30 interview, he said they wanted me to come back and meet the rest of the team on Thursday. I agreed and told him I was open all day Thursday, so get it set up and I’d be there.

As I got out of the gym at 8:00pm, I had a message from the same recruiter asking me to call him back. I did and the interview from that morning made an offer, they still wanted me to come meet the team, but they wanted to get an offer in front of me.


Wednesday morning I woke up like normal at 5:30, but I did not go to the gym because my sparring class the night before was just too exhausting, so I laid around and watched Netflix until it was time for me to go to my first interview at 10am.

As I was lying around, I heard back from the recruiter for the Tuesday afternoon interview, they wanted me to come back down for a second interview.  At this time, I had 3 offers, and all 3 companies were interesting, and I think good matches for me. The company from Tuesday afternoon, was a bit bigger than I was interested in. I declined the follow up, noting that there was nothing wrong with the people (they really were nice, and I think I could have enjoyed working with them.)

I went to my interview at 10, and it was lead by one of the guys from the gym. I knew this going in. We talked as a group for 2-3 minutes before we dove into the interview. It was probably one of the more thorough interviews I’d been involved in. They talked about philosophy, mindset, and technical questions.  The entire group was very easy to relate to, and I really enjoyed talking with them.

I came home from the interview and ran a couple of errands with my daughter and then relaxed until it was time to head to my 3:30 interview. This was set up from a former coworker who had worked at splinterworks when I started there.  As I lounged around, I got a call from the recruiter from my morning interview and they were going to make an offer.

At this point the Tuesday morning interview and the Wednesday morning interview were my top 2 choices. Both had really strong positives, and nothing negative really jumped out at me. Of course, it’s the real world, and there is no “perfect place to work” but it’s always amazing the little things you can pick up in an interview.

I did my Wednesday interview and it was a really nice company with some more nice people. But to be completely honest, there wasn’t anything there that excited me more than my top 2 choices, so when they emailed me later in the night with their technical screen and follow up questions, I declined (hopefully politely.)

I was finally done interviewing.  It was a relief to know that was the case. I had met with the company that I was going to. I had an offer from them, and I enjoyed both of my options.  In fact, it was honestly the hardest decision I’ve had to make regarding a new job. Always before one job was far and away better than all the rest. That wasn’t the case with this round.  In fact, each of the 4 offers had some very appealing aspects to them.  But I had narrowed it down to two.


I went in at 9am and met with more of the team from the company Tuesday morning. Again we sat around and talked, there weren’t a lot of technical questions. I also was able to meet the owner and one of the VPs and the owner ran me through his vision of the company, where he’s been and what they’re doing now.

As I left the company, I really felt like that was the company to beat. The projects they were working on seemed like interesting problems to solve, and they also seemed to be using innovative ways to solve them.

I went home and told my wife that her job was to talk me into the other company, the company from Wednesday morning. Salary came up, but only for a minute or two, because once all the benefits were applied there was only about a $1000 difference in take home pay for the entire year. And yes, $1000 is a good chunk of change, but at the same time, job excitement could easily trump $1000.

We agreed that the company I had just met with was where I really wanted to be. Again, it wasn’t something that was far-and-away better than everything else. And that’s not a knock on the new company, but rather a statement on the quality of offers and companies I was talking to.


I drove in to splinterworks to have lunch with the guys at least one more time. I used that call to notify the 3 companies that I wasn’t going to as well as the one company that I was.  As much as it is business, it was still hard to turn down the other 3 companies. They were each appealing for different reasons. Each of their offers were tempting. I literally pictured myself working at each job. In some small way, I was emotionally invested in each of them just from the people I met. But in the end, I knew the job I wanted to take most. And to the credit of every HR person, or recruiter I talked to, they were all very professional and polite as we discussed why I wasn’t coming to their company.

Things I Learned

Networking actually is important. When I first graduated college, I looked at recruiters more as parasites. Organisms that survived only by leaching off of the people they place. But over the last few years my attitude changed. Some of that was working with good recruiters when I was at Infogroup. Some of it was seeing that recruiters can provide a valuable service in that they can spend their time talking you up to potential clients as opposed to you trying to do that. And honestly, some of it was seeing that they are just different personalities. I spent the last 7 years at a higher state of stress and excitement because my days were filled with phone calls, and trips across town, and emails back and forth about possible opportunities. I tried to optimize my time in the car by talking to a recruiter or friend as I drove from interview to interview. That WORE ME OUT! And yet, that’s what most recruiters do EVERYDAY. For most, I assume, it’s something they enjoy. They like the business of it all, they like the interaction. I don’t. But that doesn’t mean they’re wrong and I’m right.

Additionally, just from being somewhat active in the community I was able to secure a couple of endorsements from people I met. I’m FAR from active. I don’t attend every users group meeting (in fact, I miss more than I attend.)  That coupled with talking about code outside of the immediate project I’m doing lead to getting another recommendation. In fact, at the consulting company, I was told that the two consultants that they had that recommended me carried a lot of weight.  I didn’t befriend either of these men in hopes that one day I would be able to use them as a recommendation. Instead, I just talked to them and related to them as fellow developers. In the end, it opened up some opportunities. And honestly, if the situation was reversed and they needed recommendation, I would have done the same for them.

For the fourth job in a row now, the work I have done outside of my 9-5 job has played a drastic role in helping me land a new job. At Conductix, I had done .NET development as a side project at Caterpillar to help me with some internal tools. At Infogroup, I had written an MVC application for my sister in my own time, that project helped meet many of the technical requirements they were looking for. At splinterworks, I was able to send them to a Github repo of a project I did in Ruby, as well as a blog post I wrote about the process. It wasn’t essential to the job, in fact I never did Ruby at splinterworks, but I know that demonstrating the fact that I was interested in more than just what I worked on was an important part. Finally, with this new job (and really in almost every interview I did) the work I’ve done with AngularJS, Backbone and KnockoutJS all came up as things that I do in my spare time. In both of the companies that made my final list, we talked for a few minutes about these technologies. If I had relied only on the work I had from 9-5, I would not have had the knowledge to talk about those technologies.

Put simply, the work I did outside of work helped separate me from several other developers.

Finally, I was very pleased with the recruiters I worked with. I ended up using 3 separate recruiting companies. I also had interviews with 3 separate companies that I got by my personal network. When I told each recruiter that I was done with a job opportunity (whether that was before a follow up interview, or after an offer) every single one agreed not to push the issue, and do what I wanted. None of the recruiters sent my resume to places that I didn’t authorize, and they were all up front about any company that I might be interested in, if they thought the company couldn’t match my salary expectations.


I included some of the innocuous things like the time I woke up or went to bed, the times I went to the gym to show that I was able to approach my life roughly the same as the days I had a job to get to.

I held off publishing this post until the whole thing was over. I think I did a good job of anonymizing my activity and who I was talking to, but I didn’t want to put this out and risk a company seeing it and thinking it affected whether they were in the running.

The entire process was INCREDIBLY exhausting. I kicked the process off at about 2pm on Wednesday, October 9th. I had the last conversation with a recruiter at about 2pm on Thursday, October 17th, or 8 days later. In that time I had 6 interviews and 4 offers. I met with dozens of people from recruiters, developers, managers, account execs etc. (I counted 35 different people in my head, and I’m sure I’m forgetting someone.)

Finally, I’m incredibly grateful and thankful for the experiences I’ve had in Omaha in the past several years. Each of them, at the time, seemed innocuous enough. I spoke at HDC on OpenRasta and ReSTful services in 2011, nothing directly came out of that speaking engagement, but it shaped me and put me in touch with people that ended up recommending me places this time around. I’ve been fortunate enough to get to play with some pretty cool things at work as well, and that has helped “keep the saw sharp.” When splinterworks decided to close their doors, there was not a big jump needed to get me ready to be on the open market, and I’m very thankful that’s the case.

Putting My Money Where My Mouth Is

I’ve written a lot on this blog about the software development career. I’ve had blogs about the 6 traits of a software developer, as well as about how every developer has 2 full time jobs. The first is your day job, the second is to stay on top of technology.  Today the time has come for me to put my money where my blog is, or as they say in the buzzwords of startups, it’s time for me to “dog food it.”

Today the company I work for notified us that they will be closing their doors. All work has stopped and so it’s time for each of us to move on.  As I left the meeting, I was not in a panic. This is in part to knowing that I have the next 2 paychecks covered, as well as some money in savings. Obviously, I’d prefer to not dip into savings, but that’s what it’s there for. Additionally, now seems to be a good time to be looking for a job in Omaha, the market seems to have more jobs than developers.

So why is it now time to “eat my own dog food”? Or to put my money where my mouth is? Because for a  while now, I’ve had an idea of an “Oh No! list.” Basically this list was largely in my mind, and was a group of people that I would contact should the unthinkable happen. Some people on the list are recruiters, some are other developers, some are just people that always seem to know someone.  So when I walked out of my meeting today, I called the top person on my list, asked if I could swing by his office for a few minutes, he agreed. So before I ever made it home, I had already started the ball rolling.

When I got home, I reached out to a couple more developers, had a quick Skype chat with one and a phone call with another one.  Then later in the night, I touched base with a 3rd developer, and two recruiters who have stayed in touch. By 9pm tonight, I had talked to 3 people in the development industry in Omaha, and sent resumes to 3 other people.

It’s not a fun process to go through, by any stretch of the imagination. However, having a mental check list of what I needed to do has already aided me greatly.  I’ll let you know how it works out.

Why we’re not using Knockoutjs

This past week I’ve been working on a semi-new project. It’s something I’ve worked on before. In fact, the project itself is the first thing I ever did in MVC. I never completed that version, and instead, a few years later started used it to learn Bootstrap and MongoDB. But I didn’t finish that version either. It’s a bit of a large project and I didn’t have the time to do it in my spare time.  So I pitched it as a company project a month or two ago and we decided to take it on.

It’s nothing super spectacular, but it will involve entering some data in one of several possible categories.Think of an inventory system, you might have trucks, cars, motorcycles, buses, etc. They’re all automobiles,  but each have different sets of specs, even if they do have some commonality.

Last week I started working on the main page and I saw the chance to use a client side library. I’d played with Backbone before and Angular, and thought I might use this opportunity to work on some Knockout. I got the first page up and running relatively quick. As you stepped through various customers, their inventory updated on the screen near instantaneously. It was a bit more work that just creating a Razor view, but I felt like it worked nicer and it was faster,so I ran with it.

Today I got most of what I wanted wrapped up, and so I moved on from the overall summary page to a detail page. And that seemed to work easily enough, and then I clicked the back button to get back to the summary page and try a different item, and that’s when it dawned on me. All of the work I had been doing was on a single page and view model. I didn’t track state at all, so clicking back just took me to an empty page. I realized that wasn’t going to work for our case.

I went over to the knockout page and started going through their Single Page Application (SPA) tutorial and it all made sense. I downloaded sammy.js to handle my page hashes and I started looking at getting all that wired up.

At that time I took a step back and realized that this might not be the best technology for us to use. I had a quick talk with another of our developers and we agreed that we should probably switch back to using normal server-rendered pages.

To make a long story short, the reasons actually had nothing to do with Knockout. There was not a technological reason to abandon it, by that I mean we didn’t find something that Knockout couldn’t handle. Instead, what we realized was that to do an SPA correctly, there is a fair amount of architecture involved. Planning out your templates and views. That’s true on server side as well, but we’re already used to doing it on the server side, it’s a bit more “second nature for us.”

The next reason was that we need to get this up and running somewhat quickly. It’s not super time sensitive, but the quicker we can get a working version up, the quicker we can get it before potential users to get their feedback. It’s quicker for us to do that with server side rendering.

The third reason for abandoning it, is that while Knockout isn’t really complex, it is complex enough for us as a team (since I’m the only one to use it at all, and even then was a super simple proof of concept.) So while I’m the only working on this right now, it very well could be that next week or in 2 months one of the other developers would come over to help out. If that happens it would probably take some time to get other people up to speed. We plan on doing this through code reviews over the next couple weeks, but this didn’t seem like the project for people to learn on.

Again, there’s not really anything wrong with Knockout, and this project doesn’t seem too complex that Knockout (or Angular or anything else) couldn’t work. But it doesn’t seem like the best project to initiate our quest into client side libraries.

I’m a bit disappointed, I really wanted to explore this technology. But sometimes being a professional developer means recognizing that you’ve started down the wrong path, and backing out before you’re in too deep.

So tomorrow & Friday I’ll be ripping out the code I spent the last 2+ days doing. It might seem like a waste of 3-4 days, but there are lessons that have been learned, and I think it will save us time in the long run.

No More Ninjas Falling from the Ceiling

Several years ago I was down in Texas for my sister’s wedding. We were in town a few days early to help with the set up and all that jazz. One of my sister’s bridesmaids was anxious, to say the least. She was coming up with all sorts of problems that could happen during the wedding ceremony or reception. There was a seemingly endless stream of “What happens if the flowers are wrong?” or “What happens if the ring bearer trips?” or “What happens if the DJ plays the wrong song?” Until finally my mom, hearing more than enough of these questions, turned to her and said “What if, in the middle of the ceremony, ninjas fall from the ceiling and start attacking the wedding party?” (In case you’re wondering, I got my sarcasm from my mom.)  That pretty much ended all the questions coming from the bridesmaid.

I had largely forgotten about that event. But recently I was thinking about the different project management strategies I’ve been a part of over the past 13 years. At one point in my career, we had a rather formalized process that went like this:

  • Requirements signed off by the (internal) customer
  • Developer writes a specification document based on the requirements
  • Developer has a spec review with the senior developers on the team.
  • Developer writes a design document based on the specs.
  • Developer has a design review with the senior developers on the team.
  • Developer writes code
  • Developer has code review with senior developers on the team.
  • Feature is included in the next release (happened every 6 months.)

With this path of development, design was emphasized heavily up front. If you didn’t get the feature right, or if key aspects were missed, the customers had to wait at least 6 months to get an up-to-date version.  This meant that a lot of our design involved ninjas falling from the ceiling. Specifications would involve use cases that may not ever happen. We had to anticipate every single user interaction, every single operating system that it might be installed on (this was a Windows application.)  So we’d have use cases in our specification document like “User changes resolution from 1024 x 768 to 800 x 600″ because we didn’t know what resolutions our users had — only what was possible for them to have.

However, the longer I’ve been working as a developer, the more iterative the development process has come. The thought of not releasing an update for the next 6 months seems like a long time. While working on Salesgenie, we released every 3 weeks (with a few exceptions caused by natural disasters.) While working on QuickQuote, I would often release multiple times in a week, basically whenever a serious bug was fixed or a new feature released.  For the internal projects I’ve been working on the past month, we’ve released multiple times A DAY thanks to our build server.

What iterative development has really helped with is that I don’t have to come up with “Ninjas Falling from the Ceiling” use cases any more. Why? Because even if we didn’t account for a use case, we’ll be releasing shortly and we can just include it in that next release.

This makes development a lot more fun for me. Now instead of sitting in loooong design meetings, spec’ing out every last detail, I can sit in shorter meetings and start working on the parts of the application that are essential. Instead of dealing with every possibility, I can deal with probabilities. For example, if I have the user create a username & password, what is the probability that they’ll use the same password they use everywhere else? Highly probable, I should probably look at using some sort of OAuth provider instead.  How probable is it that someone will try to quote a 17 mile track of conductor bar? Not likely.

I shouldn’t write my software in a way that deliberately breaks if someone tries to quote 17 miles. But at the same time, I should be free to optimize the program in a way that quoting 17 miles of track isn’t efficient.

In the end, iterative development keeps the ninjas where they belong, hiding in the ceiling, instead of dropping down and attacking the party.