Developer Andres Taylor drops some serious science with "Top ten things ten years of professional software development has taught me." There are some real gems on this list, and if you're a developer it's a must read.

Among our favorites, "Learn to Say No" --something every developer should learn before they burn themselves out -- Also, "If everything is equally important, then nothing is important," a philosophy that is difficult to explain to management, but is ultimately genius. You absolutely must prioritize in modern development, there's just too much to be done to move forward without priorities. If you assign an equal weight to every task and goal, you'll find yourself spinning in circles at your desk late at night, pondering why you picked Computer Science over Pre-Law during that first semester of college.

We really hope Andres leading a team of coders, because he certainly gets the basics.

So you've picked a version control system and successfully installed/configured it. Now it's time to figure out how to get the most out of all this newfound power.

The What
What kind of files would you want to put under version control? Anything and everything! Seriously, everything that you work on every hour of the day makes a perfect candidate for version control.

As the senior manager of the software development team, part of my duty is to interview job candidates. One thing that jumped out to me a while ago as I was going through a resume is that a lot of candidates have more interesting jobs at the beginning of their career than their latest employment.

My own experience is very similar. The first job I got after finishing college was with a software engineering company for transportation (mainly trains) and traffic control system, where 'engineering' meant exactly that. The company was ISO9000/9001 certified so that means every process and decision had to be clearly documented and signed off. The traditional software development model, i.e. "The Waterfall", was king and the thickness of the requirement and design documents were matched by the comprehensive testing documents. Every change request must be approved, coded, tested, and signed off before

My wife (and the rest of my family in fact) has never comprehended what I do as a software developer. Throughout all the years we have been together she has seen me sat in front of the computer and typed code into the screen for hours on end. But still she does not know how ideas in my head are transformed into a software application like one that she uses everyday. She thinks it is all voodoo magic, really she does. Last week, I explained to her that software development is kind of like cooking. Not the follow the recipes in the cookbook type, rather the Michelin Star chief type where the dish is created out of thin air.

The image of 'programmers' and 'hackers' portrait by Hollywood does not help either. When I tell people that I write computer software for a living, I am pretty sure in their mind they see binary code (probably green) flowing down the black screen continuously in multiple overlapping windows. Just like in 24 or The Matrix, in fact. And coding involves typing a few lines of indecipherable command in one of those black windows, more code flows down, and Boom! Global warming is solved!

While this image works really well in a TV series or movie, unfortunately software development is not that dramatic or glamorous. The idea of someone (be it a genius or a mad scientist) working alone deep in the basement and conjuring a software application out of nowhere and that every single line of code is memorised is so deeply ingrained in the general population psyche that I truly believe this is affecting software development as a whole.

Of course, it is partly our own fault. We, the software developers, have worked so hard to make complex and powerful software easy to use for the users. We have worked so hard to improve our development process to decrease the turnaround time for each development cycle so new features and bug fixes are delivered to the users with increasingly shorter time-scale. This has raised the expectation of the users on our ability to deliver feature that looks deceptively simple on the surface but probably hugely complex behind the scene.

Is there a light at the end of this tunnel for software developers? Perhaps, but only if we work very hard on at least the following two areas. First better design concepts (object-oriented design, design patterns, refactoring), processes (Agile, TDD), and development tools (C# 3.0's LINQ, Ruby On Rails, etc.) will continue to be improved to let us deliver more and faster. These are already in place and many clever people are working hard to take us there. More importantly, as well as building kick-ass software; we also need to begin an education initiative.

We need to change the perception of our work in the users' mind from part voodoo magic, part art, part skills, and full nerds to a disciplined profession. Some may even want to call it 'software engineering', do you believe that?! Until the general population considers software development on the same level as lawyers, doctors, or engineers, recognises the immense complexity of software applications and the skills requires to build them out of thin air, our job as software developers would only get harder and harder.

* Dev Chair: The place where I plant my butt after a hard day of code bashing and muse about meta-issue. [Alex Hung is a co-developer of desktop blogware ecto and will be penning a regular series for DLS about software development.]