David Heinemeier Hansson Explains What It Takes to Write Great Code (evrone.com) 66
The "bespoke development" site Evrone.com (an IT outsourcing company) interviewed Ruby on Rails creator David Heinemeier Hansson (who is also co-founder and CTO of Basecamp -- and a racecar driver) shortly before he spoke at RubyRussia, Evrone's annual Moscow programming conference.
And they asked him an interesting question. As a man who's seen lots of Ruby code, "what makes code good or shitty? Anything that is obvious for you at first glance?" David Heinemeier Hansson: If the code is poorly written, usually it smells before you even examine the logic. Indentation is off, styles are mixed, care is simply not shown. Beyond that, learning how to write great code, is a life long pursuit. As I said in my RailsConf 2014 keynote, we're not software engineers, we're software writers. "Writing" is a much more suitable metaphor for what we do most of the time than "engineering" is. Writing is about clarity and presenting information in a clear-to-follow manner so that anybody can understand it.
There's no list of principles and practices that somebody can be taught and then they will automatically produce clear writing every time. If you want to be a good writer, it's not enough just to memorize the dictionary. Just knowing the words available to you, knowing the patterns of development is not going to make you a good developer. You have to develop an eye. You have to decide that the most important thing for your system is clarity. When you do decide that, you can start developing an eye.
The only way to become a good programmer, where, by definition, I define good programmers as somebody who writes software with clarity, is to read a lot of software and write a lot of software.
In 2016, David Heinemeier Hansson answered questions from Slashdot readers.
And they asked him an interesting question. As a man who's seen lots of Ruby code, "what makes code good or shitty? Anything that is obvious for you at first glance?" David Heinemeier Hansson: If the code is poorly written, usually it smells before you even examine the logic. Indentation is off, styles are mixed, care is simply not shown. Beyond that, learning how to write great code, is a life long pursuit. As I said in my RailsConf 2014 keynote, we're not software engineers, we're software writers. "Writing" is a much more suitable metaphor for what we do most of the time than "engineering" is. Writing is about clarity and presenting information in a clear-to-follow manner so that anybody can understand it.
There's no list of principles and practices that somebody can be taught and then they will automatically produce clear writing every time. If you want to be a good writer, it's not enough just to memorize the dictionary. Just knowing the words available to you, knowing the patterns of development is not going to make you a good developer. You have to develop an eye. You have to decide that the most important thing for your system is clarity. When you do decide that, you can start developing an eye.
The only way to become a good programmer, where, by definition, I define good programmers as somebody who writes software with clarity, is to read a lot of software and write a lot of software.
In 2016, David Heinemeier Hansson answered questions from Slashdot readers.
This is why enforced code standards are bad (Score:2, Interesting)
If the code is poorly written, usually it smells before you even examine the logic. Indentation is off, styles are mixed, care is simply not shown
This is exactly right, and why I am against coding standards for teams.
Coding standards are like taking something that smells terrible, and just spraying a lot of perfume over it. Or maybe a car that looks smooth but the bodywork is mostly Bondo....
The point is that it temporarily hides the horribleness beneath, and lead to other developers ignoring an area of co
Re:This is why enforced code standards are bad (Score:5, Insightful)
Standards for indenting, variable names, where documentation goes etc don't affect if code is good or bad, just if other people can quickly understand what's going on based on experience with other parts of the same code base. Coding standards are crucial for any work that is produced by a large team or will be maintained by another organization.
The first step of writing good code is to get your ego out of the way. Once you realize that you suck, your ideas suck, the implementation isn't very good, and the documentation needs improvement, you're on the right path. Maintaining that attitude is the hard part.
Re: This is why enforced code standards are bad (Score:2)
I mostly agree, but especially about the ego. I've long felt one of the biggest distinguishing factors between a jr and a sr developer, is the sr has learned they can learn somethimg new from the jr.
About the issue of indentation and formatting however, these days I feel its mostly an issue of tools. Where i work some have tabs set to 3 spaces and some 4, the biggest problems especially with reviewing change sets happen when somebody auto formats a file. Super annoying.
Re: This is why enforced code standards are bad (Score:5, Insightful)
I've generally tried to eliminate the phrases "it's impossible", "it's guaranteed that...", "100% certain", and such from my vocabulary, unless there's an overwhelming amount of evidence to support such a position. I've learned that no matter how certain I am of something, there's quite often a chance I'm wrong, or just didn't think of some remote possibility.
A lot of young programmers tend to get a bit cocksure once they get a few years of experience under their belts. Another decade of experience will hopefully pound a bit of humility back into them.
Re: (Score:2)
It may be true that "coding standards are crucial for any work that is produced by a large team or will be maintained by another organization." That makes some sense to me.
But I don't for a second equate that with "quality code."
You can have mountains of uniform code, and -- it's all just bullshit nonsense.
Very cleanly formatted bullshit nonsense, though!
Re: (Score:2)
And that's wrong. the coding standard should say 2 things:
1. keep your new code the same style as the old code. If you inherit code that uses tabs, use tabs, if it uses ansi-style brackets, use the same, if it uses snake-case, use snake-case.
2. Organise your code files in the proscribed manner so everyone who picks it up knows the binaries end up in /bin (or whereever) and not tucked away in some obscure directory you felt like using that day.
Setting a global coding standard doesn;t often work, you have to
Re: (Score:2)
Organise your code files in the proscribed manner
That sounds fun. Break all the rules. (Or perhaps you mean prescribed).
Re: (Score:2)
I find the people who are the biggest proponents of these things are the ones who break them all the time.
Very true and also the ones that flip out the most when anyone breaks any of these rules even if there's a legitimate reason. Then of course later on complain that too many people blindly follow the rules when they shouldn't have. (If any here has never run into one of these people you are so lucky.)
Re: (Score:2)
> don't affect if code is good or bad, just if other people can quickly understand what's going on based on experience with other parts of the same code base
counter point:
Any code that can not be quickly understood (by a competent co-worker) is bad code.
Re: (Score:2)
Re:This is why enforced code standards are bad (Score:5, Insightful)
Have you ever actually worked in a team?
Unless the team has been working together and well long enough to have a shared coding style (at least for their team efforts), having a documented and checked coding style is necessary to keep most software developers on the same page. Otherwise there are too many factors that differ between developers. These vary from important factors like entity (variable, function, class, etc.) naming and standards on input vs output parameters, to merely distracting factors like whitespace and bracket placement.
If everybody gets to do their own thing, the shared code base will immediately trigger those bad code smells. Even with a coding standard, the poor and mediocre programmers will be inconsistent about it, which is a good indication of which code needs to be examined more closely.
Could hardly disagree more (Score:3)
He points out that inconsistent style is a hint that bad code lay ahead *because the programmer didn't even care enough to keep the style consistent*.
Saying that you shouldn't bother to care even that much isn't going to result in better quality work.
It's like when you get a package from China after you order a cheap DVR and the label says it's Degitol Video Recoderer, compating with alls of televisions sets. You know there is probably a pretty crappy product inside because the manufacturer clearly doesn't
"Polynesian" restaurant, dude, Polynesian (Score:2)
https://en.wikipedia.org/wiki/... [wikipedia.org]
The "pu pu" platter is an American/Hawaiian development, and in Hawaii, caterers and others develop a reputation for great pu pu.
This is a culture, by the way, where fried Spam on a mountain of rice https://www.onlyinyourstate.co... [onlyinyourstate.com] is considered comfort food and obesity, who you staring at, brah?
I guess a pu pu platter is a combination of different dishes having their origin in Americanized Chinese food of the don't-knock-it-if-you-haven't-tried-it category. There m
Re: (Score:2)
It's like when you get a package from China after you order a cheap DVR and the label says it's Degitol Video Recoderer, compating with alls of televisions sets. You know there is probably a pretty crappy product inside because the manufacturer clearly doesn't care about getting things right.
On the plus side you know they most likely didn't bother to license the rights to a DRM system, so it will just work.
Re:This is why enforced code standards are bad (Score:5, Insightful)
Following a style standard isn't bad, but it isn't enough. One must write in a way that reaches out to the reader and explains what is going on, so the other developers who come along years later to maintain the code don't have to spend hours trying to make heads or tails of it.
And this is something I really, really hate about Angular (along with the conventions that surround it). Part of the stylistic motivation is to eliminate "boilerplate" code (which is a set of commonly-repeated and formulaic code like variable initializers in object constructors, and similar). This is true of typescript as well. They want their code to be informationally dense.
But the result is code that is so compact, and so dense, that it looks like utter gibberish! I have seen examples in online documentation that include multiple layers of "observables" (where the function name is short but utterly non-descriptive so you have to "just know" what they do and what each parameter means), wrapped up with anonymous functions (where there is no function name to describe what it is doing and a clumsy syntax for you to mentally parse), nested within each other and involving a few very shortly-named variables, packaged in a method of an Angular "service," which itself is a teeny tiny little meatball in a bucket of spaghetti. There isn't an ounce of boilerplate, but unless you already know everything about the code upstream and downstream of this (and have the library of observables memorized), it WILL take hours to reverse-engineer what this code is doing, and you will still probably screw it up.
I think that people who love Angular really just love showing off how capable they are of producing and mentally traversing code that looks like it has already been run through a Javascript minifier AND obfuscator. High-level languages are supposed to be easier to read than assembly! That's why they exist for crying out loud!
A little boilerplate may be redundant, but if it helps someone skim the code and quickly get a handle on what the code is doing (or even if its presence simply serves to not inhibit such rapid comprehension), then it is totally worth it.
Re: (Score:2)
If great code is applying a filter that says fix your garbage then I'm confused.
Stylistic choices can easily be enforced and tend to be done so on any serious level.
That isn't great code...
There are clearer and better standards for writing readable code and formatting isn't the biggest hiccup. Someone needed to write an article somewhere and rehashed the same old concepts that are about 20 years old at this point.
Re: (Score:3)
> why I am against coding standards for teams.
**facepalm**
Because let's waste EVEN MORE time when everyone has their own bloody naming conventions, indentation, and library preferences!
i.e.
Some people signal member variables start with "m_", others "use just "m", while others use just a single underscore "_".
Oh noes, the horror of having a CONSISTENT naming convention! /s
Having a standard makes it easier to READ by having a CON
Re: (Score:1)
Do you even work in a team???
Moot point, I mean even if you're a solo dev, reading your own code from years ago which might have a different style than your current one is still a p.i.t.a
The best way to ensure a uniform bracketing/indentation style is to have no brackets, but instead use indentation at compiler level to identify code blocks. You can instantly see nesting level without scrolling or counting. You avoid those one bracket lines which improves code density on screen.
Even if you're stuck with bracketing, here's another idea:
Spoken for truth. (Score:5, Interesting)
"If the code is poorly written, usually it smells before you even examine the logic. Indentation is off, styles are mixed, care is simply not shown. Beyond that, learning how to write great code, is a life long pursuit"
The struggle is always management that couldn't care less about quality... all too often just immediate results and stupid metrics like lines of code per day.
Back in the 90s, I was working on a project as IVV (Independent Verify and Validation) for a large project. Complaining to management about quality or style compliance or complexity was meet with deaf ears. I even found 30 large sections of code that were nearly identical. They rated programmers on LOC produced which resulted in people taking several pages of code and doing a search and replace on a variable and creating multiple functions that should have been a single function with a parameter. The contractor (GE) even had a huge banner over the door bragging about the fastest ADA Code Development Facility in the world.
After multiple delays and poor performance, the entire code base was replaced by a collection of scripts (Matlab and Perl) and embedded code rewritten code by a couple of competent programmers.
Re: (Score:2)
Coders who spend hours "tidying" code (because a previous coder had a slightly different style of naming or breaking long lines of array entries or something) and minutes thinking about the algorithm - or just start typing into their auto-formatting editor - are the bane of my life as a manager.
It's true that code can be badly formatted. It's not true that it can be perfectly formatted nor that chasing such an ideal is worthwhile. On top of that, of course, some style standards are just plain bad. And that'
Re: (Score:2)
I wouldn't waste time reformatting code because it didn't fit my personal formatting tastes.
I would reformat code that was inconsistently formatted, because that makes it unclear.
Re: (Score:2)
"We all know when code is clear and when it's not."
I had a manager like this just recently. What a horrible attitude. Especially if someone is asking you to clarify something.
If we all knew, there wouldn't be endless conversations on the subject.
Re: (Score:2)
Sorry... (Score:3)
Re:Sorry... (Score:5, Insightful)
Good code is code that satisfies its requirements, including requirements for maintainability and extensibility.
Good requirements are much more difficult than good code. No amount of good code can substitute for the engineering practices necessary to generate good requirements.
The vast majority of the "critical software errors" that we see in software are not an errors in the coding - they are errors with the software development process. Lack of requirements, lack of testing, lack of critical design review, thinking that it's possible to "test in" quality without having a quality design, etc. Even with those things, it is still possible to have an erroneous system (e.g., MCAS) because of poor requirements - including poor business requirements.
Re:Sorry... (Score:4, Interesting)
Not all code has the same requirements, including maintainability and extensibility. Also, good code is code that satisfies it's requirements WELL.
The quality of code is determined by how well it is solves the problem. Sometimes that problem includes support by a large team and sometimes it doesn't. Sometimes performance is the only important criterion and your ability to understand it is beside the point. It depends, and the clear fact that no one gets that here shows that there simply aren't good programmers in the discussion.
The most important aspect is good design, I fundamentally disagree with the notion that programmers are "writers" not "engineers". It's like saying architects are "drawers", frankly its a moronic observation and reflects poorly on the intellect of the person who made it. Glad I haven't invested in Ruby, I suspect I'd be disappointed.
Your ability to understand code is not a measure of the code's "goodness" or "clarity" as it assumes your ability to understand and your familiarity with the problem. If you don't understand the problem, which will often be the case, it's not the code's fault that you don't get it.
My last programming job involved essentially a lot of bootstrapping code and virtually no "runtime", that is to say the entire job completed in under a second. This was an embedded project and I was consistently criticized for not using open source loaders and runtimes for the hardware platform used (in favor of rolling my own). The assertion was that OS code was more "maintainable", "better documented" and "easier to understand" than my proprietary solution, but it also took more than a second to bootstrap and would ensure that I would always fail to meet standards. That's what you get when people insist that "maintainabllity and extensibility", defined by someone else's standards, defines "good code". I prefer meeting objectives over failing.
Re: Sorry... (Score:2)
The original author of that code, and the ones praising it, may have bought into the "Clean Code" philosophy (there are PDFs of this book online). When my boss at a new workplace recommended the book, I soon realized it contained some good guidelines, mixed with some horrible advice (like having small methods, resultin
wHat? (Score:2)
what Does he meAn, by thaT? Any_idiotCan-write good_Code.
And next week we get the boss of Lada... (Score:5, Insightful)
... to explain what it takes to build great cars.
Re: (Score:2)
OK, what did he write that's great?
Well, he wrote one of the most successful back-end web frameworks, which has been a key tool for numerous successful businesses.
And then there was the time he co-founded a successful software business and helped to keep it successful over a period measured in decades.
I'm sure everyone taking pot shots at him has similar demonstrable success stories to their name, right?
Re: (Score:2)
A great programmer will beat a mediocre programmer in all the three metrics, code development speed, code run time performance, code quality/defects/bugs. This is one place where you dont say, A: Time, B: cost, C: Quality : pick any two. You get the trifecta with a great programmer.
What makes a great programmer? She/he would
Ladas are pretty good. (Score:2)
Seriously. They basically built the first thing that you today would call an SUV, like 30 years or so back. And if you look at the bad roads they had you know why.
Robust, repairable with a pocket knife, quite timeless design - because functional.
I'd take a Lada over an american streetcar any day.
Re: (Score:1)
Seriously. They basically built the first thing that you today would call an SUV, like 30 years or so back.
Source?
Because I can think of over a half dozen SUVs that were in production before 1990.
Re: (Score:2)
He is the Greatest (Score:1)
How he explains great programming with profound explanations of the life-long pursuit of smells, requiring an eye or two and it being simply unteachable apart from doing it a lot, it's just dazzling. Never has anyone explained great programming as great as he does.
Re: (Score:3)
The mods are not your friend, it seems, but I enjoyed your subtle sarcasm ;-)
Re: (Score:2)
Thank you. And don't worry about the mods. Some times do they give, sometimes do they take.
Quick metric (Score:2)
Re: (Score:2)
You've already excluded a large portion of the programming world with your assumption that a "bug tracker" is part of the process. If I were interviewing and a candidate said this to me I would not be impressed.
Now, if a candidate asked how my company's software was tested then I'd say he may have experience that I'm interested in, but you aren't concerned with that, you're only concerned with statistics generated by a tool. Thanks for coming in, we'll let you know.
Re: (Score:2)
You've already excluded a large portion of the programming world with your assumption that a "bug tracker" is part of the process.
ok, so how do you keep track of bugs? What do you do when a customer finds one?
Re: (Score:2)
If the code is filled with bugs, it is inevitably hard to read and difficult to work with.
I think it's the other way around. If the code is hard to read and difficult to work with, there is a high probability that is full of bugs. But not always. I've seen shit spaghetti code that ran beautifully. We just couldn't revise it to add features because nobody (including the original author) dared inserting a line which might cause it to blow up. On the other hand, easy to read code could still be full of bugs. But they are relatively easy to find and fix.
Re: (Score:2)
More value, less ego (Score:3)
What if we could be more productive instead?
It's like here's the 90-step process I use to make my own shoes. Each pair takes a week. See how awesome they are?. Versus the factory where 500 people make 50000 pairs of athletic shoes in a week.
Software development should be striving to be more like the factory and less like the artisan. More value, less ego.
Re: (Score:3)
Factory would be the "solved problem" case with mature libraries; not everything in the world is like that though. Some people love developing those libraries the rest of us use. too, they're the toolmakers.
Re: (Score:2)
Factory would be the "solved problem" case with mature libraries; not everything in the world is like that though. Some people love developing those libraries the rest of us use. too, they're the toolmakers.
But the summary isn't even talking about libraries, it's talking about even lower-level stuff like formatting.
If libraries were the answer to software development productivity, then software development productivity would be solved. We have libraries. They only partly solve some things.
Re: (Score:3)
You have completely misunderstood software. Writing software is more like designing the production process. The data processing the software does is the production. 500 people did not crank out the production process for those sneakers in an hour.
Taylorism only works when you want low-skilled people to produce a great many exact copies of the same thing. It will only ever work for software is we want to only write one application over and over.
Re: (Score:2)
Everyone who has a different opinion or thought process has "completely misunderstood". New ways of thinking about things are unwelcome.
Re: (Score:2)
Some things are just wrong. Taylorism has been tried for software production ad-nauseum. It has never succeeded. There is nothing new there.
Yes, we should be software engineers (Score:2)
It is easier for a good software engineer to be a good writer, actually, a good editor, than a software writer can be a good software engineer.
It is all about plans and planning, and knowing why they are required.
Too many teams trust upon having knowledge in the minds only, instead of writing correct requirements, and configuration management plans, so that there is a plan to track things that need to be implemented, tested, recorded to have been implemented, and deployed.
That is where the editor skills
step 1 (Score:2)
"Indentation is off, styles are mixed"
Step 1: Select "styles" in settings, select K&R, hit "format source". (eclipse for example). Yeah, if you fail to do step 1 periodically in your code, you already miss his 1st notion.
Writing may initially feel like a great analogy for s/w development, but writing also includes a heavy emphasis on "creativity" and style, which breaks the analogy. Just saying. From my experience, having done a few interviews recently from these furloughs is: use it or lose it... (havi
Good code survives (Score:3)
This guys not talking JavaScript, right? (Score:1)
I get this a lot (Score:2)
Re: (Score:2)
We're READERS (in addition to Writers) (Score:3)
I've found over the course of my career that I spend over 80% - 95% of our time reading code whilst only 5% - 10% of my time actually writing code.
It is therefore imperative we learn to write great code so that OTHERS (including ourselves 6 months down the road) can read it with the least amount of jarring notation.
We write code for other people -- NOT the compiler / interpretor.
Coding standard do NOT "guarantee" quality but they help raise the bar to be consistent.
Re: (Score:2)
I've found over the course of my career that I spend over 80% - 95% of our time reading code whilst only 5% - 10% of my time actually writing code.
Good observation.
Re: (Score:2)
... I've found over the course of my career that I spend over 80% - 95% of our time reading code whilst only 5% - 10% of my time actually writing code.
It is therefore imperative we learn to write great code so that OTHERS (including ourselves 6 months down the road) can read it with the least amount of jarring notation.
Yes, programmers become better when they have to read their own code from a year ago, which they are no longer "current on". Been there, got the "T" shirt, wore it out and used it to wash my car... 8-)
Also, Engineers need to be able to write many things, not just code.
Not the code (Score:1)
This is where almost all open source projects I have looked at have failed miserably. Fixing or maintaining code that has negligible or unusable documentation is error-prone and has very high barriers to entry, so only a few "elite" coders do the actual coding, and they figure we don't need no stinkin' comments, because w
Repeating the past and the same *yawn" arguments (Score:1)
Leading with several book recommendations.... for those who've forgotten the past.
"Code Complete" by Steve McConnell
"Writing Solid Code" by Steve MacGuire
"Pragmatic Programmer" by David Thomas and Andrew Hunt
These book will help you understand the reasons for writing code that others will be interacting with as well as code that performs well. They may pertain to older languages and technology stacks, but still a lot of relevant info. There are several others that are more recent, that pertain to "modern"