Write code every day
brett.is
brett.is
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?
echo "Hello, world"
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.
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.
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_...
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.
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.
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.
I 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.
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.
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)