Category: career
How to get a big break – Notes to my younger self.

How to get a big break – Notes to my younger self.

By | | Comments 0 Comment

Getting into the positive territory of my talk! A turn for the worse, ended up being a turn for the better! Why, how, this is what happened and how I got my ‘big break’.

This is a direct carry on from the previous post and is as the others have been based on my talk that was given at the Finland React JS conference. If you’ve read the previous post, it wasn’t a terribly happy ending. I did create a good number of items, but over time that one main item which was a failure ultimately meant that more work wasn’t coming through. Due to previous experiences, what I could see happening and also the fact that I was really enjoying messing around around with Adobe Flex/Actionscript I took matters into my own hands.

Direct Action

Work was drying up, getting zero direction from management, even after asking about creating work for the client that I knew they could use – after all why not give them something when I wasn’t working on anything. Nope…

So time to take matters into my own hands. I was busy doing little demos, experimenting with new libraries, new techniques, answering questions on Stack Overflow, while also reading some common questions and creating examples based on those questions. What did I do with these demos/snippets? Well I created a simple WordPress blog (yes this blog) and every now and then I’d put up my examples and source code.

This wasn’t done to get coverage, but purely to help share my knowledge. In turn my actions on sharing my knowledge allowed me to extend my knowledge. My site way back then used to be rather popular – I even made a little bit of money at it via Google ads and some free merchandise! Which was a nice bonus when you expected nothing.

The Point

What am I getting at. Well, by experimenting, keeping things small and simple allowed me to learn the intricacies of the language, learn the lifecycle of the flashplayer, find out where the memory leaked, the add-ons, as well as the latest and greatest releases. This really mattered.

In todays market, this would be like me taking the latest hooks coming out in React 18 and creating demos against each one. Comparing it to what went before. Figuring out where and when lifecycle methods were being called and why. So dig in, create the smallest of demos and tinker around.

The Breakthrough

First place I worked while in London

So not to far down the line, the inevitable happened and redundant once more. Even though it wasn’t the first time and not a huge surprise, it doesn’t make it any easier. While hunting for jobs, there were zero in my local area. Quite a few down south in London and in the end I got hired by a high end consultancy company who worked with a range of leading banks.

While I can’t say for sure why they exaclty hired me, I know my blog was a big selling point of my coding abilities (yes, it’s very much lapsed now – this was around 15 years ago) and when it came to the interview as I now knew the code framework inside and out, then that certainly got me through multiple stages in the interviews.

In the end, each week I’d fly to London on the Monday morning, and fly back home on the Friday. I was renting a place in London while there and even with those extra expenses I was still coming home with way more than I’d ever done in the past – not to mention it was great fun being involved in such a large project. But there was a cost, but that’s for another story…

Now that I’d entered the contract market, that gave the outlook on doing work a completely different feel. Again that’s for anther story. Something that for those that can, I’d certainly recommend as long as you are aware of it’s drawbacks.

Gotcha
Works on my machine! Notes to my younger self.

Works on my machine! Notes to my younger self.

By | | Comments 0 Comment

Thanks for that, good to know – Works on my machine! It’s such a common issue, hey lets ship your machine then 😁 How did we get to this situation. A lack of Ownership & Trust, that’s what! Part 3 from my series on the talk I gave at React JS/Finland. You can watch the talk directly here – https://youtu.be/zE8PDM_7xoQ?t=11404 This part covers my discovery that coding, isn’t always about coding. Read on…


For this one, I need to set the scene to highlight what I did and why it was wrong. Being more experienced now, I certainly wouldn’t have done what I did all those years ago.

The story

I was in a new role, one the main reasons for me being in that role was to fix an application that someone else had created that wasn’t functional. This application was created by a web developer who hadn’t written any web applications before. The process of designing/creating a web page is drastically different to creating a web application.

So I come in to this role, get shown the application, asked my views on it and how to improve it. After a while digging into it and running it, my conclusion was that I needed to re-write it from scratch. So that’s what I said. Like would I not say that – after all that was what was needed!

The answer to my request was a No. As it was my manager that said no (also the same person that wrote it) I was OK, fine I’ll get to work with trying to fix the issues. And yes I did improve it, I got it down from rendering a view in around 2 minutes, to being usable in under a second! I was like brilliant! Every time you make a large leap forward in getting that time down was like a huge win. So all was good – yeah?

No it wasn’t all good

I’d gotten the app down to an acceptable speed, pushed to production, then got the client to use it. They were still not happy? Why on earth were they not happy. It worked just fine (on my machine!). Anyway after a call, I go up to the clients office (for the first time), and within moments of being in the office it was clear why they still had issues. Their machines were archaic, super slow, well out of date machines. There was next to nothing left to optimise now, not a great situation.

What went wrong?

Firstly I should have understood that even though the guy that created the application knew it was rubbish, it was still his rubbish. It was his personal thing and as such someone coming in and suggesting it be started from scratch wasn’t going to fly. People don’t like to be corrected, even when they know that they are wrong. It’s human nature. You have to work at providing the evidence in a clear and balanced manner. Not just – it needs scrapped. Must understand the human element of coding.

Secondly, I should have found out what the client wanted. I should have found out what type of system the user was going to use the application on. After all the first pass of the app was out. The client may have loved it’s look and feel, or equally they could have hated it. Who knew? Not me anyway, and no one else seemed to care either.

STOP

Before doing any large scale of work, you need to stop. Never jump straight into the code, you will more often than not regret it in the long run. Unless your piece of work is for something short lived then you need to plan. I should have done an analysis of what was wrong with the existing app. The cost of fixing it, the timescales required to fix it, the risks associated with fixing it etc. On the other hand I should have done the same, but the risks etc for creating it from scratch using a new framework suitable for the requirements of the client.

With the existing, but broken app being considered a prototype and a stepping stone to making a better application, along with the raw data on risks/benefits etc given and shown to management (not just direct manager), then it would have been much more likely to have been successful when I suggested it needed to be redone.

Even on the basic needs that the users machine and monitors were so outdated, they needed a different solution. It would have cost the client a heck of a lot less to upgrade their PC’s and monitors, but that wasn’t an option. Why I’ll never know. Well I do know – but the reason made no sense, not a bit of it.

Key learnings

Ownership/Trust – I should have trusted in my ability to re-write from scratch the app to make it better. I knew I could, but when it came down to it I still didn’t have the belief to force my opinion to re-write it. Documenting the risks/benefits would have given that mental safety net, as carrying on with the old one wasn’t a viable solution at all.

Know your customer/client – Learn what the client has and what they use. Far too often I hear, it works on my machine. It needs to work on the clients machine.

Stop – Think about why you are doing something, what’s being planned, where is the future of the code going to be.
Life Sucks! Notes To My Younger Self.

Life Sucks! Notes To My Younger Self.

By | | Comments 0 Comment

As a developer, especially as a junior developer things can take a turn for the worse and you probably won’t have seen the blinding obvious coming right at you… Life can seem to suck at times, but like everything, it depends what you take from it.

This is part 2 from the React JS/Finland talk that I had the opportunity to give on the 14th Sep 2022 (https://youtu.be/zE8PDM_7xoQ?t=11416). This sections goes to show that even though I had what seemed like the ideal first job, it really wasn’t.

My first role was to help with the creation of this game! 😎

First Job

So after a year of job hunting, I got my first role in a AAA games company. Exciting – yes, very much so. A large company with 3 separate games being made (in conjunction with other studios). Each team had around 30+ people in it. The place had it’s own arcade booths, we got fresh fruit every day, people would play online games during lunch. Variety of the latest consoles laying around the office. What wasn’t their to like!

Downhill

So in the door and on the whole, people were busy, very busy. They had headphones on and coding away – in the zone so to speak. I recall being shown a list of literally 1000’s of bugs that needed fixing before the game was suitable for release. Of course in those days, you couldn’t update over the internet. What shipped on the disk was what shipped into peoples homes and of course if the game didn’t make the Christmas deadlines for being created that was not a good thing!

So with everyone being so busy, support was next to nothing. I only recall a single meeting with management to see how things were going, and that was early enough for me not to really give a good opinion in it. Recall many times scratching my head, wondering what was happening with the code, but everyone had headphones on and ‘in the zone’. As a junior, certainly didn’t feel like I could/should be interrupting the other dev’s to ask ‘silly’ questions. None of the senior dev’s would ask how I was going, or if I required assistance.

Could it get worse?

Yes it could! Due to the main team being in the states (we were based in Scotland) and infrastructure issues (20 years ago, transferring 2-3GB of data nightly was problematic at best) the whole team had to fly out to the states in order to complete the game on time. But I was about to get married, so I couldn’t go…

So now I was working US hours, essentially on my own in a mainly empty office. But I was getting free food/dinner as I was working late, and I was still doing some dev work, just nothing really meaningful. Trying being a jnr in a code base many 1000’s times bigger than anything your experienced from university, it’s not documented in any way, PR’s and unit tests were not a thing, even source control was very sketchy.

Coasting

But did I see any of the above as an issue – NOPE! Why not, well I just didn’t have the experience. I thought once the team get back from the States, I’d get properly into the code, be able to ask questions, do some learning etc.

I knew things weren’t great, but at the back of my head, I was sure it would pan out and be fine!

Did that happen, nope… Redundant soon after Christmas 😢

Hard lessons

Looking back it was clear from the start that the company wasn’t interested in me. I was a number to allow them to get what they wanted. A decent company that hires a junior dev will never just leave them to flounder on their own. They will mentor and guide them. The simple fact that there was zero support was a simple and clear warning. So if this is your experience right now or at some point in the future – what to do?

You need to invest in yourself. They will not care, so you have to make the time to pull apart the code base. Dig into it framework, put tests around items and generally if anything looks different/new learn why. This is hard, but take it in small chunks. Create a small app and slowly copy parts of the larger code base into it to get them working in a context you know and control.

Managers

Always support a junior developer. If you happen to be a workplace that loves music to code (most of us do). Then make sure that you take off those headphones to ask how it’s going. Don’t just accept a – ‘yeah all good’ response. It’s easy to do so, as you’re busy and if they say they’re fine, then great, you can carry on with your important jobs… Make sure that they are good. Junior dev’s are the people that come with energy, enthusiasm, new ideas etc, you need to channel that into something meaningful.

As an aside, over the years I feel that the gain you think you get from being in the zone with headphones on and banging out code – is actually a downside. Yes being focused is great, but often being out of reach regularly from your fellow developers is not good. One place I worked got the balance right, but that will be explained in part 4 of my talk review.

Junior devs

You can’t learn effectively in isolation. You need a team around you, you need a variety of experience. If that isn’t there then it’s time to look for an exit strategy. Be preparing your CV, go looking to see who’s looking to hire etc. Get preparing small demos, learn the usual interview questions as so on.

At the same time you should and need to be more vocal in asking questions. Never stop asking questions, don’t keep asking the same questions, but do keep asking questions. It’s not only good for you to learn, but at the same time those you’re asking the question off will also learn. If something isn’t clear – is it a good bit of code? If it isn’t, then perhaps it needs refactored. Sometimes it’s good to discuss an area of code that hasn’t been touched in years as you’ll have forgotten it’s purpose. Either way it’s not a one way street when you ask questions. So as a senior developer, I welcome questions.

React Finland Kenneth Sutherland overview
Landing your first job! Notes to my younger self.

Landing your first job! Notes to my younger self.

By | | Comments 0 Comment

First ever conference talk complete! Something that was well worth the effort to create. Anyway I thought it would be great to put down my talk into words. I’ll put a post up per topic that was covered during my talk. I’ve yet to listen to my own talk, although I know I rattled through it faster than I wanted 🙂 So here I’ll expand what was in my head as well as some of the areas that I didn’t have enough time to delve into.

For those that didn’t attend or watch the React JS Finland conference (https://youtu.be/zE8PDM_7xoQ?t=11399) – it was great. Such a warm and welcoming bunch of people. And some of the people there are just amazing and super friendly. Helsinki may not seem like place to go – but I highly recommend it. The developer community feels like it’s really big and cooperative.

Getting started

This was my first point and the main jist of it is – without work experience how to do you get that experience so that someone hires you? This is something I didn’t do before I got a job, although over my early years in various jobs, I did things like this – which seriously helped me get more advanced roles.

Perhaps out of this section, the one thing I didn’t have time to mention was that I’ve seen over the years, that those who while at university (or similar) are able to get some kind of internship or summer time work experience (even if unpaid/helping charities etc) developing software. They are much more likely to be hired first.

While this perhaps seems a little unfair, as many can’t afford to work for free or next to nothing, life isn’t fair. Which is why you need to put the effort into the next part if you didn’t or couldn’t get work experience while learning at the same time.

View from the tower in the conference centre.

Motivation & Ideas

Two key things will hold you back, motivation and a good idea. You can look online and I’ve seen so many to-do lists, for example. While these are just fine for a tutorial, they aren’t the kind of thing that will excite you to keep programming for hours and days on end.

Too that end you’ll need to find yourself a good idea. So where to get that from? Well, in the past picking an item from one of your hobbies or interests. You will no doubt find that someone else has created something else that’s very similar, but don’t let that put you off. As you develop YOUR idea, you will end up adding your own twist to it.

Mental rewards

Whiteboard, sticky notes and pens. Why? Some people in the software world don’t do this (not even electronically). These people have been developing for a good while and when you interview them you can tell that what they do isn’t structured/well planned as it could be. Yes it’s not as simple as get a whiteboard, but it’s a mindset and the Jira/whiteboard board needs to be part of it. So what should you do?

Well, you have your idea/subject. It needs broken down into a few big tasks ‘epics’, then each of those needs to be broken down into individual units/stories. Those need prioritised. This is your first business take away. You will learn to prioritise them and now you have a concrete example to talk about in an interview (that bit is super important). When you do work on your tasks, work on them one by one. Only ever do one at a time! If you complete a story and something comes out of it, maybe just a ‘tiny’ task, you think I’ll just stick it onto this task. DON’T! Create a new task and do it right after, but don’t join the two together.

Buy yourself a physical whiteboard

The whiteboard

This is where the whiteboard/sticky notes come in. Put up enough to complete an actionable item/epic. Some of these many be learning tasks (spikes) as well as actual coding tasks. As an example you may need to investigate bundling/build tools. Task 1 could be to find out the top 3-5 tools available. You can have new tasks per tool. You’d create a ticket per tool and that will involve doing a small demo per tool. Finally you’d have a ticket to evaluate each one against the others. So a simple find a suitable build/bundler for your idea may well have 7 unique tasks/stories.

The act of progressing a ticket from ready for work, all the way along to done/released is a concept that although simple will trigger those mental rewards. You’ve done something! Great! The smaller the task the more tasks you can get done. There is nothing more demoralising that being stuck on the same task for days. If this is being done during a few spare hours, the smaller you can make the tasks the more likely you are to complete them. A large task requires much more time to get the task into your head. Sometimes by the time it’s in your head, and you’re flowing, the time is up. Keep them small.

There is a whole heap of knowledge out there on Agile (for example https://www.atatus.com/glossary/agile-methodology/), this post isn’t to teach you that, but to highlight doing it is very rewarding.

Takeaways

  • Get an idea for a project from your hobbies/interests.
  • Create tasks that are as small as you can make them.
  • Only ever do one task at a time.
  • Prioritise tasks to get something out/completed.
  • Think about why you are doing something. As in why is task A more important than task B.
  • You will be learning new techniques, think about how you implement such learnings, how to enhance your learnings.
  • Think about your flow, how to you improve it. Did you do anything that suited your style of code/learning.

Coding is as much about the process of writing code, as it about writing the actual code. Can you describe that?

Cycles of Life – A Cautionary Tale!

Cycles of Life – A Cautionary Tale!

By | | Comments 0 Comment
“Those who do not learn from history are doomed to repeat it.” (George Santayana)

Having been around the software world for more than a few years you see the same cycles time and again. That rather old phrase of “those who do not learn from history are doomed to repeat it.” comes to mind.
Teams grow and shrink and all going well grow again, prepare for it, so you can mange it.

More appropriately this should be called –
Cycles of Life a Software Team – A Cautionary Tale!

Software and the teams around them are on the whole very versatile and nothing is really doomed. It will probably just slow (hugely) you down or cost someone a shed load of cash to sort out 😛

We’re entering a new year, all going well your team is looking forward to growing, so keep the following in mind!
When you know what to look for then hopefully you can do something about it.

Team growth

  • How big is your overall team?
  • How big are the individual teams within the overall team?
  • How quickly has the team grown?
  • How quickly do you want it to grow?

These questions are key to figure out what will happen. The following has happened on more than one occasion and in completely different teams.

How quickly have you grown?

You are an awesome start up, your idea is a massive hit with the investors, it’s time to grow, grow, grow!
BRILLIANT!

Here’s the thing, the software industry has a HUGE staff churn rate. Even the best companies will struggle to keep staff for a long time. You must be prepared for this.

Your team has grown from 10 to 30, maybe even 50+ in a very short period. The buzz around you encourages others to join. Nothing better than a greenfield project to work on.

Here’s the rub, all those new staff will be very likely to leave in very quick succession after 18-30 months, once the first goes. Sure some will stay on longer, but also some of the core team may also leave. Through no fault in the team or the project, but just to go experience something else. This is completely normal in software teams. Especially once a senior long standing member goes – look and plan immediately for other to leave.
There is virtually nothing you can do to stop the flow, just accept it will happen and deal with it.

So what!

I’ve hired before, I can hire again. It’s all fine. It’s just a coupe of people.
If it’s not already clear, the short life span for a developer in one place, means if you hire lots in quick succession, they will leave in the same fashion. Unless you are still actively growing, you’re in for a bump!

It’s the wave effect

This point in time, you are no longer a start up, you no longer have a greenfield project, you no longer have the ability to just hire another dozen developers.
Also notice and look for a bit of a build up, like a wave really. Their is a feeling of general minor grumblings. Nothing major, but then once someone goes, curiosity and a question of ‘is it greener over there’ without something to cancel out these thoughts means that inertia to leaving is broken.

Managers, why?

I have to admit failing to understand this point, but senior management never wish to replace a member of staff leaving right away. They seem to like the thoughts of, well it’s only 1 person out of 40. We’ll make do without them.

Sure enough, the team does, it’s only 1 person. But that wave is building up in the rest of the team. Then the 2nd, 3rd go. By which time those leaving encourage others to go, maybe even taking there mates with them.

Know your market!

Depending on how quickly you can hire. Every market is different and you need to know where you are.

  • Maybe your company is in a software hub of a city and hiring isn’t an issue.
  • Maybe your company is in a software hub, but part of a structure that makes hiring a labourious process
  • Maybe your company is in a remote area as far as getting a pool of developers is concerned

Essentially how quickly can you get people back in that door. Are you ready to take staff out of their day jobs, plough through CV’s, then do a fair amount of hand holding to get the new staff up to speed?

Even in the best situation where your company has a low bureaucratic process for hiring, you develop in a good cultural hub/city and you have the finances to pay a potentially larger staff bill (generally a case of the best way to get a raise is to move on). You will have to take team members of active duty for transitioning in new staff.

Recommendations

  • Plan for people leaving – it will happen.
    If you quickly back fill a space, it will reduce the desire of others to look around. Anything fresh is a good thing, even a new face aids.
  • When you know it will take a 3 month minimum period to hire someone, never leave it for 3 or more people to leave. If you do then then even if you start hiring, those seeds of change will have sunk in already.
    Really if 3 people have left and you’ve not started looking, then you’re guaranteed that others will be on the way out (and in quick succession too, esp if they we’re all hired within a similar time frame).
  • Do not ignore unhappy staff – they’ll just leave quicker.
    You may well, and quite possibly completely disagree with your staff members reasons for being unhappy, but it’s often an open market.
    Do you want them to stay or not? If not, plan for them to go. If they stay, great, if not, then you are ready.
  • Ideally always look to the weaker area in the team. Have a range of CV’s coming in and keep the top ones for reference later. If you have potentials ready to roll, then anything you can do to reduce a gap is crucial.
  • Most importantly it can take a number of months to gain enough domain knowledge. The longer you leave it to re-hire folk,this will increase the risk of crucial knowledge being lost, which will likely lead to a major issue that could be solved quickly, but only if the domain knowledge was retained.

Finally…

Stop focusing on just the technical. You need to be a team, personally as much as just work colleagues. This is SUPER hard, sometimes you want nothing more than to just do the work and go, but…

  • The grass isn’t always greener on the other side! So keeping your staff happy, when they go, they will spread the good knowledge and practices of your team.
    This can even aid in then getting new staff in, but it can also mean that staff can and will come back! Having been in many different companies, the programming world can feel like small circles at times. Just because someone left doesn’t mean they won’t wish to come back.
Notes to my younger self – Dark Clouds!

Notes to my younger self – Dark Clouds!

By | | Comments 0 Comment

Welcome to part four in my series of what I’d like to tell myself if I had the chance to pop back a few years. In part 3 I’d essentially been forced into looking for another role as I could see the dark clouds surrounding the job I was currently in, funding was obviously an issue. It was not rocket science to know it wasn’t going to be far off that if I didn’t jump I’d be pushed.

Things were looking very gloomy!

Moving forward

What the heck was going on!

  • Left university
  • Non programming job
  • Dev Job – in name only
  • Non programming job
  • Fun programming job, but as stable as a tower made of jelly

Having now been in the world of development for almost 20 years, so it’s easy for me to say there will be something else to come along. At the time it wasn’t so. What can you do? What could I have done better?

You’ll read elsewhere in feel good blogs or twitter snippets that no one needs to extra hours, that a role should never require lots of extra effort and if it does then you should leave. But in reality, this is not true. It would be awesome if it was, but it isn’t. Certainly not in the lower ends of the development market.

In this instance I was fortunate to find another role close by. I had time to look, which took a while but when that opportunity came up I made sure to study for the interview. It was a Java role, I really disliked Java, I didn’t know Java (J2ME is not the same), but somehow I passed the interview and various tests they gave 😎. Then after getting the role, I actually found the role wasn’t really Java! RESULT. It was a new language, and what’s more I actually liked it.

Try different languages, they are not all the same! You may find your niche in an area that you hadn’t seen before.

Few years later, in very similar circumstances, had I learned from the previous lessons? No, actually I hadn’t… 🤦‍♂️Did I see the company in trouble, nope. Should I have? Yes. Was I prepared for what was to come? Actually I was!

What is KEY?

Experience! But what if you do not have any, you need to get yourself some!

Shortly before my 3rd enforced job move I had started up my own blog. I started this up before I knew my job was in trouble. Why did I do this. Was it to get followers, fame, status or fortune? Nope.

I wanted to put up some examples, so that when I got stuck I could look at my own code and help myself and if I discovered something that I had issues finding online then I’d put up the solution for that as well to aid others. I spent a fair amount of time doing this. Actually when I was working, but I didn’t have any work, I’d be experimenting with code. Creating small chunks, cool visualisations. Testing the latest, greatest libraries and blogging about them.

This was KEY to what was about to become my best years as a developer!

After being made redundant, I had to get into the contract market. My blog was such a selling point to anyone wanting to hire me (it’s changed a lot since then, don’t even think most of it will work anymore – written in Flex/Actionscript).

Contracting was a completely different ballgame. But it was great. So always be positive 😃 Even in the adversity of what was happening, I had some of the most wonderful experiences, all because I was made redundant (again) and the only places I could work were many miles away.

Take away

This is what I’d like myself and others to take away. Enjoy your work. Highlight your work. Take time to get your foot on that ladder, and make sure it stays there. In the early years you will need to invest in yourself. If not directly with your employer, you will need to spend those extra hours doing research and finding new items, probably in your own time. This WILL set you up in a good way for when trouble hits – and it does!

So go, have a rummage in your head. What problems do you see around you, what are your hobbies, do your friends, or yourself grumble about structures etc. Look for small areas you could improve something. Maybe someone has already solved it. Does that mean you shouldn’t? No.
Just give it a go, but keep it small and simple or you will never finish.

Give it time, and the sun will come out 🙂

Next…

Mentioned last time I’d share my experiences of team cohesiveness and being part of a team as it’s fairly crucial in ways I did not understand in my early years. But this post took a different turn. Watch this space for the next post, and I’ll see if I can cover it then…

Games
Notes to my younger self – Gaming comes to an end

Notes to my younger self – Gaming comes to an end

By | | Comments 0 Comment

Welcome to part 3 of my guide and ramblings that I’d like to tell myself if I had a time machine. This theme was to be the basis of a talk I was going to give at the React Finland JS 2020 conference – until Covid 19 came along and tore up everyone’s plans for 2020.

Thanks (sign as you leave conference hall in Helsinki)

In my previous posts (part 1, and part 2) I mentioned that I started of my developer career in the games sector. This first role was short lived for the given reasons. So after a while of looking for a second role in the area I wanted to work, a position came along at a small start up. They were creating mobile phone games. Yeah!

For most who think about mobile phone games now you’ll probably be thinking of the literately 1000’s of simple games with the really annoying adverts that appear every 30 seconds. Well this isn’t that! This was back when the most popular game would have been Snake

New Nokia 3310 to feature colour display, 'Snake' and ...

Applications/games where being written in J2ME (Java 2 Micro Edition) and I of course had zero experience with J2ME. At the time my knowledge was C/C++ (any recruiters reading this, please stop sending requests for C++ jobs! I’ve not touched it in over 15 years!).

TIP

Be honest! I wasn’t hired because I faked my CV, or because I said I could write J2ME. I was hired, believe it or not because of my ‘experience’ in the games industry.

If you are a fit for the company then they will hire you. Good programming skills are transferable between languages – it’s just different syntax. Team cohesiveness is as key to work as how you think and code.

What happened?

So this company was small and if you’ve ever worked in a start up, then they can be a tad unconventional. Two developers, an artist, a ‘business guy’ and now myself in a small office. It was OK, not great, but OK.

My eyes were a bit more open going into this job. I enjoyed my coding, which is a key component for any developer. You must be able to enjoy it, not always, but at least some of the time. If you can’t enjoy writing code, then as a developer I’d say you are in the wrong job.

It’s a skill, almost an art form. Bringing logic, processes, instructions together to create something beautiful and useful. Code is there to aid others. The fun is what makes you get into ‘the zone’, spend longer than you should at your computer, even solve your coding issues while you sleep, but that’s the way it goes. You can’t call yourself a developer unless you’ve solved something in a dream – surely!!! 😎

One of the other coders at this start up was also a chef, and this comes to mind –

Code can become heated. If you don’t enjoy coding then you may be best looking elsewhere.

Week in, week out I’d be writing code for devices that had extreme limitations. Our games were ‘full colour’, and although it was written with Java (write once, run everywhere…) getting it to run on everything was far from simple. No rule will cover 100%, even for Java. Different phones would even use the same enum for different purposes! At the same time as trying to get a game out the door, the ‘business guy’ had grand ideas of a game with lots of mini games inside it.

We were struggling to get a single game out. Let alone a game with mini-games.

!Important

Stop reaching for the stars! Get something out there, get it out fast. As a developer it will never be perfect, NEVER!

If you have to hard code something because creating the flow to not have it hard coded would take a week or more, then yes go for it. Once your product is out, then you can tweak it.

We didn’t need a level editor, if the game sold 10,000’s and we ended up making dozen’s of clones then yes. But it didn’t.

The company went bust, you MUST get Minimal Viable Products (MVP) out the door. That’s the bread and butter. That’s why we do agile. Every two weeks you should be able to deliver something.

Bigger companies can absorb the costs of delays to releases, while it can kill a smaller one. Also getting something for end users to play with will change your road map – for the better.

What is the minimum required for this to be of use?

This question should be the first thing you ask for each user story/journey.

As I write this, I can’t stress this enough. It is most certainly one of the top items I’d tell my younger self. Just stop tweaking it, stop wanting to add that one extra feature to make the users journey so much easier! How do you know it will, do you have any users? Do you have any metrics on the applications use?
Even as I create items now for users, we had an unpolished feature in an app. Functional yes, but it had a couple of minor flaws that we knew about. Did we release it – YES.

The next week an issue arose and we needed that tool. Without it we’d have been in trouble. Did the minor flaws make a difference – No.

Get it out into the wild!

End Game of Games

This was not a big company, we did in the end get a game out. But by the time we did, the writing was already on the wall. The game was actually a great wee game. MotoX in colour, on prehistoric mobile phones, it ran really well. The game was cloned and re-skinned quickly to help create another game (Jet Ski). Exact same, but the different look and feel was very good. Ultimately this was too late. Had I have known more, had more influence I could have helped saved this company – although I think that would have been hard due to other issues within the small team. But it could have been with knowledge.

In the end I was already applying for other positions and not in the games sector. Too many games programmers I knew were losing there jobs locally, too many were having to work crazy hours to keep there positions. People were sleeping at work and so on. As much as I enjoyed coding, this was not the way forward. I needed more stability.

Learnings

  • Don’t be afraid to try something new
  • Be honest – always
  • Think of the user and get something for them to try ASAP
  • Be part of ‘the team’ (going to cover this in detail in another post as it’s super important). I failed at this until at least my first contracting role. Few years after the above role ended.
  • Just because someone is more senior, does not mean they are correct. Challenge, but challenge with knowledge.
  • Working silly hours, working long hours, working for nothing (yes some at this company did at times). These are all alarm bells. If you can’t change these culture items – get out.

Next…

I’ve mentioned team cohesiveness and being part of a team a few times now in this series, but not really covered it. This is crucial in ways I did not understand in my early years. Watch this space for the next post.

What would I teach myself. My first job

What would I teach myself. My first job

By | | Comments 0 Comment

Following on from my previous post. This week I should be giving a talk in Helsinki, but I can’t due to lockdown ☹. So I’m going to put some of my thoughts, memories, learning’s down into my blog. Hopefully at some point in the future I’ll be able to do this in person.

Vantaa (North side of Helsinki)

First job

So I’d gained my degree in computer games, spent quite a while refining my demo 3D game for the playstation, navigated the interview (thankfully I’d learned from my disaster with GTA makers Rockstart North) and gained my first programming role since leaving university.

My game was similar to Wipeout (above image), but without many of the fancy graphics or multiple weapons!

I was happy, excited and yet at the same time the warning signs where there. But I didn’t have the experience to see what was actually happening.

1st Warning Sign

I had to cancel my honeymoon! Yes I was in the process of getting married, booked and organised everything and as is the normal process after being married you go away for a few weeks. It was all planned, 3 weeks away, but in order to get the job I had to agree to cancel it and drop it down to 1 week!
Of course being my first role I was all to eager. I pushed all our holiday plans back from Aug to Jan.

Why was this a warning? If a place is hiring a junior/graduate developer and they need them so desperately they can’t take a pre-planned holiday, then there is a MAJOR MAJOR issue going on.
(As much as I thought my skills were the best, they obviously were not, as any senior dev will attest to)

2nd Warning Sign

Again as a junior I did not get this, but having now been in many different organisations, training doesn’t stop when you leave uni. Training, mentoring, continual learning must be the foundation of any established organisation taking on new programmers.

Did my new employers give me any? Nope, no plan, nothing. I got a desk and pointed in the direction of a code repo and a database/spreadsheet of bugs. Thousands of them!

Did anyone help me, do some pairing, give me some tips etc. Again nope! When I look back, it was so clear this place was doomed.

3rd Warning Sign

Where is my team? So the company was based in Scotland, they were making the multiplayer portion for a AAA console game for EA who were based in the States. Christmas deadlines where looming. This was back in the early 2000’s – getting GB’s of data from the States to Scotland and back each day was painfully slow. So the entire team where flown out to LA – except for me and one other – for months.
The office did have 2 other games being made, so I wasn’t entirely on my own. But the other guy on the same project I was on that I can remember was an artist. Due to restrictions on IP, NDA’s etc we had next to no interactions with the other teams. No chance for learning or gaining experience.

Could it have been worse?

Quite frankly as a junior developer it couldn’t have been worse! Other than getting a good wage, some nice benefits (worked evenings to tie up with the guys in the States – so unlimited pizza each night) and not knowing any better, I expected that once the crazy release time was over things would improve. So I coasted along, not doing very much, frankly I hadn’t a clue what I was doing and no one really to ask.

Later I found out they didn’t care, for them I was just a number, head count so they didn’t breach there contract!

What happened next?

January came around, the entire team were still away. The game had been released and the dust had settled. I went away on my delayed honeymoon for a couple of weeks. All was well – I thought. Expected to have the team come back soon, get into a new project, start fresh, learn some code etc. Nope, nope and a big fat get lost.

Arrived at our house after a great holiday, to a letter which spoke of issues and blah blah blah. That was it, game over. No longer required!
Long story short, a few months after I was let go, the company collapsed. Looking back, really not surprised in the slightest.

Learnings

Would I still have taken the job knowing the future? Yes.
Was there anything I could have done differently? Yes and no.

Experience is top dog, so if you can gain anything then go for it. But do not be afraid to keep looking even if you have just started a job. If you have time, spend that time creating and experimenting on what you enjoy.
I struggled for a long time not knowing what to do. Without having people physically near it was even harder to ask questions, but I should have. Keep asking, asking asking!
Expectation entirely from myself was that I should have known what to do, asking ‘simple’ questions seemed wrong. But I know now I was wrong not to ask. Ultimately it would have made zero difference to the company, but it would have made my time better. I would have been more productive, while I’d have gained more valuable insight which would then go on to aid in future positions.

Top points

  • Ask, ask and ask some more.
  • If you have time, work on personal items you enjoy (this will let you get a new job)
  • You are valuable, even at junior level. If they are not investing in you, you are being used. Prepare to LEAVE.
  • Do not be fooled by gimmicks such as games machines, free food & fruit, playing LAN games during lunch etc! These are great and may seal the deal to keep you in a job you enjoy, but if the core (investment in you) isn’t there, these are not worth it.

This post has gone on a bit longer than I expected. So I’ll continue the learning’s from my 2nd job (and last) in the games industry in the next post. Plus what I went into after games.

Vanhankaupunginkoski, Helsinki
What would I teach myself?

What would I teach myself?

By | | Comments 0 Comment

I’m sad right now. Why?
Well many months ago, when looking forward to this week coming, I expected to be getting myself all worked up. Tonnes of nerves, excitement, anticipation etc. Yes I was meant to be at the seriously good React Finland Conference, doing my first talk!

But, as with everything right now, Covid-19 is putting the best laid plans to the side. Off course all going well I’ll get back to Helsinki another time. Beautiful city and having been twice already I’ve got some great memories already. Anyway I digress…

View from bridge in Helsinki
View from one of the bridges in Helsinki

“Notes to my younger self “

Yes that was the title of my talk – “Notes to my younger self “. So what exactly would I try to teach myself if I had the chance?

Abstract –

Want to hear about getting the most out of the company you are in, whether it’s a dead end job or perhaps the company are on the brink of sinking into oblivion? Maybe you’ve hit the apparent jackpot and are working in the most fantastic start up – is it though?
It’s also about you! Listen to this talk and hear real life lessons on why Monday mornings are not painful, but are instead something that can be looked forward to.
And of course the code, all those things I’ve done or not done over the years – would I do it all again the same? No!

To much there for a single post, so I’ll see if I can break them up into various posts.

Where to start???

Context is king. So where have I gained my knowledge from? Here is a super brief outline.

  • First 9 years of being a developer – 12 companies.
    • First few were permanent roles, later ones were as a contractor
  • Worked in games industry, creative and business sectors
  • Been in tiny start ups, and huge multi million pound teams
  • Had privilege to work all over the UK and further (not a fan of the sun, but warm countries in winter, yeah I’ll take that again 👍)
  • Last 8 years, been in one company, with the ability to swap teams (essentially new job, but with same employer)

The Start

I’m going to go back to a point where I wasn’t even thinking about work!
This doesn’t matter whether you are self learning, evening courses, formal university or other means to learn to code. Find something you enjoy, make it your pet project, create it, develop it and use it for your CV.

This will be your best friend when you go looking for a job. If I was to interview two people and one had a demo and a degree (lets say a 2.1) and someone else only had a degree, but it was a 1st. Who’d I hire? The one with the demo (providing it was good 😉).

Why? Enthusiasm and a passion will trump pure head knowledge any day. If I can see your code, I can see how you think and how well you’ll fit into a team. Coding more often than not requires team work. Working on your own, being the sole developer has it’s place, but on anything substantial you’ll have to share responsibility.

For me, I created a 3D racing game for the playstation (yes this was almost 20 years ago now). It got me a number of interviews with games companies. I can still recall my first ever interview, with Rockstar North – for a role with creating GTA! Man did I screw that interview up!!! That’s for another post! Still it was a learning experience 😎

TIP – avoid super clever code

You’ve spent two days solving a problem, you’ve been in the zone and created a masterpiece, it’s even got multiple levels of recursion in it, so elegant you want to frame it.

Now you’ve solved it – change it! Clever code, or more to the point masterpiece code, no one will be able to debug it or follow it, other than you (only after getting back into the ‘zone’).

This is why if you are one of those really clever coders that can name and use ever pattern under the sun, think about those that will follow. It’s a team effort, code must be readable/maintainable. If it’s such a masterpiece then highly unlikely to be either of these things.

We’ve all been there and we can be proud of our creations, at the time the code makes complete sense. But pull your colleague over and get them to scan it. How many attempts did it take them to understand, if at all without you telling them what each part does?

I’ve done it before, had a senior dev come over and polity tell me to change it. Was I annoyed – yes a wee bit. Was he right? Yes, completely.
Creating the ‘masterpiece’ wasn’t a waste of time though. It will give you a deep understanding of the issues and as in my case the refactor was a fairly painless exercise. End result, clean maintainable code.

Getting back to your personal project for demo purposes. Test Test Test.
It’s the phase of our times just now, but it applies to code as well as covid! Maintainable code will be tested, can you write tests? Show you can. Take time to test, doing so will get you a job and a good job at that.

If an employer isn’t interested in testing, you are going to be in for a rough role. Beggars can’t be choosers with your first job, but you’re going to want to leave there pronto.

Next post

I’ll cover my experience in my first role, which was very much less than ideal for a range of reasons. Enjoyable and not at the same time. Find out more here