2 answers

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

Asked Providence, Rhode Island

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

2 answers

Lee’s Answer

Updated Portland, Oregon

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!

Brian’s Answer

Updated St. Louis, Missouri

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/