I work in a small and "family"-like software compagny. I do not currently program video game at the office, but rather medical softwares. I do have a video game side project that i develop alone, on my free time.

Since we're a small team, i often have to do both programming and analyse.

Basically, my days goes like this:

When i arrive at work, we hold a very quick meeting with the devs and project director to see when has been done the eve. Possibles issue are discuted there, along with solutions. This take at most 15 minutes.

I always have tasks assigned via Jira, so i know what i have to do ahead of time. Normally, what i have to do is documented by the analyst. Of course, not "everything" is deocument, so if issues arise, i need to voice them / thinks of a solution. This process is very sastifing, as i act at the analyst's back-up, if he screw-up (which happens sometime).

To be honest, i don't really count the line of code in a day. It can fluatuate a lot. I normally code about 50% of the day, do research 30%, speak with my coleague 10%. The last 10% is administrative work not directly related to coding, like meetings, filling my timesheets, documenting stuffs, etc... You could write 10 line of code in a whole day and be considerer still be considered very productive.

Then, when i'm out of work i usually keep coding 2 to 5 more hours in the evening on my personal video game project. I work in a software compagny, but my real goal is going to a video game compagny. This personal project is very nice on a CV (if completed). Also, i could make somes money out of it, but that's not really my primary goal.

Ill add my input just to add some different perspective. Im currently an intern at a company that provides services to games. Usually I come in and check email at the start. I dont usually take the support tasks as Im new but others will take them and work on them for some portion of the day. I look at my current tickets and work on them for appropriate hours for each for the day depending on priority. Then I have a scrum meeting at the end of the day with the rest of the team where we look over the board and discuss the tasks and quickly prepare for the next day. When I finish a ticket a new one is assigned to me and I seem to have 2/3 going at a time depending on how large they are.

For the tasks some time is spent thinking about how Ill tackle it or discussing it with someone who knows more about the area of code Im working in. Then spend some time making my changes, and depending how far along I am, testing those changes to see if they work. Or just implementing the unit tests to see if they work. Ill run into problems when working with such a large existing code base where Ill have to talk to someone to just understand how a certain section is working because I dont want to make a small change that breaks the whole thing. Once a task is done put it up for review with my team and then make changes that they suggest.

Then of course theres random chats, food time, beer o clock and other such fun stuff that are in the day. Some variation of those make up my day.

I'm new in gamedev, but so far I like it so much.

That is pretty sweet that someone new in gamedev can work in a small game making company. I'm curious how did that happen? Was AS3 the only requirement?

Yeap. And I had to write the small game with the Starling framework to demonstrate the way I approach to problems, if my code is clean enough etc.

Programming, and game design both interest me greatly.

I am unsure if this career is for me.. or should it remain a hobby.

Some questions that come to mind...

On average.. how much line of code does a programmer write per day?

How structured is it... Is the programmer told what classes to code etc.. or is expected to figure out what needs to be done?

If anyone knows any good articles, books, or videos that show a day in the life of a programmer, I'd love to see it.

I work as a programmer for a company that automates the process of pulling real-time and historical data from gas flow computers and PLCs over any sort of network (sorry not a game programmer). Graphics is my hobby though.

How much code per day?

It varies...but usually the volume is irrelevant. Its quality. Usually its tweaking existing code or adding features on top of it. Writing stuff from the ground up is pretty rare. So not a lot of code. More analysis. One or two lines of code is often the difference between something that works and something that does not.

How structured is it?

We have a list of tasks that are stored on a server. The stakeholders (sales and top tier management) consult my boss and build/maintain the list of tasks. If there is something urgent my boss will assign the tasks...if not the developers pick them. We are very customer centered so if you work on a project you are still expected to be able to take a direct call from a customer on it. Developers used to always take technical support calls whenever something came in...we now have some dedicated people for that but it still happens when there is either overflow or a problem they could not solve (or it requires code access). So organized chaos to answer your question.

Big AAA Publisher-owned House like any house funded by EA or Sega, you will find yourself silently expected to work 80+ hours a week, at times opting to sleep under your desk, seldom seeing your family. If you're not willing to do this, they find some contrived reason to fire you as you are very easily replaceable: there are lines of programmers out the door that really, really want to make games and are willing to sleep under that desk you're suffering on. (Also, the pay is crap...for a software engineer.)

...

I'll never forget Jake Solmon's (Firaxis, lead designer on XCOM: Enemy Unknown) last interview where he said that he'd missed the first year of his baby's life. I do not want that to happen to me.

While I wouldn't go so far to say that the famed 80+ hour work week is a myth, it's definitely a gross generalization. I work at a studio tied to a major publisher and can't even remember the last time I was even asked to work overtime. That isn't to say I don't work any overtime. My team are professionals and we do what we need to do to get the job done. With that said, I am one of the younger/more junior people on the team (at 31 with 8 years professional game experience), so we have a lot of experience to draw on these days.

There are teams in my company that are shit shows (I have worked on some in the past). There are teams working on great AAA titles all over the industry that kill themselves to ship their games. I have a lot of friends who work at startups (games or otherwise), and kill themselves more than when they were at big companies. At the end of the day, you need to take care of your responsibilities. Also, people change. I gladly worked myself to the bone in my 20s. Now that I have a daughter, I am not willing to work weekends (outside of around important milestones if something explodes), and no longer work more than 50 hours a week.

I'm a career software engineer. ... I do not work in games, and there's a pretty succinct reason for this: my understanding is that you *really* have to want it, because it's very grueling. I'm going to be a bit reductionist here in the hopes that somebody who works in the industry today pipes up and corrects me...but here's why I'm not in the game making industry: you are at either one of two kinds of dev houses which each have a common theme I do not like.

Big AAA Publisher-owned House like any house funded by EA or Sega, you will find yourself silently expected to work 80+ hours a week, at times opting to sleep under your desk, seldom seeing your family.

I have worked both inside and outside games.

I found that quality life in games is actually a bit more reasonable. People actually TALK about quality of life issues.

When working on business software, I was expected (=required) to work two Saturdays a month helping with deploying software around the business. Usually I could call in and everything was okay. Sometimes I needed to be there physically rather than over the phone. Sometimes I needed to be there for a full weekend. Very often I was expected to put in longer hours, and I was occasionally chided for arriving and leaving on time.

Obviously in games you still need to be professional about it. Just like any other industry, the software must ship eventually and there is usually a big push near the end, usually lasting under a month, where people end up staying late several nights to clear out their bugs and hit the deadline. Some projects are well-managed; I have worked on several games where extra hours were not required generally (although some QA people worked extra). Some projects suffer from bad management which includes poor planning, project "pivots", bad estimates, and insufficient staffing. The bad projects I have watched decay were almost universally from bad management decisions. Some projects suffer from team members that spend development days watching youtube instead of developing.

My best bosses, even during crunch time, have been strict on QoL. "8 great hours, then go home" was one mantra. If our manager caught someone watching videos, he asked them if they were planning on staying late to get their 8 hours in; the few people who previously wasted a lot of time surfing the web very quickly became more active contributors or were quietly moved on. Under that boss we didn't have a crunch at the end of any project. Another manager (a fairly bad one) refused to cut features, told designers and producers "yes" to everything, and was hated by the development team. His teams routinely stayed late. I had the misfortune of being assigned to his project for a year. I continued to work my "8 great hours". When I was invited to work extra hours, I politely declined, reminding him of the studio's policies (and the state's well-documented law) that they cannot mandate overtime for salaried positions without paying overtime because by statue we were all non-overtime-exempt salary employees. The exempt and non-exempt status can vary by many factors (especially state-by-state law!), but many white-collar workers are actually non-exempt although employers claim they are exempt. Most artists do art to spec and are non-exempt even when making a salary. Programmers in some states that do code-to-spec are non-exempt because code-to-spec is not a creative work; in CA it is based on salary as well, currently about $83K/year. There are few penalties for it when the business gets caught, normally just paying a few months' back wages and no real penalty, so many employers will just not pay and hope you never notice. I paid a visit to HR and asked for clarification that requiring overtime meant paying 1.5x wages because we were non-overtime-exempt salaried employees, and was told that was correct, were were non-exempt. The boss was called and asked to join me in the HR office to hear his side, including his passionate pleas that team members work unpaid overtime. The HR manager thanked me, and the following day the boss changed his tune about requiring overtime and apologized to the team. The new tune was that although salaried workers could volunteer overtime if they wanted, they would not be paid extra for it and would not be penalized in any way if they didn't work it, and that those who had been putting in extra hours would be getting some extra money for their previous overtime but that was now over. The day after that, features started to get cut. Most of us are professionals and are passionate about quality work, and will put in the work reasonably necessary for the job... as long as we are paid for it.

I have found that each studio is different, each project is different, each time within the project is different. Modelers may have tons of free time but animators are struggling. The combat system programmers may take long lunches and leave early, but the overworld team may arrive early and leave a little later.

I have almost always had better QoL inside the games industry than outside it.

I often describe my day simply as such:

40% research/reading

40% conversation

20% coding

close to my own - depend what you mean by the 'day ' if 8 h

or 16 hours - I got 16 h day work on my own - i spend a lot a lot of time on research and reading but also freely mixing it with conversation and resting (forums, etc - there research is easier and i could rest which is very important) (this year im reasting more than before, previous years i was focusing more but i was feeling strange and quite noticable overwork simptoms, (now It seem improved, interesting) )

It depends hugely on the type of job you have.

I'm a consultant, my main project currently is mostly made from consultants.

The teams are managed through bidding on tasks on a time to complete basis. New guys don't get to take part, they're usually given over the shoulder jobs or more traditional tasks and closely monitored and helped so it's not overwhelming.

The permie guys probably work 42 hours a week, we generally do 37.5, they keep us down as the rates rocket up to double after 38 hours.

LOCs doesn't really reflect productivity, I might remove 100 lines and improve the code.

If the work is quality related, 2 locs/day might be normal, you'll spend most of your time in meetings reviewing the code, planning the code, modelling the code then liaising with guys around the world who will test the code, then referencing the test results against the model and writing documents to show why they're different. If it's not high quality work you might get to code for maybe half the day, meetings, project discussions and general crap takes up the rest. If you're working for a small games co you might get to code almost all the time.

With quality work everything will be mapped out for you, there's very little innovation or autonomy. Non-quality can be hacking away all day long with no-one bothering you and you have almost full control. Where your work interfaces with someone else's that will be defined (or you'll have to define and document it).

An average day for me if not flying would be arrive, get coffee and check the overnight test results as I wake up, skim over the version control logs to see who has branched what and what's been merged in. Check the build still works.

Reply to emails regarding the results, usually interrupted by a team meeting to discuss progress and deal with any emergencies (you might get flown out to do something exciting here but usually not, maybe twice a month)

Code for an hour or two until lunch.

After lunch peer review someone's code, or help the testers or calibrators with the new software written from the day. Or assist the hardware guys if something is looking dodgy. Some days are spent doing pure architecture, but mostly not.

There's quite a lot of interacting with non tech people which is amusing but can get frustrating.

It can be quite glamorous, usually it's not.

The better you are, the less likely it is you'll be coding much tbh, you tend to get pushed up quite quick and away from the development into more overreaching tasks, which can be frustrating, coding can be a rare treat with some contracts.