Skip to main content
6 answers
6
Asked 1664 views

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

+25 Karma if successful
From: You
To: Friend
Subject: Career question for you

6

6 answers


0
Updated
Share a link to this answer
Share a link to this answer

Vandhana’s Answer

You can choose job roles like Developer, programmer, Architect etc whose primary responsibility is to write code to build a product or a software. However companies are looking for coders who have additional key skills like communication, problem solving, coordination etc. He/she should be able to think out of the box from customer's perspective. He/she should be able to analyze requirements thoroughly before the design is documented and implemented.
0
0
Updated
Share a link to this answer
Share a link to this answer

Kathleen’s Answer

I agree with Paul that it is less about the position title and more about the company and product you work on.

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!
0
0
Updated
Share a link to this answer
Share a link to this answer

Tim’s Answer

Hi Anina,

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.
0
0
Updated
Share a link to this answer
Share a link to this answer

Prashant’s Answer

Hi Anina! I can totally relate as to why you are asking this question - I had a very similar mindset in college as well. I was really passionate about coding and coding practices, and I wanted to just code, and not deal with the additional baggage of writing tests, worrying about CI/CD, reading documentation, figuring out internal tools, etc. I was always looking to work on components that were "code heavy" and once coding was done, to hand it over to someone else and start something new...

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!
0
0
Updated
Share a link to this answer
Share a link to this answer

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.

Thank you comment icon That makes a lot of sense! Thank you for clarifying :) Anina
0
0
Updated
Share a link to this answer
Share a link to this answer

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.

0