To put it another way... What is the most commonly held and frustrating misunderstanding about programming, you have encountered?
Which widespread and longstanding myths/misconceptions do you find hard for programmers to dispel/correct.
Please, explain why this is a myth.
That because you're a programmer, you know how to fix [person]'s virus ridden machine.
A common HR thing that drives me nuts when I'm job hunting: the implicit assumption that all coding skills are language-specific, that there is no software engineering expertise that transcends command sets. That ten years experience in Java and another five in Perl mean you'd be completely useless on a project that uses, say, C#.
"Yes, there's a learning curve. But I've made harder transitions than this. I'll make you a deal, pay me 80% for the first month and at the end of that time if I'm not ... oh, wait, we're not actually having this conversation, because your HR monkey simply deleted my application."
If you're not typing, you're not working.
I believe zombie blank stares and coffee walks are essential to programmers organising things in their heads.
that you can speed up a late project, simply by throwing more people at it.
That writing software is easy.
How else do you explain all these projects that run over time and over budget and people (politicians, the media etc.) are still surprised, and customers complain when you tell them that their "small website" (or whatever) will actually take 6 months to develop and cost several thousand dollars (pounds, Euros, [insert currency of choice])
With fuzzy and ever changing requirements I sometimes think that it's amazing that any software ever gets finished!
I know it's a bit more complicated than that ;)
The complexity of the app is directly proportional to the complexity of the UI. By this reasoning, you should be able to build Google or Twitter over a weekend.
All programmers are good at math. :-)
Any teenage kid who hacks with computers is equivalent (or superior) in skill to a veteran working programmer.
My 14 year old nephew is good with computers and I'm paying him $10/hr to mow my lawn. Why should I pay you six figures to write the next FaceBook?
That real-time means fast.
Stating "The packets need to be processed in real-time." is worthless and the evil twin...answering "How fast does X need to happen ?" with "Real-time" is possibly less than worthless...bordering on stupid rather than ignorant.
Real-time means that, simply put, that function Y will always take X amount of time and that any deviation indicates a serious error. The duration of X does not define "real-time" it could be six microseconds or six days. That you can determine function Y will take X time defines "real-time". Real-time systems are deterministic by this definition.
So knock it off..
Why don't you guys simply write it right the first time, rather than spending so much time typing in buggy code and then later reading the code trying to find the bugs?
:-) :-) :-) :-)
If you havent gone to university, you are not suitable for the job
That premature optimization means you shouldn't optimize at all. I've seen more horrendously bad databases because no one wanted to consider performance (critical to any database system) in design as that was premature optimization than any other database design issue . Rubbish, there are known performance killers, stop using them as your first choice.
Another myth, it's too hard to refactor the database. No but you have to consider how to do refactoring in the design phase to do it effectively. And BTW, the longer you wait to fix that annoying design-based performance issue, the harder it's going to be to fix.
Another bad myth, database design should reflect OOP principles. No, databases are designed to work with sets not OOP principles. Some OOP things will cause horrible performance problems and others are just pain silly in database terms.
Finally, you should enforce data integrity in the application. Databases are going to last past the application and would lose the rules when the application is replaced, mulitple applications are going to access them and there will often be the need to run direct queries to fix things that do not go through the application. I have never seen a database that refuses to enforce data integrity in the datbase that has good data.
That there is some mythical source of absolute best practices.
No deviation can ever be justified.
No document claiming to define something as a best-practice can ever be questioned.
The fact that marketing seems to think that adding a ton of small features is less work than adding a single, but rather heavy, feature. Which probably is a more specific case of the misconception that "task-switching has no overhead".
If we use something other than Java, C# and C++ in our project, we won't find any programmers to support it.
That commenting code is unnecessary, or that "good code doesn't need comments". Sometimes you need to explain what a complex bit of code is doing. Furthermore, commenting sections of code helps you skim read much more effectively.
The worst myth: If you are programming for a long time then you can be a Project Manager easily.
And that you should become a project manager if you have been programming for a long time.
Java is just C++ with different classes.
Probably the most dangerous one I've seen, because it gets accepted so readily, is that being able to write code quickly is good, and therefore the more quickly you can code [insert feature here] in a given language, the better the language is.
This is a serious example of premature optimization, since far more work goes into maintaining code than creating it. This means that it's much more important to write code that's easy to read, comprehend and debug than code that's easy to write quickly, and facilitating easy-to-read code is a much more useful measurement of language quality.
Manufacturing lessons can be applied to the software development process.
that as a programmer you know everything about latest hardware trends, overclocking, case mod, etc. friends and relatives consult you when they buy their gears.
That when programmers say it's very hard to do/simply impossible, HR thinks they're lazy and unmotivated
There must be an open source program for my business. Can't you just download it and tweak to my requirements.
I've had more than one person ask me about what it is like to program only to realize midway through the conversation that they actually think we program directly in binary or using mathematical symbols.
I don't know if I want to dispel that myth, it makes me look really smart!
I think the biggest misconception is that it's more important being able to write the code down easily than being able to read and understand the code.
Programming is just like assembly line work. You are working on a product for a certain time (maybe with coworkers) and finally you ship it. Just like building a house of bricks.
Contra: Programming contains a lot creativity and planning. It is art. Like the mason, also a programmer knows the difference between shaping a brick and planning a whole cathedral.
Porting a program to C++ will automatically make it run faster.
Any programming environment with a visual designer of some sort will make it so that business users can "write" the program and actual programmers aren't needed.
OOP reuse. It's the biggest fallacy marketed in programming.
That learning the syntax is the hard part.
That assigning a priority other than "1" means the task will never be done.
I had a manager ask me to customize the bug-tracking tool with priorities 1a, 1b, 1c, 1d, and 1e so he could assign everything as some variation of priority 1, but we could still organize the work.
And yes, I did get through all the "priority 1" issues. But before I could proceed to the issues that were still in priority 2-5, the manager made me re-assign the priorities of those issues into the five priority 1 levels.
(I realize this myth isn't specific to programming, but that's true of several other answers on this thread.)
2 myths I want to have revealed. A lot of my friends do not understand that Java and JavaScript are completely different, and a lot of non-programmers I know don't understand that there is more than one language. One of my friends was just getting into programming and needed some help from me, 'course he didn't even know what language he was working in.
Those both come up a lot for me.
As long as the computer understands the code you type in, that's all that matters. Therefore typing in comments and using variable names that are more than two letters long is a waste of time. :-(
Keyboarding form is related to programming ability. Seriously, one of the teachers at my high school told me, "You can't code quickly if you can't type quickly." My response was, "That's like saying I can only write the Great American Novel if I do it in cursive."
That the prototypical programmer:
Bug free software. Later I came to know that every program would still run with Bugs and whole play was about accomplishing customer Requirements.
That Hungarian notation only means that you prefix variable names with a type (like int iArraylength = 5; ) instead of what kind of data it holds (like int xcTextfield = getTextfield().coord.x; )
"Systems Hungarian notation" != "Apps Hungarian notation"
That any code written in an OOP (C#, C++, Java) language by anyone is automatically Object Oriented and "Reusable".
It wasn't just once where I was asked to reuse a thousand line code block or a class in an architecture that did not have any patterns except inheritance (which doesn't even count). Apparently, copy pasting also counts as good code-reuse for anyone who doesn't know the difference between an OO-language and OOP itself.
A favorite TDWTF that's happens every so often: Code-Refuse
That web apps can be up "7x24."
Ask any business person what downtime is allowed and they always insist on 100% uptime. Nevermind that 1 minute downtime per week is still 99.99% and is nearly unachievable for an organization smaller than a major utility.
All programs written in C/C++ will execute faster than Java/C# equivalent programs.
Programmers who became managers saying:
"Three weeks?! I've coded in the past, how hard can it be?"
That any M.Sc. with one programming course is enough to be hired as a software developer.
That because you are a programmer, you know how to fix the copier.
That being a manager is better then being a coder. Being a manager is BORING. Anybody who went into pure management has never loved programming to begin with.
Which wrong ideas are widespread for long time
There is a very widespread belief among programmers about how to find performance problems. It is that in order to find them, you have to measure them.
The simplest counter-example is an (undesired) infinite loop. It takes 100% of time, doing things that are completely unnecessary.
How do you find the problem? You get it under a debugger and pause, halt, or interrupt it. Then you look at the stack, because you know the loop is somewhere on it. You've caught it in the act. Did you measure it? or just find it?
Suppose it's not an infinite loop, it just takes longer than you think necessary. Suppose the unnecessary work is less than 100%, like 90%, 50%, or 20%. It's the same idea. If you pause it, that percent is the chance that you will catch it in the act. (You don't have to know what the percent is to catch it.)
Just to be sure, you can pause it several times. As soon as you see it doing something, on as few as two samples, that you can replace with something faster, you can fix it for a nice speedup. Not only that, you've just made any other problems easier to find, because the time is shorter and they take a bigger percent. This can "snowball" until the code is very close to optimal.
Of course, if you want to measure the problem, just take more samples, but that's not a prerequisite to finding it.
People tell me, wishfully, that this is what sampling profilers do but do it better. Many would rather debate the issue than see for themselves.
That a manager knows jack-squat about the code that his/her developers are writing.
There is a language called C/C++
Or that the languages are so close that skills are interchangeable.
Among programmers: That Delphi is dead, dying or on life support.
That writing software is actually about writing code.
Many people tend to think that JavaScript is similar to C++ and don't understand that it actually uses prototype inheritance.
That programming languages change all the time.
This might have been a long time ago in the past...
But nowadays the changes are mostly extra features which try not to break existing code.
Why do programmers insist on writing bugs? (Coming from a marketing+tester person that can never get a bug report done right).
Using English (or your native language) to describe a problem:
is more useful than providing a compilable example of the code the illustrates the problem.
The whole hollywood mentality (for lack of a better name) that whenever a programmer in a movie/tv series speaks up he needs to articulate every technology he needs (I need a PHP front-end and a MySQL back-end!!!11)... And then some more that doesn't make any sense at all of course.
If I would talk like this I'd probably get kicked in the nuts.
Good Programmer if you spend more time on programming.Practice makes a person perfect but doesnt make him good.
That comments are actually useful
