Crucial to good Object Orientation, is the separation of concerns and capsulation. This means your objects need a clear API that limits the way the internal state can be changed. The object itself must be responsible for the state and must guard its integrity. While the API defines what operations are allowed, these methods have restrictions of their own. It is essential that the parameters provided to these methods are within the limitations. The only solid way of checking these values is by using preconditions.
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.
A Map is a very common data structure to use, and often you find yourself wanting to traverse over all elements in it. For this we have multiple methods:
If you are interested in both the keys and the values, the valueSet does not fit your needs as it is impossible to get the key based on the value. But which one of the remaining two ways performs the best? I did the test and found some interesting results.
We all continuously use protocols and most of the times this is fine and we don’t really care about it. The protocol however determines a lot more than just which data you have to send, and in this blog post I will go into detail on the requirements to have lossless communication on the application level. There is a big difference between lossless communication on the lowest layer, such as TCP and on the application layer.
Lossless communication can not be achieved with any protocol, the protocol must be designed for it in such a way that it can handle all types of failures:
- Network failure
- Client crash
- Server crash
When writing software we often are only focused on just that: getting the feature done. With the rise of Test Driven Development (TDD) some of us will first write tests before the actual code and this is great. Personally I like the concept of TDD, but I can’t seem to make myself adhere to it as I am always to eager to write the code instead of first write the test.
Another reason I don’t do TDD is that I find it hard to write a test for something that doesn’t even exist yet. At least the public interface should exist, but this interface can change often during my implementation because I don’t come up with a full design in the beginning.
But even though I don’t do TDD, I spend a lot of time writing unit tests, making sure all of my code is being covered and that I didn’t forget anything. I do this because this is the only way to avoid bugs in the future. Others however will spend either much less time on writing tests or none at all but will write a lot more code. To an outsider it may seem like these developers are more productive as they output more code. There are however a couple of problems with this idea.
Different software engineers get motivated by doing different things. Some get motivated by fixing bugs, others like trying to break the code. Software engineers like me however, like to solve complex problems, coming up with algorithms and data structures to solve the problem the best way.
While it is easy to provide enough bugs or code to break, it is much harder to constantly provide new problems that are challenging enough. As a result I often start to feel bored at work after a couple of months, but there are ways to solve this and keep the challenge.
For companies it is hard to have a promotion path for software engineers. Some companies may have the option to promote to a leading role such as a team lead or a software architect. This promotion however contains a complete different role for the software engineer as he will no longer do any of the actual programming anymore. For some software engineers, among which I count myself at the moment, this is not desired, as it is the passion of the actual writing the software that drives us. This however means that some people will always be ‘stuck’ in the same role at the same level.
From this a different type of promotion path was created: the path of expertise. A software engineer with a lot of experience could use that experience and become an expert in some domain, giving him more responsibility for that part and decisions that have to be made. This is often indicated with the levels: “junior”, “medior” and “senior”.