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

21–30 of 346 posts

Re: The Case for Slow Programming

#21

Post by cesarbs »

> Fast programmers build hacky tools to get around the hacky tools that they built to get around the hacky tools that they built to help them code.

This resonates so much with me. Sometimes I worry that I'm falling behind on keeping up with technology, but whenever I try to learn something new it seems like I have to install a package manager, then another package manager inside the first one, then pull a million other tools and libraries and frameworks before I can even begin doing something with this stuff I'm trying to learn. No, thanks.

I love computers, I love computing, I love thinking about solving problems using computers, but I hate the direction things seem to be taking. I'm seriously considering a career change in the immediate future because all this crazy tooling truly burns me out.

Re: The Case for Slow Programming

#22

Post by wellpast »

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 is our industry is short on skill sets. With specific skill sets, you can build architecturally sound systems at no extra cost.

If I were to build a house today it would take me much longer than someone else because I don't have the necessary skills. I might hurry in which case the house would be shoddy. Is the shoddiness of the house necessarily because I hurried? No. It's because I didn't acquire the required skill sets first.

The software industry has no such (practical) concept of the skill sets required to build architecturally sound systems. We have a bunch of well-meaning hackers, and as a result shoddy systems that decay into technical liabilities.

Our industry needs to solve this skill set problem. The challenge is that academia has a hard time teaching these skill sets, because they are so removed from the practitioner. And businesses can't teach it b/c it takes years and special experience to actually teach it. So it's not advantageous to a business to teach those skill sets.

So how do we do it? And how do we organize an industry around professionals who know how to build architecturally sound systems and code? This is a very difficult problem for a world that has such high demand for code and such little understanding of what the professional skill set would afford them.

Re: The Case for Slow Programming

#23

Post by BhavdeepSethi »

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.

In the real world, you'll be spending more time on code design than typing it out. The race against a deadline mostly affects design choices. eg. Whether implementing a certain feature yourself with rigorous testing, or introducing a new technology which has been tested before. There are pros and cons of each. You go ahead based on the constraints involved (time, cost, expertise, etc.). I'm not talking about making the code beautiful. I'm talking about the /right/ way to do it.

Re: The Case for Slow Programming

#24

Post by elwell »

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…

But I think the main reason for choosing the word "slow" is to bring to mind its connection with the Slow Movement [0]; as the author mentioned.

[0] - https://en.wikipedia.org/wiki/Slow_Movement

Re: The Case for Slow Programming

#25

Post by hasenj »

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 becomes almost a mechanical process. I already know what I'm typing, I've figured it all out and put it in paper (or some plain text note in another text editor or note taking app).

There's stress in trying to hold it all in your head. That stress is released when you jot things down. Then you can just mechanically write out code with less levels of stress.

The explicit syntax means you have more to type but less to think about.

I know it sounds paradoxical. But that's been my personal experience.

Re: The Case for Slow Programming

#28

Post by kenrikm »

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 see it like a Craftsman woodworker vs a high school shop class. At the end of the day they can both build a birdhouse though the quality of final result will be very different.

Re: The Case for Slow Programming

#29

Post by andyl »

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 doesn't work that way for me - for some reason the syntax makes a huge difference in my productivity and level of energy.

Coffeescript works way better than JavaScript, Elixir better than Erlang, Slim better than ERB. It shouldn't make that much of a difference, but it does.

Re: The Case for Slow Programming

#30

Post by Adam89 »

swalsh wrote: post #12
Adam89 wrote: post #5

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

As women we should be able to birth the same babies? After the baby is born anyone can raise the child, some better than others, but its easy. We call that adoption. Until its born though, the baby, and it's mother are symbiotically connected to each other. I think this is similar to the process of programming. Break down an interface, and work on a team at that level. Behind the interface though, keep it small. one…

I really like that analogy but am not sure if that's what the author was alluding to.

Besides the one thing I strongly disagree with is how typing slow can help you produce better software.

Taking time and thinking about your design certainly does help but typing slowly and taking your time designing are not the same thing.

Post reply on HN