Every post I write is based on my own experience and it's brought to you to help you learn from my mistakes
Do you follow any Design Patterns? Why those? Is it committed and pushed to a repo? Is it easy to understand for next versions? Will anyone (that it isn’t you) be able to pick up from you finished? And more…
At the beginning, in my job, I was assigned a “mentor” that was able to make me aware of those questions. After about a month and a half I was (apparently) prepared for my first assignment.
I had the opportunity (later realized how rare this is) to build a new project from scratch. When I say “I” I mean a co-worker and I. Thankfully my co-worker didn’t really care for this new project, so the main parts were mine to create.
This system was a Server-Client kind of system and was designed under a lot of constraints my company required.
It was all in C# and we used files to communicate between the modules. After the client would be deployed, there would be no way of contacting it but with our server, no manual intervention could be done. I was a bit afraid the client won’t work as intended (being this my first project…), so one of the modules I worked very hard on was a self-update module. You could send the client a new version of itself and it would self-update – Cool!
This module made me ask myself the following question:
How the software can change its own files while running?
Apparently there are (at least) two ways:
Dynamically write a batch file that will do the update itself. Run it from your application and exit your application. Add a delay in the batch file to allow the application to close before you start changing the files in the batch file. Run the new application from the batch when finished.
Apparently, Windows has this feature/bug (never found out) that allow you to rename files even if they are in use (doesn’t work for Office files, but for Dll’s and Exe’s it does!).
So you could use this to replace your files!
I chose option #2 for my self-update mechanism, it seemed more clean to do it this way rather than creating an awful batch file.
The idea was this:
If you receive a self-update package, rename all of your files (append “temp” for example) and copy the new files to your folder (thus replacing the old ones). Finish with restarting yourself (Using a small batch file to re-run yourself after you exit). If any of the steps fail, rename the files back.
This little feature made me really happy!
I probably tested this feature twice as much I tested all the others.
Three years have passed from that, and we didn’t need to send a self-update to fix anything. We sent it to upgrade the clients to have more features (and it worked!)
Not only the client was able to self-update, I felt I have updated myself. This project took me approximately half a year and being the first half year of my work life, it taught me a lot.
Here is a list of stuff I think worth mentioning about my experience.
Always be prepared to changes in the requirements. In my case it was constraints that were added and more features.
This means that all the Design Patterns we learned are really important and can really make the difference.
It sounds like a cliche and we hear it all the time but it is real. Clients don’t know what they want and don’t know what you can offer them. Sit with them and listen to what they really say when they say they need “X”.Don’t underestimate the power of tests (but don’t overestimate them). “Tests are good as the person who wrote them”. You can easily have a 100% covered project that doesn’t work.
I didn’t write automatic tests for this project and I regret it to this day.
If you don’t have automatic tests that really check your code, you are writing legacy code (more about this in an upcoming post).
You want the next person that looks at your code (let it be yourself) be able to make changes and updates easily, automated tests are a huge part of this.Projects from scratch are awesome and very rare! If you have the opportunity to write something from scratch grab it with both hands and don’t let it go! It is really rare (unless you work in a start-up I guess).
Why It’s awesome? Because it lets you be creative and you can build it as you want. Moreover, I think you learn the most from creating something from scratch rather than adding feature to an existing code-base.Being new and an outsider is actually a good thing! I came fresh from the outside. I wasn’t narrow minded and could see things with a fresh look. A lot of things I said where indeed pretty null but a few were good and improved the system and other projects. Don’t be afraid to speak up.
It’s OK to ask questions. Actually, it’s not OK to not ask questions.
You might think you are the best but rest assured you are not. Your co-workers probably have more experience than you have, and even though they don’t know everything about what you are working on, I’m sure they can advise you and will be happy to (no one loves anything more than showing they know something…)Write your code like the next person who is gonna look at it is a mad-alcoholic-axe-holding-nothing-to-lose guy. After three years of that system, I sometimes look back at the code and swear the guy who wrote that, then I remember it was me.
Most of the code I write nowadays is one I’m happy to look back at it and it really makes me joy to know I wrote that. (Most, not everything)
I’ll talk more about this in a future post.You know nothing about development until you have worked on a real project (with clients, managers, co-workers, QA team and more). There is a huge difference between coding for an assignment and coding for your job. This too will have a future post.
This project is up and running up until today and will probably stay online for a few more years.
I would love to hear some of your experiences of your first project on your first job, I think each one feels a bit different and can contribute from its own experience.
See you on my next post!
(You can read more like this on my blog!)
Top comments (0)