While listening to Spark, on CBC Radio, I had the idea it might be nice for non-developers (and aspiring developers) to know what a typical day might look like. I get up at around 6:40 am, and spend most of the next hour with my better half getting the kids ready for school and daycare. We leave for school at 7:40, school starts at 8 and there’s no bus (because we didn’t choose the default school for our neighborhood). As I usually only take the eldest of our two children to school, leaving the youngest to the love of my life, I arrive at the office at about 8:15.

Currently, I work as an analyst-programmer, so I design and implement software according to functional (requirements) specifications. That means my job consists of analysing functional requirements, analysing existing software that the new software has to integrate with, designing the new software, implementing it and testing it. I do this, like most of my peers, mostly working alone and validating the analyses with my peers, making sure I have sufficienly understood the requirements and the existing software, before diving into design and implementation. The teamwork part of my job, in this type if setting, is in the validation of the analyses and the discussion of the design.

In different settings, teamwork takes different guises: in settings where there is a formal design phase in which functional requirements are hashed out, project managers and functional analysts work in teams to design products that will then be produced by the thousands and shipped around the world, teamwork tends to take the form of discussions, meetings, validating analyses and peer reviews of code. In environments where development is more project-based, where the requirements to be met are those of a single customer for up to a dozen installations, the effort put in a single installation is a lot more important but the time-line also tends to be a lot shorter, resulting in a setting in which teamwork starts to look like a scrum. I’ve worked in both settings and I honestly don’t prefer one to the other: both have their advantages and their drawbacks as both are essentially a trade-off between short-term and long-term productivity.

To continue the description of my day: I work eight-hour days (at the moment), so after the first four hours I take a 15 minute break, heat my lunch, eat it and get back to work, which means my work day is over at about 4:30 pm - in time to go pick up my eldest child from school, go home, fix dinner if my better half hasn’t. We then corral the children through the drill of dinner, bath and bedtime stories and, once they’re in bed, try to catch up on my reading. I do read my E-mail during the day (personal E-mail at about 7 am and 5 pm) and listen to the radio most of the time, but my “real” reading is a thing of the evening - which is also when I write my blog.

So, where do I find the time to do my podcasts, etc.? You might be surprised if I told you the “C++ for the self-taught” podcast is written and recorded all the way up to March and the next few Funky demos are ready for when the next version of Funky comes out of testing. The project that’ll be the subject of the “C++ for the self-taught” podcast will actually be pretty interesting as it will touch upon many subject that real-life programmers will run into in their daily lives.

So, to sum up, my days are pretty well-filled. If you intend to become a programmer, an analyst, or some combination of the two, your days just might be similar to mine - or they might be quite different. If you already are a programmer, an analyst, or some combination of the two, please feel free to post what your day looks like :)