A flurry of hacks tends to beat the "correctly designed" way:
http://www.jwz.org/doc/worse-is-better.html
The Case for Slow Programming
61–70 of 346 posts
Re: The Case for Slow Programming
#62> 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.
That sounds awesome, I'll definitely give it a try.
Re: The Case for Slow Programming
#63I posted the same article 1 day ago... but used the https address... https://news.ycombinator.com/item?id=8678439
Re: The Case for Slow Programming
#64"There's never time to do it right, but there's always time to do it over".
This reminds me of something I've been saying for a while. I'm a practitioner of TDD - Test Driven Development, not Test Driven Design. I like test-first coding not because it's faster, as many proponents claim, but because it's more comfortable and thoughtful. It forces me to slow down and think about what I'm actually doing. I don't think I'm any faster when I'm coding to tests. I do, however, feel much safer. I hate that feeling of cranking out a bunch of code, then it breaks, and I don't know what broke or why.
But good design is absolutely not an emergent property of the process of coding! Thoughtless coding leads to poorly structured spaghetti. Well-tested spaghetti is still spaghetti! Good design is always a matter of compromises. You can either make those compromises in a conscious and thoughtful way, or you can close your eyes and hope for the best. Good luck with that.
Re: The Case for Slow Programming
#65I hesitate to recommend my process to other people, because I don't think I'm a very good programmer. But for the past year or so, I find that I program best by actually writing out my program in a notebook (in my case a quad-ruled lab notebook). I don't even start typing until I have it laid out pretty much in it's entirety on paper. This sounds ridiculous (and I can imagine it's not practical for all types of progr…
Paper is my favorite programming tool. The beauty of paper is that it's easy to find out when you're wrong, when you're pursuing the wrong path, without going deeply in and getting distracted by the small-scale details of the code.
This gets right back to the design thing.
Re: The Case for Slow Programming
#66Earlier quoted context omitted.
At least in my experience, the main point of coding interviews has always been to expose and analyze the way that you approach and solve problems, not to see how fast you write code. It's usually better to take a step back and re-evaluate the design of your solution rather than dive into the first solution you create, since you'll usually find a better way to express the solution that is short enough to write down on…
Why shouldn't a programmer be reliant on their tools? What a bizarre idea. I like to measure a carpenter's skill based on whether they can build a nice looking bookshelf with just a pocket knife said no one ever.
If you're asking them to design something rather than build something off a pre-existing design, you might like to know that they actually understand the principles of design, and aren't relying on a tool to pretend they do.
Re: The Case for Slow Programming
#67I'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) that manically hop from framework to framework and sprint to sprint because design work is "too slow" end up expending more energy than if they'd just been lazy and really thought about what they wanted to accomplish before they worked on it. This is especially true in business, where that mindset is invaluable for skipping work you'd otherwise do while finding fit.
Second, I disagree that on a good team engineers aren't fungible: the fact is that, if you have one person who "owns" a part of the code, you are inviting disaster and bad design. This, and not its converse, has been proven to me over and over the last decade. Sure, one person might have the domain expertise or familiarity with something to really nail it, but they should never be the only one on the team who can do so.
If they are, you slip them pizzas under the door, make them happy and productive, and then sack them as soon as you can extract their knowledge for they are a liability waiting to turn into a problem.
Third, and perhaps most controversially, the author supposes that good design is important. For almost any business, sadly, it isn't. Nobody gives a shit when you have deadlines to meet and bills to pay--and if you're lucky, you can push that burden up onto the next poor bastard to inherit the codebase after you've cashed out.
I really, really wanted to believe that good design mattered, that somehow it had intrinsic value. Sad thing is, it doesn't. BeOS failed. Plan9 failed. Inferno failed. Transmeta failed. Sun and SGI failed. Smalltalk failed. Lisp failed. Erlang failed (and cleverly stood back up, but not because the majority knew or cared about design).
Re: The Case for Slow Programming
#68> 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…
It is not the fault of these tools. You can think of code as data, and programmers producing this data, just like many other professions are producing data, too. Programmers often have a variety of far better tools to handle this data. I think the reason for this are of course the programmers dogfooding, but also the culture of life-long learning, which minimizes UI design to just API design. An intuitive GUI for a crowd less open to learning new things is so much harder to make.
I nevertheless see this as a gift. It is your attitude with these tools, that makes you unhappy. I I often have this strange feeling of missing out on an even better technology, the cool kids might be using. I think the key here is to be confident with your choices of tools, improve them, when their is pain and identify when something is good enough for some time (measured in years) before you should reconsider again. In the end it is also about handling the tools. This sounds very reasonable but in practice it is often hard to overcome the urge to use the new shiny tool, which seems to make you a better programmer, when you define yourself as one.
I don't think the extremist view of skipping them altogether and condemning the whole thing is the solution. I believe people, who feel they can't keep up in this imaginary race either search for ways to define themselves in another way e.g. in alternative careers (like you) or in their opposing way of programming (like the article author) throwing the others in a bottle of people, who do it wrong. There is a middle-ground between the Node developer and his weekly changing recursive package managers and the Coldfusion shop not doing scm.
Re: The Case for Slow Programming
#69> 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…
One treatment of this exact problem: Just let me code [1]
Re: The Case for Slow Programming
#70Earlier quoted context omitted.
At least in my experience, the main point of coding interviews has always been to expose and analyze the way that you approach and solve problems, not to see how fast you write code. It's usually better to take a step back and re-evaluate the design of your solution rather than dive into the first solution you create, since you'll usually find a better way to express the solution that is short enough to write down on…
Why shouldn't a programmer be reliant on their tools? What a bizarre idea. I like to measure a carpenter's skill based on whether they can build a nice looking bookshelf with just a pocket knife said no one ever.
I don't think the whiteboard interviews expect an executable at the end of the process. It's not a complete test, but a partial one: testing if you can come up with suitable algorithms within a reasonable time - and perhaps how you work/your process. None of which is dependent on any (software/IDE) tools