What is a typical week for a computer programer? What are some important key points to look for in while applying for coleges to ensure a benefical education for computer science?

The company and the industry have a lot to do with your typical work week but computer programming is usually demanding. You will usually have a schedule and deadline to work against and depending on the issues that you run into, how much effort and how many hours to spend to finish your deliverable can vary.

What to look for while applying for colleges for a CS degree? the school ranking, the curriculum they offer, how up to date and relevant the courses are, how meaningful the courses are to the job market and the problems of the real world, the quality of faculty and peer students.

As another answer says, a "typical week" will be very different from job to job, but here's a sketch from one of my previous development jobs, as an example. This is a really long answer, but I hope the tangible detail is useful. I'm focussing just on the first of the two questions you've asked.

I think this sketch would be somewhat familiar to a lot of programmers or software engineers once they have a few years' experience. (Entry-level roles might feel a bit different, but you probably won't stay in an entry-level role for many years!)

In a typical week, there would probably be at least one day, sometimes many, where I didn't really do any "actual" programming at all. Making software is about a lot more than just writing lines of code; the hard part is knowing _what_ to write. Once I had experience, I was expected to do a lot of the figuring out what to write, as well as the actual writing. This involves buzzwords like requirements gathering, specifications, software design, or software architecture.

Bigger corporations will typically have dedicated people who do each part of that, so a developer will just write code - but in smaller companies, it's fairly common to expect developers to multitask and look after the whole process of creating the software. For me, this is one of the best and most rewarding aspects of the job - the variety that this end-to-end responsibility brings.

My company was pretty much all based in one office building, so the "figuring out" was mostly done in meeting rooms, face-to-face, with small groups (3-5 people, different skill sets). Lots of talking, sometimes whiteboarding, sometimes lots of writing things down as we made decisions or worked things out (sometimes not!). Sometimes we'd all be stuck on a tough problem, pretty much sitting quietly together and thinking hard, throwing a few words out occasionally until someone got an idea that moved us forwards. Sometimes we'd disagree about the best way to do something - then we'd have to really make sure we understood each others' opinions, and if we still thought ours was best, work to try to 'sell' it to the others through logic and reasoning. Usually we all reached agreement voluntarily - sometimes the boss had to come and break the tie!

So verbal communication skills, and abstract problem solving, are two things I use a lot that I didn't necessarily expect to when I started my career. The problem solving sometimes involves math, but often it's just logic and creativity, plus knowing different programming 'patterns' that could be helpful.

Aside from design meetings, which were intense, technical and fun, there'd also be meetings for the sake of project management (keeping track of how long everything's taking, and when we'll hit certain milestones, or how much we'll have got done by the end of the week, etc). These are sometimes necessary but not so fun usually - working out how long the programming will take to actually do can be difficult. There are different approaches to project management out there - 'agile' methodologies are the hot thing these days, but not every company is totally agile, partly because sometimes customers don't like it.

And then there were also some meetings for communicating with customers - where I was usually invited just to make sure I knew what was said, not to participate much, or sometimes even just for the 'show' of having a developer in the room.

So, quite a lot of meetings. When I wasn't in meetings, there's also a lot of other communication - email, or other collaboration platforms (instant messaging, Slack-type tools etc). Sometimes there'd be a lot of writing down and documenting (in plain English) what the design was going to be, because it mattered a lot to the customer. So I'd sometimes end up writing a pretty comprehensive prose English version of the software, before writing any actual code.

Naturally, in any office job, you also spend a certain portion of your time walking to refill your coffee cup, swapping stories from the weekend with colleagues, or helping others work through problems with their projects, as a fresh pair of eyes or ears. Then there's also practicalities like performance reviews, non-project related team meetings, time for training or skill-sharing, etc, that take up time here and there.

After all this, in a 'quiet' week, I'd only spend maybe 32 out of 40 hours (assuming I was in work 40 hours a week - in reality, it was often more) actually at my desk looking at code. In busy weeks, maybe only 8 hours!

Sometimes, all of that time was spent writing new code furiously - getting the basic structure of a project ready, or implementing things we'd already worked out exactly how to do. Oftentimes, programming time still meant problem solving - working out on my own how to achieve what I wanted in the language, or how to do it most efficiently. So I might spend an hour focussed on one source code file and one task, but only generate a few lines of code at the end of it. Researching on the internet was certainly a part of development - checking how other people have solved similar problems in the past, using resources like Stack Overflow / Stack Exchange, as well as documentation for the programming language or libraries. This doesn't stop as you gain experience - the kind of things you search for just get more complex and esoteric.

Then there's debugging - fixing typos and errors in the code - and testing - running the code and checking it does what I expect, or writing separate test code to check that for me. Sometimes I'd have to revisit older code (or someone else's code) and rewrite it to be more efficient. The kind of software I worked on was very data-driven, not browser-based web apps or something: I also had to be good at exploring the data going into and coming out of the software, and using that to figure out whether the software was doing the right thing, or why it wasn't. Oftentimes I'd find problems with the input data, and have to describe that problem to the right person who could fix it.