
Too scared to write a line of code - benhowdle89
https://medium.com/i-m-h-o/eef96ea6f4cb
======
ilikebeets
I appreciate the thought behind this post and I wish this mantra could be
applied in every situation but I don't think we should all now "Just code to
get it out there". It is sound advice for developing the login screen
functionality on your website, but when it comes to larger backend systems, a
flawed or unoptimised initial design can't just be optimised when it is
discovered it isn't working as required. The cost correcting a flawed design,
post delivery, could cripple a business. Even in the case where the product is
functioning as required, if OOP principles were not applied in initial design,
enhancements to that product would most likely be much more difficult to
implement. So, as with most things in life, consider the consequences before
taking action.

------
thejacenxpress
The situation depends also on the team. I've been on teams with sloppy
programmers and efficient programmers. What I've learned personally is that
efficient programmers who plan things out and focus on best practice tend to
keep their code very DRY and understandable for others to catch onto. The
sloppy programmers end up having to race to the deadline in order to refactor
and sometimes redo their code because the end result was close but not correct
enough for passing to a client. While I like the idea of saying "f-it" let me
program I love thinking about efficient problem solving, it actually makes me
continue to think and IMHO makes me a better programmer.

------
amcrouch
I have worked on projects which are developed against stupid deadlines where
getting the code out is all that matters. These projects are always doomed to
maintenance overheads and cost.

I agree with the comments below that state code the simplest solution to make
your tests pass but learn the best approach to tackle given problems so they
are second nature.

My experience has shown me that learning various principles and pattens
results in smaller code bases that make maintenance and refactoring easy. In
turn you are able to deliver quicker.

That being said, its not always so easy to achieve with established code
bases.

------
mceachen
<http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast> is wisdom that all
software engineers should adopt and internalize.

------
LordBritishSD
I agree with the basic idea behind this post. But most of the worrying over
architecture and paradigms should be done at the preliminary design stage,
which should happen before you even think about coding.

It doesn't have to be a polished, detailed, or even good design, but it does
need to be something that you can at LEAST loosely stick to initially and have
faith in. If the design is flawed enough that coding progress is halted, stop
coding and revisit your design.

------
garvin
I think this principle is best applied in personal projects where you are not
even sure if your idea will catch on. But for client projects with buckets and
deadlines this is a terrible idea. In my experience clients only decide what
they want after they see what you have done based on what you asked for. At
this point if you are rewriting entire modules then you did not design and
plan properly.

------
rabidguppy
How did we get to the point that code became writ, too holy to change?

Throw some paint on the canvas. Make it _do_ something, good, bad, or ugly.
Then, pay attention to what works under the covers. What's hard to change,
what's risky, what your team loves to work with.

But, remember and _apply_ those things -- they are some of the best whetstones
for a developer's skill.

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

~~~
shortstuffsushi
Boy, if you take this a bit too seriously, you're going to end up putting
yourself out of a job.

I could write this new product... but the market is already saturated with
products that kind of already do this... they probably don't need mine.

The exception to that opinion is social networks. If you think you need to
build a new social network, stop yourself and erase any traces of that thought
from your mind.

------
spare20
I don't know about other companies, but we very rarely get the budget to go
back and optimise code which has been tested and released. We are expected to
meet the task's requirements under time pressure and if there are performance
issues down the line, red flags are raised - often with the blame resting on
the offending developer.

------
MichaelAza
When I develop, I don't think about that stuff not because I ignore it but
because it's ingrained. I don't think "Should this be a factory? A decorator?"
I just tend to notice opportunities to use these and other patterns. The
reasons you shouldn't think about it is because it's an instinct, not because
you're ignoring it.

------
tedyoung
This is why I love TDD: the only code I need to think about are the tests that
implement my expectations. Writing the code itself is easy, I just have to
write the dumbest thing that will make the tests pass.

Of course, this all assumes you've got the right architecture for the job.

~~~
gbog
You're to handle data structures? If you do it wrong, if each bookstore
address is duplicated beside the book's entry, tests will pass but you will
have migration nightmare very soon.

What you are forgetting here is the essential refactoring step in the loop.

------
pschastain
"Make it work, make it work right, make it work fast" or "Premature
optimization is the root of all evil"

This is where it starts for me - <http://www.faqs.org/docs/artu/ch01s06.html>

~~~
x3ro
[http://f.cl.ly/items/232p1q3t0r1J2Z1l3K1s/Image%202013.05.25...](http://f.cl.ly/items/232p1q3t0r1J2Z1l3K1s/Image%202013.05.25%202%3A05%3A38%20PM.png)
q.e.d.

------
greyfade
I just consider what code would be correct. Does it do the right thing? Is it
concise and clear? Is it stable, given all expected inputs?

I worry about optimization and all of the other details later.

~~~
rhizome
"Concise and clear" is an optimization itself.

~~~
gbog
No. Concise means dry, which requires a lot of refactoring on the fresh meat,
and it is not optional. Clear means readable, which is necessary too, lest
your hope for your code is to never be read again. I mean used.

------
smanuel
Whenever I feel this way, I just open <http://programming-motherfucker.com>

And I just start writing code.

------
VikingCoder
Step 1) Do the dumbest possible thing that will solve your current problem.
Try to explain it clearly so that other people will understand what you did
and why, but don't spend effort on being clever.

Step 2) Assess whether this is good enough, if so, move on to the next
problem. If not, think hard and do something smarter.

~~~
shortstuffsushi
Maybe not dumbest, but do what comes to mind. Solve the problem. Then
determine if you've done it right.

