Don't you find it frustrating when someone starts a thread and requests help
with code that they obviously haven't checked?
"I've created this code" really gets up my nose when the comment lines( such as '// enter your words here')
show that it's just been copied from somewhere.
Download a reference manual and use it is my advice.
I'm not an IT professional, I'm a hobbyist, and I've learned all I know by research, and testing and more of the same!

mvmalderen commented: This thread is a nice idea, I've read alot of interesting things already ;) +0
bguild commented: Fun thread! +0

Recommended Answers

All 16 Replies

Precisely sir. And if I may add, there's nothing more rewarding than finding problems in your code and being able to solve them with your own research and work, :D;

Member Avatar for diafol

Don't you find it frustrating when someone starts a thread and requests help with code that they obviously haven't checked?

Absolutely. This is precisely why we try not to offer solutions, but guide the poster to his / her own. In these circumstances, I think a polite,

"Why don't you ask the guy who wrote it?"

or

"Does the site from where you copied this code have a help forum?"

would be sound advice.

However, we need to be circumspect, as we often build client code, so the comments, such as the '// enter your words here' may indeed be our own.

Download a reference manual and use it is my advice.

That's too much work when they can just post their problem to umpteen forums with the expectation that some kind soul will do it for them.

I'm not an IT professional, I'm a hobbyist, and I've learned all I know by research, and testing and more of the same!

Even among professionals, you're a rare breed. More and more I find that I can no longer assume that the developers and IT specialists I work with have any clue how to do their job.

commented: That secures your job position :D +0

I also agree. When I was working on a team several years ago, I was senior member and young people was ask me how to do this or that. My response: RTFM! and use google to do research. If they still couldn't figure it out then I'd help them. It's surprising how much we can learn by reading manuals, learned a lot more than I had intended.

More and more I find that I can no longer assume that the developers and IT specialists I work with have any clue how to do their job.

The worst is when the only skill that people develop during a programming course is their skills at finding code on the web and disguising it as their own. At some point, it gets to the point that they even believe that they did it themselves. A while back I delegated a simple coding task to a senior computer science student that was part of my robotics team. It was a simple pattern-matching task, no big deal, maybe a few hundred lines of code or so. It took him about 3 months to get it done and what he delivered was clearly pieced together from 2 different sources, and still had the original authors' names in most of the source files. And of course, the code was completely inappropriate for the task given. And when I confronted him to those facts, he couldn't understand why I would say that he didn't do the work, but said that of course he didn't literally write the actual code himself, as he said "nobody does that anymore", some programmer he is. It never occurred to him that his programming courses were trying teach him to be able to write the actual code himself, he thought the point was to have a vague understanding of it and be able to cobble up code from the web to solve his problem, afterall that's all he ever had to do during his courses. And, of course, I had to write that code myself in a few hours at the last minute.

I also agree. When I was working on a team several years ago, I was senior member and young people was ask me how to do this or that. My response: RTFM! and use google to do research. If they still couldn't figure it out then I'd help them. It's surprising how much we can learn by reading manuals, learned a lot more than I had intended.

I totally agree.

I sometimes get a disparaging feeling that the coming generation (in high-school and undergrad today) has a bit of a generalized feeling that a lot of things (i.e., technologies) reside in black boxes labeled "magic" and it's forbidden to look inside. But at the same time, they want to work on or be experts about those very same things that they are not really willing to seriously look into. You hand them big manuals or spec-sheets, or any significant chunk of code, and they panic and freeze and don't know where to begin or what to do. They seem to somehow think that older people had their knowledge beamed into their brains, and somehow they'll never get it, and the worst is when they don't even seem interested in seeing how you do it when they finally get you to do it for them (by trickery or a pressing deadline).

For example, you give a task to a novice, knowing that you could do it in 20-30 minutes, you given him a day to do it, just to make sure he has plenty of time to learn to do it himself, and ask specific questions about it, but because he knows you can do it in 20-30 minutes he thinks "what's the point of even trying", so he waits one day, then says he couldn't figure out how to do it, and so, you sit down and get it done quickly to be able to move on with the schedule. The only real delusion here is the novice thinking that he got the best of it as he didn't need to do or learn anything, what a fool. He missed an opportunity to learn a useful skill and/or to shine for his accomplishment, and you lost 20 minutes of your day (which you probably would have lost anyways at answering his questions if he had seriously tried to do it) and now, you know who not to hire or promote in the future. Who's the loser?

Those kind of questions give people the opportunity to increase their post count by saying "Where is your code" or any of the excuses that was written above... but what annoys me most is that they never mark the question solved nor do they ever return after a maximum of 3 posts...

It never occurred to him that his programming courses were trying teach him to be able to write the actual code himself

He probably heard the pie-in-the-sky promises of OOP about code reusability and took it to the extreme. Like the guy who wanted to close the patent office decades ago because everything had already been invented, he thought that all the useful code had already been written.

We're back to diafol's post in another thread. Too many people grew up having things handed to them instead of having to work for them. When it comes to actually putting in the effort they figure it's easier if someone else does the work for them.

I sometimes get a disparaging feeling that the coming generation (in high-school and undergrad today) has a bit of a generalized feeling that a lot of things (i.e., technologies) reside in black boxes labeled "magic" and it's forbidden to look inside.

When I was in my third year of University, homebrew computers were being sold at the Byte Shop and we had just received a Comemco (I think) 8080 based micro computer (yes, I'm that old). I wanted to see how the magic worked. The cover was off that sucker more often than not. My younger son had a course in how computers work at the micro-code level. He wasn't crazy about it but I would have loved it (even though I agreed with him that his professor was a major league a$$hole).

I'm happy when they at least have gathered some code of the internet. It seems to me that the patern nowadays is that if a wizard or a drag&drop can't make it happen then it can't be done.

I'm professional now, and 100% of that comes from self-research. It is without doubt the best way to learn.

do research. If they still couldn't figure it out then I'd help them

Ancient Dragon sounds exactly the same as my professor at oxford!!! The best years of my life, happy times :')

A lot of my frustration is gone now that I'm retired. Most of it had to do with people who wouldn't do their job properly leaving me to take up the slack.

Case in point:

A programmer in another group was responsible for FTPing files to our server every five minutes. His process guaranteed that if there were any delays on his side the process would fail. A simple mod would have fixed the problem (FTP using a temp file name, then rename the destination file). He wouldn't do it, leaving me to write some kind of crapware that would guarantee (it couldn't) that the files always arrived intact.

Case in point:

Coworkers who do the exact opposite of what is needed to fix a problem such as when the users complain about slow network response and his solution is to start copying multi-gigabyte files continuously to "stress" the network even further.

These days I just carp about old people who stop in the doorway of the grocery store exit for two minutes to look for their car keys or couples who walk slowly side-by-side down the aisles without regard for the people behind them. And people who talk non-stop in movie theatres.

Actually, I try to stay home a lot.

Member Avatar for diafol

What about taking a therapeutic class to ease the old frustration? French lessons, for example? :)

@diafol - That is absolutely the funniest thing I have heard in weeks. You made my day.

The worst is when the only skill that people develop during a programming course is their skills at finding code on the web and disguising it as their own. At some point, it gets to the point that they even believe that they did it themselves.

I agree, to some extent. However, sometimes "people/students" are encouraged to use code that has already been written. For example, in my undergrads I had to develop an algorith that used an FFT (Fast Fourier Transform) and it would be impossible/not pratical for me to write my own because:

1) I wasn't improving, editing or adding to the algorithm
2) I didn't have enough time to test my algorithms (in-depth) because that would require my whole year.

I agree that a lot of people come onto forums specifically asking you to do their homework, and, it's usually people who are in higher education and have the choice whether or not to do programming and I get the impression that some people just don't enjoy programming, yet study it? (Has it got some "magic" attraction that I dont/didn't know about?).

For example, in my undergrads I had develop an algorith that used an FFT (Fast Fourier Transform) and it would be impossible/not pratical for me to write my own because:

Sure. But there's a difference between choosing not to reinvent the wheel for good practical reasons and not being able to reinvent the wheel when required. In some cases, you are required to write an algorithm from scratch, e.g., because you need to add some twist or feature to it, because you need to stream-line it to your application, because you are borrowing ideas from a few different algorithms to make a new one, because you can't find a suitable off-the-shelf implementation that you can use directly, or simply because the algorithm is completely original. In any of these cases, you have to be prepared and able to sit down and competently write a good implementation (including the testing that ensues). And that's the whole purpose of getting CS students to write classic algorithms like sorting algorithms or basic numerical methods (like FFT). But if they sort of skip that under the pretence of "don't reinvent the wheel", well, they never acquire the most basic skills a good programmer needs.

2) I didn't have enough time to test my algorithms (in-depth) because that would require my whole year.

Well, an FFT algorithm can be written and thoroughly tested within at most a few days, by a competent programmer, that is. This also goes to the point of not reinventing the wheel. Re-implementing a classic algorithm is not so much re-inventing the wheel as it is building a wheel from existing, detailed blue-prints. If I implement a quick-sort algorithm, I'm not really thinking and designing an algorithm from the principles of trying to sort a series in the most efficient way and coming up with this algorithm after a ton of analysis and experimentation. All I do is read the description / pseudo-code and write real code that does that, and then I test it out a bit to make sure I didn't make a mistake in writing it (no need for thorough testing, just tests to establish correctness). It's more like grabbing the blue-prints of a machine and building it, which is a rather trivial task if you have the practical skills.

And the point is that without those skills, the task can seem insurmountable, and hence the "that would require my whole year". And if you get paid to design a machine / algorithm, you have to build prototypes / implementations, and if you're not good at that, then you're no good at all. And the better you are at the latter, the more time you can focus on the former, and your employer gets more bang for his buck.

basic numerical methods (like FFT).

I wouldn't call an FFT "basic numerical methods" when I studied CS I was told not to go anywhere near such methods because they were not taught, and only one person in our University knew what they were. However, I was determined to understand the mathematics behind them. It depends on the programmer, I mean, you may see concepts such as FFT's basic because of your knowlege and experience and, of course, your academic background.

Well, an FFT algorithm can be written and thoroughly tested within at most a few days, by a competent programmer, that is.

Ok, so a year was a bit of an exaggeration on my part so I apologise for that. ;)!

I agree with the points you make, however, it depends on where you get taught as well, right? For example, some Colleges/Universities have lecturers that are just focused on researching and not teaching and often give their students the advice:

"Go Google it" ->

"Google is your best friend" ->

etc..

They do not specifically ask for code to be written from scratch (which is bad!) and most of the time, do not ask you to follow a structure like pseudocode. Which is why in my opinion we now have this idea where it is just second-nature to google the type of algorithm that they need and then submit it, or, post it on a forum. Which is why, when they come to having interviews, or, actually being in a job they cannot handle actually writing code from scratch.

I agree with the points you make, however, it depends on where you get taught as well, right?

Well, what you should be taught does not depend on where you get taught. But it does depend on the focus or specialization that you are concentrating on. If you are studying general CS, then a cursory look at FFT algorithms might be interesting, but no more. But if you're doing image processing or pattern recognition or something along those lines, then it is probably well worth the effort to get a good grasp on those algorithms, including implementing them and tweaking them.

But if your curriculum is so general that it doesn't require seriously looking into (and implementing) any kind of algorithms or methods, then does that make you a competent programmer? No. It's like studying art without developing any particular artistic craft of your own, and calling yourself an artist when you're done with your studies just because you have a cursory knowledge of trends and techniques used by actual artists. Such an art curriculum might be good to do art appraisal or trading, but no more.

Some people go through a CS curriculum in much the same way (whether it's their fault or their school's fault, usually a bit of both), but then, they apply for programming-intensive jobs, under the self-delusion that they are actually competent at programming. Part of the problem is that there aren't too many jobs for computer scientist who are incompetent at programming, and CS knowledge is often equated with competence at programming, which is very wrong. Competence at programming usually implies a good amount of CS knowledge, but much less so for the converse.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.