here is one little pearl
The sooner you start to code, the longer the program will take. Roy Carlson Anon. University of Wisconsin
Taken from BUMPER-STICKER CS http://www.bowdoin.edu/~ltoma/teaching/cs340/spring05/course...
The Case for Slow Programming
211–220 of 346 posts
Re: The Case for Slow Programming
#212Earlier quoted context omitted.
Curious which languages you use that don't have this problem? Usually the point of package managers is to allow you to leverage the work of others, so you don't have continually reinvent the wheel. I've yet to run into a programming environment that did not have it's shares of headaches and nuances.
> Curious which languages you use that don't have this problem? None. It's why I'm burnt out and want to so something different. Not something different from my current job. Something different from developing software. I've lost count of how many times I've spent entire work days battling against the environment which is supposed to help me write the code I need to, to make a customer happy. Entire days of trying to…
> Windows so damn slow all of a sudden
VS is an awesome development environment, but I was having your problems with Windows and programs running under Windows for most of my adult life. I switched to Linux full-time at about 5-6 years ago, and I've been happy ever since. I can leave the OS running for weeks with no issues, and it would probably go for months but I'll turn the power off.
Oh, and with Linux, if you don't run a graphical desktop environment like Gnome or KDE (which most distros have the option of doing), then you boot into a REPL you can program the system in (Bash shell). Windows used to have the same with DOS, but no more...
Re: The Case for Slow Programming
#213Earlier quoted context omitted.
I'm not saying that it doesn't take time to build software and I'm not making a case for how to do management. In my decade of experience on different teams and products, the main impedance to productivity has by far been to do with bad code and architectural choices. The justification is always "speed" but my point is that is wrong. It's not speed that is at fault, it's that most software engineers don't know how to…
Describe good architectural choices?
There are some methodologies for this: http://en.wikipedia.org/wiki/Architecture_tradeoff_analysis_...
Re: The Case for Slow Programming
#214Earlier quoted context omitted.
That's actually the problem! Many current engineering disciples were before handled by craftsmen until scientific principles were applied to it, making it engineering. There have been very few scientific studies about the basics of building software, like how much unit tests really affects the bug density, and those few studies go often unnoticed when teaching future software engineers. It would require a major effor…
It's not just that not a lot of science is applied to the craft of programming. It is that many programmers are actively hostile to the concept. For example, the rules of programmers.se forbid asking for statistics. So if you want to know objective facts about the craft of programming, you're forbidden from asking for it on the most popular forum about that craft. When I asked why this rule was in place, it became ap…
You should ask: do I want it to be an art, or merely a discipline?
Re: The Case for Slow Programming
#215You get shitty fast programmers and shitty slow programmers.
You get good fast programmers and good slow programmers too.
'Fast' or 'slow' in isolation are not really a measure of anything valuable, except perhaps how an individual fits into the team culture.
The crucial thing to measure is how long it takes to get to good, robust software that does what it needs to do.
There are many strategies to achieve that (agile or big design up front or others) but software engineering as a medium is too immature to have found the one true way (maybe there will never be a one true way). Up front design and emergent design have both succeeded and failed on many occasions.
This post reads to me as someone who doesn't like working with younger teams as the work style often doesn't fit, and therefore concludes the team's working style is wrong, rather than he just subjectively doesn't like it.
Most of this thread sounds the same to me too.
Maybe the benefit of a fast programmer is it is quicker to find out if they are shitty?
I'm 42 and consider myself fast-ish FWIW.
Re: The Case for Slow Programming
#216Earlier 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…
"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".
I think zügig probably comes from the other, older meaning of Zug, "pull", "drag".
Re: The Case for Slow Programming
#217> 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 one.
I didn't know what a fast programmer was until I had to work with one. The king of copy and paste. All his neurons on his fingertips. He showed to me that thinking with their hands wasn't limited to manual workers. Luckily for me, his awesome speed allowed me to become his "boss" a couple of months after being hired. And I'm not being sarcastic here. The manager saw he was better left typing and me better left thinking.
Re: The Case for Slow Programming
#218'Slow programming' has too many syllables, and you end up having to say it fast. Let's call it slooowgramming.
Re: The Case for Slow Programming
#219The Author lost me at "I'm glad I'm not a touch typist". Coding isn't about typing at the same time when programming you should be writing code not thinking about where the semicolon is. I type and interact with my IDE incredibly rapidly. Generally my ability to type quickly is not the bottle neck. Sometimes it is. When it is I'm glad I can do it as rapidly as I can.
Meanwhile I agree with other comments that slow programming is the wrong word. You can rapidly write quite a bit of code with out needing to resort to hacking or avoiding best practices. It depends on your familiarity with the space and ability to properly construct the problem in terms of implementation quickly.
The point here is that you work at the appropriate pace and put some sense of craftsmanship into your work. I doubt that over the course of a sizeable project the approach of being diligent versus hasty is going to result in the diligent programmer tacking longer to get the same amount of work done.
Re: The Case for Slow Programming
#220Earlier quoted context omitted.
Try Go, seriously. There's just the one tool. No package manager, no dependencies... And the code it produces is the same. Just a binary. "Here, have this tool, just run it." It's small, simple, and the community actively searches out simple solutions.
I found go to be quite cumbersome in comparison to npm. Magic folders in the filesystem and such. With node you never have to do more than npm install and everything is ready.
In Go, the dependencies only matter during development not during deployment. Let the developer hash out what specific version of each library works, and then during deployment, it's all baked into a single statically linked executable.
That's the nice thing about using tools written in Go. There is no npm install. There's a file copy. Bam, done. You don't even need to know it was written in Go unless you're using the code for your own development.
The magic folders in the filesystem exist in every package manager, it's just more obvious in Go. So, for example, npm puts code it downloads into /usr/local/lib/node. I'm very far from a Node expert, but this doesn't sound terribly different from GOPATH.