Controversial programming opinions

One of the very first ideas we had for this blog was to convert some of the wonderful gems of the early era of our site, the undisciplined period, to blog posts. Questions that were once enthusiastically received by the community, but no longer fit Programmer’s scope.
The first deleted question I’ve chosen is Jon Skeet’s “What’s your most controversial programming opinion?” question (available only to 10K+ users, sorry), a +391 scored question that was originally asked on Stack Overflow on January 2, 2009. What follows are twenty of the highest voted answers, in random order…

1. Programmers who don’t code in their spare time for fun will never become as good as those that do.

   I think even the smartest and most talented people will never become truly good programmers unless they treat it as more than a job. Meaning that they do little projects on the side, or just mess with lots of different languages and ideas in their spare time.by rustyshelf
   

2. Unit testing won’t help you write good code.

   The only reason to have Unit tests is to make sure that code that already works doesn’t break. Writing tests first, or writing code to the tests is ridiculous. If you write to the tests before the code, you won’t even know what the edge cases are. You could have code that passes the tests but still fails in unforeseen circumstances. And furthermore, good developers will keep cohesion low, which will make the addition of new code unlikely to cause problems with existing stuff.
   by Chad Okere

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

   Too many people jumping on too many bandwagons and trying to force methods, patterns, frameworks, etc. onto things that don’t warrant them. Just because something is new, or because someone respected has an opinion, doesn’t mean it fits all.
   by Steven Robbins
    

4. Most comments in code are in fact a pernicious form of code duplication.

     We spend most of our time maintaining code written by others (or ourselves) and poor, incorrect, outdated, misleading comments must be near the top of the list of most annoying artifacts in code. I think eventually many people just blank them out, especially those flowerbox monstrosities. Much better to concentrate on making the code readable, refactoring as necessary, and minimising idioms and quirkiness. On the other hand, many courses teach that comments are very nearly more important than the code itself, leading to the this next line adds one to invoiceTotal style of commenting.
   by Ed Guiness

5. “Googling it” is okay!

     Yes, I know it offends some people out there that their years of intense memorization and/or glorious stacks of programming books are starting to fall by the wayside to a resource that anyone can access within seconds, but you shouldn’t hold that against people that use it. Too often I hear googling answers to problems the result of criticism, and it really is without sense. First of all, it must be conceded that everyone needs materials to reference. You don’t know everything and you will need to look things up. Conceding that, does it really matter where you got the information? Does it matter if you looked it up in a book, looked it up on Google, or heard it from a talking frog that you hallucinated? No. A right answer is a right answer. What is important is that you understand the material, use it as the means to an end of a successful programming solution, and the client/your employer is happy with the results.
   by PhoenixRedeemer

6. Not all programmers are created equal.

     Quite often managers think that DeveloperA == DeveloperB simply because they have same level of experience and so on. In actual fact, the performance of one developer can be 10x or even 100x that of another. It’s politically risky to talk about it, but sometimes I feel like pointing out that, even though several team members may appear to be of equal skill, it’s not always the case. I have even seen cases where lead developers were ‘beyond hope’ and junior devs did all the actual work – I made sure they got the credit, though.
   by Dmitri Nesteruk

7. I fail to understand why people think that Java is absolutely the best “first” programming language to be taught in universities.

     For one, I believe that first programming language should be such that it highlights the need to learn control flow and variables, not objects and syntax. For another, I believe that people who have not had experience in debugging memory leaks in C / C++ cannot fully appreciate what Java brings to the table. Also the natural progression should be from “how can I do this” to “how can I find the library which does that” and not the other way round.
   by Learning

8. If you only know one language, no matter how well you know it, you’re not a great programmer.

     There seems to be an attitude that says once you’re really good at C# or Java or whatever other language you started out learning then that’s all you need. I don’t believe it- every language I have ever learned has taught me something new about programming that I have been able to bring back into my work with all the others. I think that anyone who restricts themselves to one language will never be as good as they could be. It also indicates to me a certain lack of inquistiveness and willingness to experiment that doesn’t necessarily tally with the qualities I would expect to find in a really good programmer.
   by glenatron

9. It’s OK to write garbage code once in a while.

     Sometimes a quick and dirty piece of garbage code is all that is needed to fulfill a particular task. Patterns, ORMs, SRP, whatever… Throw up a console or web application, write some inline SQL (feels good), and blast out the requirement.
   by jfar

10. Print statements are a valid way to debug code.

      I believe it is perfectly fine to debug your code by littering it with System.out.println (or whatever print statement works for your language). Often, this can be quicker than debugging, and you can compare printed outputs against other runs of the app. Just make sure to remove the print statements when you go to production (or better, turn them into logging statements).
    by David

11. Your job is to put yourself out of work.

      When you’re writing software for your employer, any software that you create is to be written in such a way that it can be picked up by any developer and understood with a minimal amount of effort. It is well designed, clearly and consistently written, formatted cleanly, documented where it needs to be, builds daily as expected, checked into the repository, and appropriately versioned. If you get hit by a bus, laid off, fired, or walk off the job, your employer should be able to replace you on a moment’s notice, and the next guy could step into your role, pick up your code and be up and running within a week tops. If he or she can’t do that, then you’ve failed miserably. Interestingly, I’ve found that having that goal has made me more valuable to my employers. The more I strive to be disposable, the more valuable I become to them.
    by Mike Hofer

12. Getters and Setters are highly overused.

      I’ve seen millions of people claiming that public fields are evil, so they make them private and provide getters and setters for all of them. I believe this is almost identical to making the fields public, maybe a bit different if you’re using threads (but generally is not the case) or if your accessors have business/presentation logic (something ‘strange’ at least). I’m not in favor of public fields, but against making a getter/setter (or Property) for everyone of them, and then claiming that doing that is encapsulation or information hiding… ha!
    by Pablo Fernandez

13. SQL is code. Treat it as such.

      That is, just like your C#, Java, or other favorite object/procedure language, develop a formatting style that is readable and maintainable. I hate when I see sloppy free-formatted SQL code. If you scream when you see both styles of curly braces on a page, why or why don’t you scream when you see free formatted SQL or SQL that obscures or obfuscates the JOIN condition?
    by MustStayAnonymous

14. UML diagrams are highly overrated.

      Of course there are useful diagrams e.g. class diagram for the Composite Pattern, but many UML diagrams have absolutely no value.
    by Ludwig Wensauer

15. 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.
    by Craig P. Motlin

16. XML is highly overrated.

      I think too many jump onto the XML bandwagon before using their brains… XML for web stuff is great, as it’s designed for it. Otherwise I think some problem definition and design thoughts should preempt any decision to use it.
    by Over Rated

17. Software development is just a job.

      I enjoy software development a lot. I’ve written a blog for the last few years on the subject. I’ve spent enough time on here to have >5000 reputation points. And I work in a start-up doing typically 60 hour weeks for much less money than I could get as a contractor because the team is fantastic and the work is interesting. But in the grand scheme of things, it is just a job. It ranks in importance below many things such as family, my girlfriend, friends, happiness etc., and below other things I’d rather be doing if I had an unlimited supply of cash such as riding motorbikes, sailing yachts, or snowboarding. I think sometimes a lot of developers forget that developing is just something that allows us to have the more important things in life (and to have them by doing something we enjoy) rather than being the end goal in itself.
    by Greg Beech

18. If you’re a developer, you should be able to write code.

      I did quite a bit of interviewing last year, and for my part of the interview I was supposed to test the way people thought, and how they implemented simple-to-moderate algorithms on a white board. I’d initially started out with questions like:

    Given that Pi can be estimated using the function 4 * (1 – 1/3 + 1/5 – 1/7 + …) with more terms giving greater accuracy, write a function that calculates Pi to an accuracy of 5 decimal places.

      It’s a problem that should make you think, but shouldn’t be out of reach to a seasoned developer (it can be answered in about 10 lines of C#). However, many of our (supposedly pre-screened by the agency) candidates couldn’t even begin to answer it, or even explain how they might go about answering it. So after a while I started asking simpler questions like:

    Given the area of a circle is given by Pi times the radius squared, write a function to calculate the area of a circle.

      Amazingly, more than half the candidates couldn’t write this function in any language (I can read most popular languages so I let them use any language of their choice, including pseudo-code). We had “C# developers” who could not write this function in C#. I was surprised by this. I had always thought that developers should be able to write code. It seems that, nowadays, this is a controversial opinion. Certainly it is amongst interview candidates!
    by Greg Beech

19. Design patterns are hurting good design more than they’re helping it.

      Software design, especially good software design is far too varied to be meaningfully captured in patterns, especially in the small number of patterns people can actually remember – and they’re far too abstract for people to really remember more than a handful. So they’re not helping much. And on the other hand, far too many people become enamoured with the concept and try to apply patterns everywhere – usually, in the resulting code you can’t find the actual design between all the (completely meaningless) Singletons and Abstract Factories.
    by Michael Borgwardt

20. Less code is better than more!

      If the users say “that’s it?”, and your work remains invisible, it’s done right. Glory can be found elsewhere.
    by Jas Panesar
    
    
    SOURCE: http://programmers.blogoverflow.com/2012/08/20-controversial-programming-opinions/
    
    
    -----------------------------------------
    
    

    Hopefully More Controversial Programming Opinions

    I read 20 Controversial Programming Opinions, and I found myself nodding "yes, yes get to the good stuff." And then, after "less code is better than more," it was over. It was like reading a list of controversial health tips that included "eat your veggies" and "don't be sedentary." In an effort to restore a bit of spark to the once revolutionary software development world, I present some opinions that are hopefully more legitimately controversial.
    
    Computer science should only be offered as a minor. You can major in biology, minor in computer science. Major in art, minor in computer science. But you can't get a degree in CS.
    
    It's a mistake to introduce new programmers to OOP before they understand the basics of breaking down problems and turning the solutions into code.
    
    Complex compiler optimizations are almost never worth it, even if they result in faster code. They can disproportionately slow down the compiler. They're risky, in that a mishandled edge case in the optimizer may result in obscure, latent bugs in the application. They make reasoning about performance much more difficult.
    
    You shouldn't be allowed to write a library for use by other people until you have ten years of programming under your belt. If you think you know better and ignore this rule, then one day you will come to realize the mental suffering that you have inflicted upon others, and you will have to live with that knowledge for the rest of your life.
    
    Superficially ugly code is irrelevant. Pretty formatting--or lack thereof--has no bearing on whether the code works and is reliable, and that kind of mechanical fiddling is better left to an automated tool.
    
    Purely functional programming doesn't work, but if you mix in a small amount of imperative code then it does.
    
    A software engineering mindset can prevent you from making great things.
    
    
    SOURCE: http://prog21.dadgum.com/149.html
    
    
    ----------------------------------------
    
    

    12 (Really) Controversial Programming Opinions

    A few days ago, Yannis Rizos posted 20 controversial programming opinions on the Programmers Community Blog. Judging by the comments on the blog, and on reddit and Hacker News, none of these opinions are considered all that controversial by the programming community at large. The problem stems from the fact that the opinions posted were selected from among the top-voted answers to Jon Skeet’s question What’s your most controversial programming opinion?, originally asked on Stack Overflow on January 2, 2009. People seem to have voted for answers they strongly agreed with, making those top answers some of the least controversial opinions you could gather.
    
    I decided to take a different approach. What follows are some of the opinions that I found near the middle or at the end of the list. I tried to pick only answers where the author made an attempt at supporting their opinion, but as you can see some of these opinions were downvoted more heavily than they were upvoted by the Stack Overflow community. (I'll add that my own "controversial" opinion is that Jon's question is perhaps the best argument we have that these types of opinion polls simply do not work on Stack Overflow.)
    
    1. Two lines of code is too many. (+20/-32) by Jay Bazuzi
    
    If a method has a second line of code, it is a code smell. Refactor.
    
    2. If it's not native, it's not really programming (+5/-15) by Mason Wheeler
    
    By definition, a program is an entity that is run by the computer. It talks directly to the CPU and the OS. Code that does not talk directly to the CPU and the OS, but is instead run by some other program that does talk directly to the CPU and the OS, is not a program; it's a script. Read more
    
    3. The "While" construct should be removed from all programming languages. (+6/-14) by seanyboy
    
    You can easily replicate While using "Repeat" and a boolean flag, and I just don't believe that it's useful to have the two structures. In fact, I think that having both "Repeat...Until" and "While..EndWhile" in a language confuses new programmers. Read more
    
    4. Copy/Pasting is not an antipattern, it fact it helps with not making more bugs (+4/-5) by serg
    
    My rule of thumb - typing only something that cannot be copy/pasted. If creating similar method, class, or file - copy existing one and change what's needed. (I am not talking about duplicating a code that should have been put into a single method). Read more
    
    5. Developing on .NET is not programming. Its just stitching together other people's code. (+7/-5) by Gerard
    
    Having come from a coding background where you were required to know the hardware, and where this is still a vital requirements in my industry, I view high level languages as simply assembling someone else's work. Nothing essentially wrong with this, but is it 'programming'? Read more
    
    6. The use of try/catch exception handling is worse than the use of simple return codes and associated common messaging structures to ferry useful error messages. (+11/-3) by Einstein
    
    Littering code with try/catch blocks is not a solution.
    
    Just passing exceptions up the stack hoping whats above you will do the right thing or generate an informative error is not a solution. Read more
    
    7. Test Constantly (+15/-7) by PJ Davis
    
    You have to write tests, and you have to write them FIRST. Writing tests changes the way you write your code. It makes you think about what you want it to actually do before you just jump in and write something that does everything except what you want it to do. Read more
    
    8. Object Oriented Programming is absolutely the worst thing that's ever happened to the field of software engineering. (+34/-14) by Breton
    
    The primary problem with OOP is the total lack of a rigorous definition that everyone can agree on. This easily leads to implementations that have logical holes in them, or language like Java that adhere to this bizarre religious dogma about what OOP means, while forcing the programmer into doing all these contortions and "design patterns" just to work around the limitations of a particular OOP system. Read more
    
    9. C (or C++) should be the first programming language (+24/-5) by hansen j
    
    The first language should NOT be the easy one, it should be one that sets up the student's mind and prepare it for serious computer science.
    C is perfect for that, it forces students to think about memory and all the low level stuff, and at the same time they can learn how to structure their code (it has functions!)
    
    C++ has the added advantage that it really sucks :) thus the students will understand why people had to come up with Java and C#.
    
    10. Classes should fit on the screen. (+22/-7) by Jay Bazuzi
    
    If you have to use the scroll bar to see all of your class, your class is too big.
    
    Code folding and miniature fonts are cheating.
    
    11. Making invisible characters syntactically significant in python was a bad idea (+43/-5) by Paul Wicks
    
    It's distracting, causes lots of subtle bugs for novices and, in my opinion, wasn't really needed. About the only code I've ever seen that didn't voluntarily follow some sort of decent formatting guide was from first-year CS students. And even if code doesn't follow "nice" standards, there are plenty of tools out there to coerce it into a more pleasing shape.
    
    12. Singletons are not evil (+42/-7) by Steve
    
    There is a place for singletons in the real world, and methods to get around them (i.e. monostate pattern) are simply singletons in disguise. For instance, a Logger is a perfect candidate for a singleton. Additionally, so is a message pump. My current app uses distributed computing, and different objects need to be able to send appropriate messages. There should only be one message pump, and everyone should be able to access it. The alternative is passing an object to my message pump everywhere it might be needed and hoping that a new developer doesn't new one up without thinking and wonder why his messages are going nowhere. The uniqueness of the singleton is the most important part, not its availability. The singleton has its place in the world.
    
    SOURCE: http://billthelizard.com/2012/09/12-really-controversial-programming.html