Stopping from time to time to ask yourself how you became who you are and what made you this way is often an insightful endeavor. Today about six years after receiving my bachelor’s degree in software engineering I’ll explore the question of what I learned and what I should have learned in college.
Studying in Germany
I received my bachelor’s degree from a German Hochschule (usually translated as university of applied sciences but some institutions prefer to leave the applied part out of it). A Hochschule is something in between a Berufsakademie (university of cooperative education) which confers an academic degree while requiring a considerable portion of hands-on experience in a company and a regular university which has a very strong theoretical focus. I had a fair share of both theory and practice.
Structure of the program
I perceived the study’s orientation of being very broad starting with various programming languages (focus throughout the study was Java though) and software design, continuing with usability and business-related aspects and finishing with psychological facets of teams and projects. A mandatory six-months internship, a specialization and various elective courses rounded out the structure. Possible specializations were systems engineering or SAP-based consultancy. I chose systems engineering with automation and embedded systems in C as main areas.
Programming languages – the more the better?
If you ask me there were too many programming languages and frameworks present in those three and a half years.
For a part-time job I had to refresh my Pascal knowledge and learn Delphi for porting a visualization tool from the former to the latter. I guess that’s again my fault. It was good money for me, but it also took a lot of time.
As an intern I did Android programming. Luckily the iOS internship position was already taken or else who knows, I might have Objective-C on my list.
For the analysis course we had to learn MuPAD which came in very handy when I had to digitize some mathematics scripts for a part time job.
And when I learned by chance about esoteric programming languages, I just had to experiment with Brainfuck.
You probably can imagine how naively proud I was of my résumé. While I knew I was still a rookie, I was not aware how complex everything really is and how much more you need to know to halfway master – not only one language – but also its ecosystem.
In retrospective I would say that sticking to two, maybe three languages is more beneficial than dispersing oneself like I did (and partially had to do).
Since I finished university, I call Java my daily business. After receiving the degree, I probably could have built any piece of software with my programming skills albeit poorly.
Towards the end of the study I did a small personal project in Java. I remember liking what I did. From today’s point of view that piece of code is just badly designed. There are simply too many things mixed together which would have been better separated. Is this discrepancy normal? Up to a certain point, surely.
You don’t become a senior developer just by finishing a bachelor’s in software engineering.
It wasn’t easy for the professors either
The software engineering department of my university was struggling with the same problem as many software engineering departments do: too few students finished their study and too few learned how to program (even poorly).
Their answer to this problem were modern pedagogical concepts. In the first semester we used BlueJ as our IDE, in the second one we switched to Eclipse but used Greenfoot for a larger team-based project aimed at demonstrating our knowledge.
It is astounding what can be done with something seemingly so simple as Greenfoot provided that you know what you are doing, which we didn’t really. But we had to work in teams, we were required to structure our code with design patterns, which we were thought a handful. We had to version our code with SVN and we had to create a product requirements document. Pretty fancy for the second semester.
We were just playing of course. Four people working together on a small thing, without any idea of how to structure it, led to everyone working on everything trial-and-error based. Almost each commit resulted in plenty of conflicts. The design patterns topic wasn’t better, but it was easier: you always have a list you iterate through, so there you have your iterator and since you have a GUI and some events, there you have your listeners (aka observer pattern). And you can always declare something to be a singleton. Voilà.
Well-meant teaching methods did not always lead to the desired results. Instead of “playing” developer and project manager I really would have preferred to understand what I was doing, to understand what design patterns are good for and not just the simplest ones and to learn how to structure my code. It would have been important to learn how to deal with threads (above the very superficial level we did), to learn about reflection and generics and to delve deeper into the collection APIs. I really would have liked to learn how to master the debugger and the IDE.
Well, I would have preferred to be a better programmer after my college years.
I won’t make many words about the Java EE course. In short, for me it was a catastrophe. It might have been me to a certain extent, it might have been Java EE, but mostly I think that we just did not spend enough time with the topic for me to understand it.
We did Servlets, JSP, JSF, RMI, JMS, JMX and Webservices, but it was all too much. Interestingly, I did not perceive my lack of knowledge of Java EE to be a deficiency when I have built my first Spring Boot application a few years later.
Management methods, people and helper tools
But it wasn’t all that bad.
We were required to test our code with JUnit almost from the beginning (starting with the second semester, I think). Checkstyle was mandatory for enforcing coding standards. We used FindBugs for static analysis. We used Subversion starting with the second semester, which generally led to problems when working in teams, but still was overall a very important lesson. Planning our work with the help of Kanban boards was sort of required (we used Redmine for that). We used wikis to document various things. We used Ant for building software (Maven would have been a good addition too). I am grateful for all these things and knowing them from the beginning, even at a non-expert level helped me a lot.
Working in teams is not a goal in itself, social aspects add complexity. But large systems can only be built by large teams which makes communication skills very important. In the fourth semester we had to do a larger project, again in teams, using Kanban. We could freely choose the technologies and what we wanted to implement. My team’s project ended in an absolute disaster. We couldn’t work as a team, we even broke up in the end. But I learned some very important stuff through that project:
- Reaching a consensus when building something is very important, the ability to communicate is paramount.
- You seldom can choose your team or your project, but there are teams which just don’t work or work very poorly. This is something I’ve seen a few times during my career so far. The one who puts the people together and the one who manages them must be aware of this.
Although I studied at a Hochschule, we had our fair share of maths. And I must say I loved it. It was clear, simple and concise compared to the fuzziness of our Java courses. But, except for the Fibonnaci sequence used in the planning game I didn’t have the opportunity of using the math I learned.
I probably even forgot all of it by now.
Although I did not really learn this during the study, this is an important lesson in my opinion: mathematics deals to a much greater extent than programming with necessities. Programming is more about suitableness. The question whether a mathematical tool is in any way suitable for a task is not for the mathematician to decide but for the domain expert. A programmer can simply build a suitable tool for his problem if he is not happy with the existent ones.
I specialized in systems engineering, more precise in the development of embedded systems in C. That was the thing to do if you liked a challenge. Only two students of our year did that. I thought embedded systems also to be more fun than business consulting. I even could imagine doing that for a living back then, something that changed meanwhile.
Besides the importance of performance optimization – an aspect very often ignored – I cannot remember anything I learned which helped me with my career so far.
Would there have been a specialization in Java EE, I guess I would have done that rather than embedded systems.
I guess the structure and contents of my bachelor’s program were overall neither much better than other programs nor much worse, it was simply average. Nothing bad in this. The foundation laid was strong enough to build upon it.
I thought the bachelor’s program to be very broad. Meanwhile I know software engineering is a lot broader than that. In a previous article The Complexities of a Java Developer’s World I outlined what I consider important to know as a Java developer and why it is so difficult to keep up with everything.
I considered the whole psychology and working in teams stuff irrelevant – after all I just wanted to code. Meanwhile I know that people are more important than technology and projects will more likely fail because of the people involved than because of the chosen technologies (and even when the technology is the problem, it’s still the people who choose it).
I thought it’s fun to delve into many different things – and it is. Meanwhile I think it’s more important to know one thing well than to know many things superficially.
Mathematics might be fun, but you most probably won’t need it. It’s much more important to understand how to program. Laying good foundations is very important, it is no less important to constantly improve your skills and expand your knowledge.
Is it worth it to go to college?
I’ve met software developers who did not study and were very good at what they were doing. I’ve also met people who had a diploma in software engineering and could barely program. Not every engineer with a degree has to be a good developer, some are good managers or leaders. Sadly there are also some who are neither and only have the degree.
But then you have to ask yourself, why do you want to study? Is it because of the higher salary afterwards? Is it because of the broader knowledge-base? Or is it for increased credibility? I guess studying helps with all these, but is not a mandatory prerequisite (might also depend on the country you live in).
I can only say, that for me, studying was worth it.
You might also like the following articles or book reviews:
- The user story metaphor – is it appropriate?
- The complexities of a Java developer’s world
- Why frugalism may appeal to software engineers
- Daniel Kahneman – Thinking, Fast and Slow
- Bertrand Meyer – Agile! The Good, the Hype and the Ugly
- David Thomas, Andrew Hunt – The Pragmatic Programmer (20th Anniversary Edition)