This page is just for me to talk about programming and game dev things that I am doing that aren't necessarily whole projects in a slightly less formal context.
It's a bit of an outlet to talk about some things I come across in the process that won't necessarily constitute a whole page and if you are interested in making some of the things I am working on you might learn something.  Please Enjoy.😀

Over the course of the last couple of months I have finished my higher education and gotten employed in my first game programming job! This of course is pretty exciting, it is exciting to see how bigger companies make professional products, and as is the case in a lot of jobs I have learnt more in the last month or so than the majority of my time in education.

For those who are currently in the job hunt for their first game dev job or will be on the hunt soon, I wish you the best of luck! The game development industry is full of competition but also full of opportunities.
For those lucky enough to be starting their first positions soon, I would like to give some comforting words, it will be overwhelming and it will be a lot to learn  and you will feel shitty and it could even feel that you know nothing at all, but that is okay. It is all a part of your process to becoming a professional and you will be much better for it, the company that brings you on will be more than happy to show you the ropes and for you to ask questions and learn how they do things. A lot of things that big companies do to make professioinal products won't be found online due to things like company NDA's so it is likely that you won't know how they do things if it is your first job, chin up you will be feeling better about it in a couple of weeks.

- Dan

Recently I completed working on a game Gunsect, where in the credits you can see that I was a solo programmer.
Whether or not I was ready for a position like this, I was entrusted with the it and placed onto the team. This meant that whatever happened over the course of the project; to have a competent game things relied on me. This was something I understood well when going into the project.

How you respond to this challenge as a programmer and as a team member matters in a lot of ways! Especially if everyone on the team knows the project is going to last for 6 months! Which is something that is important to note if you ever find yourself in this position.

How you react to ideas and your work load can shift the entire project's momentum and is vital in making sure other people are comfortable with the project before starting and maintain that comfort as the project goes on. 

Here are some of the things I found useful over the project:

• Underscope, Overdeliver -
  I found that people were much more comfortable and motivated in the project if they knew that I was happy with the amount of work that I had to do. I always mentioned if something was out of scope for me and would often try and do about two thirds of what I thought I would be capable of. This lead to me not missing deadlines and getting more work done.

• Take A Lead Position -
  It is incredibly important for you to step up as a leader in the project as a whole, whether or not you are comfortable with doing so. It's important establishing this position early! Having people step over your ideas of what is and isn't possible won't be something you can afford to let happen, they WILL scope out of your abilities and time window.

• Make The Team Work For You -
  There are a number of things that you can allow the other disciplines to handle in their own way that you might think that you have to do with programming. Doing some UI movement that you thought you would have to move through code could be done through an artist animating (and it will probably look better too!).
  On top of that you can get the artists and designers to work in a way that helps your code base! I personally worked quite closely with my artists to ensure that they worked in a way that was easy for me to utilise polymorphism in my code so I didn't need to program animation and shader implementation code multiple times. This often is no less work on their part if you tell them before hand and makes a world of difference to you.

• Plan Your Tasks! -
  It won't be enough for you to just smash out code! As a solo programmer I found it also wasn't enough to just rely on your producer to have tasks planned out for you, it is important to talk closely with your producer to create a plan for when certain tasks will be delivered and will help you keep track of how many tasks you still need to do. However do your own task tracking on top of the regular task tracking that you are doing, I personally found sticky notes quite helpful as well as making lists in documents, it is also important as a programmer to break your tasks down into smaller steps!

• Be Aware Of Where The Project Is -
  This is something that is useful advice for any project that you are on. There was a period of time where the majority of the team didn't know where the game was as a whole or where their files were in engine and how they were being implemented. I was on top of these things and it was frustrating to be one of the few people who knew what was going on as it meant that I needed to work harder come build time implementing everyone's work, which was on top of creating the structure for a number of them to implement their work in the first place. This was something I could not afford to do for long and it definitely burnt me out.
  I spent 2 weeks of my time catching everyone up in the project and barely doing my own work to ensure everyone else could do there's. This was a lot of time taken up, but worth it to ensure that the team was caught up to speed and I didn't have to plug in art assets or fix levels anymore, and it freed up my time greatly.

• Don't Allow Feature Creep -
  Feature creep is problematic for a project of any scale, but can be especially bad if you are alone when programming those features.
  It is easy to say 'no' to a larger feature. It is a lot harder to say 'no' to a small feature, but those features add up the more of them you say 'yes' to.
  This feeds back into needing to take a leadership position in the project, if you are in a position of leadership people are more like to listen when you speak up against something. I found it important also to explain to other people who may not know much about programming as to why a particular feature is more or less trouble so they had a better idea of what kinds of features take a longer or shorter amount of time to make.

All in all I found in post mortem of the project that I was appreciated on the project, not only for having the work done but for doing it in a way that made other people feel involved and important to the success of the project. I also found myself with new friends who appreciated the amount of effort I put in to ensuring that the work was done and planned out so thoroughly.