- The original address: programmers.blogoverflow.com/2012/08/20-…
- Giuseppe Picciano
- Translator: Qin Yi
One of the reasons for creating this blogoverFlow was in the early days of StackOverflow, when websites were less restrictive and there were gems of beauty that were censored but still worth documenting. Even if they are no longer suitable for programmers, there is no denying that they were once popular in the community.
The first question I picked that was removed was Jon Skeet’s “What do you think are the most controversial ideas about programming?” (Only 10K users have seen this question, sorry for that), 391+ responses since it was asked on February 2, 2009. The top 20, in no order, are listed below.
1. A programmer who does not program in his spare time will never be as good as one who programs in his spare time
I think even the smartest and most talented programmer will never be a good programmer if he or she only programs as a job. Not only do they do programming as a job, but they do small projects in their spare time or tinker with different languages and ideas.
— rustyshelf.
Unit tests don’t help you write good code
The only reason unit tests exist is to make sure that already working code doesn’t break. Writing tests first or writing code for tests is ridiculous, and if you do, you don’t even know what boundary test cases are. You’ll still write code that passes tests but fails in unexpected scenarios. In addition, a good developer will keep code aggregation low, so that new code is less likely to cause old code problems.
— Chad Okere
3. The only “best practice” that needs to be used at all times is “Use your brain”
Too many people jump on the bandwagon and force methods, patterns, frameworks, etc. where they don’t fit. It may be new, or it may be the opinion of a few pundits, but none of these reasons prove that it is for everyone. — Steven Robbins
4. In fact, most code comments are harmful code duplication
We spend most of our time maintaining code written by ourselves or others, and poor, incorrect, outdated, misunderstood comments top the list of most annoying human factors. I think most people end up deleting all of them, especially those flower box monsters. Instead, focus on readability, refactoring when necessary, and reducing cryptic idioms. On the other hand, many courses say that comments are almost more important than the code itself, resulting in an order-line-style code comment on the top line of the code.
— Ed Guiness
5. “Google it” is OK!
Yes. I know this idea offends some people who have been thinking and/or proud of programming books for years that are beginning to degenerate into resources available to all within seconds, but it shouldn’t be against those who use search engines either. I’ve heard too many criticisms of Google’s answers to questions that don’t make sense. First of all, the reference material is all people need. You don’t know anything so you need to do some research. Given all this, does it really matter where you get your information? What does it matter if you get information from a book, from a Google search, or even from an imaginary frog? It doesn’t matter. The right answer is the right answer. The important thing is that you understand the material, apply it to a good solution, and be recognized by both the client and the employer.
— PhoenixRedeemer
6. Not all programmers produce the same
Project managers often assume that because developer A and Developer B have the same level of experience, they are equal. In fact, the difference between the two developers can be 10 times or even 100 times. It’s politically risky to talk about this, but sometimes I want to say that even though several members of a team seem to have similar skill levels, they may not be what they seem. I’ve seen tech leads “hopeless” and junior developers do all the real work — and I’m sure they share the credit.
7. I don’t understand why Java is considered the absolute “number one” language to learn in college courses
First, I believe that a first programming language should emphasize the need to learn flow controls and variables, not objects or syntax. Second, I believe that those who have not tried debugging C/C++ memory leaks will not understand the benefits of Java. The natural progression of learning should be from “how do I implement it” to “how do I find the library to implement it”, not the other way around.
— Dmitri Nesteruk
8. If you only know one language, no matter how well you know it, you are not a good programmer
This seems to suggest that a language where you are proficient in only one language like C# or Java or whatever language you start learning is sufficient. I don’t believe in the theory that each language can teach me new things that I can incorporate into my work. I think people who limit themselves to one language could have done better. It also showed me a lack of inquiry and experimentation — qualities I look for in a really good programmer.
— glenatron
9. It’s okay to write junk code once in a while
Sometimes all it takes is some fast, dirty junk code to accomplish a particular task. Building a console/application quickly using schemas, Object Relational Mapping (ORMs), SPR, etc., or writing some inline SQL code (which feels good) may be more than you expected.
— jfar
10. Output printing is a great way to debug code
I find using System.out.println (or output statements in any other language) to be a great way to debug code. It is usually faster than the break point, and you can also compare the output data from different runtimes. Just make sure to delete the print codes when you go live (or better yet, log them).
— David
11. You work to lose your job
If your software is written for employers, the code must be easy for other developers to pick up and understand. The code is well-designed to be logical and consistent, it’s well-formatted, it has all the documentation it needs, it gets pushed into the repository every day, it keeps good version management. If you get hit by a bus, get fired, fired, or quit your job, your employer can always replace you. The next person can quickly pick up your code and run it within a week. If he or she can’t do that, you’re a loser. Interestingly, I found that putting myself out of work made me more valuable to my employer. The more I try to be a throw-away product, the more valuable I become to my employer.
— Mike Hofer
Abuse Getters and Setters
I’ve seen thousands of people claim that public fields are evil, so they private all fields and provide getters and setters for them. I firmly believe that this is not much different from using public altogether, unless you use threads (which are not common) or your accessors have some business/underlying logic (at least somewhat “weird”) that might be slightly different. I don’t like public fields, but I also object to adding getter/setter (or Property) methods to all fields and then claiming that it encapsulates or hides information… Ha ha ha!
— Pablo Fernandez
13. Treat SQL like code
This means that C#, Java, or any other favorite object/procedure language needs to evolve into a readable and maintainable format specification. I hate to see free scribbled SQL code. If you’re ghosting Angle brackets with two different formats on the interface, why don’t you ghosting free-form, sloppy, convoluted combined-condition SQL code?
— MustStayAnonymous
14. Overestimate the UML
Of course, there are some useful diagrams, such as class diagrams for composite patterns, but many UML diagrams are absolutely worthless.
— Ludwig Wensauer
Code readability is of Paramount importance
Readability is even more important than correctness, and if the code is readable, it can be easily fixed. It’s also easy to optimize, change, and understand the code. Hopefully, other developers can learn from the code as well.
— Craig P. Motlin
XML is overrated
I think too many people jump into the XML bandwagon without thinking… XML works well on the Web because it was designed for the Web. So I think there are some definition issues and design ideas that should be prioritized before using it.
— Over Rated
Software development is just a job
I really enjoy software development and have been blogging about it for the past few years. I took my time and got over 5,000 likes. I work at a startup and typically work 60 hours. The money is less than my outsourcing job, but the team is great and the work is fun. But in the grand scheme of life, it’s just a job. It ranks lower than a lot of things like family, my girlfriend, friends, happiness, etc. If I have more money than I can spend, I have plenty of other things to do, such as biking, sailing, skiing. I think a lot of developers sometimes forget that programming allows us to own the bigger things in life (by having them in a way that we enjoy) rather than being our own end game.
— Greg Beech
18. Developers should be able to write code
I interviewed a lot of people last year, and one part of the process was to test the candidate’s way of thinking by writing a simple to medium algorithm on a whiteboard. I start by asking questions such as: Given 4 * (1-1/3 + 1/5-1/7 +…) It is possible to estimate the Pi value, please add code to make the Pi value more accurate to five decimal places. This is certainly a question to ponder, but it should not be beyond the control of experienced programmers (about 10 lines of C# code will get the answer). But many of our candidates (screened by headhunters) can’t answer or even explain how to find the answer. So after that I started asking them simpler questions such as: Given that the area of a circle is Pi times the radius squared, write a function to calculate the area of a circle. The results were amazing, with more than half of the interviewees unable to write the function in any language (I can read most popular languages, so I gave them the choice of language, including pseudocode). We have “C# developers” who will not implement this function in C#. This was a surprise to me. I always thought developers should be able to write code. Now that seems to be a controversial idea. This controversy certainly exists among the candidates in the interview.
— Greg Beech
19. Design patterns hurt good design more than they help it
Software design, especially good software design, varies widely, making it impossible to extract meaningful content from patterns. Especially the few patterns that we actually know — they’re so abstract that we actually remember very little, so they’re not really that helpful.
On the other hand, too many people are obsessed with concepts and want to apply patterns everywhere. You don’t usually find all the (completely meaningless) singletons and the actual design between abstract factories in your code.
— Greg Beech
20. Less code is better than more!
If the user says “That’s it? “And your work isn’t visible to him, which means you’re doing something right. Glory will find its way, but not here.
— Jas Panesar
The translator of essays
The translation dragged on for a month and was altered several times.
This post was published in 2012, and now in 2021, there are a lot of points that I don’t think are controversial, like it’s ok to write junk code once in a while (lol). Now I can’t find the discussion of the original problem, so when I read the article, I can only think by myself why I can’t write junk code occasionally, what’s the harm? Reduced code quality, resulting in unnecessary maintenance costs later…