"FAO calculates that around half of the world's hungry people are from smallholder farming communities, surviving off marginal lands prone to natural disasters like drought or flood. Another 20 percent belong to landless families dependent on farming"
"there are 842 million hungry people in the world"
If you are really interested. There are some open source programs that do static analysis also. Have a look e.g. at the source code of Cppcheck ( http://cppcheck.sourceforge.net/ ) to see how it works. E.g. some potential performance issues are pretty easy to detect, e.g. using i++ instead of ++i for objects. Or passing a copy of string instead of a reference.
If you want to know what kind of faults can be found or what do they look at on the source level, here is a list of bugs that Cppcheck has found from open source projects (obviously not everything is listed, but it should give you a pretty good picture): https://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Found_bugs
> But we think we've only found about half of the "annihilate a city" 300-m sized ones
Not only that, but e.g. one 400-m sized one might hit the earth in a couple of months, but we don't know for sure whether it will hit or not, because last observation for it was in year 2008. It is very unlikely that it would hit us, but still... we don't know. http://neo.jpl.nasa.gov/risk/2008uv99.html
Summary: organizational distance between employees is best known way to predict bugs in a software project. It is even better than code coverage, complexity or pre-release bugs. In best case scenario all employees work for the same boss and you get best quality. In worst case scenario they work for different companies and you get the worst quality.
Derren Brown and a few others have shown how to hypnotize a person during a handshake and make them sleep within seconds. Is that real of fake? If you have never seen it, here is a video: http://www.youtube.com/watch?v=cSCA6osMHx4
> You're suggesting I switch my mind and SCM state to this newly spotted thing, fix it, submit it and then come back?
I do this a lot. I have written, reverted and rewritten code sometimes even 5 times before I have been able to commit what I originally was planning to do (yes, I also create patches/branches when suitable). Some might think that I wasted a lot of time there, but every time I wrote the code, I learned something knew that allowed me to make better decisions.
> And even if it goes perfectly, have I been spending my time wisely? Was that newly spotted bug a high priority, urgent job, or a low priority, non time-critical job?
I have seen people spending weeks trying to fix a bug that was caused by a low priority bug they saw instantly, but didn't fix, because they wanted to fix the high priority bug first.
Quite often, fixing something that is very low priority can save millions of dollars for the project, but no-one can see the cost, because it is so well hidden. E.g. every time you add a new text, you have to write it into 4 different files, and sometimes it is forgotten and thus time is wasted both for writing it and then finding&fixing the bug it caused. This is a common hidden cost, caused by a low priority bug (duplication in source code, usually not even marked in the project bug tracker).
If you only fix what is the most important, be sure that you know what it is.
> I would say that this is similar to a chessmaster who has solved countless chess puzzles.
Chess masters recognize patterns in chess like they recognize faces. Show them a realistic pattern for a few seconds and they can remember it. Show them a random pattern and they won't remember it.
You can test this with programmers. Create a pattern, e.g. a common for loop: for( int i = 0; i 10; i++ ) {
print i; }
Show this to a person for a couple of seconds and ask them to rewrite it out from their memory. If they can do it, they are more likely experienced. If they can't, they are more likely not experienced. To make the test more fool proof, you should also create a random pattern from those characters and test if the person can remember that. As some people actually have a very good memory even if they are not programmers.
> Software engineering does not introduce random mutations into the Software and then selects the mutations that made a the Software a little bit more useable
I think that usability and user experience are more important that programming. I think usability and user experience should be taught to everyone at school. It wouldn't require that much hours as it is mostly common sense. And because it is common sense, it would be really easy for people to learn, unlike programming.
Imagine doors that people can open to correct direction without a mistake. Imagine books where the information you seek is easy to found. Imagine ovens that are easy to heat and light switches with 10 buttons where you instantly know which button will start which light. That all is reality, if people had a little knowledge about usability.
Imagine alarm clocks that gently wake you up. Imagine a wheelchair that makes you look cool. Imagine an error message that informs you about your own mistake so politely that it makes you feel good that you made the mistake. All this is possible if people had a little knowledge about user experience.
Imagine if all the programmers would read just a couple of books on this subject. Does Entrepreneurs need to know this stuff? No way. But I'm pretty sure that Jobs did.
> with 310+ million Americans each would only need to drive 3 miles a year to reach a billion.
With actual numbers: "There were 190,625,023 licensed drivers in the United States in 2000." [1] 190625023 * 3 = 571875069
So not only are you wrong, but I don't see your point either. Americans drive a lot, but they also have a lot of car accidents. (Feel feel to provide more recent numbers, but you won't get a billion even if you count the whole population.)
To be fair, I think that computer controlled car should be granted the right to drive, if it can pass the driving test, which human drivers need to pass. Should there be an accident, the company that provided the car should pay. That is unfair for the company, but it is to earn the trust of the population and to ensure that cars have as little defects as possible.
> We have deserts in America, we just don't live in them asshole!
Las Vegas is in a desert. They just put some water pipes there and started living there. In Brazil they have started to grow stuff in places where the soil is poisonous and where nothing grows. They simply investigated what makes the soil so bad and modified the soil to fix it.
On the other hand, people have cut down all trees on some areas and erosion has taken all the soil and places that were full of plants are now deserts. People have had to move out from locations that had fresh water and plenty of food, because their houses are now covered by sand, due to hacking down all the trees.
So neither desert or forest is something stable. You can change the environment. It is just a lot more easy to create a desert than it is to create a forest. That is why it is good that in some countries (e.g. in Finland) it is illegal to cut down forest without planting new trees to replace them and e.g. in China they have the National Tree-planting Day.
We could solve this voting issue very easily. Every vote costs a dollar and you can vote as many times as you want. It would be no different from the current system where only the rich have enough money to advertise themselves to get voted.
> People are not going to spend months developing books and products if some parasite can just copy their work
"I don't ask for money. I don't ask for sexual favors. I don't ask for access to the hardware you design and sell. I just ask for the thing I gave you: source code that I can use myself."
Torvalds, Linus (2007-06-14). Message to Linux kernel mailing list. Retrieved on 2010-02-01.
Linux kernel is about 20 years old (So Linus has been developing it for a little longer than a few months). It has been sold commercially by people who didn't even ask permission from Linus before doing that. And Linus is okay with that. If you need more examples, you can google for free software, free movies, free books, free music.
I also learned programming myself, over 15 years ago. Yet I have still today learned a lot of useful stuff from others who I have worked with.
This is what I think: - If he is motivated to learn by himself, that is the best way to start. Not because of what you learn about programming, but because of what you learn about learning and studying new stuff.
- After a year or so, if possible, get a good mentor. This time, to learn about programming. There is a lot of advanced topics which you don't even know to exist unless you have a really good book or a really good mentor. This doesn't mean that you couldn't study this stuff by yourself, but you will need someone to tell you what to study. Here is a list, which contains topics, perhaps a bit too advanced for someone who just started to program, but the list contains a lot of things I wish someone had told me sooner: -- unit testing (more important than the program itself), -- more about testing and what you can do with it, e.g. performance testing -- pair programming -- writing clean code (e.g. why it is important that you think really hard how to many each variable you create), -- refactoring (how you can do it and why you should), -- programming principles and patterns (e.g. why a class or a function should have only one responsibility), -- usability (how you can analyse it and improve it), -- user experience (why people think that the software is faster and has less errors just because you changes the error messages more polite), -- tools(version control, IDE, continuous integration with static and dynamic analysis, and how they can help you do your job). -- Agile methods, lean, kanban. (these are pretty good to know when you start working for real)
My recommendation for language: Python with pygame (for writing games).
> Through in gimp, sure you might be able to do all the things that you can do in photoshop but there will be a huge learning curve.
I have to disagree with you. We did usability test with 3 people who had no experience with Gimp, but some had experience from Photoshop. None of them had any major problems and everyone was able to complete the tasks without help. The results of the tests were the exact opposite of the impression I have seen in Slashdot. Gimp is actually very easy to learn and use. I was especially impressed with the Photoshop user, he had no problems doing special tricks with Gimp, even he couldn't find the same tools he had been using in Photoshop.
Not if you write it down. I have kept a record of these predictions. None of them came true. E.g. in 2005 it was predicted that by 2006 we should have invented material for space elevator cables... still waiting for that.
None of the predictions I have monitored have come true. Some have changed the schedule, some have completely disappeared. But no worries, soon we have contacted ET, have eternal lives and we drive with flying cars. It is unfortunate that the Internet crashed a few years ago, but at least we don't need to worry about spam.
Slashdot Mirror
"FAO calculates that around half of the world's hungry people are from smallholder farming communities, surviving off marginal lands prone to natural disasters like drought or flood. Another 20 percent belong to landless families dependent on farming"
"there are 842 million hungry people in the world"
http://www.wfp.org/hunger/who-...
Rainforests 28%, oceans 70%, other 2%.
http://education.nationalgeogr...
If you are really interested. There are some open source programs that do static analysis also. Have a look e.g. at the source code of Cppcheck ( http://cppcheck.sourceforge.net/ ) to see how it works. E.g. some potential performance issues are pretty easy to detect, e.g. using i++ instead of ++i for objects. Or passing a copy of string instead of a reference.
If you want to know what kind of faults can be found or what do they look at on the source level, here is a list of bugs that Cppcheck has found from open source projects (obviously not everything is listed, but it should give you a pretty good picture):
https://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Found_bugs
> But we think we've only found about half of the "annihilate a city" 300-m sized ones
Not only that, but e.g. one 400-m sized one might hit the earth in a couple of months, but we don't know for sure whether it will hit or not, because last observation for it was in year 2008. It is very unlikely that it would hit us, but still... we don't know. http://neo.jpl.nasa.gov/risk/2008uv99.html
> there are companies out there whose sole purpose in life is not to screw you over.
I think you might find this study interesting:
"THE INFLUENCE OF ORGANIZATIONAL STRUCTURE ON SOFTWARE QUALITY: AN EMPIRICAL CASE STUDY":
http://research.microsoft.com/pubs/70535/tr-2008-11.pdf
Summary: organizational distance between employees is best known way to predict bugs in a software project. It is even better than code coverage, complexity or pre-release bugs. In best case scenario all employees work for the same boss and you get best quality. In worst case scenario they work for different companies and you get the worst quality.
Derren Brown and a few others have shown how to hypnotize a person during a handshake and make them sleep within seconds. Is that real of fake?
If you have never seen it, here is a video: http://www.youtube.com/watch?v=cSCA6osMHx4
> You're suggesting I switch my mind and SCM state to this newly spotted thing, fix it, submit it and then come back?
I do this a lot. I have written, reverted and rewritten code sometimes even 5 times before I have been able to commit what I originally was planning to do (yes, I also create patches/branches when suitable). Some might think that I wasted a lot of time there, but every time I wrote the code, I learned something knew that allowed me to make better decisions.
> And even if it goes perfectly, have I been spending my time wisely? Was that newly spotted bug a high priority, urgent job, or a low priority, non time-critical job?
I have seen people spending weeks trying to fix a bug that was caused by a low priority bug they saw instantly, but didn't fix, because they wanted to fix the high priority bug first.
Quite often, fixing something that is very low priority can save millions of dollars for the project, but no-one can see the cost, because it is so well hidden. E.g. every time you add a new text, you have to write it into 4 different files, and sometimes it is forgotten and thus time is wasted both for writing it and then finding&fixing the bug it caused. This is a common hidden cost, caused by a low priority bug (duplication in source code, usually not even marked in the project bug tracker).
If you only fix what is the most important, be sure that you know what it is.
> I would say that this is similar to a chessmaster who has solved countless chess puzzles.
Chess masters recognize patterns in chess like they recognize faces. Show them a realistic pattern for a few seconds and they can remember it. Show them a random pattern and they won't remember it.
You can test this with programmers. Create a pattern, e.g. a common for loop:
for( int i = 0; i 10; i++ )
{
print i;
}
Show this to a person for a couple of seconds and ask them to rewrite it out from their memory. If they can do it, they are more likely experienced. If they can't, they are more likely not experienced. To make the test more fool proof, you should also create a random pattern from those characters and test if the person can remember that. As some people actually have a very good memory even if they are not programmers.
> Software engineering does not introduce random mutations into the Software and then selects the mutations that made a the Software a little bit more useable
I think the he was talking about evolutionary algorithms: http://en.wikipedia.org/wiki/Evolutionary_algorithm
> It's nearly impossible to find much of any negative science on drinking coffee.
"Drinking three cups of coffee a day linked with vision loss and blindness"
http://www.dailymail.co.uk/health/article-2213308/Coffee-cups-day-increase-risk-vision-loss-blindness.html?ito=feeds-newsxml
But you learned from that, didn't you?
I think that usability and user experience are more important that programming. I think usability and user experience should be taught to everyone at school. It wouldn't require that much hours as it is mostly common sense. And because it is common sense, it would be really easy for people to learn, unlike programming.
Imagine doors that people can open to correct direction without a mistake. Imagine books where the information you seek is easy to found. Imagine ovens that are easy to heat and light switches with 10 buttons where you instantly know which button will start which light. That all is reality, if people had a little knowledge about usability.
Imagine alarm clocks that gently wake you up. Imagine a wheelchair that makes you look cool. Imagine an error message that informs you about your own mistake so politely that it makes you feel good that you made the mistake. All this is possible if people had a little knowledge about user experience.
Imagine if all the programmers would read just a couple of books on this subject. Does Entrepreneurs need to know this stuff? No way. But I'm pretty sure that Jobs did.
> with 310+ million Americans each would only need to drive 3 miles a year to reach a billion.
With actual numbers:
"There were 190,625,023 licensed drivers in the United States in 2000." [1]
190625023 * 3 = 571875069
So not only are you wrong, but I don't see your point either. Americans drive a lot, but they also have a lot of car accidents. (Feel feel to provide more recent numbers, but you won't get a billion even if you count the whole population.)
To be fair, I think that computer controlled car should be granted the right to drive, if it can pass the driving test, which human drivers need to pass. Should there be an accident, the company that provided the car should pay. That is unfair for the company, but it is to earn the trust of the population and to ensure that cars have as little defects as possible.
1) http://www.fhwa.dot.gov/ohim/onh00/onh2p4.htm
> We have deserts in America, we just don't live in them asshole!
Las Vegas is in a desert. They just put some water pipes there and started living there. In Brazil they have started to grow stuff in places where the soil is poisonous and where nothing grows. They simply investigated what makes the soil so bad and modified the soil to fix it.
On the other hand, people have cut down all trees on some areas and erosion has taken all the soil and places that were full of plants are now deserts. People have had to move out from locations that had fresh water and plenty of food, because their houses are now covered by sand, due to hacking down all the trees.
So neither desert or forest is something stable. You can change the environment. It is just a lot more easy to create a desert than it is to create a forest. That is why it is good that in some countries (e.g. in Finland) it is illegal to cut down forest without planting new trees to replace them and e.g. in China they have the National Tree-planting Day.
> I am paying for the product I have asked you to build.
Wouldn't you rather want to see what you are going to get and change it, before you get what you didn't want?
http://johngushue.typepad.com/.a/6a00d83451f25369e20120a513810c970b-pi
We could solve this voting issue very easily. Every vote costs a dollar and you can vote as many times as you want. It would be no different from the current system where only the rich have enough money to advertise themselves to get voted.
> People are not going to spend months developing books and products if some parasite can just copy their work
"I don't ask for money. I don't ask for sexual favors. I don't ask for access to the hardware you design and sell. I just ask for the thing I gave you: source code that I can use myself."
Torvalds, Linus (2007-06-14). Message to Linux kernel mailing list. Retrieved on 2010-02-01.
Linux kernel is about 20 years old (So Linus has been developing it for a little longer than a few months). It has been sold commercially by people who didn't even ask permission from Linus before doing that. And Linus is okay with that. If you need more examples, you can google for free software, free movies, free books, free music.
I would like to add that Javascript can be used to write back-end code also: http://nodejs.org/
Look for yourself:
http://en.wikipedia.org/wiki/List_of_Nobel_laureates_in_Physiology_or_Medicine
> You cannot obtain a patent on something that is public knowledge.
Yes, it is not like you could just go there and patent a wheel: http://www.newscientist.com/article/dn965-wheel-patented-in-australia.html
I also learned programming myself, over 15 years ago. Yet I have still today learned a lot of useful stuff from others who I have worked with.
This is what I think:
- If he is motivated to learn by himself, that is the best way to start. Not because of what you learn about programming, but because of what you learn about learning and studying new stuff.
- After a year or so, if possible, get a good mentor. This time, to learn about programming. There is a lot of advanced topics which you don't even know to exist unless you have a really good book or a really good mentor. This doesn't mean that you couldn't study this stuff by yourself, but you will need someone to tell you what to study. Here is a list, which contains topics, perhaps a bit too advanced for someone who just started to program, but the list contains a lot of things I wish someone had told me sooner:
-- unit testing (more important than the program itself),
-- more about testing and what you can do with it, e.g. performance testing
-- pair programming
-- writing clean code (e.g. why it is important that you think really hard how to many each variable you create),
-- refactoring (how you can do it and why you should),
-- programming principles and patterns (e.g. why a class or a function should have only one responsibility),
-- usability (how you can analyse it and improve it),
-- user experience (why people think that the software is faster and has less errors just because you changes the error messages more polite),
-- tools(version control, IDE, continuous integration with static and dynamic analysis, and how they can help you do your job).
-- Agile methods, lean, kanban. (these are pretty good to know when you start working for real)
My recommendation for language: Python with pygame (for writing games).
Yes, we count with our fingers, that is why we use base 16 and can count up to 0xFF:
http://en.wikipedia.org/wiki/File:Hexadecimal-counting.jpg
> Through in gimp, sure you might be able to do all the things that you can do in photoshop but there will be a huge learning curve.
I have to disagree with you. We did usability test with 3 people who had no experience with Gimp, but some had experience from Photoshop. None of them had any major problems and everyone was able to complete the tasks without help. The results of the tests were the exact opposite of the impression I have seen in Slashdot. Gimp is actually very easy to learn and use. I was especially impressed with the Photoshop user, he had no problems doing special tricks with Gimp, even he couldn't find the same tools he had been using in Photoshop.
> Actually, fitting a camel through a real eye of a needle isn't impossible
If you got the money, just buy a bigger needle.
Not if you write it down. I have kept a record of these predictions. None of them came true. E.g. in 2005 it was predicted that by 2006 we should have invented material for space elevator cables... still waiting for that.
None of the predictions I have monitored have come true. Some have changed the schedule, some have completely disappeared. But no worries, soon we have contacted ET, have eternal lives and we drive with flying cars. It is unfortunate that the Internet crashed a few years ago, but at least we don't need to worry about spam.