Blog throwback: When the going gets tough or, how to improve your life as a developer

Yes, I’m revisiting old blog content again! This advice from 36-year old me is still relevant, so I want to share it.

Originally published on June 2, 2008, this post was written after being asked the same question at two different events. After struggling to come up with good answers during the events, I decided to put my thoughts down in blog form. I’ll set the context here and just include a portion of the old post (the good stuff).

Note: Some links were removed, and the post was convered to markdown. And seriously, I apologize for the overuse of :-)

And now, the post:

When the going gets tough or, how to improve your life as a developer

Things you can do

First, there’s not much you can do when it comes to the budget, but you can do something about being behind schedule and using proper development practices. You need to set the example.

Be an evangelist.

Find others that share the same values as you within the organization. Sometimes having someone else to share the burden can help. After all, if you find others that know the importance of “doing the right thing”, you won’t be the lone crazy guy in the corner mumbling about his red stapler, right? ;-)

Write unit tests for your own code.

Hell, you don’t even have to check them in. Write them first, write them last, just write them! Doing so will give you confidence that your code is doing what it’s supposed to be doing. When you start cranking out solid fix (or change) after solid fix (or change), other developers (or even management) will start wondering how you’re doing it. ;-) At that point, take them aside and show them the benefits of writing unit tests. Remember, even the smallest changes can have an impact on the larger organization.

Setup your own continuous integration server.

Some people might debate this one, but I honestly believe CI works for a single developer all the way up to large teams (in fact, we discussed this on twitter a few weeks ago). Can’t get the hardware? Use a virtual machine. Locked down and can’t install stuff on your own system? Make friends with someone who can. ;-)

Use source code control.

Is your employer not using source code control? Install a local copy of subversion or git (or even Visual SourceSafe) and use it for your own changes. Locked down and can’t install stuff on your own system? Again, make friends with someone who can. There is absolutely no excuse to not be using some kind of source code control system.

Set milestones for yourself and stick to them, but don’t be a hero.

Keep track of your tasks, your estimates and the actual time it took you to complete the task. Use this information when you develop future estimates.

Don’t let the small things get in your way.

Sometimes it’s better (and easier) to ask for forgiveness than it is to ask for permission. If you want to improve the way things are, you have to be willing to take some risks, BUT (of course there’s a but)…

Dealing with the decision makers

Technically, you don’t even need to tell anyone you’re doing the things I described above, but if you want to make any inroads within the larger organization and make it a better place, you need to learn how to communicate with the people that are making things difficult to begin with.

Ask.

Yep. It never hurts to ask, right? :-) You can start off by asking if you can do some “proof-of-concept” work within your organization. Start simple. Ask if you can start writing unit tests. You might be surprised at the answer you get especially if they (management) don’t have to do much. Write your tests and then ask about standing up a CI server. If you hit some resistance, find out what the problem is and try to work around it.

Get a copy of Carnegie’s “How to Win Friends and Influence People” (and read it).

As cheesy as the title is, it’s actually a pretty good book that gives a *lot of good advice. It’s a really quick and easy read. There is a course that goes along with the book, but I wouldn’t recommend it (bad experience when I tried to sit through the course about 10 years ago).

Learn how to communicate the benefits of TDD, CI, etc. in non-geek terms.

Learn how to communicate the benefits of TDD, CI, etc. in terms the decision makers will understand. Explain how it can help the bottom-line (because that’s what they care about). Explain how it can help you write better software faster.

Be prepared to back up what you’ve been doing.

At some point, someone may (will) challenge you on the things you’re doing. Someone will tell you, “but this is how we’ve always developed software.” Don’t back down. Explain the benefits of what you’re doing. Point them to blogs, articles, screencasts and books on the subjects. Show them the gains you’ve made and how their software has improved.

Be prepared to leave.

If you believe in what you’re doing and are told to stop even after explaining the benefits in non-geek terms, you have a tough choice to make. You can back down, crawl back to your cube and accept that your life at that company will always suck or you can move on to a company that appreciates what writing good software is all about.

In the end

Remember, we work to live, we don’t live to work. Do what you can do to make things better. I believe this applies to every facet of life, not just work. Do what you can do to make things better. Change what you can change, but be willing to stand up for what you believe in.

Special thanks to Sarah for reviewing and providing some great feedback for this post. :-)

---