What is the most important thing you weren't taught in school?

What topics are missing from the CS/IS education?

Posted so far

  • How to sell an idea


  • Often, good enough is better than perfect.
  • Making mistakes is actually a Good Thing? -- as long as they're new mistakes.
  • If a user can break your code they will.
  • In the Real World? they're all open-book exams
  • Self confidence is way more important in getting ahead than intelligence.
  • Always prefer simplicity over complexity. The best code is the code that you don't write.
  • You never know when you'll meet someone again ... or where. It's always worthwhile to treat people with respect and kindness.
  • Be aware of what you don't know and don't be afraid to ask questions when you need to

Missing knowledge:

  • How to communicate effectively.
  • Lack of source control
  • Lack of Softskills experience
  • How to productize code
  • How to write secure code
  • How to formulate problems
  • How to self-measurement. To evaluate ones true competences and market worth.
  • How to debug code
  • How important is backup
  • How to read code on a large scale (being able to adapt and build upon existing projects)
  • Good Regular expressions comprehension
  • How to teach others effectively
  • TDD/Unit testing
  • Critical thinking
  • How to integrate different skills and languages in a single project

This question has been preserved for historical reasons, but it is considered off-topic, so don't use it as an excuse to post something similar. More info here: http://stackoverflow.com/faq


We weren't taught about source control. Luckily, I had a good mentor who taught me before I finished school and embarrassed myself.


Often, good enough is better than perfect.


It is ok to be wrong, it is ok to make a mistake, it is ok to say "I don't know"


Critical thinking.

I wish more kids were taught how to analyze a problem, how to avoid fallacious thinking etc. etc. I can't tell you how many times I've got caught in the error of "all or nothing" thinking--for example, if we can't fix all the problems with some software we shouldn't bother to fix any of them. I'm sure there is a name for that logical fallacy--I'm sure some bright commenter will tell me what it is. :-) My point is that learning to think critically is a skill that serves any developer well and it isn't taught in any schools that I know of.


TDD/Unit testing.


How to teach yourself.

Often in the real world you will not have the tools/skills/expereince to resolve a problem, that is one thing that the human brain can do that machine's cant. It can figure it out.


Working with large codebases and pre-existing code.


How to communicate effectively.

Getting people to understand you and taking the effort to understand others is critical in all endeavors.


That the real world is unfair.


Making mistakes is actually a Good Thing™ -- as long as they're new mistakes.


How to read code on a large scale.

In the "real world", there is a lot of code that you have to read, understand, build upon, and refactor.

Sadly, most university projects are "start from scratch" type things, which are more the exception than the rule in industry.


Choose your employers wisely.

Bad employers = bad references, which can follow you around forever.


How to resolve a technical disagreement.


In the Real World™ they're all open-book exams, and it's ok to copy from your neighbor. It's more important to know where to look, or whom to ask, than to have all the answers in your head.


You never know when you'll meet someone again ... or where. It's always worthwhile to treat people with respect and kindness.


You can't help learning when you teach. And explaining something to others is an excellent way to find out exactly how well you know it.


How to formulate problems in the form of a problem, rather than in the form of an unimplemented solution.


  • "I need to be able to place my online photos into different directories to organize them."


  • "I need to be able to categorize and organize my online photos."

Only one possible solution which may be difficult to implement depending on design vs. many possible solutions which may be easier to implement or even superior in solving the underlying problem (such as Flickr's tags+sets+search system).

Another example: "I need firewood." (Solution: more firewood.) vs. "My house is too cold." (Solutions: better insulation, electric/oil/gas/geothermal heating, wear a sweater, etc.)


The link between technology and business. i.e. Technology is driven by the business requirements.


How to ask my own questions. Too often in university, you're simply asked to answer a canned question. Sometimes the key to succeeding at something is knowing what questions to ask.


The fact that you're often doing more harm than good by over-commenting your code.

int count = 0;  // variable to store the counter

should NEVER be taught as good programming practice.


To tell hype from substance.

In school/uni I was taught, how great Object Oriented Programming is, and how to normalize data into normal forms for storage in RDMBses, and the value of high-level abstraction which will make Java the last language ever, and how XML will replace all network protocols and configuration files, ...

What I had to learn for myself is how every one of those technologies have their respective place but that none of them is the Silver Bullet.

Non-programmers always know about the next big thing and how it will once and for all magically make complexity go away. You constantly need to remind them, that what looks good in Powerpoint, doesn't necessarilly do so in a source code editor.


That good colleagues is a 90% guarantee that you will enjoy your work, no matter what you do or how you are supposed to do it.


Marketing and sales. Not in the selling-sugar-water-to-tourists sense, but in the ability to effectively 'sell' your ideas to your peer, managers, and customers.


How to teach others effectively.


Paul Graham summed this up well, I think: What You'll Wish You'd Known

  1. Source code control
  2. Unit Testing (testing in general)
  3. Agile Development
  4. Code Commenting
  5. Code Review
  6. Standards compliance
  7. Proper architecture compliance

How to fight fires. In school you always have time to complete your assignments - there is never a time when you have to get something working immediately that is critical to the business. Especially something that you either didn't write yourself or had little input on. The biggest thing about fighting fires is keeping a level head so you can quickly debug without losing it.


Debugging. Real debugging.

If you made it through school you know how to debug your own stuff. But now you a new frontier awaits you when you meet legacy code. Unless you are working in a startup writing all your own stuff, you will come across this problem someday, and when it's bad, it's REALLY bad.

This is because sometimes you will have code that is 5 years old, has major flaws, and has 5 years worth of hacks/workarounds/aborted-attempts/semi-completed-attempts piled on top of it, masking the real problem.

And this is what real debugging skill comes down to... figuring out where the real problem lies, and then figuring out if you are actually have enough time and are competent enough to fix it properly, or at least leave things in a better state than you found it (sometimes leaving comments is the best you can do)


Always prefer simplicity over complexity. The best code is the code that you don't write.


We weren't taught that the consequences of poor quality go far beyond a bad grade!


What people think you're capable of accomplishing is a good indicator of your success.


People skills. Organising teams. All my greatest headaches are nearly always problems of 'soft' skills.

Estimating delivery times (especially delivery as opposed to just feature-complete code), handling difficult customers, organising & motivating teams, methodological questions, estimating process duration, understanding the importance of tests, did I mention ESTIMATION, agile methodology, estimation for agile methodology, considering the unestimatable quality of bug fixing VS the estimatable quality of writing comprehensive unit and acceptance tests before writing the code, understanding when something can be unit-tested or requires integration or functional tests, understanding that ANY technology that makes unit-tests difficult to program is therefore inherently bad (BPEL I'm looking at you!) ... the list goes on.

As a senior developer these are the things that take up my day. Not the purely-technological problems.


"A problem well-defined is half-solved."

So focus on defining the problem, and clearly communicating the problem; convincing others and yourself that there is a problem and that you know what it is.

All this before you jump playfully into "solution space".

I've met people who aren't even aware that they're in solution space, when to them they think they're in problem space.


Not enough emphasis on technical writing.


They never told me that once you build a good application that users love to use you can never escape it.

They also never taught me that the success of fixing a bug after struggling with it for hours on end is much sweeter than getting it right at first. It is also addictive.


Regular expressions.


At school plagiarism is bad, at work plagiarism is good.


refactoring, and build only functionality that has a use, don't build more than that for some abstract completeness concept. Every line of code has a corresponding percentage chance it will contain or introduce a bug.


"There most certainly is such a thing as a stupid question."


Social Skills

Closely related to communicating effectively are social skills in general. After you graduate, you?re not going to be dealing with your high school or frat buddies anymore.

You?ll be dealing with many people from different backgrounds, countries, and more importantly different age groups, so it would be wise to learn how to socialize outside your own group.

Cut the slang. Learn to respect customs from other countries. Learn how to listen ? few people do. Learn when to speak and when NOT to.

Build rapport. Learn the art of networking ? that?s key. Networking is a big skill that?s not taught enough in schools. Learn to compliment. Mingle. Make small talk.

Learn to approach people ? that?s another big skill. Most people don?t have the guts to take the first initiative and introduce themselves. Be the big man. Take the first step.

I missed all these things. :-(


Just how important being able to effectively communicate really is.


How to survive and succeed in the ever changing technological landscape?


The majority of people are idiots and liars


The most important thing I've learn is that knowledge need to be up-to-date in software and that I'll need to learn for the rest of my life :)


The skills to keep on learning.


Real world is dirty. Problems are hard to define and understanding them thorougly is a big part of a solution. Tech knowledge is usually not enough, solving real-world problems requires a lot of communication and improvisation skills.


Curiosity is a Good Thing . . . no one really likes cats anyway.


How to conduct myself in a job interview


Confidence. You can be white-hot at what you do but if you come across as a bumbler then you won't get far. There are plenty out there with lesser talent who sell themselves more confidently so they get the gong.

Not to be confused with arrogance.

  • How to work as a team
  • How to maintain old code
  • How to debug
  • How to productize code
  • How to write secure code
  • How to write portable code

How important is backup.


Here are the most important wrong things I was taught in high school + college:

  • I was taught that my efforts were mine alone. My successes were mine. My failures were mine. The same applied to others. Being an intelligent island was what was important. Cooperating and networking with others was irrelevant and even potentially detrimental.

  • I was taught that it was ok to be shy and not want to speak in front of others.

  • I was taught that my interpersonal skills were of far less importance than my mental abilities.

  • I was taught that I would be doing interesting and mentally taxing tasks all day.

  • I was taught that being smart and having "potential" would get you into a good school even if your parents didn't have much money. And it would especially be enough to get you a good job that you're able to do, even if you don't yet have the experience.

  • I was taught that proper grammar was important. If you don't know exactly how to avoid sentence fragments and comma errors, you will be looked down on because everyone else knows this and follows it closely.

  • I was taught that higher math was highly valued and that you'd use at least some of it after high school.

  • I was taught that learning the arts adds little value to life since you can't turn it into income.

  • I was taught that the quadratic formula was worth studying for a month or two but compounding interest was only a formula worth memorizing for a few days.

  • I was taught that the most competent person would be in any given position in business. The unqualified would be kept out of a position.

  • I was taught that every smart woman must pursue a BA and a career. What confident self-assured woman could possibly want to be a stay at home mom? At best, it's weak and ambitionless. At worst, it's squandering the gains made by hard-fighting sacrifice-making previous generations.

  • I was taught that a textbook any older than 2 years is obsolete and must be replaced.

  • I was taught that Lotus was the future that I positively must learn if I am to have any competitive edge in business.

  • I was taught that writing lengthy papers was a valuable skill. The more advanced courses had longer paper requirements so it only stands to reason that longer = better.

  • I was taught that there were no long term effects to any of my actions. If I failed a class or simply lost interest, I would only take a small hit on my GPA and in many cases, I could take it again without consequence.

  • I was taught that choosing to take Calculus is more important to your life than choosing a "marriage and family" course.

  • I was taught that all projects could be completed in 5 months or less and would never have to be maintained -- by myself or by others.

  • I was taught that school taught the important things. By corollary, the items never even mentioned in school must be trivial: writing a resume, establishing good credit, how to dress and act on an interview, balancing a checkbook, determining the long-term impact of purchasing something on credit, taking initiative in a group, negotiation, diplomacy.

  • When science and religion disagree, if you are in my urban highschool, if you take science's side then you are objectively right and everyone will come to agree with you. And if they don't, their feelings aren't worth considering. Moreover, if you ostracize them, there's no real-world harm that can come back to you if you attack their views. It's not like someone else can affect your island.

  • When science and religion disagree, if you are in my rural university in the southeast, if you take religion's side then you are objectively right and everyone will come to agree with you. And if they don't, their feelings aren't worth considering. Moreover, if you ostracize them, there's no real-world harm that can come back to you if you attack their views. It's not like someone else can affect your island.


how to ask your boss for a raise.


How to effectively communicate to non-programmers and design a program for what they need, not what they want.


Don't discard your mistakes -- they may be more valuable than your successes, even if only as bad examples ... or SO questions!


That most things you learn will be obsolete in 5 years. I haven't programmed in FORTRAN using a deck of punch cards since I left college.


Requirements gathering. If you show up at your first day of work expecting to be handed a program description that a TA could grade you on how well you followed, you're going to be in for a surprise. I know I was.

"Well, how do you want it to work? What do you mean 'I don't know'?!?"


All the nuances and issues that arise between 100% academically correct and 100% employer correct:

100% academically correct will get you a good grade. 100% employer correct will get you a good paycheck.

How to cover your ass when instructed by time constraints to do something that is not 100% academically correct.


if a user can break your code they will. Users of your applications will break it if you leave a hole. Users of your code will use it wrong if you let them.

Make sure what you write works, because if it doesn't then you'll pay for it.


Nobody will tell you that as an adult you will have a choice on working at things that make a positive difference or just taking any opportunity that puts food in your mouth, and the ethics of the goals your workplace sets and the ethics of the people around you should be a fundamental criteria, because otherwise you will find your work put to ends you don't want to admit.


How to debug code. From my first year as a professional programmer, I keep marveling why they did not teach us this in school.

This could have fit nicely into a course on software quality assurance or engineering (SQA/SQE) as a big chunk of it.

Beyond "putting print statements" in our code, instructors taught my fellow students and I nothing about debugging code.

They taught us how to do anti-bugging but not debugging.

The debugger is a vital tool in both fixing problems and inspecting code to understand it and look for problems.

These days, with continuous integration practices/mechanisms, widely available free tools for doing static code analysis to check for errors and compute complexity/instability, help automate unit and even functional testing - and all sorts of other things that drive quality out and bugs up - a one semester course on these things would be powerfully useful for coursework and future professional work.


That passing these courses have very little to show how you will perform in the real world.

More important concepts:

  • being able to work together with other people. (ie dont lock yourself in a room writing code)
  • memorizing something that is in a book is pretty much useless. (the index is your friend)
  • if you know what you are doing the language/os being used is close to irrelevant

Self learning.Educate yourself.


The most important things that I didn't learn in school couldn't really be taught there anyways.

  1. The people around you, in particular your family, are more important than your work, your ideas, and what you think is your "future". There is no future, only an ever-changing now.

  2. Your work is more important than your salary. By this I mean what work you do, who your boss is, your corporate or non-corporate work environment, co-workers, hours, commute, life-work balance. Salary should be an afterthought - if you are doing work you enjoy, then it is probably fun and challenging and will be paid what it is worth.

  3. Work determines life outside work. If you are working stressful hours, that will determine what your hours outside work will be like - stressed out, or recovering from stress. if you are working long hours, then your life outside work will be short. If your work is not well-paid .. then your life outside of work will be frugal. But it's better to have lots of stress-free hours outside of work, having fun frugally, than a few stressed-out hours with lots of money.

  4. At your funeral, no one's going to remember or care that you were a great student, whiz programmer, or great worker. They will remember what you were like in your personal interactions, the times you were kind or understanding, and the fun you had together, and hopefully how much you loved them and how much they love you.


Critical thinking. It's not the same thing as problem solving but often it's confused with it. We're just given assignments and told to do it, we're taught data structures as if they were formulae, and we're taught OOP just because it's the thing in the industry at the moment. Teachers just assume students will "pick up" critical thinking skills as they do the work. I don't think that's a good assumption to start off with.

I think the worst thing is when university courses over focus on the industry. For example, one of my courses was "LAN Principles". In reality, what is was, was what Cisco Systems wanted potential employers to know. I don't want to memorize what key combination does what to the Cisco console. For certifications, that's OK, but for University that's bullshit. True Universities don't churn out lemmings for the industry - they create people who can think for themselves.


One thing that I wasn't taught in school is that not everything they teach you in school is a good idea, or even correct.


This is a programming site, so I'll talk about my CS education- I wish someone had said: "Hey, all this academic maths stuff like big-O notation that you think is nothing to do with the real world will actually turn out to be very useful if you pay attention to it. Except for your Formal Methods Of System Specification course, that really is the waste of time it seems like."


How to speak, discuss and correct or be corrected by my boss.

I have been stressed out because I don't know how to talk to my boss (specially when I think I'm right, and he thinks he's right)


How to make software to sell.

We were taught all about how to write great software in the context of an existing business. However, it's quite another animal when you're starting a business with your software.


Self confidence is way more important in getting ahead than intelligence.

I felt kinda ripped off when I figured that one out. All that effort lavished into learning things...


Self-measurement. Specifically, how to identify my weaknesses, my strengths, and my market worth.

You can easily tell if your haircut looks bad. Unfortunately, there's no mirror for our personality or work patterns.


Be aware of what you don't know and don't be afraid to ask questions when you need to.


I wasn't taught how thankless a job programming is. Even your fellow programmers often don't know, don't understand, and therefore can't appreciate what you did. So in a comfy corporate programming job, there is no risk-reward. It's an entirely different game showing business value out of all that difficult coding you did.


Actually, i have learnt everything about programming all by my self. But if you let me talk about my complete education life, i would be glad if someone let me know how to learn something! if you learn to educate yourself, you can learn anything you want.

We have a saying says that "There is no age to learn"

Since i have studied in Turkey, that may not apply you :)


Successful are not the one who know better but the one who present better.


I came out of an IT program with no idea how to structure complicated web applications. Many of the courses were centered around PHP, but I had no MVC knowledge, no best practices for where to store certain types of files (templates, css, images), no idea how to organize files logically. It has come to me over time, but some help would have been nice.


Project management.


How to work on a mature application -- that is, when to make wholesale application changes (or lobby management for the time to make them), as opposed to plugging holes in your application.

At my first job, I was handed sole ownership of an application over 20 years old, and I had no idea what to do with myself. I had real choice anxiety about the changes I made up until a few months before I left the company, because I couldn't pace myself or prioritize issues. The naivete of being so young and "knowing" how things "should be" often left me feeling that everything was of the utmost importance.


How to write a debugger or at least how does it work


How to learn effectively (based on cognitive science).


That a lot of what you just spent four years learning became obsolete eight years ago.


The developers (people?) who claim to know the most tend to understand the least.


salary negotiation


That unlike school and if you played sports, there is no such thing as good sportsmanship. Two people going for the same job, there will be blood. The person sitting in the cube next to you WILL throw you under the bus at review time, and when projects come late your boss will sacrifice you up to their boss in order to save their own arses.

It's nice that we teach little kids that all is fair, and that we can't keep score and that despite the fact that the other team kicked your ass 10-0 you still have to smile and shake their hands and all go get ice cream... Reality is a cruel wakeup call and kids are shown a great injustice by not being prepared to be kicked in the gut now and then.


How to integrate different skills and languages in a single project.


One university professor had something like this in his sig (not from my university, and I was never taught this there):

"If you get 90% correct on my assignment, you pass the course. If you get 90% correct at work, you get sacked."


?How to communicate effectively


Time management.



My school didn't offer any classes on databases. I think this is the stupidest thing to not include in any Computer Science degree. What are computers without data? What is corporate IT without data?

Every single company / place of work has data and understand how to access it, how it is stored and how to manage it is kind of important.


Building software is a social activity, more than a technical one.


Life is not multiple-choice.


One thing that doesn't seem to be explained in universities is the real-world importance of code optimisation. I used to find that developers fresh from school (me included) tend to suffer from the following issues:

  1. Miss the critical sections which require optimisation.

  2. Waste excessive amounts of time optimising code which is not executed frequently enough to be of any benefit and reducing its readability.

  3. For many graduates optimisation means moving variables out of loops, something compilers will do for 99% of high-level languages, rather implement caching, and appropriate data structures.

  4. CS students tend to think in exclusively Big-Oh notation, so that a 2x speed increase on a critical section is not something worth chasing.

Profiling is another technique which many graduates are unfamiliar with.


That the world doesn't turn around me, and that it doesn't care about me either.


Spending even 20 minutes planning your projects (however small) can save you hours or more of headaches, refactoring, debugging, etc.


learning how to learn anything. thats the only thing one education needs to teach any one. rest can be taken care of.


Principles I never learned at school:

never every make fun of anyone

treat people the way you like to treat you

all viewpoints are correct

put yourself in the person's shoes when treating him

Don't do or act anything may lead to self-image damage

Get what you need not what you want

focus on smaller things, and do one thing at the moment

Dont take every thing seriously nor personal

focus on relationships a bit more.

love the job you do, read more about it, live it


Whether you think you can, or think you can't, you are right.


You'll be working with real people. Correct code and command-line switches ain't good enough in the real world.


Until you've been in the business for at least 10 years you really don't know anything.


This may seem picky and trite, but a very overlooked skill that would have come in SO much handy was a solid teaching on how to properly construct Makefiles, including and certainly not limited to setting the include and link paths. I cannot begin to describe just how painful an iterated HTTP server development was in C without solid Makefile knowledge. Same for C++, same for Java Ant files, and so on.


That no matter how much fun I had programming as a hobby, it really sucks being a professional software engineer. Then again, being a professional anything probably sucks.

I'm not kidding. Univ. graduate (w/ honors) and 2 years exp in industry... and I still can't figure out what I want to do with my life.


Starting from nothing when creating a program - professors always had scaffolding and starter code for us. In a real project I often start from scratch and that opens the possibilities and that makes me realize that school should have been explaining the different possible starting points.


The most important thing:



Herms posted this comment earlier and I completely agree with this: origin post

I find that generally these things are only OK when you actually own up to them/admit them. If you make a mistake but refuse to admit it then it's not OK. If you're wrong but don't learn from it it's not OK.


Working, straining myself to achieve something. I got through school without ever doing my homework or learning for a test (outside of class), and still got acceptable grades.


How to deal with bosses. My last boss micro-managed me to insanity.


Oh, and, most people have a very fuzzy definition of the truth, which is annoying for techie types who prefer a more binary worldview.


Creativity Independence Free thought


how to sell an idea


How to program - I learnt it by myself.


No code is better than no code.


It is better to be lucky than good.


I'd like to know the most important thing learned in school, since I never went!


How to keep up with the rest of the world would be my answer. For example, when should someone start trying new tools or new versions of things? How do I get into something that I haven't done before in a quick and efficient way? In some ways I'm still working on this answer but it would have been nice if school could have given me a starting point.


I never had User Interface design/optimization. Usually my form has bunch of (too many) text boxes and combo boxes. I would love to get rid of many of those controls...


Think from the output point of view and not the process how we achieve it.Getting the output is important.


You need to test your code before saying done.


be careful what you ask for, you might get it.


Code conventions


To work as a team


Debug code in a systematic way.


The importance of commenting your code and how to do it well.


What you read and what you believe is almost certainly not true.


Use Google when you are stuck!

And don't type too long at a time or else you get carpal tunnel synd.

  • A deeper understanding of things I thought I knew everything about.
  • Several new and insightful ways to think.
  • networking with people of like mind.
  • Actualized things I could theoretically do.

Write neat code.


...that you have to learn most stuff yourself if you really want to be good at something.


Life is fucking hard.


They didn't teach me how to use a personal computer in school. They were $10,000 at the time, and way too expensive for student use, so we had a few departmental vaxes that were so overloaded that vi was disabled (we had to use ed instead). It did teach me regular expressions ... even ed was way too slow, so I learned some powerful regular expression search-and-replace methods to save on keystrokes (this way I didn't have to scroll the screen).


The following things have nothing to do with 'computer science' and instead belong in a class devoted to scamming microsoft fanboys.

* How to sell an idea
* Often, good enough is better than perfect.
* If a user can break your code they will.
* In the Real World? they're all open-book exams
* Self confidence is way more important in getting ahead than intelligence.
* You never know when you'll meet someone again ... or where. It's always worthwhile to treat people with respect and kindness
* Lack of Softskills experience
* How to productize code
* How to self-measurement. To evaluate ones true competences and market worth.
* How to read code on a large scale (being able to adapt and build upon existing projects)

The following thing just plain sucks, and if someone is going to be a 'computer scientist' then they'll need to be smart enough to obviate the need for it:

* TDD/Unit testing

Instead of learning buzzwords that out-sourcing contractors use to sell garbage code to government contractors, maybe students in CS should learn some basic skills:

* How to use vim
* How to type
* several languages that adults would use: Haskell and Python would be a good start
* How to recognize pitiful failures by their undying love of commercial progamming languages.