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 sometimes needs a step back and a look at things.

So, if I came to work "zügig", I didn't speed, but there was no traffic jam, I didn't stop for a coffee somewhere, etc.

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 Aesop's Fables.

Another analogy that works in programming terms is comparing the speed of a container ship to the speed of a Ferrari. One of them zips about a lot and goes round corners really fast. The other one takes a while to load up and takes an hour to turn, but it will shift a hell of a lot more cargo, a much greater distance, in the same time.

There's a place for both and the most important thing is knowing the difference; not sticking to one or the other dogmatically.

Best I could fined.

Things that are expedited are put on a 'fast track,' obstacles removed -- and, frequently, corners are cut.

As said below Latin has it in festina lente -- "Make haste slowly."

First of all, I find the claim about 35 hours being the average a bit dubious. It may have been the average some years ago, but today it's probably closer to 38-40 hours, with service jobs (from retail to agencies) often adding unpaid overtime to that. On the other hand our work laws are pretty employee-friendly (e.g. a mandatory uninterrupted resting period of 24 hours per week in case you have to work on sundays) and larger companies are more likely to follow the letter of the law.

The rules regarding Facebook and private e-mail have more to do with German privacy law: if the private use of work computers is explicitly forbidden, there are less legal landmines involved with intercepting or monitoring Internet use. In practice many places have an informal policy that allows these things, just not officially.

The bit about employees not hanging around after work is also inaccurate. For many people a lot of friendships (and relationships) involve co-workers. In fact, this is one of the reasons there was such an outrage when Walmart tried to implement its US work policies in Germany (which forbade romantic relationships between co-workers -- not that that rule would have held up in German courts to begin with).

There are indeed more days of paid vacation and families do receive preferential treatment when it comes to scheduling vacations during the major holidays or summer break.

The difference when it comes to "Handwerk" is also very striking. Mediocre pay (and rampant moonlighting) aside, craftsmen are generally held in high regard and like most professions take a lot of pride in correctness and precision. This probably again goes hand in hand with Germany having a lot of laws, rules and standards for various fields of work (e.g. you can't just set up a shop as a car varnisher, you need a formal qualification for that).

Also, bureaucracy. Although the sibling is right in that you do usually get the expected result if you follow all the rules, the paperwork can be daunting. Most people joke about the tax law in particular, but we have laws, rules and standards for everything. German law generally tends to define even edge cases clearly rather than leave them up to interpretation by the courts, consequently the legal system tends to be less shady than in the US, but trickier cases can still take years (but on the plus side, they are much cheaper than in the US).

Also, universal healthcare.

This culture makes administrative processes bulky and tedious and tiring.

It often fuels my Ungeduld, because I want to get st done zügig.

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.

And even if you succeed, in the end there'd be a rule that requires the Pdf to be printed, signed, copied, filed, scanned and filed again, digitally.

A lot of the studies on it I've seen come down to "work time is for work, free time is for not working" and respecting that.

In English, I'd say a train has a fast & steady speed, therefore I propose the translation "steady".

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

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

We have a term for that as well -- cruising speed.

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/

I once interviewed for a job at one of the most recognized and big Perl shops in the world and didn't get invited to face to face because I "took my time" with their puzzles. My response was that my first drafts were faulty, and that I preferred to program slowly because I could deliver more code, faster, and better by taking my time with it. In the end, their loss.

Deliberation is important. That often means slower apparent progress but faster progress overall.

In the reverse case, facebook's "move fast and break things" works because it suggests you move fast enough to dare breaking things to try an overcome the caution that holds people back from doing great things.

In this case the equivalent slogan might be "Do it right and ship it late" i.e. its so important to get it right its worth risking missing a shipping date. Practical principles, like the agile manifesto, describe a preferred trade-off rather than just naming a good attribute like swiftness, because who doesn't want the good attribute? It would be irrational.

I think this also highlights why moving faster is nearly always better even if uncomfortable for some: its a more effective way of handling uncertainty and learning faster that in most commercial environments is more important than quality. Quality in the wrong places is waste.

A better way of saying it might be "optimize your progress over the next 10 years, not over the next week."

I think there is a false choice usually presented between agile, move fast and break things, vs old waterfall approach. I don't think waterfall is the right alternative. The waterfall approach is really difficult to get right because to some extent it insulates design from coding. The integration of these two is something that agile gets right.

But what agile gets wrong is in de-emphasizing design too much. Design is important, and it is important regarding long-term progress. And if you don't design, you will pay for it a hundred times over. But the best design is where technology is designed bottom-up and UX is designed top-down. Done right, this integrates design into coding but it also emphasizes design and code contracts.

If it takes a longer time than management wanted for something to be built, that isn't necessarily because "skill sets" are lacking.

If the product is shoddy, that is probably not because the team lacked the magical ability to make sound products instantly, but because the team was rushed (on the theory that they are not professionals and have to be micromanaged)

The odds are that the feature spec was bloated and management was bad at estimation (perhaps because they demanded estimates out of programmers who are also not good at estimation, in a bid to squeeze as much output from them as possible).

Hackers aren't the problem. A pogrom on "hackers" is unlikely to solve anything. "Professional" in the sense of wearing this or that, or following whatever you personally consider to be best practices isn't going to fix scope creep, wrong estimation, fundamental facts about project coordination, or the laws of physics.

Building serious stuff takes time.

It's management's job to handle that without flipping its shit.

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 properly engineer software -- they haven't been taught nor had the time to learn it. It's absolutely an issue of skill sets.

Yes, management and project estimation are other issues to work out. I'd say we're actually much further along on these fronts than we are on the technical skill sets front. That is, the skill set of building architecturally sound systems.*

* Note: I do believe there is a time trade off between features and feature flexibility -- but there is no time trade off necessary for achieving architectural soundness, again so long as the right (presently rare) skill sets are present.

Not necessarily. Proper architecture takes time and planning and reasoning. If it didn't, we could make a program do it for us. There is absolutely a time tradeoff between coming up with the proper architecture for the application vs just using something that looked cool from a google project. The latter will always be faster at first, but not in the long term.

The first: The ones that can be made after the original, bad ones. The second draft, which is an improvement in the first draft, in every field.

The second: His (or her) own. We all know there are developers out there who think they're the greatest thing to ever write code, and that everyone else's decisions are bad.

The third: The ones that really should have been made, in place of the ones that really shouldn't have been made. As in, "You wrote your own SQL parser using hardcoded strings and no grammar parsers?"

(Shuffles away sheepishly)

I think in the end the best architecture is that which is thought through from a contract-oriented approach, rather than a buzzword checklist.

Linus said something along the lines of bad programmers worrying about the code, and good ones worrying about the data structures. I think there is truth in this, even though I develop Django database applications most of the time. If I find myself doing too much work at the application level, taking a step back I can usually see a better approach when I rearrange the database.

Agreed. The ideas in this article are sound, but I'm not sold on this "slow programming" term. It's more like "careful" programming, or how about "care-full" programming, in which you put your full amount of care into every character you write.

The reason we've been able to speed things up is because of these tools, like CI systems and test frameworks. Faster iteration means getting results back faster and that means you can spend more time thinking about the problem and less time implementing it. That is the major benefit of what the author calls "fast programming" and it's something he glossed over completely. Just because you move fast doesn't mean you can't be careful along the way. You just need tools that extend your own visibility in order to catch problems faster and more accurately solve them.

It's possible to change the entire world in half a page of code. That should be the goal...

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

> Wu wei is an important concept in Taoism that literally means non-action or non-doing ie. "effortless doing"

Set goal, think and explore a little, rest a lot and wait until you get clear picture. Then and only then start coding.

Pros: No burnouts, less stress, etc, and constantly moving forward (in contrast to 2 steps forward 1 step back cycle) what results in overall faster progress.

Cons: Personally it's sometimes pain in the ass to wait, but it's important to understand -> not to be obsessed with job. Get a hobby, do something else and let unconscious part of your brain deal with what needs to be done -> mind blowing discovery for me that actually works, but still have to get used to this concept :-)

You are right that most people that come out of university are woefully unprepared to design software systems. However, that doesn't change the fact that what ends up being the "best" design in the end is rarely apparent (or appropriate) in the initial planning stages of a software project. Requirements change, and the architecture needs to adapt with them. These architectural changes do have a very real cost. The tough sell is trying to show management that the alternative creates technical debt that will strangle the project if it isn't addressed, and that the longer the refactoring is deferred, the more expensive it will be.

Most likely, not a lot of things compare to building houses in all aspects.

The point is, if developers are having problems wrt. scaling, then we need to build tools that abstract away scale. Define a language that allows the runtime to auto-scale, depending on load. As far as I can see, it's "just" another engineering challenge, not essentially different from figuring out how to make a skyscraper withstand heavy winds.

If you're worried about that, then the problem is that you have someone managing a software project who doesn't know how to manage software projects. That's not a failure of the methodology; it's a failure organizational design.

The analogy with house building is flawed. Home construction generally follows a preplanned architecture, schedule, and process that has been refined and tested over a long time in an environment which doesn't change much over time. The process of building houses is well understood and if a delay occurs it can be attributed to a lack of skills as you say (or funding problems, etc).

Software has a different nature. If you have thoroughly solved a problem, the solution can often be automated. There is no button you can press to build the same house you built once before. It still takes time, money, and materials. With software, if you are not spending a large portion of your time working on a problem that has a novel component or two, you or someone else has probably failed to automate enough.

As a result, you never quite possess the necessary skill set to solve your current task. You are always pushing some boundary, even if small. Gross skill set mismatch is a separate problem, of course, but a transient skill mismatch is an inherent aspect of good software development and I don't think it's justified to place any blame on moderate and transient skill mismatches as a result.

Whenever you are dealing with something novel, you will need to go slower than usual. It's the same for new types of buildings that use newer construction tools or technology.

The fast food industry did not "win" the restaurant industry; it did succesfully quantify the (minimal) skillsets around manufacturing food.

By the way, I think these skills can be acquired and even taught. They just aren't yet being taught afaik.

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

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.

At the same time though, I think it supports my point that the training for these kinds of things should be faster than reading a big thick book followed by a bunch of trial and error.

"Measure twice, cut once"

I'd argue that a lot of projects these days suffer a death of a thousand cuts.

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 effort to first study the existing emergent software craftsmanship practices to find common patterns and to scientifically evaluate their effectiveness, and the results would have to be taught in the hypothetical future curriculum where future software engineers would be made. Then we might have software engineering instead of just software craftsmanship.

It's almost a bit amazing that software "engineers" who can be very obsessive about getting the data or A/B-testing will craft software based on methods they have no data about.

There hasn't been a lot of great quantitative scientific study on how to productively do science either. Academic science is a craft, and is more or less learned through apprenticeships.

I'm trained as a physicist, and I'm certainly a fan of quantitative scientific methods, but I think it's important to realize that there are some areas where quantitative science is effective and rewards the required work well, and other areas where it is largely an ineffective waste of time.

I suspect trying to quantitatively study things like "how much unit tests really affects the bug density" is one of these cases with a poor reward to effort ratio.

There's a danger in trying to apply quantitative science to complex phenomena, when many or most relevant factors are actually uncontrolled and unmeasured. Once you have a number--any number--the tendency is to fetishize it at the expense of broader thinking. Make no mistake: quantitative measurements of the behavior of people performing complicated tasks do not carry the same epistemological force as quantitative measurements of the magnetic dipole moment of the electron.

Scientists themselves more typically try to understand their own craft through case studies and "professional wisdom" passed down from practicing experts to apprentices. Software developers would probably do well to (continue to) do the same.

Can you reference those claims? If I ever repeat this claim, I would prefer to be able to link to the administrators' statements directly.

I like to use the word "deliberate" when I mean "slow", but think that "slow" will be misinterpreted.

We aim to focus on systems, because it is the most efficient way to work. By using good methods, designing complex systems well, and spending adequate time designing, we achieve a net speed increase, productivity increase, cost decrease, and additional positive benefits such as programmer morale and overall quality.

In my mind, quality is the genesis of everything, but you do have to word that really well so that the overlords comprehend the consequences correctly.

There are two systems in the brain at play. "Fast thinking" involves gut reactions & intuition. "Slow thinking" involves logical analysis & formations of models. Both contribute to effective solutions.

Recognizing iteration as the cycle of evolution & growth creates working systems in congruence with natural law.

It's pointed, poignant and accurate as well as precise; self-defeating it is not.

Except the extra labor costs of someone with that skillset.

Maybe slow programming means finding important things to work on.

Your system may be well-considered but if it's not architecturally sound it's going to increasingly tumble over time.

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.

This absolutely misses the point of the article. It is definitively not about programming abilities, or speed of these abilities.

Many authors have hit TFA's points from different angles. For example, Tom Demarco's excellent Slack[1] introduces uses of "efficiency" (what speed is the organization moving at?) versus "effectiveness" (is the organization moving in the right direction?). DeMarco uses these to illustrate that many organizations optimize for the wrong parameters: they want to move at breakneck speed ("efficiency", "butts in seats", etc.), but in doing so trade off their vital strategic ability to think, design, to steer the ship!

In an organization without slack (briefly, the ability of knowledge workers in an organization to engage in vital reflective tasks, a key part of TFA's design process), everyone's so focused on Getting There that no one remains to decide if There is the right place to be going. This can and does result in everything from classic technical debt to strategic business failure. DeMarco describes a pile of organizational anti-patterns that stem from this philosophical damage.

I like that TFA's author connects these concepts explicitly to more recent thinking on the importance of design process.

[1] http://www.amazon.com/Slack-Getting-Burnout-Busywork-Efficie...

It is the LEAST trivial thing to measure the "code quality"/"unit of time" metric in a programmer. For example, you might bang out an implementation that looks fine, but 1 guy will say "that will become unmaintainable in 1 year" or "that will be a problem if we ever switch databases" or whatever and sure enough, a year later, the team has to do that... and that 1 guy was fucking RIGHT.

Who's to say how you measure such a thing?

The longer you spend in a career that has ANY creative component, the more you will come to loathe the importance placed on "performance evaluations." In fact, I'd argue that the more advanced you are in those creative jobs, the SLOWER and BETTER you work... the problem is that the newbies won't be able to recognize the "better" portion.

And sometimes YAGNI, we'll cross that bridge when we come to it, nice problem to have, good enough is good enough, do the simplest thing that could possibly work, premature optimization, perfect is the enemy of good, grass is always greener somewhere else, better a bird in the hand than two in the bush, he's right but it's still not worth the cost right now, etc.

They key point however is, that one guys insight shouldn't be ignored. You can take the words of wisdom and proceed to not do anything about it, but at least you know the cost down the road. All experienced managers I know personally, know the cost of umaintainable software and are more than willing to do something about it if ressources allow it. They need to, otherwise it's their ass that is in the line of fire when it cost a factor 10 to implement a new feature and bugs creep up at the customer time after time, even though they spend a factor 10 more on QA.

Actually in terms of very old games Go is one of the harder ones to measure performance of during the game. In terms of measuring performance in any 1v1 game however it is easy.

Small difference.

Anyone who can build reliable systems using unreliable parts (like humans) will have an edge.

EDIT: If you're going to measure the worker's programming concept knowledge, Alison Tew's work seems to be at the leading edge.

[1] 'Developing a Validated Assessment of Fundamental CS1 Concepts', Tew, Guzdial, http://dl.acm.org/citation.cfm?id=1734297

We can teach people how to do math correctly. That doesn't guarantee that they will be able to solve arbitrarily complex problems. But to solve math problems, you MUST at least have the skill sets.

So there is a test to measure do you have the skill sets. How much one is willing and/or able to handle complexity is a separate thing to consider.

I think a better adjective would be robust. But I'd hate "Robust Programming" become as much of an abortion as "Agile", now an excuse for micromanagement and business-side mediocrity, has proved itself to be.

If we want to create more tolerance for good engineering practice, we can't act like primadonna artists obsessed with building our perfect masterpieces on someone else's dime. We're hired by businesses, so our arguments need to be grounded in business value.

"It's a shitty architecture" isn't going to get you anywhere.

"It's going to fall apart and cost you millions if you do it that way, but if you take out these less important features and spent more time on what matters, we can do it right for the same cost..." People might just listen to that one.