Posts Tagged ‘best practice’

20 controversial programming opinions

06 May 2018

This is my response to the 20 controversial programming opinions stated in this Software Engineering Stack Exchange blog post.

  1. Programmers who don’t code in their spare time for fun will never become as good as those that do.
    I somewhat agree with this statement. Being interested in programming in your spare time by creating side projects and reading programming related material make you a better programmer. However, I don’t think one needs to devote their entire life to programming to become very capable. Even an hour or two a week working on a side project can make a difference.
  2. Unit testing won’t help you write good code.
    I disagree with this statement. Unit testing and test driven development (TDD) can help you write good code. With TDD you can write a test that fails and then write/alter code until it passes meaning you solved the problems. Edge cases can of course be discovered during development and a good programmer will revise/update tests if they encounter edge cases when creating their solution.
  3. The only “best practice” you should be using all the time is “Use Your Brain”.
    I agree with this statement. You don’t always have to apply a method, pattern, framework to every problem.
  4. Most comments in code are in fact a pernicious form of code duplication.
    I somewhat agree with this statement. I myself am guilty of writing some redundant comments. Actually I tend to over-comment quite a bit (which I still believe is better than under-commenting). Comments like this are obviously redundant but aren’t very common overall:
  5. “Googling it” is okay!
    I agree with this statement. Googling is always okay. Referring to references/documentation is efficient. Sitting down and struggling for an hour or recreating the wheel when you could have looked up a solution/idea/etc is just a waste of time.
  6. Not all programmers are created equal.
    I agree with this statement. There will always be a difference (minor or major) in the skill set of every programmer. Some will be more knowledgeable in some areas and others may be able to churn out code faster.
  7. I fail to understand why people think that Java is absolutely the best “first” programming language to be taught in universities.
    I agree with this statement. I think C is by far the best programming language to learn as your “first programming language”. Its very low level, bare bones and makes you take care of almost everything (memory management, complex data structures, etc). I had to code in purely C for my first programming class in University and it was a great start.
  8. If you only know one language, no matter how well you know it, you’re not a great programmer.
    I agree with this statement. A programming language is simply some predefined human-friendly syntax which is then compiled into machine code or parsed. A good programmer should know general programming concepts. They should in theory be able to pick up any language after a quick tutorial and become more advanced after learning language specific quirks.
  9. It’s OK to write garbage code once in a while.
    I somewhat agree with this statement. Sometimes to meet a deadline or address a time sensitive issue, you may have to write ‘garbage code’. This can always be refactored at a later date but keep in a mind its much more time consuming to refactor bad than to write good code initially. Thus, writing garbage code is rarely OK. 
  10. Print statements are a valid way to debug code.
    I agree with this statement. Although many don’t like it, a quick print statement for a very small bug may be more than sufficient. However, with more complex bugs, you’ll find a debugger is basically a necessity and print statements won’t cut it. I still don’t understand why some programmers have very strong opinions about using print statements to debug small bugs.
  11. Your job is to put yourself out of work.
    I agree with this statement. Writing code that 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 makes you great at your job. I also believe programmers that do this become very valuable over time.
  12. Getters and Setters are highly overused.
    I agree with this statement. Obviously this depends on the specific case but typically having a standard getter and setter for a private field means its more or less public.
  13. SQL is code. Treat it as such.
    I agree with this statement. A lot of people are careless when writing SQL statements making them inefficient, prone to security flaws or hard to understand. Treat SQL like code and design clean, clear and efficient statements.
  14. UML diagrams are highly overrated.
    I agree with this statement. I don’t believe UML diagrams are required for planning a well designed solution. They can be useful for documentation/showcasing a solution though.
  15. Readability is the most important aspect of your code.
    I agree with this statement. Readability often comes from the code itself. However, code style, variable names and comments can also contribute to the readability of your code. It would be fine to optimise some frequently used code at the cost of less readability if the changes are properly documented.
  16. XML is highly overrated.
    I somewhat agree with this statement. Depending on the scenario, using XML can be great.
  17. Software development is just a job.
    I disagree with this statement. For some people it may be. For others (like myself) its also very much a hobby. I wrote my first program and studied basic programming as a young kid. I wasn’t doing it because I was prepping for a job in 10 years, I was doing it because it was fun and interesting. I’m happy that I can do something I enjoy as a job rather than something menial.
  18. If you’re a developer, you should be able to write code.
    I agree with this statement. For obvious reasons.
  19. Design patterns are hurting good design more than they’re helping it.
    I agree with this statement.  I think trying to apply a design pattern in every scenario is problematic. Design patterns are useful and its good to be aware of them when designing solutions.
  20. Less code is better than more!
    I disagree with this statement. Sometimes less code can be better but lines of code (LOC) is a useless metric. The readability of the code is more important. I would take 1000 lines of readable, well designed code over 200 lines of garbage.


It looks like I agree with 17 of the 20 controversial programming opinions made.
As a graduate software engineer, I’m interested to know how my opinions will change in a couple of years when I’ve gained more real world experience.

No Comments

Posted in Programming