What does a typical day of a computer programmer look like?

I was a programmer for a short time, a long time ago. I moved form there into software quality assurance, so I was able to associate with programmers/developers for a number of years. Many of the ideas I share below are common no matter what the profession is.

Rather than tell you about a typical day, let me address a typical week. I want to include things that I wish I would have known very early in my career.

In addition to the immediate project you are working on, there are a lot of long-term things you need to put time into, across the weeks and months. Everything from professional development (including attending webinars) to maintaining your health, from preparing presentations for others outside your organization, to community service.

For me, the thing I find very valuable is to plan my week with the long-term objectives, and then to set aside time each day to review what was done that day and to plan the next day.

Let me refer you to a book. The Seven Habits of Highly-Effective Teens by Sean Covey. There is a chapter titled Sharpen the Saw. pages 206 to 242. The basic idea is don't be so busy cutting down the trees that you don't have time to sharpen the saw. Or in other words, don't be so busy driving that you don't have time to get gas.

Mr. Covey suggests there are four areas you need to plan activities in each week, that will help you keep your saw sharp. Body, Mind, Heart, and Soul. I will let you read what he says.

You also want to grow in your ability to perform the job. One of the ways to do this is to improve in your ability to manage a project to completion on time. One thing I have always wished I would have done better is accurately estimating how long it takes to complete a job.

One way to do this is to improve the accuracy that you have to estimate how long it will take you to do a job. Examine the project, figure out how big it is, and make an initial guess. Keep track of how many hours you work on it, and compare it with your initial guess. Then figure out what caused the differences. Keep a personal record of this, by project, describe the nature of the project is (how big, how many hours you estimated, how many hours it took, and how many "defects" ended up in the final product.) That way you have the data to back up your statements, when you give your manager an estimate of how long it will take you to do a particular task. And you can show how accurate you have been in estimating past projects.

This is something you can start right now with your homework. So by the time you graduate from college, you will have a large amount of data and a lot of experience estimating your productivity.

The benefit of this is that you become accurate at estimating the time it will take to get your assignment completed and that will include the time it takes to fix problems. you become trustworthy in the eyes of management and your peers.

You also want to develop good relationships with those you work with. This takes time and effort. It does not happen automatically. Make time in the week to strengthen your relationships. The benefit of this is people know you and like having you around. And that means, when they are choosing team members for the next project, they will choose you. Not all team members are people you want to have on your next team. So in addition to building stronger relationships, strive to improve in your ability to be the kind of person that people like to be with.

That does not answer the question about the typical day, but it gives you a picture of the kinds of activities you need to work into your days during the week as a professional, so you can be successful over the long term.

Hi Matthew,

I'm sure there are very many different answers to this question depending on where the programmer works, what type of program they're making, what role they have among programmers, and other factors. I've only ever had one professional job, so I'll answer this question only from my point of view.

I work as a support web developer at a very professional, but chill company. As a web developer I have nearly no compile time. I've heard stories of programmers who will sometimes start compiling their code, go get lunch, and still have to wait for the compiling process to finish after they get back. For me, I almost never have to wait more than 5 minutes for code to compile.

As a support developer, I am not creating new sites, but I'm adding new features or fixing bugs on existing sites. Since it's usually less work to maintain a site than to create one I actually work on three separate sites. Even in a single day I'll often do a small amount of work for each of my three sites--often working with a co-developer on one or two of those sites.

My company is professional, but chill. We have project managers who talk to the client, get their requests and send it along to the developers. They will then schedule meetings with me to talk about the site and make sure everything's proceeding at a good pace. I'm also in a small team of three other developers. We meet occasionally just to check up on each other and see if anyone needs help with anything. All of these things are good and productive, but they cause a good amount of distractions from actual programming. Since the company is chill though, I do not live in fear of my boss or of failing. I actually have good relationships with everyone I work with including my boss.

In all, I'd say my typical day involves 1-3 hours of meetings (most of which directly relate to a specific site, but not all); less than an hour of reading emails and the occasional computer maintenance; and finally programming to fix 1 large issue or up to 4 smaller issues. Usually, there are occasional things that I have to deal with for another site that distract me from the 1-4 main issues, but they rarely distract me for long. Towards the end of each month, the sites begin to stop me from programming much more for them as they hit their monthly budget max. I'm usually resourced pretty full though, so if one account is out of hours another account probably still has time.

I hope that helps you out! Please do not take my comment as your only source for the project as it's limited to my specific environment. Hopefully other people will respond and give you an idea of what it's like for them.

Regards,
Kenneth

Meeting time, coding time, support time (making sure legacy systems are working ok), planning time (figuring out what to do next) are probably the 4 biggest chunks (not in that order).

Those will vary significantly across companies, level of seniority, or just where you happen to be in a planning cycle. For example about a year ago at this point in time I was having maybe <1 hr a day of meeting, 5-6 hr coding, and 1-2 hr everything else. A couple months ago when we were in the middle of planning, I was doing maybe 2 hrs of meetings, 1 hr of coding, 3 hrs planning, and 2 hrs fixing legacy stuff.

But I would say the 4 big types I do on a regular basis are:
-plan/design what code to write,
-actually write code,
-figure out how/why code is broken (and fix it),
-and meetings (hopefully the meetings help make one of the other along, often the plan/design bit + meetings get kind of jumbled together).

Also as you move up and learn more stuff, another big work item you tend to take on is:
-help other devs by answering questions, walking them through things, teaching, etc

Also as you get more experienced, and more familiar with the specific systems you're working on, the time it actually takes to write code decreases drastically, and you spend more time planning what to do.