The Hardest Lesson: It's Not All Code

One of the most difficult things as a developer is the constant need to remind myself that my job isn't just code. There are a lot of pieces that go into being an effective developer, coworker, and employee. Not all of them are fun, but most of them are necessary.

Administration

Most jobs have some basic administrative work that everyone has to do. Time tracking was easy but annoying as a junior developer working long stretches on a single project. As a Senior it became worse; trying to keep track of conversations and support that could be billable or fall under capital expenditures for tax purposes. This overhead seems to stand between us and the code we want to write, but tracking them properly can impact the company's financials, and that can impact your job. Requesting time off. Meeting deadlines for required HR paperwork.

Communication

Delivering code on time is amazing, but rare, and communicating that discrepancy is important as soon as you know it is there. If you realize your project will be a week late because of a new development, added requirement, or unforeseen issue, people need to know that right away.

A particularly great boss of mine insisted he didn't care what the timeline was, just that we tell it to him. When you communicate delays and difficulties, others can provide assistance. Leaders, project owners, and subject matter experts can help prioritize or change requirements. Team members can be reassigned or provide input.

None of that happens if you don't tell people that something is harder than you originally expected or different than estimated.

Documentation

Normally when we say "documentation" we think manuals, changelings, code comments, but that's only a slice of what documentation is. Documentation is durable communication. Communication lets others know what's happening; documentation provides a way for others to find things on their own.

Did you have a conversation during lunch that changed a requirement or adjusted a design? Did a critical issue take you away from your task? Did someone tell you that it was OK to leave something out of the project for now? Tracking those details in a way that others can find them is important. Updating design documents, commenting on tickets, copying email information into a ticketing or documentation system, and even updating your ticket status are ways of documenting work for others to see and understand, both right now and far into the future.

Teamwork

As much as you need to communicate when something isn't going to plan, you also need to communicate in general. Maybe you are writing a new utility to eliminate duplication across several files. Would your coworkers benefit from knowing about it? Maybe there are conditions or use cases that your utility doesn't cover? Has anyone else worked on this in the past? Maybe there's a reason for the duplication. If you talk to your coworkers, everyone has a chance to share knowledge and learn.

Teamwork can be as simple as sharing a link to a new feature or API with others, or it can be the harder task of speaking up in a room or messaging channel and saying you have a problem and could use some opinions or support.

A good team helps each member become better at their tasks and at their job, and it takes effort to maintain a good team.

Advocacy

Don't be afraid to speak up. We assume that leaders and managers already thought about the questions and concerns we have, because maybe they've been doing this longer or have more skill in certain area, but different jobs come with different focus and patterns of thought. As developers we also need to be willing to make suggestions, propose changes, and just ask questions when we don't know things.

This includes pushing back at times. Are you uncertain about a design or choice being made? Are there technical limitations or even regulations that aren't being considered?

A great boss will advocate for you when you have concerns or goals, but you can't expect others to know what you haven't told them. Communicate your ideas, concerns, and disappointments. Understand that not everything will go your way, but you have better odds if you speak up.

Your Thoughts

What are the parts of a development job you didn't expect, or discovered were more important than you first thought? I'd love to hear about your experiences!