When you’re juggling four active projects, talking with clients and debugging thousand-line classes, being a developer can be stressful at times. Luckily, by planning a little here and there and working on your process, things can be much more manageable. A good developer is always perfecting his/her habits and skills. Here are a few things we’ve learned along the way.
1. Use a Version Control System (SVN, CVS, Git, et al.)
Many years ago, when I was first introduced to SVN, I didn’t understand the benefits right away. It seemed like a hassle—an extra step to go through that required me to learn something new and I didn’t think the value outweighed the inconvenience. Then I accidentally overwrote two large class files in an e-commerce project I was working on and had to redo the work. Needless to say, SVN became part of my daily workflow.
In truth, it’s fairly simple to get up to speed with the core functionality of SVN. You only need to learn a few commands before SVN becomes a very powerful part of your process. It’s especially useful if you’re working with a team of developers, as it allows everyone to work together without overwriting each other’s work, to easily share fixes and patches, and to release code to the public in a logical way. If you’re not using a version control system, you’re playing with fire.
If you’re a Rails developer, you might want to check out my SVN with Rails tutorial. It’s a little outdated now, but it should still give beginners a good idea of how to use SVN with a new Rails project.
2. Talk to Your Client
If you don’t know everything about a project, it probably won’t succeed. You need to get as much information from your client as you can. This means initial meetings and a discovery phase, but it also means that you can’t be afraid to ask follow up questions when you need to. You’ll find that most clients are more than willing to tell you anything you’d like to know about the project, and more likely than not they’ll be excited to see you’re so interested in understanding every aspect. Don’t be shy.
3. Pick the Right Technology for the Job
Just because I like Ruby on Rails doesn’t make it the right technology for every job. A good developer chooses the right technology for each project based on the requirements. But do keep in mind that it is your responsibility to suggest the best option. A lot of clients will come to the table with pre-conceived solutions based on things they’ve read or been told, and it’s up to you to state your case and give them their best options.
It’s not a bad thing to suggest a client go a different way. A lot of inexperienced developers will take a client’s requirements and run with them, even if they aren’t the best options for the project. No one wins that way. Be honest, be thorough, and make sure you’re choosing the right technology for the right reasons.
4. Keep the Client Focused on the Important Issues
This tip could alternatively be titled, “Tell the Client to Stop Worrying So Much About 99.9% Uptime and Redundancy Before They Even Have a Product to Keep Up All the Time.” It’s true: Clients believe (as they have been told for years by IT people the hosting industry) that the most important thing is that your website or web application have near-100% uptime. Notable people have written articles about how this simply isn’t true.
Here’s the reality: If you never have a product to launch because you spend all your time maximizing scale and uptime, none of that will matter. The truth is, even large web applications don’t need 99% uptime. And that’s even during success. You’ve got weekends and holidays and nights and slipping a few minutes here and there isn’t going to hurt you. In fact, if your product is good enough (i.e. you spent your time making a killer product), people won’t even mind if there’s occasional downtime that spans hours.
Don’t get me wrong: You should make an effort to maximize your product’s efficiency. But focus on getting it done first. Scale later.
5. Create Functional Specs
When working in a team (large or small), it’s important to spend time creating a functional spec—or something similar—that gives you and your team a clear development path. Many of my most successful projects have started with a functional spec. This does not mean you have to plan every part of a project out. A functional spec is to a developer what an outline is to a novelist. It’s broad strokes: Page flow, general functionality, features. It gives you a map to begin plotting your development with.
Functional specs do not need to be extremely complicated, which means that anyone on your team can do them. It doesn’t have to be the developer. Often times, the most successful functional specs I’ve used were created by other people on the project and then we met to discuss them and make changes. This lead to solid specs influenced by everyone in the project, and in the end a solid deliverable.
6. Read the Documentation & Participate in the Community
Being a developer means learning many different foreign languages. Sure, the core is English, but it might as well be Eskimo the first time you look at it. If you take one of your PHP classes and show it to a non-developer, they’d be looking at gibberish. So it’s understandable that eventually (and constantly), you’re going to need to reference documentation to get things working. And that’s not a bad thing.
Learning how to read documentation, and becoming good at seeking help is an important part of being a successful developer. Even more important is making an effort to be part of the community. Talk about the work you’re doing, read other developers’ weblogs, seek out new technologies and techniques. Join mailing lists or hang out in IRC chat rooms. You’d be surprised how much you can learn by asking questions or just reading about what other people are doing.
7. Find the Right Tools
This sounds like a no-brainer, but you’d be surprised how many people are making due with whatever they’ve been using since 1999. Times have changed. There are great text editors, powerful IDEs, and fantastic tools to help a developer get work done more efficiently and with less stress. If you’re a Mac user, you’ve probably used BBEdit at some point in your career, but have you checked out TextMate or Coda? Or vice versa? Don’t assume that the tools you’re used to are the best tools for the job. It’s possible that your work can be easier if you suffer through a week of transition.
And, of course, there are many utilities such as MySQL interfaces and solid FTP applications that will help. Don’t be afraid to spend a little time playing with your options. Once you’ve decided on a toolset, spend time learning as many shortcuts and such as you can. Getting really good with your tools speeds up your process and makes your job much easier.
8. Take Frequent Breaks
It’s simple: The more you sit in your chair at your desk staring at a computer screen, typing and mousing, the worse it is for you. Break up your work day. Take frequent short breaks and a few long ones. Your back, arms, eyes and brain will thank you. And they might even reward you with the ability to solve those problems you’ve been having the past two days with your user authentication method.
9. Do a Post Mortem
Once you’ve delivered your final project to the client, do an internal post mortem. Talk about what went well, what went wrong, and what you need to change in your process in the future. This is important to do even if the project was a complete success, since it’s a good idea to note how your process worked and how you might apply that to future work. It’s even more important, obviously, especially when things don’t go well.
It’s also a good idea to get feedback from the client. Ask them how they felt about the process, the work, et cetera. Implore them to be very honest. Their feedback will help you to deal with new clients and even improve relations in case the client comes back for more work in the future.
10. Choose the Right Project
Don’t take anything that crosses your plate, unless you’re in desperate need of money or there’s a special circumstance. Being picky is a good idea. Don’t choose projects which you have a bad feeling about—chances are that your first impression is the right one and things won’t work out. It’s much better to take fewer projects on and have them all be successful than taking many and having no successes.
There will be many times that a project starts well and goes badly. That’s the nature of the work. But if things look bad before you write the estimate, step back and think hard about whether or not you want to put in the work to try to change the situation to something you want. In most cases, this simply won’t work out and you’ll regret taking on the work at all. Be selective.
All great points, but as a relatively new freelancer, I can also add a #11. In effort to make sure I had enough post-steady-paycheck income, I loaded up on projects and have been working too much all year. In retrospect, I could have taken on a few of them that have turned into long term projects and easily make a “steady check”, and one month-long website project alongside that at a time. Luckily, sites are launching and I see the light.
With regard to #10, I find that many clients have flat out said that they are looking to me (if hired) to tell them if they have a stupid idea (overall) or any bad ideas within the project. Luckily, I am very frank, anyway, with my clients when it comes to the “will this work” and “will this make me money” conversations. I had one client that came to me with an ida that was so niche that she was limiting herself from a lot of potential traffic/users/income. We talked a lot and she thought through idea and revised her plan in several key ways that opened it up somewhat. Would the initial idea have worked? Maybe, but I doubt it. The final product works and she is happy.
Nice post, Garrett. I just wanted to comment about #4, which is a great tip, although if scaling is important to the product being developed, as it is for one of my current clients, you definitely want to keep that in mind.
A la Jeff’s post on Django, you don’t want to keep re-inventing the wheel. So, if scaling is important to the client from day one, I’d keep that a key focal point of development.
@Andy: If you know scaling is important (for example, you’re re-architecting an already massively popular site), then by all means, plan for scaling. But, there are a lot of start-ups with grand visions of making it big that do spend way to much time, thought, and money on how they’re going to scale without first launching a product.
Most modern development environments (for example, Django and Rails), and n-tier setups: you can always easily throw more hardware at them. In that sense, scaling is pretty easy to do after-the-fact.
Bottom line: cross the scaling bridge when you come to it. If you’re already there, then you should absolutely be thinking about it. If you’re not, ‘tis better to spend your effort and money on making a great product. Needing to scale is a good problem to have. Burning through thousands of dollars each month on bandwidth and hosting charges for a product no one uses is not.
I loooove SVN but am convinced that git and bazaar are going to be the “where it’s at” version control systems going forward.
We decided to set up an svn/git/bazaar version control system, as we didn’t see any that were geared towards closed-source projects.
http://xerophyte.net
I have read too many articles like “10 Tips for Successful Development Projects” and I find something about Version Control System at the first time only in your article. And this point was at the first place here. I find it really correct and reasonable.
Great article. My respect.
Very good advices. It read me the article well. I command all
Great article. Especially advices #2 & #3 are good for me.