Hacker News Reader

Comment by hawkharris | Hacker News Reader

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 do nothing but revert to the technologies and techniques that you find most comfortable.

View on HN

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.

As someone with the opposite problem/concern, can I request your strategies for reading and thinking about technologies and techniques?

There are a number of technologies that I'm interested in right now (machine learning, "NoSQL" databases, graph databases, computer vision analysis, Node.js, amongst others) so I will just casually read about these things as time goes by. When the time comes for a new project I'll try to use one of them (but usually only one, too many new technologies and you're spending too much time just learning APIs). This has helped me to continually pick up some new techniques. Not sure if this is a silver bullet but it's been working pretty well for me. I try not to stress too much about jumping on the latest tech - I'd much rather wait and have others try it out and let me know if it does/doesn't work!

I agree. I have the habit of constantly learning, without producing. So I'll pick up side projects, suck the learning-marrow from their bones, and discard them without finishing.

I have so little to show in terms of actual work product, which I am attempting to fix with a similar "don't break the chain" approach.

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 "sucking the marrow from the bones". However your metaphor refers to the marrow as "learning-marrow" which confuses the larger metaphor that is "eating an animal".

Have I completely misunderstood the extended metaphor you were trying to use?

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.

i know it's usually frowned upon to make jokes on HN, but it's amusing that this comment seems be sexualising everything and your user name is an anagram of "viagras"

It's actually a word in Sanskrit, meaning creative energy, but it has a secondary meaning of seed / discharge. And my comment sexualizing the relationship between a dev and his work is not a joke - I really believe that thing that allows us to enjoy such work that other find repulsive is a kind of attraction similar to sex. I'm using this insight for finding a good attitude towards my work - you know, you gotta admire the curves before you get into the mood. :-P

Exactly it is more of an exercise of discipline. Discipline is not simply achieved, it is a constant challenge.

I have the exact same problem, I love learning new stuff, thinking about new projects, mentally designing code and UIs... but I do much less of actual coding done than I would want to. One reason is that once the novelty of the project wears of, it becomes a boring routine work.

maybe if you keep your projects in the "really small" size bin you can actually finish them before the boredom sets in. and the positive feedback loop might even prop you up to see a bit bigger projects through.

Yes, that's about the only way I finish projects. I try to make very short-term milestones.

When I think too much my ideas change; what was once meaningful is not anymore. Feature creep is the other problem: as time passes features creep in and I never move out of the design phase.

I can appreciate that perspective, and there must be value in your approach if the quality & amount of code you produce is any indication. (As an aside, I really enjoyed Secrets of the JavaScript Ninja; that book changed the way I think about JS.)

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.

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"

The best way to employ the things you learn and discover when reading and thinking about code, is to write code. All the reading and thinking is no good without the part where you write code.

True.

The statement "Practice makes perfect." is false if you don't invest time in reading, thinking, doing retrospectives of your work. The 50/50 ratio seems fair enough.

I see your point but I don't think when John says "Write Code Every Day" he means writing without thinking. Of course any decent programmer knows thinking about the architecture, pattern, design, data structure and algorithm while writing code is paramount.

What I see him saying is that practice the art of coding every day but you can't write code without thinking so it's kind of implied to me.

Agree with both you and enterx.

For me the interpretation is to not just write code everyday, but write QUALITY code everyday. Quality code that improves what you're working on, challenges you to learn new things, and contributes to the development of this skill.

Otherwise I could write hello world for 30 minutes a day.

Reply on news.ycombinator.com