

Things they never teach in college about programming. - wtfdeveloper
http://www.makinggoodsoftware.com/2010/05/27/10-things-they-never-teach-in-college-about-programming/

======
mikeryan
"Be ready to spent 80% of your time thinking, debugging, testing, in meetings,
conversations…"

I always considered thinking, debugging and testing part of coding...

------
superdavid
Two major problems I see with people straight out of their course:

1\. They've never heard of source control, let alone understand why or how it
should be used.

2\. They know exactly the frameworks they've been shown during their courses,
and think that anything else is either completely foreign and useless, or
needs to be dived into head-first, rather than seeing any framework as just
another tool to be used based on first principles. (Replace "framework" with
"language" and you get the same idea on a different scale.)

Maybe these comments are specific to Australian courses?

~~~
pwhelan
As someone not too far out of coursework in the US -- neither I nor most of my
classmates didn't use source control. For most homework assignments and
projects it just wasn't a necessity. You were working with so few people and
just sorta ground it out. Setting up/using version control wasn't worth the
frustration and time. Had it been required and assignments were turned in by
checking in our final version, then it would be second nature.

I wonder if the framework/language thing is more just a lack of experience in
using new things without jumping in head first. I still have some of that.
However, it was made very clear that first principles should always be used.

~~~
sanderjd
"Setting up/using version control wasn't worth the frustration and time."

I think the onslaught of very usable distributed source control systems with
cheap and easy local repositories should make this a non-issue. I wish I had
known about hg or git when I was in school - a simple repository per
class/project would have alleviated a few pain points that weren't severe
enough to be worth with the hassle of setting up a subversion repository.

~~~
pwhelan
I agree with you just at least at my school we didn't have it. I have a friend
who works in the CS department now (and is one heckuva lecturer) that I'm
going to mention it to.

I still don't know much about version control but perhaps a wrapper might be a
good open source project or something.

------
rimantas
#4 reminded me of these two laws:

a) there is always a bug b) every program can be reduced at least by one
instruction.

Hence, you can reduce every program to a single instruction which is a bug.

~~~
amalcon
"There are two ways of constructing a software design. One way is to make it
so simple that there are obviously no deficiencies. And the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult."

-C.A.R. Hoare.

------
edw519
_1.- We're always wrong._

SometimesWereWrong + SometimesWereRight != "We're always wrong"

 _2.- If something can break, it will break._

Good thing this isn't true. I'm am continually amazed that some of the crap I
have to maintain ever ran in the first place, much less that it continues to
run. But it does. Sometimes for years without ever breaking. I call it
"dodging the raindrops".

 _3.- All code is crap._

OP must have never seen really magnificent code for him to say this. What a
shame. It's out there.

 _4.- There is always a bug._

False. The first step in writing bug-free code is believing that it's
possible.

 _5.- The most important thing is the client._

Lots of things are important, but it's hard to argue with this one.

 _6.- Design on paper doesn't work._

Sure it can. Just because it usually doesn't work doesn't mean that it can't.
I prefer prototyping, but blueprinting can be effective too.

 _7.- Less is more._

Generally, yes. That's what great design and refactoring are for. But there
are counterexamples to this.

 _8.- Coding is only 20% of what we do._

If you actually believe this, then you're not spending enough time coding. I'd
say more like 50 to 80%.

 _9.- The customer doesn't know what he/she wants NEVER!._

False. The customer often knows _exactly_ what he/she wants, but may have
trouble communicating. That's when you expert analysis and prototyping skills
come in handy.

 _10.- Someone has done it before._

Similar to #4, the first step in inventing something new is believing it's
possible. Lots of stuff that needs to be done hasn't been done for all kinds
of reasons. Maybe no one thought it was possible or no one has understood its
potential. But we know better.

 _Bonus: Hey! Our job is cool!_

Yes! I agree!

~~~
j_baker
"If you actually believe this, then you're not spending enough time coding.
I'd say more like 50 to 80%."

If you don't include debugging and thinking in that figure (as the author
does), 20% doesn't seem unreasonable. I seriously doubt that it's possible (or
even preferable) to spend 50-80% of your time literally typing text into your
text editor.

~~~
bmj
I think it depends on the size of the team (and related teams) and the sorts
of dev cycles you experience. I'd say in my case, including testing and
debugging, I code roughly 50% of the time. That doesn't mean, however, that I
spend four hours everyday coding and another four going to meetings, etc, etc.
The pattern is often more like: code 85% of the time for several weeks, then
drift into a period of considerably less coding as we review releases, work
with other teams for product hand-off, offer training, and review bugs and
issues.

~~~
drunkpotato
It's also true that we (humans) are terrible at self-reporting information
like this. Not that you are lying, simply that you are most likely incorrect.

------
koningrobot
I used to believe that all code was crap, and, to drive the point home, that
my code was the very worst. Five years of experience forward, I think my code
is rather good. I have never had impressive colleagues.

Some open source code is impressive, and to work on projects with good code is
one of the few things that are great. But most open source code could have
been written by my former colleagues.

I'm not really all that arrogant -- people who are actively looking for better
ways to write their code are just as much a joy to work with. It's just that
"my code is the worst" is the kind of "tip" or "wisdom" you find in this kind
of article, yet truth be told, most of us (here on HN, there on
reddit/programming, or on the c2 wiki where it used to be at) write some
pretty awesome code.

------
perlpimp
I'd like to contend with the writer 1st answer / question: 1 - We're always
wrong. Vocabulary is vital in accurately describing situation. I think
dispassionate wording without using good / bad / right / wrong suits better to
reflect what is really going on - process of continuous learning and
continuous realigning of the information. People often get attached to ideas,
ways of doing things. And they start attaching emotions to them. We should
consider issues dispassionately while in analysis - this is hard: we are
emotional beings. Appealing to our emotions is a way to deliver a message.
However message should not be corrupted with fixed notions that some thing can
be either wrong or right - as I think is happening in this article.

------
j_baker
I disagree with #1. In fact, you can almost say the exact opposite: we're
always right. The difficult discussions happen when two people have different
ideas that are _both_ right. I sometimes struggle with this. I might get into
an argument with someone when neither one of us really realizes that neither
one is incorrect, but they're both alternate ways of achieving the same goal.

------
wazoox
> 6.- Design on paper doesn't work.

Some of the very best programmers in history (Don Knuth, Jean Ichbiah)
designed some of their best known programs on paper. Ah, but I forgot rule 1:

> 1.- We're always wrong.

Then it makes sense.

