Anina
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
6 answers
Jeffrey Reed
Jeffrey’s Answer
Anina:
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.
Paul East
Paul’s Answer
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.
That makes a lot of sense! Thank you for clarifying :)
Anina
Prashant Gupta
Prashant’s Answer
But over time, I realized that even though all this was exactly what I wanted to do and it made me happy, my code remained sub-standard for a variety of reasons.
For example:
- Not reading code that others have written means you might not be learning from other developers' expertise, or perhaps recreating a lot of things that already exist.
- Not reading documentation might mean your code will miss certain aspects that might be covered in the documentation.
- Not writing test cases might mean your code fails certain edge conditions, which might have been caught with good tests.
- Not communicating or coordinating with coworkers might mean you miss out on their invaluable experience and expertise and make mistakes which might have been caught by them.
In short, by doing all these mundane things, my code quality started improving, even though I spent less time actually writing code.
The way I think about it when I have to write code for something is to feel that I OWN the code that I am writing. (by owning I do not mean in a legal sense, instead think that you are the creator and you are bringing something new into this world by writing code) Whatever I code, it's MINE, I created it and hence I want to make it the best I can. And when you have that feeling of owning something, doing mundane tasks like reading documentation, writing test cases all come naturally. It's almost like driving a car versus OWNING a car. If you just drive a car, you don't care about anything else apart from the fact that the car should work, but when you OWN a car, you feel like making an effort to keep it clean, have frequent maintenance and inspections done, check tire pressures, and do other mundane tasks which you perhaps would not have done if you just drove a car.
Hope that helps. Good luck with your final year!
Tim Sturge
Tim’s Answer
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.
Kathleen Carroll
Kathleen’s Answer
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!
