Long-held, incorrect programming assumptions

For a long time I assumed that everyone else had this super-mastery of all programming concepts (design patterns, the latest new language, computational complexity, lambda expressions, you name it).

Reading blogs, Stack Overflow and programming books always seemed to make me feel that I was behind the curve on the things that all programmers must just know intuitively.

I've realized over time that I'm effectively comparing my knowledge to the collective knowledge of many people, not a single individual and that is a pretty high bar for anyone. Most programmers in the real world have a cache of knowledge that is required to do their jobs and have more than a few areas that they are either weak or completely ignorant of.

That people knew what they wanted.

For the longest time I thought I would talk with people, they would describe a problem or workflow and I would put it into code and automate it. Turns out every time that happens, what they thought they wanted wasn't actually what they wanted.

Edit: I agree with most of the comments. This is not a technical answer and may not be what the questioner was looking for. It doesn't apply only to programming. I'm sure it's not my longest-held assumption either, but it was the most striking thing I've learned in the 10 short years I've been doing this. I'm sure it was pure naivete on my part but the way my brain is/was wired and the teaching and experiences I had prior to entering the business world led me to believe that I would be doing what I answered; that I would be able to use code and computers to fix people's problems.

I guess this answer is similar to Robin's about non-programmers understanding/caring about what I'm talking about. It's about learning the business as an agile, iterative, interactive process. It's about learning the difference between being a programming-code-monkey and being a software developer. It's about realizing that there is a differnce between the two and that to be really good in the field, it's not just syntax and typing speed.

Edit: This answer is now community-wiki to appease people upset at this answer giving me rep.

That I know where the performance problem is without profiling

That I should have only one exit point from a function/method.

That nonprogrammers understand what I'm talking about.

That bugfree software was possible.

That private member variables were private to the instance and not the class.

I thought that static typing was sitting very still at your keyboard.

That you can fully understand a problem before you start developing.

Smart People are Always Smarter than Me.

I can really beat myself up when I make mistakes and often get told off for self-deprecating. I used to look up in awe at a lot of developers and often assumed that since they knew more than me on X, they knew more than me.

As I have continued to gain experience and meet more people, I have started to realise that oftentimes, while they know more than me in a particular subject, they are not necessarily smarter than me/you.

Moral of the story: Never underestimate what you can bring to the table.

For the longest time I thought that Bad Programming was something that happened on the fringe.. that Doing Things Correctly was the norm. I'm not so naive these days.

I thought I should move towards abstracting as much as possible. I got hit in the head major with this, because of too much intertwined little bits of functionality.

Now I try keep things as simple and decoupled as possible. Refactoring to make something abstract is much easier than predicting how I need to abstract something.

Thus I moved from developing the framework that rules them all, to snippets of functionality that get the job done. Never looked back, except when I think about the time I naively thought I would be the one developing the next big thing.

That women find computer programmers sexy...

That the quality of software will lead to greater sales. Sometimes it does but not always.

That all languages are (mostly) created equal.

For a good long while I figured that the language of choice didn't really make much of a difference in the difficulty of the development process and the potential for project success. This is definitely not true.

Choosing the right language for the job is as important/critical as any other single project decision that is made.

That a large comment/code ratio is a good thing.

It took me a while to realize that code should be self documenting. Sure, a comment here and there is helpful if the code can't be made clearer or if there's an important reason why something is being done. But, in general, it's better to spend that comment time renaming variables. It's cleaner, clearer and the comments don't get "out of sync" with the code.

That programming is impossible.

Not kidding, I always thought that programming was some impossible thing to learn, and I always stayed away from it. And when I got near code, I could never understand it.

Then one day I just sat down and read some basic beginner tutorials, and worked my way from there. And today I work as a programmer and I love every minute of it.

To add, I don't think programming is easy, it's a challenge and I love learning more and there is nothing more fun than to solve some programming problem.

"On Error Resume Next" was some kind of error handling

That programming software requires a strong foundation in higher math.

For years before I started coding I was always told that to be a good programmer you had to be good at advanced algebra, geometry, calculus, trig, etc.

Ten years later and I have only once had to do anything that an eighth grader couldn't.

That optimizing == rewriting in assembly language.

When I first really understood assembly (coming from BASIC) it seemed that the only way to make code run faster was to rewrite it in assembly. Took quite a few years to realize that compilers can be very good at optimization and especially with CPUs with branch prediction etc they can probably do a better job than a human can do in a reasonable amount of time. Also that spending time on optimizing the algorithm is likely to give you a better win than spending time converting from a high to a low level language. Also that premature optimization is the root of all evil...

• That the company executives care about the quality of the code.
• That fewer lines is better.

I would say that storing the year element of a date as 2 digits was an assumption that afflicted an entire generation of developers. The money that was blown on Y2K was pretty horrific.

That anything other than insertion/bubble sort was quite simply dark magic.

That XML would be a truly interoperable and human readable data format.

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.

I believed that creating programs would be exactly like what was taught in class...you sit down with a group of people, go over a problem, come up with a solution, etc. etc. Instead, the real world is "Here is my problem, I need it solved, go" and ten minutes later you get another, leaving you no real time to plan out your solution efficiently.

I thought mainstream design patterns were awesome, when they were introduced in a CS class. I had programmed about 8 years as hobby before that, and I really didn't have solid understanding of how to create good abstractions.

Design patterns felt like magic; you could do really neat stuff. Later I discovered functional programming (via Mozart/Oz, OCaml, later Scala, Haskell, and Clojure), and then I understood that many of the patterns were just boilerplate, or additional complexity, because the language wasn't expressive enough.

Of course there are almost always some kind of patterns, but they are in a higher level in expressive languages. Now I've been doing some professional coding in Java, and I really feel the pain when I have to use a convention such as visitor or command pattern, instead of pattern matching and higher order functions.

For the first few years I was programming I didn't catch on that 1 Kbyte is technically 1024 bytes, not 1000. I was always a little perplexed by the fact that the sizes of my data files seemed slightly off from what I expected them to be.

That condition checks like:

if (condition1 && condition2 && condition3)

are performed in an unspecified order...

That my programming would be faster and better if I performed it alone.

"The project will be done in 2 weeks"

and

"That will take 2 hours to implement"

That I can understand my own code without comments!!!

I thought I would need it.

That dynamically typed languages like Python or Ruby are somehow less qualified for use on large projects.

One assumption I had as a rookie those days was that people with more years in the field automatically are better developers..

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.

This is really embarrassing but when I was starting to learn how to program nothing could satisfy me. I wanted to write video games. Not the trivial little programs all these books wanted me to write. So I decided I could easily skip 10 chapters and ignore the basics.

So I basically ignored variables!

The problem was that I did not recognize keywords from conventions:

Car car = new Car(); //good
Car test = new Car(); //wrong must be lowercase car!

for (int i = 0; i < 10; i++) //good
for (int test = 0; test < 10; test++)//wrong must be i

I did this for over a year and even made a tic-tac-to game in 3000 lines! I was thrilled by my awesomeness at that point, until I found a tic-tac-to in 150 lines on the Internet. Then realized I was an idiot and started over again.

That programming is easy.

That Unix and Linux OSs are well designed ... I should probably qualify this(!)

Firstly, the view is reenforced by such anti-truisms as:

• every subsequent OS developed ends up redesigning Unix poorly (it's said about Lisp as well, where it is more true).
• the list of rules that make the 'Unix philosophy'. It's not that they are wrong, it's the implication that Unix itself follows them closely.

It may be more true to say that they were well designed/well done, and surely parts of them are, but even this is just a relative judgment, relative to some awful versions of Windows. Here are some examples of things that are done badly:

• configuration is a mess, ad-hoc flat file configs are not good
• the C programming language should have been replaced (by something like D) a long time ago
• shell scripting is schizophrenic. It is not good for development as it is shorthand designed for quick typing.
• directory structures are badly named
• the GNU tool chain is unnecessarily arcane
• the belief that general purpose always trumps special purpose

Overall they require unnecessary expertise to operate. Or rather a lot of knowledge where there is only a moderate amount of understanding.

It's not all bad. Linux is politically better and not corrupted by business needs, but sadly to a large degree a lot of the technical highground has been lost.

Ok, I learned programming rather early. I was 14 or so. And I held all kinds of crazy beliefs, but don't ask me about the precise timing, because that was a … long while ago.

• Ok, so, I believed for a while that if you use the term synchronize in Java, then Java solves this nasting synchronizing thing for you

• I believed for at least half a year, likely more, that static typing would improve performance.

• I believed that freeing something would return memory back to the OS.

• I believed that malloc calls boil down to checking if there is enough free space on the OS, so malloc would be inexpensive.

• I thought a long while that Java was built with all the benefits and flaws of the other languages in mind, into a "perfect blend" that would take the best properties of the other languages and reject the mistakes.

• I vastly overestimated the number of cases where LinkedLists outperform ArrayLists.

• I thought that NP-hardness was a proof that no INSTANCE could be solved efficiently, which is trivially false, for a while.

• I thought that finding the best flight-plan on travel agency web sites would take so long because of the "Travelling Salesman Problem", as I proudly chuckled to my relatives (when I was small, alright?!)

Could come up with more. No idea how long I sticked to each of them. Sorry.

PS:
Ahh, ok, this one got cleared up not so slowly, but I see newbies do this every now and then, so I thought you might be interested: I also thought that to store an uncertain number of things, you'd need to declare a new variable for each. So I'd create variables a1, a2, a3, ..., rather than using one variable a, which I would declare to be a vector.

When I first started after graduating from university I expected that more senior developers would know what they were doing. Boy was I wrong....

I used to believe that the majority of work on an application was actually programming. I'm sure this is true in some cases, but in my experience I spend more time researching, documenting, discussing, and analyzing than actually coding. (I work on software that operates a laser-based sensor, and determining how best to control the hardware is much more challenging than writing the code to do so.)

I also used to think that open environments where programmers can look over their shoulder and ask the guy (usually) next to them a question were the best environments for a team of programmers to hammer out a solution. It turns out that a dark lonely room is more productive, team or no team.

When I graduated, I assumed that programming professionally would be like programming in college, meaning that I would be given the inputs and expected outputs and asked to fill in the black box that does the conversion. In reality, I have to figure out the inputs, outputs and the black box.

I didn't used to think marketing and sales guys were the scourge of the human race, so naive.

That's its a 9-5 job

Having No defects is possible before going live.

It is definitely not true, even P2 defects get left open at times.

That code reviews are a waste of time.

Having moved from a company where they were entirely optional to one where they are mandatory (even audited) I've come to understand their usefulness. Having a second set of eyes on code, even on the most trivial pieces, can:

A) save you embarrassment when you screw up something trivial (a trivial code review, for instance, would have prevented us from spamming hundreds of emails to our customers, at my previous job)

B) can teach you things that you didn't know in the first place (I'm ever learning new libraries at my current job - inevitably at a big company, someone has already stumbled upon the problem you have and done a better job solving it - it's just a matter of knowing where to look)

C) at the very least ensure that someone other than yourself knows how things work.

In the end, I wind up happier with the code I submit here, than in my previous employment, even though back then I thought I knew everything :)

That if conditions were evaluated every line, and if you wrote code like this:

Dim a as Boolean = True
If a Then
    Console.WriteLine("1")
    a = False
    Console.WriteLine("2")
Else
    Console.WriteLine("3")
End If

Then the output would be:

1
3

That the design of the NT operating system is flawed when compared to UNIX. It turned out that NT Kernel and design decisions are very similar to any modern UNIX like system and that most of the problems you get in the kernel is the result from third party buggy drivers written by buggy companies.

That .NET structs (C# and VB.NET) were reference types, just like classes.

I "received" that piece of wisdom at some point shortly before or after .NET 1.0 arrived on the scene (I've no idea where from, it may have sprung whole from my mind, like Athena from the brow of Zeus), and kept it until disabused of the notion by Jon Skeet about 4 months ago.

Thanks Jon.

P.S. Not programming related, but I also believed (until about 5 minutes ago) that "Apollo sprang whole from the brow of Zeus".

That bytes and characters were the practically same thing - "ASCII" was just a way of mapping a byte value to a glyph on the screen.

Reading about Unicode really opened my eyes (although I still don't fully understand it).

That I was a good programmer!

I used to assume it's enough to program Win32 applications.

Also that every program must come with a GUI, because command-line is "outdated".

That one day I'd have a realistic idea how long it would take to build some nontrivial code/system/whatever.

I thought all I needed to do to improve database performance was put the database in 3rd normal form.

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

That this:

SomeClass object(initialValue);

and this:

SomeClass object = initialValue;

were guaranteed to be equivalent in C++. I thought the second form was guaranteed to be interpreted as if it had been written as the first form. Not so: see C++ Initialization Syntax.

Some of the things that I still have trouble with are the following misconceptions - I still try and hold on to them even though I know better:

• All stakeholders will make decisions about software design objectively. Those that aren't embroiled in writing the code make all sorts of decisions based entirely on emotion that don't always make sense to us developers.
• Project budgets always make sense - I've seen companies that are quite happy to drop [just for example] $50,000 a month for years rather than pay $250,000 to have a project completed in 6 months. The government for one loses their annual budget if they don't spend it - so spend it they will, come hell or high water. It astounds me at how many project dollars are wasted on things like this.
• You should always use the right tools for the right job - sometimes this decision is not in your hands. Sometimes it comes down from on high that "thou shalt use X technology" for this project, leaving you thinking "WTF! Who came up with that ridiculous idea?"... the guy paying your paycheque, that's who, now get it done.
• Programming ideology comes first and foremost, everything else is secondary. In reality, deadlines and business objectives need to be met in order to get your paycheque. Sometimes you make the worst decisions because you just don't have time to do it the right way... just as sometimes that word is on the tip of your tongue but the minute it takes to recall it makes you choose a different and less ideal word. There isn't always time to do it right, sometimes there is only time to do it - however that may be. Hence oft' seen anti-patterns used by so called experienced developers who have to knock out a solution to a problem 10 minutes before the presentation deadline for the software being delivered to your best client tomorrow.

Back when I programmed on the TI-83, I thought you couldn't assign a variable to itself. So (ignoring that this is C code, not TI-BASIC) instead of writing

c = c + 1;

I would write

d = c + 1;
c = d;

When I learned about += and ++ it blew my mind.

That IDEs would get faster.

That I should always optimize my code. That's not to say I shouldn't think through it before I write it, but that I should think hard about how to squeeze every bit of performance out of each statement, even to the point of sacrificing readability.

That XML namespaces (or worse, well formedness) are in some way more difficult than trying to do without them.

A very common blunder, even at the W3C!

My incorrect assumption: That while there's always some room for improvement, in my case, I am pretty much as good a programmer as I can be.

When I first got out of college, I'd already been programming C for 6 years, knew all about "structured programming", thought "OO" was just a fad, and thought "man, I am good!!"

10 years later, I was thinking "OK, back then I was nowhere near as good as I thought I was... now I get the ideas of polymorphism and how to write clean OO programs... now I'm really good".

So somehow, I was always really good, yet also always getting way better than I was earlier.

The penny dropped not long after that and I finally have "some" humility. There's always more to learn (have yet to write a proper program in a purely functional language like Haskell).

I think I was 10 years old when someone convinced me that there will be a computer capable of running an infinite loop in under 3 seconds.

In C++, during a long time I was tkinking that compiler rejects your when giving a definition for a pure virtual method.

I was astonished when realizing that I was mistaken.

Many times when I tell someone else to give a default implementation of its pure virtual destructor for its abstract class, he/she looks back at me with BIG eyes. And I know from here that a long discussion will follow ... It seems a common belief somewhat spread within C++ beginners (as I consider myself too .. I am still learning currently!)

wikipedia link to c++'s pure virtual methods

As an old procedural programmer, I didn't really understand OO when I first started programming in Java for a hobby project. Wrote lots of code without really understanding the point of interfaces, tried to maximize code re-use by forcing everything into an inheritance hierarchy - wishing Java had multiple inheritance when things wouldn't fit cleaning into one hierarchy. My code worked, but I wince at that early stuff now.

When I started reading about dynamic languages and trying to figure out a good one to learn, reading about Python's significant whitespace turned me off - I was convinced that I would hate that. But when I eventually learned Python, it became something I really like. We generally make the effort in whatever language to have consistent indent levels, but get nothing for it in return (other than the visual readability). In Python, I found that I wasn't doing any more effort than I had before with regard to indent levels, and Python handled what I'd been having to use braces or whatever for in other languages. It makes Python feel cleaner to me now.

G'day,

That I'd be just designing and writing code.

No requirements gathering, documentation or supporting.

cheers,

• My co-workers were/are producing supposedly bad code because they sucked/suck. It took me a while to learn that I should first check what really happened. Most of the times, bad code was caused by lack of management, customers who didn't want to check what they really wanted and started changing their minds like there's no tomorrow, or other circunstances out of anyone's control, like economic crysis.
• Customers demand "for yesterday" features because they are stupid: Not really. It's about communication. If someone tells them it everything can really be done in 1 week, guess what? they'll want it in 1 week.
• "Never change code that works". This is not a good thing IMO. You obviously don't have to change what's really working. However, if you never change a piece of code because it's supposedly working and it's too complex to change, you may end up finding out that code isn't really doing what it's supposed to do. Eg: I've seen a sales commission calculation software doing wrong calculations for two years because nobody wanted to maintain the software. Nobody at sales knew about it. The formula was so complex they didn't really know how to check the numbers.

never met with integer promotion before... and thought that 'z' would hold 255 in this code:

unsigned char x = 1;
unsigned char y = 2;
unsigned char z = abs(x - y);

correct value of z is 1

The OO is not necessarily better then non-OO.

i assumed that OO was always better.. then i discovered other techniques, such as functional programming, and had the realization that OO is not always better.

That goto's are harmful.

Now we us continue or break.

I just recently found out that over a million instructions are executed in a Hello World! c++ program I wrote. I never would have expected so much for anything as simple as a single cout statement

don't use advanced implementation-specific features because you might want to switch implementations "sometime". i've done this time and again, and almost invariably the switch never happened.

I am a young fledgling developer hoping to do it professionally because it's what I love and this is a list of opinions i once held that I have learned through my brief experience are wrong

The horrible mess you end up with when you don't seperate user interface from logic at all is acceptable and is how everyone writes software

There's no such thing as too much complexity, or abstraction

One Class One Responsability - I never really had this concept, it's been very formitive for me

Testing is something I don't need to do when I'm coding in my bedroom

I don't need source control because it's overkill for the projects I do

Developers do everything, we're supposed to know how to design icons and make awesome looking layouts

Dispose doesn't always need a finaliser

An exception should be thrown whenever any type of error occurs

Exceptions are for error cases, and a lot of the time it's OK to just return a value indicating failure. I've come to understand this recently, I've been saying it and still throwing exceptions for much longer

I cam write an application that has no bugs at all

That we as software engineers can understand what the user really wants.

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.

That the only localization/internationalization issue is translating messages.

I used to think that all other languages (and I had no concept of locales) were like English in all ways except for words and grammar. To localize/internationalize a piece of software, therefore, you only needed to have a translator translate the strings that are shown to the user. Then I began realizing:

• Some languages are written right-to-left.
• Some scripts use contextual shaping.
• There is large variation in the way that dates, times, numbers, etc. are formatted.
• Program icons and graphics can be meaningless or offensive to some groups of people.
• Some languages have more than one "plural form".
• ...

Even today I sometimes read about internationalization issues that surprise me.

• Programming Language == Compiler/Interpreter
• Programming Language == IDE
• Programming Language == Standard Library

I used to think I was a pretty good programmer. Held that position for 2 years.

When you work in a vacuum, it's easy to fill the room :-D

That the now popular $ sign was illegal as part of a java/javascript identifier.

Thinking that I know everything about a certain language / topic in programming. Just not possible.

That virtual-machine architectures like Java and .NET were essentially worthless for anything except toy projects because of performance issues.

(Well, to be fair, maybe that WAS true at some point.)

That C++ was the coolest language out there!

It's important to subscribe to many RSS feeds, read many blogs and participate in open source projects.

I realized that, what is really important is that I spend more time doing coding. I have had the habit of reading and following many blogs, and while they are a rich source of information its really impossible to assimilate everything. It's very important to have balanced reading, and put more emphasis on practice.

Reg. open source, I'm afraid I won't be popular. I have tried participating in open source, and most of them in .NET. I'm appalled to see that many open source projects don't even follow a proper architecture. I saw one system in .NET not using a layered architecture, and database connection code was there all over the place including code behind, and I gave up.

That managers know what they talk about.

I could spend days trying to reduce the amount of memory my business layer used, just to later realize that the WinForms (GUI) of my project used 4 times more memory than the rest of the application.

the assumption that i was to make the program 100% complete and bug free and report it as "completed". Sometimes the company wants to release the program when there are many bugs to get market share first.

that after I finish CS school, I can start a job and use my knowledge that I learned in school for real world applications. (I actually wish i wouldn't waste 4 years of my life in learning operating systems and prolog)

Bitwise comparisons on integers in SQL WHERE clauses are practically free in terms of query performance.

As it happens, this is somewhat true for the first half-million rows or so. After that it turns out to be extremely UN-free.

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

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

That ASCII was stored in a different way to binary

In the early days, most personal computers had a cassette tape interface for loading and storing programs. I did not have a computer at this time but read everything I could get my hands on (mostly magazines) that had anything to do with computers (this was the late 70's - no internet for me). For some reason I was under the impression that programs were executed directly from the cassette tape and that the only reason computers had any RAM was to store variables while the program ran. I figured that when the code had to execute a jump instruction, it would somehow rewind or advance the tape to the correct position and continue from there.

That everyone else is using the latest and greatest technology, while my team is the only one stuck with inferior outdated tools. (Except for the mystic cobol dinosaurs)

That everyone wants to produce the best\most sutiable code possible for a problem...

That, being the owner of the code I write, I'm the only person who should understand or touch it.

That people would care about best practices, or even consistency.

alt text http://images.despair.com/products/demotivators/teamwork.jpg

That there is always a "right" way of doing things. I held onto this assumption for far too long after leaving university.

Of course I came to realise that there are always many ways a task can be completed. There are always advantages and disadvantages to each method. Look at the information available, decide, then make sure you can justify it to your boss.

Turns out it doesn't matter whether you check if memory allocation returns a reference or not under Linux, as it will actually lie to you and either actually allocate the memory at some time in the future or abort your program altogether if it doesn't have the memory you need.

Since college days, I thought myself to be master of programming. since I could code but others couldn't. But when I joined a company, then I was struck by my ignorance about basics. All my assumptions about myself turned out to be wrong! Now I know what I need to know and what I do not know!

When at college (mid 90's) they only had Windows 3.11 machines in the computer lab (I know, weird college).

For a while I thought that only the Windows platform was relevant to me as a professional programmer and that all other platforms were only interesting from an historical academic point of view.

After graduating from school and learning about modern unixes and linux environments I couldn't help feeling angry and disappointed about my lame school.

I cannot yet believe I graduated with a computer engineering degree without ever seeing a bash shell or even hearing about emacs or vim.

That it was so important to make efficient programs without wasting a byte nor a CPU cycle.

But with more experience, its not about bytes or about CPU cycles, its about your flow of thought, continuous, uninterrupted, much like a poem.

Essentially, don't try too hard.

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...

Learning regular expressions will save you time

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.

That the evaluation order of if statements in C/C++ was compiler-specific. So writing:

if ( pointer != NULL ) && ( pointer->doSomething() )

Was un-safe because the evaluation order could be swapped. I found out recently (after many years of spouting that lie) that its part of the ANSI-C specification, you can guarantee the order and its perfectly safe.

James

That I would ever become wealthy programming software for someone else

In school, you are taught the programming is "read input, process data, write output". In reality, there is rarely a processing step -- Most coding is just "read input, output"

Generally, it's either "read from user, write to database" or "read from database, display on screen". Those two cases cover about 95% of the work you'll ever do.

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

The less code the better. Now I know that sometimes it's worth to have more lines of code if it makes easier to read/understand

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 I wouldn't need to rapidly refactor my Object oriented code. Martin Fowler finally opened my eyes.

That I would never find a practical use in programming for the Karnaugh maps I was taught in my computer science curriculum.

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.

If you can't read my code, you just don't know the language. I had a few code reviews where I tried to counter with that.

Took a couple more years to learn there's a time and place to be magical with your code and it is in the libraries, not the application. The app is for clarity and readability. Magic is best used when hidden behind extension methods and frameworks.

That I grok programming. By studying the SICP book I saw that I knew nothing. At least now I am delving into programming more.

the assumption that if i write code really well and as bug free as possible, and that's the best thing i can do. turns out sometimes the managers prefer people who try to become their favorite instead of doing nice work.

That programming elegance combined with automation was an adequate substitute for good old-fashioned testing.

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.

That somehow a company that runs a large number of fairly high profile/high traffic websites actually knew what the heck they were doing. It ended up they were for the most part clueless and extremely lucky to be in the position that they were in. So I guess the moral would be,

solid software engineering && best practices != business success

or....

most critical software systems == crap

This is embarrassing, but for the longest time I had believed it was more memory efficient to nest my method calls, or make multiple method calls, than to create a variable to store the value for each method call in C#.

Not longest-held, but at some point and for several years I:

• Thought Microsoft Windows was the only Operating System in the world ( it was 1992 )
• Knowing DOS was more than enough to have "advanced" OS knowledge.

That's why I didn't choose "computer course" in high school. I thought that I knew already enough about computers.

Later at university and out of my mistake:

• I thought that UNIX os/programs were perfect and DOS/Windows won't ever come any close to it ( back then it look so true, I guess Linus at al thought the same and that's why Linux is sooo similar to UNIX and not.. well other OS's )

Finally and for a long time, I thought that:

• Only my software sucks and commercial software was flawless, because... it was "COMERCIAL" software
• USA software/engineers/products were synonyms of excellence and anything outside were just poor attempts.

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

Error handling is unnecessary when you have tested your code thoroughly.

That always there is not enough time to finish it before deadline.

That a WTF is always an evidence of a bad professional.

In fact I've been realizing recently how many WTF's I committed myself throughout my career, but I was comforted when StackOverflow showed me they are just another software metric.

That variables are actually just names for specific areas in the memory.

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.

That a language suitable for systems programming must support [mutable] variables.

Common poor assumptions: "Quality of Code is secondary". Even poorer assumption: "Quality of code is not important at all."

Quality of code can be a very broad concept. I disscued it quite thoroughly here.

That the more lines of code then the better the software would be.

That you could memset( this, 0, sizeof(TheObject) ) a C++ object in its constructor with no negative consequences

That marketing guys care about what you do.

That you needed a client specification to complete a project. More times than not you start with a sales meeting and a notepad. Of course at the end of the meeting they would like a deadline, "just ballpark it".

I never thought I would be a professional programmer, I thought I would be working with electronics. But in the end, programming is so much easier and pays so much better that what started as a side job became my main thing.

My biggest preconception was that I would be allowed program the way I wanted to. Then of course I left university and got employed by a company that had ridiculous frameworks, rules and procedures in place that not only meant I wasn't programming the way I wanted to, but meant I was programming badly.

• I thought I'd be coding for 8 hours straight. Realistically, I get 4 hours a day of coding, 1 hour for lunch, 1 for coffee breaks, and 2 for screwing around / chit chatting/ stack over and under flowing.

• Prior to working, I thought that all clients would be idiots and don't know two craps about computers. Boy was I wrong on that one. Sometimes, we get projects by people who can do it better than we can, they just don't have the time to do it.

• I thought cubicles were bad, Right now I love them :D I actually moved from a door-ed office to a cubicle. I like the openness.

• All programmers are not athletic. I thought that I was the only one that goes to the gym. Where I work, at least 10 of us go to the gym every day at 5 am.

• I thought there would be no women programmers. A couple of our leads are ladies.

That Java passes copies of objects to functions, not references.

In other words, I thought that if you pass an object into a method, then change the object in some way, it doesn't change the object in the calling scope. I always passed objects into methods, manipulated them, then returned them!

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 software engineers are always honest about what they are doing now or done to your software in the past.

That 640K should to be enough for anybody (DOS). That was widely believed by a lot of people for a number of years.

The first time I had a system with 8MB of RAM, I thought that was far more than I needed. That ran the OS (Mac) plus all the applications I was using (Word, Email, Firefox, etc).

That threads in Windows are cheap.

Turns out this is only somewhat true. A thread has a certain amount of overhead and requires its own address space where it can live and be happy. So if I find myself dealing with dozens of threads within a single application, I ask myself how I can simplify and consolidate everything into fewer threads.

That everything I wrote would fail at some point in the foreseeable future.

Not that everything won't eventually fall apart, but early on in my programming education, when I found try..catch blocks...I wrapped EVERYTHING in them....things that, if they failed, would have represented much bigger problems than my programs would be handling (e.g., the north and south pole have switched places)

That learning a whole new language would be really really hard.

That run-time performance mattered. Total solution time is what matters, often.

Since learning python, I have weaned myself from my attachment to static typing.

I did not know something divided by 0 in Javascript is Infinity (IEEE 754 arithmetic). Learnt it the hard way recently.

That profiling and performance analysis were the same thing.

Then I found out that profilers, while better than nothing, contain faulty assumptions, such as:

• only aggregates matter, not details
• statistical precision is necessary in locating performance problems
• measuring time, and locating unnecessary time-consuming operations, are the same thing

That an identity column cannot contain duplicate values: identity column in Sql server

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.

That I know to write a proper web application and was all clear when I had to design stuff that works in all the browsers it screwed me.

That understanding pointers and recursivity would be freakin' hard.

That Integers in VB6 has different size than .Net.

That VB6 could make bit level operations.

Professional programmers make bug-less software.

That OOP was obsolete :( I still regret thinking that till this very day.

If I have a powerful static type system like the one in ML or Haskell, I should use it to encode as many invariants as possible. Only with experience did I learn that sometimes it's better to let the invariants be dynamic.

That full Unicode support was a prerequisite for successfully deploying software to Asian regions.

I thought writing good enough software is an easy task

That our development methods were chosen and used because they were the best of breed.

Then I figured out that the tools we use had a much greater impact on what we did, when we did it, and how we did it than what I thought.

That people actually cared about the technologies being used (open source/ closed source).

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.

I assumed it was going to be a rollercoaster ride of fast cars, loose women, private jets and daring escapades. Just wait until I get my hands on that career advisor....

The specs are complete and suffient

Of course you could look at FindBugs and PMD but these are my favorite gotchas and tricks (all Java):

Fields are not overridden, they are shadowed.

There is no explicit super.super access.

Classes with no constructors defined have an implicit zero-argument constructor. I made a practical error related to this one this year.

To get a reference to an inner class's parent you can use the syntax "Outer.this" to disambiguate method calls or synchronize.

Classes are "friends of themselves" in C++ terms, private methods and fields of any instance of that class can be referenced from any method of the same class, even static methods. This would have made some of my early clone() and copy constructors much simpler.

Protected methods and fields are accessable in a static context of extending classes, but only if that class is in the same package. I'm glad that flex.messaging.io.amf isn't a sealed package.

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

That software requirements generally come from market research.

He said he knew programming, it must be true!

That dimension n is an instance of dimension (n+1) when they're equivalent.

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.

When i was learning algorithms in my junior middle school, i thought NPC as just non-polynomial problems, which meant the complexity of this problem was no more simple than polynomial. I didn't recognize i was wrong until i learned computational theory in my college -_-b

A program can eventually have all of its problems ironed out.

that:

for (int i = 0; i < myObj.variable; i = i + 1)

gets optimized to:

int j = myObj.variable; 
for (int i = 0; i < j; i = i + 1)

wow, i stopped putting in function calls in the place of j when I realized that they were being run EVERY time!

Reason:

for (int i = 0; i < myObj.variable; i = i + 1){ 
    if (function_argument == NULL){ 
        myObj.variable++; 
    } else { 
        printf("%d", myObj.variable);
    }
}

is not the same as:

int j = myObj.variable;
for (int i = 0; i < j; i = i + 1){ 
    if (function_argument == NULL){ 
        myObj.variable++; 
    } else { 
        printf("%d", myObj.variable);
    }
}

arbitrary example, but you can see how the optimization would change execution.

@Kyralessa: It's worth noting that on most processors, in assembly/machine language, it's possible for functions to return someplace other than their caller while leaving the stack in good condition. Indeed, there are a variety of situations where this can be useful. One variation I first saw on the 6502, though it works even better on the Z80, was a print-message routine where the text to be printed immediately followed the call instruction; execution would resume after the zero terminator (or, as a slight optimization when using the Z80, at the zero terminator, since letting the zero byte be executed as a NOP would be cheaper than trying to avoid it).

It's also interesting to note that in many modern languages, functions have one normal exit point (which will resume execution following the call) but can also exit by throwing an exception. Even in C, one can use setjmp/longjmp to simulate such behavior.

Java is slow. So many perl fan bois on slashdot regurgitate(sp???) this, its sad.

That I would be programming in VB forever, I am now c#.