394 karma · joined October 16, 2008
I do weekly backups, alternating between two sets of disks that are kept at opposite ends of my flat in case only one end burns down, as happened to a friend. The really critical must-not-lose data is encrypted and stored on SD cards on my keyrings that I keep with me all the time.
The most strict of all was when I was writing code for an air traffic control system. Every single line of my code was reviewed a minimum of three times. We spent almost as much time reviewing the code as we did writing it.
Version one had simple functionality. Version two had all the bells and whistles dreamt up by the programmers and the customer while we were working on version one. Those were added to a todo list for version two. They were not implemented in version one.
That kept up the flow of ideas but didn't disrupt the project. It made the programmers feel appreciated while giving us an outline for the next version so our competitors couldn't keep up.
What surprised me was that the whole team got into the spirit of the thing. When someone came to me with an idea, cries of "Version two! Version two!" echoed around the programming room.
It was very popular even though it had only one dialup connection at 300 baud. The average user spent more than an hour on it.
Remote: No
Willing to relocate: No
Technologies: EFTPOS, Linux device drivers, mainly C, some C++ with PowerPC, Intel and ARM chips.
Resume: Electronic engineering background, wrote AS2805 library for EFTPOS terminals, wrote drivers for a mobile phone base station, medical equipment and an air traffic control system.
Email: mrlbp@bigpond.com
The previous programming team had written a data transfer program with its own implementation of ftp. I just used the one which was already on the computer.
It took me a while because I had to read the Unix source code to find out if my program would work. In the days before Google, and even the World Wide Web, I used a combination of Gopher and WAIS to find a publically available copy. That was difficult as it had been released only to universities with a licence saying it must be kept hidden.
1. Do you have coding and documentation standards?
2. Do you conduct regular peer reviews?
3. Do you use a bug tracking system?
4. I feel more comfortable working as part of a team, not just a bunch of people working together. Do you conduct regular team building exercises, such as weekly lunches or meetups at the pub after work on Friday?
It's surprising how many companies don't have even these fundamental quality and people management procedures in place.
My experience of college code is that it may work but it rarely scales and performs well. For example, I downloaded a driver that set up the DMA, did the data transfer then tore down the DMA for every read and write. I changed it to set up the DMA for an open and tear it down for a close, leaving the DMA set up for the data transfers.
Look for a job with interesting work, nice people to work with and a financially stable company. Sometimes you have to settle for two out of three.