These days I'm mostly comfortable in reading reactions from people of the opposite sex, but back when I was in my late teens and early twenties, it would be really difficult to avoid misinterpreting the situation occasionally.
It's a sad fact of life where there's always some tension between people of the opposite sex, but you make it sound as if it were so easy to navigate the situation. It really isn't, especially for those who generally have much less successful experience (you really need to have two control groups before you can tell the difference between them).
[offtopic] That being said, I wonder whether it's really a good idea to blame it all on the "sex" part of "sexual harassment". I mean, as a straight male I'd probably feel uncomfortable around creepy people badgering me for whatever reason even if they probably don't have any sexual interest in me..... It's the "harassment" part that needs to be dealt with, IMHO. [/offtopic]
I agree with your statement generally, but the commonly accepted solution against unintended assignments in the if conditional is to add an extra set of parenthesis -- which is literally bending code style so that compiler (at least the static analysis tool) will catch violations.
Perhaps you'll also learn not to take comments on Slashdot seriously.
Seriously though, it's hard to believe *anything* taught in schools at all would be helpful (without proper interpretation). Different problems require different solutions and different processes, and not every solution / process fits the problem. So far, all the crap floating around claims it's the best thing since sliced bread, but they don't really tell you the context in which their solution works (and they probably don't have sufficient perspective to tell you anyway). Your professor in school is probably clueless as to their differences anyways, anyone who is intimately involved in real-world software projects don't have time to teach.
That being said, before you dismiss the stuff in your textbook and lecture notes, be aware that a lot of the software processes are for *long term*, *medium-to-large scale* projects. Your weekend project doesn't have to follow those processes, and probably shouldn't. There is a difference between code monkeys writing "code" and somebody who understands the "software engineering stuff" as well. I wouldn't attempt to make serious distinctions between "programmers" and "software engineers" and what not. They're merely stupid labels. Most people fall between the extremes -- although these days, with everything becoming a software/data problem, people from non-software disciplines occasionally have to write programs, especially in the scientific/engineering fields. They might be able to cobble together something that works, but I wouldn't trust them to run a 10-man software project.
If you read what the GP said, it never said it was "all right". In fact, I think it's pretty clear that GP was implying that violating IP rights isn't something to be proud of.
Two wrongs make two wrongs, and it's just fair that both are mentioned.
It seems you're complaining that somebody is presenting the full picture. It might be irrelevant, but hey, you're not complaining about it being offtopic.
I've had my own intensive "eat sleep code repeat" cycles back in high school, which is more than a decade ago. That's probably when I went from being a shitty programmer (by adult standards) to an OK programmer. These days I mostly fool around random things when I'm not working, instead of being a beta tester for some bleeding edge software development stack (that's what I secretly think of developers who use RoR and node...)
The "eat sleep code repeat" cycle is probably quite effective initiallly, I just think there are diminishing returns to this approach. If you've done this thing for (say) 10 years already, you probably don't need another twenty years doing the same thing -- it either gets repetitive (which, especially in this field, isn't exactly a good thing), or you've managed to continue to innovate, but by then you've probably holed yourself into a tiny niche or something.
Not that I disagree with you though, the *intentional* breaks from actually programming, i.e. those that you force on people just because doing something other than coding "makes you a better coder" probably don't really work. I guess you just need to do coding a lot, and also somehow manage to squeeze other stuff into your life as well.
If you can train a monkey to do your job and a monkey is willing to do it..... well, then maybe your years of experience and collected knowledge isn't that worthwhile anyways...
Software engineering jobs are in ever more demand today, and you're talking about bleak prospects in a job which you say isn't going to fire you any time soon.
You talk about stability and jumping ship from a safe job in the same sentence.
Hmm.
Actually, what do you want? Or maybe you just hate software engineering as a job or career?
The argument goes both ways -- I've spent hundred hours of my life learning POSIX, and if my boss wants me to run a POSIX program in Windows, I'm pretty much doomed. (I know a bit of Win32 API if that helps...)
"Open" does not mean "supported on all major platforms". It only means "can be supported by other vendors if they choose to". And if you choose a language or technology that is out of fashion, it doesn't really matter whether it is open or not.
And yes, I know Microsoft Windows is POSIX compliant.
Which industry are you talking about? Because almost all your points are true for all industries to some extent. If that's your explanation why women are reluctant to study CS, you haven't proved your case.
Clean room reimplementation is legal as long as the specification used by the implementors is free of copyright (and other I.P.) issues.
I definitely agree that some of the prior cases of clean-room implementation is at odds with the notion that APIs are copyrightable. To be honest, copyright law has never been logically consistent to me -- which is why I don't even pretend to have knowledge of it unless I'm arguing about legal topics on slashdot...
The "wrong decision" referred to the GP isn't about the trivial range check, but rather the notion that APIs are not copyrightable.
It would be really shitty if APIs were copyrightable, but, as the GP said, that has been the conventional understanding of copyright law for a long time.
It would be interesting to see how the story unfolds, but really, there's nothing funny about the notion of APIs being copyrightable.
Furthermore, because of deallocation cascades, a release message in such schemes can have a very high latency
Right. When gc happens, good garbage collectors don't freeze the whole application for hundreds of milliseconds to scan through the allocated memory looking for objects to free.
It is legal paranoia. Just like how IT-types have network security paranoia and ban a bunch of software/tools that *could* *potentially* introduce security issues to the company network...
I mean, sure, if you spend time looking at an individual license it could be OK. But why spend the time to investigate? Just blanket deny, and if somebody thinks it's worth fighting the bureaucracy to use a damn piece of software, *then* it might be worth looking into making an exception...
What makes you think that the Java API is "public"? At least Sun/Oracle never said that anyone can use those APIs. Which is why there was this compatibility certification crap.
I read somewhere that Oracle wasn't interested in buying Sun until they learnt about Android's use of Java APIs. If they were successful in suing Google for this, the damages could make up the purchase price anyway.
What you say is true, but "not being the most brilliant people I know" is not necessarily "failure", and definitely not "the floor".
I know a bunch of really brilliant CS people as well. Almost all of them graduated with CS degrees and doing quite well. There are different kinds of "smart". The person who becomes a competent sysadmin at 16 is different from the one who drops out of college to found a successful startup, and is different from the one who gets a CS PhD and then a researcher job at Princeton.
The 16-year-old sysadmin probably can't do my job, at least not as well as I (software engineering), and I probably can't do her job well either.
There are different paths to "success", although I must agree that the value of getting a degree is diminishing every day, it's not necessarily a bad thing to do. It really depends on the circumstances of each case.
Slashdot Mirror
Perhaps you can write a sonnet without a million dollars of training, but I'd like you try flying to the moon without a million bucks...
âLook, I'm not judging, but when an illegal immigrant janitor who shouldn't be interested in stocks talks about stocks, I'm disgusted."
I can't believe such shitty rhetoric got modded to +5. I bet it's OK for the OP if rich, white bankers in Wall Street do the same thing.
These days I'm mostly comfortable in reading reactions from people of the opposite sex, but back when I was in my late teens and early twenties, it would be really difficult to avoid misinterpreting the situation occasionally.
It's a sad fact of life where there's always some tension between people of the opposite sex, but you make it sound as if it were so easy to navigate the situation. It really isn't, especially for those who generally have much less successful experience (you really need to have two control groups before you can tell the difference between them).
[offtopic]
That being said, I wonder whether it's really a good idea to blame it all on the "sex" part of "sexual harassment". I mean, as a straight male I'd probably feel uncomfortable around creepy people badgering me for whatever reason even if they probably don't have any sexual interest in me..... It's the "harassment" part that needs to be dealt with, IMHO.
[/offtopic]
I agree with your statement generally, but the commonly accepted solution against unintended assignments in the if conditional is to add an extra set of parenthesis -- which is literally bending code style so that compiler (at least the static analysis tool) will catch violations.
Perhaps you'll also learn not to take comments on Slashdot seriously.
Seriously though, it's hard to believe *anything* taught in schools at all would be helpful (without proper interpretation). Different problems require different solutions and different processes, and not every solution / process fits the problem. So far, all the crap floating around claims it's the best thing since sliced bread, but they don't really tell you the context in which their solution works (and they probably don't have sufficient perspective to tell you anyway). Your professor in school is probably clueless as to their differences anyways, anyone who is intimately involved in real-world software projects don't have time to teach.
That being said, before you dismiss the stuff in your textbook and lecture notes, be aware that a lot of the software processes are for *long term*, *medium-to-large scale* projects. Your weekend project doesn't have to follow those processes, and probably shouldn't. There is a difference between code monkeys writing "code" and somebody who understands the "software engineering stuff" as well. I wouldn't attempt to make serious distinctions between "programmers" and "software engineers" and what not. They're merely stupid labels. Most people fall between the extremes -- although these days, with everything becoming a software/data problem, people from non-software disciplines occasionally have to write programs, especially in the scientific/engineering fields. They might be able to cobble together something that works, but I wouldn't trust them to run a 10-man software project.
If you read what the GP said, it never said it was "all right". In fact, I think it's pretty clear that GP was implying that violating IP rights isn't something to be proud of.
Two wrongs make two wrongs, and it's just fair that both are mentioned.
It seems you're complaining that somebody is presenting the full picture. It might be irrelevant, but hey, you're not complaining about it being offtopic.
This.
Catalyst was there before Ruby on Rails was even a thing.
I've had my own intensive "eat sleep code repeat" cycles back in high school, which is more than a decade ago. That's probably when I went from being a shitty programmer (by adult standards) to an OK programmer. These days I mostly fool around random things when I'm not working, instead of being a beta tester for some bleeding edge software development stack (that's what I secretly think of developers who use RoR and node...)
The "eat sleep code repeat" cycle is probably quite effective initiallly, I just think there are diminishing returns to this approach. If you've done this thing for (say) 10 years already, you probably don't need another twenty years doing the same thing -- it either gets repetitive (which, especially in this field, isn't exactly a good thing), or you've managed to continue to innovate, but by then you've probably holed yourself into a tiny niche or something.
Not that I disagree with you though, the *intentional* breaks from actually programming, i.e. those that you force on people just because doing something other than coding "makes you a better coder" probably don't really work. I guess you just need to do coding a lot, and also somehow manage to squeeze other stuff into your life as well.
Hate to break it to you, but if you even had to look up syntax regularly, you're not a professional programmer.
Seriously, you need practice.
If you can train a monkey to do your job and a monkey is willing to do it..... well, then maybe your years of experience and collected knowledge isn't that worthwhile anyways...
210k salary and you can't feed a family of 3.
Software engineering jobs are in ever more demand today, and you're talking about bleak prospects in a job which you say isn't going to fire you any time soon.
You talk about stability and jumping ship from a safe job in the same sentence.
Hmm.
Actually, what do you want? Or maybe you just hate software engineering as a job or career?
it depends on whether you take into account relativity...
The argument goes both ways -- I've spent hundred hours of my life learning POSIX, and if my boss wants me to run a POSIX program in Windows, I'm pretty much doomed. (I know a bit of Win32 API if that helps...)
"Open" does not mean "supported on all major platforms". It only means "can be supported by other vendors if they choose to". And if you choose a language or technology that is out of fashion, it doesn't really matter whether it is open or not.
And yes, I know Microsoft Windows is POSIX compliant.
Which industry are you talking about? Because almost all your points are true for all industries to some extent. If that's your explanation why women are reluctant to study CS, you haven't proved your case.
clean-room reimplementation is legal
Clean room reimplementation is legal as long as the specification used by the implementors is free of copyright (and other I.P.) issues.
I definitely agree that some of the prior cases of clean-room implementation is at odds with the notion that APIs are copyrightable. To be honest, copyright law has never been logically consistent to me -- which is why I don't even pretend to have knowledge of it unless I'm arguing about legal topics on slashdot ...
The "wrong decision" referred to the GP isn't about the trivial range check, but rather the notion that APIs are not copyrightable.
It would be really shitty if APIs were copyrightable, but, as the GP said, that has been the conventional understanding of copyright law for a long time.
It would be interesting to see how the story unfolds, but really, there's nothing funny about the notion of APIs being copyrightable.
Furthermore, because of deallocation cascades, a release message in such schemes can have a very high latency
Right. When gc happens, good garbage collectors don't freeze the whole application for hundreds of milliseconds to scan through the allocated memory looking for objects to free.
It is legal paranoia. Just like how IT-types have network security paranoia and ban a bunch of software/tools that *could* *potentially* introduce security issues to the company network...
I mean, sure, if you spend time looking at an individual license it could be OK. But why spend the time to investigate? Just blanket deny, and if somebody thinks it's worth fighting the bureaucracy to use a damn piece of software, *then* it might be worth looking into making an exception...
they have not discovered any form of language beyond what they already knew about mRNA
Duh. Have you discovered any language beyond what you already knew about sound waves and ink? I thought not.
Most critical production systems have alerts to pagers and phones. Nobody exclusively relies on email for this kind of stuff.
What makes you think that the Java API is "public"? At least Sun/Oracle never said that anyone can use those APIs. Which is why there was this compatibility certification crap.
I read somewhere that Oracle wasn't interested in buying Sun until they learnt about Android's use of Java APIs. If they were successful in suing Google for this, the damages could make up the purchase price anyway.
I agree with your list, except this one:
- one day I will rewrite this to be better
Welcome to the real world, where there are deadlines and sometimes it's a necessary evil to write crap to fix later.
What you say is true, but "not being the most brilliant people I know" is not necessarily "failure", and definitely not "the floor".
I know a bunch of really brilliant CS people as well. Almost all of them graduated with CS degrees and doing quite well. There are different kinds of "smart". The person who becomes a competent sysadmin at 16 is different from the one who drops out of college to found a successful startup, and is different from the one who gets a CS PhD and then a researcher job at Princeton.
The 16-year-old sysadmin probably can't do my job, at least not as well as I (software engineering), and I probably can't do her job well either.
There are different paths to "success", although I must agree that the value of getting a degree is diminishing every day, it's not necessarily a bad thing to do. It really depends on the circumstances of each case.
If you can't write self-documenting code, you cannot write self-documenting documentation.