What types of software engineering roles will allow me to spend the most time actually writing code?
Hi everyone. I'm a CS major in college, about to become a senior, and will be looking for a full-time role soon. I feel like I'm on track, and am considering what type of software engineering role I'd like to pursue. One thing that I've learned from my summer internship is how much of software engineering can involve things other than writing code: 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. I don't necessarily have a problem with any of the other types of tasks, but this got me wondering if there are certain types of roles where I might spend more (or less) time actually writing code. What are the factors that might affect the % of time I'd spend coding? (Factors might include characteristics of the company that I work for, characteristics of the department or team I work for, etc.) I'd appreciate any experience you might have on that one. Thanks!
#software-engineering #programming #software-development #python #web-development #backend-development
To echo some of the other commenters here, writing the most code doesn't necessarily provide the most value to a company. For example if you can find an open source project that solves the problem you were tasked with, you have succeeded! Don't assume that writing the most lines of code written equals the most success.
That said, having worked at both large and small software companies, I would say that people spend more time writing code at smaller companies. That is because there is less communication to be done (less meetings) and also because there is less existing code. At Google, where there are billions of lines of code, your new code is less important than at a small startup where there are only 100,000 lines of code.
You also usually have the opportunity to work on a greater number of projects at a small company; you may well be asked to work on something different every 3 months. Again, because there are less people per project than at a larger organization.
That said, I feel like a lot of what you mentioned is essentially required as part of a software engineer's job. Unless you are working alone on a brand new project, you will certainly be reading coworkers' code and coordinating with them to understand what you are working on. Same with reading documentation. If you're doing a basic web development job, there might not be many internal tools to learn, but I feel like most companies nowadays have some sort of internal tools you will use regularly. I would consider writing test cases and fixing your bugs part of the code writing process as well, so it's hard to split those up.
I think you would be hard-pressed to find a position where you don't do any of those things, as I would fully consider them part of the coding process. You might find some companies where things like writing configs or setting up internal tools are distributed to other teams, but beyond that, unless you're working on a personal project defined by your own rules, you will likely be doing all those things at any company. If you don't want to do any of them, your best bet would be to ask during the interview process!
I would say that it is less the role type for software engineer that defines the amount of time focused on code writing and more the type of software and industry the software engineer is apart of.
For companies that are producing software for enterprise use there is a lot of work to get it right. This involves understanding requirements, designs, reviews, tests, and the code.
If working in a role that is building internal tools I have seen the requirements, design and reviews take less time so more time to iterate and code new things. This works for a time depending on how the internal tool is used and how big it becomes. Too much code that becomes spaghetti code will become unmaintainable or not scalable. Then it will be back to understanding what is required and redesigning things before getting back to writing code.
Writing great code is a key skill but being able to design something that scales and is easy to maintain is just as important and planning that out can often take more time than writing code.
Hope that helps.
The value of software is delivering value to the customer. It takes a lot of work to understand what is needed. You're value is to understand the needs and deliver a solution that meets those needs. Be careful, there are 10's a millions of offshore developers. It's easy to offshore a coder. Business leaders want developers who are strong communicators, truly understand their requirements, and deliver the right solution in a timely manner.