
Controversial programming opinions - Sammyadems
http://programmers.blogoverflow.com/2012/08/20-controversial-programming-opinions/
======
ajdecon
Most of these have wide acceptance among the HN/Startup crowd; I might expect
to see more disagreement if the list were exposed to corporate programming
environments, or especially to their managers. I have a couple of quibbles,
though:

\- 1: I'd modify "Programmers who don’t code in their spare time for fun will
never become as good as those that do", to be "Programmers who don't code in
their spare time for fun will never be as good as they would if they did". I
definitely believe coding for fun helps your skills, but I've seen too many
"just-a-job" programmers code circles around others on the same teams who had
side projects and kept up with the trendy languages. It's not a clear
differentiator, just a data point.

\- 2: Unit tests don't help you code in the same way that a safety net doesn't
help you walk a tightrope: this is technically true, but not a helpful
statement in reality.

\- 10: Print statements are "valid" in that they often work, but when a
debugger is available it's almost always the right way to go.

~~~
awolf
>Print statements are "valid" in that they often work, but when a debugger is
available it's almost always the right way to go.

I don't know about this one. I think that having to write print statements
makes you do actual thinking about your debugging strategy and therefore makes
you understand the flow of your code more. A debugger is certainly useful, but
I was surprised the first time I had to go without one to find that I didn't
miss it that much and possibly was even more efficient.

~~~
KirinDave
Debuggers are great and superior to print statements when they're usable. Use
a debugger when you can. Sadly, it is increasingly the case that you cannot
use a debugger when you want to use one.

Print statement binary search is primitive, but it's survived as a tool
because it's almost universally applicable.

~~~
btilly
Debuggers are more efficient at locating and fixing specific bugs. However
when you debug with print statements you get the opportunity to review the
code and find bigger design problems that need to be fixed.

Furthermore, and more controversially, if you debug with debuggers, you will
be driven to use programming techniques that are friendly to your debugger.
But when you debug with print statements, you are free to use whatever
programming techniques are best for human comprehension.

Now before you raise your keyboard and rush to disagree, consider carefully
that the position I just described is agreed with by well-known programmers
such as Linus Torvalds and Larry Wall. There are equally well-known
programmers who disagree.

The true merits of the case are hard to determine. But if you think that one
side is trivially wrong, then you should view this as a learning opportunity.
Because you're certainly mistaken.

See
[http://lkml.indiana.edu/hypermail/linux/kernel/0009.0/1148.h...](http://lkml.indiana.edu/hypermail/linux/kernel/0009.0/1148.html)
and <http://www.perlmonks.org/?node_id=48495> for more background on this
topic.

------
rauljara
> The only “best practice” you should be using all the time is “Use Your
> Brain”.

This is true, in that very few best practices are universally applicable and
you should never stop thinking. The author is also totally right about people
jumping on bandwagons and being cargo cult members.

So I'm not really disagreeing with him, but just adding that a lot of best
practices actually aid your ability to reason through code. They can help to
push repetitive things off to the automatic portions of your brain. They can
help to make patterns in your code that are visible and familiar, so you can
spend less time thinking about how to implement (or read) some simple thing
and more time thinking about how the simple pieces fit together.

Which is not to say all "best practices" are great. But even the questionable
ones usually have some interesting problem they are trying to solve that
explains why they sprung into being. If a "best practice" is popular enough
that it gets called a best practice, it's probably worth paying attention to
and thinking about even if you ultimately decide not to use it.

~~~
jfoutz
Yeah, throwing out experience is super risky.

If you face the exact same problem 10 times, and you think it through from the
beginning every single time, you're going to get 10 different answers. You
just can't remember all the little details every single time.

~~~
btipling
I think experience can actually become a liability. Things have changed and
you don't have to write assembly code to optimize your program. Compilers will
probably do a better job than you. And if you have a lot of experience writing
JavaScript for IE6, you may actually be wasting time optimizing in ways no
longer relevant.

~~~
keithnoizu
True, but this is why you tend to migrate towards an architect/lead role later
in your career where the general insights about systems and design are still
applicable with out needing to overly focus on present day implementation
minutia .

------
TheBoff
It seems to me that most of these aren't controversial at all.

I disagree with one of the points supporting "Unit testing won’t help you
write good code.", though, where he implies that writing the code reveals the
edge cases. Surely the edge cases are something you should have carefully
considered before starting to code? I've found that crystallising the edge
cases as a test before writing the function can be really helpful.

~~~
Chris_Newton
_Surely the edge cases are something you should have carefully considered
before starting to code?_

There are two kinds of edge cases: the essential ones that derive from your
requirements and problem domain, and the accidental ones that result from
implementation details like your choice of programming languages or which
libraries you use or your software architecture.

You can try to identify the essential ones and write tests for them in
advance, but for the accidental ones there’s only so much you can do with a
black box approach to testing.

------
S_A_P
I found the "programmers should be able to write code" off putting, but not
because I dont think that programmers should be able to write code. Too many
hiring development managers expect that someone can just walk into a room and
without hesitation expose the way they think to them. I also think that most
of these people fall victim to their own hubris. So what if a problem can be
solved with "3 lines of code". I guarantee that many problems are not
immediately solved in 3 lines of code and its only after iterating through the
problem domain that an elegant solution can be found.

Being put on the spot is a different kind of stress that can take many people
out of their game. Some managers may argue that they want to weed out people
who cannot act under pressure but once a "team" is formed, the pressure of
having to act quickly doesn't involve some of the socialization that is
required in a job interview.

If you really want to know if someone knows how to code, have them write
something for you. If you are afraid that they would cheat, look at their git
hub account. Ask to see a portfolio if possible. If none of that is possible,
make the hiring process take long enough that a level of rapport can be
developed between the team and the candidate.

~~~
danielweber
The point of Fizzbuzz is that some people simply cannot write any code at all.

It's not necessarily looking for the best possible answer. In fact, I
completely expect (as both interviewee and interviewer) that the candidate
will write a first pass on paper, we will look at it, figure out it's big-O,
and then go on to improve it to be better.

~~~
S_A_P
That is a fair point, too. I have done some interviews where I questioned how
the person got far enough into the process that I was involved. However I have
also seen the flip side of the coin where a developer/manager interviewed and
subsequently rejected someone who was likely a great candidate over an on the
spot brain quiz, and one that the candidate would likely NEVER see while
performing his/her job duties.

------
borplk
#17 is absolutely spot on.

I think developers are putting themselves at a severe disadvantage and are
being taken advantage of because of this whole 'hacker culture' or 'startup
life' ideas.

We are making it the norm, and raising everyone's expectations of us which end
up hurting us in the long run.

Stop for a second, and consider other professions and industries. Do you see
lawyers or financial analysts play with side-projects in the weekend, and
running all-nighters and hackathons? Or working on open-source-like-
equivalents of their professions?

Sure they are different industries, but there are similar things they could do
if they really wanted to, but they don't.

When we talk about 'hacking for fun' etc... we are sending a message to other
people which changes their attitude to "hey i only pay you this much because
you'd be doing similar stuff in your spare time anyways..."

People value your time based on things like this. Lawyers play this game very
well, they pretend like they don't have a single extra second to spare, and
hey they don't talk about law being fun either, and hence they can charge
$200/hour fees and others will happily pay for it.

I think we need to be smarter and adjust our attitude to account for the
economic goals and political games of the rest of the society.

~~~
DougWebb
Lawyers and financial analysts don't play with side-projects, but many of them
do pro-bono work for friends and charities, and I think that's their
equivalent of this idea. Engineers and craftsmen often do side-projects for
fun... engineers create fighting robots, and craftsmen create furniture and
art for their own use. That's pretty much exactly the same as programmers
doing side projects and participating in hackathons.

~~~
B-Con
Except that a lawyer or financial analyst won't be interviewed based on the
pro-bono work they've done for a friend.

Interviewer: "So, do you do pro-bono work?"

Interviewee: "Yeah, I've done some for some friends."

Interviewer: "Excellent, give us copies of all of it so we can determine how
good of a lawyer you are."

That doesn't happen.

------
brosephius
Sorry, I still can't agree with #1. It assumes that all workplace programming
is gluing things together, fixing/maintaining legacy crap, or writing generic
CRUD apps, which is untrue. I know some great programmers who never code in
their spare time, and some that do that are, quite frankly, very uninteresting
people to be around due to their lack of other hobbies.

I know the current trend in startups is all about "show me your github", and I
admit that it has some value as a filter, but I feel like I'm seeing people
writing fairly uninteresting code snippets and blogs just to put it on their
resume, in the same way that high schoolers join a bunch of student groups to
beef up college applications. There are plenty of programming jobs that
require writing complex code and having deep domain knowledge, and to discard
those candidates because they can't show you their code and have other hobbies
outside of work is just not smart.

~~~
danielweber
I think "show me your github" might be the most toxic practice for the well-
being of software developers' lives that is popular on HN.

As I said elsewhere, I really like programming and will often do it in my
spare time because it's fun. But needing to maintain some public repo or an
open-source project in order to get a job makes it no longer fun.

~~~
nuclear_eclipse
> _needing to maintain some public repo or an open-source project in order to
> get a job makes it no longer fun._

I completely agree, and I already have an above average amount of open source
code available on Github. Some startups have found my projects and mentioned
them in interviews, which was great, but I've never been directly asked for my
code before an interview, and I like it that way. Writing code for the purpose
of showing to potential employers would ruin the magic.

------
talmand
Topic 4: So comments are a problem because people do not update them? I
believe the blame is misdirected there. I agree that one should make code very
readable but comments can be very useful. Just because someone uses the tool
incorrectly doesn't make it a useless tool.

Topic 18: His questions are not about writing code, they are about writing
algorithms. The kind of code I write on a day-to-day basis does not require
working with math equations of this type. I could eventually do it but I would
probably have to research and test before I would be happy with it. Most
definitely not something I could do on the spot during an interview, but I
guess that means I can't write code.

I don't think I have much of a problem with the rest of them and agree with
most of them.

~~~
DougBTX
> His questions are not about writing code, they are about writing algorithms.

What's the distinction between those? He isn't asking the candidates to invent
algorithms, just to implement simple ones. The answer to the second question
is "return Pi * radius * radius", isn't that just writing code?

~~~
dllthomas
The first one (find pi to 5 decimal places from the sequence) is asking
candidates to remember or invent algorithms - in fact, I'm not immediately
sure how to generate the error bound there.

~~~
JasonFruit
No, he _provided_ the algorithm. What he's asking for is an implementation of
it, which seems reasonable to me.

~~~
dllthomas
No, he provided the sequence. There remains the question of how you make sure
that calculating n terms of it puts you within 10^-5 of the true value of pi.
If he provided that as well, then yes, it should be a trivial exercise. If
not, it's nontrivial (although not, I think, hugely difficult) mathematics
followed by trivial programming.

~~~
ward
The sequence is enough, you just keep going till your fractions (multiplied by
4) do not change 10^-5 any more. You do not need the actual value of pi.

As soon as 4 * 1/(2n+1) < 0.00001, then you can stop looping. The sequence is
the algorithm.

~~~
dllthomas
This is not true for the general sequence, and I would be hesitant to give
that answer without an understanding that it is true for the given sequence.
It is, and I sketched the proof in reply to your sibling comment, but it takes
more figuring out than I could do before coffee.

------
shanelja
I agree that developers should be able to code, I just got off the phone with
a "web developer" who specializes in adding Joomla to a website, installing a
template and sticking in some text.

For all intents and purposes this man is a glorified text editor.

He doesn't know the smallest bit of PHP (the stack with which he claims to
work), CSS or HTMl - in which world is he a web developer?

~~~
fghh45sdfhr3
Developers damn better be able to write code. But writing code and writing
code during a job interview are two very different things!

If you only hire people who can write code during job interviews, you might
get a great guy who was completely relax during the interview. Or you might
get someone who's OK at writing code, and miss out on someone 100 times more
productive only because they were nervous during the interview.

Nervousness is poison for thinking, fear is the mind killer, etc. I've always
been most nervous at interviews for jobs I really, really wanted. Not because
I needed a paycheck, but because I was passionate about the job.

Advice for job candidates: Drill coding under pressure.

~~~
prodigal_erik
If I can't write code during an interview, neither can I coordinate a staged
release of a fix I just wrote during a 3 AM outage. That shouldn't have
happened but sometimes it does; pressure isn't always artificial.

~~~
fghh45sdfhr3
Indeed. But if I find out that a company never does 3AM fixes, or death
marches, then I know their management is _damn_ great. And I really want to
work for them!

~~~
quantumstate
It depends what your company does. Where I work we write CAD/CAM software
which gets released roughly twice a year. It is pretty inconceivable that a
3AM fix would be necessary. Even 0 day security flaws in the software (pretty
unlikely since there isn't any need for network connectivity) really shouldn't
be fixed at 3 am, they can wait 12 hours and be handled under less stress and
tiredness.

~~~
n00b101
I'm sorry, but in which line of work is coding and pushing emergency bug fixes
at 3AM an acceptable occurrence?

------
cgdangelo
These don't seem very controversial. I'd say that several of them are actually
rather _popular_ opinions. 1, 5, 8, 11, 16, 20 in particular.

~~~
rhizome31
#2 and #19 are controversial.

#2 contradicts itself. It says that unit tests will _make sure that code that
already works doesn’t break_ but at the same time it won't help writing good
code. Well as far as I'm concerned, code that breaks can't really qualify as
good code. _Writing tests first, or writing code to the tests is ridiculous._
Not sure what _writing code to the tests_ actually means, is that even correct
English (I'm not a native English speaker)? The main benefit of writing tests
first, is that tests do get written. It's too easy to say _we'll write tests
when we have time_. If you discipline yourself to write tests first, by the
time the code is written, the tests are written as well. Writing tests first
also saves a lot of manual testing time (eg. clicking over and over in a UI),
which is repetitive and stressful activity. Overall testing and TDD help a lot
to achieve #11.

#19 is an amusing caricature, but misleading. Design Patterns are not limited
to GoF patterns. They show up at different levels of abstractions and give
developers useful vocabulary to communicate about stuff they do anyway. #19
mentions 2 patterns that are not very useful in our daily lives, but they are
patterns like MVC, observer or iterator that we use all the time without even
realizing they are patterns. The point of patterns (design, coding or
architectural patterns) is not to memorize the GoF list but to learn to
identify, label and share recurring solutions that we can reuse in various
situations.

~~~
Chris_Newton
_Not sure what_ writing code to the tests _actually means, is that even
correct English (I'm not a native English speaker)?_

It’s idiomatic, and it usually has a negative connotation. An analogous
example is criticising a school for “teaching to the exam”, usually implying
that the school’s teaching is inappropriately prioritising getting the student
a good grade in their exam, at the the expense of giving the student a good
general education in the subject.

Here’s a contrived example of writing code to the tests, in the negative
sense. Given this test:

    
    
        def test_add():
            assert(add(1, 1) == 2)
    

we could write this obviously broken implementation of the add function, which
is nevertheless the simplest code that passes the test:

    
    
        def add(a, b):
            return 2

~~~
dripton
Obviously your test case is insufficient.

In Kent Beck's "Test Driven Development by Example", he starts just like this,
with an insufficient failing test. Then he writes a minimal function that
passes it. Then he adds another test, then improves the function until it
passes both. By the time he's done, he's got tests for all the edge cases he
could think of.

I think it's a great way to make sure you cover all the edge cases, for a
sufficiently complicated function. I don't have the patience to write all my
code that way, though.

~~~
Chris_Newton
_Obviously your test case is insufficient._

Yes, it is. The point is that even given many additional test cases of the
same type, they will _remain_ insufficient, unless of course you’re planning
to test the entire input domain, which I imagine is going to take you a while.

Clearly at some stage you have to replace satisfying isolated cases with some
form of generalised understanding. At that stage, you’re no longer coding to
the tests.

This is not to say that unit tests can’t be useful. On the contrary, I find
them a valuable tool for many programming jobs.

However, as I have observed before, the plural of “unit test” is not “proof”.
I do find it frustrating when I see overconfidence instilled in too many
developers just because they have a suite of unit tests available. Using TDD
can’t magically guarantee that a program actually satisfies all of its
requirements. Refactoring without thinking isn’t magically safe as long as the
code still passes the test suite. Writing code to the test is not a substitute
for understanding the problem you’re trying to solve and how your solution
works.

------
columbo
I agree with #18 wholeheartedly but I disagree with the examples because those
are more of math questions than programming questions. I have never needed to
write a program that dealt with circles/radius/area/pi so I'd probably fail
that test as I'd have to look up a few things that I have't thought about in
over twenty years.

I prefer to have about 15-20 index cards with problems that have open ended
solutions ("Build a RPG combat system using 4,6,8,10, 12 or 20 sided dice",
"Create a system to store Books and allow people to search by author/title or
genre")

~~~
ZoFreX
If you can't answer those questions in #18, and you can code, then it isn't
mathematical skills you lack - it's reading comprehension (a skill that seems
to be woefully underdeveloped amongst developers). I suspect you can actually
pass both of those without difficulty though.

~~~
mindslight
What's the easy answer to the first one? It seems that you need to
analytically prove a bound for the remaining terms, no?

~~~
zxoq
I would just write the code to compute it to arbitrary precision and then tell
the interviewer that I would test how many iterations are required and hard-
code it.

If they insist that it must be solved at runtime, I would check the size of
the computed term (1/(1+2x)) and repeat 'til it's less than 10E-6.

~~~
nemetroid
Besides the slowness of such a solution, that condition is not enough to
ensure the first five decimal places are correct.

~~~
danielweber
If you are told the formula to use, you use it. No, it's not the bestest way
ever of finding pi. It's to make sure the guy sitting across from you can
actually write code, which a scary number of people actually cannot do.

------
pbiggar
The problem with most of these opinions is that they are absolutes, and
therefore by definition many of them are wrong. They could mostly be improved
with the addition of "sometimes", "in most circumstances", "depending on the
goals of your project", etc. For example:

\- "Programmers who don’t code in their spare time for fun [frequently won't
be] as good as those that do.

\- "Unit testing [may not] help you write good code [in many situations I have
encountered]."

\- "[Possibly the most useful] “best practice” you should be using all the
time is “Use Your Brain” [though for some teams in some circumstances there
may be more useful best practices]."

\- "If you only know one language, no matter how well you know it, you’re
[almost certainly] not a great programmer."

\- "Readability is the most important aspect of your code, [depending on your
company's goals and method of achieving those goals at this point in time]"

Of course, these are [mostly] opinions, and adding all sorts of disclaimers is
[almost] never fun, but opinions stated as absolutes are [almost] always
wrong.

------
MojoJolo
I agree with #8. Learning a different programming language is not that hard.
Because I think most programming language are related with each other. They
have the same "structure". Just different in syntax. So if you only one
programming language I think, programming is not for you.

~~~
masterzora
While knowing one will certainly ease learning the others it's rather
misleading to say that Java, Haskell, Prolog, and Brainfuck all have the same
structure. Their differences are significantly beyond syntax.

------
127001brewer
I agree with the first point, "Programmers who don’t code in their spare time
for fun will never become as good as those that do."

However, out of curiosity, how many people actually work on side-projects?

Because, after ten years, I have only worked with a couple of people who
actively work on side-projects. And I know that some people treat programming
as "only a job" and they're done at 5:00 PM, which is fine. But is it really
uncommon that programmers work on side-projects?

[Shameless plug: I have a few small projects on GitHub
(<https://github.com/mattchoinski>) and I also work on freelance projects for
various clients.]

~~~
scott_s
I don't have time for side projects. My work consumes all of my productive
time. Granted, I am a researcher, but I think this should apply to others as
well.

~~~
michaelt
In work I'm concerned with writing code my colleagues can maintain. Often the
most sensible design decision is to use the technology stack my team mates and
I already know. If everyone else uses Linux to write Python web apps I'd need
a very good reason to write a Windows only GUI app in C#!

Five years from now, my employer's standard technology stack might be
obsolete. If I only gain skills at work, my skill set would be obsolete too.
This would harm my future career prospects.

Could an employer pay me enough that I'd give up my side projects, sabotaging
my future career prospects? Probably, but it would have to be a lot of money.

Of course, I also maintain a healthy work/life balance and have hobbies that
let me get away from the computer and meet other people. This is also
important.

~~~
scott_s
I realize that my intended meaning was weaker than my wording. I meant that
surely there _are_ others that this should apply to. That is, surely
researchers are not unique. But I don't mean that it should apply to everyone.

------
mariusz331
I really like this list. I think the only opinion I don't share is number 20-
"Less code is better than more". I've been coding in C++ for a while now and
approaching a problem without an object-oriented focus can yield substantially
less code, but it's not very readable nor flexible for quick changes later on.
Also, if performance is key, you may want to dig deep and that usually yields
a lot more lines.

I started using Ruby this summer and it was fun turning 10 lines of code into
1 or 2. But it was a big pain deciphering it weeks later =(

~~~
qu4z-2
I think the comment advocates simpler solutions, not vim-golf style "compress
as much as possible and use single-character variable names".

The idea is to remove as much accidental complexity as possible, to focus on
the essential. Signal-to-Noise Ratio, basically.

------
glenjamin
I reckon #15 is one of the ones that's very easy to forget, and easy to lose
track of between starting writing some code, and committing it. I
wholeheartedly agree that it's more important than correctness though!

Readability is the most important aspect of your code. Even more so than
correctness. If it’s readable, it’s easy to fix. It’s also easy to optimize,
easy to change, easy to understand. And hopefully other developers can learn
something from it too.

------
nnethercote
"UML diagrams are highly overrated."

"XML is highly overrated"

Whoa. Steady on there, tiger. My brain can only handle so much controversy in
one day.

------
dlikhten
The "less is more" argument -- less code = better can be better summarized as:

"I'm not smart enough to understand this really complicated code, so I decided
to write something smaller and simpler."

This is something a co-worker of mine said once.

~~~
MojoJolo
That's interesting. And might be considered as a paradox. If he isn't smart
enough, how can he write a simpler code?

Or maybe he's just humble that he's not smart enough.

~~~
se85
Yeah I really have to agree with you on this one.

There is a reason why programming chops are not usually measured in lines of
code.

In my opinion the "art" of programming is to keep things simple yet still
solve the complex problems.

I'd say the guy was being humble for sure, as it seems extremely unlikely he
would have the discipline to sit down and write something SIMPLE from scratch
if he really was a bad programmer.

I've never seen it.

------
stephen_g
I think most of these are spot on, but I disagree with number 12 (especially
if you're writing code in a library).

It's worth having getters and setters for variables that need to be publicly
accessible, even if there's no logic in them, because it gives you the option
to change how that data is stored in the future and not break _all_ the code
that uses it. You want to be able to change the implementation without
breaking all your clients' code!

~~~
stickfigure
I'm inclined to side with the author. In the 13+ years I've been writing Java,
there's only been a handful of cases where I switched a field to a more
complex implementation. And in all of those cases, the IDE would have
helpfully pointed out where I need to update client code. I can understand the
value of strong encapsulation when publishing library code, but for internal
code getters and setters are usually massive overkill.

Fortunately projectlombok takes away most of this pain, and pretty much every
modern language post-Java makes attributes/getters a non-issue.

------
autodidakto
How can the 20 most upvoted opinions be the 20 most controversial? If the
opinions were upvoted based on "I agree" (and this is what I assume), then
they would be among the least controversial to the stackexchange crowd. Maybe
the middle opinions would be better.

------
pmelendez
Wow.. I always felt alone and guilty for thinking in this way. It's good to
know that I am not alone in the world.

I wonder if we can classify programmers depending on whether they are agreed
with this or not. Something like a PQ (Programming Quotient)

------
dsrguru
"11. Your job is to put yourself out of work."

I couldn't have said that better myself.

~~~
dumb123
11\. "Your job is to put yourself out of work"

... by selling your company and pocketing enough to retire indefinitely.

What you do after that point you may still call "work" but you will be doing
it for the fun or satisfaction of it, not necessarily a paycheck.

------
vq
Are these opinions really that controversial? My favourite, "Loops considered
harmful", aren't even on that list and I consider it more controversial than
most of them.

------
znmeb
My most contoversial programming opinion ... there are too fucking many
programming languages already. Proposing a new one should be grounds for
immediate dismissal.

~~~
qu4z-2
We're gonna keep doing it 'til we get it right ;)

\-- an amateur language designer

------
MarkMc
I'm sure I'm not the only person who simply HAD to work out the algorithm in
point 18 to prove my worth as a developer.

------
n00b101
I would like to meet the person who thinks this is controversial. And fire
him.

------
jebblue
I found myself agreeing with most of those.

------
mugsie
controversial, but just a lot of common sense...

------
chris_wot
Design Patterns rock.

