The Case for Slow Programming
ventrellathing.wordpress.com
The Case for Slow Programming
1–10 of 346 posts
Re: The Case for Slow Programming
#2The best solutions don't come from hacking, but by grasping the problem and it's full scope, the chance raises that you find a solution that can not only be used for the current problem, but also for similar other problems. A good programmer always tries to find similarities and to reuse old solutions in as many other areas as possible, but not more.
Such a behavior also boosts the maintainability of the solution. On the other hand, when it is ignored, a solution quickly can become unmaintainable and the solution that was implemented so "quickly" can become a black hole of man power.
I personally experienced more than one project, where the source code has become in very short time so complex and so bug ridden, that development times literally exploded.
Re: The Case for Slow Programming
#3[deleted]
Re: The Case for Slow Programming
#4Brings to mind Rich Hickey's support of so-called "Hammock Driven Development": https://www.youtube.com/watch?v=f84n5oFoZBc
Re: The Case for Slow Programming
#5How does typing speed affect the design of software?
Thinking about your design has not got a lot to do with the speed you type at.
Secondly as programmers we should be able to work on the same code base.
Re: The Case for Slow Programming
#6Very well put. I have a similar (slightly younger) age, and often pose myself the same set of questions on speed, tooling, typing. Needless to say, my answers are very similar to yours.
As for the Design Process, it works in the exact same way you describe in other fields like Architecture, which I studied and practiced ages ago at a more than decent level.
Money (VCs'), the myth of the young billionaire, and a few other things are probably what make developing different.
Re: The Case for Slow Programming
#7> The casualty of my being a slow programmer among fast programmers was a form of dysrhythmia – whereby my coding rhythm got aliased out of existence by the pummeling of other coders’ machine gun iterations. My programming style is defined by organic arcs of different sizes and timescales...
Boy oh boy. Look, I'm all for coding slow, taking time and understanding what you're doing. But there is something to be said for "playing well with others". We're all trying to make things, not be the backdrop for your exquisitely-crafted sense of craft.
To me that reads a lot like "I would have done something really good if I weren't surrounded by those philistines". Well, maybe so, but you are surrounded by them. So choosing a method of working that does not result in "dysrhythmia" or whatever strikes me as rather prudent.
Re: The Case for Slow Programming
#8And yet, most coding rounds in interviews are rigorously timed. Almost always, the importance is given to code completeness rather than code design/elegance. I'm sure a lot of talented engineers lose out here.
Re: The Case for Slow Programming
#9You have decades on me and I still wish to work your way. It maybe anecdotal, but the more timepressure a codebase has been under the less i've liked it, roughly speaking.
Re: The Case for Slow Programming
#10I recently disregarded the competence of a coworker (who is in a programmer position) because I took a class with them and saw that they could not type. They were hunting and pecking. (This guy is 50 years old so has had plenty of time to learn)
Is that wrong? Does being bad at typing force you to be more thoughtful and actually make you a better programmer? Or does it just mean it takes you longer?
My thinking is that you are not doing much thinking while you are actually typing, so not being able to type proficiently just means you're slower and that's it. So all else being equal, a programmer that can't type well is a red flag.