Things I have learned from work... so far

 Back in 2009 I started working on a Swiss software development company called Swissbytes, since then I have learned a lot of things. This is a very short list of the most important ones:

• You are not the best programmer in the world, deal with it.
• Always put your name in your source code.
• Keep track of your work, as well of your source code.
• Think a little bit before jumping into programming, but do not exagerate.
• Keep yourself updated, no one likes conformists. 
• Learn English, that's a must do.
• A good specification is short and to the point.
• A software product is never finished, never.
• Work with standards, that's required if you are working in teams.
• Write tests for your code (this is something I'm still learning).
• Simplify your life, there are tools for that: revision control systems, automated build, template engines, static analysis tools.
• And the most important of all: Enjoy what you are doing, if your work does not make you happy, there's something wrong. That's the best motivational advice I could give you, enjoy your work, enjoy working on group, enjoy working alone, enjoy challenges, be proud of yourself.

I guess those are the most important for the moment, for sure I will be updating this list. Enjoy.

Revision control systems - Part 1

As a software engineering student, many of the subjects of the career includes software development projects. And as every kind of project, they normally have: documentation, source code, configuration files, templates, etc.

At first being a newbie in software development practices I concluded after a while that I needed some sort of revision control for my projects, because all of them were presented to the teachers incrementally and progressively.

My first approach was to 'clone' my project and name it with some I meaningful name, something like:

• bookstore_presentation_1

Was very common for me, if I read the name in the future is easy to deduce that this 'clone' is a snapshot of my project in the first presentation date.
But after a while I required to recover a 'clone' of an specific date, the only way to find it was to manually check the modification date of the files... pretty dumb.

Because of that I defined a naming convention for my snapshot copies, it was something like this:

• project_presentationNumber_date(YY-MM-dd)_description

And I was kind of happy with this approach for some time, but after a a year my projects workspace got really nasty:

• bookstore_pres1_08-02-10_initial
• bookstore_pres2_08-02-12_basic_func
• bookstore_pres3_08-03-01_simple_reports
• bookstore_presFinal_08-03-10_final
• bookstore_presFinal_08-03-10_improved
• bookstore_presFinal_08-03-10_not_working
• bookstore_presFinal_08-03-10_1h_before_presentation

Nasty, right?

But somehow I managed all my projects in this way for quite a while. Then I started working with teams; after a week of development it was pretty obvious that my naming convention was not working:

• bookstore_pres1mine_08-08-05
• bookstore_pres1jhonny_08-08-05
• bookstore_pres1oscar_08-08-05

We had some torture hours trying to merge our project versions, but at the end we did it. To finish that project, we suffered as cargo horses for a complete semester, doing manual merges and dumb overrides.

The next year I started my thesis work and I didn't want for any reason to be involved with the same problems again (I was working with a fellow developer) and I started searching for a software tool that could help me to keep track of a project. After some minutes I have found CVS, I read all I could find and I got involved in Revision Control theories.

Then a teacher suggested me Subversion (CVS done right, as he said). I downloaded a copy of SVN red book and learned the basics commands and theory of the system. It took a whole afternoon to setup a local Subversion server and create a proper repository for the project, but I did it. My partner and I started working with an initial project structure and we were progressing really fast, but at the moment of merging our work, we had LOTS of problems and ended up with the decision of setting up a central repository for both of us, as is recommended in SVN book.

We created a project in Google Code with Subversion and we started working from zero again, and the result? It was a developer heaven, all our changes were being tracked and held in a reliable service. And yes we still had conflicts but Tortoise SVN did all the dirty work for us, we finished the project in 6 months with a dozen of releases (tags) and got our degree with a very good mark.

SVN taught us how to handle our source code, our documentation files and some other important files (images, scripts). It taught us which files should be tracked and which ones should be omitted. It gave us a tracking discipline, we learned the meaning of keywords like commit, update, revert, log, resolve, etc. 

Since then all our projects were under SVN and we were pretty happy. But then we started working with some fellows in other cities, 5 in total, and some of them didn't have an internet connection for more that an hour by day.

We required another approach, SVN was not enough this time, that is why we started working with Distributed Revision Control Systems, which is described in Revision control systems - Part 2.