Long-held, incorrect programming assumptions

That C++ was somehow intrinsically better than all other languages.

This I received from a friend a couple of years ahead of me in college. I kept it with me for an embarrassingly long time (I'm blushing right now). It was only after working with it for 2 years or so before I could see the cracks for what they were.

No one - and nothing - is perfect, there is always room for improvement.

This is embarrassing, but for the longest time I didn’t really grasp the difference between reference types and value types. I thought to you had to use the ref keyword to change an object in a different method.

This is one of the most fundamental concepts to C# that I should have known.

That object orientation is always the best way to design source code and will always be.

That IDEs would get faster.

That more comments are better. I've always tried to make my code as readable as possible--mainly because I'm almost certainly the guy that's going to fix the bug that I let slip by. So in years past, I used to have paragraphs after paragraphs of comments.

Eventually it dawned on me that there's a point where more comments--no matter how neatly structured--add no value and actually becomes a hassle to maintain. These days, I take the table-of-contents + footnotes approach and everyone's happier for it.

For a long time (about 5 years) I thought that PHP rocks.

I thought that I know algorithms. And then I joined Topcoder.com

I always assumed that anyone writing any code for any language used an editing program.

I was working with a client of mine who had me on mostly as support and to write some of the more complex things for him. Well one day he messed up a file, big time. He accidentally saved over three hours worth of his own work, and when I asked him why he didn't save more often he replied with, "because I wasn't done". Naturally, this was not an acceptable answer, and I poked and prodded a little further. I eventually came to find out that he he has never used any editing program, EVER! Not even notepad.exe! He had been using an online CPanel editor for files! It didn't even have a 'Find' function. He couldn't ever save until he was done because he was editing the live file on the site!

Needless to say I was flabbergasted, and he's still using the CPanel editor to this day...

My longest held (and therefore most costly) incorrect assumption was: "The business's requirements are sane and reasonable, I'm just not understanding them yet."

100 green assumptions sitting on the wall,
and if one green assumption should accidently fall,
there'd be 99 green assumptions sitting on wall.

Alternately:

Humpty dumpty sat on the wall.
Humpty dumpty had a great fall,
and all kings horses and all the kings men,
said Effim, he's only a tech.

That, by learning an exact science, I wouldn't need to improve my limited social skills.

Satisfy a customer by implenting what he wants - unfortunately this implies that a customer knows what he wants.

That Python was an impractical, annoying language (I can still read some comments on my early code, complaining about it) and C++ what the only true object-oriented language.

I was so wrong I still fill ashamed.

That the benefit of OOP is that you get to reuse the object, when in reality it's the resuse of the rest of the code by creating a new object that has the same interface.

In reality, the object might be 2% of the code so reuse gets you only 2% benefit. The real benefit is reusing other 98% of the code by creating a new object that allows all the other code to something completely different. Now you have reuse of 98% of the code. Well worth th 3x longer it takes to write something as an object.

E.g., If you have a drawing program and suddenly there is a new shape you want to be able to draw you just change the ShapeObject (while keeping the interface the same). Nothing else in the program has to change.

That all OOP languages have the same concept of object orientation.

• A Java interface != a method's interface.
• A Java interface is a language-specific solution for the need to have multiple inheritance. Ruby's mixins attempt to solve the same problem.
• Inheritance provided out of the box in Javascript is very different from how Java implements inheritance.

I used to think that I will never program like top tier developer like the MS developer, but now I think I can write same clean code or even better.

I thought Windows 3.1 was only a platform to play solitaire. And DOS is a platform for BASICA.

That creating a successful application can easily be done by only programmers. Software is also about ease of use, good looks, documentation and proper marketing. Software development is multi disciplinary and failing one discipline will probably fail the application.

I always believed that to be a good programmer one has to know all the inner workings of the system. I was ashamed of the fact that i didn't know everything that is to be known about the language like its libraries, patterns, snippets before you start coding. Well, I am not so naive anymore.

that temporary solutions are not permanent solutions
or in other words: workarounds are not for ever :)).

That because i built the software on my 'Standard' environment it would work on everyone's machine/server. Only to discover that i had installed some obscure libraries and services that actually were being used. And then discover that i leveraged a bug, that was subsequently patched.

You can't diagnose 'intermittent errors' in production. Rebooting the server is the only way to fix it.

Maybe is was MORE true in my early days of ASP coding. But there are a lot of good profiling tools to find memory leaks and other weird issues. Perfmon also provides lots of good diagnostic data. Plus you should be coding diagnostic logging into your application.

In the early eighties when I started playing around with computers (ZX81 with 1K of memory), I used spend hours to type in reams of machine code (bytes, not human readable assembly language) for games from magazines, essentially using BASIC Poke instructions.

I believed that if I ever entered a single instruction incorrectly then I'd have to go back to the beginning and start entering the machine code again from the start.

That salesmen manage customer expectations realistically. (Trained in under-promising and over-delivering)

That software requirements generally come from market research.

Thinking I'm the only one person that makes a piece of code... then when I need that routine I can't remember what I did and simply copy/paste my own code.

Now, I know that everybody does that.