I've only used skype a few times. What is skype fraud?
My understanding of skype is it's basically a video phone using your general purpose computer.
I read some of TFA looking for what types of fraud they are talking about, but didn't see any detail. They mention credit card fraud, but that's not a feature of skype. I mean, if some stranger knocks on your door, and when you answer, asks for your credit card number, and you give your credit card number, that's not a weakness in your door or lock, that's a weakness in you.
What I do with my landline is never answer if I don't recognize the number or name in the caller ID. Couldn't I do the same with skype, never answer if I don't know who is calling? There you go, 100% fraud prevention.
Agreed. My first thought was, "If he is doing this for a new job why aren't they supplying him with a laptop so he can use it at home AND at work?" You know, like a sane company would, or at least one with a clue. If they are expecting you to do this extra work, or if you volunteered, the least they could do is supply you with a portable dev machine. Run. Run away from that company.
Because he told them he could do all this stuff. He's already committed to be an expert with.Net and MS-SQL and Porterzebbi and whatever else they asked in the interview. That's why he can't ask them for help with training.
I know it's cliche to complain about Ask/., but this one is really bad. If you can't even figure out how to set up an environment where you can teach yourself programming, you shouldn't be telling other people you know how to program.
The answers here are mind-numbingly trivial. You don't want your kids to access your pr0n...I mean "work stuff," that what user profiles and permissions are for. Don't want your background services (IIS, SQL, etc) to affect performance when you're not working?
1) They won't. How old is the hardware you have? Are we talking turn-of-century type old? If you need anything, it'll be RAM. And if you livelihood depends on it, you can't afford to NOT buy more RAM, no matter how poor you are.
2) Set the services to start manually and create 2 batch files--start_work and stop_work--to start and stop those services with a single command.
Of course another option is VM. But I'll assume since the OP couldn't figure out 1 and 2 above that configuring and using a VM is way above the skill level we have here.
This is not a recent addition to the AP schedule. AP CS has existed at least as far back as the mid 1980s.
As for acceptance, according the College Board, "AP is accepted by more than 3,600 colleges and universities worldwide for college credit, advanced placement, or both on the basis of successful AP Exam grades. This includes over 90 percent of four-year institutions in the United States."
Even if a school doesn't offer credit, having the course on your schedule (or having an AP test score if taken Junior year or earlier) will like help your chances for admission. (Unless there's a low score on the exam.)
Something I expected to see in this thread is a discussion of the material covered by AP CS. I suspect that is at least part of the problem.
AP CS uses Java to teach algorithms, data structures, OOP concepts, and documentation. Is the use of Java part of the issue? I realize a course like this can never be cutting edge or using the latest and greatest, but with all the other resources available, how many high school kids are excited about learning Java?
My take is this: as a high school student if you want to learn calculus, your best bet is probably the AP Calc course (unless there is a near-by university with a decent math department). If you want to learn chemistry or physics, there isn't competition for what an AP course can do for you.
But if you want to learn programming and basic CS concepts, there are a myriad of options--variety not just of course but also of language. I've seen these discussions here, on where to start with teaching or learning programming. If memory serves, Java doesn't come out of such discussions as a clear choice for young students.
How does being the owner of something entitle you to someone else being required to provide the means to destroy it?
That's what "ownership" means. You get to control it.
If you want that capability you should have thought about that before you created it.
Without question.
But the policy at Nextdoor.com is that you own your content. If in fact you can't control aspects of access or the current state (destroy or keep), than you *don't*own it.
What does that mean for your posts here? "Comments owned by the poster." Yet you can't edit or delete posts.
Seems Subby is the type who doesn't learn from mistakes. In trying to remove "owned" content from one site, you just get more content created with the same issues on a different site.
How about 'learn to tell time' before 'learn to code'? If they don't know the difference between a week and an hour, I doubt they have much to contribute in the areaof education.
But the main point is that States simply don't have any legal basis for taxing transactions that happen in another State. Period. That is a violation of our separation of powers.
1) This is not an issue separation of powers. SoP is between branches of government, not between states.
2) This case is not about taxing transaction that happen in another state. This is about who has to collect taxes and what constitutes a business presence in a state.
If I'm in state A and Amazon doesn't have a business presence in state A, then Amazon doesn't collect taxes for state A. But if Amazon has an affiliate or other partners in state A, is that enough to qualify as a business presence?
Why is it bad? Anything that even *leans* towards someone in state A having to pay taxes to, and which were legislated in, state B, is destructive to the very fabric of the states.
Yeah, but there isn't any of that in this case. The people paying taxes to state B are in state B. The question isn't even does someone/business in state A have to collect taxes for state B. The question is for a business like Amazon, what does it mean to "be" in a state.
This may be a bad decision, but your comment doesn't address why.
A good password is one that you don't mentally consider a word or string of words, as much as it is a dance that you do with your hands and fingers, really really fast.
On that note, non-printing characters should be allowed as part of a password. E.g. "12345" is a bad password. But why shouldn't we be able to use "12356[backspace][backspace]45"?
This begs the question. There is some reasonable expectation that people should learn to properly use the tools of modern society, but in the end, the tools should serve the people, not the other way around. If your car pulled to the left, would you say you were lousy at driving in a straight line? No, you'd say your car was out of alignment and get it fixed.
A password is something we're expected to remember, but we're wrong to pick words or numbers that might be easy to remember, such as familiar names or dates. Even if you say pick a system of choosing passwords to remember rather than an individual password, that's impossible. Every different system and site has different password requirements, so no single easy to remember system will work for all of them.
"You have to remember we are all human and we all make mistakes"
Yes, and Mr Thorsheim's mistake is assuming the issue is with the people who are using the system and not the people designing the system. The truth is,
"password systems are lousy at serving people."
(as an aside, WTF is up with systems that do not allow special characters in passwords? Are they worried about SQL injection? If that's possible from a password field, the system is FUBAR.)
Ethanol requirements are corporate welfare for Big Corn.
It has nothing to do with renewable fuels or dependance on imported oil. The second the US has large scale ethanol production not using corn, any requirements for ethanol use will disappear.
Can't skim cards [easily] with this. Apparently to "load" a new card, you've gotta snap some pictures of it and swipe it through the [included] card reader. And the card has to be in your name.
Why does it need a picture of the card? That seems strange. RTFA, but it doesn't have any more detail than your comment. I did like this nugget: "If it loses contact with your phone for a self-designated amount of time, Coin will deactivate itself."
Nice security feature. Until my phone runs out of charge, and suddenly I can make a call and I can't use my credit cards.
I have the same thought from all the proposed smart phone-as-wallet apps. Great, let me put all my eggs in one easy to lose, easy to break basket. This one was interesting until they made it dependant on keeping a live phone near by.
That's like playing Russian Roulette and claiming it's safe since you've never shot yourself yet.
And I'd conclude you've never taken a course in statistics.
"I never hear from people who lose playing Russian Roulette; I only hear from winners. Game must be rigged." Yeah, either that or the losers aren't around to talk about it.
If' I'd been playing Russian Roulette for a few years and had never shot myself, I'd conclude there are no bullets in the gun and feel safe to continue.
Everybody seems to be confusing the term "customer" with "stakeholder". The fact that a person may not understand what they really need when asking for an info system should be no surprise to anyone in the IT industry by now. It's the whole reason for the existence of business analysts like me. Being a good programmer does not by any means guarantee that you are good at gathering and understanding requirements. Being a good BA certainly doesn't make me any sort of programmer (though I do understand the concepts).
And the customer is not always synonymous with user. The role of the BA is important, but it should be part of facilitating communication between the developer and the user, not a firewall keeping them apart.
In all likelihood neither of those is your customer. Your customer is the person tasked with actually using the device, most likely a nurse or doctor, and the organization that pays you for it. The FDA is certainly not your customer. The FDA's job is to ensure you aren't selling snake oil. They do not buy or use your equipment. They are a regulator not a customer. Just because you have to please them doesn't make them your customer.
IAAQISDFAFRC. (I am a quality IS developer for a FDA-regulated company.)
Rarely is the end user the customer. Not to discount the needs of the user, but the doctor or nurse using the product is not the same as the customer paying the bills and setting the requirements.
The FDA is a regulator, but that does not capture the relationship between the company and the government entity. For example, I'm selling a vial of serum A. The regulator wants to make sure the vials actually contain serum A and if there is an issue, I can track down which vials went where and to whom so I can send out a notification or a recall if necessary.
But the labels and packaging with the vials, the FDA will have more input on those than my "customers." Documentation on validation of my systems is going to be more visible to the FDA than my "customers." Reports on product complaints, process deviations, documentation discrepancies, all go to the FDA, not my "customers."
For the software developer working under the regulations of the FDA and other such agencies, those agencies are very much our customers.
As for the example above, regulation may tell you what data the software needs to collect and how to handle that data, but it will not tell you in specifics how to collect that data. So for that nurse, required fields and commonly-used functions should be quick and easy to access. That certain fields are required, I've never known a developer to favor requiring fields when not necessary, so that almost certainly is due to the customer. That the nurse has to enter a value each time and not have the data default to a value from the last record, that's regulation. If it wasn't necessary for the nurse to take the measurement at each exam, the field wouldn't be required. Having a default value is the path to inaccurate data and false records.
It really depends. Talking to people is often better. In large user bases that are isolated, this is hard; but when you're doing i.e. department-to-department, you're far better off asking. If you're writing software systems for Accounting and Finance, for example, there's 200 people working there. You want to interface with the Accounting Manager and Finance Manager--who will be doing, in part, exactly what's proscribed here--while also communicating with some of the actual people in these departments. This will get you a much better understanding of requirements than just "Well I don't know a fucking thing about finance, but I watch the finance people bang their heads on this shit a lot so we should do it this way instead! It would be better!"
What happens often with that scenario is by talking to the people in Finance, the developer ends up thinking he or she has learned something about finance, and can write up requirements which read well and will be accepted by the users, but actually has very little understanding of what the users need and will produce awful software.
There are a few reasons for this. First, every area of expertise has its jargon. Often jargon is an ordinary word with a different, specific meaning in a certain context. So better to follow someone through their work flow and know you're getting lost or not understanding some steps than to have a description you think you understand.
Second, something obvious to anyone who has even a 101 intro level of understanding in a field may be completely unexpected to someone outside of that field. When talking to the folks in Finance, there is some basic assumption so elementary they never mention because everyone in finance covered it in day one, but is completely unknown to the developer with no finance background. Talking will almost never solve this issue. They won't think to mention it; the developer won't know what question to ask.
Third, we relegate tasks to "muscle memory." When describing oft-performed tasks, people invariable miss steps. There are little things that, while vital to successful completion of the process, we forget just because we've done them so many times, they happen without conscious thought. You won't know where these are until you try to replicate results from a procedure someone has described, or if you observe that someone doing the procedure.
So for someone who doesn't know a fucking thing about finance who is developing a system to be used for finance, there's so much more to be gained by watching the finance people bang their heads than just talk to the finance people. As for the Finance Manager, talking to this person should be strictly reserved to some or all of 1) budget of the project, 2) timeline of the project, 3) availability of the finance people for requirements gathering.
A few years I was... After that week of seeing things first hand, the software was fixed in about a month.
That post should be mod'ed to +6 and stapled to the forehead of every project manager or system owner who thinks developers should be kept away from end users.
I think its more about understanding needs. Don't stop at listening may be better. Listen to what they say "I want drop box" and think what does that mean?. Does it mean "I want some third party to make everything work"..... no it means they want a way to make working with files so seamless that it seems like they have a single global filesystem...without having to think about it.
Which is why the developer needs to stop listen and start looking. "I want a drop box" is useless as a business requirement. Even "they want a way to make working with files so seamless that it seems like they have a single global filesystem" is useless. Does the developer have the same understanding as the end user of a term like 'filesystem'?
You are right that it is about understanding needs. However for the daily tasks users perform most often, the repetitive tasks that cause the most pain, the user does not know and cannot articulate what he or she needs. This is not a slight against users.
Here's an exercise: write a procedure, as if you were verbally instructing someone, as how to tie a shoe. Don't look at your shoes! Without visual aids or string for demonstration, with just words, tell someone how to tie a shoe. Unless you've spent a lot of effort dedicated to writing detailed instructions, you are probably not going to come up with a good guide to tying shoes. Does this mean you don't know how to tie your shoes?
No, it means two things. One, some things are easier to communicate through demonstration. And two, when we repeat the same task enough times, it becomes part of "muscle memory." We go on auto-pilot and do things we don't realize we are doing.
I agree with folks saying this is not news, but I also agree with the folks saying this is not done nearly enough.
I admit I may be applying some creative misremembering myself but I definitely recall whether things were bonds or anti-bonds to be somewhat arbitrary and bond energies and lengths were certainly never presented as something that could be derived from first principles.
Which is why at the better programs students take physical chemistry before organic chemistry. P-chem should cover electron orbitals, affinities, and bonds enough that o-chem is a logical application of principles, and not just memorization and intuition.
It seems most chemistry majors and almost all pre-meds do that sequence backwards (organic before physical (if they take physical at all)), so in that aspect I understand the attitude towards organic presented in TFA.
What I argue is there is nothing inherent in organic chemistry that means it must be so. In e.g. calculus, there is no way to memorize all the answers. So should students rely on intuition? Or should they learn the rules of calculus and apply them in a reasonable manner?
For me the most bothersome part of TFA is not what this student has to say, but the quotes from professors and educators. That a science educator would say something along the lines of "if a student has really good math skills, they can slide through physics, but you can’t do that in orgo," that's just shameful. It leads to this attitude from the student, that organic "doesn’t require equations or math."
Slashdot Mirror
I've only used skype a few times. What is skype fraud?
My understanding of skype is it's basically a video phone using your general purpose computer.
I read some of TFA looking for what types of fraud they are talking about, but didn't see any detail. They mention credit card fraud, but that's not a feature of skype. I mean, if some stranger knocks on your door, and when you answer, asks for your credit card number, and you give your credit card number, that's not a weakness in your door or lock, that's a weakness in you.
What I do with my landline is never answer if I don't recognize the number or name in the caller ID. Couldn't I do the same with skype, never answer if I don't know who is calling? There you go, 100% fraud prevention.
What makes a genius?
Roller skates and Acme Corp on speed dial.
Agreed. My first thought was, "If he is doing this for a new job why aren't they supplying him with a laptop so he can use it at home AND at work?" You know, like a sane company would, or at least one with a clue. If they are expecting you to do this extra work, or if you volunteered, the least they could do is supply you with a portable dev machine. Run. Run away from that company.
Because he told them he could do all this stuff. He's already committed to be an expert with .Net and MS-SQL and Porterzebbi and whatever else they asked in the interview. That's why he can't ask them for help with training.
I know it's cliche to complain about Ask /., but this one is really bad. If you can't even figure out how to set up an environment where you can teach yourself programming, you shouldn't be telling other people you know how to program.
The answers here are mind-numbingly trivial. You don't want your kids to access your pr0n...I mean "work stuff," that what user profiles and permissions are for. Don't want your background services (IIS, SQL, etc) to affect performance when you're not working?
1) They won't. How old is the hardware you have? Are we talking turn-of-century type old? If you need anything, it'll be RAM. And if you livelihood depends on it, you can't afford to NOT buy more RAM, no matter how poor you are.
2) Set the services to start manually and create 2 batch files--start_work and stop_work--to start and stop those services with a single command.
Of course another option is VM. But I'll assume since the OP couldn't figure out 1 and 2 above that configuring and using a VM is way above the skill level we have here.
This is not a recent addition to the AP schedule. AP CS has existed at least as far back as the mid 1980s.
As for acceptance, according the College Board, "AP is accepted by more than 3,600 colleges and universities worldwide for college credit, advanced placement, or both on the basis of successful AP Exam grades. This includes over 90 percent of four-year institutions in the United States."
Even if a school doesn't offer credit, having the course on your schedule (or having an AP test score if taken Junior year or earlier) will like help your chances for admission. (Unless there's a low score on the exam.)
Something I expected to see in this thread is a discussion of the material covered by AP CS. I suspect that is at least part of the problem.
AP CS uses Java to teach algorithms, data structures, OOP concepts, and documentation. Is the use of Java part of the issue? I realize a course like this can never be cutting edge or using the latest and greatest, but with all the other resources available, how many high school kids are excited about learning Java?
My take is this: as a high school student if you want to learn calculus, your best bet is probably the AP Calc course (unless there is a near-by university with a decent math department). If you want to learn chemistry or physics, there isn't competition for what an AP course can do for you.
But if you want to learn programming and basic CS concepts, there are a myriad of options--variety not just of course but also of language. I've seen these discussions here, on where to start with teaching or learning programming. If memory serves, Java doesn't come out of such discussions as a clear choice for young students.
How does being the owner of something entitle you to someone else being required to provide the means to destroy it?
That's what "ownership" means. You get to control it.
If you want that capability you should have thought about that before you created it.
Without question.
But the policy at Nextdoor.com is that you own your content. If in fact you can't control aspects of access or the current state (destroy or keep), than you *don't* own it.
What does that mean for your posts here? "Comments owned by the poster." Yet you can't edit or delete posts.
Seems Subby is the type who doesn't learn from mistakes. In trying to remove "owned" content from one site, you just get more content created with the same issues on a different site.
When I first started working in IT, back in my early software days (as a tech writer),
Apparently "early software days" means "before invention of the paragraph." ;)
It's time to start a boycott of Slashdot. These summaries are getting too bad to ignore. Weeklong hours? Peace prize in physiology or medicine?
I might have to resosrt to doing work to pass the day.
weeklong Hour of Code
How about 'learn to tell time' before 'learn to code'? If they don't know the difference between a week and an hour, I doubt they have much to contribute in the areaof education.
But the main point is that States simply don't have any legal basis for taxing transactions that happen in another State. Period. That is a violation of our separation of powers.
1) This is not an issue separation of powers. SoP is between branches of government, not between states.
2) This case is not about taxing transaction that happen in another state. This is about who has to collect taxes and what constitutes a business presence in a state.
If I'm in state A and Amazon doesn't have a business presence in state A, then Amazon doesn't collect taxes for state A. But if Amazon has an affiliate or other partners in state A, is that enough to qualify as a business presence?
Why is it bad? Anything that even *leans* towards someone in state A having to pay taxes to, and which were legislated in, state B, is destructive to the very fabric of the states.
Yeah, but there isn't any of that in this case. The people paying taxes to state B are in state B. The question isn't even does someone/business in state A have to collect taxes for state B. The question is for a business like Amazon, what does it mean to "be" in a state.
This may be a bad decision, but your comment doesn't address why.
A good password is one that you don't mentally consider a word or string of words, as much as it is a dance that you do with your hands and fingers, really really fast.
On that note, non-printing characters should be allowed as part of a password. E.g. "12345" is a bad password. But why shouldn't we be able to use "12356[backspace][backspace]45"?
"people are lousy at picking good passwords"
This begs the question. There is some reasonable expectation that people should learn to properly use the tools of modern society, but in the end, the tools should serve the people, not the other way around. If your car pulled to the left, would you say you were lousy at driving in a straight line? No, you'd say your car was out of alignment and get it fixed.
A password is something we're expected to remember, but we're wrong to pick words or numbers that might be easy to remember, such as familiar names or dates. Even if you say pick a system of choosing passwords to remember rather than an individual password, that's impossible. Every different system and site has different password requirements, so no single easy to remember system will work for all of them.
"You have to remember we are all human and we all make mistakes"
Yes, and Mr Thorsheim's mistake is assuming the issue is with the people who are using the system and not the people designing the system. The truth is,
"password systems are lousy at serving people."
(as an aside, WTF is up with systems that do not allow special characters in passwords? Are they worried about SQL injection? If that's possible from a password field, the system is FUBAR.)
A wind farm getting blown away by a typhoon is ironic. A geothermal plant getting blown away is not.
Come on NYT! That not paradoxical; it's ironic.
It's not ironic, it's unfortunate.
Ethanol requirements are corporate welfare for Big Corn.
It has nothing to do with renewable fuels or dependance on imported oil. The second the US has large scale ethanol production not using corn, any requirements for ethanol use will disappear.
Can't skim cards [easily] with this. Apparently to "load" a new card, you've gotta snap some pictures of it and swipe it through the [included] card reader. And the card has to be in your name.
Why does it need a picture of the card? That seems strange. RTFA, but it doesn't have any more detail than your comment. I did like this nugget:
"If it loses contact with your phone for a self-designated amount of time, Coin will deactivate itself."
Nice security feature. Until my phone runs out of charge, and suddenly I can make a call and I can't use my credit cards.
I have the same thought from all the proposed smart phone-as-wallet apps. Great, let me put all my eggs in one easy to lose, easy to break basket. This one was interesting until they made it dependant on keeping a live phone near by.
No accidents so far
That's like playing Russian Roulette and claiming it's safe since you've never shot yourself yet.
And I'd conclude you've never taken a course in statistics.
"I never hear from people who lose playing Russian Roulette; I only hear from winners. Game must be rigged." Yeah, either that or the losers aren't around to talk about it.
If' I'd been playing Russian Roulette for a few years and had never shot myself, I'd conclude there are no bullets in the gun and feel safe to continue.
Everybody seems to be confusing the term "customer" with "stakeholder". The fact that a person may not understand what they really need when asking for an info system should be no surprise to anyone in the IT industry by now. It's the whole reason for the existence of business analysts like me. Being a good programmer does not by any means guarantee that you are good at gathering and understanding requirements. Being a good BA certainly doesn't make me any sort of programmer (though I do understand the concepts).
And the customer is not always synonymous with user. The role of the BA is important, but it should be part of facilitating communication between the developer and the user, not a firewall keeping them apart.
I liked /. more before it became predominantly slashvertisements and marketing focus groups.
What did I think of the movie? I thought they should rastify Thor by 10% or so.
My customer is the patient and the FDA.
In all likelihood neither of those is your customer. Your customer is the person tasked with actually using the device, most likely a nurse or doctor, and the organization that pays you for it. The FDA is certainly not your customer. The FDA's job is to ensure you aren't selling snake oil. They do not buy or use your equipment. They are a regulator not a customer. Just because you have to please them doesn't make them your customer.
IAAQISDFAFRC. (I am a quality IS developer for a FDA-regulated company.)
Rarely is the end user the customer. Not to discount the needs of the user, but the doctor or nurse using the product is not the same as the customer paying the bills and setting the requirements.
The FDA is a regulator, but that does not capture the relationship between the company and the government entity. For example, I'm selling a vial of serum A. The regulator wants to make sure the vials actually contain serum A and if there is an issue, I can track down which vials went where and to whom so I can send out a notification or a recall if necessary.
But the labels and packaging with the vials, the FDA will have more input on those than my "customers." Documentation on validation of my systems is going to be more visible to the FDA than my "customers." Reports on product complaints, process deviations, documentation discrepancies, all go to the FDA, not my "customers."
For the software developer working under the regulations of the FDA and other such agencies, those agencies are very much our customers.
As for the example above, regulation may tell you what data the software needs to collect and how to handle that data, but it will not tell you in specifics how to collect that data. So for that nurse, required fields and commonly-used functions should be quick and easy to access. That certain fields are required, I've never known a developer to favor requiring fields when not necessary, so that almost certainly is due to the customer. That the nurse has to enter a value each time and not have the data default to a value from the last record, that's regulation. If it wasn't necessary for the nurse to take the measurement at each exam, the field wouldn't be required. Having a default value is the path to inaccurate data and false records.
It really depends. Talking to people is often better. In large user bases that are isolated, this is hard; but when you're doing i.e. department-to-department, you're far better off asking. If you're writing software systems for Accounting and Finance, for example, there's 200 people working there. You want to interface with the Accounting Manager and Finance Manager--who will be doing, in part, exactly what's proscribed here--while also communicating with some of the actual people in these departments. This will get you a much better understanding of requirements than just "Well I don't know a fucking thing about finance, but I watch the finance people bang their heads on this shit a lot so we should do it this way instead! It would be better!"
What happens often with that scenario is by talking to the people in Finance, the developer ends up thinking he or she has learned something about finance, and can write up requirements which read well and will be accepted by the users, but actually has very little understanding of what the users need and will produce awful software.
There are a few reasons for this. First, every area of expertise has its jargon. Often jargon is an ordinary word with a different, specific meaning in a certain context. So better to follow someone through their work flow and know you're getting lost or not understanding some steps than to have a description you think you understand.
Second, something obvious to anyone who has even a 101 intro level of understanding in a field may be completely unexpected to someone outside of that field. When talking to the folks in Finance, there is some basic assumption so elementary they never mention because everyone in finance covered it in day one, but is completely unknown to the developer with no finance background. Talking will almost never solve this issue. They won't think to mention it; the developer won't know what question to ask.
Third, we relegate tasks to "muscle memory." When describing oft-performed tasks, people invariable miss steps. There are little things that, while vital to successful completion of the process, we forget just because we've done them so many times, they happen without conscious thought. You won't know where these are until you try to replicate results from a procedure someone has described, or if you observe that someone doing the procedure.
So for someone who doesn't know a fucking thing about finance who is developing a system to be used for finance, there's so much more to be gained by watching the finance people bang their heads than just talk to the finance people. As for the Finance Manager, talking to this person should be strictly reserved to some or all of 1) budget of the project, 2) timeline of the project, 3) availability of the finance people for requirements gathering.
Something something Gemba something something Kaizen something something reason US auto manfucaturing had to play catch-up to the Japanese
A few years I was ... After that week of seeing things first hand, the software was fixed in about a month.
That post should be mod'ed to +6 and stapled to the forehead of every project manager or system owner who thinks developers should be kept away from end users.
I think its more about understanding needs. Don't stop at listening may be better. Listen to what they say "I want drop box" and think what does that mean?. Does it mean "I want some third party to make everything work"..... no it means they want a way to make working with files so seamless that it seems like they have a single global filesystem...without having to think about it.
Which is why the developer needs to stop listen and start looking. "I want a drop box" is useless as a business requirement. Even "they want a way to make working with files so seamless that it seems like they have a single global filesystem" is useless. Does the developer have the same understanding as the end user of a term like 'filesystem'?
You are right that it is about understanding needs. However for the daily tasks users perform most often, the repetitive tasks that cause the most pain, the user does not know and cannot articulate what he or she needs. This is not a slight against users.
Here's an exercise: write a procedure, as if you were verbally instructing someone, as how to tie a shoe. Don't look at your shoes! Without visual aids or string for demonstration, with just words, tell someone how to tie a shoe. Unless you've spent a lot of effort dedicated to writing detailed instructions, you are probably not going to come up with a good guide to tying shoes. Does this mean you don't know how to tie your shoes?
No, it means two things. One, some things are easier to communicate through demonstration. And two, when we repeat the same task enough times, it becomes part of "muscle memory." We go on auto-pilot and do things we don't realize we are doing.
I agree with folks saying this is not news, but I also agree with the folks saying this is not done nearly enough.
I admit I may be applying some creative misremembering myself but I definitely recall whether things were bonds or anti-bonds to be somewhat arbitrary and bond energies and lengths were certainly never presented as something that could be derived from first principles.
Which is why at the better programs students take physical chemistry before organic chemistry. P-chem should cover electron orbitals, affinities, and bonds enough that o-chem is a logical application of principles, and not just memorization and intuition.
It seems most chemistry majors and almost all pre-meds do that sequence backwards (organic before physical (if they take physical at all)), so in that aspect I understand the attitude towards organic presented in TFA.
What I argue is there is nothing inherent in organic chemistry that means it must be so. In e.g. calculus, there is no way to memorize all the answers. So should students rely on intuition? Or should they learn the rules of calculus and apply them in a reasonable manner?
For me the most bothersome part of TFA is not what this student has to say, but the quotes from professors and educators. That a science educator would say something along the lines of "if a student has really good math skills, they can slide through physics, but you can’t do that in orgo," that's just shameful. It leads to this attitude from the student, that organic "doesn’t require equations or math."