My first week as a graduate software engineer

Welcome to my first blog post!

My name is Steve and I’m a junior software engineer who has changed careers after 10 years in another, unrelated industry. If you’re interested to hear a little more about me, please feel free to visit my About page.

I’m so glad my career change has finally started. My first week has been amazing. The time has absolutely flown by and I’ve learnt some really interesting things.

This is the pre-graduate training – a language school for new coders to start to think like a software engineer and understand the basics. We’ll meet up with the rest of the graduate cohort next week when our full graduate programme begins.

We started out with Ruby as it is one of the easier to grasp given it reads like English easily. I’ve done little bits of Ruby through CodeCademy.com so I knew some basics, although I quickly discovered looking for help wasn’t as easy as for Javascript!

My week:

Day 1

We eased into the week by doing some brainteasers. The types of questions that are asked in interviews for Google etc (but not at that level!). They were interesting to think through and try to derive an answer. The types of questions we had included:

1. Why are manhole covers round?
2. How do trains stay on the tracks?
3. How many piano tuners are there in Chicago?

They were designed to get us thinking and consider why certain things were the way they were. The last of these is an example of a fermi problem. Here we’re really just looking to get the order of magnitude of how many piano tuners there would be in Chicago. We tackled it by considering:

1. The population of Chicago
2. What percentage of these people would have a piano
3. How often do they need tuning
4. How much can one tuning cost
5. How many pianos would need to be tuned to make a living…..etc

All of our answers were guesses, but each question narrowed the answer down more and more. This was an interesting task and was brought round full circle when the instructor said “This may be thought of as ‘How many servers would we need to run our proposed website'”.

We talked briefly about binary search and how it’s used everywhere (eg) traversing databases. It was interesting to hear how large problems are sorted with simple methods such as a binary search.

We ended the day discussing the importance of well written code that’s easy to understand for another engineer. Our instructor noted that in his opinion it’s better to be good at reading code than it is to write it. I thought this was interesting and I can see how reading so many varied styles of coding can improve your knowledge of it.

Day 2

We started coding today! We made a simple Blackjack game operated through the terminal. This was tricky. We broke off into pairs/groups of 3 and went away trying to solve our problems. My group was of similar experience to me where we’d hacked away at some things in our own time but nothing really taught before coming to the grad training. This lack of experience showed. We ended up hacking something out which had a few issues which caused us a lot of pain to solve!

Our main issue was with a changing Ace. If you’re unfamiliar with blackjack, an Ace can have a value of 1 or 11 and we struggled to implement this change in our code. Even once the instructor showed us his result we still struggled. We used case statements to assign values to our cards and considered the values of our hand in a massive loop statement. However, making an Ace change its value dependent on the hand total (ie if we’d gone bust and had an ace then we can drop its value down from 11 to 1) was a real pain! In the end, another graduate came to help who has a degree in Computer Science, so was well versed in these types of problems. He inserted two simple lines of code in our loop to say if we’d seen an Ace before and if we’ve dropped its value.

In the end this gave me the biggest headache and I walked away feeling pretty dishevelled! But it’s all a learning curve.

It was also my first experience of pair programming. This took some getting used to but I enjoyed it. I liked discussing the scope of the problem with the group first and planning how we were going to tackle the problem. However there were times where I felt my old routine sneaking in. For instance, when we had an issue sometimes I just wanted to take a copy of the code and mess about with it trying to solve the issue. I still think this approach is fine, we’d try to complete as a group first before I’d hack away at it myself, although I’m not sure if this is what should be done!

Day 3

Day 3 started with completing the Blackjack game and doing a code review with the class. It was really interesting to see the different ways to solve the problem. But it was particularly helpful to see how Computer Science graduates tackled it. Their code was much more structured and they showed us a lot of useful tips to use in future projects.

Our instructors’ version was so neat and concise. I was left wondering how they tackle these types of problems. It was almost like they view coding a problem differently to me. We had similar ideas of tackling certain issues but how this was then translated into code was so different. I talked to some of the more experienced students who suggested that they hadn’t done much dissimilar to us, but it was all in the refactoring. Given my team’s issues trying to get a model working at all we hadn’t had time to refactor. The advice given was to consider any piece of code that would be used multiple times and to make it into a function. I could understand this from a retrospective point of view but I still thought the more experienced people considered this from the outset.

We then briefly talked about recursion – a function that calls itself in its function’s body. An example of this would be with outputting a series of fibonacci numbers. A fibonacci number is the sum of the previous two fibonacci numbers in the sequence. We were told that recursion in this case wasn’t actually the best way to solve the problem as the computing time increased dramatically the further out in the series you got. I was able to code a non-recursive version of this problem, but the recursive form did leave me a little confused!

We took a break from coding in the second half of day 3 to learn about networking. This was interesting and gave a really good insight to how the internet works.

The things we learnt about included:

• Hubs & Switches
• TCP
• IP
• DNS
• Subnet masks
  

It was really useful. It gave me a basic understanding of how computers connect to each other which I’d not appreciated before. During the training, however, I felt swamped with the amount of information being passed on. About halfway I got lost so I felt that I needed to do more research. I watched the networking portion of Harvard’s CS50 course as well as a very informative video from Eli the Computer Guy. All this helped to reinforce my knowledge and I’m glad I picked them up.

Day 4

Back to coding today. We made a To Do list in Ruby, again operated through the terminal. To be honest we felt a bit anxious coming into it considering our issues with the blackjack game but we felt we did really well.

We learnt from the other groups’ code from the first exercise and made our project a lot more succinct. We were happy that our code looked sleeker and operated well. I appreciate this was an easier task than our blackjack one but we made great progress here. I was particularly happy that I managed to load and save to-do lists to file. It may be minor but it’s something I’d not done before and thought it was a pretty good feature to add!

In this time we touched on hash tables and class structures. I feel there’s a lot more for me to read up on these two topics and to practice with in future projects, but I know they’ll help me with my code massively.

Day 5

Last day of the week. We had a new project – make a text based game. Anything we wanted. This was exciting to do as we were allowed to let our imaginations run wild (within the constraints of our current knowledge!).

Our initial thought was a maze type game. I felt this was hard for us to do given our experience levels and the allotted time. We instead opted for a top trumps style game with a Star Wars theme. This was much more simplistic but gave us something we could work on. We got an MVP out quickly and iterated on it often, allowing for new features as the day went on.

Others made some great games, including:

• Connect 4
• Rock, paper, scissors
• Tic-Tac-Toe

I would have loved to have made a trading based game. When I was younger I used to play a. game called Drug Wars (pardon the topic!) where the aim was to buy/sell goods to make a profit. I wanted to make a similar trading game as I thought this could be done and was still a pretty fun game to play. So I chose to do it myself over the weekend. Look out for a blog post soon on how that went!

Thoughts on my first week

I’ve learnt so much already but obviously there’s such a long road in front of me. My new employer looks fantastic. They’re very supportive and encourage us to learn topics that interest us.  They provide access to a vast array of materials to learn from in our own time so I’m very happy I’ve made this decision to move across.

As noted above, I need to learn more about how to construct my code better. Simple things such as classes will be my first port of call and I’m sure I will get better with more practice.

I’m excited to see what my second week has in store for me!

Useful Snippets

• As a software engineer always ask yourself “Is this statement true?”
• Comments are good for planning out your code…
• …but incorrect comments are worse than no comments at all!
• When writing blocks that require a start & finish (eg) if……..end, type in the ‘end’ straight away. This is to prevent your from forgetting about it and you won’t mess up the code.
• Test your code often. It’s easier to debug little snippets of code.
• Don’t just write code from top to bottom. Break it up into smaller parts and tackle them individually.
• When dealing with loops, think about every iteration of the loop, not just the first.
• Be consistent with indentation and style. It makes life much easier!
• If you have lots of if/else statements then better off using a case statement instead.
• Sometimes when you pass in an argument to a function and modify that argument, it actually modifies a copy of that object, rather than the object itself.
• The difference between a beginner and intermediate coder is making your code more robust. Allowing for all errors and providing a more user friendly error message when they do occur.