Slashdot Mirror
Programming Assignment Guide For CS Students
kennelbound writes "For those students just getting started in a Computer Science degree or a career in software development, this guide has been written to help you understand what NOT to do when coding a project. Those with a little more experience should still read it to get a good chuckle (and hopefully the mistakes stated within will not seem too familiar!)"
I'm sure many people will say this, but you learn much more from making mistakes and working out the problems than by reading a book on common mistakes.
Not cheating would be a good important one.
OBVIOUS, but always missed. If you need to cheat, change majors.
a HUGE thing is not to plagarize code. I was a TA for CS101 at my school, and plagarism is not only rampant, but really really easily detectable. besides, you don't learn anything; although, as one of my professors said, "if you can copy someone else's code and alter it so I can't tell, you may as well have actually done the assignment."
I was hoping for something educational and instead I found a collection of jokes that I don't find very amusing. I mean sure I'm smirking, but shouldn't something that took that many bytes at least make me chuckle?
Irony - look it up.
Maybe you should have used a debugger and stepped through the code. A good programmer knows when he's defeated and when he has to step through the code. Maybe that should be one of the rules. Use the debugger, it's there for a reason. Don't assume you're wiz and will fix the problem by just reading the code line by line. If you're a neophyte, chances are you're going to mess up existing working code.
Oh I just know I'm going to open up a huge bag of worms with this one, but this is why I vastly this sort of syntax:
It makes it easier to identify which statement the block is intended to begin with, and makes it easier to spot if there are un-intended characters between the condition and the block-opening (besides reducing vertical space wastage).
Yaz.
The proliferation of 'happy-clicky' programming environments has led to sloppy inefficent coders who have limited understanding of how to write clean code.
The result? Word Processors which ship on 5 CDs and do little more than similar products from a decade ago.
More RAM, bigger hard-drives, faster processors, and for what? A new version of software that doesn't do a whole lot more to justify the upgrade?
Meanwhile, a lack of formal coding education also means we still see buffer overflows and other security nasties that should never have happened in the first place.
The good news, is devices like the Palm have forced people to operate in the limited hardware/memory environments of years ago. The result, clean efficient code in just a few kilobytes.
Time to go back to school people...
Indy Media Watch-Proctologist of the Internet
So let me get this straight, you didn't get that the article was a work of satire, yet this is the only part of it you felt needed to be challenged?
Mathematics is made of 50 percent formulas, 50 percent proofs, and 50 percent imagination.
Here's a VERY GOOD hint for those of you who are starting to program:
.h header file or UML diagram on paper.
THINK UML.
THINK OBJECTS.
THINK MULTI-TIER.
THINK BOTTOM-UP.
USE A NOTEBOOK.
If you start designing on paper the functions/object/interfaces/etc for your program, then start coding. As you begin to code, you'll start realizing that you'll need auxiliary functions (like an array searcher or something - most of the time lazy guys like you or me want to do everything in one function or method. Don't fall in the trap. If a series of steps is going to be very difficult, thing bottom-up and put it in a separate function or method. But before you start coding it, add it to a "to-do" list in your notebook.
That way you can keep coding your current function, by calling the not-yet written function that only exists as a declaration on paper. But the idea is there.
In the end, you'll end up with practically a completed
That helps a lot when programming (specially for low-termed memory guys like me). When you're finished designing the code, all you got to do is start typing and see which functions need to be coded, or which details . Why? Because you've already solved the problems in your code.
In one day i could design an OOP SQL wrapper (business tier) for my database project, and i only had to adjust minor details (i.e. bugs) when finished coding.
So, believe it or not, paper SAVES TIME. Trust me.
Do not slack at your math. You will repeat it. It often takes time. It is very important. Learn to utilize math and make it one of your more powerful tools.
Do not cheat on code assignments. Once again, it may take time but you need it. Messing up and looking through code more than writing it is what really makes you good.
Take hard CS classes. Take advantage of rare courses your school may offer in CS. Take tough classes like compilers or computational geometry. Make sure you take some diverse classes but also try and focus on something a bit that you enjoy.
Take more math. This is a skill that can really differentiate you from other programmers in the industry, If you have good math skills, you can get good paying, secure jobs in fields like computer graphics, physics, medical and other science fields that demand proficient math skills. It will also change the way you think if you really take it seriously and understand that much of the early math is indeed lame, but necessary to understand useful math that you will eventually learn.
Take other classes, like art. You can learn a lot from these things and apply them to what you are doing. Knowing about various things will come in handy at some point.
Learn more than what your school will teach you. It is up to you to read about things in the field, both theory and practical. Learn languages not needed in your school. Play around with things. Put together a cheap Linux computer at home and play around in it if you haven't already. You are interested in this anyways, so this shouldn't be something you have to do.
Maybe CS is not for you. The future is not guaranteed in this field as far as job security is concerned. You may spend a lot of time taking hard classes only to have to end up doing something else. You may not even make it through the program. Personally, I think there will always be a need for well educated, creative, smart people. The analytic skills you can learn will do more for you than anything else. Pay attention.
If you love it and are good at it and really spend the time in school to really learn this art, you could enjoy a career working in an industry you love. If you are ambitious, there will be many trails to be blazed in the future in this young, ever changing field. It's not about "computers". It's about computation, a modern subset of math that we can abstract in electronics. The possibilities are endless and you may invent the next big thing.
"If you are a dreamer, a wisher, a liar, A hope-er, a pray-er, a magic bean buyer
I've got to disagree - for beginning CS students, compiling frequently is an excellent thing to do. I'm a CS TA, and most of the panicky emails I get from students the night before a project is due revolve around small, simple problems that get blown way out of proportion. A single misplaced semicolon can make the compiler spit out dozens of errors for lines of code below it, none of which will make any sense. Errors propogated through code are terribly difficult to detect; your program's output might be incorrect due to something that you wrote two class files ago and have already forgotten about. And then there's the problem of poor program planning combined with infrequent test compilations - namely, the design sucks donkey balls and you just spent three hours laying down the foundation for a code base that is completely useless. I wrote code like this until I because a grad student, and it shows - I spend way less time designing and write far better programs due to multiple test compilations.
That's a pretty pretensions comment. Many people don't have access, either through finance or friends, etc to get interested in CS things like programming at an early age. Granted, while in it you ought to be interested and enthused about, else you should probably be doing something else that does. But, that's the whole point of college; to discover what interests you if you haven't already and experiment with things. Many of these "majority of CS students" are taking a Java class to see if they enjoy it, thus it is the first time they have touched a command line. Many of them will find it's not for them and drop. Some will stick around for some reason.
Besides, if you knew anything of CS you would know Java and command lines have as much to do with it as telescopes do to astronomy, to paraphrase Dijkstra. In fact, I had professors who could care less about Java or command lines because their interests are in theoretical computer science, algorithms, math, theory, etc.
Perhaps you are in the wrong major. Maybe you belong in a traade school for programming?
"If you are a dreamer, a wisher, a liar, A hope-er, a pray-er, a magic bean buyer
Re-use is ok after you graduate so the professors are OK, copyright assumed not to be an issue. While you are learning you need to do things yourself.
When I was in university I would spend 90% of the time putting together a "framework" to solve the actual problem (much more general and thus useful for future classe). Then I would spend 7% of the time debugging it. Then I would spend the remaining 3% desperately trying to figure out how to use the framework to solve the assigned problem.
Well I was under the impression that they join the program to learn CS and not the otherway round. I have seen smart students who have never used a computer before do really well in my course. Also CS is not just about programming, its like other engineering branches
I was hoping for something educational and instead I found a collection of jokes that I don't find very amusing.
This is intended to be educational. Rather, it is intended (at least in part) to be yet another thing to point first-year (and later!) students to, in the hopes that they decide to absorb it for a change. Give the advice in enough forms, and maybe one of them will take.
That, and it reads a bit like it was written to vent frustration. I know I can sympathize with a lot of what was expressed there (I've had to TA programming courses many times).
While some thought is, of course, necessary I have definitely seen the problem with new programming students of thinking too much.
Basically, they try to understand the whole problem fully before writing the first line of java or C. My feeling is that this is not possible for a new student. There is just too much. Rather you just have to write code at some point. Forcing yourself to try things in code is often the only way to really get started in your first programming language. (After the first one, you should be able to think as much as you want because you should have enough background not to get lost).
I have actually noticed this problem more in girl then guys. Guys tend to rush right in and try to hack it while girls try to understand it fully first. Sometimes the hacking approach is just the necessary one. (Of course this then flips in the second or third CS course where NOT fully thinking through the problem hurts more).
Many a programmer will give you tons of insights on what not to do, but everyone and their great-granduncle seem to forget that the use of FONTS is of great important on eye-balling bugs.
Your example of the ";" could have easily caught if you use a font that makes stuffs like ";" "." "," "`" and so on FAT and OBVIOUS.
And on more thing - ENLARGE the size of the font to a comfortable degree, instead of squiming your eyes to look for ridiculously faint dot.
For programmers, although our brains are important, it's our eyes that have often been over-strained.
Muchas Gracias, Señor Edward Snowden !
If the class is not a early class in the CS flow, don't place the focus of the course on simple documentation. Also, on a scripting class like Javascript, enforce what would be asked for on your job. Inline comments. Block diagrams or system flows are more used in industry then nitty gritty flowcharts and pseudo code. As most CS projects are too small to go beyond building just a flow, I can see why they don't use block diagrams.
Classes should try to focus on teaching as much of the subject as possible in the time alotted especially if it's further down the prereq list. The subject should not be if you got your flowchart right! it should be if you got the program right AND knowing how you did it. Require the documentation, but don't let it weigh in heavy on the grade.
In my current class, there are also group projects (in a web class no less). While a little hard to deal with, it's not too bad as that is the way alot of developers are meeting.....just in e-mail or IRC or what have you.
In any case, as far as supporting others work, comments in the code and decent end user documents is all I ask.
Also, alot of languages don't lend themselves to flowcharting...so why require it?
Sorry, just venting on how far back in the times some instructors are! I spent the first 3 weeks of class learning basics....basics I learned 15 years ago.
Gorkman
I'm a CIS student, about ready to graduate. I'd already been programming for several years before I started school (and never allowed my school to interfere with my education), and I've spent a lot of time helping my fellow students, and here is some advice based on what i've seen.
Learn to love whitespaces. I don't know how many times i've seen people try to cram their code down as small as possible by removing every possible whitespace. A few extra spaces can really help you catch mistakes when your using a lot of nested parenthesies. ( ( (th) ( (i)(s) ) ) is much easier to read than (((th)(i)(s))) if your trying to make sure you don't screw up your parenthesies.
DO NOT comment every line. Seriously. Comments are a good thing, but when you comment every single cin and cout, every single bracee and function call, then it can make it a lot harder to find what you are looking for. A good rule of thumb I tell people is to comment every line you have to think about for more than 30 seconds, comment every function and class, and comment every block of code that you have to spend more than 2 minutes pondering over.
Learn to use your editor. Whatever IDE or editor you decide to use, learn to use it well. Learn to use the debugger specifically, but also get used to the environment. I don't know how many people I've helped who's problem was not with their code, but with an improperly configured IDE.
READ Error messages. This sounds obvious, but I swear people don't read them, or don't think about what they could mean. I think a lot of this comes from programmign classes that teach people to memorize syntax, without giving them an understanding of what's going on at the machine level, or what the compiler is actually doing.
If you miracously fix something, understand why. Students seem like they can not resist randomly moving code around, and sometimes this does fix things. If this happens, take some time to understand what you moved and why it might have fixed the problem
Take Breaks. This one applies to everyone. I've seen a lot of good programmers go crazy over simple problems simply because they are too stressed out to think clearly. If you start to feel stressed, tired, or your mind starts to wander, then step away from the computer, have a cigarette or a cup of coffee, take a walk, and get your mind away from the problem for a bit. Even if you have a deadline, a 15 minute break can often save an hour of frustration at the computer.
Famous Last Words: "hmm...wikipedia says it's edible"
Lindsey Lohan? Why, man, why?
Baps.
As of tomorrow I will have done 5 assignments in C++ this year. For 4 of those assignments I didn't have a compiler at my home (our program had to compile in Turbo C++, you could tell who used different compilers at home). Instead I had to go to school to debug my programs, so what I did was I'd write out my code at home in a day, go to school and then spend a few days debugging it. For 1 of my assignments (my last one) I had a compiler at home so I could debug as I go. Guess which assignment I actually enjoyed. That's right, the last one. Not knowing if my code will work makes coding unfulfilling. Spending days debugging is tedious and stressful. This just sounds plain lazy. Your code should (with as minimal effort as possible) always be compilable. If you've got a menu that calls 5 modules, write stubs for the modules. Utilise flags. This allows you to compile as you go along. Actually it's closer to "create 100 errors get 10000 error messages, try to sieve through all the messages to find the correct 100." Whereas it's much easier to go through 10 error messages to find the correct 1. You'll notice you tend to get the same 9 error messages each time, whereas having 1000 makes it a lot more difficult. And this is just syntax errors. We're not even talking about logical errors (and yes, there will be some, no-one's perfect). Actually you won't be implementing anything. You haven't implemented it until it's working. And focusing on the higher picture should be done in the PLANNING STAGE. NOT the CODING STAGE. Ideally you shouldn't even be on a computer when writing the algorithm (which is where you focus on the higher picture). You should have a pencil, a rubber and lots of pieces of paper. But even if you are on the computer it should be done in Pseudocode. I bow before your intelligence, for you can write code without debugging it at all and only have "a couple of errors." You must truly be a coding genius. That or you're talking out you're ass. I haven't met anyone who can do what you just described. Not any students and not any teachers. Either you write simple code or you're a liar and/or a troll. Because the chances of that being true is (IMO) very small.
"Oh, and here we take a local variable, which for brevity we called 'i', and let it iterate over a range from zero to the length of the array minus one (note that array indexes are zero-based here, so the last valid index is length minus one"
:(
Yeah, I can see how that would help.
Don't comment lines that don't need explaining. Comment the functions they are in, what it does, under what circumstances, and why.
Be wary of any facts that confirm your opinion.
Rudolf Diesel, the inventor of the engine, graduated from University and then went and trained as a skilled mechanic. Isaac Newton could use a lathe by the time he got to Cambridge. And Alan Turing could machine his own relays. Apart from the career options, acquiring both academic and practical skills makes you a more rounded person, and thus more employable generally.
Panurge has posted for the last time. Thanks for the positive moderations.
The moderators have been on crack ever since the moderation system started.
As far as I can tell, especially with people from an academic background (PhDs! argh!), this guide is way too advanced -- something like this might be more useful to start with:
-- Do not keep the entire project in
-- Use source control
-- Run the code before delivering it
-- NOT JUST ON YOUR OWN WORKSTATION, BUDDY!
Then, from that one could work up to 'try and ensure it is possible to install the software by some deterministic process', and only then would it be worth actually starting with actual code...
Well, they learn eventually I guess, in most cases.
Whence? Hence. Whither? Thither.
If you don't compile every few minutes, you're running your tests every few minutes.
If you're not running your tests, how do you know your code works?
If you're not compiling and testing, how are you figuring out what the code you're writing is meant to be doing?
I used to code for a day without compiling, then sit in amazement as my code compiled first time. Luckily computers are faster now and it doesn't take the better part of an hour to recompile - it takes a few seconds - long enough to pick up my coffee, take a sip and think about the next test I'm going to write.
Now that I compile more often, and run tests several times an hour, my code is immensely higher quality, I write it faster, I spend far less time sorting out compile errors and random bugs and I can safely walk away from the computer with just a couple of minutes notice without worrying about leaving a nasty mess that it'll take me a couple of hours to understand, finish and compile the next day.
In other words, thanks for the advice, I'll follow it if I want to return to where I was a decade ago.
Every /. story about programming seems to bring this tired meme out of the woodwork yet again. There never was a time when people wrote apps that do almost as much as current software in a tiny fraction of the disk and memory space.
What people forget is that old games and GUIs only had 1/50th of the pixels (and 2 of the 16 million colors) a modern display has to contend with, that their old 100KB "word processor" was really a stripped-down text editor with 3 fonts and no spelling check, DOS could fit on one floppy because it was really just a program loader and a half-hearted attempt at a shell, and "searching your filesystem" meant rummaging through desk drawers for a floppy disk! Programmers could fit apps of the time into tiny memory spaces because their programs didn't *do* much of anything, not because they had some magic ability to "code properly" that's lost on programmers of today.
0 1 - just my two bits
(Posted in "Code" so as to get the formatting right).
/All/ of your sources are using this. Someone comes along and uses an editor which inserts a tab character instead of spaces, with a 3-character tab stop. They work on a file, and check it back in.
/multiples of eights/! If developer number 2 didn't just add new functions/methods/etc. to the end of the file, and they added lines inside existing blocks, the code readability is now totally fubar.
/noise/ provides structure, and allows you to determine which close braces go with what statements. It is due to this sort of potential confusion that many non-C derived languages actually use specific close statements for each different type of open statement (ie: Pascal, Modula-2/3, Ada83/95, shell script (although for a somewhat different reason).
...
...
...
... // Oops -- not supposed to be inside the for statement
"Since modern code editors force tabs or spacing in these scenarios, I find comments like "// end if" to create more noise overall."
It's additional meta-information. And if you're working in a group where each developer gets to choose their own editor (such as in virtually any Open Source project on the web), if one user sets their tabstops to something different from the rest of the group, and/or someone starts using spaces instead of tabs (or vice-versa), you wind up with indentation problems.
For example, you're using tabstops every 3 characters, insterted as tab characters. Some guy working with your file is using 4-space tabs, inserted as spaces. They need to add a line of code below an existing line starting at column 12 on their display (ie: three tab stops in your editor). So they hit tab three times. Looks correct to them, and the editor permits it, so they save the file and fire it back to you.
/You/ look at the newly added line, and see that where the previous line starts at column 9 on your display, their newly added line starts at column 12, one whole tab-stop extra.
Or how about if you're always working with only spaces (ie: tab is set to insert three spaces, and not a tab character).
Developer number 3 checks out the file, and for whatever reason always uses the space bar instead of the tab button for indentation. Because of this, they never bothered to change their editors default tab stop of 8. They load up the file, and suddenly it's a mess: the space-stopped lines are still indented in multiples of threes, but the lines containing tab characters as inserted by developer number 2 are now indented in
And yes, I see this happen all the time, both inside and outside commercial development. You can mitigate this through education and enforcement, but anyone who does any real development work has seen this happen.
Adding what you call
And in some environment, it can be exceedingly important if you're nesting a large number of blocks. Take this simple Java example, for example:
// A fragment of Java
class MyClass {
method someMethod() {
for(int i=0;i<100;i++) {
if(i<50) {
synchronized(this) {
try {
} catch (Exception e) {
}
}
}
}
}
}
Here there are six closing tags in sequence, in short, concise, and valid code. It doesn't take much to scroll the top few lines off the top of the screen (I'll get to why your refactoring comment is invalid in a second). It is exceedingly easy to introduce errors here, such as inserting code in the wrong place, such as:
class MyClass {
method someMethod() {
for(int i=0;i<100;i++) {
if(i<50) {
synchronized(this) {
try {
} catch (Exception e) {
}
}
}
doSomethingElse();
}
}
}
This is very easily mitigated through the mechanism I've already demonstrated:
class MyC
You only catch bad cheaters, by definition.
paintball
I read his objection differently than I think even he intended it...
// end_if
// if (x%2)
}
should be
}
Or some such. The point being that you should have meaningful comments, and chances are with oodles of If's, sticking end-if after each closing brace will probably be less than informative.
paintball
I used to do that in the previous millenium, but its crap, you cant just // comment out the condition and run the code as is, you have to move the { later.
Besides it looks ugly the way you have it.
Liberty freedom are no1, not dicks in suits.
Of course, I'd very very thoroughly stepped through every code path by hand.
So where is the, not testing, part? Dry testing is testing as well. And not the worst way of testing, imho.
Yes, your code should read like a novel or at least like a well-written newspaper article or technical paper.
However, it should read like that _without_ comments! If you need to add long comments to make the code clear then fix the code first. In general, it is better to say something in code than in comments, for example 'const int x' is better than 'int x' plus a comment saying 'x will not be changed'. Well-chosen variable and subroutine names are also important. Finally arrange things in a sensible order: when writing you can either lay out the simple concepts first and use them to build up more complex things (like writing a mathematical proof) or you can start with a broad overview and then fill in the details. Either of these two styles may be appropriate depending on what your program does.
Remember: comment _how_ and _why_, not _what_.
-- Ed Avis ed@membled.com
On the other hand, with his code layout, it's clearer where the if starts and ends, and it's clearer to what the else is associated.
It's clearer for you, because that's how you got used to coding. The other way is clearer to me, because that's how I got used to it.
With regards to the vertical space wastage, this is just my personal opinion, but there is always code that is self-contained but doesn't fit on the screen in one go, and the more of it you can fit, the easier debugging becomes. There's a reason we don't use line-by-line editors anymore, it's because seeing more of your code at once actually helps you code.
Regardless though, this is a matter of personal preference. It's my personal opinion that those using the newline before brace style are making life harder on themselves, but I'll respect them if they respectfully disagree with me, and let them be.
Meanwhile, let me state that any project where more than one person is working on the code needs a coding style guide, including how to name things. I'd code the other way if the style guide told me to, because it's better to have code all in the same style than to protect your own personal opinion fiefdom.
Tripping on dextromethorphan and boosted by ephedrine.. that's Dayquil for you.
:)
It's not exactly LSD, but there's no wonder your logic was bizarre
Your assertion is too absolute.
// writing pseudo-pascal sucks
Sometimes, especially in the real world, commenting what is just as important.
In the real world, a comment like this:
Is common - in class, it got me a D when the rest of the code was well commented and the code well-formed. It was in direct protest to the assignment I was given. In reality, my fellow coders would probably agree with me.
However, that's not my point. I've written blocks of code that were hard for me to understand after I put them away for a month, not because of poorly named variables or functions, but because they made use of side-effects. A great example of this is optimization. Optimization in many cases has the deliberate effect of making your code harder to read for a number of reasons.
Duff's device is a great example of an optimization that, without explanation of what, you certainly won't get how or why.
Well chosen names only go so far. I've worked on code that used sentences for the names of some of it's DB calls. And one could say that OCI has well-chosen names, but only the bravest database programmers tackle that mess.
The great irony, of course, is that at some time in your programming career you probably will come across a genuine compiler bug, and no-one will believe you...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
If you like this approach, you might want to take a look at Knuth's "Literate Programming." One place to start is http://www.literateprogramming.com/
In either case, one needs to remember that too much can be as bad (or worse!) than too little. In real life, you may not always be the one to edit the code, and if someone edits the code but doesn't update the commentary, you can get into real trouble.
-Hil
THE MOST IMPORTANT THING FOR YOUNG PROGRAMMERS TO LEARN IS READABILITY.
Yes, code must work, it must error check and be stable. Good design is an obvious requirement. But, too many young programmers don't know the true value to business of code readability. I'm a 15-year veteran primarily in C, C++, Perl, Java, and alas, Cobol. I've seen crappy code for years as a contractor, coming in to fix problems or add features.
The statistics on business costs bear me out. Nearly 50% of the cost of a program is incurred during the long in-use / maintenance phase. There are definite rules for making code readable and they should be taught early.
Practice during programming classes should include:
* Code reviews - other people looking at your code;
* Code reviews - reviewing other people's code and asking lots of questions;
* Style guides - rules re: what coding style (where to put curly braces, for one) to use on a project are common, be prepared for them;
* Simplification paradigms - stuff like avoid do_while loops since they're seldom used and often just confuse people;
* Reliability lessons - lessons like don't use while(1) loops with breaks, rather for(1..n) with an overlarge n and subsequent test if N got big to know if things failed;
* Max Subroutine sizes - too often violated but a bigger deal than you think;
* Global variable minimization - sometimes it does make it simpler to use a global variable, just keep it to a minimum;
Lots of these rules apply. SIMPLIFY! SIMPLIFY!
It speeds up everyone's life.
--Kevin
Unitarian Church: Freethinkers Congregate!
Sorry to say that man, but you really got lost on the irony in the text. Or you are so used to skimming over 100+ pages of literature at insane speeds doing your PhD research that you just can't slow down while reading anymore. :-)
Computer Science is a good major to be in. It is useful, hard and interesting at the same time. However, given the fact that IT job cuts are on the rise, students should learn more things than just coding.
I am a recent CS grad. I work in the field and yet I am thinking of getting a second degree that is not related to computer science because I realized that in several years developers who know only one thing -- that is coding -- will become extinct. What you need to teach CS students is how to develop valid and correct solutions that can be used by real people and businesses. These solutions must be well designed first; then developed. If I got a cent for every piss poor designed program that I have seen in my life, I'd be Bill Gates :)
Developers solve problems with code; however, just because you have an ability to write a program does not make this program a valid solution! I have noticed that there are too many people with excellent software engineering skills that are simply out of touch with reality and its business side. If your "cool" program does not solve a problem it is absolutely useless in the real business world (the world where you get a pay check for what you do).
Despite being relatively young, I have been employed in the field during all downturns. I managed to survive using only one rule: you must come up with solutions that are valuable for customers who are willing to pay for it. Unfortunately, many of the recent comp. sci. grads do not understand this rule. Instead of focusing on real life and its business needs, they spend their time learning languages without even knowing what these languages are good for. Then they use wrong tools for wrong tasks. My favorite example is my friend who used J2EE to build a site that could have been (and should have been!) done in PHP. He spent half a year on the fucking thing just to realize that a simpler solution could do everything that he wanted!
Then there are people who run into terrible coding problems because their design is flawed. For some odd fucking reason people never think before they start implementing. I use one great rule: software engineering does not provide efficient solutions for some of the problems. Period. Too many people jump into coding without even thinking about the problem. They waste their time on something that can either be done manually with lower cost OR cannot be done at all. The worst thing is that most of these people are afraid of throwing their initial design away and starting from scratch...
With this in mind, here is what I think every comp. sci. student should know:
How to meet business needs with software engineering. How to "read" requirements and come up with solutions that meet them.
How to realize that your design leads to implementation problems and when to throw such a design away.
A well-written program is good. A well-written program that meets customers' needs is better.
How to use a right tool for the right task.
How to become employed and stay employed.
How to use computer science in various aspects of real life. When I am talking about real life, I am talking about something useful that can be actually used by people. I found out that this can be achieved by taking a second minor or getting a second major that is not related to technology.
Yeah, well if the college actually followed through and expelled plagiarists maybe people would think twice before doing it?
Over half of my networked operating systems class was caught cheating on a machine problem (write a UNIX shell with job control and I/O redirection). The professor announced this during class and said whomever came forward wouldn't face any punishment. The college handbook clearly says that this is an offense that may result in explusion from the University. What happened? Not only did the University not expell any of these students, the professor wouldn't point them out in class so the rest of us knew who they were.
During an exam for a linear algebra class, I saw students pulling crib sheets out of their backpacks and placing them between their feet during the exam. Surely the proctor saw this (~35 students in the class), but nothing was done.
If colleges want to cut down on cheating, they need to start enforcing their own policies.
- Fix the first one and the first one only .
Actually, I fix the first one and any similar errors that I know I committed elsewhere.
A corollary to this is:
"When your code compiles cleanly, it is ready for testing and debugging."
The net will not be what we demand, but what we make it. Build it well.