Three Things I Learned About Software WHILE NOT in University

Question

Well this question is asked by Scott at Scott Hanselman's blog, but I want to introduce over here.

What were the Three Things You Learned About Software WHILE NOT in University?

Answer 1

Just one thing: everything.

I didn't study comp sci in college.

Answer 2

• life would be a lot easier without users / customers :-)
• Murphy will hunt you down - your system will break at Friday 4:30pm and require an immediate fix
• there's always one more bug

Answer 3

Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far the universe is winning.

(Rick Cook)

Answer 4

1. Version Control
2. *
3. *

Answer 5

The hardest part of a piece of software is its interaction with the rest of the world.

If you want to judge the cost of a software project, or its likelihood of success or failure, measure the number and complexity of its interactions - with users, administrators, databases, hardware, operating systems, networks, everything.

The more interactions there are, and the more complex and inter-dependent they are, the more complex, expensive and prone to failure the project is.

[ That's one thing I've learned, in three paragrpahs. So vote me down. 8-) ]

Answer 6

1. How to estimate.
2. How to design/build large scale systems.
3. How to deal with the "real world" (changing requirements, legacy systems, etc).

School is great for learning the basics about how to program, oo design, database normalization, etc. but once you get out of school you realize that "programming" is only about 50% of what an actual programmer has to deal with.

Answer 7

• Automated testing is incredibly important.
• Version control (like davetron said).
• Communication skills are just as important as programming skills.

Answer 8

1. The difference between free time as in weekends and free time as in unpaid.
2. How much resistance there can be to version control and issue tracking systems
3. That there are a lot of people who aren't very interested in learning new stuff.

Answer 9

• Proper discipline (still trying to acquire!!)
• git
• vim

Answer 10

1. There's no substitute for practice, practice, practice on your own time.
2. Version control (excluding STORE, which I and probably any future employers will wish I hadn't learned)
3. Power of open source software.

Answer 11

1. Version control
2. That many users will do anything to avoid telling you what it is they want. I've had fantasies of hiring requirements analysts from the mob and telling them I just want the user requirements, and don't want to hear how they got them. Sometimes US Army interrogation techniques just seem inadequate to get user input.
3. Inside any seriously useful software product, there's obsolete technology and usually bad code.

Answer 12

1. Clean Code
2. Working in a team
3. Source Control

Answer 13

1. People skills. Still a work in progress.

2. University is all small, one-shot programs. Real world is huge, long term programs. Real world and hard knocks has taught me the importance of careful design.

3. The importance of building skills outside my University CS education (business, EE, manufacturing, etc).

Answer 14

1. Working for a company that build a product is much more satisfying than building a consultingware.
2. Quick fixes and hacks can quickly become quicksand!
3. Fixed-price contract for building software is a broken promise.

Answer 15

When I came out of school, I thought I was the man, cocky, sure of myself after all I knew my stuff, I could find my way around new languages quickly, I thought I could walk into a company and just write software, right? Oh how I was mistaken. I learned very quickly that school didn't give me much in the way of real world programming skills at all. When it comes to programming, university is much like graduating from primary school - you can speak your native language, read, write do basic arithmetic, you can understand things you are told. University really only gives you basic abilities:

• The ability to research and learn for yourself.
• A bunch of reasonably good resources with which to achieve that.
• The basic tools of your trade - reading/writing/arithmetic (metaphorically speaking)
• Perhaps a taster of living outside your comfort zone.
• Discipline [arguably], the awareness that I must study things that aren't always interesting to me in order to complete the task at hand, and the will power to get them done... and sometimes, it does take a lot of that.

What I'd learned in university was only a foundation upon which to build my real programming skills. I really had very little idea about programming outside of the very basic syntax, structure and algorithms - which was all I thought I needed. I could speak the language and I could use the tools, but in the real world it's akin to a child who can speak, read and write, but really has no idea about life. I think this is very much the same thing...

So things I learned since university:

• In the real world, shit happens. Your computer goes down, your hard disk gets corrupted, the house floods or burns down, you lose all your work, the client doesn't care, they still want to see what they're paying for... now. Backup your work, use Version Control, make sure it's somewhere you can get at it in an emergency.
• Code elegance is something you should always strive for but not expect, and not at the cost maintainability which is where you will spend 70% of your life. Sometimes you have to put your personal standards aside in order to get the job done on time. This is something I still struggle with after 14 years. Sometimes you just have to do what it takes to get the job done, by hook or by crook; even if that takes some of the most crappy hacks you've ever had the dismay to have had to write. In fact I have a project like that right now, much to my chagrin.
• Don't write software just because you can. Sometimes it's okay to say it's not worth it.

Sadly, in university, they don't really teach real world skills like version control, system backup and restore, maintenance of inherited code, bug tracking, debugging, scope creep etc. They really should. It would be much more useful to industry if students graduated knowing how to follow business best practices as well as just knowing the basic algorithms and languages.

Answer 16

1. Businesses don't want to buy software.
2. Businesses don't want to write software.
3. Businesses just want you to integrate this system with that system. Yesterday.

Answer 17

I leaned that: 1 - College teachs nothing useful! Period. 2 - If you want to lear something, that deppends on you. 3 - I could have bought a lot of useful things with the money spent at the college.

Answer 18

• People Skills: It's not what you know, it's who you know!
• Deleting code is much more satisfying than writing it.
• Bespoke Software is Expensive

Answer 19

1. Most folks care less than you do.
2. Cynicism may help your ego, but it doesn't help your project.
3. Sometimes you don't get everything you want. Don't let this slow you down.

Answer 20

1. The customers will use your product in the "wrong" way.
2. Version control everything.
3. It always takes longer than you thought.

Answer 21

1. Stress management

   By far the most important thing I've learned is figuring out which deadlines to blow (err, reschedule), which to meet.

2. Logging

   What to log, when to do it, and where. Seriously, this was the absolutely hardest thing for me to learn.

3. Code lifecycles

   At uni, you wrote code for a course, had it finished when it ended, and could then throw it away (or save it in your "snippets" folder). Code written in the Real World, however, will either never be used, or it will be used for far longer for far more purposes by far more people than you ever imagined. I wrote a simple monitoring shellscript (a disposable hack, I thought) on my first Real World job. My manager saw it and told me to mail him a copy of it. It is rumored to still be in use, serving a semi-critical role, which means it could quite likely be the only code I wrote still in use there. Mysterious ways.

Answer 22

Judging by some of the responses above, those university CS programs must've been lacking. I'm just finishing my freshman year of CS curriculum, and I've been exposed to almost all of the above.

Answer 23

• Massive refactors: never had a 3+ year project in college.
• customer may be always right, but doesn't know what s/he wants.
• Thank god i am at a great university.

Answer 24

• most of the best things you code will not be rated "A". in fact, they will be as soon as possible become just part of a project;
• how to use version control software. i've never seen one in the university;
• depending on where you work, you should never care about "new" technology. in fact, you may even never have contact with newer things.

Answer 25

My first programming job was in the 1970s so:

1) The language you learned in school is not the language you use on the job. 2) The computer you used in school is not the computer you use on the job. 3) The job pays way more than the student aide job you had at college!

Answer 26

1. Thinking of the "ripple" effect a change may have on a system and impact live customers
2. ALWAYS back up a database before making significant changes especially data related
3. Keep a version control of everything - code, releases, databases, etc and script your database and store it in source vault in case of emergencies!