The value of slow coding
When I took my first programming class going after my Master’s Degree. My instructor then, John, told all of us that if we sat down to code and wrote 100 lines of quality code in an 8 hour day that we were really great programmers. At the time, I thought he was being somewhat facetious. I’ve worked on projects where I turned out several hundred lines of code in a day which was ultimately deployed and considered useful.
Then wisdom followed knowledge. I know how to code. I can figure out what I’m after, write it, and it will pass tests and it will work, but I also learned from John to re-visit my code and always try to make it better. Whether that’s more memory or processor efficient, or just generally create a better algorithm to do what I need to do; it didn’t matter, just to re-visit the code after I’ve left it alone for a while.
Now I’m working on a project and I realize that in the last two days, I’ve written maybe 200 lines of usable code, other than metadata code in wiring up a database to a web app which ensures better type safety, etc. That’s the stuff I write without thinking and while it’s necessary, it’s not the most stellar code.
This morning I found myself really proud of 4 lines of code. It took me some thinking and research to write 4 lines, but in the end, it was 4 good lines that did what I wanted and were well-crafted. So, now I’m realizing John was really right; slower coding produces better results.