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”.
A few days ago someone with more experience, and I assume more knowledge about the Java Virtual Machine told me that there actually is a difference between a synchronized method and a synchronized(this) block encapsulating the entire method body. The reason why he used the latter was to get more performance, as so he told, the JVM is allowed to synchronize all methods (even those without the synchronized keyword) if this makes it easier to manage. The gained performance comes from methods that do not need to be synchronized but will be out of your control. As a good computer scientist, I tried to test the statement.
And so has the year 2016 come to an end, and we welcome 2017 as a new year full of challenges and opportunities. So with some delay (due to my holiday) I wish you all a happy new year.
Looking back on this blog and what happened in 2016 it was alright. The goals I had set to write a post every two weeks was met as I wrote a total of 26 blog post. However, I failed to promote my blog and I didn’t do much to make it easier to be found online. I have looked into Search Engine Optimization, but WordPress demands you have a premium account for that, since I am only a simple and beginning blogger I have no intention on paying for this service.
I achieved a total of 169 views, which seems very little over a whole year, done by a total of 103 visitors. While this may sound as I only barely missed my target of 2 visitors a week, it was nothing like that. I had weeks where nobody visited my blog, and then the next all of a sudden 4 people.
I am very delighted to see that people find my blog both by using search engines as well as being forwarded, either by another blog, my linked-in or some other website. Though most people just seem to find my blog magically, as WordPress is unable to tell me where they came from.
It was sometimes very hard to find a topic for my post, even after reducing the frequency of my posts. I hope I can continue to keep writing blog posts that will interest you and me. So if any of you have some topic you want me to write about, just let me know.
In 2017 I hope to do what I did not do in 2016, share my blog with more people and spread the word. I am also thinking of leaving WordPress to a different blog, one that more easily allows me to do Search Engine Optimization and some other customizations I would like to do.
How often do you really think of a good name before you start writing code? From my experience I never do this, I just come up with names along the way which complicates some things:
- You need a name for your repository
- You need names for certain classes
- You need a name to be used in documentation
If you don’t think of a name up front, you will likely have used a very technical name which down the road may not fit the application anymore. Maybe you just got tired of the name, or you initially said that it was only a temporary name. But replacing an existing name can be very painful.
It is pretty easy to forget about logging when writing code, and even if you think about it most often you will just log any exceptions. While logging exceptions will tell you when something went wrong, and where it went wrong it will not tell you what was the actual cause of it. In other cases there will not be any exceptions at all, but the problem will be caused by a bug in the program.
When trying to figure out the cause of the problem it is essential you can see the actions leading to it. To allow this you should log a lot more than just the exception, but logging everything that happens will lead to a log file that will easily blow up and become impossible to handle. A log file that is too big to read or to hard to understand is just as bad as having no log file at all. So what are some good practices to have decent logging?