Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Case for Slow Programming

ventrellathing.wordpress.com

Post reply on HN
Print view View original

31–40 of 346 posts

Re: The Case for Slow Programming

#31

Post by akbiggs »

tiglionabbit wrote: post #13
BhavdeepSethi wrote: post #8

And 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.

Most interviews I've done have expected me to write code on a whiteboard. This is pretty unnatural for me. I'm a very fast typist, so it's frustratingly slow to have to draw letters manually on the whiteboard.

At least in my experience, the main point of coding interviews has always been to expose and analyze the way that you approach and solve problems, not to see how fast you write code. It's usually better to take a step back and re-evaluate the design of your solution rather than dive into the first solution you create, since you'll usually find a better way to express the solution that is short enough to write down on the whiteboard without pressing against the time constraints.

It's also important to see how reliant people are on their tools.

Re: The Case for Slow Programming

#33

Post by m_mueller »

hasenj wrote: post #25
elwell wrote: post #11

> "I’m Glad I’m not a Touch-Typist." Yes, typing speed, when looked at in isolation, does not cause the production of high-quality code. But there is an argument to be made for reducing the friction between one's mind and the code on the screen. Insofar as we can ignore that transference of data from biology to technology, we can think more fully and clearly. So, emacs commands that are fully ingrained in one's subco…

I used to believe that. It's why I picked up coffee script. I thought, the less there is to type, the more you can focus on the problem rather than the code. I found out I was wrong. The redundancy actually helps. There's somehow a calming effect in it. I don't know how to put it into words. I found out that I never actually think while typing per se. I have to first jot down my thoughts on paper. Typing out the code…

It's not paradoxical at all. I think that the more syntax you have (thus shortening the code), the less you can reason about what you write while writing it, because the mental overhead of writing itself goes up. Compare stenography to latin in that regard - stenography is almost never used to write down ideas, only to transcribe.

Re: The Case for Slow Programming

#34

Post by pyre »

Swizec wrote: post #16
BhavdeepSethi wrote: post #8

And 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.

> most coding rounds in interviews are rigorously timed In the real world you will have to work against a deadline. As much as code gardening is fun and does produce better software, in the real world shipped software always wins over well designed software. Can you get it done, is a more important question to answer than can you make it beautiful.

While that may be true, timing your solution of an issue at a whiteboard isn't necessarily representative of your 'ability to ship on time.'

Re: The Case for Slow Programming

#35

Post by hasenj »

wellpast wrote: post #22

I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. Our goal is architectural soundness. I believe the biggest fallacy of our industry is we think the only way to get these is to go "slow". Not true. What we're really saying…

I think we can learn from some other (not-so-obviously-related) disciplines.

The game of go[0] has a ranking system where players progress from 30kyu (complete beginner) to 1kyu, then 1dan to 9dan (very strong).

[0]: http://en.wikipedia.org/wiki/Go_ranks_and_ratings

It's mostly statistical and based around comparing your skill level to other players. While a 7kyu level is not necessarily that well defined, and might differ between different ranking systems, there's still a meaning to the difference between the levels. When a 5kyu (stronger) is playing a 7kyu, the 7kyu player is given 2 stones in advance (handicap) to make the game even. The number of stones given as a handicap is determined by (or defines) the difference in levels.

It's not immediately obvious how such a system could be adapted for programming skills. But the idea of having levels, and having ways to measure one's level, is very interesting, and might be quite useful.

Japanese (and probably other languages) have standardized tests[1] to determine one's language abilities.

[1]: http://en.wikipedia.org/wiki/Japanese-Language_Proficiency_T...

You don't take a test to determine your level. Rather, you take a test designed for a particular level. You either pass or fail.

N5 is the lowest level (beginner) N1 is the strongest level (near-native or even better maybe)

When you feel you are at say, level N3, you take the N3 test, and if you pass, then you can say that you have passed the N3 test. If you fail, you just fail. It doesn't mean you are N4 or N5. (As far as I know - I might actually be wrong here).

I wonder if some standardized tests can be, in principle, constructed to measure programming abilities.

The tests must be crafted such that, even if all the questions are known to the public, then studying for the test is the same thing as studying to build up your skill level.

Re: The Case for Slow Programming

#37

Post by mVChr »

wellpast wrote: post #22

I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. Our goal is architectural soundness. I believe the biggest fallacy of our industry is we think the only way to get these is to go "slow". Not true. What we're really saying…

I think of it more like "deep" and "shallow".

Re: The Case for Slow Programming

#38

Post by kenrikm »

pzxc wrote: post #10

I 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 th…

I would say it's wrong, typing faster will not produce better software. Most of the time involved in writing software is not actually writing it. You may type 3x faster but if he is 5x faster at coming up with a quality solution then your gains will be lost.

Re: The Case for Slow Programming

#39

Post by mbillie1 »

serve_yay wrote: post #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 f…

> 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.

I had the same reaction here. Everybody wants good design. This article seems to walk the line between providing valuable insight and just complaining about how other people work.

Re: The Case for Slow Programming

#40

Post by georgemcbay »

pzxc wrote: post #10

I 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 th…

I type about 105 wpm using four fingers (my index fingers and my thumbs); I don't touch type at all but I also don't look at the keyboard, I just know where the keys are from muscle memory (when switching to a keyboard that is unfamiliar to me it takes me a minute or two to adjust if the keys are particularly different in shape/size from ones I usually use). I'm not sure what that says about me as a programmer.

In any case I don't think it makes sense to use typing speed as a measure of programming competence because typing speed is never the bottleneck in producing real, useful code.

Post reply on HN