Live data from Hacker News

Write Code Every Day

ejohn.org

171–180 of 221 posts

Re: Write Code Every Day

#171
post #23

In the long run, this is unhealthy. Yes, it makes you more productive, but what if you fall in love, get sick, have a child...? Then you feel guilty about not catering to your side projects and guilt breeds procrastination. I learned how to break down work into small pieces and rather finish one small piece and then call it a day instead of leaving something half-working for the next day. Because of this, I left proj…

There's a time and a place for both.

If you are a constant procrastinator, forming good habits, even on trivial stuff, reconnects you with why you need to do the work, and prepares you for getting started.

But after awhile, you find that you're just working, and need to produce. So it switches to deliverables.

My only life hack addition: instead of calling it a day, pick what you are going to set for your next completion goal before you quit. This was a Hemingway hack to make sure he could get up the next morning and start writing immediately. I've found that even the most informal mental commitment the day before solves the starting problem and ends up producing more positive streaks. It is great at overcoming (and preventing) any kind of "block".

Re: Write Code Every Day

#172
post #150

Earlier quoted context omitted.

> what are your self-publishing plans (if you don't mind discussing them)? The book will remain freely available in web form in its entirety. When I put up the last chapter, that will include a nice redesign that should hopefully make it pleasant to read across most devices. Soon after, I'm going to start working on an eBook and print version. I'm not sure how I'll do the eBook yet, but I'll do some investigation. Th…

I'd recommend Leanpub[0]. They accept markdown and their workflow is pretty easy and non-exclusive. For my book[1] I just used pandoc and Makefiles, but once the school year ends and I turn my attention back to the book getting it up on Leanpub is a priority. [0] https://leanpub.com/authors [1] https://learnjavathehardway.org/

Yup, leanpub is one of the things I've started looking into. :)

Re: Write Code Every Day

#173

I am a total convert to the "don't break the chain" idea. I started writing a book on game programming[1] about four years ago. At the time, I was working at EA, miserable, and highly motivated to have the book done so it could help pad my resume. I got a book deal (O'Reilly) then, when that fell through, another (Apress). I had a real writing schedule, and a very supportive wife, and I would work on it for hours at…

Did you work on Madden at EA (since you mention it in the intro)? If so I'd love to read more about the architecture of that. I've always wondered how offensive/defensive line interaction and AI worked -- among a million other things. And the book looks good!

> Did you work on Madden at EA (since you mention it in the intro)?

I did, though I didn't really touch gameplay. I was a UI programmer on Madden PC 2002 (Oh God that's over a decade ago now, what happened to time?) and I worked on the first version of Madden for the X360 doing mostly animation and tool pipeline stuff.

I'm not the best person to ask about it, but the part that blows my mind is that the "AI" for the game is deeply tied into the animation system. Madden has hundreds (thousands?) of individual player animations: runs, tackling, blocking, catching, you name it. The AI works roughly by searching for an animation that lines up with what it wants to do.

For example, if the ball is coming towards a receiver, it looks for a catch animation that will put his arms in about the right place and that stitches together well with the animation he's currently playing. If it finds one, then it transitions to that animation and makes the catch.

This means the producers who are building and tuning the gameplay do much of it by tweaking animation: changing timing, deciding to add more animations of certain types, etc.

As far as I know there is no holistic set of data or code that says, "this is the AI of Madden". Instead, it's just the sum of all of these animations.

Re: Write Code Every Day

#175
While Resig's dedication is admirable, I'd caution against applying his advice too broadly. He is doing it because he has side projects that he wants to complete. There's no reason to force yourself to code every day for coding's sake.

I've been doing a lot of side-project hacking the past three months, as evidenced by my Github activity graph (https://github.com/zhemao), which, admittedly, is not as impressive as Resig's. However, this week, I finished up my latest side project and found myself at a loss for new ideas. At first, I did feel a bit guilty about not doing any coding, since it had been a long time since I had nothing to work on. But then I realized that there's more to productivity than a nice contribution graph and sometimes it's good to take a step back in order to think, reflect, and get inspiration.

I'm currently reading through Patterson and Hennessy's "Computer Organization and Design" to learn more about computer architecture. I'd also like to practice my saxophone some more, start learning how to draw, help a friend who is still in college find a job, and expand my social life a bit. My Github account will still be there when I am ready to get back into it.

Re: Write Code Every Day

#176

Telling a programmer to write code every day is a bit like asking an aspiring carpenter to swing a hammer: it's a necessary component of improving your skills and building things, but it is also a narrow, technical task that has limited value in isolation. Having said that, programmers should spend at least as much time reading and thinking about code as they do writing it. You can write code for hours each day and d…

I'm going to go out on a limb and say nearly everyone reading programming blogs don't need to be told this, but a large fraction of them do need to be told to "get shit done"

Re: Write Code Every Day

#177

Earlier quoted context omitted.

I have been in the same boat as you when it comes to side projects, but I'm curious about your use of the metaphor of "sucking the marrow from the bones" because that metaphor is typically used to describe completion to an extreme. For example, if "eating an animal" was your metaphor for working on a side project, I think that a more apt extension to that metaphor would be "leaving meat on the bone" rather than "suck…

Yeah, probably. Also I didn't think it through either. I extract the goodies from whatever I'm learning, and never finish the project I'm learning from. My attention shifts as soon as the project stops being interesting & new, and becomes "work" to finish up.

You gotta think of your project as you think of a woman you are in love with, otherwise, there's no sex. I think there is a lot in common between love, advancing in a project and even picking a movie to watch - they all involve a kind of 'sexual' openness towards the subject.

Re: Write Code Every Day

#178
post #33

Telling a programmer to write code every day is a bit like asking an aspiring carpenter to swing a hammer: it's a necessary component of improving your skills and building things, but it is also a narrow, technical task that has limited value in isolation. Having said that, programmers should spend at least as much time reading and thinking about code as they do writing it. You can write code for hours each day and d…

I'd agree with you if my primary desire were to improve my ability as a programmer. Unfortunately, at least at this time, it's not. My major concern is getting meaningful work done. I spend far too much time thinking and reading about technologies, techniques, and planning for the future - more time needs to be spent on actually implementing all the amazing stuff that you want to exist.

I'd agree with you if my primary desire were to improve my ability as a programmer. Unfortunately, at least at this time, it's not. My major concern is getting meaningful work done.

FWIW, code I don't have to think about tends to not be the meaningful part of a project.

Post reply on HN