Is it as simple as knowing how to code, sitting down and typing lines and lines of code out? That alone sounds complex to me, but I assume once you know how to code, it is a easy as speaking your native language?

I ask as I often ponder taking courses in programming, but I'm still quite unsure on it. Hell i need to know coding to get into testing, so I'l need to learn coding regardless.

---

http://automission.deviantart.com/

Just from my experience in programming internships, we work as a team.

Start of the week, we generally had a little meeting discussing what would get done and who would do it.

So generally speaking, you were given a problem and allowed your own way to solve it (the part I love).

Day to day after that consisted of coding up said solutions. If we were working in a language I wasn't familiar with, you can bet there was ALOT of research to be done on my part, using both company learning tools and google. Also, all members of the team were usually using a chat service so I could IM them quick questions to answer, or if they were particularly complex I'd walk to their cubes.

Since our dept. was small and I had been brought in to meet a pretty big deadline, we didn't really have time for proper testing. But testing is a huge part of being a programmer. So after you *think* you've got a working solution, you have to test it from every possible angle you can think of, maybe even get someone else to do testing for you. Afterwards, you go back to the inevitable rewrite of your code so that it works properly. Rinse and repeat until you have either run out of bugs, or run out of ways to fix bugs. Assuming you don't have any bugs or only have very, very tiny inconsequential ones, then you go to code review.

That is, usually around the end of the week, we'd review code written and discuss how it works, why you did things certain ways, and how you came to the solution. Other programmers might point out constructive criticisms to make the code more efficient, or find a potential security issue, bug, etc.

So, while there is plenty of coding day in and day out, there are also many other things you need to do to ensure organization and well-written code.

---

Philosophical Ninja.

A day in the life of a coder is probably better as a week in the life of a coder.

For me, before a single line of code is written, our group sits down in several design meetings. We identify the problem we wish to solve, attempt to narrow the scope as much as possible as we get input from the other departments our code serves.

Once we have the requirements set, we discuss methodologies and break the project down into smaller units that can be given to developers. We devs then try to map out on paper/flowchart what we intend to do and the logic we intend to implement to create some initial documentation. This will usually then be reviewed in yet another meeting to make sure we're on the right track. Next we'll stub out some unit test harnesses. Then we finally start coding. After coding, we'll run our code against the Unit test harnesses, and have another meeting to make sure what we just coded solves the problem, determine if scope changes, or otherwise adjust the project as well as do code reviews.

On the daily side...

First thing in the morning is usually checking and responding to emails. Getting called into meetings. Spending a decent part of the morning going over the bug tracker and doing fixes. Then start working on the actual current project. Lunch, afternoon meetings, then back to working on current project. Near end of day, another sweep of the inbox, a glance at the bug tracker if you need to prioritize something for the next day. Make sure your code is checked back in to your specific dev branch of the code repository in case your machine crashes overnight, and go home.

When I'm coding, what happens in my day is generally ignoring e-mails, sticking my headphones on and drinking coffee while hammering code out furiously. I tend to work at home a lot when I'm doing this so I can't be disturbed.

When I'm in the office and trying to get the requirements for something nailed down, my day to day life is largely political as I try to convince people of a need to do things properly, to choose the right technology for the job and learn new skills if necessary.

I'm not just a programmer though, I'm the technical lead on an "enterprise" (they like that word) product and that generally means I have to speak to a lot of people in order to work out what the hell the business wants from the development team.

You'll find different people assume different roles and do different things in their day depending on their skill sets.

I'm largely technology oriented, and I'd like nothing to get in the way when working with technology. I work with a few other people who end up managing the project even though they're just meant to be programmers.

In a newer company, in a company where they had more formal practises and etc - things would be more formal and people would have roles assigned to them that reflected the job they do - but from what I've seen from talking to other people in the industry it's largely quite disorganised and people just do what they're told to do.

My day to day life is one of being grumpy at people for interrupting me, drinking a lot of coffee and listening to music whilst writing code and checking Twitter and Facebook.

It's a productive life.

---

I have no idea what I am talking about

I am an intern programmer at a large fortune 500 company.  I entered the internship with knowledge of C++, and C#.  Due to licensing issues etc. I ended up having to create a training simulation in ActionScript 3.0 for Adobe Flash.  This is a language I had never worked with and knew nothing about.

The first two weeks of development I went through tutorials in a book.  Each lesson I did I kept in mind my overall goal for the project.  Each day while taking these tutorials if anything I was learning seemed analogous to what I would need to do in the final game I would slightly modify it and then I'd have one little piece of my game prototyped.

After I went through all the tutorials in this book I was all on my own.  I would come to work each day and say, ok, I need to get this small part of the game completed.  Then I would come up with a way to tackle to problem using code in my head.  I would make mental notes of every little thing that the game was doing and figure out how to handle each of those things.

I kept going through what I intended to be the final outcome for the current chunk of the game I was working on.  I would imagine how it would all play out on the screen and behind the scenes and not leave any stone uncovered.  Most of the time while doing this I scribble notes down on my best friends, Post-It notes.

Then I'd get into the code and write it all up, making comments along the way so I didn't come back and get lost.  I'd test after I had enough to make something new happen on screen and if it didn't work properly I'd go back and fix it before I moved on.  If it did work I'd try to break it by doing things other than what I am expecting my user to do.

The next day I would either continue refining code from the day before if it never was completed yet, or move on to the next system I needed to complete.


I would say 40% of my time is planning algorithms and scribbling notes, 15% of my time is writing code the first time, and 45% is running the code and going back and rewriting things to get them to work properly.