Ask HN: How many hours do you spend coding per day? | Hacker News Reader

Ask HN: How many hours do you spend coding per day?

11 pointschunky199419 comments

How many hours do you spend, writing/thinking about code? Any advice on how often a beginner programmer should code?

My answer to the second question would be to spend as much time on it as you find enjoyable. If you don't find any amount of time programming enjoyable then you're going into the wrong field.

As an example when I was first starting out I would spend 8+ hours a day programming because I found it to be a lot of fun (this was when I was in middle school, after being in school for a full day)

Currently I'm 23 and work at an early stage healthcare IT startup and I still get the same feeling from programming as I did when I first started, and I can spend hours working to solve all the problems that popup throughout product development. Sometimes I get so wrapped up into solving a problem that I have a hard time falling to sleep because my mind is constantly thinking about how to solve it, and I actually do tend to come up with a lot of my solutions during the 10-15 minutes before I finally get to sleep.

I might be predisposed to programming though because my grandpa was a programmer for over 25 years and I was always fascinated by his stories on the job

I totally get that! I started writing code when I was 11. Now I'm 25 and I too am kept awake late nights thinking of problems I can solve and things I want to implement the next day. I often get so wrapped up I get tunnel vision, work obsessively, and I still can't keep up with all the cool stuff my mind brings back to me when it wanders late at night.

I do enjoy programming a lot! Most often though, I find myself solving random problems, I begin to feel that my programming isn't really going anywhere, for example, how do you start writing application software? I mean, it's certainly interesting, but I can never get myself to actually write such a disciplined piece of code, partly because I don't know how.

The problem that stops a lot of people is that they see something cool and they want to do it too. The problem is that you can't just start off writing a GUI app from nothing. You have to get the basics down first.

For software you first have to understand the basics of procedural programming and write simple programs that run in the terminal. When I learned C++ I first learned simple 'cout >> "whatever"' programs with if statements. Knowing this kept me from being frustrated because I understood I had to climb the proverbial "ladder".

I'm a web guy and I'm able to make some pretty cool interactive stuff now but as a beginner I had trouble changing background colors and floating elements in a row.

That's the thing that stops people. They're frustrated because there's no easy way to learn how to do the things they see and want to copy without learning the absolute basics first. Patience is a serious virtue when you're a programmer.

Well, I've written a few simple applications, but what I can't really get is how to actually start on a big application? I mean, do you just have to break it down into little pieces and then put them into a whole? Isn't this a very frustrating method of doing so? Is there a better method? Or is this a necessary vice you'll have to overcome?

Modularization is a good thing, not a bad thing. With a large project its better to think of it as a set of components rather than one whole. At my current job we are stuck with a large monolithic legacy application and everyone is in agreement to break it into modules, which we are currently working on. Try to pick out the core "units" of a project that can be relatively self contained and work on those first. You should learn not to worry about starting with the UI, the UI shouldn't necessarily drive a software development project.

You're definitely showing your inexperience with that comment and that's okay, you'll learn. Even when you're writing procedural code you have to break it down. That's what programming is all about. It's really the beauty of it. By breaking down your app into a bunch of smaller problems that you solve you make it much easier on yourself.

I think you should look into learning object oriented programming concepts. Breaking things down is a really good thing. Not only is your code easier to maintain but it's easy to test and extend. If you were to write one giant program all at once and it fails to work then you have to tackle hundreds of lines of code. By building things as modules you are able to implement functionality one class at a time and know one thing works before moving to the next.

My advice would be not to try to start a big application. If I knew what you wanted to build I could be more specific but let me give you an example. Let's say you wanted to build a music player. Instead of tackling a huge iTunes clone start by creating an app that simply lists and organizes music files in a particular folder. Then add support for playback. Then playlist creation and so on. Taking on too much at once is a noob mistake that kills the motivation to learn before you get anywhere. There was a 3 year period where I almost gave up on programming because I tried to skip over the fundamentals and got frustrated. Take it slow.

I'm a web guy also

I started off working on random problems with PHP then I started working at a 1 person web development company where I learned a lot in terms of frontend development and cross browser compatibility issues and database work. Now I'm using all of the skills that I learned over the course of the years in this new startup where I'm the lead technology guy. I also picked up Ubuntu server command line administration in addition to assembling servers and deploying them.

Give it time and if you maintain the interest you'll end up learning a lot of cool stuff that will be helpful throughout your future

12-13 on some days - I work full-time and then spend a few hours working on an open source project. I don't intend to always do this but right now I have a reason I'm working on the open source project (Specific goal) so am doing it for now. When I first started I would literally spend 15 hours some days because I was trying to cram a lot of learning into a small period of time.

The personal project time is much more productive, the 8 hours of work, I guess, is questionable as to whether its "Writing code" as a lot is wasted wrangling with the legacy app I have to deal with, debugging old legacy code, etc but even though its writing less code I find it far more stressful than working on my own project where I am mainly writing code.

I don't advocate anyone work for an employer by spending more than 8 hours a day working unless you're being paid really well but when you work full time and want to get stuff done outside of work its inevitable that you have to spend extra time coding.

I've never been reliably productive for more than 4ish hours of code per day.

When stuff is exciting or trivial it's easy to get list and spend longer, but in general I consider it a good day of I wrote for 4 legitimate hours.

Four consecutive hours? Is this without snags in your code?

I'm the same. In fact, I track my hours but only productive hours. It usually comes out to about 4 hours per day. There are those great days when it could be as high as 6 or 7 but those are rare. In fact, I've found that if I try to push myself and do more than 25 hours per week, I tend to get sick much easier.

Three or four years ago, maybe 10-12 hours spent on thinking about programming, probably no more than half that spent actually writing code.

Today, I'm burnt out and have written only a single line of code in the last month, for recreational purposes. Took about two hours of work. Ugh.

I program in spurts of 15-20 minutes throughout the day for a total of about 4-5 hours. If you're not employed in a traditional sense I find it best to write your code when you're in a super motivated, super stoked frame of mind because you'll write better code and have more fun doing it.

At the moment I'm in a busy phase so it's higher than usual, but I'd probably say 5 or 6 hours coding. At least the same on top in thinking/planning. I'm not as productive this way but right now I have near constant phone calls for updates and any perceived slacking is unacceptable :(

Just writing code? I spend several minutes a day.

Just thinking about it? Oh, a good 8 hours a day.

How much do I actually get done? Nothing, and I am such a horrible programmer.

From 2 to 4 hours. Everyday.

All day... At least that's how it seems. I often work a 12 hour day but not all that time is actually spent writing code. Like others have said, being in the right frame of mind is key. Coding isn't like other things where you just have to force yourself and practice. When you code and you're not in "the zone" it often feels like you never sat down to write code at all.

That said, there are times you will have to force yourself anyway. As a beginner I would tackle a project you think is really interesting and work on it until it turns out as you'd imagined. Copying things others have already done is a great way to learn if you don't cheat and just copy/paste their code and call it yours.

It alternates between 5-ish hours per day, and 12-ish depending greatly on the project, how focused the work is, and my mental state (how burned out I am).

I work as much as I feel I can, and no further.

Reply on news.ycombinator.com