My name is Angelo Rodrigues and I'm a programmer. I am currently in Seattle working on a Start-up and will be documenting my findings - hopefully it helps.Many hats
Life at a start-up is not easy. There’s a hundred things to do and not enough people to do them all. And of course, you’re facing ridiculous deadlines because you need to move faster than everyone else. It’s the perfect storm for your developers to get burnt out, but it’s also what attracts them in the first place. Because of the tight deadlines and lack of people, everyone is forced to do a little more than their actual job title. That programmer also does graphic design and SEO. That graphic designer is great at talking to potential clients. That front end developer is also the go to guy when your server goes down.
Working in a start-up is about having a closet full of hats. And you have to carry them with you every day, because you never know what will happen.
The great thing about it this is that you become very knowledgable about a lot of things in a very short time. The key thing to take away is – don’t limit yourself by thinking your career title is what you are. Just because you’re a programmer, don’t JUST focus on programming related tasks. Step outside your comfort zone and explore a little – you never know what you’ll find.
Test Driven Feature Development
Traditional Software Development Life Cycle[/caption]TDD has its perks Test Driven Development is a simple idea, but one that had a huge impact on how we build software. The traditional method of software building was long-term iterative.
Notice that it is truly cyclical in nature. The parts that we are most concerned with are “Design”, “Implementation” and “Testing”. We move quite clearly between each of these phases, never looking back. Obviously this type of system only works in truly large companies – when you can afford to have separate departments in each phase. In smaller companies we squish the cycle. Each phase slightly overlaps with the others, allowing for some back-and-forth during the beginning and end of each phase.
This has the great effect of making your software better.
By forcing this overlap you allow your development team to spend time with the “Design” and “Testing” phases to ensure that the “Implementation” goes smoothly. After all, the quality of your implementation directly effects the length of your testing. The closer the two teams work, the less time you spend waiting and the more time you can spend developing your awesome product.
Squishing the SDLC has the amazing side-effect of making you more productive as a company.
So why not squish it further?
The folks over at Pivotal Labs pioneered a technique that is now known everywhere as Test Driven Development. What this does is actually further compress the “Design”, “Implementation” and “Testing” phases of the SDLC into two phases. First, they altered how the “Design” phase works. During the design phase you actually write some code-based “tests”. These tests are essentially to test various “units” of work. So for example, you might decide that your application requires the user to enter an email. You would then write some tests go through various possible inputs for the field – both valid and invalid. The tests could simply be running a valid/invalid email address through a validateEmail method. Obviously your test case will NOT pass, since you haven’t written any code that actually does the validation.
Your next step is to simply sit down and write this implementation. You’ll know that what you did worked because you periodically re-run your tests. Once all your test-cases pass you’ll know that the feature you wrote works and you can move on. The idea is that from now on ANY time new code is added the whole test suite is re-run. Any changes to validateEmail that break it will instantly be caught during the implementation process and you can fix it right away.
Test Driven Development is proven to work. It’s not the only way of doing things, but it is definitely a good one.
However, if it works so well, why not apply TDD to other facets of your business? Specifically, why not apply Test Driven Development when designing your feature list?
Think of it as Test Driven Feature Development.
The idea is quite simple. In anything larger than a start-up, what happens next with the product isn’t up to a lone developer. Instead that task normally falls to some kind of manager, who goes through a bunch of meetings before coming back to their development team to share their findings. They often come back with features like “upload a file”, or “make it faster”. To a non-technical person that’s just ONE task – and they’re flabbergasted when a developer turns around and says “oh that will take a few weeks”.
See there’s a clear disconnect. The developer knows that each “task” that management hands down is really a collection of 4 or 5 mini tasks that need to be done. And each of those may comprise of any number of little tweaks, fixes and additions to the existing code-base. And each of those little fixes may cause any number of problems to existing code. And of course, you need a buffer because things always take longer than expected.
However, with Test Driven Feature Development, you spell out the sub-tasks whenever you hear about a new feature – in writing. By pushing it externally you not only invite discussion, but you allow your team to approach decisions uniquely. In addition, you now have a list of tasks that a developer needs to get done. If they don’t have the time or skillset to perform a particular piece of the puzzle, someone who DOES have that can easily see what’s on their plate and offer to jump in.
In addition, as a manager you know exactly what is needed to integrate a particular feature, and you know exactly what your team will be working on. Your development team also has a checklist of things that they can work against – and when all those sub-tasks are done and working properly (using TDD right?), your feature is done.
Test Driven Development applied to Feature design allows your developers to externalize what they already do when you give them a new “Feature”, but in a way that fosters better work and understanding from all those involved.
How to avoid Programmer Burnout
Being a programmer isn’t for everyone. You have to really love creating and learning – because you’ll be doing a lot of both as long as you’re a programmer. This is really easy at first. A new website, a blog, a little custom CMS. These are all relatively quick goals. Each step of the way you’ll have something to show for it. The problem is that as you become better the problems that you’ll be solving start getting bigger – which in turn requires more complicated solutions. This leads to more abstraction and actual architectural planning. Which is a good thing.
And a bad: You’ll find that you start doing more work without any tangible return.
Gone are the days where you can sit down, wire up a file upload system and then having something to show for it. Now you’ll spend days just moving little virtual pieces around and researching new tech. You’ll spend a lot of time and at the end of the day you’ll have nothing actually created that you can show someone. Short term you can work through it, but when it becomes a bigger part of your day, it gets harder. I believe that THIS is a major cause of burnout for developers. You work all day, for months and then at the end of it you have nothing to show for it. You pour all your time and energy into making something that no one will ever see or truly appreciate.
Being a programmer isn’t for everyone.
But there is a way to fix it. Getting burnt out is actually a fear of mine – but I’ve been lucky enough to have a solution going for me that not only works but that has become a habit for me. You need to have a hobby. But not just any hobby – your hobby needs to have some outcome that is quickly achievable. You need to be able to spend an hour or two and be able to say “look what I did”. You need to be proud of that outcome and be able to share it with other people in that community. And then have them be happy for it.
My immediate gratification is simply to play FPS games online. Short 20 minute intervals of games and simply being on the winning team (50% base chance in team death matches) is enough of a gratification. But it provides ample room for additional gratification. Keep in mind, games are being designed to GIVE you gratification and they’re designed to stream out the gratification fast enough that you feel like you accomplished something, but have enough of them that you keep coming back to it. There’s a whole theory around this called Gamification. You’ve no doubt stumbled across this idea before and either dismissed it as un-applicable or just ignored it. But the truth is, the core ideas behind gamification are based on psychological ideas that require a whole post of their own. But suffice it to say, that for the majority of people, gamification works.
Gaming isn’t the only option, it’s just the one that I feel is most optimized for gratification for the least amount of input. There are other things that people do as well – it’s all about personal preference. Gardening, reading, watching tv shows, playing an instrument. The key is that you should be able to show some kind of progress very quickly. There is a balance however, you have to have SOME input for the gratification – free gratification doesn’t work for extended periods of time. You have to feel like you’ve don’t something deserving of gratification.
So take take some time to find that hobby. Find that thing that works for you and make sure you always enjoy it. The might it stops being fun, it’s time for something new. Being a programmer isn’t a career choice, it’s a whole lifestyle – you need to make sure that you always have what you need to support it.