It can be hard to tell folks who aren’t familiar with computer science or the tech industry what I do. The problem sets I had in college aren’t a good reflection of what I do either, so my fellow classmates who took 1 or 2 computer science courses probably won’t have a good idea of what a paid developer does. Here’s generally what I do:
1. I translate product requirements into code
This is the funnest part of development. You are getting paid to solve problems, and in solving those problems you are creating business value to your employer. Depending on the team and the scope of the project, you may be given feature specs by a project manager, or you may be part of writing those feature specs. You may also be part of the planning process where problems/features are articulated and you help turn them into requirements for a solution. This not only involves exercising your craft as a developer, but your ability to understand and communicate on a high level to your team and your product owner. Sometimes it also involves communicating how much time it will take to get something done, which leads me to…
2. I estimate how much time a project/feature/task will take
A tech lead may assign certain tasks an estimated time of completion, or you may be in charge of understanding how long something will take you. At any rate, if you’re getting paid to code you will undoubtedly hear the question “how long will this take?”. You will hear it from your product manager, an account manager who wants that feature for their client, the sales team, the design team, etc. I consider this a learned skill akin to an art form. You will need to have knowledge of your code base, the various stakeholders, and other members of your team. You’ll need to understand how long writing the new feature, debugging, and testing will take you. And you’ll need to understand how to communicate your progress to the various stakeholders. For example, if you’ve been assigned a task where you’re fixing a bug affecting a large account for your startup, you probably have an account manager who wants it fixed ASAP and doesn’t fully understand where this task fits in on your priority list or how long it will take you. You may not understand how long it will take you either, since it was a regression that was introduced to the code base and you may or may be not familiar with that part of the code base. Continuous communication with all stakeholders is key.
3. I write tests
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” - Martin Golding
“If you don’t like testing your product, most likely your customers won’t like to test it either.” - Anonymous
Any tech team worth their salt will emphasize writing tests as part of writing a successful feature. Some might have their own QA team that writes tests for them. Some might assume you have written tests for your feature. Testing is at the core of developing software people want to use and buy.
Some tech teams will even follow Test Driven Development (TDD). Using TDD, you will write tests for functionality that doesn’t exist, watch them fail, implement the functionality, and eventually watch them pass. I’m not confident you will find this in academia.
4. I find/resolve bugs
Sometimes you will feel like you are constantly finding, fixing, and talking about bugs in your code base. You will hear your manager talk about the technical debt your org has. This is a fact of life when getting paid to code. However, you do not need to be drowning in tech debt every day (that is what those tests were hopefully for!).
5. I catch up on email/task threads/go to meetings
If you work for an entity who employs you, chances are you are going to have to more spend time than you want engaged in these three activities. As a member of the beaurocracy, I too spend time in these activities.