I suppose it depends on the size of your shop, the language you work in, and how much is at stake if bad stuff goes out the door.:-)
I'm fortunate enough to work on a mature project with ~50 applications, ~60 developers, ~5 architects, dedicated CM and QA staff, and a continuous build system that sends out emails if the build breaks or if the tests don't pass. Not everyone is disciplined enough to write unit tests, of course, but the senior developers here try to set an example.
I believe you'll find the difference, at least for blacks is not fully explainable by economic factors. There is a significant middle-and-upper-class black population.
Here's some data on economic factors separating American black families and white ones. TL;DR: the presence of a few successful black families in America does not negate the fact that white households continue to have significantly higher median incomes, and thus, access to greater resources for their children:
Just because the difference between a person with intelligence and talent and one without in more cerebral fields isn't as obvious as the difference between a person with talent in sports and one without doesn't mean the difference isn't there.
But the range of opportunities are totally different. Software development is not a "geniuses only" field. You can be of average intelligence and still have a good career as a software developer, or beta tester, or system operator, or network admin -- just like you can be a decent electrician, carpenter, or architect. But if you want to go into professional sports (in the sense of earning big bucks), you have to be physically exceptional, period.
...education right now. One important question is whether the relatively lucrative STEM fields, like Software Development in this case, are drawing from candidate pools that are skewed toward certain demographics simply because those demographics have greater access to resources and encouragement in the first place.
So if American Blacks and Hispanics are underrepresented in the Software Development field compared to the overall American population, one question to ask is, is it because Blacks and Hispanics are "simply not interested" in Software Development, or is it because they generally come from less affluent backgrounds, in school districts that cannot afford to provide the same resources toward educating and encouraging students who might otherwise be interested in these fields?
Likewise, are American women somehow "innately not interested" in Software Development, or is it because they have traditionally been steered away from high-tech industries because of pervasive cultural messages (in school, at home, on television) that "those are professions for men"?
The reason some people care about equal access and encouragement for STEM fields (as opposed to, say, food service) is that they pay extremely well and yet, unlike sports, these careers are attainable by nearly anyone with determination and encouragement.
Tell that to the people who equate the time you spend parked in your chair in their offices with productivity. They're called "Management"
I don't need to tell it to them: I am them. As well as being a developer who is, coincidentally, writing some JUnit tests at this moment for my team's current delivery. Time well spent, seeing at the automated tests I wrote earlier today caught an error in our service layer, and our code freeze (for a high volume public-facing website) is in a matter of days.
If you're a software developer and your managers and/or customers don't understand that a basic degree of CM and QA is needed, then you either need to educate them or change companies. Or you will end up very, very bitter.
I've spent many decades in that Real World. Ignoring compiler warnings and failing to write automated unit tests for edge cases can cause production defects and database corruption crises that will eat many, many more hours of productivity than simply addressing all compiler warnings. Not to mention causing poor end-user perception and increasing the workload up and down the software support and delivery chain.
Developers whose coding habits cause such situations in real world enterprise or commerce systems are ultimately "less productive" than having no developer at all.:-)
I am always tempted to discourage client-side validation, at least in the initial phase of any implementation. Prove to me that the server-side is locked down tightly first... then we'll worry about giving the client instant-feedback. Hell, don't even assume that the values you've provided in your hidden fields, drop-down lists, and radio buttons are the ones which will make it to the server.
The GROW AMERICA Act, or Generating Renewal, Opportunity, and Work with Accelerated Mobility, Efficiency, and Rebuilding of Infrastructure and Communities throughout America, will do exactly what its name implies...
...cost taxpayers hundreds of thousands of dollars, merely for the time that public officials have spent devising its cutesy yet vague, forgettable, and [therefore] pointless acronym.
Note that Gilad Bracha is working on Newspeak, which will probably be as close to an ideal web language as one could hope for - once it's finished - and not only in the matter of containment.
It's doubleplusgood!
re userpost antethis newspeak proglang doubleplus ridiculous namewise: specdocs unmention mathop "++" replace fullwise with plusfull syntax:
To just tell the perspective employer that you have the skill, and learn it if you get the job.
Ooooooo. No.
When I interview candidates, I get people all the time who claim to have a certain skill on their resume, even answering in the affirmative when asked directly if they have that skill. A simple question or two about the technology is usually all it takes to determine if they're lying. Some of them then actually admit it, saying "the recruiter told me to put that on my resume". I don't really care at that point. Lying to me is a big, big minus.
If, however, the candidate does not claim to have the skill, but when asked says, "I don't know it, but give me a chance and I can learn it," that's a big plus.
Edmund: Never had anything you doctors didn't try to cure with leeches. A leech on my ear for ear ache, a leech on my bottom for constipation. Doctor: They're marvellous, aren't they? Edmund: Well, the bottom one wasn't. I just sat there and squashed it. Doctor: You know the leech comes to us on the highest authority? Edmund: Yes. I know that. Dr. Hoffmann of Stuttgart, isn't it? Doctor: That's right, the great Hoffmann. Edmund: Owner of the largest leech farm of Europe...
This is often the case when a project is begun with insufficient foresight into what its technical needs might be down the road. This happens with evolving systems all the time. When the current architecture acts as a drag on development efforts, the architects must weigh the cost of a little temporary user inconvenience against the cost of maintaining a monolithic application.
When the tail is caught in the spokes of a wheel, the dog has no choice but to follow the wag'n.:-)
It sounds like the code base has grown to the point that they realized it would make sense to separate the code for managing a collection of online files from the code for editing a particular file. So: Drive is the file manager, Docs is for word processing documents, and Sheets is for spreadsheets.
That sounds pretty reasonable, especially from a project-management perspective. De-coupling the code will probably allow the different teams to release updates as needed without having to be in perfect synch with each other's schedules. That is, they can submit a patch to Docs even if Sheets is in the middle of a major refactoring.
Slashdot Mirror
I suppose it depends on the size of your shop, the language you work in, and how much is at stake if bad stuff goes out the door. :-)
I'm fortunate enough to work on a mature project with ~50 applications, ~60 developers, ~5 architects, dedicated CM and QA staff, and a continuous build system that sends out emails if the build breaks or if the tests don't pass. Not everyone is disciplined enough to write unit tests, of course, but the senior developers here try to set an example.
Curiosity compels me to ask what you do for a living, and who you work for. :-)
I believe you'll find the difference, at least for blacks is not fully explainable by economic factors. There is a significant middle-and-upper-class black population.
Here's some data on economic factors separating American black families and white ones. TL;DR: the presence of a few successful black families in America does not negate the fact that white households continue to have significantly higher median incomes, and thus, access to greater resources for their children:
- http://www.pewsocialtrends.org...
- http://www.pewresearch.org/fac...
- http://www.washingtonpost.com/...
Just because the difference between a person with intelligence and talent and one without in more cerebral fields isn't as obvious as the difference between a person with talent in sports and one without doesn't mean the difference isn't there.
But the range of opportunities are totally different. Software development is not a "geniuses only" field. You can be of average intelligence and still have a good career as a software developer, or beta tester, or system operator, or network admin -- just like you can be a decent electrician, carpenter, or architect. But if you want to go into professional sports (in the sense of earning big bucks), you have to be physically exceptional, period.
...education right now. One important question is whether the relatively lucrative STEM fields, like Software Development in this case, are drawing from candidate pools that are skewed toward certain demographics simply because those demographics have greater access to resources and encouragement in the first place.
So if American Blacks and Hispanics are underrepresented in the Software Development field compared to the overall American population, one question to ask is, is it because Blacks and Hispanics are "simply not interested" in Software Development, or is it because they generally come from less affluent backgrounds, in school districts that cannot afford to provide the same resources toward educating and encouraging students who might otherwise be interested in these fields?
Likewise, are American women somehow "innately not interested" in Software Development, or is it because they have traditionally been steered away from high-tech industries because of pervasive cultural messages (in school, at home, on television) that "those are professions for men"?
The reason some people care about equal access and encouragement for STEM fields (as opposed to, say, food service) is that they pay extremely well and yet, unlike sports, these careers are attainable by nearly anyone with determination and encouragement.
I don't need to tell it to them: I am them. As well as being a developer who is, coincidentally, writing some JUnit tests at this moment for my team's current delivery. Time well spent, seeing at the automated tests I wrote earlier today caught an error in our service layer, and our code freeze (for a high volume public-facing website) is in a matter of days.
If you're a software developer and your managers and/or customers don't understand that a basic degree of CM and QA is needed, then you either need to educate them or change companies. Or you will end up very, very bitter.
I've spent many decades in that Real World. Ignoring compiler warnings and failing to write automated unit tests for edge cases can cause production defects and database corruption crises that will eat many, many more hours of productivity than simply addressing all compiler warnings. Not to mention causing poor end-user perception and increasing the workload up and down the software support and delivery chain.
Developers whose coding habits cause such situations in real world enterprise or commerce systems are ultimately "less productive" than having no developer at all. :-)
Many ostensibly senior developers do this too.
I am always tempted to discourage client-side validation, at least in the initial phase of any implementation. Prove to me that the server-side is locked down tightly first... then we'll worry about giving the client instant-feedback. Hell, don't even assume that the values you've provided in your hidden fields, drop-down lists, and radio buttons are the ones which will make it to the server.
...doesn't seem to work so well.
...Really? They decided to use that acronym?
Apparently it's a hard journal to get published in.
+1 Intriguing...
It's doubleplusgood!
re userpost antethis
newspeak proglang doubleplus ridiculous namewise: specdocs unmention mathop "++"
replace fullwise with plusfull syntax:
it = ++good
oldthinkers unbellyfeel newspeak.
You're about to install "Angry Birds 7.0". This app wants to...
1. Do whatever the hell it wants to with your tablet setup, your phone connections, and the Internet
2. Not tell you about it
[ ] Yes: I'm bending over right now!
[ ] No: uninstall Android, brick my tablet, and post all my downloaded porn to Facebook
I don't see the connection between the two... can you explain it using a car analogy?
I herd you like stars, so I put a star in your star so you can fusion while you fusion.
Not right now, at least, considering the very recent public discussions.
No one "has to lie". They choose to.
To just tell the perspective employer that you have the skill, and learn it if you get the job.
Ooooooo. No.
When I interview candidates, I get people all the time who claim to have a certain skill on their resume, even answering in the affirmative when asked directly if they have that skill. A simple question or two about the technology is usually all it takes to determine if they're lying. Some of them then actually admit it, saying "the recruiter told me to put that on my resume". I don't really care at that point. Lying to me is a big, big minus.
If, however, the candidate does not claim to have the skill, but when asked says, "I don't know it, but give me a chance and I can learn it," that's a big plus.
It's Adobe's fault for hugging their cloud servers instead of putting them in the cloud....
Edmund: Never had anything you doctors didn't try to cure with leeches. A leech on my ear for ear ache, a leech on my bottom for constipation.
Doctor: They're marvellous, aren't they?
Edmund: Well, the bottom one wasn't. I just sat there and squashed it.
Doctor: You know the leech comes to us on the highest authority?
Edmund: Yes. I know that. Dr. Hoffmann of Stuttgart, isn't it?
Doctor: That's right, the great Hoffmann.
Edmund: Owner of the largest leech farm of Europe...
Man. And I thought my cubicle was cramped...
The OP was making a point by comparing one virtual currency with another. ISK, BTC, Linden dollars, etc.
I'm pretty sure Kaenneth could have googled the answer if that had been the sole intent of the post.
This is often the case when a project is begun with insufficient foresight into what its technical needs might be down the road. This happens with evolving systems all the time. When the current architecture acts as a drag on development efforts, the architects must weigh the cost of a little temporary user inconvenience against the cost of maintaining a monolithic application.
When the tail is caught in the spokes of a wheel, the dog has no choice but to follow the wag'n. :-)
10. "Global climate engineering"
9. "Atmospheric carbon dioxide deficit reduction"
8. "Carbon gifting"
7. "Meteorological redistricting"
6. "No Cloud Left Behind"
5. "The Hurricane Insurance Investment Initiative of 2024"
4. "The Global War on Terra"
3. "Operation Desert Planet"
2. "Great Flood II: Our Glorious Return to Biblical Times"
And the number 1 future euphemism for Global Warming is...
1. "Occupy Everest"
It sounds like the code base has grown to the point that they realized it would make sense to separate the code for managing a collection of online files from the code for editing a particular file. So: Drive is the file manager, Docs is for word processing documents, and Sheets is for spreadsheets.
That sounds pretty reasonable, especially from a project-management perspective. De-coupling the code will probably allow the different teams to release updates as needed without having to be in perfect synch with each other's schedules. That is, they can submit a patch to Docs even if Sheets is in the middle of a major refactoring.