Can someone describe a normal day working as a computer science?

There will always be variation, of course, but with multiple answers you should be able to build a picture.

I majored in Computer Science in college, but am working as a Software Engineer at Google. This is a very common path, but is technically different from going into Computer Science itself as a job. That would likely involve a lot more theoretical work than I do.

On a typical day at Google, I start by checking my email (a large part of the company is in California, three hours later than me, and we use email a lot, so there tends to be a large amount that built up over the night after I went home), and then figure out which of my projects to start working on. Sometimes I had a program that needed to run for a few hours execute overnight, and so I base my start on the results that were reported.

The division of Google I'm in has a large, complicated program, which most of my work revolves around. I usually have a handful of different projects involving it at once. Right now, I'm adding a feature for a customer, investigating whether we can change from one source of data to another one, improving some testing tools for the main program on to make better use of Google's infrastructure, and I'm involved in finding places to clean up our code base, in addition to various other small tasks.

On any given day, I pick a project (based on what other people are waiting on, when I get results of old tests, and simply what I feel like I can make progress on) and start working on it. I don't actually spend that much time writing new code in the main program, but I spend lots of time examining it to see how it works and how to add new pieces, and writing tests for the small changes that I do make. I also write a lot of smaller programs, to help me with things like data analysis and making tools for myself and others to use.

I usually work on a couple of my projects at different times during the day (when I get stuck on one, or have a meeting, which usually happens at least once a day, I use those as boundaries which spur me to shift projects).

I work for around 8 hours a day, though it can vary slightly depending on if I'm making a particularly large amount of progress on something and don't want to leave. I don't let myself make a habit of staying longer than 8 hours, though, since some engineers do that and it degrades their quality of life.

While working, I try to stay fairly focused, though have a variety of ways to take small mental breaks, such as quick chats with my friends (online at work, in person at work, or online with people not at work) or websites like Google News. I find that I'm most productive when I give myself brief chances to rest.

So, there you have it. Get into work, check email, cycle among projects (which means writing code and looking at data) until I go home. I greatly enjoy it, though it's not for everyone.

Greetings, Eddie!

I am pleased to see a variety of answers to your question, above.

Having weathered the "dot-com-bomb" of the late 1990s, worked for several tech startups and large(r) companies since, I am happy to ofder my personal response to your question.

In addition to the linear, often repetitive tasks outlined in this thread by other professionals, I will add the variable of "On Call" which generally applies to computer science types (bona fide engineers) who work within the framework/infrastructure of Global Foundation Services (GFS), also sometimes referred to as: DevEng, DevOps, SiteOps, TechOps and/or ITOps.

The vast majority of a Tech organization's operational infrastructure consists of teams of On Call engineers who share a rotational Duty Roster (which defines an escalation path of "Whom Shall I Contact in a Customer Affecting Outage?"). On Call engineers in Network Engineering and/or Site Reliability Engineering (SRE) typically support one or both of a company's revenue stream: Corporate and/or Production.

Production resources (routers, switches, firewalls, virtualized application server clusters, database clusters) typically reside in physically secured, climate-controlled datacenter environments. When something breaks, On Call teams are called into immediate service. The longer a customer-affecting issue (unscheduled e-commerce website related maintenance, for example) goes unresolved, the more revenue is lost - and the more thoroughly a company's reputation is damaged.

As an On Call Network Engineer, I wear multiple hats, often simultaneously:

• First Responder/Triage Agent


• Network Architect (sometimes)


• Troubleshooter


• Problem Solver


• After Action Evaluator

I have worked as long as 52 hours straight (in a worst-case scenario) in the past; however, my average day is 8-12 hours of project-based, pre-planned (i.e. - proactive versus reactive) work. Within the dynamic context of the Internet, few environments remain fixed/unaltered for long. The constant, profit-driven pace of Big Business demands that equipment and data circuits be upgraded and fine-tuned - seemingly endlessly.

If you think you might enjoy fast-paced, almost 100% academic work (and don't mind the frequent EXTREME stress and occasional GRUELING hours), a career in Network Engineering or Site Operations may prove to be well-aligned with your aspirations.

Fiscal compensation is reasonably good (and certainly quite acceptable to most); however, the type of work I perform daily is considered utterly unacceptable by many who value and insist upon as static, unchanging and predictable work-flow and "work-life-balance," as seems to the popular HR/recruiting term "de rigueur"). I know no fewer than 5 peers who hold/have held similar posts who have endured divorces from their spouses specifically due to the interruptive, unpredictable nature of their work.

"Your mileage may vary."

I hope this helps.

Good luck out there!

It truly depends on the type of environment you are working in. With service/product related jobs around computer science, you will find yourself working in ether a waterfall or agile based senario.

Under a waterfall (or as I like to call waterfail) mentality, you will find yourself coding on several projects at once an not have very much communication with the client besides at the beginning and end of the project. If you are working in an environment like this, it is very important to only developed what is promised. There is no room for change.

The other method is called Agile. This is an iterative based mentality where you work on one project at a time and communicate with the client thoughout the project. You will still find yourself coding a lot, but will have more interaction with the client and co-workers throughout the project.

Note that these don't reflect the type of work you will be implementing, just the way your work is delivered.

I'm a test engineer, so my experience is a bit different than the average developer, but a lot of the procedure is the same:

I get into the office around 9:45 am for our stand-up meeting at 10 am, in which we talk about what we did yesterday, what we're planning to do today, and if anything is blocking us (i.e., if there's something stopping us from moving forward on or completing a task). It's a short meeting, just to make sure the team is on the same page.

After that, I check my email -- being an engineer in a startup means my inbox is usually blissfully empty. I worked at Amazon before this, though, and I'd have to sift through a good amount of email every morning.

Then I pick up whichever project I'm working on for the day. We try to avoid having meetings in the afternoon, but we're a startup and even we can't do it 100% of the time. At bigger companies, meetings generally occur throughout the day. My projects usually consist of writing automated tests to exercise new features, diagnosing test failures, reviewing developers' code, and occasionally doing manual testing of a release or feature set when automated testing won't work out well. It definitely varies from day to day -- not boring! I like to say I get paid to break other people's stuff, which is actually fairly accurate.

I'm generally in the office 9-10 hours a day, but that's typical for a startup, and our ideals promote having a healthy balance between work and the rest of your life. I'm sometimes in the office more during crunch time when we're, say, working to make a deadline, but those times are rare, and the perks make up for it. (Software developers are, in general, spoiled rotten.)

So, to summarise, get in, sync with my team, check email, work on projects -- write code, read code, test code, look at data -- and then go home around 6:30 or 7 pm. Much like Eric from Google up there, I enjoy it very much, but it isn't for everybody. :)