This is not actually my first post, but I decided to scrap my past publications because the blog really hadn’t a clear purpose or direction, but now I’ve got it, so I wanted to start fresh.
I’ve recently started working at this really cool startup where minds are fresh, people are good, and developing your heart always wins (because our clients are also good people). Two things that came out of working for them:
- I have fun with my job now. Like, “fun” fun. Learning new technology now is as exciting as finding a new coffee shop that I like and want to keep going back to every once in a while. In that spirit, There will be more “tech that I explored recently” posts coming.
- I work at the client work division, but the division next door makes games (and it’s great stuff and we’ve got some cute mascots but I digress). I’ve been wanting to get into game dev for a while now, but I overcomplicated my own plans and I never moved forward with them. After chatting with our game director a few times, I got some tips that changed my perspective on “planning a dev/game journey”.
The shortest thing – and the biggest tip I could get – our Game Director told me is that you can make long plans about what you’d like to learn “before you actually get serious”, but that ends up also being procrastination. This is because what you (and teams that hire you) really want is an actual history of releases in your portfolio, and not an encyclopedia of concepts you only know in theory.
You can spend months learning A and B to get some confidence, but the next project will require Z of you and you’ll once again go back to the “I know nothing” stage. Facing something completely unknown in a new project is completely fine, so there’s no need to build confidence beforehand. Also, in CV terms, “I planned and released one crappy app in three months” >> “I spent years learning Unity from tutorials”. This means you need to set your mind on one thing to develop – and just do it.
Another thing that stuck with me though is that you have to be practical about it. You can set a goal and spend years working on your super game and actually release it – what game teams will see in the CV/interview will be “a guy who is good at working by himself”, and that’s a blocker when hiring people.
Plain and simple – personal projects need to be fun, short, releasable and have a codebase that shows “I can do this in a team too”.
With that in mind, this blog is now just for fun. “Found this new tech so I tested it”. “Decided to make this crappy game so this is my dev log”. Let’s go.