Scott Hanselman recently put out an interesting request for folks to post about three things they've learned about software either in college, out of college, or both. Seeing as I only took one programming class in college (C++ 101), this post will cater to his request of "I'm especially interesting in those who didn't go to college at all, to add yours" (I do have some college, but only 3 semesters worth).
Reading Karthik's response is what inspired me to hammer out my own version.
- Learn how to say "no" early on in your software development career. I don't mean just all out "no we can't do that" but something more along the lines of knowing how to avoid scope/feature creep. Give clients an inch, and they'll take a mile if you start succumbing to a "we can do anything" attitude. Potentially this can snowball into ever slipping ship dates, and the client will blame you.
- Release early and release often when it comes to milestones/alphas/betas. The sooner you can get bits into real world usability scenarios, the more polished the end product will be. Doing this also instills a greater sense of ownership from the client's perspective which will appease even the most 'hands on' type of clients.
- Your job does not end at 5 o'clock each day. Many days it will not end until well into the wee hours of the morning. I don't mean that you'll always be doing billable work during these hours...this is a career that requires more self training than most others, and as such if you're not willing to devote a substantial amount of your own time and money making yourself more marketable, then this isn't the right career path for you.
- *bonus* Try not to get caught up in what I like to refer to as the "everything looks like a nail" syndrome. It's very easy to want to start applying all of our newly discovered knowledge to projects we are currently working on. My rule is "if the project has an invoice attached to it, use practices that have worked for me/my team in the past, and that I am familiar with...save the bleeding edge stuff for personal projects, or get guidance from someone in the know (teammates, leads, etc)." Redoing architecture after the fact is expensive, and will usually cost you a client.
Software development is still very much an art more than a science, so what works for one team very well may not work for another. In the end, it comes down to learning from past mistakes (of which there will be plenty early on in a career), and doing more of what has worked in the past. Well, for me at least.
Sat, Jun 30 2007 2:30 AM