I was recently in a conversation where we were talking about things we'd learned in college that helped us in our jobs today. I tried to distill it down to one thing but couldn't so here are the three I came up with.

  1. Operating systems aren't elegant. They are a glorious heap of performance hacks piled one upon the other.
  2. Software engineering is the art of amassing collected anecdotes and calling them Best Practices when in truth they have more in common with fads than anything else.
  3. Pizza is better than Chinese food for late night coding sessions.

What are yours?


 

Wednesday, June 27, 2007 7:38:19 PM (GMT Daylight Time, UTC+01:00)
Less code is better code - less code to maintain - it took me a while to discover this, and it happened at around the time I first was introduced to C. A lot of new programmers generate lines and lines of unnecessary code, thinking this is beneficial, when they could be generating useful comments, or test cases or something.
Wednesday, June 27, 2007 8:16:23 PM (GMT Daylight Time, UTC+01:00)
Things I learnt from college (93! eek):

1. I don't like getting up early. It's both unnatural and wrong. I now blame all my design mistakes on whatever the hell was in those 9AM lectures.

2. The people that didn't 'get' Prolog, even after copying my paper, ended up as either managers or business process consultants that still don't 'get' it. College introduced me to the concept that a very small amount of bullshit can go a very long way in this field.

3. College introduced to me to the place that when I'm programming then time is a completely arbitrary concept. It's one of the few things in the world where I can metaphorically blink and whole hours/nights can disappear in a flash. I still have fond memories of being shocked to see the sun coming up and the birds chirping, hunched over a keyboard. That and the beer.
Wednesday, June 27, 2007 8:48:43 PM (GMT Daylight Time, UTC+01:00)
1. Dare is not pronounced like the identically spelled word in "Truth or Dare".

2. There are people who don't get code, and people who don't get people. Avoid both if at all possible when doing code, as they both make creating good software hell.

3. Most people can't pass simple coding tests. People with degrees with the word "Computer" in their name.

4. All these wonderful ideas you have about how something could work or what could be causing a bug? Until you empirically determine that to be the case, you're just talking and wasting time. Draw pretty lines and boxes all you'd like, prototypes are king and debugging by shutting up and just looking is queen.

5. Getting good at making prototypes crappy enough that you can people who don't get code to throw them away is harder than most NP-Incomplete problems.

6. The people who *really* get the machine from top to bottom don't give a flying crap about efficiency unless their doing embedded work or the profiler tells them to.
Michael Langford
Wednesday, June 27, 2007 9:06:39 PM (GMT Daylight Time, UTC+01:00)
1. O(n) is better than O(n log n), which is better than O(n^2)

2. Academics find it difficult to prove anything about an algorithm which I can intuitively understand.

3. A good internship is better than a degree in Computer Science any day.
Wednesday, June 27, 2007 10:16:04 PM (GMT Daylight Time, UTC+01:00)
I coded a lot in university -- some of it for pay -- but fortunately, I didn't study computer science or engineering. Here are my major lessons:

1. Readable code goes further and survives longer than optimized code, especially once you're no longer the one maintaining it (or if you come back to it two years later).

2. If you write code that makes you feel like a genius, throw it out -- you'll realize later that it's crap. If you write code that makes you feel like a competent tradesman, you're on the right track.

3. No matter how smart you are, everyone -- even the most incompetent loser of a coder -- knows at least one thing you don't. It's a good idea to listen.

Thursday, June 28, 2007 12:28:13 AM (GMT Daylight Time, UTC+01:00)
1. *Good* operating systems are well designed, and even the performance optimizations are nice.

2. Building OSes and building compilers are the two ends of the spectrum of applied CS. Learn about both, and you'll be able to solve most problems coming your way.

3. Nobody writes good tools. Ever. As soon as it does the bare minimum, it's declared OK.
Thursday, June 28, 2007 12:41:12 AM (GMT Daylight Time, UTC+01:00)
I learned how to talk to girls while the rest of you were playing with your puds.
T Hawkins
Thursday, June 28, 2007 11:25:23 AM (GMT Daylight Time, UTC+01:00)
1. Software is neither science nor engineering. It's a craft.

2. All lasting software has elegance and grace as foundation. (except Cobol)

3. Most people who write software never read others. These are the same people that don't want you to read theirs. A sure sign of their presence is phrases like "my code" and "your code" in discussions. Leave them if you can.
Friday, June 29, 2007 11:26:01 AM (GMT Daylight Time, UTC+01:00)
There are vast differences in programming aptitude - at least an order of magnitude difference - and that's not counting people who don't really get programming at all (I grade CS101 assignments in college).
Eric Gunnerson
Friday, June 29, 2007 11:41:40 AM (GMT Daylight Time, UTC+01:00)
http://forkaveri.wordpress.com/2007/06/29/four-things-i-learnt-when-not-in-college/
Thursday, July 5, 2007 10:48:20 PM (GMT Daylight Time, UTC+01:00)
That academics can be nasty?

Comments are closed.