Long-held, incorrect programming assumptions

Question

I am doing some research into common errors and poor assumptions made by junior (and perhaps senior) software engineers.

What was your longest-held assumption that was eventually corrected?

For example, I misunderstood that the size of an integer is not a standard and instead depends on the language and target. A bit embarrassing to state, but there it is.

Be frank; what firm belief did you have, and roughly how long did you maintain the assumption? It can be about an algorithm, a language, a programming concept, testing, or anything else about programming, programming languages, or computer science.

Answer 1

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.

Answer 2

That programming is easy.

Answer 3

That bugfree software was possible.

Answer 4

That nonprogrammers understand what I'm talking about.

Answer 5

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

Answer 6

Having No defects is possible before going live.

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

Answer 7

That condition checks like:

if (condition1 && condition2 && condition3)

are performed in an unspecified order...

Answer 8

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

Answer 9

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

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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!

Answer 14

This language also OOPs....

Answer 15

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.

Answer 16

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

Answer 17

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.

Answer 18

That software engineers are always honest about what they are doing now or done to your software in the past.

Answer 19

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

Answer 20

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.

Answer 21

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

Answer 22

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.

Answer 23

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

Answer 24

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.

Answer 25

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

Answer 26

That I know where the performance problem is without profiling

Answer 27

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.

Answer 28

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.

Answer 29

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

Answer 30

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

Answer 31

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.

Answer 32

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.

Answer 33

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

Answer 34

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.

Answer 35

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

Answer 36

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

Answer 37

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

Answer 38

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.

Answer 39

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.

Answer 40

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

Answer 41

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

Answer 42

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.

Answer 43

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.

Answer 44

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.

Answer 45

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

Answer 46

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.

Answer 47

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)

Answer 48

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.

Answer 49

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

Answer 50

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.

Answer 51

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.

Answer 52

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

Answer 53

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.

Answer 54

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.

Answer 55

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.

Answer 56

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

Answer 57

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)

Answer 58

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.

Answer 59

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.

Answer 60

That goto's are harmful.

Now we us continue or break.

Answer 61

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.

Answer 62

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.

Answer 63

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

Answer 64

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.

Answer 65

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.

Answer 66

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

Answer 67

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

That software requirements generally come from market research.

Answer 68

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

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

Answer 69

I thought I would need it.

Answer 70

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.

Answer 71

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

Answer 72

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!

Answer 73

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.

Answer 74

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.

Answer 75

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

Answer 76

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 :)

Answer 77

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.

Answer 78

He said he knew programming, it must be true!

Answer 79

That women find computer programmers sexy...

Answer 80

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

Answer 81

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.

Answer 82

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

Answer 83

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

Answer 84

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

Answer 85

"The project will be done in 2 weeks"

and

"That will take 2 hour to implement"

Answer 86

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

Answer 87

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

Answer 88

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

Answer 89

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.

Answer 90

That an identity column can contain duplicate values: http://stackoverflow.com/questions/889855/identity-column-in-sql-server/889863#889863

Answer 91

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

Answer 92

That ASCII was stored in a different way to binary

Answer 93

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.

Answer 94

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.

Answer 95

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

Answer 96

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.

Answer 97

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

Answer 98

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.

Answer 99

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

Answer 100

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

Answer 101

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)

Answer 102

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.

Answer 103

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

Answer 104

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

Answer 105

Learning regular expressions will save you time

Answer 106

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

Answer 107

That's its a 9-5 job

Answer 108

That C++ was the coolest language out there!

Answer 109

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.

Answer 110

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

Answer 111

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.

Answer 112

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

Answer 113

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.

Answer 114

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.

Answer 115

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

Answer 116

That IDEs would get faster.

Answer 117

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

Answer 118

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

Answer 119

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.

Answer 120

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.

Answer 121

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

Answer 122

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

Answer 123

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.

Answer 124

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.

Answer 125

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.

Answer 126

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

Answer 127

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

Answer 128

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

Answer 129

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

Answer 130

That ASP.NET was so complicated it's not worth learning... oh wait, that one is right.

Answer 131

That I was a good programmer!

Answer 132

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

Answer 133

That managers know what they talk about.

Answer 134

I thought writing good enough software is an easy task

Answer 135

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.

Answer 136

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

Answer 137

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.

Answer 138

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

Answer 139

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

Answer 140

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

Answer 141

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.

Answer 142

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

Answer 143

That I would ever become wealthy programming software for someone else

Answer 144

That marketing guys care about what you do.

Answer 145

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

Answer 146

That the number of sides of a coin isn't 10.

Answer 147

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

Answer 148

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.

Answer 149

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

Answer 150

G'day,

That I'd be just designing and writing code.

No requirements gathering, documentation or supporting.

cheers,

Answer 151

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.

Answer 152

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.

Answer 153

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

Answer 154

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.

Answer 155

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

Answer 156

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

Answer 157

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

Answer 158

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

Answer 159

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

Answer 160

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

Answer 161

The specs are complete and suffient

Answer 162

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!

Answer 163

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.

Answer 164

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.

Answer 165

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.

Answer 166

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

Answer 167

That I need to define all the variables I'll use in my function in its beginning (Pascal style).

I used to believe I need to think about ALL the resources to be used by my function and define them before I start coding, this is probably because my first language was Pascal where that's the requirement. Then when I moved to C, I would define temp variables that are used only within loops outside those loops, disregarding in-loop scope, just so that "everything will be defined in the beginning".

It took me several years to understand that defining all the resources in advance is not a holly cow, and that scoping is by itself ultra important to code readability.

Answer 168

That other people would be as bothered by known bugs as I was, and would make fixing them a priority over project work.

Answer 169

That my schooling would prepare me for a job in the field.

Answer 170

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.

Answer 171

That I wouldn't need to rapidly refactor my Object oriented code. Martin Fowler finally opened my eyes.

Answer 172

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

Answer 173

That tests were just another method of procrastination.

Answer 174

That learning the language is just learning the syntax, and the most common parts of the standard library.

Answer 175

I thought "duck typing" was actually "duct typing" when I first heard of it, similar to the way people often say duck tape. "Duck typing" just sounded wrong, while "duct typing" made a weird kind of sense (cobbled-together types).

Answer 176

That programming is for juniors and that the best project managers are people who can’t program.

Answer 177

That an html element id and name attribute where interchangable.

It turns out that elements with 'name' attributes are related/used.referenced for POSTs etc and 'id' attributes are used for DOM reference.

Answer 178

I was convinced, for at least 6 years, that every problem had exactly 1 solution.

Utterly unaware of multiple algorithms with differing complexities, space/time tradeoffs, OOP vs. Functional vs. Imperative, levels of abstraction and undecidable problems. When that blissful naivety broke, it opened up a world of possibilities and slammed the door on simply sitting down and building things. Took me a long time to figure out how to just pick one and run with it.

Answer 179

That I could convince traditional procedural programmers of why OOP oft-times provides a better solution.

That is, a language that describes the world needs the ability to describe complex objects and their relationships.

Arguments usually included nonsense about abstract classes, which I responded to with "not all OOP programmers are fresh out of Uni and still obsessed with abstracts". Or the classic, "there's nothing you could do in OOP that I couldn't do with strictly procedural programming", which I usually replied to with, "It's not that you could, it's whether you would if you had a more extensive toolset".

I've learned to just accept that they don't see the world through the same lens I do.

Answer 180

That you never finish the project you didn't start.

Seems really stupid but I put off so many projects because the scale was simply overwhelming. Having just finished a monster of a project I realized I never would have started had I realized the scope of it. In reality though, even the most complex system is pretty simple when broken into discrete and defined pieces. Yet looked at on the macro level it is quickly overwhelming.

Answer 181

That PHP's mysql_fetch_row was the only way to retrieve data from an executed SQL query.

Honestly - I programmed an entire web application without using mysql_fetch_array, and had to change bunches of numbers every time I wanted to change the function to add an extra column.

Answer 182

That Internet Explorer 6 box model is an evil dumb idea MS came up with only to break compatibility with other browsers.

Lots of CSSing had convinced me that it's much more logical, and can make the page design maintenance (changing blocks paddings/borders/margins) much easier.

Think of the real world: changing an A4 page paddings or borders widths doesn't change the page width.

Answer 183

I can read SO and get any work done.

Answer 184

That simplicity almost always beats complexity. KISS - Keep It Simple Stupid rules.

Edit: As Georg states below I got this one reversed. My mind must have gotten lost in the replies. Simplicity almost always makes your code better if used correctly.

Answer 185

That bytecode interpreted languages (like C# or F#) are slower than those reset - button - hogs that compile directly to machine code.

Well, when I started having that believe (in the 80s), it was true. However, even in C# - times I sometimes wondered if "putting that inner loop into a .cpp - file would make my app go faster").

Luckily, no.

Sadly, I just realized that a few years ago.

Answer 186

That procedural developers/programmers unfamiliar with SQL and relational databases don't need any formal training or understanding of how to work with and or use SQL and that a quick read of something like SQL For Dummies is enough to be sufficient in working with Relational databases like Oracle & SQL Server.

Far too often many errors in applications dealing with data stored in a relational database like Oracle and SQL Server are caused by a lack of understanding or how to use the langauge of relational databases; SQL.

I used to work for a software vendor who had the mentality that all a developer needed was the SQL For Dummies book or something similiar and they would be fully equipped to handle any relational database issue. Now that the clients of this vendor have databases measuring in hundreds of gigabytes this lack of SQL knowledge is coming back around in a negative way. It's not just bad performing lookups and or updates and inserts that are a problem but the actual design of the database itself that is the real obstacle.

All of that could have been avoided and resulted in far less costs now if at that time the development lead would have treated SQL and relational databases with the same leve of respect that they did with the langauge they built the application with.

Don't dismiss SQL as unimportant because it WILL come back to haunt you eventually. You may be able to get away with it for a while, even years but you will eventually hit that breaking point where you can't progress without a complete re-design of your database and that is when the costs will be highest.

Answer 187

That....who needs JUnit testing when breakpoints are effective? (when testing applications in debug mode). I realised later why....

Answer 188

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

Answer 189

thread = process