
Too scared to write a line of code - whosbacon
https://medium.com/i-m-h-o/eef96ea6f4cb?imm_mid=0a9102&cmp=em-velocity-newsletters-vl-save20-20130523-direct
======
cheald
This is really kind of the whole idea behind the "red, green, refactor"
mantra. The point isn't to write perfect code right out of the gate, it's to
write _working_ code. Once the test is green, then you can refactor as
necessary with the confidence that you aren't going to accidentally break
things (as the test will backstop you).

Ironically, I think this is something that affects seasoned programmers more
than new ones; the more you know about the trade, the more voices you have
saying "no, that's wrong! Don't do that!", which can freeze progress. The way
I combat it is by writing down pseudocode in my source code - literally just
english, non-compiling pseudocode - which I then "refactor" into working code
(thus the first "green" is "it parses"). By making step 0 the expression of
the idea rather "writing the fist line of code", I can get right into the
process rather than getting hung up on the "how".

~~~
minikomi
Also kind of related - programming by "wishful thinking". You first lay out
the flow of the program as calls to high level functions which don't yet
exist, and then go back and fill in the functions as you can. The first few
SICP video lectures are all about this style, and I found the idea simple but
very useful to avoid trying to hold too much of a problem in your head at
once.

~~~
cheald
Yes, exactly. By writing pseudocode, I end up writing business code rather
than implementation code, which inherently assumes the a high-level interface
to the nitty-gritty details. This leads to an approach where the idea is
expressed at a high level first, rather than getting stuck in the
implementation details of some small piece of the problem.

~~~
vog
It's kind of "breadth-first search" on software development, while the classic
approach is more "depth-first search".

On the other hand, it is also important to quickly get into the state of a
running program, because only that allows for iterative development where you
can catch bugs shortly after you wrote them, rather than having tons of bugs
after weeks of (not sufficiently tested) work.

------
steven2012
I program the way that I imagine I would sculpt. If I had to sculpt a head, I
wouldn't start by sculpting the perfect ear, and then sculpting the perfect
eye, etc, because who knows what will happen. Maybe in the course of sculpting
the eye, I need to move the ear, and then all that work goes out of the door.

Instead, I would sculpt the entire piece of art roughly, almost
unrecognizably, and then target large parts of the sculpture. Details like
ears and eyes might even never get done, depending on how the requirements
change for the sculpture.

I always approach writing software the same way, so the first iteration is
just a hardcoded piece of software that just shows me that it will actually
work, and then I iterate and start smoothing out all of the sharp edges, of
which there are a ton.

------
andrewljohnson
People interpret "just do it" as practical advice to write good code, but
really it's practical advice to get code from people who won't otherwise write
anything. Good code comes from both will and knowledge. When you don't have
knowledge, will alone will do.

"Just do it" is the best advice for stuck people - you tell them to just start
doing the thing, not worry about details, and eventually you'll do it right.
This is good advice for a business guy who's pin-wheeling ideas in his head, a
programmer with no product sense, or anyone else who wants but does not make.

When you know a little bit about what you want to build, and maybe even a bit
about _how_ to build it - when you have some actual experience, skill, and
will - then the right advice is typically to slow down and think it through.

~~~
jlgreco
I have a theory that the extent to which the "Balmer peak" actually exists is
the extent to which it makes the "just do it" advice easier to follow.

------
danso
What keeps me from coding is not necessarily optimization (well, at least its
connotation connected to speed), but maintainability...By that I mean the
constant battle between, "Do I write the boilerplate I need to set this up
right?" and "Let me just copy/paste/mock all of that". To me, this is a more
sapping concern than optimized code, because taking too many shortcuts makes
the project harder to maintain in its midstages...even worse, the shortcuts
can cause sloppiness to cascade into the design of all the other dependent
objects and interfaces.

Doing some nominal TDD has helped quite a bit for me, because it does require
writing code, but not code that I have to worry too much about (and if it
happens to be a pretty shitty, shortsighted test, I can delete it without it,
theoretically, hampering the app) screwing me over. Sometimes this physical
act is enough to get me past the code-writing block.

Also, if I actually do the testing right, it prevents regression, improves
code quality, etc. etc.

~~~
yarou
I think it ultimately comes down to "choose the right tool for the job". TDD
is just one tool that you have in your toolbox to accomplish whatever project
you are working on. That doesn't mean that TDD is appropriate for _every_
project.

------
notacoward
It's an oldie but a goodie. Fred Brooks:

"Plan to throw one away. You will anyway."

The mistake most people make is that they mix learning and doing in a single
round. It's much better to write a prototype with a specific goal of wringing
as much knowledge from it as you can without being distracted by scalability
or maintainability minutiae. Then, and only then, will you be ready to write
The Real Thing with all of the bells and whistles. In the end you'll probably
save more time than if you kept going back and forth waterfall-style between
learning and doing on the same codebase. You'll certainly end up with a better
result.

P.S. That quote is from 1975. To quote another great mind (Santayana): those
who do not know...

------
rmason
I remember when Facebook's front page code leaked. I am no PHP expert, but it
was pretty ugly code. Probably today you couldn't get hired at Facebook if you
wrote code like that.

[http://techcrunch.com/2007/08/11/facebook-source-code-
leaked...](http://techcrunch.com/2007/08/11/facebook-source-code-leaked/)

I've heard many arguments where people will tell you, it won't scale. Or
you're doing it all wrong by writing quick and dirty procedural code. Quite
frankly scaling is about the nicest problem to have if you're a startup.
Without traction your ugly code simply isn't going to matter. With traction
you will gain funding and the ugly code problem quickly disappears like I
assume it did at Facebook.

~~~
daeken
> Quite frankly scaling is about the nicest problem to have if you're a
> startup.

I'm certain I stole it from someone here on HN years ago (whoever it was, I
owe you a beer!), but I've always called this a "Maserati Problem". That is,
it's something I can think about while I'm driving down the road in my
Maserati that I've purchased with money my startup has made already.

Scaling, in most cases, is a problem very much like "where am I going to store
all this money that's pouring in?!" If you have it, you've already won.

------
laumars
I'm by no means a pure functional programmer, but I've found some of the
mantra from that paradigm helps when building the early blocks of a program as
it allows you to break down your application into core problems which can be
tackled individually. Plus it allows your application to scale easier and
makes it easier to rip out and replace code as you start to add complexity.

But of course, before starting any major project, the first thing any
developer should do is map out _at least_ a basic mental design of the program
- even if that map isn't written in pseudo-code or in a form of a flow chart.

~~~
dustingetz
in other words, FP evolved to solve _hard_ problems. You don't need to
understand monads to model a cash register. You probably do need monads if you
want to write a bug free distributed asynchronous system.

~~~
pseut
I don't know that you need monads, but a lot of recent languages seem designed
to guide programmers to certain types of good design. You don't _need_ the
language to emulate the design ideas.

------
agentultra
I've missed coding with whimsy and curiosity. There was a time in my life when
it wasn't all _engineering_. Characters from the Lord of the Rings trilogy
made their way into tutorials and references to the Flying Circus were
everywhere. Communities were a lot more accepting of newcomers and few people
were so paranoid of _bad, unmaintainable, spaghetti code_. There was less of a
focus on being a _10x developer_ and more on learning, having fun, and doing
neat things.

I'm probably remembering things with rose-tinted glasses.

These days, even in open source -- the once proud land of eccentric hackers
and the _can-do_ spirit, there is such a negative focus on _bad developers_. I
can certainly see how the OP could feel paralyzed when just trying to write a
line of code.

In reality we're all at different points in our journey and have had different
experiences along the way. There's always room to improve ourselves and it's
important to listen to criticism so that we know where to start. But sometimes
you just need to cut loose and let it all hang out. I started writing a
library I call "Horton," for this very purpose: _whimsy_ , _pleasure_ , and
most of all to _avoid_ the engineer mindset!

In order gain insights and develop new ideas you have to find new hunches and
investigate them. It's hard to develop hunches in a vacuum where your reality
doesn't expand beyond your own self-made bubble. You've got to push once in a
while... and people out there who complain so loudly about _shitty_
developers? Get a life and help someone out. We're just making programs.

 _update_ : <https://github.com/agentultra/Horton> forgot the link...

------
tikhonj
I don't know--my impression is that most people go to far in the _other_
direction. They write code with no thought at all for the future, and then
shortly have nightmarish debugging sessions in spaghetti code that's
impossible to extend or reuse. All in the name of a rather extreme "worse is
better" philosophy.

I've certainly experienced this with some of the people I worked with
recently. Anything you win in the short term gets lost several weeks--if not
_days_ \--later when everything is a horrible mess. Don't even think about
coming back to that code months later!

I've found that putting in a little bit of care for the future pays off even
in the short term. Perhaps not on the scale of hours or days, but definitely
_weeks_. Which is still pretty immediate.

However, _how_ you do this is also very important. The handy rule I've been
using is simple: simplicity. Improve your code by making it do _less_ not
_more_. If you can make code more maitainable or general by simplifying, do
it. If it would require adding new concepts or mental overhead, reconsider.
Try to reuse existing abstractions as much as possible.

This usually--but not _always_ \--means making your code more functional. Do
you really need to write this operation in place? Do you really need to tie
everything together with a bunch of implicit state changes? Probably not! This
is not to say that you should _never_ use state: just be sure to only use it
when it fits well and makes sense. And be explicit about it.

The functional style (at least in languages like Haskell) also lends itself
very well to reusing simple and general abstractions. The key idea here is
that these abstractions are _not_ about doing more: they're about doing
_less_. More general code simply leaves you less room to make mistakes. If
you're working with lists of numbers, there are all sorts of arithmetic
mistakes you can make; if you manage to write the same code against lists of
_anything_ , the only mistakes possible will be in list handling.

Haskell just makes this more practical by providing abstractions with a great
"power-to-weight ratio": ones that manage to be simple, general and yet still
expressive. Code with functors or monoids or traversables is easier to write
than more concrete code and yet still flexible enough for many useful tasks.
As a bonus, it's also more reusable. For free.

So the key idea is reduction: all these abstractions work by _stripping_
concrete types of power. A functor can do much less than a list. A monoid can
do much less than a number. This lets you write nicer code without becoming an
"architecture astronaut" because instead of adding structure, you're really
taking it away.

I've found that programming like this _really_ helps in maintaining and
extending the code later on. But it doesn't slow me down when I'm writing
either--I actually _save_ time because I spend less getting time getting the
code correct in the first place.

These days, I've started being able to make large changes or add complicated
features and have them work on the first try. Not every time, but surprisingly
often. Certainly much more often than before! In large part, I think this is
because of writing the code with an eye towards simplicity.

So the important insight: take the _simple_ route, not the _easy_ route.

~~~
Zakharov
If you write code too slowly, go faster. If you write code too quickly, go
slower.

You can tell if you're too slow when you've spent two weeks thinking about the
program and have neither working code nor a detailed design, or if you've
created a detailed design only to realize upon implementation you'd gone about
it entirely the wrong way.

You can tell if you're too fast if you find yourself spending more time
cleaning up messes of poorly-thought-out spaghetti code.

~~~
andrewljohnson
This is like in go. If your walls are too brittle, play more conservatively.
If your walls are too thick, loosen up. You can make generally better moves in
go just by recognizing if you are too conservative or too aggressive. Same
with poker.

~~~
avalaunch
Upvoted to make up for MBlume's mistake. :)

~~~
Zecc
Upvoted again, because I felt like it. But it's still one upvote short, I
guess.

~~~
mgkimsal
Fixed. :)

------
johnvschmitt
This is good advice when you're new to a stack.

But, if you know better, do better please.

After writing tons of code, I've come to realize that 80% of the time, it
takes about the same time to do it "right" (scalable/secure/modular) as it
does to do it "OK".

Ex: Are plaintext passwords any faster to build/code than encrypted+salt
passwords? Nope.

And, it's fine to intend to refactor later. But, too many organizations have
no tolerance later to let engineers do things that don't have visible results.
I've suffered through a stint of handling "legacy code" like that & it was
painful & demoralizing.

------
KVFinn
In general writing a trick to get around this is to do a 'vomit draft' --
intentionally write something bad.

In part, this is simply to get past the analysis paralysis or creative block
and get going on something. But also because it can sometimes be easier to
make something good when you have a clear bad example in front of you to
contrast it with.

------
dvt
(From a couple of years ago: <http://dvt.name/2010/ward-cunningham-on-
simplicity/>)

Occasionally, I find myself “stuck” when writing code – the coder’s “writer’s
block” I guess. This quote by Ward Cunningham is both inspiring and truthful:

\-- Once we had written it, we could look at it. And we’d say, “Oh yeah, now
we know what’s going on,” because the mere act of writing it organized our
thoughts. Maybe it worked. Maybe it didn’t. Maybe we had to code some more.
But we had been blocked from making progress, and now we weren’t. We had been
thinking about too much at once, trying to achieve too complicated a goal,
trying to code it too well. Maybe we had been trying to impress our friends
with our knowledge of computer science, whatever. But we decided to try
whatever is most simple: to write an if statement, return a constant, use a
linear search. We would just write it and see it work. We knew that once it
worked, we’d be in a better position to think of what we really wanted. --

Next time you’re stuck, just write the simplest thing that could possibly
work!

\-- So when I asked, “What’s the simplest thing that could possibly work,” I
wasn’t even sure. I wasn’t asking, “What do you know would work?” I was
asking, “What’s possible? What is the simplest thing we could say in code, so
that we’ll be talking about something that’s on the screen, instead of
something that’s ill-formed in our mind.” I was saying, “Once we get something
on the screen, we can look at it. If it needs to be more we can make it more.
Our problem is we’ve got nothing.” --

Source: <http://www.artima.com/intv/simplest.html>

------
hawkharris
I write news articles in addition to code, and a fellow writer gave me a
simple piece of advice that I think applies to both disciplines. It has to do
with planning -- but not over-thinking -- your work.

Before you start writing, sit down with a friend in a bar and explain to him
exactly what you're trying to say and do. If you can't communicate your idea
in a concise, conversational way, then you're not ready to start writing.

Applied to code, I suppose this is similar to the concept of Rubber Ducky
Debugging: <http://en.wikipedia.org/wiki/Rubber_duck_debugging>

------
dustingetz
you need to learn calculus if you want to model relativity. you only need
fifth grade math to model a cash register.

if your team builds apps with 500k LOC, you need to be constantly focused on
abstracting and factoring out patterns or you will drown in your defect rate
before the project even ships. If your team builds medical device software, if
you aren't doing this, you'll get someone killed.

If you're building a personal blog, your time is better spent by pasting
jquery snippets.

There is a spectrum here and most projects fall somewhere in between.

~~~
dsirijus
Of course. And to add an example of the other part of spectrum (opposed to
medical device software) - bunch of simple 2d game prototypes. There's people
who do such jobs, and many similar, who'd be a fool not just "push the
buttons" _all the time_ , with basically just a quick forethought related to
structurization and code quality.

------
jstanley
I can identify with this. Some of the best work I've ever done has been some
of the worst code, just because of the paradigm shift involved: "get shit
done" instead of "write nice code".

------
jamieb
I understand completely.

"And all that is fantastically interesting, but completely beside the point. I
just fell into the classic programmer trap of exploring and learning about
(what I find) fantastically interesting things that will address all sorts of
amazingly complex situations, _but which the learning of said things resulted
in absolutely nothing of tangible value being created_."

<http://www.jamiebriant.com/blog/2013/1/fireworks.html>

------
systematical
I disagree. Too simplistic. It's my job as a developer to try and think of all
the ways my project can fail and bog down before hand (within reason on the
performance). I've got a list of items I am actually working on and will post
it above my desk when done:

1\. Let me think about this some more before giving you an answer.

2\. I will use my debugger.

3\. I will create a new branch for this task.

4\. I have commented my code and commented it well.

5\. I have accounted for fail scenarios.

6\. I have considered multiple solutions to this task.

7\. I have not begun hacking away immediately at a task.

8\. I have attempted exploiting my code.

------
shurcooL
Here's what I came to after 10 years.

1\. Write code fast.

2\. Refactor when necessary (either because you got to a dead end and can't
keep writing code fast anymore, or because you're done and want to move on to
another task).

3\. Goto 1.

------
c0mpute
The problem with this approach, while great for you, the developer it is a
nightmare for the future team.

I am now working at a startup where the early devs have left. They did
precisely what was needed at that point - build quickly, ensure it works for
the 3/4 customers we had back then and document it as well. Fast forward a
year later, that same code is no longer extensible for many clients. Its rigid
and tightly coupled and rewriting some parts means, we have to pretty much
rewrite a whole lot more than we bargained for. We will have to burn through a
lot of cash to just build a whole new product based on some of the scalability
and maintenance learning we now have from a year of learning and growing to
client# 100.

The point is, there is always going to be "this is the right thing right now,
its what our customers want" and then something else for the future.

I have seen that people who have worked for a while and in many startups do
the smart thing (as expected) and while follow "build for now" they also do
the sensible thing of investing for the future (from experience).

------
munger
I can relate to this. There is a real risk in freezing up when you attempt for
your first writing of code to be the fully architected solution.

I would still go one step further and at least apply the strategy
pattern/polymorphism when you have a large if/else/case block going beyond 2
or 3 conditions in a controller or model or something. (assuming MVC web apps)

The fact is you can write out some ugly code directly in a controller where it
might get some code working fast and prevent the freeze up of your output, but
once working you should immediately move it to the appropriate place like a
model or library, and apply a basic OO strategy pattern (perhaps not with
factory/interfaces etc until needed later) where appropriate to cut down on
spaghetti/nested conditionals.

This really does not take much more time than stopping at working code that is
ugly, and is a good middle ground where it is not painful to return to later.

There is still no good excuse for "taking a dump in the corner" of your code
base just to get a marginal gain in output.

------
kbenson
I can relate to this, somewhat. I've spent quite a bit of the last few years
writing code either under deadline, or for work that's ultimately charged
hourly. That doesn't lend itself to thoughtful refactoring.

As such, when I'm not under those constraints, I sometimes go a little
overboard factoring out duplicated code and looking for the beautiful
solution. To me, beauty is the maximization of clarity _and conciseness_.
Since I'm usually writing Perl, there's quite a lot to work with in that
regard.

For example, yesterday I spent 4-6 hours writing approximately 40 lines of
Perl (along with another 40 lines of tests).

On the plus side, what I generate during these binges is generally an
efficiency multiplier for the other code I write, as well as a god way to
really examine some of the more esoteric, but useful, ways to use your chosen
language.

------
joeblau
This is a great post. I just wrote about a project I worked on in February[1].
When I first built the website, it wasn't optimized and now I realize that I
greatly over estimated how many resources I thought the site would need.

Last week, after getting to the first page on Google's search results, I'm
getting about 12,000 hits a week. Monitoring shows my daily CPU usage is
nearly 0%, and memory usage around 32MB. Today(3 months later) I finally did
some SEO, added compression, caching, and a CDN to get drop page load time
from ~2 seconds to under 500ms.

[1] <https://medium.com/look-what-i-made/5d808ce36277>

------
alickus
"Build it, release it, analyse it and only then decide if it needs
optimising." I think it depends from company culture.

The thing is if you don't do it right with first go you will have hard time to
get it done later. What management cares if it works, it's your responsibility
to make it right from the start and they probably won't give you time to make
some refactoring/optimizations later, because time is money :(. Sometimes it's
hard to explain consequences. I have seen this too many times.

I believe you need to find golden middle, by not trying to hack things to much
or overengineering problem, though sometimes is hard to define where is this
middle.

------
6ren

      A complex system that works is invariably found to have evolved
      from a simple system that worked.
    

<http://en.wikipedia.org/wiki/Gall%27s_law>

------
zerooneinfinity
"We are what we do repeatedly." If you spend time thinking about best
practices, it becomes easier and less time consuming. You need a balance of it
early in your career but if you're constantly working at it, it'll become
second nature. In my opinion, the best programmers are the ones who have
exceptional practical wisdom, who know when to utilize a rule and when to
yield to exceptions (no one likes a ferengi programmer --
[http://www.codinghorror.com/blog/2009/02/the-ferengi-
program...](http://www.codinghorror.com/blog/2009/02/the-ferengi-
programmer.html)).

------
mzarate06
_Build it, release it, analyse it and only then decide if it needs
optimising._

I often share a similar sentiment with teams I work with: _Don't throw
solutions at undefined problems._

That commonly applies to performance and premature optimization.

I'll agree that there needs to be some thought as to what's being built
before, and while, doing so, but spending time resolving as-of-yet-undefined
problems means decision making based on high levels of uncertainty.

Get something working and let problems define themselves. Often times, they do
so in a way that makes them easier to fix vs. relying on the speculative
solution making I mentioned above.

------
themanr
This calls to mind what Zed Shaw wrote about creative and defensive programmer
mindsets. <http://c.learncodethehardway.org/book/ex27.html>

------
rhizome
So what's this "velocity newsletters" campaign Medium is running in their
URLs?

------
iframe
There are thousands of guidelines and many of the contradict each other ..
there are many advisors creating posts, tutorials, patterns but I think you
should work the way your ecosystems require it , don't try to be perfect just
get things done and ensure your code will work in critical cases. Sometimes I
wish I could be up to date in all the best practices but is just impossible
some developers like me we work with deadlines and there's not much chance to
try new things.

------
namenotrequired
A few more comments on this from earlier this week here:
<https://news.ycombinator.com/item?id=5736911>

------
thisone
One thing I've learned from having to do rapid prototype development is to
just put fingers to keyboard and go.

If I find myself getting stuck in the cycle of "this can be written better,
I'll just spend 2 hours improving it rather than finishing the framework" I
stop, I think about it, then I leave the working-but-probably-crap code in
place and move on.

Once the framework is in place, then I start making things better, one area at
a time.

------
motters
Thinking about scalability or portability of the code from day 1 is useful
because it may be difficult to crowbar those things in on day 200.

That said, don't dither too much over writing code. History favours the doers
rather than the vacillators. Most software except for utilities has a quite
short working life anyway. There is also the standard advice of "expect to
throw one away".

------
Nervetattoo
Actually you need to stop earlier, I've found that quite a bit of the stuff
that people think they need to have built isn't even close to needed in
reality. In fact, building it and shipping it can be a major mistake itself.

So I completely agree on the underlying principle: Dont to _anything_
prematurely, and that first and foremost includes actually writing any code at
all.

------
wb14123
This point is very like an engineer's point, which have many years of
development experience. He tell me when I'm a intern in the company. I always
like to write perfect and complete code that time. But you must _write_ code
first, so that other people could cooperation with you. Just write and see and
test, then you can find the problem.

------
MichaelAza
This is the god-knows-which time this link surfaces on HN and I keep saying
the same thing - once all this stuff is ingrained you don't think about design
patterns, you just do them. Either that or you decide what to do in a design
session or on the whiteboard.

Thinking about this stuff is the sign of either a newbie or lacking up-front
design.

------
zobzu
There's a freaking huge difference between double checking every single line
of code, and coding a new features (hundred, thousand of lines of code) with a
scalable design.

Does that resonate enough for you?

Seriously, seeing stuff black&white is how bad code happens. (And so many
other things in life.)

------
readme
With experience, you will know where you need to put a little extra effort in
to avoid having to rewrite it later because it's too slow.

Also, test your app with LOTS of data. Even during early development. A slow
algorithm/query will become very obvious under a high load.

------
pseut
There's another approach from polya's _how to solve it._ If your problem is
too hard to solve, find an easier related problem and solve it first. Which I
guess is sort of like applying an MVP to parts of the project as well as the
whole thing.

------
geetee
Sure, go hog wild on anything and everything... except protecting my privacy
and security.

------
analytic
Just be prepared that if you write a service that does not scale, that will
eventually bite you painfully bad with massive amount of data going nowhere
but stuck in the stupid relational database with terabytes of data.

------
conorwade
Like most things in life, I feel like a sense of balance is the most important
thing to be aware of. Jumping into code too quickly is just as bad as trying
to design the perfect system from your head.

------
michaelfeathers
Good design isn't optimization. The trick is to do it so often as katas that
you internalize it. Then you see the better way to do things and just do it.
No stage fright, just action.

------
chris_mahan
See <http://www.canonical.org/~kragen/tao-of-programming.html> pay close
attention to section 4.4

~~~
chris_mahan
oh, and to piss off many, see section 2.4.

------
kamakazizuru
word! If I think of all the projects I started and didnt finish becuase I
overhtought and overengineered and often just froze.

------
nixpulvis
I'm not sure I agree about this with respect to security, even though security
can be a huge time investment to account for.

~~~
daeken
As a security professional as well as developer, I agree with the OP. Simply
put, you're going to screw things up no matter what you do. Be smart about it,
plan for the worst, and seek outside feedback into your security processes;
you're never going to find all the edge cases, even if that's your day job.

------
iajrz
Ah, it's important to write the code for easy replacement, at least. Make it
easy to kill only chunks.

------
jrockway
This is a good idea if your time in the future is worth less than your time
today.

------
Aardwolf
Don't be scared... Just hack something together and have fun!

------
calebgilbert
Same school of thought: 'Write Code Like You Just Learned How to Program' -
<http://prog21.dadgum.com/87.html>

~~~
amboar
That article is simplistic. Sure, write code that you won't care about in the
future like you don't care about it, but if you take that approach with
anything requiring longterm reliability or maintenance then you're setting
yourself up for failure. Essentially: Think about it. Use techniques and
tricks where appropriate, but at least consciously make the decision to do a
less than stellar job and document your reasoning. A couple of lines of
comments justifying some weird and verbose approach might show to others that
it wasn't the lack of mental capacity to come up with another implementation.

~~~
calebgilbert
I believe the spirit the article was written in has value. Obviously one
should use common sense and still apply the best practices that they know of
at the time.

------
michaelochurch
The Bad Guys want you to feel insecure about your work, your position, your
relative standing, and everything else because their worst nightmare is that
software engineers and scientists and thinkers wake up and realize how much
leverage they would actually have if they were organized and capable of
looking out for their own interests. We'd reshape the entire business
landscape, and the power relationships between us and them would be inverted.

They prey on the insecurity of the smartest people. It makes us easy to take
advantage of, and compromises almost all of our leverage.

Every time you let them sit in your head and natter about how your work isn't
good enough because it doesn't isn't in accord with what they see as
"professional", you're letting them win. The problem with assholes is that
their imprints live on even years after you get away from them. It takes
conscious effort to get that lingering cognitive load out of your mind.

We need to step back and simplify: solve problems, and do it well. (This
includes documentation and testing, when appropriate.) Make stuff, make it
good, make what's good better. We need to get back to that, rather than
slugging it out over "agile" and TDD and nonsense. Zed Shaw got it right:
<http://programming-motherfucker.com/>

~~~
ojbyrne
Really? From my experience the "Bad Guys" don't give a shit about code quality
and will shower you with praise if you give them the crappiest code possible,
as long as you make the changes they want 5 minutes ago. This article is
really talking about the insecurity that other programmers inculcate, because
we're all very smart and all very competitive.

~~~
michaelochurch
The Bad Guys don't care about code quality, but they want programmers to be
insecure. They do, however, play divide-and-conquer games against programmers
and encourage our own cannibalism (e.g. long email flamewars about tabs vs.
spaces) as well as that rockstar/ninja bullshit.

~~~
andrewflnr
Wait, flamewars about spaces vs tabs are part of a conspiracy to keep
programmers insecure and frightened? You'd better explain that remark.

~~~
michaelochurch
Executives don't care about that specific flamewar (or even know that it
exists) but they _like_ creating environments where we slug each other over
minor, superficial differences in coding style because (a) it makes us look
stupid and petty, and (b) it tires us out and makes us even easier to steal
from.

Programmers are often oblivious, when they find themselves in work
environments that are designed to play divide-and-conquer games against them,
to what is going on. Executives often enable/encourage the worst traits of
programmers in order to weaken the group.

~~~
throwaway9848
Please seek out a therapist to talk to. You can't be happy with the level of
anger and resentment that you seem to have right now. At first I thought you
were an attention seeking jerk, but after reading your comment history, I
think you have gotten yourself into a bad place in life. Please consider it.

~~~
reaclmbs
Shut up, jerk.

------
glockular
I can't scroll that website by pressing the space key. The article is not
worth reaching for pgdn.

