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

02 Jun
by mjeaton, posted in Uncategorized   |  11 Comments

A couple weeks ago when I gave my “Lessons Learned” talk at the Cleveland Day of .NET, I took some really good questions and wanted to share one here.  During my talk, someone in the audience described a pretty horrible situation at her job; a project that was behind schedule, overbudget, management won’t allow proper development practices to take place and everything had to be done NOW.  Unfortunately, projects like that seem to be pretty abundant.  Anyway, her question came down to this: what could she, as an individual developer with very little power in the organization, do to improve things.

Honestly, my first response was to tell her to quit because we all have to realize that there’s a point at which we can do nothing except deal with a horrible situation or find a better place to work.  For the woman that asked the question, she had no choice but to stay since she was working on some kind of visa (H1b?).  At the time, I simply told her to change what she could change.  Even the smallest things can have an impact on the larger organization.

The subject came up again at the May 22, 2008 Microsoft Developers of Southwest Michigan meeting.  Josh was talking about “worst practices” in an organization when someone in the audience asked pretty much the same question I had gotten in Cleveland.  After hearing Josh’s response and having time to think about it, here’s what I’d say if asked that same question again:

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. :-)

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

  1. Alan Stevens

    Excellent post, Mike. It reminds me of the serenity prayer. I like to say that companies are like families, they’re all dysfunctional. The trick is to find one that is loving and dysfunctional rather than abusive and dysfunctional.


  2. Dan Hounshell

    The tip “Setup your own CI Server” works. I’ve done it a couple of times now. You set it up on your machine and fellow developers will ask you what you’ve got going on, especially if you use cool sounds for successful and failed builds (think Homer Simpson clips).

    Once they see it some will grok it and they’ll find it easy to join in on the fun by simply adding CC.NET’s CCTray. Finally the straglers will join in because they don’t want to be the only ones not doing it.

    Then you can start adding unit tests, and eventually FXCop, and then …

  3. Gayle

    Great post, Michael!

    This reminds me of a project I was on with one other developer who had maybe 10 years of experience on me. When I asked if we were going to set up source control, he insisted we didn’t need it because there were only 2 of us. Sharing the code base between us on the network wasn’t going to be that hard, so it was “more trouble than it was worth” to bother setting up CVS.

    I backed down feeling like I was way to inexperienced to possibly stand up to someone that much more experienced than I. In a way, I was. Even though I was experienced enough to know it was wrong, I was not yet experienced enough to formulate any concrete examples or counter-points. And I backed down.

    In retrospect, I could have talked to other people I know to help formulate those arguments, or do some online research.

    If I knew what I know now, source control is good even if you’re working on a project by yourself! It’s not just about file sharing within the code base, and how easy or hard that is. It’s about having backups, and having a history of changes. You need it even if it’s just you!

    My advice, never feel like you’re too inexperienced to stand for what’s right. If you’re the “green” one you have to be more careful about spouting off like a know-it-all. But find the right approach and even as a green one you can gain respect of others. Find a mentor who will help you formulate your argument if you need to (preferably someone ON your team so you can stand together, which is one of the points in this post.)


    There’s only one issue I see with setting up your own version control, unit tests or CI, that I have encountered personally with unit tests. I’d like to hear if anyone has more thoughts on this. The problem is with maintaining the unit tests. During the evolution of code, often time the unit tests need to evolve too. If many people are writing code but only one person is updating the unit tests, maintaining the unit tests could become very time consuming, almost a full-time job. I don’t know how you could prevent that from happening unless everyone is pitching in on maintaining the unit tests for the code they’re changing?

  4. Alper

    Is there a step by step guide to setting up your own personal CI server somewhere?

  5. Michael Eaton

    @Alper – Check out my latest post – http://michaeleatonconsulting.com/blog/archive/2008/06/02/follow-up-continuous-integration.aspx

    It has links to a couple of great tutorials for setting up a CI server.

  6. Michael Eaton

    @Gail – Thanks for the feedback.

    Good point about trying to do unit testing on your own when other devs are involved. :-)

    I definitely agree with what you said: “My advice, never feel like you’re too inexperienced to stand for what’s right.”

  7. Matt Blodgett

    From Joel Spolsky: “Getting Things Done When You’re Only a Grunt”


  8. Josh Holmes

    Great post! And one tip – If you’re not an admin and have one favor to call in – shoot for the VMs because once you have a VM that you control, you can do whatever you want including running your own source control in it… :)

  9. Jon

    Awesome post. Glad to see that my organization is doing some of the things you mentioned already. :]

  10. Jane

    Life as a developer is always tough.. Either you get screwed by deadlines or your senior managers.

  11. Outsourced Product Development

    thanks for the great post…