[ionrock]

At some point I think it is important as a programmer to take pride not only in the result of the code, but the code itself. Efficiently managing a project can and should be rewarding as well. Developer usability is a very important feature. As a programmer, we write and iterate on code until it is ready to be published to the upstream repository. Our tooling has come about to help take our rough and ugly hacks and massage them into well written code we can be proud to push.

Also, banging out code is overrated. I've found that when I take time to think, my actual coding becomes closer to what you see in the movies. I can find my flow and quickly materialize my ideas, and most importantly, solve the problems that arise. When I try to just "code" it ends up being poorly designed and written.

The point here is that when you do have the desire to "just code" take a step back and consider taking pride in the code you publish. The tools and systems in place are there to make you a better code publisher. The goal is to write well written code that others (including yourself) can maintain. Rather than being frustrated you have to deal with the intricacies of rebasing or 3-way merges, take a moment to understand these skills will help you publish better code.

[mattgreenrocks]

The desire to "move fast and break things" keeps you firmly in the 1 year of experience repeated 5 times camp. They teach you to overvalue tools like frameworks and languages and undervalue your use of them. It reinforces a consumer notion of technology, whereby you passively play in conceptual sandboxes constructed by The Great Framework Authors.

"Just use Rails!" you hear, ignoring the small voice in your head wondering if all of the beauty of computation can really be foisted into ill-chosen paradigms. The cognitive killswitch that is mass acceptance and cultural success overrides that voice, though, so it's all good.

Then, when you inevitably get things into a mess, you consult the inevitable cottage industry of people who give you tricks to ward off the pain temporarily.

[stinos]

When I try to just "code" it ends up being poorly designed and written.

this. Not really important for small and/or personal projects, but for anything beyond that simply spitting out code ends up in a bad design violating SOLID and everything else out there, more often than not. After I figured that out, "code" now actually for me means something along the lines of "think about how components should cooperate with a minimum dependency, [enter rest of SOLID and everything else out there here], then start spitting out the tiniest functional pieces needed to implement it from the bottom up". Might not work for everyone, but it has done wonders for me. Especially the more my knowledge/experience about the first part grows (i.e. thinking about design upfront), the better the second part (i.e. spit out actual code gets), and the more proud I am of it. Heck, code from past two weeks is actaully a new personal record for me. So beautiful and well-cratfed :]. Then again, I thought the same thing about a piece I wrote 6 months ago. And the same goes for the way I use all other tools in the build process actually.