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

Question

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

Principles:

• 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

Answer 1

How to teach others effectively.

Answer 2

How to resolve a technical disagreement.

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

Often, good enough is better than perfect.

Answer 7

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.

Answer 8

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

Answer 9

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

Answer 10

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

Answer 11

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

Answer 12

That the real world is unfair.

Answer 13

Choose your employers wisely.

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

Answer 14

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

Answer 15

Just how important being able to effectively communicate really is.

Answer 16

How to communicate effectively.

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

Answer 17

TDD/Unit testing.

Answer 18

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

Answer 19

The skills to keep on learning.

Answer 20

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.

Answer 21

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.

Answer 22

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

Answer 23

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

Answer 24

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.

Answer 25

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.

Answer 26

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'?!?"

Answer 27

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.

Answer 28

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.

Answer 29

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

Answer 30

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

Answer 31

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.

Answer 32

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

Answer 33

The majority of people are idiots and liars

Answer 34

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.

Answer 35

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

Answer 36

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

Answer 37

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

Answer 38

How to conduct myself in a job interview

Answer 39

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.

Answer 40

Working with large codebases and pre-existing code.

Answer 41

Not enough emphasis on technical writing.

Answer 42

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.

Answer 43

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.

Answer 44

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.

Answer 45

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.

Answer 46

Regular expressions.

Answer 47

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.

Answer 48

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

Answer 49

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.

Answer 50

• 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

Answer 51

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)

Answer 52

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.

Answer 53

Write neat code.

Answer 54

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

Compare:

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

vs.

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

Answer 55

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.

Answer 56

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

Answer 57

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.

Answer 58

The most important thing:

Moxie.

Answer 59

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.

Answer 60

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

Answer 61

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.

Answer 62

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)

Answer 63

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.

Answer 64

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.

Answer 65

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.

Answer 66

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

Answer 67

How important is backup.

Answer 68

How to learn effectively (based on cognitive science).

Answer 69

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

Answer 70

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

Answer 71

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.

Answer 72

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

Answer 73

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.

Answer 74

Creativity Independence Free thought

Answer 75

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

Answer 76

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.

Answer 77

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

Answer 78

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

Answer 79

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

Answer 80

Life is fucking hard.

Answer 81

how to sell an idea

Answer 82

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

Answer 83

salary negotiation

Answer 84

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.

Answer 85

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.

Answer 86

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

Answer 87

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

Answer 88

How to program - I learnt it by myself.

Answer 89

No code is better than no code.

Answer 90

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

Answer 91

It is better to be lucky than good.

Answer 92

how to ask your boss for a raise.

Answer 93

•How to communicate effectively

Answer 94

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

Answer 95

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.

Answer 96

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.

Answer 97

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

Answer 98

Time management.

Answer 99

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

Answer 100

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

Answer 101

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

Answer 102

Self learning.Educate yourself.

Answer 103

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.

Answer 104

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

Answer 105

Databases.

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.

Answer 106

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.

Answer 107

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

Answer 108

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

Answer 109

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.

Answer 110

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.

Answer 111

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

Answer 112

Project management.

Answer 113

Life is not multiple-choice.

Answer 114

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.

Answer 115

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.

Answer 116

You need to test your code before saying done.

Answer 117

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

Answer 118

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

Answer 119

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

Answer 120

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

Answer 121

Code conventions

Answer 122

To work as a team

Answer 123

Debug code in a systematic way.

Answer 124

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

Answer 125

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.