> <i>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.</i><p>You make a persuasive argument for why someone should <i>not</i> write code every day, but instead step away from the keyboard occasionally and get a sense of perspective.<p>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 <i>cause</i> problems, by adding another random pointless format for the rest of us to have to support.<p>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.<p>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.