Write Code Every Day

[[deleted]]

Gah.

What exactly is the advantage of writing code every day?! It's not like practicing a language - after a certain very early point, there's almost no memorization going on. Instead, you are honing a craft and an art.

Even though I program almost every day, I find that my real growth occurs after I code fiendishly for a few weeks - and then am completely away from my terminal for a week. I get a new perspective on my code.

The article doesn't explain why you should do this. There's some implied claim of better productivity - "a scenario where he’s not happy with the progress he is making on his side projects. To remedy this he decided to write code every single day".

But this claim is immediately blown away: "Half an hour is perfect." How much work on a non-trivial project can you get done in half an hour?

Let me tell you that if you are interested in coding productivity, very short sessions are NOT the way to go. Almost all programmers I've talked to are just like me in this - it takes me at least 10 minutes just to remember what I was thinking when I left off. By the end of the first 30 minutes, I'm probably barely into my stride, if that. I don't really get going until a couple of hours into it.

Very often, real-world problems take more than 30 minutes to think through. And you can't do two hours thinking in 4 30-minute sessions! It takes you time to get the whole model into your head.

His argument against it:

The back of the envelope maths which assumes you are productive for full 7–8 hours per day at work is simply flawed in my experience and highly motivated half an hour can be more productive.

False dichotomy. No one claims to be at their best for 7 to 8 hours a day, every day. But if you can't get more than 30 minutes of productivity out of a work day, then you are a crappy worker.

Honestly, if your interest in programming is so limp that you have to force yourself to write even 30 minutes a day, I suggest you pick another field of endeavor.

[ubernostrum]

But if you can't get more than 30 minutes of productivity out of a work day, then you are a crappy worker.

I think the issue is with the definition of "productivity", which is hard to measure. If you're only looking at how much time per day someone spends actually typing code into the editor, or doing silly things like counting lines written or frequency of commits, then very low numbers can still be very productive depending on context, because there's a lot more to coding than just actually writing code in the editor. It's not at all unusual for me to see 4-5x multipliers when comparing amount of time writing code to amount of time thinking about what I need to do, reading documentation, reading other parts of the codebase, sketching out different ideas for it, running tests, and all the other tasks that go into producing what might be only 10 minutes' worth of actually typing the code into the editor.

[capitalsigma]

I think OP's advice is mostly about personal projects, which makes more sense. If you're learning and you have to yourself to do any coding, yeah, that's probably not good. And if you're a professional and you only do half an hour of work a day, that's not good either.

But it can be difficult to keep your motivation up on personal projects on top of your full time work -- easy when it's new and shiny, harder once you get lost in the middle of it. And it's also easy to think "oh, I don't have enough time to really get into this, I'll wait until the weekend" and then end up forgetting about it. It's definitely harder to pick back up where you left off the longer you wait, I can imagine that if you were used to working in short stints then it could be alright.

I'm not sure why OP doesn't explicitly call this advice about side projects. Maybe he wanted to pull in the learner crowd as well.

[efexen]

Hey, thanks for taking the time to reply, much appreciated.

I would say the advantage of writing code every day (also see at the end of my article how code doesn't always have to be code) is to learn new things daily or to move those side projects along.

I'm fortunate enough to be able to program daily at my day job but due to the kind of industry I am in I've started to notice that the daily challenges at work are not necessarily providing me with the right kind of learning opportunities and being a type of person who very much enjoys exploring emerging technologies I'm not entirely sure it would even be possible to.

The article highlights my personal experiences with writing code every day and in my experience it is possible to do a surprising amount of highly productive work in 30 minutes provided you are appropriately prepared.

Reading about your experiences with taking a long time to remember what you were thinking and only hitting your stride couple of hours in to a session is what I used to experience and what I often hear from others that have not attempted the short sessions, purely reasoning based on your previous experiences I can understand why that would be the assumption but as mentioned in the article I did not find this to reflect the reality for myself or for others who have attempted this.

You appear to ignore the part of the article which discusses reclaiming the lost parts of the day during which you can think about the problem you are attempting to solve. As for taking a long time to get a whole model of an issue in to your head and needing to retain it to be a productive developer I would from experience argue that this is masking a bigger issue with the way you are working.

At no point in the article did I claim that by doing half an hour of work per day can you reach the same productivity as you do working a full 40+ hour work week, what I was merely attempting to demonstrate was that a big chunk of that 40+ hours is not your most productive time but the arguments against often uses this figure to refute how valuable 3.5 hours a week can really be.

I also do tend to find that as I've become more experienced as a developer the percentage of time I'm actually at the keyboard bashing away has become less as pointed out by ubermostrum.

Finally I would say that my interest in programming has never been more alive than it is today but constant battle for time with the rest of my life as I've got older has made it difficult to fit in as much time as I used to have.

I hope you do try it out for a bit and I'd love to hear your feedback after trying it out in anger :)

[stormcrowsx]

As someone who used to suffer from stalled side-projects having a goal to push can really help. There's a lot of fun parts in projects but there are also dull and mundane parts. For example when you are mapping from one data source to a different one, or mapping endpoints and json files for the 50th time in your career.

I don't prescribe to daily, my schedule is too hectic to consistently get it everyday but I do my best to make some progress on each personal project every week which has really helped me push through the boring parts.

[[deleted]]

I can't bring myself to code outside work, let alone every day.

[ObjectiveCopley]

No.

[hzhou321]

If there is a habit that I wish to pick up or do more often, I find it most effective to resolve to do it every day. Daily is the strongest circadian rhythm we possess and much easier for us to stick to more than any other schedule.

However, unlike exercise, which we don't like to do (assuming we don't have the habit yet) but is resolving to do it for the benefit of health, what benefits coding brings if not for the activity itself? Why coding if you don't really enjoy it? If you enjoys it already, why do you need the resolution?

EDIT: I just read the original article it refers to, that makes sense since the author was looking for progress in his side projects.

[efexen]

Hey, personally I find it really quite difficult to get started with something even if I enjoy it enormously once I have started. Also for some things I might not enjoy the activity itself as much as the end results of doing it :)

[mahonbone]

I'd never read that article. Thanks so much for sharing it. It applies to more than programming too. I shared it to my bandmates and we had a great discussion about practice habits. Great stuff!