What Is It Like to Write Code For a Living?

Having been employed as a programmer for ~14 years, the following is a stream-of-conciousness breakdown of my experiences. Buckle in for some random tidbits and read on!

Ensuring Specifications

While they can be very brief, I always strive to have at least some kind of specification from the stakeholder or client to work towards. The rule of thumb is "as long as it offers some form of a finish line, it's good enough". I can always eek by with less-than-ideal levels of detail.

Often, work is broken down into milestones where I'll round up with a stakeholder and verify my work so far against their desired goal(s).

Here, things can pivot or change in direction, and the most important aspect of these kinds of meetings is capturing any new direction. Remaining flexible & understanding shifting goals can sometimes be tough, but it pays off to not get too attached to any early development efforts.

Tracking the Work

I'm always using an issue tracker like JIRA, Redmine, Trello, etc. In rare cases work will be tracked exclusively through Slack or a series of phone calls, but even in these cases it can be helpful to use a personal task tracking solution to keep things organized.

Ensuring that change requests are tracked in these systems is critical as well. It's helpful when another dev needs to come in and take over work & understand how specifications changed over time, but also for stakeholders to understand the impact of changes on budget, delivery timelines, and so on.

Doing the Work

Making sure I have uninterrupted hours for just getting things done is essential.

A typical cycle I might find myself repeating for any project is:

• Planning; sketches in a notebook or online flow-charting system
• Writing the code (notice how everything else is in support of this humble list item?)
• Debugging using proper tools. This is huge and in my later years of development I've come to recognize how proper debugging tools can save you immense amounts of time. Use breakpoints, work smarter not harder, etc.
• Googling problems or error messages not covered in documentation.

Speaking of problem solving and Googling...

Googling Things

One of the most common gate-keeping strategies in tech is to insinuate that "real devs don't need to Google stuff every five minutes" — this is false and ridiculous.

We only have so much mental bandwidth, and focusing on the abstract problem at hand should comes, while implementation details come second.

I spend an enormous amount of time reading documentation for language features, individual open-source packages, paid vendor libraries, API specifications, and so on. I Google for error messages and strange behaviors I'm not expecting. This is clutch.

Without many hours of writing the same kinds of code over and over again, there will always be a need to reference documentation and external knowledge.

Testing, Implementation, DevOps

I'll regularly push code I've work on to remote environments for staging and verification. I manage code and supporting assets in source control (e.g Git, Perforce) for a project; checkouts, merges, commits, and the like.

Occasionally, there might be responsibilities for setting up hosting environments for web frontend/web backend services, configuring databases, or working within various services specific to domains, DNS, and so on.

Verifying functionality once code or product is running on a remote environment is important. The goal here is to primarily avoid a "Well, it works on my PC!" mentality. I think it's key to take ownership and ensure things are working in a context outside of local development.

Research, research, research!

Much of my time is spent Googling and just hanging out online. While it's a part of pretty much any career in tech these days, it's not always about solving direct problems on Stack Overflow or a in a technical Slack group.

I'll spend time reading postmortems from large industry projects, articles about new technologies or techniques, as well as more broad concepts like systems architecture and how each "brick" of a large programming project can come together to form the grand masonry of the finished superstructure.

Experimentation

Spinning up personal projects to explore a new technology or technique is something I find myself doing often. It has the potential to really put some wind in my sails during a lull at work, or when the project(s) I'm working on are very rote; I like new things!

It's easy to feel like there's just too much to do, and not enough time. Keep an eye on self care and don't burn out!

Pros & Cons

Likes

• Creative opportunities. There are many ways to solve a single issue, and finding the optimal route to a solution is engaging and rewarding.
• Programming is powerful. There is so much that can be automated or enabled by coding. The applications for these skills are really broad, and expertise can travel across all kinds of industries.
• In the mix. Unlike some disciplines that come either before or after a project's production phase, development often occurs in the heart of the pipeline. This makes for lots of collaborative opportunities, chances to right wrongs, push functionality towards it's best possible incarnation, and so forth.

Dislikes

• Chiefly technical. Despite there being creative opportunities for implementation, development exists in a realm where the "correct" outcome can be expressed with cold, hard logic. This leaves less room for creative expression, which can be draining over time.
• Rote. Once you're comfortable with a given problem domain, writing code can become little more than wiring together known quantities. Access API X, verify outcome Y, output result Z, and so forth.
• Toxic gatekeepers. While this kind of thing can be found it almost any industry or career path, I feel pretty strongly that the expertise and esoteric knowledge gained during a programming career pushes people towards these tendencies.
  • More times than I can count, I have encountered folks who are more interested in being the keeper of knowledge than a purveyor of solutions or collaboration.
  • Avoiding this can be difficult, and I often want to escape to a more subjective discipline when faced with team members or clients like this.

In Closing

While I love the pragmatic approaches necessary to be successful in development, I long increasingly for work that allows for more subjective expression and offers more opportunity for emotional storytelling. These days, the realities of programming full-time have inspired me to begin thinking about a shift in focus. Perhaps away from technical expertise and more towards technical writing, documentation, or educational materials.

In any case, I am sure my development experience will enhance whatever I find myself doing next. It's a wonderful set of skills to have cultivated over the years.

Please reach out if you have any questions about your own journey in programming or beyond. You can find me on Twitter as @aaronransley, or shoot me an email!