

How I stopped writing awesome code - jhovgaard
http://jhovgaard.net/how-i-stopped-writing-awesome-code

======
petercooper
Point 1 is about not writing unit tests and instead focusing on acceptance
tests since they can replicate the experience of the boss or customers who
might ultimately complaint to you. If they can't notice something's wrong,
hurrah!

I don't adhere to the philosophy, but there _is_ something to this _if_ you
refuse to do TDD or write unit tests. It's better than _nothing_ and it will
catch the most blatant issues if you replicate the user stories carefully.
It's what I call "minimum viable testing" (MVT!). However, among other
problems, it won't help at all with _refactoring_.. but I suspect a developer
who gives up on unit tests isn't one who's doing much refactoring or
structural work anyway? (Points 2 and 4 imply this.)

 _My personal result of doing all of this is productivity and better products.
I can't tell if I did it all wrong, and that's why I'm writing better code
now, but I truly believe that I'm not alone. In fact I think that most of us
regular web developers, tend to do the same "mistakes" as I did._

There's room for argument over the meanings implied here, especially in
tossing up productivity vs code quality. Is ad hoc, spontaneously designed,
poorly tested code that's doing the job in production "better" than well
planned, well tested code that's still sitting around under development? It
could be yes or no, depending on your viewpoint, but it's important to
appreciate the nuances and the balance involved.

I'll note, however, that more developers than not _do_ develop in this way and
mostly do OK at it. While there's also a large group of developers who'll jump
up and down about architecture, clean code, TDD, and various other
philosophies (me included sometimes!) there's also a whole world out there
unfamiliar with such concepts and still putting together _passable_ software.
The key is knowing _when_ and _why_ certain things matter or are useful, and I
suspect the author of the article has been getting a feel for that and coming
to terms with what disciplines his sort of projects _really_ require (i.e. not
many).

------
herval
I'm by no means a "purist" regarding any specific practice - I agree you don't
HAVE TO test everything, write interfaces for everything and all in all write
"awesome" code. BUT:

\- how often do you interact with other programmers?

\- how long is the usual life span of your code (in other words, what's the
longest timespan you can expect to touch code you wrote in the past)?

\- how big is the app/system you work on?

Imho, this approach ONLY works if the answers to above points are "never", "a
few weeks max" and "very small"...

There's a time and place for every coding "style". Neither "TDD everytime" nor
"cowboy style forever" are the definite answer.

------
Estragon

      > You don't need armor and life, if you kill in one hit!
    

This is why the approach is working for you: you're doing simple stuff.

