I guess it depends on what field you're in. If your field has 3 months of hard work implementing a system in order to be able to get any results at all, you probably won't have that kind of problem - it tends to weed out the people who aren't willing to put in the effort.
Unless you go to a foreign country where the meaning of "a lot" is much lower.
Which some companies are fighting tooth and nail to do.
Having quite some exposure to developers from a country where "a lot" is a lot less than "a lot" over here (over here being western Europe in my case): the best of those "cheap" developers are rapidly getting smart, and realizing that they can make several orders of magnitude more money if they move to where employers are willing to pay more. Quite a few of the "cheap" top developers are no longer staying in the "cheap" locations because they know they are worth more and can get those jobs if they want.
So the cries you hear might actually mean that cheap-arse employers are finally starting to find it difficult to exploit cheap but great developers from low-pay countries.
In fact, the point made in the GP's post is valid: the company I work for is nowhere near top 5%. We have some excellent talent from (not necessarily any longer IN) eastern Europe, and we try to coddle them as much as we can, but we have lost several of them to places like Google in London and Geneva. We don't blame them, in fact we congratulate them, because we care about our people enough to let them go if they get an offer we can't possibly match (financially or in "sexiness" of the job and company they are going to). Some of them come back to us after being burned out on "big company culture" too. It's the best we can do.
It's fine if you're writing code in.net targeted at a Microsoft platform. If you're trying to do something cross platform, or use a different language, or use a Makefile, or Maven, it's not so great.
We do most of that just fine - generating our native C++11 Visual Studio solutions and projects with CMake (along with the XCode OSX and iOS versions).
In languages with side-effects exceptions force the caller to handle the error if they want to continue operation, instead of silently assuming that everything went right and inadvertently propagating a potential problem all the way up to the first place where the error condition actually matters. So in my opinion it's actually the exact opposite of what you state: if you would like someone to catch and recover the error rather than just bombing out late and at odd times due to bad programming, throw an exception. It'll bomb out early, and give the offending programmer a good kick in the shins about not checking for errors.
That doesn't mean I think both of your examples are fine: the first case is just stupid - there IS no error if you're hiding a dialog that's already hidden. The second case should be local: you're opening a file, and if you then don't have a file descriptor you're going to have a more serious error REALLY quickly afterwards (unless you have terrible programming, but then you have terrible programming, and no amount of exceptions will help there!). In the file case it's actually even more different: there's usually no error code, you just have a valid file descriptor or you don't, and people learn quickly, so exceptions are not necessary.
When it comes to error/success return codes.... I've seen a lot of code containing macros to check the return codes and then throw an exception on failure;-).
I understand the train of thought, but I feel the conclusion is wrong. The correct conclusion is that OO design following accepted "best" practices (the SOLID principles) makes for difficult-to-navigate code. That doesn't necessarily mean that I think OO design is bad, it just has some pretty major downsides when it comes to navigability if you don't have good support from your development environment.
I remember reading somewhere about a system that does away with the concept of "files" entirely, and the whole coding process is based around smart navigation - what's on your screen could be pulled from many different locations at once without you having to know where from - shame I can't recall where I read that exactly.
Coding style is not just be about making code look pretty (according to someone's personal definition of pretty). The purpose of a coding standard is to make the code more readable and thus, more understandable. Having the code look consistent helps in that regard.
No, it doesn't. Making the code more consistent just makes it more consistent in whatever readability state it started, which might be total batshit insanity if you actually think applying a coding standard is going to make your life noticeably easier (but hey, now at least it's consistently shit!).
I'll take a stylistic mix of well-written but readable code over hundreds of pages of unenforcible coding standard (note: coming from a C++ background, where automatic beautifiers can do a better job fucking up your code than an ex-Java programmer that hasn't been told about manual memory management).
I can read Shakespeare, Tolkien, Edgar Allan Poe, HP Lovecraft, M.R. James and Robert E. Howard just fine, and they don't have the same style at all. Okay, it took some getting used to Shakespeare, but then the style actually added to what was being expressed. Learn to read each-other's code, dammit. It's already more than structured enough - it's a PROGRAMMING LANGUAGE. That anal retentive thing called a "compiler" does more than enough. Decent developers always have a perfectly acceptable coding style of their own, and will make small adaptations to the common implicit standard where appropriate.
I find it a bit strange that these trading systems don't seem to use some kind of identification (like signed certificates). How is it possible that some system did these things and the stock exchange doesn't immediately know whose system this was? This sounds like a disaster waiting to happen.
Another BIG reason that you see a lot of friction against writing documentation:
No matter what the OP and many people in this discussion claim, no-one ever reads it anyway. "WTFM" is all-too-often actually shorthand for "explain it to me like I'm a retarded five year old, again, because I didn't listen the first time". In my almost Dilbertian experience the amount of sheer pig-headed ignoring of everything you've written (or said) increases proportionally to the effort put in. So the end result is that you write exactly *nothing* until someone starts asking you directed, specific questions, to avoid a monumental waste of effort.
Gah, slashdot ate my formatting. I was replying to "it's hard to find most information online", when the posted article clearly indicates that some information was rather too easy to find online.
As a member of the IEEE I have to admit we have the worst web site you can imagine. It constantly asks for login information as you try to browse and it is hard to find most information online.
. We need to go back to the drawing board and figure out a better way to get the message across, including tools to make it easy for people to get it right.
Maybe it would work if we could get a battery-powered horse to staple the correct message to people.
Only a programmer could come up with a *fictional* romance story where the utter pinnacle of the protagonist's romantic achievement is embarrassment at a single stolen kiss.
It's a bullshit made-up story, it's misogynistic, and it draws a general conclusion from the flimsiest of data. Kill it. With fire. From orbit.
The difference is that I have 20+ years of experience with a variety of technologies and projects and he has 3 months experience shovelling whatever the higher ups tell him is the best product, what he reads on the internet, and what he hears from his friends.
But in custom software development this situation is nearly always reversed. The customer might have 20+ years of experience doing the business she's doing, but she knows next to nothing about developing software, and has probably developed a very myopic view of the problem and its possible solutions. That's where the guys with software development experience, and experience in solving problems from multiple domains, can come up with a solution that's much better for the actual problem that needs solving.
he simply sounds like a persistent man. Have we come so far that persistence is considered evil?
No means no. If the person in question cannot see that persistence after clearly being told to back off is wrong, then he needs to seek some counseling before they end up doing something a lot worse than be charged with harassment after misinterpreting signals from a woman that's (at least initially) actually interested in him.
Slashdot Mirror
I guess it depends on what field you're in. If your field has 3 months of hard work implementing a system in order to be able to get any results at all, you probably won't have that kind of problem - it tends to weed out the people who aren't willing to put in the effort.
You meant "it tends to weed out the people who aren't willing to fake their data", right?
They probably shipped them with the free carpware virus checker.
Carpware? Sounds fishy.
Unless you go to a foreign country where the meaning of "a lot" is much lower. Which some companies are fighting tooth and nail to do.
Having quite some exposure to developers from a country where "a lot" is a lot less than "a lot" over here (over here being western Europe in my case): the best of those "cheap" developers are rapidly getting smart, and realizing that they can make several orders of magnitude more money if they move to where employers are willing to pay more. Quite a few of the "cheap" top developers are no longer staying in the "cheap" locations because they know they are worth more and can get those jobs if they want.
So the cries you hear might actually mean that cheap-arse employers are finally starting to find it difficult to exploit cheap but great developers from low-pay countries.
In fact, the point made in the GP's post is valid: the company I work for is nowhere near top 5%. We have some excellent talent from (not necessarily any longer IN) eastern Europe, and we try to coddle them as much as we can, but we have lost several of them to places like Google in London and Geneva. We don't blame them, in fact we congratulate them, because we care about our people enough to let them go if they get an offer we can't possibly match (financially or in "sexiness" of the job and company they are going to). Some of them come back to us after being burned out on "big company culture" too. It's the best we can do.
It's fine if you're writing code in .net targeted at a Microsoft platform. If you're trying to do something cross platform, or use a different language, or use a Makefile, or Maven, it's not so great.
We do most of that just fine - generating our native C++11 Visual Studio solutions and projects with CMake (along with the XCode OSX and iOS versions).
In languages with side-effects exceptions force the caller to handle the error if they want to continue operation, instead of silently assuming that everything went right and inadvertently propagating a potential problem all the way up to the first place where the error condition actually matters. So in my opinion it's actually the exact opposite of what you state: if you would like someone to catch and recover the error rather than just bombing out late and at odd times due to bad programming, throw an exception. It'll bomb out early, and give the offending programmer a good kick in the shins about not checking for errors. ;-).
That doesn't mean I think both of your examples are fine: the first case is just stupid - there IS no error if you're hiding a dialog that's already hidden. The second case should be local: you're opening a file, and if you then don't have a file descriptor you're going to have a more serious error REALLY quickly afterwards (unless you have terrible programming, but then you have terrible programming, and no amount of exceptions will help there!). In the file case it's actually even more different: there's usually no error code, you just have a valid file descriptor or you don't, and people learn quickly, so exceptions are not necessary.
When it comes to error/success return codes.... I've seen a lot of code containing macros to check the return codes and then throw an exception on failure
I understand the train of thought, but I feel the conclusion is wrong. The correct conclusion is that OO design following accepted "best" practices (the SOLID principles) makes for difficult-to-navigate code. That doesn't necessarily mean that I think OO design is bad, it just has some pretty major downsides when it comes to navigability if you don't have good support from your development environment.
I remember reading somewhere about a system that does away with the concept of "files" entirely, and the whole coding process is based around smart navigation - what's on your screen could be pulled from many different locations at once without you having to know where from - shame I can't recall where I read that exactly.
Coding style is not just be about making code look pretty (according to someone's personal definition of pretty). The purpose of a coding standard is to make the code more readable and thus, more understandable. Having the code look consistent helps in that regard.
No, it doesn't. Making the code more consistent just makes it more consistent in whatever readability state it started, which might be total batshit insanity if you actually think applying a coding standard is going to make your life noticeably easier (but hey, now at least it's consistently shit!).
I'll take a stylistic mix of well-written but readable code over hundreds of pages of unenforcible coding standard (note: coming from a C++ background, where automatic beautifiers can do a better job fucking up your code than an ex-Java programmer that hasn't been told about manual memory management).
I can read Shakespeare, Tolkien, Edgar Allan Poe, HP Lovecraft, M.R. James and Robert E. Howard just fine, and they don't have the same style at all. Okay, it took some getting used to Shakespeare, but then the style actually added to what was being expressed. Learn to read each-other's code, dammit. It's already more than structured enough - it's a PROGRAMMING LANGUAGE. That anal retentive thing called a "compiler" does more than enough. Decent developers always have a perfectly acceptable coding style of their own, and will make small adaptations to the common implicit standard where appropriate.
Because the wording of the court judgment didn't ask Apple to publish the wording of the court judgment, it asked something else.
Developers! Developers! Developers!
Developers?
[sound of crickets]
The War Cry of Microsoft if about to change. They are shortening it a bit:
ELOPERS! ELOPERS! ELOPERS!
Please come back?!
Of course Apple launched them quietly after all the flak they took for hearing damage caused by loud iPods.
I find it a bit strange that these trading systems don't seem to use some kind of identification (like signed certificates). How is it possible that some system did these things and the stock exchange doesn't immediately know whose system this was? This sounds like a disaster waiting to happen.
Regulation BAD. Free market GOOD. RRROOOOOAAARRRR!
Another BIG reason that you see a lot of friction against writing documentation:
No matter what the OP and many people in this discussion claim, no-one ever reads it anyway. "WTFM" is all-too-often actually shorthand for "explain it to me like I'm a retarded five year old, again, because I didn't listen the first time". In my almost Dilbertian experience the amount of sheer pig-headed ignoring of everything you've written (or said) increases proportionally to the effort put in. So the end result is that you write exactly *nothing* until someone starts asking you directed, specific questions, to avoid a monumental waste of effort.
This is like when in an interview, the interviewer asks "What are your weakness", you say "Sometimes I work too hard".
Or "I'm not a sore loser, I just have no experience with it.".
It was highlighted correctly in the preview :)
Gah, slashdot ate my formatting. I was replying to "it's hard to find most information online", when the posted article clearly indicates that some information was rather too easy to find online.
As a member of the IEEE I have to admit we have the worst web site you can imagine. It constantly asks for login information as you try to browse and it is hard to find most information online.
Are we reading the same article here? ;-)
. We need to go back to the drawing board and figure out a better way to get the message across, including tools to make it easy for people to get it right.
Maybe it would work if we could get a battery-powered horse to staple the correct message to people.
Also, I challenge you to come up with a symbol for saving files without using a diskette or something like that.
A crucifix ;-)
(No, I'm not serious).
I've been using that for years. I give Windows the finger daily.
Only a programmer could come up with a *fictional* romance story where the utter pinnacle of the protagonist's romantic achievement is embarrassment at a single stolen kiss.
It's a bullshit made-up story, it's misogynistic, and it draws a general conclusion from the flimsiest of data. Kill it. With fire. From orbit.
In the US, if the US had spent trillions of dollars on its people, instead of on wars, there would be no poverty in the US at all.
Some might argue there would be no US at all ;-)
The difference is that I have 20+ years of experience with a variety of technologies and projects and he has 3 months experience shovelling whatever the higher ups tell him is the best product, what he reads on the internet, and what he hears from his friends.
But in custom software development this situation is nearly always reversed. The customer might have 20+ years of experience doing the business she's doing, but she knows next to nothing about developing software, and has probably developed a very myopic view of the problem and its possible solutions. That's where the guys with software development experience, and experience in solving problems from multiple domains, can come up with a solution that's much better for the actual problem that needs solving.
I did once, but its value wasn't saved properly across calls.
he simply sounds like a persistent man. Have we come so far that persistence is considered evil?
No means no. If the person in question cannot see that persistence after clearly being told to back off is wrong, then he needs to seek some counseling before they end up doing something a lot worse than be charged with harassment after misinterpreting signals from a woman that's (at least initially) actually interested in him.
Aside from game obsolescence, it's not all that different from competitive sports.