A Day in the Life of a Programmer

The Ideal

You wake up full of ideas about new features and capabilities that can theoretically be added to the product you are working on. Several of these new features generalize existing functionality and get rid of corner cases that have been getting consistently flagged as bugs by users. The features and their underpinnings have been incubating for a while now and you’ve been working on sketches, mock-ups, and prototype code over the last few weekends. You’ve been taking real time out of your weekends to push the boundary on an existing product that will in your mind pay huge dividends. The pay off is not in terms of money or economic metrics. It is about making the lives of people better and you can see how your ideas will do that.

You go to work and bounce some ideas off your co-workers, they see the vision and the generalizations, and even point out a few blind spots you didn’t cover and suggest solutions to those cases as well. By the end of lunch you’re feeling even better and branch off mainline to work on the feature. While stuff is compiling and testing you help out your co-workers with some of the stuff they’re working on. You pay them in kind and engage with the real vision of their ideas and point them in a few directions they didn’t think of. They go back to the drawing board to incubate the ideas further. You realize when those new features are ready incorporating them into what you’re working on might cause some problems so you re-design some of the data-flow to make their life easier in the coming months. You’re not a religious man but notice the spiritual aspects in the creative and communal process of programming.

By the end of the day you have the prototype reviewed, tested, and merged into mainline. No one in IT and infrastructure blinks an eye when you tell them you need a few custom packages. The pool of custom VMs is ready within 10 minutes of you pinging the relevant folks. Your test cluster is up, prototype is deployed, and actual integration tests are running. You realize you forgot an OS specific dependency. You again ping the relevant folks and they point you to your cluster definition. It is just plain code, not puppet, not chef, not ansible, not some weird YAML format, but real code. You have root access to each VM so you test the relevant bits live and then commit the changes when things work as expected. You submit the fixes and re-provision your cluster. Integration tests are once again running. The day ends with all green tests, both unit and otherwise. Your changes have passed all the relevant gates and are slated for the next deploy train.

Today was a good day.

The Reality

You wake up full of ideas about new features and capabilities that can theoretically be added to the product you’re working on. But even at this stage the architecture of the code is opaque to you and you’ve been working on this code for over a year. It is unclear how these features can be incorporated into the existing code base. Although in theory you have generalized existing features and gotten rid of all sorts of corner cases that have been flagged as bugs by users you do not see a path forward for integrating those ideas. You are hopeful your co-workers will have more context and will see the vision and new capabilities your ideas will add to the product. You finish your breakfast and head off to the office. Still very hopeful your ideas will survive till the end of the day.

Right out of the gate there is another re-organization. It is a Tuesday and you half-expected this. You suspect someone in human resources read a book called “Tuesday Re-organizations” and misinterpreted all of it. Some teams have been merged and others disbanded. Whims of the powers that be. This is neither good nor bad in your mind. Just general grayness that permeates the organization to keep people on their toes. You look out the window and see a guy pacing back and forth and gesturing wildly. He mentions needing more resources and you can not tell if he is talking about pencils or people.

You’ve had a ticket open about getting a new cluster for testing out your ideas for a few weeks now. Provisioning new VMs is an arcane process that involves some weird pseudo-language. All of your attempts to get involved and improve this process have been thwarted. The reason are varied, hollow, and usually backed by an artificial sense of urgency: “Not in your job title”, “Not on the roadmap”, “New release is tomorrow”, “Urgent bug fix”, “Contractual obligations”, “Required by law”, etc. Kafka springs to mind but you’ve not read any of his works. You have an intuition that you would have been friends if you’d been alive around the same time. You realize many of the “broken things” are castles with moats. Martin Fowler got it wrong, it’s not micro-services, it’s micro-castles and it is truly the future of all software development. You start imagining this is all a deleted scene from the movie “Brazil”. You are a programmer in the bureaucracy. You imagine pulling out a gun, putting it to your head and pulling the trigger. HR bureaucrats spring into action as soon as they hear the gunshot and start racing to see who can stamp a new requisition form for your replacement first. The guy that was gesticulating outside the window a few minutes ago runs inside: “Hold on one second please. I need to put you on hold. YOU SEE? WE NEED MORE RESOURCES!!! Ok, are you still there”. Where were you? Right, validating some new feature code.

You have some friends and they are technically competent so in between compile phases and test runs you ping them with your ideas. They are not engaged or excited in any way. They do not see the vision of how it improves the product and provides a more unified experience for the users. You don’t blame them. Their manager has been breathing down their neck about a thorny bug that has eluded all root cause analysis for a few months now. It is not reproducible in any consistent way and could be hiding in any number of 3rd party dependencies. The list of transitive dependencies is so large that no one knows anymore why some version of Guava keeps conflicting with another version of Guava every 3rd day of the month. The workaround ever since you can remember has been to re-run the 3 hour build that produces whatever artifacts depend on those set of dependencies. You ping another friend, same response. You look at your Jira and Asana queue and pick up something to work on and while on Jira you ping that ticket you’ve had open for some new VMs. Your mind starts to wander and you start chasing an analogy. There are no assembly lines in sight and yet it feels like one. Take the thing, re-jigger the thing, add another thing, pass it on to the next guy. You don’t expect a response from the ping because IT has been migrating hardware and they are operating at reduced capacity and don’t have time for new stuff.

You complete the task you had picked up and three other ones have already shown up in the queue. There is neither coherence nor any kind of aesthetic sensibility in any of the new items. No grand unified vision. Just requests by go-betweens that sit between you and the actual users of all the products you’re working on. You remember some kind of manifesto about not doing things this way. Something about frequent and direct interaction between the makers and the people that get value out of the work of the makers. Your mind wanders again and you see the trail of another analogy. This is like playing house except for engineering but you’re too tired to carry this one to completion.

You finish the day with five new lines of code. Too tired to carry on the initial thread that started in the morning and had you excited to go into the office. The build is broken and you’re unsure why. Maybe it’s the 3rd of the month? You can not run it on a clean cluster to figure out if it is your code that is breaking or someone else’s.

You grab a bottle of water and head home.

2 thoughts on “A Day in the Life of a Programmer

  1. Pingback: Professional Development – 2015 – Week 28

  2. Pingback: Professional Development – 07/13/15 – 07/19/15 | The Software Mentor

Comments are closed.