As a developer I have used version numbers but never gave many thought about it until recently. I know I have had some issues with it where not explicitly enough specifying dependency version could break things with new builds. On the other hand the usage of version numbers of internal libraries was always non-existing. In this blog post I will go deeper about how I experience version numbers from a developer’s point of view.
In my four year carreer, I recently started my third job. This may make me come over like someone who very quicky changes jobs but I never changed job for the money or some other better deal I would get at the new location. I have always decided to leave based on the work I was doing at that time, altough I must admit that in no circumstance I have ever changed to a job that was offering me less then what I had. My quick passage at jobs may sound like switching could have been the wrong choice and that the previous job wasn’t that bad after all, this is what I will elaberate on during this blog post.
At my previous job they were starting up a new project on which many different people from different locations would contribute to. To give you an idea of how distributed the team would be, it would consist of 7 people in 4 different locations. Altough we have come a long way, and communicating with people all over the world has become possible without much effort there still are some problems that could arrise.
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”.
As a software engineer you often don’t have much impact on the team structure and you just have to deal with what management decides is best. Management however often does not know the impact of team structures on the produced software. Splitting up people in teams will make this separation clear in the code as well simply due to the extra barrier communicating with other teams and code being developed in parallel without much knowledge of each other.
A number of factors that in my opinion affects productivity, quality and performance of your team are:
* Amount of teams
* Number of people in a team
* Skills of the people in the team
* Structure of a team
In this blog I will go over each of these topics and discuss them shortly.
Ever since I started working for the new company I have been working on this type of warehouse management system, although we call it ‘material flow control’. Many things have changed since the initial design (which I wasn’t part of), the biggest one being going from a generic to a specific approach. At the moment this decision was made, my team lead also told me to forget about persistency for now and just focus on the functionality.
With all the bare functionalities implemented, it is time to start working on the presistency. This proved to be much harder simply because the design wasn’t made with persistency in mind. So my first priority was to refactor a lot of the code so it can be more easily be stored and recovered from a database. Clearly this could have been avoided and saved a week of effort for the already too tight deadline.