"Reference"-style humor is not upvoted on HN, since the audience lacks the common context, and the site doesn't provide a way to hide minor comments for those looking for major comments, which makes them expensive to readers.
Lol, that article when it came out was incredible. The author somehow failed to realize that "ABC", from Alec Baldwin's psychopathic character, is actually satire about the mindset of such psychopaths, not actual advice to live by.
It's similar to asking why I think Malfoy in Harry Potter is portrayed as a bad person. There's nothing subtle about the GGR character. I recommend watching the movie, primarily for the performances.
Actually, spend time with your kids every day. Or your special one. Or kitesurfing. Or playing pool. Or just learn about chess and play folks in the park.
Do other things and let your mind expand and bring those benefits to your code. It will make you a better coder (and person) and life will actually be interesting.
I think his point is quite obvious, which is basically "don't forget there's a life outside of the tech world".
I know that I'll sit here doing nothing on the Internet when I'm not constructive yet the hours still fly on by. Realistically, I should realise when things won't get better, get up, go for a walk or play with my son. On the off chance I've done this in the past, I always feel more refreshed and can turn a previously crappy day into something positive.
But sitting on your chair, punishing yourself because you don't know what to do/code, isn't very effective in bettering yourself.
I totally agree with this. And is actually a really good point I missed in my article.
You cannot, and should not, force yourself to sit in front of the computer non-stop just because you "should". You need to take those breaks too, they are just as important as the work you put towards mastering your craft.
I agree with this if you code at work, or in school. For someone trying to pick up coding as a hobby or potential new career coding daily could really help solidify skills.
Yes, do all of that, and remember, you may still have some time left to code every day, if that's what you want. Doesn't mean finish a big project every day, but you can advance it, or not, something just for the heck of it. Even if it usually does, coding doesn't have to come at the expense of life.
And what if I don't enjoy those things? My only hobby is writing code and I'm fine with that. I don't see why I should resist my will by forcing myself to do other things instead.
No, he's asking you to back up your claim. If you're going to make a statement like that, you should be prepared to provide some information. Dont make others do the research.
Off-topic, but why did you decide not to go with YAML? Did you just want a version of YAML that wasn't whitespace-significant? Forge just looks like an nginx-y YAML, with no arrays and `=` instead of `:`.
Was mostly just how it turned out. A lot of the decisions were mostly arbitrary, I wanted something that look/felt like an nginx config but was more generic (didn't have application specific directives), it just so happened to end up looking a lot like yaml.
'=' was arbitrary, I think paired with ';' I was going for a programming language type feel, which might not of been the best decision, but it is what I did. I also have plans to add more features, there currently are references (pointers essentially), intend on adding list/sets, operators (merge/concatenation/substraction/union/intersection/etc) and being able to reference environment variables. Not sure what else is to come.
Also, side note, I found writer a parser that deals with brackets '{}' to define blocks was much easier than trying to do it via whitespace. So that decision was mostly a time based decision.
> More times than not the above exercise leads me to a problem that I then can go off and solve. For example, a few weeks ago I sat down and decided I wanted to write a web server in go (think nginx/apache). I knew going into the project I wanted a really nice and easy to use configuration file to define the settings. So, I did what most people do these days I and used json, but that didn’t really feel right to me. I then tried yaml, but yet again didn’t feel like what I wanted. I probably could have used ini format and made custom rules for the keys and values, but again, this is hacky. This spawned a new project in order to solve the problem I was having and ended up being forge, which is a hand coded configuration file syntax and parser for go which ended up being a neat mix between json and nginx configuration file syntax.
You make a persuasive argument for why someone should not write code every day, but instead step away from the keyboard occasionally and get a sense of perspective.
No, your mix between json and nginx configuration file syntax is not "neat". It's pointless, and doesn't solve any real problem. In fact, if anyone ever uses your idea it will cause problems, by adding another random pointless format for the rest of us to have to support.
And did you miss the beginning of what you said? You set off to write a web server and instead you got bogged down in parsing the config files. Your efforts did not produce a web server. Writing code every day has apparently not taught you how to focus.
In short, quantity of code does not beget quality. Quality code isn't just code that's nicely formatted, clear, terse, etc., it's also code that solves a real problem that you've set out to solve. And just writing more code isn't going to help you learn what a real problem is, let alone how to solve it.
The goal, as stated, was to have the experience of writing code. Bringing another web server into existence was not the goal, it was a potential means to the goal.
For the same reason athletes have practice routines that are not "play a game of <sport>" -- it allows you to focus your practice. If OP wants to practice writing nontrivial code, re-implementing something is a good way to avoid the MORE difficult problem of having to invent a product. It allows him to concentrate on having a nontrivial coding experience.
As an aside, I personally code just for fun. Not for practice, and not to make something. I write a lot of code nobody but me will ever see because I enjoy doing it. Putting pressure on myself to turn each thing into a product can ruin the joy of experimentation. I'm doing it for the joy of doing it, for the same reason I might watch TV or play a video game or do a sudoku puzzle.
You can solve real world problems with code without creating a product. Things don't have to be monetizeable to be useful (and indeed many things that are monetizeable aren't useful (except to make money)).
And experimentation is totally a necessary part of solving real-world problems. I'm not sure where you get off representing "solving real problems" as being anti-experimentation.
The reason I responded to someone else rather than you is that you do not appear to be making much of an attempt to understand the things you are replying to. You are, to my best estimation, simply being argumentative. For example, in your previous post, you said you could just write echo "Hello World" over and over, which clearly does not give you any practice at writing code and is clearly not related to the conversation. In this post you talk about monetization, something I didn't mention at all, and while "product" may not have been the best possible word I could have used, it makes me think you didn't make much of an attempt to understand my point.
> For example, in your previous post, you said you could just write echo "Hello World" over and over, which clearly does not give you any practice at writing code and is clearly not related to the conversation.
No, it definitely is practice at writing code; it's just not useful practice. My point is that not all practice is useful. If you're going to accuse me of not making much attempt to understand my point, maybe don't dismiss what I said so easily?
As an employee, yes. As a hobby, who cares what he makes? Maybe his config parser is shit, maybe it is the shit. Either way it wouldn't exist without his efforts.
It existing is at best no better than it not existing.
If you're advising other people to change their behavior (i.e. code every day) then the "why" of the advice certainly matters. It's true that I have no reason to care, if he wants to bash his face into the keyboard and call the results code, that's fine, but if he comes and posts on hacker news about how everyone should bash their faces into their keyboard, I don't feel the need to pretend what he's doing is great because "it wouldn't exist without his efforts".
It was clear to begin with, thanks, it's just wrong.
Practice does not make perfect, perfect practice makes perfect. If you practice doing things wrong, you're just reinforcing a bad habit.
And make no mistake: solving solved problems and losing focus on the problem you set out to solve are bad habits, every bit as bad as writing code that segfaults or leaks memory or throws exceptions.
If we are always expected to write new, different, useful, quality code that solves real problems, then no one would ever start programming in the first place.
Everyone needs to start somewhere and maybe for a veteran coder the expectation is to solve new real problems, but for those just starting out, writing and re-writing basic conditionals and loops are more important than solving real problems.
Each project should end in learning something new. For me this config parser (whether anyone actually finds it useful or not) was learning how to write a scanner/parser from scratch. To try and fill a void in my knowledge, rather than solving real problems.
If we aren't expected to write new, different, useful quality code that solves real problems, then there's no reason anyone should start programming in the first place.
Everyone needs to start somewhere and maybe for a complete beginner expectations are low, but if you're not veteran enough to solve real world problems then you are in no position to be giving advice like "code every day" on the internet.
The nice thing about solving real world problems is that you'll inherently learn something new, not just to you, but to humanity.
And lets be clear here: you didn't learn how to write a scanner/parser from scratch, at least not a good one. To do that you would have to read literature and/or look at production code. It's unlikely that you've figured out decades of parser research with your lexer/parser--it's much more likely you've just reproduced a bunch of mistakes that were made and solved in the 60s without even realizing they were mistakes. You could actually learn how to write a good lexer/parser by reading a handful of academic papers or reading through the code of, say, PLY or working with a parser toolkit that exposes its workings like Parsec.
On the face of it your advice sounds sensible, but is it actually possible? Can you rest your brain? You can do things that feel like they're less effort mentally but your brain is still doing just as much work - things that feel nicer are just releasing a different combination of dopamine and serotonin. Is there actually any difference in the amount of energy you use doing "down time" activities? What mechanism is your brain using to recover?
First, most athletes do train every day. Even tapering before an important competition involves training daily. I ran track and XC competitively in high school and college. Some of my teammates hadn't missed a day in years. Most of us only skipped training if we were injured or very ill.
Second, the brain is not a muscle. Sleep deprivation and stress hormones can diminish its abilities, but no amount of thinking or drudgery can damage it. Neurons can't tell if they're reading, playing video games, or debugging code.
An examination of history also supports this. A mere century ago, people toiled far greater for far longer than we do today. The average work week was over 60 hours![1] Despite such exertions, even the concept of burnout didn't exist. It still doesn't exist in some cultures, and in the cultures it does, burnout doesn't affect everyone. Unlike sleep deprivation or physical exhaustion, some people just don't burn out. If you start looking at studies, you'll find papers like, Is burnout separable from depression in cluster analysis? A longitudinal study.[2] The answer: no. So far, researchers haven't been able to reliably differentiate between burnout and depression. This indicates that burnout is depression, not a guaranteed consequence of working.
Of course, one should still be wary of depression, and work is one piece of that puzzle. Yet work alone is neither necessary nor sufficient to cause ruin. Exercise, social gatherings, and friendships are equally (if not more) important.
As one more piece of evidence that work alone doesn't cause burnout, I submit myself. I have written code every day for the past 908 days.[3] That's almost 8% of my existence. Those commits aren't just whitespace or linter changes. Every day, I write real code that runs in production. I also exercise, socialize, and generally live a fulfilling life. People sometimes voice their concerns about burnout. But to me, it's as if they'd asked, "Are you worried about getting burnt out from reading so much Hacker News?"
There's also the lovely condescension that I can't help but sense when someone tells me why writing code every day shouldn't be as fulfilling as it is. That's a big part of how some people get a sense of fulfillment, myself included. I suck at drawing and painting, and programming is my main creative outlet. Implying (or sometimes stating!) that I should be spending less of my time coding so as to spend more time doing something that they find more fulfilling is... rude at best.
Nobody said anything even remotely rude, let alone "rude at best". Nobody said you don't find coding fulfilling, and nobody said you should do something they find fulfilling. Nobody said coding isn't creative, either.
I think if all one does is code then the vast possibilities life offers is being ignored.
I don't know any athletes that train 7/365, although in fairness, I only keep up with several dozen (ex- and current clients, and trainers that I work with).
The level of training we work at is more intense than typical; the body breaks itself down and fails after too much of that. If we consider walking to be "exercise" then sure, I suppose they "work out" every day.
Regarding [2], without reading it yet, if it isn't separable, then it could be burnout or depression. Not being able to distinguish between the two doesn't mean they're the same thing, it means precisely what it it says--you can't tell which it is.
The bottom line is that everybody is different. Some people will get burned out, some people will get depressed, some people will be both, some people won't.
"Micro-rests", e.g., having a fulfilling life outside of whatever the cause of burnout/depression is, is still rest.
Many athletes I know practice every day, or nearly so; they may not do high intensity workouts every day, but not all practice is high intensity workouts.
And the physical reasons for resting between high intensity workouts don't apply to intellectual activities, and AFAIK don't have a clearly established direct analog that does, either.
While I appreciate the sentiment when you set your goal as coding every day, that becomes your hammer to solve every problem.
The best example of this is your confguration project. I am amazed how many well-intentioned projects there are to do with configuration when really all you need is environment variables. No libraries, works everywhere, with every language and easy to understand.
"Hey hey hey..." yep, that one doesn't quite work either.
"Do you want to know the secret of life? [I'll] tell you the secret of life: it's not the amount of time we have... it's not quantity and it's not even quality. It's variety." - Bardo the Just, Neverness (by David Zindell)
For me the whole point of technology is to free us. I want to write code that solves a real problem. 90% of my time is spent thinking about what problem to solve.
I see a lot of negative comments here. The point being missed is doing something is better than doing nothing.
Yes he might not have ended up finishing with the web server what he started. But I'm pretty sure he did NOT set out to build something that would be a product or a startup someday. He set out to do something repeatedly, so that he becomes good at it and uncover new problems that are interesting to keep working on. None of this relates to productivity or writing the best code possible.
You start out with something; end up finding pleasure in doing something else; then you keep on doing it until you've written enough code to know where you stand and keep improving.
The take away for me is this. As for me it always was the chicken to the egg problem. I need to be keep working to find new problems. However, I need to start somewhere with a problem that I don't know yet. Trying to rewrite existing stuff was something I'd do to learn new tech. Now it hits me that I could use the same, to keep my fingers stuck to the keys.
I'd love to read more writes like this. Sharing how you overcame something is noble. It helps more people than you anticipate.
65 comments
[ 2.7 ms ] story [ 128 ms ] threadI have not read the play, seen the play, or seen the movie.
I guess I need to add the movie to my backlog now.
http://www.cracked.com/blog/6-harsh-truths-that-will-make-yo...
My opinion is that both viewpoints have merit, and it is very dangerous to embrace one and dismiss the other.
Do other things and let your mind expand and bring those benefits to your code. It will make you a better coder (and person) and life will actually be interesting.
I know that I'll sit here doing nothing on the Internet when I'm not constructive yet the hours still fly on by. Realistically, I should realise when things won't get better, get up, go for a walk or play with my son. On the off chance I've done this in the past, I always feel more refreshed and can turn a previously crappy day into something positive.
But sitting on your chair, punishing yourself because you don't know what to do/code, isn't very effective in bettering yourself.
I hope that's what OPs point was. :)
You cannot, and should not, force yourself to sit in front of the computer non-stop just because you "should". You need to take those breaks too, they are just as important as the work you put towards mastering your craft.
It helps. Just one little thing, doesn't need to be big. Just something.
Except that's wrong...
The first couple of results are great. However, if you really are interested, I would look through Google's entire first results page.
'=' was arbitrary, I think paired with ';' I was going for a programming language type feel, which might not of been the best decision, but it is what I did. I also have plans to add more features, there currently are references (pointers essentially), intend on adding list/sets, operators (merge/concatenation/substraction/union/intersection/etc) and being able to reference environment variables. Not sure what else is to come.
Also, side note, I found writer a parser that deals with brackets '{}' to define blocks was much easier than trying to do it via whitespace. So that decision was mostly a time based decision.
I wrote an article about the project here: https://brett.is/writing/about/forge-configuration-parser/ It doesn't give any good details into why I made the decisions I did, just a quick overview.
You make a persuasive argument for why someone should not write code every day, but instead step away from the keyboard occasionally and get a sense of perspective.
No, your mix between json and nginx configuration file syntax is not "neat". It's pointless, and doesn't solve any real problem. In fact, if anyone ever uses your idea it will cause problems, by adding another random pointless format for the rest of us to have to support.
And did you miss the beginning of what you said? You set off to write a web server and instead you got bogged down in parsing the config files. Your efforts did not produce a web server. Writing code every day has apparently not taught you how to focus.
In short, quantity of code does not beget quality. Quality code isn't just code that's nicely formatted, clear, terse, etc., it's also code that solves a real problem that you've set out to solve. And just writing more code isn't going to help you learn what a real problem is, let alone how to solve it.
As an aside, I personally code just for fun. Not for practice, and not to make something. I write a lot of code nobody but me will ever see because I enjoy doing it. Putting pressure on myself to turn each thing into a product can ruin the joy of experimentation. I'm doing it for the joy of doing it, for the same reason I might watch TV or play a video game or do a sudoku puzzle.
You can solve real world problems with code without creating a product. Things don't have to be monetizeable to be useful (and indeed many things that are monetizeable aren't useful (except to make money)).
And experimentation is totally a necessary part of solving real-world problems. I'm not sure where you get off representing "solving real problems" as being anti-experimentation.
No, it definitely is practice at writing code; it's just not useful practice. My point is that not all practice is useful. If you're going to accuse me of not making much attempt to understand my point, maybe don't dismiss what I said so easily?
If you're advising other people to change their behavior (i.e. code every day) then the "why" of the advice certainly matters. It's true that I have no reason to care, if he wants to bash his face into the keyboard and call the results code, that's fine, but if he comes and posts on hacker news about how everyone should bash their faces into their keyboard, I don't feel the need to pretend what he's doing is great because "it wouldn't exist without his efforts".
Does that make it more clear for you? Or do you want to troll some more?
Practice does not make perfect, perfect practice makes perfect. If you practice doing things wrong, you're just reinforcing a bad habit.
And make no mistake: solving solved problems and losing focus on the problem you set out to solve are bad habits, every bit as bad as writing code that segfaults or leaks memory or throws exceptions.
Everyone needs to start somewhere and maybe for a veteran coder the expectation is to solve new real problems, but for those just starting out, writing and re-writing basic conditionals and loops are more important than solving real problems.
Each project should end in learning something new. For me this config parser (whether anyone actually finds it useful or not) was learning how to write a scanner/parser from scratch. To try and fill a void in my knowledge, rather than solving real problems.
Everyone needs to start somewhere and maybe for a complete beginner expectations are low, but if you're not veteran enough to solve real world problems then you are in no position to be giving advice like "code every day" on the internet.
The nice thing about solving real world problems is that you'll inherently learn something new, not just to you, but to humanity.
And lets be clear here: you didn't learn how to write a scanner/parser from scratch, at least not a good one. To do that you would have to read literature and/or look at production code. It's unlikely that you've figured out decades of parser research with your lexer/parser--it's much more likely you've just reproduced a bunch of mistakes that were made and solved in the 60s without even realizing they were mistakes. You could actually learn how to write a good lexer/parser by reading a handful of academic papers or reading through the code of, say, PLY or working with a parser toolkit that exposes its workings like Parsec.
Athletes don't practice every day, they rest.
The brain needs rest, just like the body. Take some down time. Come back refreshed. Practice deliberately.
First, most athletes do train every day. Even tapering before an important competition involves training daily. I ran track and XC competitively in high school and college. Some of my teammates hadn't missed a day in years. Most of us only skipped training if we were injured or very ill.
Second, the brain is not a muscle. Sleep deprivation and stress hormones can diminish its abilities, but no amount of thinking or drudgery can damage it. Neurons can't tell if they're reading, playing video games, or debugging code.
An examination of history also supports this. A mere century ago, people toiled far greater for far longer than we do today. The average work week was over 60 hours![1] Despite such exertions, even the concept of burnout didn't exist. It still doesn't exist in some cultures, and in the cultures it does, burnout doesn't affect everyone. Unlike sleep deprivation or physical exhaustion, some people just don't burn out. If you start looking at studies, you'll find papers like, Is burnout separable from depression in cluster analysis? A longitudinal study.[2] The answer: no. So far, researchers haven't been able to reliably differentiate between burnout and depression. This indicates that burnout is depression, not a guaranteed consequence of working.
Of course, one should still be wary of depression, and work is one piece of that puzzle. Yet work alone is neither necessary nor sufficient to cause ruin. Exercise, social gatherings, and friendships are equally (if not more) important.
As one more piece of evidence that work alone doesn't cause burnout, I submit myself. I have written code every day for the past 908 days.[3] That's almost 8% of my existence. Those commits aren't just whitespace or linter changes. Every day, I write real code that runs in production. I also exercise, socialize, and generally live a fulfilling life. People sometimes voice their concerns about burnout. But to me, it's as if they'd asked, "Are you worried about getting burnt out from reading so much Hacker News?"
1. https://en.wikipedia.org/wiki/Working_time#Gradual_decrease_...
2. http://geoff.greer.fm/files/Bianchi_20R__20et_20al__20_28in_...
3. http://geoff.greer.fm/images/github_streak_908.png
There's also the lovely condescension that I can't help but sense when someone tells me why writing code every day shouldn't be as fulfilling as it is. That's a big part of how some people get a sense of fulfillment, myself included. I suck at drawing and painting, and programming is my main creative outlet. Implying (or sometimes stating!) that I should be spending less of my time coding so as to spend more time doing something that they find more fulfilling is... rude at best.
I think if all one does is code then the vast possibilities life offers is being ignored.
I'll grant you that a lot of people (a) assume coding isn't a creative act, and (b) assume that what they enjoy everyone will enjoy.
The level of training we work at is more intense than typical; the body breaks itself down and fails after too much of that. If we consider walking to be "exercise" then sure, I suppose they "work out" every day.
Regarding [2], without reading it yet, if it isn't separable, then it could be burnout or depression. Not being able to distinguish between the two doesn't mean they're the same thing, it means precisely what it it says--you can't tell which it is.
The bottom line is that everybody is different. Some people will get burned out, some people will get depressed, some people will be both, some people won't.
"Micro-rests", e.g., having a fulfilling life outside of whatever the cause of burnout/depression is, is still rest.
And the physical reasons for resting between high intensity workouts don't apply to intellectual activities, and AFAIK don't have a clearly established direct analog that does, either.
The best example of this is your confguration project. I am amazed how many well-intentioned projects there are to do with configuration when really all you need is environment variables. No libraries, works everywhere, with every language and easy to understand.
http://12factor.net/
Fix cars every day.
Perform brain surgery every day.
Fly passenger jets every day.
Flip burgers every day.
Hmmm. Doesn't really seem like a great idea.
"Do you want to know the secret of life? [I'll] tell you the secret of life: it's not the amount of time we have... it's not quantity and it's not even quality. It's variety." - Bardo the Just, Neverness (by David Zindell)
Yes he might not have ended up finishing with the web server what he started. But I'm pretty sure he did NOT set out to build something that would be a product or a startup someday. He set out to do something repeatedly, so that he becomes good at it and uncover new problems that are interesting to keep working on. None of this relates to productivity or writing the best code possible.
You start out with something; end up finding pleasure in doing something else; then you keep on doing it until you've written enough code to know where you stand and keep improving.
The take away for me is this. As for me it always was the chicken to the egg problem. I need to be keep working to find new problems. However, I need to start somewhere with a problem that I don't know yet. Trying to rewrite existing stuff was something I'd do to learn new tech. Now it hits me that I could use the same, to keep my fingers stuck to the keys.
I'd love to read more writes like this. Sharing how you overcame something is noble. It helps more people than you anticipate.