7 ms·

Things they never teach in college about programming.

34 points by wtfdeveloper 16y ago

superdavid 16y ago
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 16y ago
  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 16y ago
    "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 16y ago
      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.
- aero142 16y ago
  Yes, and then they learn all about source control. It's really not that hard and is pretty easy to learn. Hence why you don't need to pay someone to teach it to you.
mikeryan 16y ago
"Be ready to spent 80% of your time thinking, debugging, testing, in meetings, conversations…" I always considered thinking, debugging and testing part of coding...
edw519 16y ago
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 16y ago
  "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 16y ago
    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.
rimantas 16y ago
#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 16y ago
  "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.
j_baker 16y ago
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 16y ago
> 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.
koningrobot 16y ago
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 16y ago
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.

34 points by wtfdeveloper 16y ago

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 16y ago
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 16y ago
  "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 16y ago
    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.
aero142 16y ago
Yes, and then they learn all about source control. It's really not that hard and is pretty easy to learn. Hence why you don't need to pay someone to teach it to you.

mikeryan 16y ago

"Be ready to spent 80% of your time thinking, debugging, testing, in meetings, conversations…" I always considered thinking, debugging and testing part of coding...

edw519 16y ago

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 16y ago
"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 16y ago
  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.

rimantas 16y ago

#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 16y ago
"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.

j_baker 16y ago

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 16y ago

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

koningrobot 16y ago

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 16y ago

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.