What nobody at Uni will tell you about being a Software Developer

31 Oct 2017 What nobody at Uni will tell you about being a Software Developer

I wasn’t sure what my first day at Shine would look like. I looked for some blog posts that resembled this one for some insights but I figured everyone’s experience is different. I hadn’t worked in this industry before, and my work experience at a laptop repair shop didn’t really count. The only relevant experience I had was the industry project I did in my final year of study and that turned out to be very valuable. I knew I would be thrown into the deep end and have to learn quickly. Since day one, I’ve been surrounded by great mentors, helping with code reviews, best practices to follow, great book suggestions and general insights into how this business works. Anyway, I think enough time has passed now to reflect on this year.

First week at Shine

On my first day I started off with some admin stuff setting up my accounts and getting my work environment setup then I met my team over a coffee downstairs. My team leader filled me in on the client we were working with and what languages and tools I would have to learn. He asked me what my favourite platform or tool was and I said “Android”. He said “great, you won’t be using it here”. So I said goodbye to Android.

I was given some documentation and blogs to read like this, related to my first task. This covered Google Cloud Platform services: BigQuery and Cloud Dataflow. This was my first interaction with GCP and my understanding of it was simply “Google’s version of AWS”. I was fortunate to have covered Amazon Web Services during my studies but I was aware we didn’t go deep. What it provided rather was a feeling of familiarity to what AWS could be used for. I knew what a lot of the services were and how they could be used alongside other services but in labs we never went further in execution past spinning up an EC2 instance. Also AWS has a constantly growing list of products and services, too many to cover.

I did the first part of my task using a shell script and the Google Cloud Storage command line tool. It was either that (extending an existing script) or using Python and an API to replace that script altogether. Despite not being well versed in either language, the shell script seemed the more straightforward option so I went with that. I saw the codebase that I would be adding to. I hadn’t contributed to an existing codebase of this size before. There appeared to be a lot of files with different formats and a mixture of scripts and Java all connected – quite a change in scale and complexity from uni.

This also marked the first time I had seen a separate staging and a production environment in use. My development prior to this had all been local development and execution. I had read about about different environments (staging and production) but now they had some weight behind them after seeing a real-world example. I learned that we deploy first to staging before anything goes into production, with staging being a close approximation to production. This way we may find a missing dependency or bug when we move from our local development environment to staging, well before it actually goes into production.

I also saw some cool automation set up by my team. When you merge a feature branch into the master branch, it kicks off a Jenkins job that runs the tests, builds and deploys into staging. All of this is integrated with Slack in a dedicated channel so you can see: when a merge request has been accepted, some code review comments on the changes, see that it built successfully or failed some of its tests. I’ve seen some great examples of automation thus far. Why should you do these repetitive things manually when you can save time and work on something else instead.

So what good was my degree?

As I had expected, I found the industry project I did in my final year of study to be the most useful in terms of preparing me. The project was for a maritime training company which made simulation rigs consisting of an array of screens surrounding the user for immersion and some hardware controllers to interact with software that would control a marine vessel within a simulation. The use case was for maritime training much like a flight simulator for training pilots.  Our task was to make an app for an Android tablet that could be used to replace the hardware controllers that they built individually for every rig. The hardware was quite costly and easier to just simply digitise it.    

The project covered a wide range of skills and technologies. We practiced Agile development and had roles within our project team, having a stand up twice a week in a meeting room (similar to how we do it here at Shine). The requirements stated Android to be the primary platform and no one in the group had any experience developing mobile applications.  I had previously dabbled with GUI programming using C++. It seemed like the most relevant experience anyone had so I put my hand up to start development using Android Studio and try to teach everyone else as I went.  It was a great opportunity to force myself to learn a new technology in an unstructured fashion to get the job done.  It seemed daunting to pick up a new technology in such a short amount of time but I have found that to be the norm in this industry – there appears to be a new popular language or framework springing up every day.

 

 

Another thing the industry project provided for me was experience in problem solving. We had an interesting problem of making the user’s interaction with the tablet’s touch screen equate to action in the simulation software running on a PC – controlling the vessel.  However, we had no access to the simulation software’s source code and no API to use. We defined two paths we could take to find a solution. The first involved replacing one of their DLL (Dynamic-link Library) files with our own and the second involved spoofing a COM port using a virtual one. Both paths were quite hacky due to our limitations and ultimately we ran out of time. But it’s fine – getting that to work was considered a bonus on top of what we had already completed.

Luckily we were taught Version Control during the project and a bunch of project management tools like Jira and Confluence that I was pleased to find we use here. Moving to IntelliJ as my go to IDE was easy because Android Studio is built on IntelliJ so they look and feel the same. Again that meant one less new tool to learn.

In one of my subjects we covered Docker and even though I used it to create containers with functionality, I feel like I hadn’t seen a great use case for it until I was at Shine. I like it’s use as an environment to run unit tests where all the dependencies can be defined and provided or to use it as a sandbox to use a particular version of a library or language that you don’t want to install on your local environment.

When I was learning database fundamentals and SQL I was unsure whether I’d ever use SQL. I was told it would be beneficial if you wanted to become a database administrator which didn’t seem like my path. However, in our team we use BigQuery daily which uses SQL. I recall a friend at uni telling me “don’t worry about databases and SQL”. I’m glad I didn’t listen to him – all those group by, order by and left joins are coming in handy now.

One thing I think my course really glossed over was unit testing and it’s importance. It was covered alongside usability testing as testing in general. We saw an example of a testing framework and how the syntax worked but I missed the point of what makes a good unit test, which is important when it’s so easy to write unit tests that don’t accomplish anything. I don’t think they sold the argument for unit testing. I spent some time playing catch up on this one when I was asked where my unit tests were. The usefulness is obvious after you have written them, in particular they can alert you to broken functionality you may have unknowingly introduced when making changes to existing code.

I’ve seen many people write that one of the most enduring parts of getting a degree is learning how to learn. I agree with that. The industry project in particular taught me how to self learn, focussing on only the relevant bits as you need them. Of course the degree also covered the fundamentals that are essential – eg. how one programming language works in depth so that you can move to another language with less friction (Java to C++ was similar enough). I’m glad I covered React during my studies, because it would make another JS framework like Angular easier to pick up if I am to use it in future.

Being surrounded by helpful and experienced developers, I was pretty conscious of when to ask for help. There’s times where the answer can simply be searched online or worked out after short amount of time. That’s an occasion when you don’t need to ask for help because you would most likely be wasting someone else’s time – in that case they’d Google it in front you. But if it means you’re wasting your time figuring something out for hours on your own when it could have taken five minutes with someone explaining it to you, then that’s a good time to ask. Most likely someone has encountered a problem just like yours before and can save you some time.

In closing

Since starting at Shine, there’s been multiple times where I’ve been given a task which at the time either seems too large or intimidating. That’s all in context to what I’ve encountered previously. It’s helped me since day one to have a positive attitude about the next thing I’m working on. “I haven’t used this language before and haven’t even heard of this new AWS service… Alright, I’ll figure this out”.