7 ms·

There's a lot of value here, but I have to raise concerns about a few things. First, the title: written in the past tense makes it seem like he believes the jo

There's a lot of value here, but I have to raise concerns about a few things. First, the title: written in the past tense makes it seem like he believes the journey is complete. The article itself doesn't convey that message, fortunately. But I think it's worth noting that a critical skill for a professional is constant education - don't be satisfied that you're already "better", get better every day. I also strongly disagree with the suggestion that you should ignore the form of your code. Code is read many, many times more than it is written, so improvements to your own and your teammates' understanding can pay huge dividends. In particular, the advice to "not worry about" DRY and duplicate freely reveals a common misunderstanding. DRY shouldn't be taken literally, it is a recognition that repetition is evidence of some greater underlying truth. By duplicating freely rather than thoughtfully avoiding duplication, you're just creating opportunities for bugs.

Permagate 10y ago
> I also strongly disagree with the suggestion that you should ignore the form of your code. Code is read many, many times more than it is written, so improvements to your own and your teammates' understanding can pay huge dividends. While he explicitly said to ignore fluffs, he followed it up with `Another way to say this is "use your time wisely"`. So I interpreted it as to just not spend too much time on fluffs, rather than completely ignoring it (like code styles as you mentioned). He created Prettier, so I'm sure he knows the value of code styling.
- jredwards 10y ago
  Other people's time is also valuable. Try not to write code that's impossible to read.
  - cloverich 10y ago
    I think pure style (e.g. that a linter would catch) and DRY could be treated separately. The former should always be followed. To the latter: I find weak or incorrect abstractions much harder to follow than repetitive code. And I find those much more commonly when implemented early rather than later. There's definitely a balance, and if you know the type of problem you are solving ahead of time you can probably abstract early. But if you're just kind of feeling around in the dark, which seems to be relatively common in complex business applications (for instance), I much appreciate an implement-test-reflect-refator cycle.
    - AstralStorm 10y ago
      For actual redesign, you end up with a long true refactoring iteration when no new features can be added. There is no guarantee you will not repeat the same mistakes or make it worse. It is a very tough sell to most customers. The quick cycle does not scale with project size.
- couchand 10y ago
  Simply using the term "fluff" to describe the form of code shows a lack of respect that I find deeply troubling. Those that pay little attention to code style, form, names of things, etc. (including those who rely on the tooling to fix it for them) tend to miss other, arguably more critical, things. Sometimes, but not always, this happens because those errors are lost in a soup of poor formatting and copy-paste repetition.
  - Vinnl 10y ago
    But then again, actually writing a code formatter does show quite some respect ;)
  - collyw 10y ago
    I see a lot of article that tell you how to improve code, and they often seem focused in the wrong area. Python's PEP for example, I see the value in it, but you can follow that to the letter and still have a badly designed application and confusing code.
    - Chris2048 10y ago
      Aren't style guides supposed to help write code that is more standard in style, and hence easier to read - because your brain will become accustomed to that style. And PEPs cover many things.
  - hinkley 10y ago
    I had a coworker come to my desk one day, years ago. "Why did you add all that duplicated code to that file??" Huh? Oh, I didn't 'add' that duplication. I took two long files by two different authors, changed them to use the same white space, variable names, comment style and organization strategy. That's all I did. I didn't have the time at that moment to take the next step. He came back four hours later and said that he couldn't stand it and he had refactored the code and fixed/written some tests. Perfect. I learned long ago that there are ways you can start cleaning that will induce (some) others to participate. He spent hours writing tests while I was working on an adjacent part of the code that had worse bugs in it. The work got done and a big piece of the code (this was a project I supported but didn't maintain) didn't, in the end, have my edit history all over it.
richdougherty 10y ago
Responding to your last two paragraphs... James's suggestions about ignoring code form, DRY, etc resonate with me because I'm someone who is usually inclined to spend too much time on those things. I consciously try to reduce the effort I put into those things and instead focus on trying to get the code to actually do something!
- damon_c 10y ago
  There is a good place, somewhere in the middle.
  - pacaro 10y ago
    Always, but with regards to writing clean code, it pays to just learn how to do this upfront. An analogy is of cooking. I used to be a very messy cook, the food is just as good, but when I was done the kitchen looked like a bomb had hit it. Cleaning becomes intimidating at that point. Learning to be cleaner in my processes didn't change the end result for the food, but made the rest of the evening much more pleasant. Professional cooks and chefs learn to optimize this, they are neat and clean where this is most efficient, and offload cleanup to a plongeur where necessary. Secondly I believe that with practice, DRY can become second nature. Back in the mid 90s I wrote a lot of COM code in straight C (for reasons). This ends up being extremely verbose, so repetition carried a sufficient penalty that I learned to avoid it, to carry a sufficient mental model of the code base to know when I could avoid repetition. [edit] plonjeur -> plongeur
    - couchand 10y ago
      I love your use of the cooking metaphor here. Are you expanding on Uncle Bob's discussion of it in The Clean Coder or was that just a coincidence? If I remember correctly, he uses it there to describe the difference between delivering quickly once (and making a mess in the kitchen) and reliably producing over the long term (by taking a little extra time to clean as you go). Adding the spin about the learning process really (forgive me) sweetens it.
sriku 10y ago
The note about DRY didn't sound like a mandate to ignore it entirely and "duplicate freely". As you said, duplication is a way to ratify that a common pattern exists first before putting something in place that captures the pattern. Many young programmers try to anticipate these concepts and end up with some form of over-design. The goal of DRY is not so much to avoid duplication, but to figure out useful concepts in ground-up work. "Beta abstraction" is a useful mechanism for this. Wrote a post capturing some discussions in my org. [1] [1]: http://sriku.org/blog/2016/02/06/beta-abstraction-for-bottom-up-theory-building/ http://sriku.org/blog/2016/02/06/beta-abstraction-for-bottom... edit: I wrote "as you said", but I expanded on what you said instead.
- AstralStorm 10y ago
  If you do not anticipate concerns and rely solely on bottom up design, you are guaranteed to require expensive rewrites. Plural. It is also as trivially easy to end up with bad abstraction bottom up add top down, usually by not taking measures to uncouple components (also known as leaking implementation in abstraction) Properly anticipating issues takes experience.
  - sriku 10y ago
    Thus far, "properly" has been elusive - I.e. we know it when we see it, but not beforehand. It has been easier to instruct people to look at past concerns in similar projects and tick off which ones are relevant based on current constraints and requirements. So it is not a one-time task to set the "properly" needle right, but a continuous one to keep adjusting it as the cases evolve. The way abstractions are usually laid out is by trying to generalize a concept, usually along simplistic lines without attempting to substantiate it. Beta abstraction provides a substantiatable route which could involve a bit of repeating before the abstraction surfaces. For example, the Pixar cars don't form a class hierarchy with a "car" base class - there is only one class "car" and the variety is generated by configuration (need to pull up ref for this, as I read this long ago). This may not be an obvious step for someone not in the domain.
pacomerh 10y ago
Same thought here. He makes it sound like he got to the finish line. This is an infinite journey. Good read though.
- zoul 10y ago
  He explicitly writes: Even now, though, I continually doubt myself. The point is that this feeling doesn't go away, so just try to ignore it, keep hacking, and keep building experience.
bobwaycott 10y ago
I met James around 9 years ago when I was first starting out in professional development, before he eventually joined Mozilla. I inherited more than one massive project from him, and I'd like to assure you he did not actually ignore the form of his code, nor did he avoid improvements that paid huge dividends. I've always been rather OCD about DRYness, and I never had cause to complain about the quality of his work, nor was there ever much of any duplication. I believe the spirit of what he's trying to get at is not letting concern for DRYness stand in the way of working things out. I saw this in practice many times, and even approach complex projects in much the same way--I'll typically not worry about DRYness until I've implemented something a couple of times, sometimes in different ways, to get a feel for how I can approach it best. Once I've figured that out, I clean things up. I've seen many junior devs get so worried about the quality of their code, and how they should do things, and omgosh, DRY that they can often become paralyzed and don't just start writing code. I've been mentoring someone for nearly 18 months, and I'm always trying to push him to just start coding and get something working, then come back and discuss and evaluate his work together. I think you've misunderstood what James has said, and feel compelled to push back on any suggestion that his advice regarding DRY and duplication is borne of any misunderstanding or lack of recognition of the value of DRY. Nor is he someone who I've ever seen stop learning. I keep up with his work, and I'm always impressed by the different things he picks up just because something about it interests him.
- Chris2048 10y ago
  > I've seen many junior devs get so worried about the quality of their code, and how they should do things TBH, junior devs are often hammered constantly throughout training about this stuff. They are drilled on design patterns before having even coded anything significant. It's not surprising they can only breathlessly parrot software principles when they begin..
- jlongster 10y ago
  Holy crap Bob, hi! Thank you for the kind words :) (and be honest, I'm sure there were things to complain about from my projects haha)
  - 10y ago
nallerooth 10y ago
My interpretation was more like "do not focus too much on the form of your code, while you are figuring things out". Which I think is decent advice. The classic line "Make It Work, Make It Right, Make It Fast"[1] may have communicated this concept in a better way (with each step explained). [1] http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
- rimliu 10y ago
  Yes. There is also "wrong abstraction is worse than code duplication".
amelius 10y ago
> First, the title: written in the past tense makes it seem like he believes the journey is complete. How should he have formulated the title then? I think it is logically correct.
- couchand 10y ago
  Anything in the present tense would be preferable. Just a one letter change would be an improvement: "How I Become A Better Programmer". If it's in the past tense, possibly some indication that he's partway along the journey, such as "How I Got to the Level of Programmer I Am Today" (not as punchy, needs editing).

Permagate 10y ago

> I also strongly disagree with the suggestion that you should ignore the form of your code. Code is read many, many times more than it is written, so improvements to your own and your teammates' understanding can pay huge dividends. While he explicitly said to ignore fluffs, he followed it up with `Another way to say this is "use your time wisely"`. So I interpreted it as to just not spend too much time on fluffs, rather than completely ignoring it (like code styles as you mentioned). He created Prettier, so I'm sure he knows the value of code styling.

jredwards 10y ago
Other people's time is also valuable. Try not to write code that's impossible to read.
- cloverich 10y ago
  I think pure style (e.g. that a linter would catch) and DRY could be treated separately. The former should always be followed. To the latter: I find weak or incorrect abstractions much harder to follow than repetitive code. And I find those much more commonly when implemented early rather than later. There's definitely a balance, and if you know the type of problem you are solving ahead of time you can probably abstract early. But if you're just kind of feeling around in the dark, which seems to be relatively common in complex business applications (for instance), I much appreciate an implement-test-reflect-refator cycle.
  - AstralStorm 10y ago
    For actual redesign, you end up with a long true refactoring iteration when no new features can be added. There is no guarantee you will not repeat the same mistakes or make it worse. It is a very tough sell to most customers. The quick cycle does not scale with project size.
couchand 10y ago
Simply using the term "fluff" to describe the form of code shows a lack of respect that I find deeply troubling. Those that pay little attention to code style, form, names of things, etc. (including those who rely on the tooling to fix it for them) tend to miss other, arguably more critical, things. Sometimes, but not always, this happens because those errors are lost in a soup of poor formatting and copy-paste repetition.
- Vinnl 10y ago
  But then again, actually writing a code formatter does show quite some respect ;)
- collyw 10y ago
  I see a lot of article that tell you how to improve code, and they often seem focused in the wrong area. Python's PEP for example, I see the value in it, but you can follow that to the letter and still have a badly designed application and confusing code.
  - Chris2048 10y ago
    Aren't style guides supposed to help write code that is more standard in style, and hence easier to read - because your brain will become accustomed to that style. And PEPs cover many things.
- hinkley 10y ago
  I had a coworker come to my desk one day, years ago. "Why did you add all that duplicated code to that file??" Huh? Oh, I didn't 'add' that duplication. I took two long files by two different authors, changed them to use the same white space, variable names, comment style and organization strategy. That's all I did. I didn't have the time at that moment to take the next step. He came back four hours later and said that he couldn't stand it and he had refactored the code and fixed/written some tests. Perfect. I learned long ago that there are ways you can start cleaning that will induce (some) others to participate. He spent hours writing tests while I was working on an adjacent part of the code that had worse bugs in it. The work got done and a big piece of the code (this was a project I supported but didn't maintain) didn't, in the end, have my edit history all over it.

richdougherty 10y ago

Responding to your last two paragraphs... James's suggestions about ignoring code form, DRY, etc resonate with me because I'm someone who is usually inclined to spend too much time on those things. I consciously try to reduce the effort I put into those things and instead focus on trying to get the code to actually do something!

damon_c 10y ago
There is a good place, somewhere in the middle.
- pacaro 10y ago
  Always, but with regards to writing clean code, it pays to just learn how to do this upfront. An analogy is of cooking. I used to be a very messy cook, the food is just as good, but when I was done the kitchen looked like a bomb had hit it. Cleaning becomes intimidating at that point. Learning to be cleaner in my processes didn't change the end result for the food, but made the rest of the evening much more pleasant. Professional cooks and chefs learn to optimize this, they are neat and clean where this is most efficient, and offload cleanup to a plongeur where necessary. Secondly I believe that with practice, DRY can become second nature. Back in the mid 90s I wrote a lot of COM code in straight C (for reasons). This ends up being extremely verbose, so repetition carried a sufficient penalty that I learned to avoid it, to carry a sufficient mental model of the code base to know when I could avoid repetition. [edit] plonjeur -> plongeur
  - couchand 10y ago
    I love your use of the cooking metaphor here. Are you expanding on Uncle Bob's discussion of it in The Clean Coder or was that just a coincidence? If I remember correctly, he uses it there to describe the difference between delivering quickly once (and making a mess in the kitchen) and reliably producing over the long term (by taking a little extra time to clean as you go). Adding the spin about the learning process really (forgive me) sweetens it.

sriku 10y ago

The note about DRY didn't sound like a mandate to ignore it entirely and "duplicate freely". As you said, duplication is a way to ratify that a common pattern exists first before putting something in place that captures the pattern. Many young programmers try to anticipate these concepts and end up with some form of over-design. The goal of DRY is not so much to avoid duplication, but to figure out useful concepts in ground-up work. "Beta abstraction" is a useful mechanism for this. Wrote a post capturing some discussions in my org. [1] [1]: http://sriku.org/blog/2016/02/06/beta-abstraction-for-bottom-up-theory-building/ http://sriku.org/blog/2016/02/06/beta-abstraction-for-bottom... edit: I wrote "as you said", but I expanded on what you said instead.

AstralStorm 10y ago
If you do not anticipate concerns and rely solely on bottom up design, you are guaranteed to require expensive rewrites. Plural. It is also as trivially easy to end up with bad abstraction bottom up add top down, usually by not taking measures to uncouple components (also known as leaking implementation in abstraction) Properly anticipating issues takes experience.
- sriku 10y ago
  Thus far, "properly" has been elusive - I.e. we know it when we see it, but not beforehand. It has been easier to instruct people to look at past concerns in similar projects and tick off which ones are relevant based on current constraints and requirements. So it is not a one-time task to set the "properly" needle right, but a continuous one to keep adjusting it as the cases evolve. The way abstractions are usually laid out is by trying to generalize a concept, usually along simplistic lines without attempting to substantiate it. Beta abstraction provides a substantiatable route which could involve a bit of repeating before the abstraction surfaces. For example, the Pixar cars don't form a class hierarchy with a "car" base class - there is only one class "car" and the variety is generated by configuration (need to pull up ref for this, as I read this long ago). This may not be an obvious step for someone not in the domain.

pacomerh 10y ago

Same thought here. He makes it sound like he got to the finish line. This is an infinite journey. Good read though.

zoul 10y ago
He explicitly writes: Even now, though, I continually doubt myself. The point is that this feeling doesn't go away, so just try to ignore it, keep hacking, and keep building experience.

bobwaycott 10y ago

I met James around 9 years ago when I was first starting out in professional development, before he eventually joined Mozilla. I inherited more than one massive project from him, and I'd like to assure you he did not actually ignore the form of his code, nor did he avoid improvements that paid huge dividends. I've always been rather OCD about DRYness, and I never had cause to complain about the quality of his work, nor was there ever much of any duplication. I believe the spirit of what he's trying to get at is not letting concern for DRYness stand in the way of working things out. I saw this in practice many times, and even approach complex projects in much the same way--I'll typically not worry about DRYness until I've implemented something a couple of times, sometimes in different ways, to get a feel for how I can approach it best. Once I've figured that out, I clean things up. I've seen many junior devs get so worried about the quality of their code, and how they should do things, and omgosh, DRY that they can often become paralyzed and don't just start writing code. I've been mentoring someone for nearly 18 months, and I'm always trying to push him to just start coding and get something working, then come back and discuss and evaluate his work together. I think you've misunderstood what James has said, and feel compelled to push back on any suggestion that his advice regarding DRY and duplication is borne of any misunderstanding or lack of recognition of the value of DRY. Nor is he someone who I've ever seen stop learning. I keep up with his work, and I'm always impressed by the different things he picks up just because something about it interests him.

Chris2048 10y ago
> I've seen many junior devs get so worried about the quality of their code, and how they should do things TBH, junior devs are often hammered constantly throughout training about this stuff. They are drilled on design patterns before having even coded anything significant. It's not surprising they can only breathlessly parrot software principles when they begin..
jlongster 10y ago
Holy crap Bob, hi! Thank you for the kind words :) (and be honest, I'm sure there were things to complain about from my projects haha)
- 10y ago

nallerooth 10y ago

My interpretation was more like "do not focus too much on the form of your code, while you are figuring things out". Which I think is decent advice. The classic line "Make It Work, Make It Right, Make It Fast"[1] may have communicated this concept in a better way (with each step explained). [1] http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

rimliu 10y ago
Yes. There is also "wrong abstraction is worse than code duplication".

amelius 10y ago

> First, the title: written in the past tense makes it seem like he believes the journey is complete. How should he have formulated the title then? I think it is logically correct.

couchand 10y ago
Anything in the present tense would be preferable. Just a one letter change would be an improvement: "How I Become A Better Programmer". If it's in the past tense, possibly some indication that he's partway along the journey, such as "How I Got to the Level of Programmer I Am Today" (not as punchy, needs editing).