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.

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

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!

That is: Make it pretty and readable and DRY once the code works. Until then my code can have several ugly and improvised things I've left for later.

I'm a bit skeptical of that as a general principle.

I want code to be a consistent representation of my mental model of the solution at all times. I use code to help me think, remind me of my thinking and communicate with others. It's not just a series of commands that make a machine do something.

As long as any ugliness is not in conflict with this purpose it's fine. I can totally live with functions that are a bit messy and probably need cleaning up later.

1) Make it work 2) Make it maintainable 3) Make it fast

All three should be on your mind when developing something, but if you have to choose between 2 and 1, go with 1.

My rule is simpler: never write instant legacy code. If it feels like something you won't understand a month later, it likely is legacy code.

If it reads badly (and I'm not talking about this or that brace or whitespace choice), then it also provably is in that category.

(On C2 wiki, a proper SpikeSolution)

If you hit a case your design cannot cleanly handle, it is time for redesign, but often a tiny amount of design constrained by use cases will expose a good design quickly.

Why can't you just keep working until you consider your task done?

Development time is inherently very hard to predict, so strict deadlines - even if set by people who understand the technical issues don't make a lot of sense. There many books on this, and I won't try to summarize them here.

Still, if you have a deadline, you can use your time however you want before the deadline, right? So if it's better/faster to clean up the code after you made it work than to try to type everything perfectly the first time, what's stopping you?

Or is it that the deadlines are so tight that you only have time to write terrible code?

But when I see developers with the self-expectation of clean code take on a task where the architecture is not self-evident, where the architecture probably won't be right the first time, then they often freeze up. Or they move their efforts into the abstractions they do understand, instead of the task they are trying to accomplish.

I'm talking about one single commit.

If I spend 4 hours on a story, the last half hour is probably spent cleaning up things. That's when it's easiest to do, because now that the problem is solved, I understand things the best, and the code is not in flux.

I do not have to ask a manager for permission to do this. If you do, you should really try to find a job where you're trusted to make these simple technical decisions.

If the code is working but is badly designed, that can take longer.

Occasionally, the new feature requires larger refactorings to redesign preexisting code. That can take days, but is of course essential to do.

Adhering just somewhat to principles from the beginning shouldn't make this too time consuming.

1. That's a good way to break it.

2. Typically there is not extra time given to cleanup code, write docs and unit tests.

In my (admittedly anecdotal) experience, devs who tend to overemphasize formatting and DRY are already self-aware about it, whereas those who give it far too little care and attention regularly shoot themselves in the foot by overlooking simple mistakes that get camouflaged in poor formatting and excessive repetition. My concern is mostly that the latter group would see this article as evidence that they can safely ignore code review comments and such.

Formatting, DRY, and good code organization don't solve business problems, but they do make solving those problems (and keeping them solved) a lot easier.

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

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.

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.

And PEPs cover many things.

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.

It is a very tough sell to most customers.

The quick cycle does not scale with project size.

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

How should he have formulated the title then? I think it is logically correct.

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

edit: I wrote "as you said", but I expanded on what you said instead.

Properly anticipating issues takes experience.

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.

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.