No, they're glorified babysitters. I (very briefly) dated an education major in college. She was stressed out over a project she had due for one of her classes in which she needed to make a lesson plan for third graders.
So you briefly dated one (lucky her), and from that experience alone, you came with the conclusion they are all glorified babysitters. Flawless logic based on extensive experience in the field. Today is not raining, ergo, it never rains. Modus ponens whoring ftw!!!!!!
Really challenging program there, eh?
I cannot say what challenges said person had (assume that person ever existed), but I have to ask: have you ever made a lesson plan? For 3rd graders? Also, a program is perceived as challenging depending on a variety of factors, and not just on the intrinsic nature of the problem or the person's skills when observed from a vacuum. What this person you dated burdened by other factors that are independent of her skills and the complexity of the task at hand?
That's why the saying in the engineering halls was "If you can't hack it, the College of Education is over that way."
And how long have you been waiting to expout that line? Please let get out of your chest. The more that people partake on such 3rd-grade e-jock mentality, the more a sociopath that person is (or it is a tremendous compensation for something severely missing in one's personal or professional life.)
Don't get me wrong. I used to partake on the same Business/Education bashing when I was in school. We all did (well, except the few who didn't revel in sociopathic/narcissist tendencies.) Fortunately, I grew up to recognize it's just an infantile, narcissist, callous and ultimately useless look-at-me-mine-is-bigger kind of thing. I suggest you grow out of it, too.
What is a 'wealth' gap? Who decides there is a certain amount of wealth that each age group is supposed to have, what are those numbers?
Nice strawman. It's not about "deciding" how much each group is supposed to have (in a moral/deontological ethical way). It's about the gap between the two groups that is measurable (and thus comparable/quantifiable) accross the decades. The gap is there, it's measurable, it's obvious, and it requires explaining. Yours is not an explanation by any stretch of the definition. Furthermore, you are asking "who" "decides" how much each group has. That same question begets the following one: who decided that the income gap must be greater than the ones in prior decades/generations?
Ok, so those in the 55+ demographic are the ones who started and built back in the 70's/80's many of the recognized companies that exist today and in doing so they made some good money. That is exactly what they intended to do.
This would be nice and dandy if these were the very first folks in the history of the US who made up companies that made money. Alas, they were not. There were businesses and businessmen before them, quite successful and their companies still exist today. And yet, the generational income gap present at the times preceeding the Baby Boomers was never the way it is now. Hand waving is not a valid argument.
Wonder what their incomes looked like 20-30 years ago when they were building their businesses (either as early employees of founders)? I'd be willing to guess
Why guess? Verify.
their incomes were not much different (in 70's/80's dollars) to today's youth, but their standards of living were probably lower.
So if their income weren't that different from today's youth (which is not true), and their standards of living were lower (they were), then the income gap as measured today is greater than what it was in the past, say, as a function of the decade in which the measurements took place.
So to the 18-35 crowd who hasn't made as much money I'd ask, where are the companies that you started?
Red herring. Not every Baby Boomer was an enterpreneur, and yet the gap between the average Boomer and the average Gen X/Y is greater than the gap that same Boomer experienced with respect to his then senior. Ergo, enterpreneurship is not a factor. It is if you want to present a fallacy as a logical argument, though.
Where are the years of hard work you put in building wealth?
Where were the years of hard work the Baby Boomers put when they were young that resulted in a narrower income gap with relation to their then seniors, narrower with respect to the currently observed income gap?
So, you're stupid and self-centered for complaining about something if somewhere, there's someone who is worse off than you? So there's literally one person on the planet allowed to complain.
There is complaining ("excuse me, you over charged me") and there is going bat-shit, silence-of-the-lambs fucking crazy ("you stupid bitch, my fries are cold, wtf is wrong with you?")** The nuisance is missed to most, and people willing to equate the later type with the former do so from an empty, selfish set of morals to be honest. It's not fucking rocket science, the different nature of the two is self-evident.
How you take this message is up to you and your values.
** I've seen this remark live when I used to work in McDonald's during my college years.
Why do folks live there? Schools. To have their kids go to a better school.
Otherwise stated as "schools without any blacks or hispanics".
Bullshit. Though there is the type that actually thinks that way, most people who can afford living near a better school, middle and upper middle class families, they only care to live among people of the same economic class (because they typically share the same views on education, and coupled with their income, THAT'S what make their public schools better.)
Now, there is some truth that African-Americans, Haitians and Hispanics do not fare as well, economically, in the same proportions as Whites, Asians and other Black populations (like Jamaicans). And what we have is a segregation of educational quality based on income, independently of race.
One can argue (both ways) that one (race/culture) begets the other (income or lack thereof). But it is not accurate to equate "wanting a better school" to "wanting a school w/o blacks or hispanics." That's just race baiting with no useful purpose, a vicious (and highly inaccurate) oversimplification of a complex social problem.
Jupiter Fl. is a premium place to live. I had an elderly relative that forgot to close his garage door on his huge home. The police parked a squad car in his driveway and dialed him on the phone and announced that they would not leave until that door was secured.
That suburb was very safe and relatively crime free. Contrast that kind of police service with what you get in most cities. Small towns that are highly controlled and protected can make a great work environment. I would almost rarther live deep in a coal mine than in most cities.
Yeah, but industries in Jupiter are almost nill (and to be honest is just the same in WPB, Broward and Dade.) Really good jobs in STEM are only found in Clearwater and Orlando (and a bit going to Tampa.)
I remember coming back to California from living in Nicaragua for a year and I was appauled. I was passing through San Francisco to go to an embassy and at the gas station a young chick was went full histerical because the gas pump wasn't working properly. Those tattered and frayed edges just didn't exist down there.
I hear you. I'm from Nicaragua, and indeed, I had the same culture shock. Lots of flaky people going bat-shit for the most inane, inconsequential shit. We don't see that often in Nicaragua, but that's not because we have some social pluses that we do not have here in the US, though.
In our countries, people don't go batshit crazy with stupid, inane things when there is real shit going on (like, living day to day wondering if you will have food the next day.) Or, until recently, just two decades ago, we simply killed each other in the name of ideology (another stupid, inane and truly inconsequential thing if we really reflect on that.) Unless such a person is an upper-classer, Darwin just take care of that shit in our society.
Not sure if that is something to be praised or condemned, though. We were a very fucking violent society, one stone throw away from rampant honor killing and crap like that. We can still be even though our society has made a lot of civic progress in the last two decades.
Sometimes when I see people going batshit crazy with their damned sense of entitlement because some stupid, universally inconsequential inconvenience, I sometimes feel an urge to beat them up with a crowbar telling them "you little shit, whole families in other parts of the world feed of garbage cans, and you bitch because you are waiting 2 extra minutes in the waiting line???".
BUT life goes one, and good people and stupid, self-centered people go about their lives. And if there is a God, the stupid shit they do, it's something between them and their maker within the civic institutions of a nation of laws. And I will take that, and all the whinny self-entitled bitches over seeing children picking up rotten tomatoes for food, seeing people harassed or killed for having a different political inclination, or a Sandinista dictator becoming president with 36% of the vote anytime of any day from today to the day I die.
If anything is a ghost town, it's suburban America. But I can assure you, such a compact, diverse city as SF is hardly a ghost town. Growing up in SF, surely you realize that you never had to travel many blocks to find plenty of human activity.
Yeah, but most of us aren't gay.
Irrelevant unless you give a shit about what people do with their private lives.
Apparently that's where we are headed. The so-called professional newspaper in my town won't use the words 'fisherman', 'fireman', or 'policeman' beause those words "are not inclusive enough".
If children are told to draw a policeman or fireman, they will almost always draw a man. If they are told to draw a police officer or a firefighter, they are more likely to draw a woman. The gender neutral terms are more inclusive, and are also more descriptive (does a fireman fight fires, or does he set them?), so why not use them?
I'll get off your lawn now.
Citations please. And no, I'm not being facetious. I'm actually intrigued about your claim.
What does it matter where it's taking place, as long as it's shared?
Because it's not just about knowledge sharing, but also about obtaining first-hand build-shit-of-uber-magnitude know-how (and the middle/upper-middle engineering/scientific jobs created in the process.)
"Rock stars" - we called them divas in my company - are notoriously unmanageable: many of them are temperamental, don't work well with others, tend to do what they "know" is right instead of doing what they're told,
No disrespect, but we developers also have a name for people that describe developers the way you do:-)
No disrespect, but is this "we" that you are referring to? The fact is that there are divas in the software industry, and they are not necessarily among the best developers (even though they thing they are.) Once we get a diva in the team, it's just utter chaos. They are simply impossible to manage. They can bang code like no tomorrow alright. And they might be able to describe the state of a TCP session by heart. But that doesn't necessarily make them good developers. That's just savantism.
As Dijkstra once put it, good developers are humble, or at least are capable of acknowledging what they don't know. A diva, OTH, is always right, in his mind that is, he is abrasive and nearly impossible to manage effectively.
So when management (and other developers) calls them divas, they are usually right. True that there are systemic problems with management in some places. But not all management shops are created equal, and it does not negate the fact that the software industry is infected by divas (and code monkeys.)
Also, the whole "rock start" term is so stupid and unprofessional. If you are looking for rock starts, you will most likely get pretentious walking turds. Don't look for rock starts, look for competent, professional developers. These are not the same, and the nuisance is missed to most apparently.
Shit, I spend more time reading docs, googling, staring in to space thinking about problems, and doodling ideas and flows on paper than I do actually coding. I'd think it would be hard for two programers' true coding time to line up well enough for pair programming to work, and you'd have to allow time for them to share any breakthroughs they'd had between sessions, unless you tried to pair-think too, which sounds annoying at best. Bouncing ideas off co-workers as necessary is one thing, but beyond that it seems counterproductive.
Maybe this works if you have a very top-down structure with an engineer/analyst up the chain handing you every single thing you need and defining in extremely precise terms how everything last detail should be implemented so there's nothing left to do but type, and maybe decide which kind of loop to use or whether to use switch/case versus if/else or whatever.
YMMV, but my experience has not been like that. I typically work solo, but I've done pair programming, or rather, pair-thinking using a whiteboard and paper while coding or reading (or deciphering) technical specs. It works pretty well when devising test cases too (in particular for stress/failure testing as in "how do we break this shit" or "is there any scenario we have not thought of yet?").
I've never encountered a counter-productive pair-wise experience, but that's because I rarely engaged in the practice. However, I can think of scenarios where pair programming does not work. It is one's job to know or envisage when pair programming (or any technique for that matter) is applicable or not.
I'd be very curious to know how you're measuring productivity. Our experience has been that pairing results in more than 200% productivity.
(For our definition of productivity, which includes the long-term maintenance effort on the resulting code).
It almost has to be in LOC or some other hard to judge metric.
Doesn't have to be like that. Another metric is to simply get something done with degrees of quality and efficiency that are self-evident (you know it when you see it kinda thing.) Sometimes a coarse, abstract measure is better than a concrete one.
Also, and at the risk of getting of the tangent, LOC and other metrics are not hard to judge, provided you establish some context that gives them meaning. By themselves, they don't mean anything.
It's like body weight: 200lbs for a person. What does that mean? What information that weight conveys? None at all. Add gender, age, height and girth, and now you can infer some information out of the body weight measure.
If anyone really believed that pairing two coders results in one of them getting only half of their work done, they would be idiots for letting it go more than one day.
If anyone where to believe that, they would be idiots themselves. Same with anyone who believes pairing will increase productivity two-fold. The truth is contextual to the problem at hand (and the participant's skills and personality traits), and it is always somewhere in the middle.
Mine's been pretty much consistently <50% productivity for the pair.
Why, you ask? Because 2 senior people working on web services can knock out 2 web services in 'x' timeframe, or 1 when paired, in 'x' + 'y' timeframe, where 'y' is a number equal to or greater than 0. The same goes for any other component functions.
That would be yet one more indication that pair programming should be taken as a tactical approach, and not as a general, strategic one (or religious one as the pair-programming zealots would like the rest of the world to think.) There are times when pair programming does not make sense, and engaging developers should know when not to. It certaintly cannot be mandated from above because the people on the trenches... err keyboards know when they should and when they shouldn't pair themselves up for a given task.
Putting two seniors together to do something they can do perfectly well by themselves is one of those cases. Putting two seniors together to tackle a truly new problem, or when only one of the participants is familiar with the problem space, that's a case where pair programming could be used (assuming the people involved are compatible as paired co-workers.)
Pair programming is a tool, and like all tools, it has a context in which it should and should not be used.
YMMV. In my experience, it makes me cut corners more, because I feel like I'm wasting the other guy's time if I sit and think hard for a couple minutes about how to, say, rewrite a loop more clearly.
But that's part of one's job, to think about those things and when to do them and when not to. You are teaching the junior person how to thing about such concerns, and hopefully many others (instead of just let's get this shit to compile asap!!!!). Quality coding is not just banging the shit out of the keyboard, and anytime a vet helps a junior cross that mental chasm faster, it helps both the junior and the company's bottom line.)
Yeah, if you want the seasoned vet to commit seppuku...
Nonsense. One of the tasks implicit for any seasoned vet (especially one that is vested as a senior or principal) is to guide juniors or new members of the team up to speed. Obviously, you don't want your vets to be paired with juniors all the time, as this is not economical (and at some point the junior needs to hit the ground running by himself/herself).
However, in any company (and for any job for that matter) it is a person's task to help others come up to speed if that person has the necessary know-how. It might not be the case for those who just want to fold jeans at the gap, but it is certainly true above a certain professional/salary level.
Obviously you have never heard of TSR programs or BIOS/UEFI attack vectors. Hardware CAN be infected at the 'metal' level.
Dude. A TSR is nothing but a f* DOS version of a daemon, easily removed. And UEFI and BIOS attack vectors, though real, hardly qualified as 'metal' level stuff.
the organization simply has an overall vision and flavor. Its members carry out acts based on that mission. And it has enjoyed a great deal of success — in part due to the lack of central control. Compare this to the level of control in many corporate development organizations. Some of that control is necessary, but often it's taken to gratuitous lengths. If you hire great developers, set general goals for the various parts of the project, and collect metrics, you probably don't need to exercise a lot of control to meet your requirements
This is standard common sense, and the negative effects of over/micro-managing and red tape are recognized (and felt) not just in software but in all endeavours (even within families.) We know what to do about that in all forms of organizations and projects.
That people and project still fall far from the well-known solutions, that has more to do with human behavior, team dynamics and the economics of the incentives/rewards, disinsentives/penalties, (whether tangible or psychological, subjective or objective) than anything else.
Anonymous, with its faceless nature (that precludes the realities of disinsentives and penalties), and incoherent goals, has nothing to teach us or anyone engaged in a real-life project or mission subject to incentives and disinsentives, and the realities of identifiable human relations.
The article might be good to drive traffic (ZOMG, Anonymous in teh titl3!), I'll give the author that </journalistic-attention-whoring>
Micro-management shouldn't be the object. The object should be to develop a system to distribute best practices.
First, best practices care about a lot of things beyond management. Secondly, best practices cannot be defined without first having something to compare (favorably) across an spectrum of things, and not just one spectrum, but a multiplicity of them (coding, process, management, etc.) In the management spectrum, micro-management sits on the polar opposite of management-related best practices. Ergo, one cannot describe or study best practices without first identifying and understanding the pathological case one has to avoid (at best) or directly deal with (at worst): in this case, micro-managing.
This could apply to Anonymous or to software development where more experienced workers can share their best practices with less experienced workers.
But herein lies the problem: anonymous and software development are not comparable, not unless you want to stretch the definition of problem statement. But that's just Reductio ad Absurdum just to fit an argument.
The other is to focus on the process of making critical decisions. The problem of decision making can only be solved by developing a methodology of decision making along with some basic rules to follow when making certain types of decisions.
Which problem of decision making are we referring to here?
If this is Anonymous then it's what is a legitimate vs illegitimate op. Emphasis should be on the process of decision making so that there is a standard process or guideline for choosing an op.
How does this draw lessons for software development, and to general projects and missions with identifiable players? Is it a legitimate argument that requires Anonymous as an example (which is what the article says, remember the topic)?
If it's software development then developers need to know when to use certain designs and when not to use them or when certain tools work best and not others.
But that's a myopic view of software development because software development does not work in a vacuum. There is an organizational context at play that will guide (or force) a developer's hand into what choices to make. One cannot talk about the former without considering the later.
Exactly, in most corporate environments you have to go through so many bosses (most of which shouldn't be making technical decisions) before you can ever get anything done.
Citations please. True that those organizations exist, but in my experience, they are the exception rather than the rule. Obviously, saying that most companies are like that makes good stuff for posting in teh slashdotties water coolers, but c'mon.
the organization simply has an overall vision and flavor. Its members carry out acts based on that mission. And it has enjoyed a great deal of success — in part due to the lack of central control. Compare this to the level of control in many corporate development organizations. Some of that control is necessary, but often it's taken to gratuitous lengths. If you hire great developers, set general goals for the various parts of the project, and collect metrics, you probably don't need to exercise a lot of control to meet your requirements
This is standard common sense, and the negative effects of over/micro-managing and red tape are recognized (and felt) not just in software but in all endeavours (even within families.) We know what to do about that in all forms of organizations and projects.
That people and project still fall far from the well-known solutions, that has more to do with human behavior, team dynamics and the economics of the incentives/rewards, disinsentives/penalties, (whether tangible or psychological, subjective or objective) than anything else.
Anonymous, with its faceless nature (that precludes the realities of disinsentives and penalties), and incoherent goals, has nothing to teach us or anyone engaged in a real-life project or mission subject to incentives and disinsentives, and the realities of identifiable human relations.
The article might be good to drive traffic (ZOMG, Anonymous in teh titl3!), I'll give the author that </journalistic-attention-whoring>
The engineers, possibly, the architects definitely. Not so much the builders as long as they can show they were following the spec.
If there is any liability, it should lie with the company releasing the software. No individual developer can be held responsible - the software should have gone through testing, QA, user acceptance testing... where do you draw the line? Why the developers and not, say, the testing team for failing to develop a test that shows the bug?
An individual can be held responsible if it is demonstrated that the person was overtly negligent (and worse, lied about it)..ie. claiming that a hard-to-fix bug is unlikely to manifest itself even though he/she know that was not true, or a tester who vouches a component was tested when it was not.
Depends on the contract between the software supplier and the client. For example (and I work for a defense contractor), the DoD (or similarly, the DoE) will tell you what is not sensitive and what is (and the degree of it), and how to handle it. With medical equipment, the law and industrial organizations estipulate what is sensitive when it comes to data and behavior.
All developed countries have established rules and regulations for the definition and protection of sensitive data. Using the US as an example, with medical information, credit information, and public companies' information, federal and state legislature clearly defines what is sensitive via legal bodies such as FACTA, HIPAA, SOX, Anti-Phishing Act of 2005, The Privacy Act of 1974, Title 18 of the US Code, 1028d, various legal bodies at the state level, etc.
We typically do not define the meaning "sensitive". It is already defined by law or by contract in the context of an activity or industry. We can define more stringent definitions than those required by the law or by a contract, but we cannot make our definitions that run counter with the legal/contractual ones.
There's no end to it; once you open the door a good lawyer can can convince a jury anything.
You are just hand waving. Stop. I'm sure it makes for a good post to attribute lawyers with magical powers to convince a jury of things counter with what is in the law or in a reasonable contract. But that's not how reality works.
excessively poor software should result in some form of negligence... but general âoecan happen to anyoneâ type bugs.. no.
And how do you define the difference?
A.Some things can simply happen (using < when you meant to use <=). Or obscure bugs that manifest themselves as corner cases between many components. Those are the "general, can happen" types.
B. There are others that are simply not acceptable given how much knowledge we have acquired in the last 40 years. Things that are simply erradicated by using widely accepted coding techniques.ie. putting consts/rvals on the right side of the equality operator in C/C++; always checking pointers before dereferencing; doing "string literal".equals(stringVariable) in java; sanitizing your input at every layer before passing to a lower layer (specially when the input is obtained at the UI); keeping your cyclomatic complexity low, etc.
Based on the quality of code?
Yep. Quality of code is pretty much a measurable thing. Looking at the things I identified in B above, if someone's code does not possess any of those violations, or if any such violation is rarely found, then that shows the person has done a best professional effort. However, if the code is riddled with unchecked pointer (or object reference) access, without sanitizing and checking input, with obscene cyclomatic complexity, then it will be obvious that the author has not done his professional duty. He/she has been negligent. Even though we coders are not typically legally bound to pay for our negligence, morally and ethically, we should be held accountable.
At some point our profession will professionalize itself the way professional engineers do with their profession.
Based on the amount of unit testing that was (provably) performed?
Of course. It is one of the ways to show we are not negligent to our clients.
This will start a slew of software that is only warranted under specific OS/software configurations (and then installing an aggressive anti-virus or
That doesn't make any sense. If we are talking about device drivers or medical equipment, maybe. But if we are talking about, say, web-based banking applications, I do not see how code/behavior quality assurance will be subject to such things.
not error-checking your RAM chips regularly would void your warranty).
This would only apply if you are selling your software packaged with a hardware solution (that is, a totally integrated solution). And in that case, yes, you should be subject to penalties if you do not check the hardware you are selling. This is the case of medical equipment manufacturers whom typically develop the software along with the hardware.
Now, if all you do is the software part, then, duh, hardware checking is not a requirement for you (not even if you are the person doing a hardware recommendation). It will be for the client who chooses the hardware and/or the hardware provider (typically contigent to some type of SLA.)
Stolen? Why stolen? Society gives you a lot of rights and safegards, infrastructures and services, and above all, the right to trial by a jury of your peers (as opposed to jury by the sole hand of a despot or potentate.) In return, you are asked to give a service in return. That service, which is a small token in the grand scheme of things, will cost something in return (inconvenience and loss of some of your salary.)
Strange, every year I seem to get about 40% of my salary taken in return for those conveniences.
There is always the option of living outside the realm of developed/industrialized civilization. Myself coming from a country where you can pretty much get by without paying so much taxes (Nicaragua, 2nd poorest country in the Western Hemisphere), specially if you make a lot of moolah and have connections, you should give it a try whenever the thought of paying that much off your salary for those conveniences become too much too bear.
Slashdot Mirror
Hand waving is not a valid argument.
If it's good enough for Obi Wan, it's good enough for me.
Well played sir, well played. I wish I had more mod points :)
No, they're glorified babysitters. I (very briefly) dated an education major in college. She was stressed out over a project she had due for one of her classes in which she needed to make a lesson plan for third graders.
So you briefly dated one (lucky her), and from that experience alone, you came with the conclusion they are all glorified babysitters. Flawless logic based on extensive experience in the field. Today is not raining, ergo, it never rains. Modus ponens whoring ftw!!!!!!
Really challenging program there, eh?
I cannot say what challenges said person had (assume that person ever existed), but I have to ask: have you ever made a lesson plan? For 3rd graders? Also, a program is perceived as challenging depending on a variety of factors, and not just on the intrinsic nature of the problem or the person's skills when observed from a vacuum. What this person you dated burdened by other factors that are independent of her skills and the complexity of the task at hand?
That's why the saying in the engineering halls was "If you can't hack it, the College of Education is over that way."
And how long have you been waiting to expout that line? Please let get out of your chest. The more that people partake on such 3rd-grade e-jock mentality, the more a sociopath that person is (or it is a tremendous compensation for something severely missing in one's personal or professional life.)
Don't get me wrong. I used to partake on the same Business/Education bashing when I was in school. We all did (well, except the few who didn't revel in sociopathic/narcissist tendencies.) Fortunately, I grew up to recognize it's just an infantile, narcissist, callous and ultimately useless look-at-me-mine-is-bigger kind of thing. I suggest you grow out of it, too.
What is a 'wealth' gap? Who decides there is a certain amount of wealth that each age group is supposed to have, what are those numbers?
Nice strawman. It's not about "deciding" how much each group is supposed to have (in a moral/deontological ethical way). It's about the gap between the two groups that is measurable (and thus comparable/quantifiable) accross the decades. The gap is there, it's measurable, it's obvious, and it requires explaining. Yours is not an explanation by any stretch of the definition. Furthermore, you are asking "who" "decides" how much each group has. That same question begets the following one: who decided that the income gap must be greater than the ones in prior decades/generations?
Ok, so those in the 55+ demographic are the ones who started and built back in the 70's/80's many of the recognized companies that exist today and in doing so they made some good money. That is exactly what they intended to do.
This would be nice and dandy if these were the very first folks in the history of the US who made up companies that made money. Alas, they were not. There were businesses and businessmen before them, quite successful and their companies still exist today. And yet, the generational income gap present at the times preceeding the Baby Boomers was never the way it is now. Hand waving is not a valid argument.
Wonder what their incomes looked like 20-30 years ago when they were building their businesses (either as early employees of founders)? I'd be willing to guess
Why guess? Verify.
their incomes were not much different (in 70's/80's dollars) to today's youth, but their standards of living were probably lower.
So if their income weren't that different from today's youth (which is not true), and their standards of living were lower (they were), then the income gap as measured today is greater than what it was in the past, say, as a function of the decade in which the measurements took place.
So to the 18-35 crowd who hasn't made as much money I'd ask, where are the companies that you started?
Red herring. Not every Baby Boomer was an enterpreneur, and yet the gap between the average Boomer and the average Gen X/Y is greater than the gap that same Boomer experienced with respect to his then senior. Ergo, enterpreneurship is not a factor. It is if you want to present a fallacy as a logical argument, though.
Where are the years of hard work you put in building wealth?
Where were the years of hard work the Baby Boomers put when they were young that resulted in a narrower income gap with relation to their then seniors, narrower with respect to the currently observed income gap?
So, you're stupid and self-centered for complaining about something if somewhere, there's someone who is worse off than you? So there's literally one person on the planet allowed to complain.
There is complaining ("excuse me, you over charged me") and there is going bat-shit, silence-of-the-lambs fucking crazy ("you stupid bitch, my fries are cold, wtf is wrong with you?")** The nuisance is missed to most, and people willing to equate the later type with the former do so from an empty, selfish set of morals to be honest. It's not fucking rocket science, the different nature of the two is self-evident.
How you take this message is up to you and your values.
** I've seen this remark live when I used to work in McDonald's during my college years.
Why do folks live there? Schools. To have their kids go to a better school.
Otherwise stated as "schools without any blacks or hispanics".
Bullshit. Though there is the type that actually thinks that way, most people who can afford living near a better school, middle and upper middle class families, they only care to live among people of the same economic class (because they typically share the same views on education, and coupled with their income, THAT'S what make their public schools better.)
Now, there is some truth that African-Americans, Haitians and Hispanics do not fare as well, economically, in the same proportions as Whites, Asians and other Black populations (like Jamaicans). And what we have is a segregation of educational quality based on income, independently of race.
One can argue (both ways) that one (race/culture) begets the other (income or lack thereof). But it is not accurate to equate "wanting a better school" to "wanting a school w/o blacks or hispanics." That's just race baiting with no useful purpose, a vicious (and highly inaccurate) oversimplification of a complex social problem.
Jupiter Fl. is a premium place to live. I had an elderly relative that forgot to close his garage door on his huge home. The police parked a squad car in his driveway and dialed him on the phone and announced that they would not leave until that door was secured. That suburb was very safe and relatively crime free. Contrast that kind of police service with what you get in most cities. Small towns that are highly controlled and protected can make a great work environment. I would almost rarther live deep in a coal mine than in most cities.
Yeah, but industries in Jupiter are almost nill (and to be honest is just the same in WPB, Broward and Dade.) Really good jobs in STEM are only found in Clearwater and Orlando (and a bit going to Tampa.)
I remember coming back to California from living in Nicaragua for a year and I was appauled. I was passing through San Francisco to go to an embassy and at the gas station a young chick was went full histerical because the gas pump wasn't working properly. Those tattered and frayed edges just didn't exist down there.
I hear you. I'm from Nicaragua, and indeed, I had the same culture shock. Lots of flaky people going bat-shit for the most inane, inconsequential shit. We don't see that often in Nicaragua, but that's not because we have some social pluses that we do not have here in the US, though.
In our countries, people don't go batshit crazy with stupid, inane things when there is real shit going on (like, living day to day wondering if you will have food the next day.) Or, until recently, just two decades ago, we simply killed each other in the name of ideology (another stupid, inane and truly inconsequential thing if we really reflect on that.) Unless such a person is an upper-classer, Darwin just take care of that shit in our society.
Not sure if that is something to be praised or condemned, though. We were a very fucking violent society, one stone throw away from rampant honor killing and crap like that. We can still be even though our society has made a lot of civic progress in the last two decades.
Sometimes when I see people going batshit crazy with their damned sense of entitlement because some stupid, universally inconsequential inconvenience, I sometimes feel an urge to beat them up with a crowbar telling them "you little shit, whole families in other parts of the world feed of garbage cans, and you bitch because you are waiting 2 extra minutes in the waiting line???".
BUT life goes one, and good people and stupid, self-centered people go about their lives. And if there is a God, the stupid shit they do, it's something between them and their maker within the civic institutions of a nation of laws. And I will take that, and all the whinny self-entitled bitches over seeing children picking up rotten tomatoes for food, seeing people harassed or killed for having a different political inclination, or a Sandinista dictator becoming president with 36% of the vote anytime of any day from today to the day I die.
If anything is a ghost town, it's suburban America. But I can assure you, such a compact, diverse city as SF is hardly a ghost town. Growing up in SF, surely you realize that you never had to travel many blocks to find plenty of human activity.
Yeah, but most of us aren't gay.
Irrelevant unless you give a shit about what people do with their private lives.
Apparently that's where we are headed. The so-called professional newspaper in my town won't use the words 'fisherman', 'fireman', or 'policeman' beause those words "are not inclusive enough".
If children are told to draw a policeman or fireman, they will almost always draw a man. If they are told to draw a police officer or a firefighter, they are more likely to draw a woman. The gender neutral terms are more inclusive, and are also more descriptive (does a fireman fight fires, or does he set them?), so why not use them?
I'll get off your lawn now.
Citations please. And no, I'm not being facetious. I'm actually intrigued about your claim.
What does it matter where it's taking place, as long as it's shared?
Because it's not just about knowledge sharing, but also about obtaining first-hand build-shit-of-uber-magnitude know-how (and the middle/upper-middle engineering/scientific jobs created in the process.)
"Rock stars" - we called them divas in my company - are notoriously unmanageable: many of them are temperamental, don't work well with others, tend to do what they "know" is right instead of doing what they're told,
No disrespect, but we developers also have a name for people that describe developers the way you do :-)
No disrespect, but is this "we" that you are referring to? The fact is that there are divas in the software industry, and they are not necessarily among the best developers (even though they thing they are.) Once we get a diva in the team, it's just utter chaos. They are simply impossible to manage. They can bang code like no tomorrow alright. And they might be able to describe the state of a TCP session by heart. But that doesn't necessarily make them good developers. That's just savantism.
As Dijkstra once put it, good developers are humble, or at least are capable of acknowledging what they don't know. A diva, OTH, is always right, in his mind that is, he is abrasive and nearly impossible to manage effectively.
So when management (and other developers) calls them divas, they are usually right. True that there are systemic problems with management in some places. But not all management shops are created equal, and it does not negate the fact that the software industry is infected by divas (and code monkeys.)
Also, the whole "rock start" term is so stupid and unprofessional. If you are looking for rock starts, you will most likely get pretentious walking turds. Don't look for rock starts, look for competent, professional developers. These are not the same, and the nuisance is missed to most apparently.
Shit, I spend more time reading docs, googling, staring in to space thinking about problems, and doodling ideas and flows on paper than I do actually coding. I'd think it would be hard for two programers' true coding time to line up well enough for pair programming to work, and you'd have to allow time for them to share any breakthroughs they'd had between sessions, unless you tried to pair-think too, which sounds annoying at best. Bouncing ideas off co-workers as necessary is one thing, but beyond that it seems counterproductive.
Maybe this works if you have a very top-down structure with an engineer/analyst up the chain handing you every single thing you need and defining in extremely precise terms how everything last detail should be implemented so there's nothing left to do but type, and maybe decide which kind of loop to use or whether to use switch/case versus if/else or whatever.
YMMV, but my experience has not been like that. I typically work solo, but I've done pair programming, or rather, pair-thinking using a whiteboard and paper while coding or reading (or deciphering) technical specs. It works pretty well when devising test cases too (in particular for stress/failure testing as in "how do we break this shit" or "is there any scenario we have not thought of yet?").
I've never encountered a counter-productive pair-wise experience, but that's because I rarely engaged in the practice. However, I can think of scenarios where pair programming does not work. It is one's job to know or envisage when pair programming (or any technique for that matter) is applicable or not.
I'd be very curious to know how you're measuring productivity. Our experience has been that pairing results in more than 200% productivity.
(For our definition of productivity, which includes the long-term maintenance effort on the resulting code).
It almost has to be in LOC or some other hard to judge metric.
Doesn't have to be like that. Another metric is to simply get something done with degrees of quality and efficiency that are self-evident (you know it when you see it kinda thing.) Sometimes a coarse, abstract measure is better than a concrete one.
Also, and at the risk of getting of the tangent, LOC and other metrics are not hard to judge, provided you establish some context that gives them meaning. By themselves, they don't mean anything.
It's like body weight: 200lbs for a person. What does that mean? What information that weight conveys? None at all. Add gender, age, height and girth, and now you can infer some information out of the body weight measure.
If anyone really believed that pairing two coders results in one of them getting only half of their work done, they would be idiots for letting it go more than one day.
If anyone where to believe that, they would be idiots themselves. Same with anyone who believes pairing will increase productivity two-fold. The truth is contextual to the problem at hand (and the participant's skills and personality traits), and it is always somewhere in the middle.
Mine's been pretty much consistently <50% productivity for the pair.
Why, you ask? Because 2 senior people working on web services can knock out 2 web services in 'x' timeframe, or 1 when paired, in 'x' + 'y' timeframe, where 'y' is a number equal to or greater than 0. The same goes for any other component functions.
That would be yet one more indication that pair programming should be taken as a tactical approach, and not as a general, strategic one (or religious one as the pair-programming zealots would like the rest of the world to think.) There are times when pair programming does not make sense, and engaging developers should know when not to. It certaintly cannot be mandated from above because the people on the trenches... err keyboards know when they should and when they shouldn't pair themselves up for a given task.
Putting two seniors together to do something they can do perfectly well by themselves is one of those cases. Putting two seniors together to tackle a truly new problem, or when only one of the participants is familiar with the problem space, that's a case where pair programming could be used (assuming the people involved are compatible as paired co-workers.)
Pair programming is a tool, and like all tools, it has a context in which it should and should not be used.
YMMV. In my experience, it makes me cut corners more, because I feel like I'm wasting the other guy's time if I sit and think hard for a couple minutes about how to, say, rewrite a loop more clearly.
But that's part of one's job, to think about those things and when to do them and when not to. You are teaching the junior person how to thing about such concerns, and hopefully many others (instead of just let's get this shit to compile asap!!!!). Quality coding is not just banging the shit out of the keyboard, and anytime a vet helps a junior cross that mental chasm faster, it helps both the junior and the company's bottom line.)
Yeah, if you want the seasoned vet to commit seppuku...
Nonsense. One of the tasks implicit for any seasoned vet (especially one that is vested as a senior or principal) is to guide juniors or new members of the team up to speed. Obviously, you don't want your vets to be paired with juniors all the time, as this is not economical (and at some point the junior needs to hit the ground running by himself/herself).
However, in any company (and for any job for that matter) it is a person's task to help others come up to speed if that person has the necessary know-how. It might not be the case for those who just want to fold jeans at the gap, but it is certainly true above a certain professional/salary level.
Obviously you have never heard of TSR programs or BIOS/UEFI attack vectors. Hardware CAN be infected at the 'metal' level.
Dude. A TSR is nothing but a f* DOS version of a daemon, easily removed. And UEFI and BIOS attack vectors, though real, hardly qualified as 'metal' level stuff.
the organization simply has an overall vision and flavor. Its members carry out acts based on that mission. And it has enjoyed a great deal of success — in part due to the lack of central control. Compare this to the level of control in many corporate development organizations. Some of that control is necessary, but often it's taken to gratuitous lengths. If you hire great developers, set general goals for the various parts of the project, and collect metrics, you probably don't need to exercise a lot of control to meet your requirements
This is standard common sense, and the negative effects of over/micro-managing and red tape are recognized (and felt) not just in software but in all endeavours (even within families.) We know what to do about that in all forms of organizations and projects.
That people and project still fall far from the well-known solutions, that has more to do with human behavior, team dynamics and the economics of the incentives/rewards, disinsentives/penalties, (whether tangible or psychological, subjective or objective) than anything else.
Anonymous, with its faceless nature (that precludes the realities of disinsentives and penalties), and incoherent goals, has nothing to teach us or anyone engaged in a real-life project or mission subject to incentives and disinsentives, and the realities of identifiable human relations.
The article might be good to drive traffic (ZOMG, Anonymous in teh titl3!), I'll give the author that </journalistic-attention-whoring>
Micro-management shouldn't be the object. The object should be to develop a system to distribute best practices.
First, best practices care about a lot of things beyond management. Secondly, best practices cannot be defined without first having something to compare (favorably) across an spectrum of things, and not just one spectrum, but a multiplicity of them (coding, process, management, etc.) In the management spectrum, micro-management sits on the polar opposite of management-related best practices. Ergo, one cannot describe or study best practices without first identifying and understanding the pathological case one has to avoid (at best) or directly deal with (at worst): in this case, micro-managing.
This could apply to Anonymous or to software development where more experienced workers can share their best practices with less experienced workers.
But herein lies the problem: anonymous and software development are not comparable, not unless you want to stretch the definition of problem statement. But that's just Reductio ad Absurdum just to fit an argument.
The other is to focus on the process of making critical decisions. The problem of decision making can only be solved by developing a methodology of decision making along with some basic rules to follow when making certain types of decisions.
Which problem of decision making are we referring to here?
If this is Anonymous then it's what is a legitimate vs illegitimate op. Emphasis should be on the process of decision making so that there is a standard process or guideline for choosing an op.
How does this draw lessons for software development, and to general projects and missions with identifiable players? Is it a legitimate argument that requires Anonymous as an example (which is what the article says, remember the topic)?
If it's software development then developers need to know when to use certain designs and when not to use them or when certain tools work best and not others.
But that's a myopic view of software development because software development does not work in a vacuum. There is an organizational context at play that will guide (or force) a developer's hand into what choices to make. One cannot talk about the former without considering the later.
As leader of an open source project
Apache POI, funded by MS .
So? Ad hominem much? Ex Concessis? Reductio ad Hitlerum? Not that I agree with the article, but c'mon, this is as stupid as the article in question.
Here, buy this book (Damer's "Attacing Faulty Reasoning: A Practical Guide to Fallacy-Free Arguments"), read it and then try again.
Exactly, in most corporate environments you have to go through so many bosses (most of which shouldn't be making technical decisions) before you can ever get anything done.
Citations please. True that those organizations exist, but in my experience, they are the exception rather than the rule. Obviously, saying that most companies are like that makes good stuff for posting in teh slashdotties water coolers, but c'mon.
the organization simply has an overall vision and flavor. Its members carry out acts based on that mission. And it has enjoyed a great deal of success — in part due to the lack of central control. Compare this to the level of control in many corporate development organizations. Some of that control is necessary, but often it's taken to gratuitous lengths. If you hire great developers, set general goals for the various parts of the project, and collect metrics, you probably don't need to exercise a lot of control to meet your requirements
This is standard common sense, and the negative effects of over/micro-managing and red tape are recognized (and felt) not just in software but in all endeavours (even within families.) We know what to do about that in all forms of organizations and projects.
That people and project still fall far from the well-known solutions, that has more to do with human behavior, team dynamics and the economics of the incentives/rewards, disinsentives/penalties, (whether tangible or psychological, subjective or objective) than anything else.
Anonymous, with its faceless nature (that precludes the realities of disinsentives and penalties), and incoherent goals, has nothing to teach us or anyone engaged in a real-life project or mission subject to incentives and disinsentives, and the realities of identifiable human relations.
The article might be good to drive traffic (ZOMG, Anonymous in teh titl3!), I'll give the author that </journalistic-attention-whoring>
The engineers, possibly, the architects definitely. Not so much the builders as long as they can show they were following the spec.
If there is any liability, it should lie with the company releasing the software. No individual developer can be held responsible - the software should have gone through testing, QA, user acceptance testing... where do you draw the line? Why the developers and not, say, the testing team for failing to develop a test that shows the bug?
An individual can be held responsible if it is demonstrated that the person was overtly negligent (and worse, lied about it). .ie. claiming that a hard-to-fix bug is unlikely to manifest itself even though he/she know that was not true, or a tester who vouches a component was tested when it was not.
So how do you define "sensitive"?
Depends on the contract between the software supplier and the client. For example (and I work for a defense contractor), the DoD (or similarly, the DoE) will tell you what is not sensitive and what is (and the degree of it), and how to handle it. With medical equipment, the law and industrial organizations estipulate what is sensitive when it comes to data and behavior.
All developed countries have established rules and regulations for the definition and protection of sensitive data. Using the US as an example, with medical information, credit information, and public companies' information, federal and state legislature clearly defines what is sensitive via legal bodies such as FACTA, HIPAA, SOX, Anti-Phishing Act of 2005, The Privacy Act of 1974, Title 18 of the US Code, 1028d, various legal bodies at the state level, etc.
We typically do not define the meaning "sensitive". It is already defined by law or by contract in the context of an activity or industry. We can define more stringent definitions than those required by the law or by a contract, but we cannot make our definitions that run counter with the legal/contractual ones.
There's no end to it; once you open the door a good lawyer can can convince a jury anything.
You are just hand waving. Stop. I'm sure it makes for a good post to attribute lawyers with magical powers to convince a jury of things counter with what is in the law or in a reasonable contract. But that's not how reality works.
excessively poor software should result in some form of negligence ... but general âoecan happen to anyoneâ type bugs.. no.
And how do you define the difference?
A.Some things can simply happen (using < when you meant to use <=). Or obscure bugs that manifest themselves as corner cases between many components. Those are the "general, can happen" types.
B. There are others that are simply not acceptable given how much knowledge we have acquired in the last 40 years. Things that are simply erradicated by using widely accepted coding techniques .ie. putting consts/rvals on the right side of the equality operator in C/C++; always checking pointers before dereferencing; doing "string literal".equals(stringVariable) in java; sanitizing your input at every layer before passing to a lower layer (specially when the input is obtained at the UI); keeping your cyclomatic complexity low, etc.
Based on the quality of code?
Yep. Quality of code is pretty much a measurable thing. Looking at the things I identified in B above, if someone's code does not possess any of those violations, or if any such violation is rarely found, then that shows the person has done a best professional effort. However, if the code is riddled with unchecked pointer (or object reference) access, without sanitizing and checking input, with obscene cyclomatic complexity, then it will be obvious that the author has not done his professional duty. He/she has been negligent. Even though we coders are not typically legally bound to pay for our negligence, morally and ethically, we should be held accountable.
At some point our profession will professionalize itself the way professional engineers do with their profession.
Based on the amount of unit testing that was (provably) performed?
Of course. It is one of the ways to show we are not negligent to our clients.
This will start a slew of software that is only warranted under specific OS/software configurations (and then installing an aggressive anti-virus or
That doesn't make any sense. If we are talking about device drivers or medical equipment, maybe. But if we are talking about, say, web-based banking applications, I do not see how code/behavior quality assurance will be subject to such things.
not error-checking your RAM chips regularly would void your warranty).
This would only apply if you are selling your software packaged with a hardware solution (that is, a totally integrated solution). And in that case, yes, you should be subject to penalties if you do not check the hardware you are selling. This is the case of medical equipment manufacturers whom typically develop the software along with the hardware.
Now, if all you do is the software part, then, duh, hardware checking is not a requirement for you (not even if you are the person doing a hardware recommendation). It will be for the client who chooses the hardware and/or the hardware provider (typically contigent to some type of SLA.)
Stolen? Why stolen? Society gives you a lot of rights and safegards, infrastructures and services, and above all, the right to trial by a jury of your peers (as opposed to jury by the sole hand of a despot or potentate.) In return, you are asked to give a service in return. That service, which is a small token in the grand scheme of things, will cost something in return (inconvenience and loss of some of your salary.)
Strange, every year I seem to get about 40% of my salary taken in return for those conveniences.
There is always the option of living outside the realm of developed/industrialized civilization. Myself coming from a country where you can pretty much get by without paying so much taxes (Nicaragua, 2nd poorest country in the Western Hemisphere), specially if you make a lot of moolah and have connections, you should give it a try whenever the thought of paying that much off your salary for those conveniences become too much too bear.