What are some programming problems you initially get WORSE at?

Question

In programming, as many professions, there are mistakes you'll make now that you may not have made as a beginner. For instance, consider pointers:

In C++, is there any difference between arrays and pointers?

The beginner will say yes, they are two completely different concepts, and treat them as such.
The intermediate programmer (having learned that arrays are pointers internally) will tell you no, they are the same thing, and may miss some crucial bugs by interchanging them all willy-nilly.
The expert, however, will again say they are different things (ex. see here or here).

What other questions/mistakes are like this?

Answer 1

Should I use PHP to develop a small web application?

The beginner will say yes, since PHP is widely deployed and easy to get started with.

The intermediate programmer will say no, since the language has an inconsistent (some would say ugly) syntax, and is notorious for security issues when not configured properly.

The expert will say yes, since a PHP environment can be configured to be relatively secure and the language supports well-structured code if the developer knows how to organize it properly. Most importantly, the project can be completed quickly and deployed with minimal hassle.

Answer 2

Take a look at this code:

x = x + 1

As a beginner, I said that this is mathematical nonsense since there is no x which is it's own successor.

Afterwards, I got used to this notation and intuitively interpreted it as an assignment (x becomes x + 1)

Now I'll again say it's mathematical nonsense and therefore stick to functional programming, where immutability counts.

Answer 3

In C and C++:

const int* vs. int* const

The beginner will simply not use const.

The intermediate will write const int* and, giving themselves a false sense of security, may accidentally overwrite the pointer (for instance, the common mistake of = instead of ==)

The expert will know that const int* is a mutable pointer to a constant value; int* const is a constant pointer to a mutable int (to get a constant pointer to a constant value, use const int* const!)

Answer 4

Not really a question, but a behavior

Over design and making ie quasi classes in OOP

The beginner try to use as little fancy design as possible, learning the ropes. Short way from A to B.

The intermediate developer will start to create more and more quasi classes and over design in every new project. Believing complex is better. Long way from A to B.

The expert has get to a point where most projects are re-writes of old projects and now skip the excess classes and design better knowing where to put the flexibility needed. Short way from A to B.

Answer 5

I'm sure I'm not speaking for other developers, but at the moment I'm mostly working in a language I'm extremely comfortable in, doing tasks that I know how to do really well. Because of this, design and programming mistakes are significantly reduced, so I'm finding a rising proportion in bugs are due to simple typos. You could say there's a bug between my brain and the keyboard, i.e. my clumsy fingers.

Answer 6

When it comes to fixing and finding defects/bugs:

• Over-analysing

When you have enough experience in debugging(but not really enough), then even for the most simplest defect, you ignore simple solutions("No way..how can it be so simple") and keep on over-analysing and finding complex solutions. Sometimes though, finally, you end up with the initial simplest solution.

But as you get really experienced, you start repsecting simple solutions and understand the elegancy in simplicity!!

Answer 7

Using frameworks

The beginner will say "Definitely. They make everything much easier. I use it for everything. I can make a hello world app in ten seconds. I just need to ship it with this 150 mb framework. No problem."

The intermediate will say "I don't use them at all. How are you ever going to learn programming if you just copy and paste? Also it bloats things."

The expert will say "I use it in some parts of my application. But just a few selected modules, which I've slightly altered to fit my requirements and reduce bloat."

Answer 8

The young coder writes simple, straightforward code to avoid making mistakes.

The wicked coder shows his knowledge and expertise by wringing out as much functionality as possible from each character of code.

The wise coder uses the language effectively, writing code that is clear, concise, efficient, and maintainable ... generally favoring clarity and maintainablilty after supporting wicked code.

Answer 9

Difference between Class and Structure ?

EDIT:

First of all this is entirely language dependent. so may be someone don't want to agree with me.

Beginner:

Structure member are public in default and class members are privare in default. (I know only this difference at the beginning of my education.)

Intermediate: (Something like this)

• A structure can't be abstract, a class can.
• Classes are used for large amounts of data. Structs are used for smaller amount of data.
• Classes could be inherited whereas structures could not be inherited.
• The structures are value types and the classes are reference types.
• A structure couldn't have a destructor such as class.
• You cannot override any methods within a structure except those belong to type of object.
• A structure couldn't be Null like a class.

Expert:

From OO perspective, there are no difference. From technical point, there can be many differences but that depends on the language. Ignore Structure.

Answer 10

A user calls and complains about an ugly bug he just discovered!

Junior: What? Bug? Where did it come from? Don't worry, we'll fix it quickly.

Experienced: Bug? What bug? Okay, it's a known bug, don't worry, we'll fix it soon.

Senior: What bug? All right, it's a known bug, don't worry.

Answer 11

Dynamical memory allocation in C++.

The beginner won't know about it.

The intermediate will write code with memory leaks or without exception safety.

The expert will know the proper use of smart pointers.

Answer 12

The beginner will have heard of and maybe even used version control (CVS/SVN/git etc). They are only learning of build engineers and are hearing for the first time the concepts of release management. They also are reluctant to do frequent and regular checkins.

The Intermediate engineer will know more than one version control systems, know what build engineers do, know the value of logical commits, and are curious of DVCS like git and Mercurial and why they are useful. They will also know the value of clear and descriptive commit messages.

The expert engineer has lived through more than one manual merges (and will do everything in his power to reduce the need for merging), knows the pitfalls and uses of branching and merging, knows when to use SVN vs Mercurial, knows use of tools like Araxis Merge, and unless he is starving (and has already chewed and eaten his toes), will not want to work at a place that uses VSS for source control.

I know I am dating myself with this, but you don NOT want to use VSS.

Answer 13

Should I read the documentation?

The beginner: yes, I know nothing.
The intermediate: no, I know it.
The expert: yes, I know how much I don't know.

Answer 14

The beginner knows nothing of design patterns, so never uses them.

The intermediate can name every design pattern there is to know, and will suggest one of them as a solution to any problem - he thinks in terms of design patterns.

The expert will use a design pattern when it is called for, but this is the (fairly rare) exception rather than the rule - he thinks in terms of coherent units (such as modules and classes).

Answer 15

The beginner will try to google for a solution in vain

The intermediate will not google and try to code himself

The expert will google the solution in no time (but then will spend time reading stackoverflow!!)

Answer 16

When you run into a bug in a framework your application is based on:

The beginner won't fix it, because it's difficult and they're scared to delve into framework code.

The intermediate programmer will dive in and create a large pile of code to replace the allegedly buggy framework component. They'll have fixed the immediately observed bug.

The expert will try to find a solution that works with the framework, not against it. Sometimes they'll leave the original bug unresolved when they know that to fix it will leave them open for more severe bugs down the line.