War and Peace

If you took any time slice from my career, I could easily tell you if that time period was war time or peace time. Based on the projects, the management, my co-workers, I was either stressing out (war time) or bored out of my mind (peace time).

What I want to do with this post is contrast war and peace in a software creation environment.

War Time

It’s easy to know when you’re at war. There is a constant feeling of subtle panic every time you sit down. You leave the office drained, tired and quite often angry.

Here are some specific symptoms I’ve noticed from my career:

1. You have several outstanding production issues that are non-trivial.
2. You have abandoned quality in favor of quantity. (No unit tests, code review, etc.)
3. Stakeholders are running amok. You are strongly encouraged to say “yes” to everyone.
4. You are missing management to help shield you. You have to make managerial decisions, sit in meetings and develop politics.
5. You are working extra hours to keep up.

There are of course more symptoms. Let’s look at peace time to help emphasize the divide between the two:

Peace Time

1. You have time to read articles about your industry – without feeling guilty.
2. You have time to write unit tests.
3. You have time to re-factor code per (2).
4. You have time to think about names for objects, classes, etc.
5. You have periods of focus that go longer than one hour. It’s normal to have four interrupted hours of time.

Conclusion

Now the point of this post is not to argue that developers should try to get to peace time. The point is not to decry the horrors of war. That is obvious.

The point is that as an organization, you need to know what state you’re in.

If the development team has bloodshot eyes and the stakeholders are playing Nerf basketball, then there is a major disconnect. One team thinks it’s peace time and the other is at war.

This is bad because expectations end up missing each other by wide margins. A peace time customer will ask for 100 features for a system. If he knew the development team was at war, he wouldn’t ask for 100 features. When you’re at war, compromises and sacrifices have to be made.

For any job I’m finding it’s important to know which state I’m in and then communicate that to others. It’s only fair that the stakeholders know that I consider us to be at war. Hopefully it helps them to adjust their expectations.

War and Peace

SQL Humility

At almost every job interview I’ve ever done I’ve been asked some variation of this question:

“On a scale of 1-10, how good are you with SQL?”

I answer the same each time. I try to give the interviewer a number that reflects my knowledge of the language and my ability to answer trivia, and another number which represents my confidence with the language. The second number is what I try to emphasize.

“I’m very comfortable and confident in SQL – even if I don’t know every command/approach/technique/piece of trivia.”

I don’t know why, but writing SQL had at some point in my career become a point of pride. I thought I was a stud. At my most recent job I’ve realized I have a lot to learn.

Syntax I’ve recently come across that I had previously never seen:

1. order by 1 desc (Huh? I can specify the column number? Seriously?)
2. full join (Full join? What is that? Why can’t I just use “join”?)
3. escape ‘|’ (I can escape characters in a where statement? Hmmmmmmm.)
4. select convert(varchar, getdate(), 107) (Wait, wait, wait. I can format a date as a string with different formats?!)

The list goes on, but all the point is made. I have a lot to learn.

As a result I’ve been reading lots of articles from http://use-the-index-luke.com/, which makes me feel smart and strengthens my SQL skills.

SQL Humility

Azure+TeamCity, Build Server Fun!

At work we have a strong need for a build server with pseudo continuous integration and the task was passed to me to get something up and running. Many years ago at a different job I cobbled together Cruise Control and some NANT scripts and was able to get something like a build server going. This time around I knew I could do better and on the recommendation of a co-worker I went with TeamCity.

TeamCity is awesome! Poor CruiseControl.Net looks awfully out dated compared to TeamCity.

Some quick things I love about TeamCity:

1. Lots of integrations out of the box. It can talk to TFS, MSTest, MSBuild, Powershell, etc.
2. It just works out the box. Web portal fired up fine, the windows service installed well, etc.
3. There is a ton of support online for it. CruiseControl has some of this, but not as much as TeamCity.

It was a bit harder to get TeamCity to publish projects to Azure, but with some help of a blog or two online, I got it working.

Our process now:

1. Check out latest solution from TFS.
2. Update Nuget packages.
3. Build the entire solution.
4. Run unit tests.
5. Publish to Azure (the staging instance just to be safe).
6. Flush Redis.
7. Run integration tests.
8. Email the team that a build is successful.

It’s been a few days of work getting it all dialed, but it feels good to add some automation to our process. It was getting tiresome to deploy manually and run tests a few times a day.

Azure+TeamCity, Build Server Fun!

Battling Burnout

In many of my software jobs I’ve had to battle burnout. Things usually follow this progression:

1. Honeymoon period at job. Tons of time to do quality work up to my own standards.
2. I deliver on a few projects/features. I build a reputation.
3. The dam bursts and I drown in new projects/features.
4. I do my best to keep up and come up with solutions. I want to make people happy!
5. I burn out and quit the job.

Looking back on my career I think I had a huge part in not preventing my own burnout. I’ve tended to blame the jobs, the bosses, the bad management, but in reality I had the responsibility of keeping myself healthy and engaged.

Some things I now try to do to avoid burnout:

1. Keep eating healthy. This tends to go out the window when working too hard.
2. Keep exercising. Again, because I get so tired at work, this tends to suffer in times of burnout.
3. Push back on things that are not necessary. Saying “no” to meetings, projects, features.
4. Allowing things to fail. It’s ok to miss a deadline – usually it’s due to bad management/planning and not from me dropping the ball.
5. Reading articles, writing code not related to work. This is fun for me and it always goes out the window during stressful times at work.

We’ll see if I can learn from past mistakes and keep myself from exploding in flames. I’ve done it twice in the past and am keen to not do it again.

Battling Burnout

Oops x1.6 million

Recently I accidentally sent out 1.6 million emails to customers. I was doing local development that integrated with a third party and didn’t realize my iterative testing was actually firing off emails in production.

The vendor doesn’t have a staging/sandbox environment so extra care is always needed when doing development.

It was a pretty embarrassing situation and I tried to take a few things away from it:

1. If you are integrating with a vendor and they only have production, find a way to mock their environment.
2. Always create safe data structures for testing. Create duplicates with the third party that mimic real data structures, then swap to live objects when going live.
3. Be careful! There should be a weighty, important feeling to doing work with integration. If you’re feeling very casual and loose, then something is wrong.
4. Put in safe guards. In this case I made a whitelist of objects that could be operated on remotely. I also put in place several business rules that would prevent mistakes in the future.

Big mistakes mean opportunities to learn big.

Oops x1.6 million