The Case for Slow Programming • Hacker News Board

Re: The Case for Slow Programming

#251

Post by Karawebnetwork » Tue, Dec 02, 2014, 1:38 PM UTC

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 I'm simply going to hack at it as fast as I can and make my agile manager happy.

Re: The Case for Slow Programming

#252

Post by einhverfr » Tue, Dec 02, 2014, 1:39 PM UTC

wellpast wrote: post #80

kenrikm wrote: post #28

Earlier quoted context omitted.

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.

Yep -- and I argue that the craftsman can finish at least as fast as the shop student. When someone says "I don't have time to make it sound", they're really saying "I don't have the skills." By the way, I think these skills can be acquired and even taught. They just aren't yet being taught afaik.

I would also bet that the craftsman will show less overt progress as he works. He will appear to be moving slower, but will in fact complete the three to requirements faster. And in the initial phase, in particular, the craftsman may take a lot more time. The speed will be shown not over the initial design, but over the whole production cycle.

Re: The Case for Slow Programming

#253

Post by GFK_of_xmaspast » Tue, Dec 02, 2014, 1:40 PM UTC

edpichler wrote: post #108

Really liked this part: " And the latest clever development tools, no matter how clever, cannot replace the best practices and real-life collaboration that built cathedrals, railroads, and feature-length films."

Historically, cathedrals might stand unfinished for decades at a time. Also the early days railroads were famous for brutally exploiting labor in order to get built as soon as possible. Haven't you heard of John Henry?

Re: The Case for Slow Programming

#254

Post by dschiptsov » Tue, Dec 02, 2014, 1:41 PM UTC

aercolino wrote: post #217

dschiptsov wrote: post #205

> You can’t wish away Design Process. Furious activity is no substitute for understanding. Before you start to writing the code, YOU HAVE SPEND A LOT OF TIME STUDYING YOUR PROBLEM. (Brian Harvey, CS61A) If you can’t write it down in English, you can’t code it. Programs must be written for people to read, and only incidentally for machines to execute. Immortal classic.) The sooner you start to code, the longer the pro…

Yes, someone in another thread is discussing about skill sets to be learned to engineer software, but I think academy already does a decent job. To engineer a good architecture you need time to thoroughly think and explore alternatives. Coupled with deep field knowledge and an even deeper know how, gained by means of experience. And to build the best is impossible by definition: you can only hope to build a better on…

That's why, perhaps, in pre-Java era, in good schools they taught "big ideas in CS" instead of Java syntax and how to OO everything.

Algorithms, Data Structures and reasoning behind them, Scheme courses of CS basics (based on SICP) and Operating Systems, so a student could understand the principles and design decisions.

Then such student could code in any language, because syntax and common idioms are much less important than appropriate data structures and processes. Then, perhaps, they will use a modern file-system as a database (like this very site back-end does) instead of bullshitting each other about what re-implementation of optimized in-kernel routines in Java is more popular, etc.

I know syntax of about dozen languages, but I am inferior programmer due to lack of appropriate theoretical background. I could spent days trying to figure out, should a request be a closure or an assoc or this fancy but costly "persistent-map", and these nuances like aliasing and locality in Clojure and CL.

Of course, one could always Ctrl-C/Ctrl-V from millions of online tutorials and "get shit done", but I cannot write anything without understanding why this instead of that, not because they say so in some narcissistic, over-confident blog-post. Thank god programming is my hobby, not my job.

So, it is not about syntax or how pointers were arranged (in structures and ADTs or in classes and objects) it is about whats and whys instead of hows. Coding is easy. Programming is difficult.

Re: The Case for Slow Programming

#255

Post by GFK_of_xmaspast » Tue, Dec 02, 2014, 1:41 PM UTC

I've worked with slow programmers, including someone a lot like the poster, and in my experience they never produce anything that was worth the wait.

Re: The Case for Slow Programming

#256

Post by pluma » Tue, Dec 02, 2014, 1:49 PM UTC

tempodox wrote: post #206

aragot wrote: post #204

Earlier quoted context omitted.

"Zug" means "train", "-ig" makes it an adverb like "train-ly". Can a German speaker confirm please? In English, I'd say a train has a fast & steady speed, therefore I propose the translation "steady".

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 would probably be slightly irritated.

In this case "zügig" is better translated as "in a timely manner" (rather than with haste, which would imply dropping what you are doing and running away).

Re: The Case for Slow Programming

#257

Post by Argorak » Tue, Dec 02, 2014, 1:49 PM UTC

moconnor wrote: post #243

jsilence wrote: post #180

Earlier quoted context omitted.

Please note that another german culture is to be overly pedantic in following rules, no matter if their initial intention applies or whether we just set them five minutes ago. Rules are followed because. This culture makes administrative processes bulky and tedious and tiring. It often fuels my Ungeduld, because I want to get s t done zügig.

This is true; it's also true that Things Work here. Processes, equipment, social organizations. To get your fishing permit you will need to provide all the right bits of paper and stamps, no exceptions. The flip side of this is that if you follow a set of precise, unambiguous instructions you will get your fishing permit . Source: moved from UK to Germany 8 years ago.

My favorite expat quote is: Germans have rules for everything, but with some though put into them, most of them are quite sane. ;)

Re: The Case for Slow Programming

#258

Post by aerojoe23 » Tue, Dec 02, 2014, 1:50 PM UTC

robert_tweed wrote: post #191

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…

I like this word, we should adopt it. It says a lot about the German mindset that they have a word for this. I don't think English has any equivalent (but it's a big language so I wouldn't be surprised to find out I'm wrong). We do have a very similar and pretty common idiom though: "slowly-but-surely", often used in the phrase "slowly but surely wins the race". This of course comes from The Hare and the Tortoise in…

expeditious

Best I could fined.

Re: The Case for Slow Programming

#259

Post by donatj » Tue, Dec 02, 2014, 1:52 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…

- Well it sounds silly but there will be fewer tickets when you slow down.

- If you work for a company where you're not free to question the legitimacy of tickets, get out now.

- Not all tickets should need to be done by the end of the sprint, but rather what can be done well or what legitimately NEEDs to be done for buisness reasons. I know your manager mught say everything needs to be done but that is a bold face lie.

- If you're throwing together garbage just to get the tickets done by the end of the sprint you are doing Agile wrong and just building technical debt rather than a product.

Re: The Case for Slow Programming

#260

Post by lmm » Tue, Dec 02, 2014, 1:54 PM UTC

Spearchucker wrote: post #245

lmm wrote: post #226

Earlier quoted context omitted.

> 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 admin change guidance on the fly, without touching HTML. Fields could be re-sequenced, data types changed. Business rules could be linked to fields dynamically, and applied to single fields or entire form sections. Data was saved to a SQL Server (already in wide use in the estate…

" Was your flexibility in the right direction? " Yes. " Why would your way have been different? " Because I had a form that created a form. You know, a lot of failed projects that I've worked on were my fault, because I was that guy. The guy who questioned the seasoned greybeard. The guy that knew JavaScript is the only answer. That agile is the only way to manage development. And if agile didn't work, it wasn't beca…

> Because I had a form that created a form.

I have a text editor that creates forms. I have a good abstraction for what a form is, meaning I can represent one with a simple class that expresses only the things that make that particular form unique. And I have a whole bunch of standard tooling around managing this representation of forms, like my VCS.

It sounds like you haven't really lost your certainty. "I just know. I know an idiot before he opens his mouth." - no, you don't, you can't. Being older doesn't prove anything - some of the worst decisions I've had to work with were made by the most senior people, and vice versa.