Just to be controversial, the biggest thing I disagree with is the number of hours people code. Hmm... That's not exactly true. I agree with the statement th

Just to be controversial, the biggest thing I disagree with is the number of hours people code. Hmm... That's not exactly true. I agree with the statement that few people code more than 4-5 hours a day. What I disagree with is that you shouldn't try to put your self in a situation where you can exceed that. There is a lot of communication that is necessary in programming. That communication takes time. However, there is a lot of communication that is unnecessary, but that still takes time. Being efficient with communication means that you can spend more time coding. I big part of that is working on smaller teams. Some tasks are inherently separable -- they don't require a lot of communication in order to complete. Some tasks are not. Frequently teams are built on the premise that the work is separable. You'll have 100 (or even 1000!) developers working on the same thing, and the assumption is that this will speed development. Often it is not true. Often it means that you are spending 80-90% of your day coordinating with others. There is a certain amount of communication that is necessary when you are getting requirements. One of the places where we can be inefficient at communication is with these requirements. There is a balance between getting enough information to be able to start writing code and spending your time building fictional descriptions about what you are going to build. If you spend too little time doing up front analysis, you will end up spending a lot of time iterating to your goal. If you spend too much time doing up front analysis you will strangely end up in the same situation -- the thing you thought you wanted to build turns out to be wrong because it's hard to test your assumptions without having the real thing to test it with. Knowing how to surf between these two extremes will dramatically reduce the amount of time you are spending -- and will ultimately reduce the number of conversations you require. I will say, having worked on a lot of different kinds of teams, that if you are not spending the majority of your day writing code, then there is a problem. You should try to solve that problem. Even though writing code is tiring, it is also fun. There is nothing wrong with finishing for the day and feeling like you don't want to write code. It's a good feeling. Go home and spend time with your friends and family. Get some well deserved rest and then go back to work the next day for some more fun. The last thing I would say is that sometimes people feel like if they aren't typing, then they aren't programming. Typing is only a very, very, very small part of programming. Even if you wrote on average 1000 lines of code a day (which would be quite a lot, no matter what you say about LOC metrics ;-) ), you aren't going to spend more that an hour physically typing it in. Almost all the time you are programming, you are either reading code, or thinking (or both). When I talk about increasing the amount of time you spend programming in your work day, I don't mean increasing the amount of time you spend typing. You might not even increase the number of lines of code you type. You might even reduce the number of lines of code you type (if you are really going well). What I'm talking about is increasing the amount of time you have to think about your problem. Even if that's thinking aloud with a pair programming, or mob programming, or getting advice from someone -- it's all good. But you should have the feeling that you are doing something that is directly adding value to what you are working on. As programmers, we are there to put the rubber to the road. We aren't primarily paid to organise, or prioritise, or argue, or negotiate, or produce status reports (whether written or oral). We are primarily paid to advance the project in directly measurable ways -- there is more appropriate functionality at the end of the day. Anything that is stopping you from doing that should be viewed with suspicion. This is what I wish all starting developers would learn ;-)