The Trials and Tribulations of an Industrial Year Student

University is a fantastic stepping stone to achieve a professional career in Computer Science. However it isn’t the complete path…
You go to lectures, learn the history of C11 versus C99, research about path finding heuristics, eat pasta with pesto and then believe that you are ready for the real world.
The simple truth -> you’re not.
This is why I decided to come and work with for a year to gain experience which I would not be able to achieve through study alone.

Learning Space

University Vs Industry

University assignments normally consist of building a program in Java, C or C++ with little use of libraries and where most of the code is custom created by you. This differs from industry where deadlines and expectations lead you to use prebuilt libraries which allow you to create anything from a simple website to a working API within minutes.

Although it is fantastic to create your own code in order to learn the important fundamentals of an algorithm or feature, I quickly realised that using existing libraries is a skill within itself which is not touched by academia (more on this later).

Learning curve

The terms “API”, “Ember” and “Express” were all new to me when I first came to The initial knowledge gap which I needed to bridge was strenuous to say the least. I often had to lucubrate at home in order to overcome the initial difficulties of attempting full stack development and in turn, Hoegaarden definately profitted!

My journey started by understanding Ember and the connection to Express/Mongo. At first the information base which I had to assimilate was massive. I dipped in and out of limitless pools of information to gain fundamental knowledge that I required in order to fire up the stack. This was slightly annoying because I didn’t have the opportunity to research the different parts in great depth as I would have done at university. Over time this became second nature as I started to pick-up the detailed information the more that I use the stack.

Getting Stuck In

First Project

After I understood the stack at a decent level, I was placed onto my first project for a client. This project utilises embedded hardware that connects to an API in order to gather data. uses the scrum methodology in order to separate projects into 2 week time slots called “sprints” which I had to get used to. Each feature on the project is called a “story” which is measured in complexity rather than time. I had to evaluate each individual story and give my own personal complexity in order to gain an estimate as to how long each sprint would take. The next step was planning out a new sprint every 2 weeks by placing the stories which needed to be completed inside of the sprint and finally, demoing the work which had been completed to the client. It was then rinse and repeat as the cycle continued with planning the next sprint.

Exposure to clients and carrying out backlog grooming sessions is a valuable skill which I have learned over the last few months. Thankfully the client for the project that I am working on has very similar interests to me so the relationship between us is great both professionally and personally with pub debates happening on the odd occasion. One skill that I definitely want to improve on over this year is the ability to talk with authority and confidence to an audience and talking to clients is the first step on this path.

Setting realistic expectations for the sprints is a key part to working with the scrum methodology which I struggled with at the start of my internship. There is a delicate balance between the amount that you can deliver and the amount that you say you can deliver. At first I was underestimating the complexity of stories and overestimating the amount that I could complete on each sprint with my new knowledge. I learned this the best way possible by missing a deadline due to underestimating the integration of Passport.js authentication in Express. Making mistakes is key to technical development and as long as you learn from the mistakes, you can start to improve rapidly. This experience has led me to understand that it is better to underpromise and overdeliver rather than overpromise and underdeliver.

Documentation Is Key

As mentioned above, using libraries is a key skill which is not learned in University. Passport.js is a library which I have had plenty of trouble using. The website and content layout is fantastic, but in reality a fancy website doesn’t mean that it has been well documented. Due to the lack of documentation, I fell behind in a sprint. The split views on stack overflow and lack of documentation drained my energy and took me on a journey which spanned almost 2 weeks. Now that I have implemented this library and authentication works I can say that it is a library which I will carry on using because the payoff at the end is worth the effort put into the development, due to the automation of authentication and the way in which subsequent requests are accessed.


Learning can be stressful. The more you have to learn, the less time you seem to have. This is true for most things in life but it gets easier when your used to it.

It must be noted that has certainly helped to lubricate my integration into this industry. Every two weeks, I get the opportunity to raise any thought or feeling’s through a section which is embedded religiously into the diary called “My Voice”. Team meals are also important and the occasional pint after work with colleagues relieves stress and creates a location for interesting topics of conversation.

Chuck helps whenever I am really stuck with a problem, James helps me manage my time and Ian gives me plenty of motivation.

Read this…