Tag: games

Notes to my younger self – Gaming comes to an end

Notes to my younger self – Gaming comes to an end

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.