Earlier quoted context omitted.
This is why something like golang is appealing. Simple simple and more simple.
Simplicity for simplicity's sake isn't a virtue. I often feel that Go chooses that path ideologically, whereas real world use cases should have more innings (yes, it's the generics and shitty type system thing again, I'm not expecting us to agree, I'm just pointing it out). To that end, Go doesn't work for me. I use a fairly straightforward stack atop the JVM because I can hold the whole thing in my head (nothing in…
The Case for Slow Programming
261–270 of 346 posts
Re: The Case for Slow Programming
#262Earlier quoted context omitted.
This is why something like golang is appealing. Simple simple and more simple.
Simplicity for simplicity's sake isn't a virtue. I often feel that Go chooses that path ideologically, whereas real world use cases should have more innings (yes, it's the generics and shitty type system thing again, I'm not expecting us to agree, I'm just pointing it out). To that end, Go doesn't work for me. I use a fairly straightforward stack atop the JVM because I can hold the whole thing in my head (nothing in…
Re: The Case for Slow Programming
#263I 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…
"Measure twice, cut once"
I'd argue that a lot of projects these days suffer a death of a thousand cuts.
Re: The Case for Slow Programming
#264> 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 oth…
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.
Re: The Case for Slow Programming
#265Earlier 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…
I am clueless about this, How do you learn to make good architectural choices?
Re: The Case for Slow Programming
#266>He’d been surprised to find that in at least one way he fit in: more than half the programmers at Goldman were Russians. Russians had a reputation for being the best programmers on Wall Street, and Serge thought he knew why: they had been forced to learn programming without the luxury of endless computer time. “In Russia, time on the computer was measured in minutes,” he says. “When you write a program, you are given a tiny time slot to make it work. Consequently we learned to write the code in a way that minimized the amount of debugging. And so you had to think about it a lot before you committed it to paper. . . . The ready availability of computer time creates this mode of working where you just have an idea and type it and maybe erase it 10 times. Good Russian programmers, they tend to have had that one experience at some time in the past: the experience of limited access to computer time.”
Even while he was in prison he managed to code:
> A few months into Serge’s jail term Masha received a thick envelope from him. It contained roughly a hundred pages covered on both sides in Serge’s meticulous eight-point script. It was computer code—a solution to some high-frequency-trading problem. Serge was afraid if the guards found it they would deem it suspicious, and confiscate it.
That kind of discipline and meticulous thought is very hard to build in to someone who has never had these kinds of constraints but it is certainly an admirable goal.
[0] http://www.vanityfair.com/business/2013/09/michael-lewis-gol...
Re: The Case for Slow Programming
#267Earlier quoted context omitted.
"Everyone around you is building this bridge in clay.... what are you doing fooling around with this 'steel' crap for?" Of course you can spin it the other way too, which just goes to show this isn't a useful comment. Don't do what everybody else is doing just because they're doing it, do the right thing. If that does happen to be clay, great, but there's a great deal more people using inappropriately sloppy engineer…
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…
Re: The Case for Slow Programming
#268Earlier quoted context omitted.
Zügig is just so..Germanic! It's exactly how I imagine the stereotype of German efficiency. In the anglo-saxon world we pride ourselves on how many hours we work. In Germany they work fewer hours and produce more and of better quality. At least that's my impression.
Relevant: http://knote.com/2014/11/10/why-germans-work-fewer-hours-but...
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.
Re: The Case for Slow Programming
#269Earlier quoted context omitted.
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.
Things that are expedited are put on a 'fast track,' obstacles removed -- and, frequently, corners are cut.
Re: The Case for Slow Programming
#270Earlier quoted context omitted.
" 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…
Yes I do. And I can.
"Being older doesn't prove anything"
Indeed it doesn't. I know because I pay attention.
I'll put it another way - you can be young and not know. You can also be old and not know. However, you cannot be young and know. But you can be old and know. Old is usually, but not always, measured by time.