Follow Slashdot stories on Twitter


Forgot your password?
Take advantage of Black Friday with 15% off sitewide with coupon code "BLACKFRIDAY" on Slashdot Deals (some exclusions apply)". ×

Comment Re:Power for businesses (Score 1) 103

First it means he can code (or hack) really small things. It's not an indication he would fare well in big, long-living projects.

Please take also into consideration, that coding is one of the smaller tasks a programmer does. Most is reading, reasoning, planning as well as learning. It does not help if you have the fastest guy in Lisp if he can't learn new things as fast as it's needed.

I am student, worked in projects, that existed for many years and had for the most part more than 15 coders simultaneously and take part in CodeJam and TopCoder competitions. Big projects and speed coding require totally different sets of skills.

Learning by the book is only part of it. With only learning by the book, you will get the so called "self-taught programmers" which I would keep out at all costs. What one really need to improve is constructive criticism by experts or at least people better than oneself. Anything else is just an echo chamber.

Comment Re:Similar issues in other fields, not a perfect f (Score 2) 118

I also had this problem. And when I asked an PhD student about a thing that seems suspicious in his papers experiment setup he admitted that it's actually not as great as described.

Another big problem is research in development processes like Scrum, XP, Waterfall etc.. I argued quite a bit with my professor as all the experiments cited where like "take a bunch of students and let them work on a toy project, which never has changing requirements and is tiny in code size." Well this of course can't be used to make any conclusions of real software projects with real programmers, yet the results where generalized. This is just bad science. And we should call people out for it and definitely not publish this stuff. A better but still wrong approach was getting real programmers and let them work for _one_ day. This is outright ridiculous. What would be the result of this? The problems in software projects arise after _months_ not hours. Also people need time to get used to a style of working, which will at least take a couple of days.

Even worse the professor was really in awe with this experiment, as somebody actually used real developers. When I talked with him about this flaw he just waived his hands telling me, then no real experiment could be conducted. This is actually right, but what he meant was actually: this is better than nothing. I strongly disagree.

Comment Re:I would be too (Score 1) 285

Also allow me to remark, that working overtime also is not necessarily a sign of professionalism, maybe even a sign of absence. I know how many hours I can work, before I am mentally exhausted and will introduce more errors / damage then benefit. As a professional thus I will insist staying below this threshold for the better of my employer and myself.

Comment Re:I would be too (Score 1) 285

A contract is two-sided. If one sides wishes to divert from the agreed-on terms I am sure the other side will be open for honest renegotiation so everything stays fair.

Also working overtime is a sign of bad planning, which might be the workers or his managers fault. Either the worker agreed on deadlines he should not have accepted or the manager tried to put too much work on the worker. Yet it should have been noticed early enough and the time / work could have been renegotiated. This of course requires professionalism of both sides: Don't try to hide your errors and give a early enough notice, and listening to employers and accepting that errors _are_ happing, if you are told or not.

Comment Re:One thing to keep in mind... (Score 1) 244

I disagree: Give me a really concise documentation and if there is still time then go wild on a conversational info page / demo / tutorial / best practices

  First one should be easier and faster to do and you can always reference to it for details in the more wordy thing. Examples and explanations are important especially if one just starts using the software / API, but cumbersome if I only want to know the expected boundaries of a parameter or so.

So both are important, but for different things. Probably one should not skip any of these. ;)

Comment Re:Peanuts (Score 1) 411

The thing you linked more or less said design pattern are bad because... he doesn't like it. He says there is no scientific proof they are good and thus they must be bad (without giving any proof) and because people used them wrong and introduced unnecessary complexity. The argumentation of the GoF is as sound or unsound as his. I can always construct an argument against something if I point out how it is used incorrectly. By this argumentation Assembler, C, C++ and actually every programming language is bad, because I can write really messy code.

I wrote that design patterns are usefull to _me_, yes. I can't generalize my experience, of course. Yet I learned design patterns only quite some years after I started programming. And I really prefer it this way over everyone reinventing the wheel. The code bases I worked on were many years old and more than a million lines of code or so. It just would not have worked without design patterns and code formating rules.

The problem is, that there are almost no useful experiments in software engineering. Each one I saw until now was set up way too small, too short or used students instead of professionals or any combination of this. Really good experiments are just wayyy too expensive, as you would have to watch programming efforts with and without, on the same project, over years, with professionals. Nobody will finance that, unfortunately. And case studies are just case studies and can't be generalized. Thus it is hard to scientifical sound say what is bad or good. It would be great if we could, of course.

Comment Re:Peanuts (Score 1) 411

Forgot to note, that patterns also improve communication, as you can just say, you used the observer pattern and everybody (hopefully) knows what it means. Moreover by just harmonizing the code, so that the same problem is always solved the same way, you don't have to dig deep into the implementation to see what is going on. You see ItemsPurchasedObserver and you have a rough idea what's going on. On top you are not forced to reinvent the wheel for the millionth time.

Nothing will ever be attempted if all possible objections must be first overcome. -- Dr. Johnson