The Case for Slow Programming • Hacker News Board

Re: The Case for Slow Programming

#291

Post by err4nt » Tue, Dec 02, 2014, 4:27 PM UTC

pluma wrote: post #256

tempodox wrote: post #206

Earlier quoted context omitted.

Confirmed. I think, “steady” is a good rendering.

Not quite. "Steady" usually implies a certain slowness. "Zügig" generally implies the opposite. For example, if I asked you to leave a hotel in a "zügig" manner, I would be asking you to quickly pack up your things and then leave. In other words, it's about doing something "faster than normal", but not so fast you can't take proper care. If I told you to leave "zügig" and you'd first finish watching a TV show, I woul…

In every explanation of the word 'zügig' here on HN, the word that pops into my head is 'directly'. Not sure how to make that work beside the word 'programming' but it matches the same concept.

It implies that you are following that one named goal and considering nothing else.

Re: The Case for Slow Programming

#292

Post by e28eta » Tue, Dec 02, 2014, 4:27 PM UTC

Karawebnetwork wrote: post #251

donatj wrote: post #97

I was once a "fast" developer, like thousands of lines a day. I could knock things out at an amazing pace but they always had problems and were rarely testable. That actually worked out OK where I was where we basically built things and ideally never touched them again. Now, 8 years later I write maybe 50-100 lines a day. I can see all the vectors of things that would go wrong and take the time to mitigate them. I wo…

Hotshot here. Oh, how I wish I could slow down. But how could I? My task must be done in time for the sprint. Everything I do must be logged into the right ticket, I need to time everything I do. The enemy is time, and I must defeat it. I wish I could output better quality code. Right now, I'm working on a project that was finished at 90% and I need to finish it. The code is horrible, but I have no time to fix it. So…

It's your (shared) responsibility to determine what done is, and you should have a hand in estimating how long tasks will take. In my opinion, you as the engineer are ultimately the one who decides what quality you will accept. Instead of saying/thinking "it's done, but I'm not happy with the code quality yet", just say "it's not done yet".

I also firmly believe you should review all code before you commit it (would you skip proof-reading a paper before turning it in?), and that's an excellent time to spot easy improvements, places that need documentation, code that doesn't make sense, etc.

Re: The Case for Slow Programming

#293

Post by ploxiln » Tue, Dec 02, 2014, 4:30 PM UTC

notduncansmith wrote: post #272

NateDad wrote: post #222

Earlier quoted context omitted.

Go's model is pretty good. This is why there's just a single $GOPATH and every package has exactly one location on disk, so even if 100 dependencies use the same subdependency... you only have to update one spot if it needs a patch. And again, this only needs to be done at development time. It's baked in when you compile, and from there on, deployment is just a file copy of your binary. No dependencies during deploym…

Maybe I'm missing something, but this seems like a bad idea to me. What if projects are relying on differing versions of the same package? What if two developers collaborating on the same project have different versions of that dependency installed? Sure, it's space-efficient, but disk is cheap, and developer hours are expensive. I certainly wouldn't want two employees burning man-hours trying to figure out why some…

There's a philosophical disagreement here. It's true, developers are expensive. But I think it's a fallacy that what's less efficient for a computer is better for a developer. The npm-style dependency tree enables and encourages much more complexity, which developers then have to deal with when debugging or deploying. They need new tools to help them get a handle on the huge number of modules. That's more expensive than a system kept more "under control".

Re: The Case for Slow Programming

#294

Post by err4nt » Tue, Dec 02, 2014, 4:37 PM UTC

Spearchucker wrote: post #103

This guy speaks to my soul . A couple years ago I worked on a project that tried to put a 40+ page printed form online. The form is complex. The form has a lot of intricate guidance and notes, and sections that must or must not be completed based on previous sections or fields. I threw together a form builder by re-purposing old code from a side project that took me two years to polish. My proof of concept let an adm…

I come to coding from a Graphic Design background and I wish I had computer science under my belt as I test the waters of programming, but what I'm learning reading HN is that many programmers could benefit from the thinking they taught us in design school.

What's the difference between an 'artist' and a 'designer'? One is employed! When you are designing something (even with code) your measure of success is how well you deliver what needs to be built. With 'art' there is no such requirement—art can become whatever your whims desire.

One thing they warned us very strongly about in Design school was never to become 'married' to our designs. If a client pays you to make something and doesn't like it it's NOT good design because it didn't meet their needs. Don't be personally offended, it's not art, it's design. You can do art when you're paying yourself for your time.

I write code and add things like subtle text-shadows and gradients to enhance legibility (scientific reason) to make my designs more accessible, but if I look at the commit logs I often find that my supervisor goes back and removes all text-shadows, box-shadows, and gradients just because he believes gradients and drop shadows are a passé design trend from Web 2.0 that he probably read in an article. I could get offended that he's essentially neutering the accessibility of the designs I'm making and nobody will ever see the full design as I intended it - but I got paid for writing it just the same so what do I care?! He has the website he wants and I have employment. Bottom line is I'll keep delivering value whether he wants it or not and once that handoff is made it's his to do with as he pleases.

Re: The Case for Slow Programming

#295

Post by angersock » Tue, Dec 02, 2014, 5:06 PM UTC

fsloth wrote: post #229

angersock wrote: post #67

I'll disagree with a few points here. First, I think that the key is a mindset, not an age--I'm the youngest person at my company and yet I'm consistently the one pushing for smarter, smaller, better-designed solutions to our problems. It seems that a lot of people, especially those with an academic background, forget one of the three qualities of a good programmer: extreme laziness. Developers (often younger ones) t…

" if you have one person who "owns" a part of the code, you are inviting disaster and bad design. " I think we have different definitions of ownership. To me, ownership signifies that a certain person is aware of the history of a particular area of code, is responsible for keeping it in good shape and is usually the go-to person for all modification, or at least code reviews all work done to the code. This does not m…

I suspect our experience is indeed different. :)

I've had the good fortune of working with good programmers doing performance critical C and C++ for a hobby project--the time spent in design has paid off, and the codebase is a joy to work with. Sadly, the code has yet to see the light of day, because reasons. For the purpose of "get game project finished", more bad code faster probably would've been better, though we would've had to rewrite it anyways.

As for the rest, I've been in a few shops now where people who should've known better (or who didn't!) have written klocs and klocs of unmaintainable poorly-performing garbage and who subscribe to the "code owner" philosophy. The result is, of course, that you can't fix or even organize their messy fiefdoms, and so there is no peace-of-mind to be had that the code works. And yet, the businesses still trundle along to this day despite what is probably stage 4 cancer of the IP.

Maybe it's just Stockholm syndrome. I kind of feel like an abused puppy every time I have to look at that code and fight, for hours and weeks, to do something as basic as "Hey, maybe we should try both debug and release targets!"

Re: The Case for Slow Programming

#296

Post by jdmichal » Tue, Dec 02, 2014, 5:14 PM UTC

ep103 wrote: post #279

Argorak wrote: post #45

Earlier quoted context omitted.

> 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. German has a very nice word for that: "zügig". It means "speedy" as well, but goes a bit towards "stable", "steady" and "friction-free". It's the good kind of fast, which…

This is pronounced like zoo Gig?

The IPA would be /tsygɪç/. Pseudo-English would be more like "tsoo-gish", though obviously not completely accurate.

You can enter it in Bing Translate[0] to get a text-to-speech rendition. I can't figure out how to make a direct link with text already entered. (You can type "zuegig" if you don't have easy access to the ü key.) Interestingly enough, the translation there is "swift".

[0] http://www.bing.com/translator/

Re: The Case for Slow Programming

#297

Post by dceddia » Tue, Dec 02, 2014, 5:21 PM UTC

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…

How do developers currently learn to build scalable, maintainable, well-architected systems? Certainly there are some books on the subject, and that might be a good start, but I'd be willing to bet that these skills are largely learned "on the job" through a bunch of trial and error.

Are there any good ways to dive in and get experience with a lot of smaller examples, similar to the "code school" approach but for more advanced topics and systems?

Maybe we need something like that. Code School: Advanced. There's a lot of thought going into training the next generation of software engineers from the ground up, but there doesn't seem to be much work toward improving the skills of the ones who already have a bit of experience.

Re: The Case for Slow Programming

#298

Post by angersock » Tue, Dec 02, 2014, 5:24 PM UTC

EdSharkey wrote: post #113

angersock wrote: post #67

I'll disagree with a few points here. First, I think that the key is a mindset, not an age--I'm the youngest person at my company and yet I'm consistently the one pushing for smarter, smaller, better-designed solutions to our problems. It seems that a lot of people, especially those with an academic background, forget one of the three qualities of a good programmer: extreme laziness. Developers (often younger ones) t…

But NextSTEP didn't fail. It succeeded, in the biggest, most spectacular way I can imagine an operating system would. So, design does matter. Design seems to matter a great deal at Apple, so that backs up your other point that most other businesses could care less about their software's design and that NextSTEP at Apple is an exception.

BeOS !== NextSTEP

http://en.wikipedia.org/wiki/BeOS

Re: The Case for Slow Programming

#299

Post by HCIdivision17 » Tue, Dec 02, 2014, 5:25 PM UTC

jerf wrote: post #267

serve_yay wrote: post #41

Earlier quoted context omitted.

Don't do what everyone else does if you can do something better that leads to better results. The last part matters -- otherwise you're just crapping on everyone who can go faster than you and attributing the difference to "quality" (conveniently left nebulously defined). Put another way, how do you know what you're working with is steel, and others clay? What if your "steel" is really just clay that is slower to pro…

Thank you for repeating my own point back at me and making it sound like disagreement.

I find this sort of thing fascinating. I think it nicely showcases how perspective matters on this sort of thing. I almost feel like the whole fast/slow dichotomy is missing the point, since you can have two polar opposite views agree. What the point it... well, I guess that's why there's hundreds of replys in this thread.

Re: The Case for Slow Programming

#300

Post by a_e_k » Tue, Dec 02, 2014, 5:25 PM UTC

err4nt wrote: post #127

> My wife often comes out into the yard and asks me: “are you coding?” Often my answer is “yes”. I think I need this quote in my kitchen! My girlfriend often pounces be with the accusation "YOU'RE NOT WORKING" if she sees me out of my chair moving around, doing mindless house chores or half-vacantly tossing a cat toy around the house, or running errands, but the reality of _design_ is that it happens all day. And whe…

"Sunday: Lay on my back most of the day, reading, sleeping and day-dreaming. Very literary. Some women, however, resent it, so young writers should choose their wives with care. Many a promising career has been wrecked by marrying the wrong sort of woman. The right sort of woman can distinguish between Creative Lassitude and plain shiftlessness."

-- Robertson Davies "The Writers Week" (1959)