4 answers
Asked Viewed 209 times Translate

How much of the time is a backend software engineer actually writing code?

I'm a CS major in college and I am about to finish up a 12-week internship in backend software engineering at a division of a very large tech company. I'm a little surprised at what % of my internship was actually spent writing code: just about 3 of the 12 weeks. The other 9 weeks were mostly spent reading code, reading documentation, learning to use internal tools, writing configs, writing test cases, minor bug fixes, and spending a lot of time communicating or coordinating with coworkers. Most of my tasks were not coding intensive, and looking at the rest of the team it looks like around half of the team is more involved in testing/analysis than coding. This is very different from what I'm used to in my CS coursework at my University -- where our focus is almost entirely on writing code that solves assigned problems. What's a normal breakdown for backend software engineers of writing code vs. some of the other things that you do? Was my experience this summer typical?
#software-engineering #programming #software-development #python #web-development #backend-development

+25 Karma if successful
From: You
To: Friend
Subject: Career question for you
100% of 4 Pros

4 answers

Updated Translate

Lee’s Answer

This kind of depends on the engineer, the company, what phase of life the company is in, etc. I spend a large majority of my time working with code. This is reading, debugging, testing, and writing. Personally, I bundle those up into 'writing code' because I can't successfully add new code without reading and understanding what exists. I shouldn't be shipping production code without writing tests, and doing at least some minimal testing of real use cases. As we all know, there will be bugs. And debugging takes time to read and understand what the intention is, and figuring out with testing in which cases it breaks.

All of that said, it still depends on how your team and projects are structured. Undocumented code isn't very useful. As a backend engineer, writing an API without documenting it doesn't help other teams understand what you're doing. As a new engineer though, no matter where you are, you're likely to spend a lot of time reading code, updating documentation, working on small bug fixes, and other tasks that are hard to justify putting engineering time on. It's not just because it's a bit of grunt work, it's a great way to understand the stack and tools that you're going to be working with. There's a lot to learn!

If you're in an early stage startup, you'll write a lot of code because you're creating things that don't exist yet while trying to get to a big, robust product. If you're in a large long-standing company, you're more likely to be in a maintenance role - adding to existing functionality and patching bugs. Ultimately, no matter what, you're going to spend a lot of time working with and communicating with coworkers. Someone (almost definitely not you) is going to decide what needs to be built, when it needs to be built by, and what the parameters are. You'll be in conversation with them throughout the project to ensure it meets the needs of the problem you're trying to solve. You'll spend a lot of time reviewing code. Deciding with coworkers which third party dependencies should be used. How to transition to new technologies when things start to get out of date.

Depending on how you frame it, this is all writing code. It's the underbelly of what it is to write and build something new. It's not always as fun as making something new, but it helps build something stable and maintainable that you and others can continue to add to without needing to rewrite something each time a new problem is faced. And in the end, it makes the time when you're working on a project much easier to reason with and solve in a reasonable way.

It's reassuring to know that all that work was actually useful to the company and "counts" I guess- I worried sometimes that I didn't feel like I was contributing as much as I could because I wasn't strictly coding. Thank you for the answer! Anina H.

100% of 1 Students
Updated Translate

Brian’s Answer

The industry has embraced agile more and more. I think the Scrum T-Shaped developer article is one of the best perspectives. The most value is added by reaching across disciplines. I'm also a big believer in Test-Driven Design. So, developers need to integrate testing into their approach & mindset. See https://www.infoq.com/articles/test-driven-design-java/

Brian recommends the following next steps:

Study the Scrum methodology: https://www.scrum.org/
Study the SAFe methodology: https://www.scaledagile.com/
Study Behavior-Driven Development: https://cucumber.io/docs/bdd/overview/

100% of 1 Students
Updated Translate

Rob’s Answer

It definitely depends on your role, team, and company, but I agree with Lee's comment describing all of those activities as `writing code`. You're right though, there's usually a large disconnect in what Universities teach students and what skills those students are expected to have while on the job.

As a backend developer, much of my time is spent trying to understand the problem I'm trying to solve and how to best implement a solution. This requires a ton of soft skills (talking with stakeholders, planning work, researching technologies/methodologies, coordinating with other teams, etc) and less of getting into the weeds of the codebase. Once I've developed the best solution, I will spend the majority of my time actually implementing that in code. For other teams, I've spent a majority of my time writing code, but those roles were focussed primarily on reducing tech debt, migrating codebases to new environments, etc. which, while educational, can lead to burnout.

100% of 1 Students
Updated Translate

Ajey’s Answer

Lot of people assume a project is about coding.
In my opinion, coding is 30% of your project.

This is how you can breakdown the timelines :
10% : Requirement Analysis
30% : Detailed design
10% : Learning of required technologies
30% : Implementation
10% : Testing
10% : Documentation

Note : Its not a rule that all these has to happen in the same order, there may be some overlap as well. (Implementation can be done along with testing and documentation)