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".
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.
if user.is_logged_in: print('Welcome') doesn't need a comment.
Commented
Sep 9, 2010 at 18:13
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.
If we use something other than Java, C# and C++ in our project, we won't find any programmers to support it.
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.