Tag: career

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