Thanks for the encouragement guys. It's clear there enough interest to warrant future posts. And y'all are asking good questions.
Grumblesaur wrote: ↑
Tue Oct 03, 2017 7:37 pm
On that topic, what's a typical day's dev process like at the office?
Heh. Well, the office is a 10ft box. It's a small room attached to a shared working space. There's probably 6 total tenants in the space. It's actually really cozy. Josh's usual flair extends to his ability to decorate. Hours are 'kind of 9-to-5ish or whatever works for you but we should be here at the same time for the majority of the day'. Which, frankly, I think is the healthiest way to work. I'm typically here 9:30 - 6:00. Josh 10:30 until who knows when.
We've been trying different approaches and learning how we work since I joined, so our 'typical day' has continuously evolved. I get here, setup my laptop, read through my to do list, and decide where to start for the day. I keep Notepad++ open with a few tabs of information for myself. There's stuff like research notes (quaternions at the moment), fun tasks for weekends or relax days, and most importantly a fine grained, personal to do list. My memory is abysmal so this is how I manage to keep everything together. Then I just start plugging away. If I have questions, new ideas, or need a sanity check for something I'm doing I spin around and talk to Josh. Josh does the same and this is actually the most important part of our process I think. We communicate a lot
. Often one of us see major simplifications the other didn't catch right away and it leads to more elegant code.
For new systems and major architectural decisions we talk through approaches at length. We tend to disagree fairly often and there's always some element of either enlightenment or compromise. This is another part of our process I find particularly productive. We have the same mindset about how to solve problems in general, which means we're able to work together in the first place, but we differ in the details. We're able to talk through the pros and cons of each option and make an objective decision. For larger problems we have a whiteboard nearby.
Once one of us finishes a task we commit and announce it, and almost always the other one will play with the new stuff and provide feedback. It's great for morale when someone immediately sees your work and comments on it. Many high fives ensue.
That leads to another extremely important part of the way we work together. We aren't afraid to clobber each other's code. A common theme for us is 1) talk through approaches, 2) one of us writes the initial implementation, 3) the other reads and rewrites it. It's always kind of hard to go back and refine code you just wrote (but you should still do it!) because you already have a specific solution mapped out in your head. A fresh set of eyes is far more likely to find issues and simplifications. Plus they have the benefit all the nuance that was learned in the initial implementation. You can't do that when you have team members that attach their ego to their code (my last studio was a nightmare and that was a large contributor).
Once we run out of tasks we have an impromptu 'planning meeting' where we adjust our direction and decide what the next goal and handful of tasks are. In terms of task management, we've gone through the ticket system in Assembla, plans written in Google Docs, a kanban board in the office, and probably some other stuff. At the end of the day it feels like those cost more time than they save when there's just 2 people who communicate well naturally. We still have milestones in Assembla with a timeline and the big tasks listed out, but that's not something we're staring at every day.
That's more or less our normal process. It's laid back. I tend to leave early if I finish a task late in the day or I'm just kinda burnt out that day. Josh takes days off when he needs to rest. Both are quite rare, but it makes a massive difference being able to just take a few extra hours or a day to recharge. I don't normally take breaks or eat lunch during the day, which I know they say is bad but it takes me a long time to 'get in the groove' and I don't like paying that cost. Fridays we stop working an hour or two early and play some games. On the weekends sometimes we try to come in and work on fun stuff (next time I want to try to get a debugger working in LUA).
Hyperion wrote: ↑
Wed Oct 04, 2017 5:55 am
I'd very much like to hear more on this. When do you guys get in? how many
cups of coffee do you guys drink each day? Do you guys have a formalized system for going from thought to code to testing to analysis to final implementation? Do you have cyclical tasks like "Every Friday we re-visit Dogfighting/Macro-AI/etc"?
I bring a 20oz coffee mug from home because the swill in the lounge here is unfit to be called coffee (and you know, sometimes I want a little something extra with my coffee).
Formal systems, not so much. We're not at a point where testing is time well spent, but that'll be something we have to figure out in the near future. Same with cyclical tasks. Once we get deeper into gameplay that will make more sense. Nice thing about the shared space is we can drag fresh eyes and even other game developers in for feedback (the entire building has maybe 30 offices and multiple game developers).
Hyperion wrote: ↑
Wed Oct 04, 2017 5:55 am
But probably the most important question I can think of regarding development: Adam
, are you looking to stay on the team after LT launches and be a founding employee of Procedural Reality, or are you looking to just help Josh get this to market and then move on with your own goals and pursuits?
This is something we've talked about. Working with Josh has been the healthiest, most productive, and most enjoyable development I've done. I think it'd be unfair to call me a founder, but as a partner? Yea, it's definitely something that's on the table. However, that's far from decided. The plan right now is to ship LT and then evaluate what makes sense for both of us. Personally, I'm dying to get out of the south and I think Josh is undecided on that. We've also talked about how nice it would be to take a few years and fix a lot of the not-so-great toolchains programmers are stuck with. I've never been able to imagine programming anything other than games, but I have to admit that idea is becoming more and more appealing.