Lol... My Comp Sci teacher...

So, showed him my sorting algorithm and he was just like "Yeah, I'm sure that will get you a job." and then I showed him a Quine I made, and he was just like "Oh yeah." like he didn't even know what it was.

I'm pretty sure he has like no interest in professional and real computer science, only in teaching his crappy Java :/ He didn't even know some of the more advanced Comp Sci algorithms I was naming that are SUPER common.

I didn't know what a Quine was until you mentioned it. :x

Sounds like a Comp. Sci. high-school teacher. University/College professors usually have a doctorate degree and are very interested in the field. They are usually also familiar with common and advanced algorithms depending on their concentration.

My computer science teacher couldn't understand my code. He would just give me an A no matter what I turned in. The students came to me for help, and even he did a few times. He had me write a program that would convert two strings to unique numeric representations, add then together, and then output one of an array of values such that those two strings would always produce that same value.
Pretty easy. I wrote it in a language I didn't know yet (BASIC). A language he taught. To other students besides me. Asked me to do it. Did. Easy program.

But yeah. For some reason, programming professors don't seem to be... well... programmers.

It's like they memorize languages as if it was a history class.

But then again, there's probably a reason they teach programming instead of, you know, programming.

Riddle wrote:

I didn't know what a Quine was until you mentioned it. :x

Sounds like a Comp. Sci. high-school teacher. University/College professors usually have a doctorate degree and are very interested in the field. They are usually also familiar with common and advanced algorithms depending on their concentration.

Eh. My college professor was a bad programmer too. He literally told me to stop simplifying his assignments and writing the programs more efficiently than him.
Literally said that.

One of the functions he had us write was to draw a triangle. One of the parameters was "number_of_sides," to which he commented "always 3."
I. Shit. You. Not.

The dumbest parameter I have literally ever seen in my life. I know I am saying literally a lot, but I am not using it figuratively.

I have to give him credit for being super smart with RAM and shit. I think he might have been into hardware or networking or something besides programming, and they just made him teach it because he was "good enough."

Pretty sure someone not understanding your code isn't a good thing.

You would think so. He was just an idiot. He asked me if I used a for loop once, while looking at my code.



I didn't.

It went something to the effect of:
"I see what you did here. You used a subroutine."
"No?"
"Oh. A for loop?"
"... No."
"Ah. Uh huh." and then he walked to his desk and didn't say anything else.

I have witnesses.

GAMEchief wrote:

My computer science teacher couldn't understand my code. He would just give me an A no matter what I turned in. The students came to me for help, and even he did a few times. He had me write a program that would convert two strings to unique numeric representations, add then together, and then output one of an array of values such that those two strings would always produce that same value.
Pretty easy. I wrote it in a language I didn't know yet (BASIC). A language he taught. To other students besides me. Asked me to do it. Did. Easy program.

But yeah. For some reason, programming professors don't seem to be... well... programmers.

It's like they memorize languages as if it was a history class.

But then again, there's probably a reason they teach programming instead of, you know, programming.

Well, that's just sad.

I've only experienced programming intensive courses at my current University, and we have a pretty good Computer Engineering program. Most of the professors are good at what they do. Some of them do mainly hardware, others software, and others theory (Computer Scientists). Each of them is good at their main research area, but they still have a good general understanding of all 3 main areas (hardware, software, and theory).

GAMEchief wrote:

Eh. My college professor was a bad programmer too. He literally told me to stop simplifying his assignments and writing the programs more efficiently than him.
Literally said that.

One of the functions he had us write was to draw a triangle. One of the parameters was "number_of_sides," to which he commented "always 3."
I. Shit. You. Not.

The dumbest parameter I have literally ever seen in my life. I know I am saying literally a lot, but I am not using it figuratively.

I have to give him credit for being super smart with RAM and shit. I think he might have been into hardware or networking or something besides programming, and they just made him teach it because he was "good enough."

That happened to me during my Computer Architecture class. The professor just seemed like a dumb person to me. His main area of research was also hardware, which was completely related to the class he was teaching. It could have been that he simply was not a good teacher. One time I saw him give a lecture about his research topic (something to do with processors and branch prediction optimization), and daaamnnn, that guy was actually one of the most respected individuals in that field! My mind was blown.

Lol. It's quite funny looking at the different conventions used by different professors at college/uni/highschool. I actually had a professor last year who taught that it was bad practice to comment your code. His theory was if you couldn't understand the code from looking at it, it's poor code and needs to be rewritten. That's fine in small, simple programs, but when you start building massive applications, particularly in a team environment, if nobody documents their code, you're going to be in for a bad time :p

Artificial wrote:

Lol. It's quite funny looking at the different conventions used by different professors at college/uni/highschool. I actually had a professor last year who taught that it was bad practice to comment your code. His theory was if you couldn't understand the code from looking at it, it's poor code and needs to be rewritten. That's fine in small, simple programs, but when you start building massive applications, particularly in a team environment, if nobody documents their code, you're going to be in for a bad time :p

I personally comment every single line of my programs, so that if I come back in a year I can continue working on it, and so that if I show someone else they can understand it.

>every single line

:facepalm:

GAMEchief wrote:

>every single line

:facepalm:

Why don't you have an emote for that yet?

Also, don't underestimate the retarded-ness of some people. I've had people read a System.out.println(); and ask what it does, so I explain EVERYTHING.

You shouldn't comment every single line of your code. That just looks messy. It is enough to point out noteworthy things, for example, noting that there must be a delay of 0.5s in order to avoid a race condition (or stuff like that). You could also use extensive documentation when you are implementing an algorithm that is confusing. Things like that are OK to comment extensively, every line if needed.

On a regular basis, you should not have to comment every line. You should be fine just commenting in the purpose of a block of code (functions, classes, etc) with a standard documentation format for the target language.

@Arti: That's simply retarded.
1. Create a class that spans a thousand lines.
2. Document in the header the available functionalities and the purpose of said class.
3. Avoid the massive amount of scrolling and save time reading a bunch of lines of code by reading the couple of lines in the header.
4. Profit???

Flareboy323 wrote:

Why don't you have an emote for that yet?

Also, don't underestimate the retarded-ness of some people. I've had people read a System.out.println(); and ask what it does, so I explain EVERYTHING.

It's not your job to teach them. Your target demographic for people reading your code should be people your skill level, not people just learning.