Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Many questions here about learning new things. But what about unlearning?

When we used to develop software 10 or 20 years ago very differently, we counted RAM in bytes, libraries were very rare, IDE was an unknown word and Merise was king.

What should we unlearn today? What bad habits we should get rid of?

EDIT: unlearn doesn't mean forget. Rather to use old techniques that was useful in the past, use the new technologies (such as GC for memory management). But your past knowledge will always be useful today.

share

locked by World Engineer Jul 23 '13 at 18:50

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as primarily opinion-based by Karl Bielefeldt, Robert Harvey, MichaelT, BЈовић, Bart van Ingen Schenau Jul 23 '13 at 9:40

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

19 Answers 19

up vote 6 down vote accepted

Everything

Following the vain of the previous answer, I believe all habits are bad and boxing. Falling into any sort of habit can be construed as a lack of creativity which will stifle your perception of new technology or options.

Learn patterns, don't make them a habit. Identify ones that work well and then apply them to new requirements. Don't put yourself in the mindset that every application must use MySQL, PHP with Zend, Apache 1.3, and Cent 5.4. What about CakePHP? CodeIgniter? How about using a different storage engine? Different language even.

The beautiful thing is most of the technology or paradigms in use are interchangeable. I can use ROR with MongoDB and Ubuntu for a basic CMS. I can set this up on an EC2 instance or an Ubuntu dedicated machine. I can serve content with a CDN and write backing scripts in Python. Add Redis for in memory session management with a ant script to deploy. These modular components allow you to have a diverse skill set that is necessary to be ahead of the curve.

share
6  
Really? The problem with avoiding all habits is that you have to think through everything in great detail every time you do it. For example, could you really use a QWERTY keyboard if you hadn't formed habits? Are those habits really a bad thing? The trick, of course, is to replace poor habits and retain beneficial ones in the light of our developing understanding. –  Kramii Oct 29 '10 at 15:59
1  
-1: This devalues experience. Likewise, the 'beautiful thing' reminds me of classic 'enterprise' solutions where a .net front end, connects to a java back end, which writes documents to an excel file, uploads to an ftp server via a windows service written in c++ and another windows service written in vb.net that parses the excel file into an xml doc and inserts it into a datbase. –  Steve Evers Oct 29 '10 at 16:50

Unlearn the concept that well-written code is also well-commented.

I don't have a problem with any technology or technique in use today enough to say that we should all unlearn it. But this habit of writing comments to document and explain our code is so deeply (and unjustifiably) embedded in our profession. My annual performance review questionnaire has a question: "Writes well-commented code" - "strongly agree", "agree", "neutral", etc. I have convinced my manager that the correct answer to this question is "N/A", but how many others have come to the same agreement?

I just opened a random file in one of the two IDEs that were open on my screen at the time of reading this question and it took me a less than a minute to find this:

        /// <summary>
    /// This method creates a foo depending on the bar name.
    /// </summary>
    public static Foo GetFoo( string barName ) {
                ...
    }

Let's unlearn this.

Some reply is in order after 9 votes, 6 comments, and 18 votes seconding those comments.

I am protesting against the comment-favouring bias that we programmers have. I'm very concerned where, in the words of Robert Harvey, "erring on the side of more comments" may lead us.

Let's start with Greg.

  1. Why did Greg's employer hire non-programmers to do a programming job?
  2. If the job was to write a program in Perl, why give it to people "with only passing familiarity with Pascal?"
  3. If the intent was to hire people with a skill gap and train them (by taking Perl classes, lunch-and-learns, pairing with experienced Perl developers, frequent code reviews, etc.) so that they didn't have to write unconventional Perl code and write comment explaining the intent to senior Perl developers -- none of this training apparently took place. Why?
  4. And I am not making Greg's company solely responsible for the training; if these people signed up for the job, they made a commitment to learning a new skill, programming in Perl. Were they actually expected to act that way? If not, why? Did they understand that? If not, why?

You can see many problems in Greg's company right away, but Greg didn't say he'd kill to solve any of them. Before saying that, before probing root causes, we, programmers, are much more inclined to say, "if only this code had more/better comments..."

To Adam and @bigtang: I love good comments, too. The problem is, the vast majority of comments aren't good. There is lots of waste for every non-trivial piece of code with a good comment explaining the non-triviality. Adam, what if your business analyst needs to state those "unstated assumptions" and discuss them with a customer? Have your QA people talked to you about them? If you write a code comment about it and check it in and you are the only one of the four people (developer, QA, BA, customer) who has access to the source code, the chance is almost 100% the conversations will never happen.

We tend to see comments as assets, harmless in the worst case, and never as liabilities. Let's take a look at this thread. The original poster: "They're bulky and I'm always forgetting to update them. Do you [still] recommend using them?" The original poster is clearly concerned that they are a liability. But this opinion - "Use them as much as possible", it's so cool that they show up in IntelliSense - is a runaway favourite (60 upvotes).

share
8  
I am currently rewriting some applications that run in our production environment that are largely uncommented. They were written by non-programmers; Imagine Perl code written by someone with a passing familiarity with Pascal. I'd kill to have comments in it. When I write I comment things that are not obvious. Trivial commenting is a waste of space and mental processing. –  the Tin Man Oct 29 '10 at 14:04
3  
It's hard to predict what the level of expertise is of the programmer coming after you. Consequently, I err on the side of more comments rather than less, although I do tend to keep my comments above the class or method declaration. Very rarely do I put a comment in my actual code. –  Robert Harvey Oct 29 '10 at 14:06
5  
The example that you have given is not well-commented by my definition. Comments that simply restate what is perfectly obvious are of no help. Well-commented code provides information about what is not obvious about code: external dependencies, unstated assumptions, the reasons that a block of logic is constructed the way it is, places where code will change if external systems change. I LOVE it when an engineer uses comments to point to the external project documentation that was the basis for a particular coding decision. Learning how to document well is something to learn, not unlearn. –  Adam Crossland Oct 29 '10 at 14:20
3  
-1 Good comments are extremely useful - the code snippet above does not represent good comments and I agree we should unlearn that, but comments not be useful? Couldn't disagree more. –  bigtang Oct 29 '10 at 15:00
3  
+1. I'm not anti-comment, but I am anti-non-self-documenting-code. Bad code needs more comments than good code. Your code should have as many comments as it needs, and no more. bool value = true; // sets "value" to "true" Ugh. –  user2458 Oct 29 '10 at 22:15

You don't need to custom build everything.
Look to see if there's an off the shelf product that will do the same thing. (example, we build a time management system a few years ago when we could have just bought one. Would have been cheaper in the long run.

Your time can be used to code other things.

share

Coding standards designed to format printed code

Apparently, some of us used to print our code. You know, to paper. Really. I have no regrets about being "born too late" for this one. So if your coding standards (personal or corporate) require formatting lines to fit on a printed page, please just think of the trees.

share

Inventing the wheel

Back in the day, there were no easily reusable objects or online services we could just plug into, so we had to write our own before we could start tackling the real problem at hand.

It's hard always remembering to check whether someone else has solved a problem before setting out to do so, epecially when some part of your brain actually enjoys it.

share
1  
-1 I could not disagree more. If anything, its one trait more younger developers should aquire. "Re-inventing the wheel" is how we get better wheels. Its leads to a better understanding of one's profession and more innovation. –  GrandmasterB Oct 29 '10 at 22:03
1  
@GrandmasterB - While I agree that it's a noble cause for the greater good of software, I can't think of many cases where it's a "good habit" to reinvent the wheel. I certainly wouldn't want a programmer with that habit on my team. –  realworldcoder Oct 29 '10 at 22:09
3  
There's a time to use canned solutions, and a time not to. The problem is the 'dont re-invent the wheel' mantra has been burned into so many programmer's heads that you see people going out of their way to find and impement canned systems that they could have re-created in a fraction of the time if they just had the intellectual curiousity and problem solving skills to sit down and figure it out themselves. Myself, I wouldnt want to work with programmers like that. –  GrandmasterB Oct 30 '10 at 22:18

Hungarian Notation

There's nothing wrong with "m_" for member variables but "m_sztrfgpCompanyName" outside of C or arguably in C programming it's overkill. That's what IDE's and modern compilers are for. (And yes, I know of all the dangers of void*, see "arguably")

share
2  
I've seen so many people complain about Hungarian Notation, but I am indifferent. Inconsistency in naming is far worse than any annoying naming convention. –  Stargazer712 Oct 29 '10 at 21:24
3  
Who says there's nothing wrong with "m_" for member variables? –  Kyralessa Oct 29 '10 at 22:31

Design by Database

If you're producing a business application of significant complexity, and the first thing that you do is produce a big chunky database schema -- instead of focusing on business logic, domain design, or service level interactions -- then please take that finished schema, wad it up, and eat it. Because that is about as much worth as you will be able to extract from that document, once you realize that an application logic should not be dictated by database structure. In fact, the database structure, should only be dictated by application logic, and only when you have a clear idea of the domain (the problems your application needs to solve, and how to solve them). I would go so far to say, that I would rather see a working mock of the user interface before I see a database schema, or at least a UML diagram of the major components and classes.

Disclaimer: Of course this is a generalization that does not apply for ALL applications.

share
1  
This. Oh I must write more characters? Ok. This. –  Matteo Mosca Oct 29 '10 at 14:42
7  
Meh. Why would anyone create a database schema without knowing anything about the problem domain? And once you do know the problem domain, mapping out a database schema can be a logical first step. –  Robert Harvey Oct 29 '10 at 15:25
9  
-1. A schema should be one of the FIRST things created in an application. If you can't define your data and your interfaces to it how can you possibly properly develop any other working model? Those who think a schema will restrict them in any way, maybe focus and perfect the way you define your schema vs. thinking of it as a static store? –  Xepoch Oct 29 '10 at 17:01
1  
Well, I'm assuming that much of the preparatory work you describe has already been done, before a database schema is attempted. But none of the preparatory work needs to involve code, and the database design can always be evolved. My concern would be those people who think they can "grow" a database structure from the Entity Framework, for example, without fully understanding the implications at the database level. –  Robert Harvey Oct 29 '10 at 17:10
3  
@robert I would vote your comment up a million times if I could. There are many more considerations in database design than what the application needs. And it is far more difficult to refactor a database and performance is critical to databses, so database design must happen up front. –  HLGEM Oct 29 '10 at 18:51

Single-Threading. Get used to the fact that your program is no longer a "main" function that calls other functions; more likely, your code will be compiled to some classes that live in some framework, which might create some objects, and call some methods, in parallel threads whenever you expect it least. A global static variable is no longer just "ugly" and "hard to maintain", but rather, it probably makes the program crash because of race conditions.

share
2  
I can't believe this isn't higher voted yet. The conceptual switch from single-threaded to parallel programming is probably one the most difficult but most essential changes in the modern programmer's mind. –  CodexArcanum Oct 29 '10 at 20:06

I have a couple...

Unlearn Database first design. As mentioned above.

Unlearn BDUF - big design up front.

Unlearn functional & design specs. Functional specs should go away. They're always outdated by the time something is relaesed and what is produced is almost ALWAYS wrong.

Unlearn well-written code is well-commented. This is wrong, as many are finding out. Comments don't mean anything if they're not well written, and often they're not useful anyway. Especially with a changing code base. If anything write tests, do TDD, and forget the in code comments.

Unlearn XML for everything. It just adds too much overhead to most things. XML is great for certain things, but as JSON and other technologies have proven, it isn't for everything.

share

Cobol

I had suffered from people using Cobol mentality in other paradigms. I had to write it once in my life somewhere and this question helped a lot. I am talking about writing Cobol in other environments. In the country of origin there was a word for it: "Cololeiros" which initially I thought was a form of dance...

There is a nice story in "Code Complete" about the same in Fortran.

share

How to overengineer everything for future-proofness. I get the impression that heavy OO engineering for every conceivable change was the paradigm of the late '90s. Nowadays we realize that you can't plan for every conceviable change and every bit of futureproofing against changes you anticipate makes changes you don't anticipate that much harder. It only makes sense to future-proof your code against a few specific changes that are especially likely to actually happen.

share
2  
Yes, sir! I could not agree with this more. In my experience, the more future-proof a system is, the more likely it is to fail in the present. –  Adam Crossland Oct 29 '10 at 15:55
2  
I am not sure I agree with this one. I think good OO design through encapsulation and separation of concerns (making each component general) is a great way to future-proof, but it definitely shouldn't be taken too far. –  jnylen Oct 29 '10 at 16:28
2  
Thus the emergence of the YAGNI principle –  BlackICE Nov 29 '10 at 19:24

Declaring all variables at the top of files

This may have been good practice in the days of primitive compilers, but is not required in modern programming environments. Nevertheless, a lot of programmers who have been around for a while seem to do this without thinking.

My preference is to see variables declared as close as possible to their first use.

share
5  
I remember seeing this recently and Resharper had greyed out half of them because they weren't even being used ;-) –  Mantorok Oct 29 '10 at 15:45
2  
Man I wish we could get Resharper where I work. –  jnylen Oct 29 '10 at 16:25
1  
I do this with thinking, though I am an old-timer. I think that it keeps the code organized. Luckily the IDE takes care of indicating which are not used (and all kinds of other great stuff). In Ruby I also declare them at the top, where at least they can be found and the the list trimmed. –  Yar Oct 29 '10 at 17:19
2  
I don't know about this... littering a class with variables everywhere is really messy imo. Bouncing around from declaration to declaration all over the class (especially when you're trying to comprehend it) is never fun. I prefer to read a class and see "Oh, this class makes use of one of these and one of those. Oh, and it defines properties for this and that." –  Steve Evers Oct 29 '10 at 18:54
3  
I completely 100% agree with this, but honestly it shouldn't make a difference. If you have a ton of variable declarations inside a huge method or class, you probably need to look at doing some refactoring. –  Watson Oct 29 '10 at 19:18

Programming isn't always about how quick you can get an application out of the door

I often hear people claim the old chestnut of how much quicker apps were developed and released to customers 10-15 years ago, but unfortunately these people don't appreciate the kind of obligations we as programmers are now under, an app that was banged out of the door quickly was most likely fraught with bugs, security holes, lack of scalability and extremely difficult to maintain by anyone other than the person who wrote it.

It would be great if we could just switch off to the potential 10's or 100's of people who might try and hack our product or not bother to protect all of the personal information in it, or not give 2 hoots whether our colleagues would be able to maintain and extend it, but unfortunately the world doesn't operate this way anymore.

I would like the see the seniors appreciate how much more effort and thought is required these days in order to construct applications and websites.

share
6  
You have a valid point, but some of us old-timers just have a hard time believing FULLY in the 19-layer framework that's in place that causes a 40-60 hours estimate to add an extra field entry on an input page. We get why it takes so long, just very frustrated at programmers/architects who put more effort into their frameworks than solving business problems. –  Xepoch Oct 29 '10 at 15:54

Unlearn your Bias

I can't tell you how many times personal bias gets in the way of the correct solution. Sometimes, inadvertently, I am biased and make sub-optimal recommendations. Sometimes others are biased towards the existing paradigm no progress can be made.

All that said, you need to also know when to stand your ground on your approach (of course in a cool, collected way).

share
1  
For those who keep voting down, pray why? –  Xepoch Oct 29 '10 at 16:57

I would like many engineers to break themselves of the habit of using XML for anything and everything. Perhaps it is just the clients for whom I have worked recently, but I consistently see poor old XML bent, twisted and perverted towards uses that do not suit it.

Specifically, I detest the notion that making a system configurable means loading and interpreting vast quantities of data from XML files at start-up. Rather than achieving the intended affect of adding flexibility and adaptability to a system, it tends to shift too much complexity there and make configuring the system an exercise in spell-casting and black magic.

share
1  
+1. Great answer, though this is just a special case of something more general: en.wikipedia.org/wiki/Inner_platform_effect –  dsimcha Oct 29 '10 at 16:51
1  
What's shameful is that the XML is usually poorly structured, lacks namespaces, or has other flaws that take away all the benefits of using XML. Does your config really need an XML file, or would some simpler text format be enough? I think most people just use XML now because the libraries for accessing it are ubiquitous. –  CodexArcanum Oct 29 '10 at 20:10
2  
+1. Using XML for anything except communicating with another system that only speaks XML is a code smell IMO. –  Mason Wheeler Oct 29 '10 at 22:41

A few years ago I remember someone claiming that developers could now forget all about optimizations like common subexpression elimination in loops, because "compilers are so much better now". It seemed reasonable at the time, but in todays world of interpreters and DSLs, a lot of those techniques are life- (or at least job-)savers.

I'm not really ready to give up on any of my "archaic" knowledge. It lets me take advantage of those old wheels that get re-invented every five years or so.

share
1  
There is the case, at least in Java, of scoffing at people who would concat strings with a plus sign. "That's so inefficient!" And now, with Groovy being taken seriously (which produces MUCH less inefficient code, but efficient enough) we can start to prefer readability over efficiency (in some cases). –  Yar Oct 29 '10 at 17:16

None - Now I know this is going to be a controversial statement, but old technologies and techniques should not be unlearned because you never know when someone might find some old code that you have to dust off and understand and if you don't remember the technologies and techniques that were in place, that code is going to be a mystery.

Likewise, getting rid of bad habits should not be associated with unlearning and old way of doing things. In a lot of cases, I would argue that the old way of doing things might not be relevant, but they were generally done that way because they worked. Remember why it worked and use it to provide suggestions that might be useful to new technologies and techniques - just be sure to try and not force the old way of doing things on new technologies.

Update - With an update to to the question, and update to my answer. In terms of unlearning old technologies and techniques, I think that my original none assessment still applies as in a lot of cases, the old solutions work just as good as the ones based upon new technology and techniques. At the end of the day I think that it all comes down to the right tool for the right job. The age of that tool shouldn't make any difference.

share
1  
Further to your comment, I was reading some comments on the internet a week or so ago that mentioned someone trying to fix a bug in the current Excel build from code written in the 1980s –  dassouki Oct 29 '10 at 12:38
4  
The thing to unlearn is when to use techniques; not the techniques themselves. –  STW Oct 29 '10 at 13:14
1  
Choosing the right tool for the job is important, but many older techniques are actually counterproductive in modern programming tasks. Of course there are exceptions, but there are often good reasons why old-style programming practices have been left behind. –  Kramii Oct 29 '10 at 15:52

C++ as a better C

It used to be that C++ was mostly a better C, but the language has evolved much past that. Fortunately, the people I'm working with also have, but not everybody has. The correct way to write programs in C++ is much different from in C.

share
1  
What if you're writing something inherently low-level that can't use most of the features of C++, but you still want a few of the extra goodies that C++ offers? –  dsimcha Oct 29 '10 at 15:25
1  
My response had nothing to do w/ compiler availability. In embedded systems, for example, it might be nice to have function overloading, default parameter values and stronger typing, but you might not want exceptions due to the overhead, or templates and STL due to concerns about executable size. –  dsimcha Oct 29 '10 at 16:29

The expected rate at which technology changes.

share