Stack OverflowThree Things I Learned About Software WHILE NOT in University
[+3] [25] Syed Tayyab Ali
[2009-05-01 21:07:24]
[ concepts survey ]

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

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

(6) Why three things? Why not four? Or two and a half? - Michael Myers
(17) This should be a community wiki - Ichorus
(2) i'm with ichorus, wiki - Fredou
(1) I am also with ichorus. - Syed Tayyab Ali
[+16] [2009-05-01 21:12:13] marc_s
  • 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

(1) "almost" one more bug or "always" one more bug? - Chris Lutz
+1 on the Friday 4:30 bullet. I swear, more than half of my support ticket have dropped in on Friday afternoon, critical and non-critical alike. I assume people horde issues over the week and want to start the next week with a clean sheet. - gustafc
[+12] [2009-05-01 21:39:31] BenAlabaster [ACCEPTED]

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.

Yes, real world is different. - Syed Tayyab Ali
@balabaster: I am agreeing with your answer. - Syed Tayyab Ali
(2) I disagree with the adverb "sadly". The point of university is to educate people in the broader sense, not to give them a limited subset of skills that are only relevant in a particular context. If they spent time teaching you all that stuff they wouldn't have as much time to teach you how to learn it. If you want specific training like that you go to a trade school. - intuited
@intuited: Do software development trade schools exist? - Andrew Shepherd
@Andrew Shepherd: I'd say schools like CompuCollege, where you specifically learn, say, javascript programming, without getting a lot of background knowledge or compsci theory, are effectively that. - intuited
[+11] [2009-05-01 21:22:45] xkcd150
  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.

(3) #3 is very sadly, very frustratingly true. - David Poole
(1) especially in the case when people don't want to learn about new tools that could help them. i've been in #3 + #2 hell lately. - xkcd150
+1 for your first point - Jeremy Cron
+1 for #2 & #3... though issue tracking systems can be a problem, e.g. ClearQuest/ClearCase. - ceretullis
(1) #3 is SOOO upsetting and true. There are many I wished I could've given a good kick in the @$$ over the years. - Marc
[+7] [2009-05-01 21:13:30] marc_s

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)

[+6] [2009-05-01 21:16:06] Eric Petroelje
  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.

In my opinion, - Good understanding of data structures - Good skill of requirement gathering and software engineering - Coding is an art, it become fine and tuned day by day through experience and and contact with experienced peers. - Syed Tayyab Ali
But I like your answer. - Syed Tayyab Ali
[+6] [2009-05-01 21:32:53] John Nolan
  1. Clean Code
  2. Working in a team
  3. Source Control

working in a team, good. - Syed Tayyab Ali
+1 for working in a team, this is a challenge. - ceretullis
[+5] [2009-05-01 21:17:38] Kevlar
  • Automated testing is incredibly important.
  • Version control (like davetron said).
  • Communication skills are just as important as programming skills.

I appreciate your reply. - Syed Tayyab Ali
[+5] [2009-05-01 21:32:58] David Poole
  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).

[+4] [2009-05-01 21:14:33] davetron5000
  1. Version Control
  2. *
  3. *

Even in fourth year it surprised me how many people I needed to introduce to subversion. - Aaron Maenpaa
[+4] [2009-05-05 14:02:09] gustafc
  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.

logging thing is really important. - Syed Tayyab Ali
(1) Haha, #3 is soooo true. There must be a formula revolving around the amount of code vs. the output and the likelihood of it still being in use a given amount of time later. Some inverse correlation of code lifetime and a function of lines of code and number of minutes taken to hack it together. So 100 lines of code hacked together in 20 minutes will still be used 10 years later, but the 2.5 million lines of lovingly crafted code that took your team a year and a half to write will only have a lifetime of 5 years - if you're lucky. - BenAlabaster
[+3] [2009-05-01 21:10:48] Jon B

Just one thing: everything.

I didn't study comp sci in college.

[+2] [2009-05-01 21:33:57] Matt W
  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.

[+1] [2009-05-01 21:15:41] RichieHindle

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

+1 Your point is true. I dont step you down. - Syed Tayyab Ali
[+1] [2009-05-05 04:00:39] tmclaugh
  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.

[+1] [2009-05-05 13:11:38] Robert
  1. The customers will use your product in the "wrong" way.
  2. Version control everything.
  3. It always takes longer than you thought.

I learned 1 & 2 at university (somewhat). You just have to take the right course. Do they not offer HCI at your uni? - hasen j
[+1] [2009-05-05 17:23:55] Paulo Guedes
  • 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.

@Paulo Guedes: But in my opinion, regardless of location, good programmer should learn new technologies.. - Syed Tayyab Ali
@Paulo Guedes: +1anyways - Syed Tayyab Ali
[+1] [2009-05-05 17:32:14] JonnyBoats

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!

@JonnyBoats: so true. - Syed Tayyab Ali
[+1] [2009-05-05 17:40:22] Vixen
  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!

+1 for change management. - Syed Tayyab Ali
[0] [2009-05-01 21:23:04] hasen j
  • Proper discipline (still trying to acquire!!)
  • git
  • vim

please write little bit more. I could not understand what are you saying? - Syed Tayyab Ali
hehe, git and vim are just tools man. - hasen j
[0] [2009-05-01 21:25:23] Matthew Flaschen
  1. There's no substitute for practice, practice, practice on your own time.
  2. Version control (excluding STORE [1], which I and probably any future employers will wish I hadn't learned)
  3. Power of open source software.

[0] [2009-05-01 21:28:01] David Thornley
  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.

[0] [2009-05-05 03:46:14] David Plumpton
  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.

[0] [2009-05-05 03:52:03] Paulo

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.

[0] [2009-05-05 03:56:26] Mitch Wheat
  • 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

[0] [2009-05-05 17:11:54] Tom
  • 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.