Are there any Computer Engineering/Science jobs that don't require programming ALL day [closed]

Question

I've recently graduated with a BS in Computer Engineering, and I have been looking for a job. I've had 4 internships in the past; they've been at both government and private sector, both small and large. However, I've found the common factor is that they set you in front of a computer, and expect you to code for essentially 8 hours straight. (Edit: When I say 'program', I mean programming and all that it realistically entails. I didn't sit and bang out elegant, functional code all day. I fixed bugs, researched solutions, got fed up and blamed the hardware, etc.)

Now, I'm not a complete fool. I knew that Computer Engineering would involve a large amount of programming when I signed up, and that I'd spend a significant portion of my time interacting directly with computers. However, actually sitting down and considering the next ~40 years of my life would be nothing but this left me feeling a little perturbed.

I don't hate programming; I actually quite like it. I've been working on personal projects while I'm unemployed, and I feel motivated to code in general. But I can't go for >4 hours without feeling completely burnt.

I'm wondering if there are any jobs where I can apply my skillset, while not being trapped working on one single thing for 8 hours every day. I realize that whatever "other thing" I'm doing while not programming will be tied heavily to computing/programming (tutoring, research, writing, etc.), which is totally fine. I just need something to break my responsibilities up.

I'm sure these types of jobs exist, however I don't have the familiarity with the industry to know about them.

EDIT: I wanted to clarify that I didn't spend 8 hours banging out new code. I was working on pre-existing code in almost every case. So of course, I did spend a significant amount of time debugging and working with/learning code that other people wrote. I think it's safe to assume that unless you're developing your own app or working for a small shop, that you won't be creating your own brand-new code right off the bat, and I'm okay with that. However, it felt like 90% of my day was sitting alone in my cube, staring at an IDE window. That's really the part I feel I need to be broken up.

Answer 1

Based on what you tell us, it seems that those jobs that expect you to code for several hours straight may be related to the Software Engineering area of CS (although 8 hours straight sounds a bit exaggerated IMHO).

Those kind of jobs are more code-intensive: a project is designed, tasks divided and assigned, and then it's "just" a matter of coding and coding until all tasks are completed. Depending on the size of company and the practices they have on board this might result in several (4-6) hours of "straight coding"... but in my experience effective coding time can be much less.

Being realistic, if one had no bugs or setbacks then if you coded for 4-6 hours straight most surely the project will be done in a very little time... but there are many other aspects to Software Engineering than just coding like a monkey. When you hit bugs you have to stop and think how to solve them, when starting a new task you have to stop and think how to proceed or consult peers... as we can see, there is much more to Software Engineering than "just plain coding", and if we were able to code without interruptions or setbacks this would run more smoothly.

That being said, there are other areas of CS that are less code intensive. One of them for example is Data Science area.

Generally speaking, in Data Science related jobs you spend more time on the thinking part and less on the coding one, as these projects tend to require fewer lines of code/boilerplate but each line tends to be more significant than other kinds of projects. However, that doesn't mean that Data Science is paradise for CS folks; coding is easy, knowing what to code is the hard part, and Data Science has lots of hard parts on thinking (note: I am currently leading both DS projects and Software Engineering ones)

So, to sum it up. Perhaps you would be more interested in other fields, like Data Science, or take on more lead roles which require a bit less coding and more managing. However, sometimes one has to "climb their way up" and learn your ways, before actually reaching a less code-intensive/leadership job. Expecting that freshly out of College might me a bit unrealistic, but don't lose your hope just yet as you have several other options :)

Answer 2

My nominal software job (one title I have held: Senior Software Engineer) requires that I spent about 85% of my time gathering requirements, figuring out what modules will need to be updated, dealing with “The Business” (non-software people), etc. and about 15% (if it is a lot) doing actual coding. Of the coding time, very little is spent typing. Most is trying to figure out what the code did before and how to make it do what we need now with as little impact as possible. Various boss types around the office want me to offload the coding to junior people but I push back because that is the only part I “enjoy.” I don’t obtain great and lasting pleasure from coding but at least I am not dealing with the id10T s in the business. (Instead while I am coding, I cuss about the “suboptimal” people that worked on the programs before me.)

The application I work on is a Point Of Sale system for a BIG retailer (I’d say there is about a 35% chance you have used it.) A few pieces are OLD, dating from the late 1990s. Parts are new, no more than a few months old. All of it has been written and worked over by people of varying ability. Requirements change and updates have to be made to everything sooner or later.

Count your blessings. When dealing with new code, you don’t have to make updates to badly written code by some arrogant and abrasive coworker who is hostile to anybody touching the perfection of his program, even if it is broken and he can’t be bothered to fix it.

In answer to your question, Yes, such jobs exist but they tend to be more senior level. I guess I would suggest giving it a year or two until you get a little experience on your resume and see about getting a job with more design, etc. and less direct coding.

Answer 3

It isn't actually normal to expect a software engineer to code for 8 hours straight a day, because time spent coding isn't an accurate measurement of progress. Unfortunately, it isn't your job that's broken, it's the work culture you're in.

For a software engineer, your day should be broken up with things like:

• prototyping a new solution,
• standup/team meeting
• research new ABC tools or XYZ features you could be using,
• code reviewing team members,
• talking to engineering manager and/or product manager about a new feature,
• squashing bugs,
• writing tests,
• planning future work,
• splitting up work between multiple team members,
• mentoring interns or more junior team members,
• getting mentored by more senior team members, and
• much more

If that list doesn't sound like you, then a role/career change would be good for you.

Answer 4

I can only go off my experience. In the past decade of working as a web/software engineer I found that on average I do maybe 1-2 hours per day of actual coding, if that. Usually around 10-100 lines of code, max. Rest of the day is spent either researching or figuring out best approaches to problems.

Now it's hard to say what is wrong (or not wrong) about your job. It could be that you're just forcing yourself to write code as long as you can. Could you research, do meetings, talk with teammates, etc?

I heard of sweatshop style jobs in all IT fields. I knew of an animator who was really good at Maya and 3ds Max, he had to work 12-15 hours per day making animations for this company that gets outsourced to draw for some larger companies. He's basically told to sit at his desk and he can't take lunch breaks or do anything else other than animate. He was sometimes forced to come in during weekends to work as well especially when they had a tight deadline or they had to pick up slack.

I observed that these shops tend to be small and frequently advertise open positions (since they are anticipating high turn over). They also have their office space in a factory style setting with a large open space for everyone to gather in like a hanger or open floor stores converted to a "office." Research how a company post jobs online. If you're seeing them bump the same post each week or if some position is posted seemingly indefintely, it might be a sign of sweatshop style development. Check out their glassdoor ratings too.

Answer 5

People have mentioned senior/management positions, but since you have just graduated I am going to offer another potential option that you can explore sooner: working for a start-up/small company! I can only speak from my own experience with this as a junior developer.

I work for a B2B software company that has only a dozen or so employees. Because we are so small, most people have to wear multiple hats - I am officially a software developer but I frequently do all of the following:

• Requirements gathering/researching/planning (solo and w/ clients and coworkers)
• Coding features and bugfixes (solo and with coworkers)
• Give demos/walkthroughs of software for clients
• Perform client installations and troubleshooting
• Updating documentation

Sometimes it can be frustrating if I just want to code but tasks from multiple categories all need attention, but overall having such a variety of responsibilities keeps the days more interesting gives me a better idea of what potential career paths I am and am not interested in.

Answer 6

As a software developer who also does not enjoy mindlessly writing code for 8 hours a day, I would recommend a preference for smaller companies. Larger companies tend to have more specialized roles while smaller ones often require employees to wear a variety of hats.

Having said that, literally any job that has you sit and write code for 8 hours a day is not a good one. If you're not spending more time gathering requirements, talking to stakeholders, thinking through problems, etc. than actual coding, you're probably doing it wrong. The job market is pretty good right now, no reason you should have to be a code monkey.

Answer 7

Note, some of the roles described might not be considered strict CE but prior CE experience is at least very valuable. Sometimes prior "pure" programmer experience is essential and you get to the described role after you work on a code for at least few years, but you were referring much more than 10+ years perspective.

The list probably isn't complete. Also often jobs combine more than one from the list (I've seen plenty of BA/DEV and BA/PM roles offered) in which case your tasks include tasks of both roles (a share might not be 50-50).

Business Analyst (IT)

This one I'll describe from my experience so my answer will be most elaborative here.

A BA role is about gathering and documenting requirements. It might range from understanding the business as a whole, remodeling processes etc. or be focused just on the requirements for a specific application. It may be given different names in a job role description (Functional Analyst, Requirements Analyst) but all are related to the same field.

Most of the time BA does one of 3 things:

• interacting with the business (meetings, workshops, conf calls etc.)
• creating documentation (BRDs, FSDs, Backlog, manuals, data mappings, mockups, GUI design, input to PM managed documents etc.)
• interacting with the devs and other IT people (explaining what is in documents ;-) )

Additionally this work can have some programming (I would say ~10% on average with projects ranging up to max 50%), project management (again ~10% on average with up to 30% for a specific project), testing, training.

Test Analyst

As a TA you're responsible for the QA of the project. You interact more with the product itself than the product source code. TA does a range of various tests trying to validate that the application behaves as it should (also if user does something they shouldn't).

Since the testing is more and more automated, this type of work usually involves quite a good chunk of coding (e.g. to define test robots), but the essential part is elsewhere.

Software Architect

It might sound a development role but it's more about understanding the software. SA's main area of responsibility is to define on how the software solutions should be build to be aligned with the strategic approach. There are two basic types of SA:

• App specific - a person who knows a specific application thoroughly and decides how to apply new requirements in order to keep everything easily maintainable; they ensure following standards for the application (low-level), decide on elements like DB structure, technologies to be used in the project etc.
• Organization-wide - a person who is responsible for defining standards and the landscape of all applications. They may have less knowledge of particular apps, but should know for example how all apps depend on each other, what are the contact points, exposed APIs etc.

Generally speaking first type of SA hands out task details to the code monkeys ;-) while the second type validates requirements provided by BAs from the IT strategy perspective.

App specific SA usually does some coding as well but this coding is limited to the most difficult and interesting areas.

Project Manager

In this role you will be responsible for making things happen. You manage the budget, team, timelines etc. PM reports to the management (sponsors) about the progress of the projects.

As a PM you do not code yourself, but you ensure your project team does the right job.

Line Manager (IT)

As an IT Manager you're responsible for your team (but it is not a project team like for PM). You'll handle things like new hires, people promotions (but also firing them if needed), escalations etc. Depending on the team and company size a manager can also partially do the same job as their team, but it'll usually be no more than 50% of time. Of course a manager can be for any of the teams, so it can be devs manager, BAs manager etc.

Answer 8

Apart from all the options already mentioned, there is also:

• Research. As in people-who-write-papers. You typically do a Master and/or PhD, post-doc, and so on. Mostly at universities, research institutions and very big companies.

• Teaching. At universities, schools, etc.

• Writing (e.g. books, articles). I understand it is very, very, difficult to earn a living just by writing.

• Technical writing. Specifications, user manuals, software documentation.

Answer 9

This depends on what you define as programming and interacting with computers.

I'd agree with you that the thought of sitting in office 5 days a week and churning out business or web based apps for the rest of my life sounds soul destroying. But that is not the only option for you.

For example anything these days that involves manufacturing or heavy industry or shipping will involve computers - and computers require people to program them. And there is nothing like writing code that will control something big and physical, and the there is always a new and different plant being built somewhere.

Case in point, right now I am blocking out the code for one of those cranes that sits at a container port and transfers containers to/from ships. In the past I have also programmed Steel mills, Paper Mills, Aluminium Mills, Waste Water plants, AA battery manufacturing, even a dairy. And in every one of these areas I have balanced design, coding and going on site to get the damn thing working.

So if you look around you will find an endless variety of computer usage in the world, which leads to an endless possibility of career options.

Finally, programming and computers are not static. Over the course of your career you will see everything around change as technology advances, so you will be continually learning in order to stay relevant.

Answer 10

It's hard to code for more than 6 hours straight in a single working day. ~4 hours is a little less than the average you'd expect in a typical working day, but YMMV. The most important thing is what you deliver, not how many hours you give your butt a chance to make a buttprint*.

That said, you might find consulting to be more suitable, as it involves some customer contact and possibly travel. You'd still have to work hard (probably even harder) but it has a different pace to the code-monkey path you're currently on.

Another option is to become a manager. This is on your promotion path for most companies and it's basically programming at scale. Currently you manage one developer (yourself), a manager manages multiple devs. Less programming depending on the company, and you'll have to deal with your peers / juniors.

While you can always get a lucky break, a fresh started is typically expected to do a bit of grunt work for a few years before any of the above open up. But again the world is not immutable and your mileage will vary.

^*_{Let me decode that: You can goof off all you like as long as no one realizes you're goofing off. The best way to do that is to deliver what's expected of you}

Answer 11

If you are literally writing code for 8 hours a day, then you are probably doing it wrong. First, you must be very lucky, working on a green-field project (i.e., no legacy code to interact with at all). I would love to have anywhere near 8 hours of coding time per day. Second, it sounds like you aren't writing any unit tests, or you would have mentioned debugging and refactoring and having the coding cycle being broken up by build/run/test phases. Third, it must be a very small shop, if you don't have to consult with teammates about interactions between your code and the code other folks are working on. Fourth, it's pretty surprising that someone can give you a specification, and you can just immediately start writing code and keep writing code for 8 hours, day after day.

Real software engineers spend a lot of time A) figuring out what it is that should be built (gathering requirements), B) understanding how the new thing fits in with the old/existing things, C) communicating with various stakeholders to make sure there aren't conflicts in design/APIs/etc., D) researching existing solutions, best practices, libraries or other components that you can reuse, etc.

Now, if this doesn't sound at all like your experience, there's a pretty obvious reason why: your experience was all internships. While an internship does a good job of exposing you to the tools and people that you might work with, an intern will necessarily have to work on a project that can be completed in 10-12 weeks, usually. That often requires a fairly unnatural kind of project that the full-time engineers do not get. In particular, it usually excludes one of the most important phases of engineering: design. As an intern, you will usually have a problem and design handed to you, so that you have something to show for yourself at the end of your stay. As a full-time engineer, you will eventually be expected to design the solution yourself. Even as a beginner, you will be expected to have a critical eye and ask questions about what you are asked to implement.

For now, I would say that you should relax. It is almost impossible to find a full-time software engineering position that entails a full 8 hours of coding per day, for weeks at a time. In any interview you get, just ask the interviewer how many hours per day they get to code, and I will bet you a coffee that the vast majority of them will whine about how few hours they get to code, and how much time they spend doing all the other tasks of software engineering (fixing bugs, investigating bugs, dealing with flaky tools, dealing with flaky coworkers, etc.).

Answer 12

Work for a small startup 5-15 people.

You'll end up doing all sorts of other business functions. Project management, requirements-capture, design, testing, systems administration, user experience engineering, dealing with clients/customers, strategy meetings. You'll have to do whatever needs doing right now.

You'll also be very well positioned to move out of software development and into other roles in the company. So pick an industry / sector that you like.

Answer 13

I'll chime in with a different perspective - if you really want to do something other than programming then the best way to do it is to develop secondary skills in other areas. If you can be very good at something other than programming and also have the ability to program then your utility immediately skyrockets.

For myself as an example, my background is in engineering physics, electrical engineering, and material science. I didn't study programming at university but am self-taught and have been programming, as a part of my job, professionally for about 17 years now. It isn't, of course, all of my job.

At the moment I work in industrial automation at a medium sized company so the job also includes lots of hardware (PLCs, robots, motors, motion control, sensors, detectors, and some esoteric physics-y stuff). There is a combination of hands-on work, systems design, mechanical design, and developing automation software, HMIs, etc.

I know of a lot of others also who work in different fields in a similar position. The really critical point is that if you want to do a variety of things in your job you have to focus on developing competence in a variety of things.

Answer 14

The other answers are correct in that you likely won't be spending most of your time coding even in a software development position. I've been a developer for around 8 years now and I can tell you that although I enjoy being in front of the computer more than most people, I am usually not capable of focusing for 8 hours in one sitting. If you gain the trust of your employer then software development jobs tend to have a more lax schedule because they know you get your work done. Some days I work less or more than 8 hours depending on the work load and how much I enjoy the task, but I tend to work maybe 3-4 hours in the morning before eating lunch then taking a nap. After that I'm able to work much better than if I were to continue working without a nap. Getting good sleep, eating healthier and removing time wasting activities such as browsing reddit were also beneficial toward me getting more out of my time spent programming.

The best part about programming positions is that you tend to be measured by your productivity - so figure out how to maximize that rather than how to sit for 8 hours in front of the computer.

Answer 15

There are a number of other jobs that someone with computer science expertise can do. They often involve some programming but it's not the entirety of the job.

• System Administration -- you'll often have to write scripts to automate your work.
• Software Quality Assurance -- writing tests is a form of programming. In some organization, you may work closely with the programmers on fixing the problems you discover; other organizations have a firewall between those departments.
• Technical Support -- determining whether a customer problem is due to software bugs may involve reading the code (at least, I found that helpful when I was a support engineer), and you may be able to work with the programmers to resolve them.

But even as a Software Engineer, there should be other activities breaking up your day:

• Design discussions (but perhaps you're not senior enough to be involved in these yet)
• Responding to bug reports
• Writing specifications, internal documentation, etc.

Answer 16

Yes, there are.

From your description you sound like someone who likes the academic rigour of coding, but finds that there is intense tedium in building solutions. Possibly you also sound like you want more human interaction - determining the issue, creating solutions (not building them) and so on.

Well, there is consulting

If that is the case, then there is consulting.

Typically people see management consultants as stuffy and boring - and hard working. This is true, but consider they also earn considerably more, and the projects are generally 1-3 months, so while you might get a boring project, you might also get a really interesting one. You also work with the brightest and most ambitious. You will get to flex that academic muscle and do research, but without the tedium of actually writing code. You also work with people.

If you want to pull more coding, most big consulting shops also now have a technical arm. There is obviously Accenture, but McKinsey also has a tech consulting division.

Don't fall into the trap of "a coding skillset means writing code".

Also, don't fall into the trap of "a coding skillset means writing code". As it seems, gosh, everyone has noted here, strictly speaking, coding never happens 8 hours a day. There are clarifications, research, considering edge cases and determining optimal solutions, on top of the more CS-based "writing code" and "debugging".

You might think coding is "coding". It honestly isn't. "Coding" is simply using your intellectual capacity in a set manner - but that manner can also be used to solve other problems. The fact that you are trained to clarify, question, investigate and determine optimal solutions is a boon for every single other enterprise and industry. If you are helping a shoe company to determine the optimal factory layout, or for a furniture firm to work out which market to expand to, or if it is worth investing in a certain tech firm - you are still doing all of the above (aside from writing code). That's still probably 5 or so hours of your day!

Oh, other options

OH. And if you're wondering, venture capital needs people with those skills. So does private equity, and trading. Also, forestry management, global warming think-tanks and hospital management.

Finally

Finally, you should strongly consider leaving IT behind if you feel that you don't like working for 8 hours on your own all day. There is significant research showing that the person finds the job. So in sales, you'll typically find people who are naturally enthusiastic and enjoy working with people (and competitive). In IT, you'll find the reverse - risk-averse, shy, dislike interacting with people, perfer working alone.

Now this is a generalisation, sure. But what it also means is if you're naturally outgoing or like working with people then you will struggle to be happy in IT, because very few other people will share those qualities and the work isn't tailored for that personality type.

Answer 17

Any non-trivial project require more than one person working on it (simply to get done faster) and this alone mean that you cannot spend all your day coding as you need to communicate with your team mates. Meetings, discussions, documentation to be certain you are all agreeing, etc.

Also in my experience most coding efforts are not limited by how fast you type but how fast you think, and you typically need breaks.

All that said, the single most efficient optimization of your time you can do is learn touch typing by heart. Not as much when programming (as there are many hard-to-reach symbols) but it helps a lot when writing prose, being documentation or meeting notes or simply just your daily emails.