University is the place where you are taught essential skills required for your future career. Although it is less then 3 years ago that I graduated University, I do feel I have evolved and learned a lot since then. Even though at University I already felt I was a good developer and had a strong mind, working on some real life software does learn you a lot. I would like to look back on some things I have learned, how my view of things has changed and what this is all caused by.
Even at University I was pretty thorough when it came down to testing, I didn’t use any unit tests however. All tests I ever wrote were integration/application tests, testing everything end-to-end. I even wrote about this in one of my earliest blog posts, as back then it was my preferred way of doing it. When faced with an application that is too big to do this testing approach, as it results in tests that run for minutes, I started to read up on some material and I have completely changed my mind. Since then I am a big fan of the pure unit testing.
From my work experience I have been shocked a couple of times as well. I have seen many unorganised environments where it was normal that nothing was well documented and only the people who worked on it knew anything about it. I have always been pretty strict on writing JavaDoc for everything I write, it may not have been very good documentation, but at least there was some. The lack of this simple documentation was very shocking for me, as a new person this makes it nearly impossible to learn anything without having to spend a lot of time investigating the code. I was expecting to have a lot of UML diagrams as well, showing the architecture of the application, but I have now learned that no time is spend on this as the application and thus the architecture often just grows and isn’t really talked or thought about.
During my first work experience I have spent time investigating the point of having documentation, and I have joined the ‘clean code over documentation’ team. Meaning I still write JavaDoc, but I no longer write massive inline comments explaining what I am doing. Instead I try to choose the names such that it is clear what I am doing. Document why you are doing something, not what you are doing. I do however feel the need for exceptions when you are talking about larger hierarchical concepts. A class for instance still needs documentation explaining what it can be used for. It is also essential that the high level interactions between classes are documented somewhere as well, although I am not certain whether this should be done in the code itself or by having external UML diagrams.
With my first work experience, I also had my first agile experience. This had me believe that every software team was already using it, but I have learned that this is not the case. There are still many teams who use the good old waterfall approach (which I have never experienced yet). Even though I consider my first experience with agile not as completely successful, I have learned the ideas behind agile and I value them greatly and want to keep using them. Part of this is code review, continuous integration and having a deployable version by using the correct definition of done.
While there are more things that I have learned and changed over this little time, the things listed here are the most radical changes or new experiences that I have gained. I will take them with me for the rest of my life, and I hope I can keep experiencing, keep learning new things. This continuous improvement is essential in Computer Science as it evolves very rapidly.