Your view is common. I held it myself for a long time. I have since changed my mind. The real problem is that programming is taught very badly pretty much everywhere.

I spent 20 years as a programmer and then taught English as a foreign language for 5 years. I am now back programming, but I have started to apply what I learned as a teacher to programming. Just like programming, foreign languages are usually taught badly: the idea is to teach grammar and drill vocabulary. The students jam words together using the grammar and eventually learn how to speak. The problem is that most people are not very good at this technique, leading everyone to the conclusion that you need to have some sort of talent for learning languages in order to become fluent at a second language. I have found (like a lot of other teachers) that this is a poor way to teach. It is better to use "comprehensible input" to build fluency. The idea is that if you furnish students with a large amount of input that they can understand, they will acquire language. So instead of breaking up language by category and teaching rules that students apply, you give them language in context that they can understand and have a high amount of repetition. My experience (at high school level) is that the vast majority of my students could reach a surprisingly high level of fluency.

When I went back to programming a couple of years ago, I started mentoring some of the guys on the team who were under performing. Their main problem was that they would not understand what was going on in the code and would resort to "programming by google" (i.e. just cut and paste whatever crap from stack overflow that seemed relevant into the code). I talked with these team members and asked them, "When you read the code, how much of it do you understand perfectly". The answer was "70-80%". I explained the input hypothesis and told them that in order to reach fluency with the code, they would have to understand 95% of everything they read. Or, since it is hard to tell if you understand 95%, they should aim for 100% comprehension. After a few times where they fell back and claimed that it was "impossible" to understand all of the code (and I demonstrated that it was not impossible), they started taking more time to comprehend what was in the code base. Within a few months, their level improved dramatically.

I'm not saying that anyone can be a great programmer. But, most people who are diligent enough to graduate from college can become a half decent programmer. Our team is rather special in that we provide a lot of time and support to allow people to improve. I think the reason most teams can only get good productivity with talented programmers is that they essentially abandon them once they join the team. If you don't have the chops, then you don't deserve to be here. I've actually said that before, to my shame. I now think that most people who are interested in programming can be a programmer if they are taught properly.

In over 20 years as a professional programmer, I have met many, many good programmers. In the same time period, I have met maybe 3 competent program managers (or business analysts, or whatever they call them in your neck of the woods). I'm lucky to be working with a great program manager right now and it is amazing what a difference it makes. I would easily trade half my team for that one person. There will be a lot of people here who have *never* worked with a competent PGM.

If you have people skills, organizational skills, can find a way to not go crazy listening to programmers complain about minutia, and can grasp technical concepts you can be a good PGM. Which probably explains why there aren't very many... Rather than push people who are not interested in techie things to become programmers, why not look for people who are interested in talking to people, listening to problems and organizing things. Train them as PGMs.

I can't really understand what you are talking about. A Calfee frame costs $3000 and weighs 6-7 pounds. My entry level (knock off Asian clone) carbon fiber frame costs $800 and weighs 2.1 pounds.

My entire bike weighs in at 17.5 lbs (I have crap wheels and a heavy seat post). Adding 4 pounds for the frame is nearly a 25% increase in weight. If I was going to spend $3000 on a frame, I would certainly match it with decent wheels and seat post. This would change the weight increase to over 30%.

Bamboo, while cool, is an expensive way to dramatically increase the weight of a bike. Not that I'm a weight weenie... But if I wanted a "heavy" bike, I could get a great aluminium or steel frame and spend the other $2000+ on the rest of the bike. A Caad10 aluminium frame, which is a very decent frame, weighs 2.4 pounds. Top of the line steel frames weigh about the same. Honestly, I can't really tell the difference in weight when riding a bike with a 3 oz heavier frame, but I can definitely tell the difference with a 4 lb heavier frame.

I can see this working very similarly to the free software movement. As you correctly point out, there are already plenty of gardeners who are passionate about seed sharing. The internet allowed free software to be an efficient method of software development and distribution. 30 years on, it has even reached mainstream development. Just look at the percentage of teams using free software development tools (especially in web development).

In the past, it was difficult for an individual (dare I say hobbyist) to develop a useful new variety of plant. You need a lot of time, effort and especially land. But what if you can coordinate with other hobbyists over the internet? What if you all agreed that you would share seed? What if you all agreed that nobody could restrict the future use of these seeds. Now you have many hands, and many small plots of land, and many different growing environments, pollen, etc. Suddenly it scales.

What is needed is coordination and trust. The GPL created a level playing field that allowed people to trust each other when collaborating in software development. I'm not sure, but having a similar agreement for seed development does not sound like a bad idea to me.

Just to clarify. The lawsuit that I'm aware of entailed a farmer using roundup on his field and discovering that some things didn't die. These were volunteers from a neighbouring farmer's field that blew into his. He collected that seed and grew a subsequent crop of roundup resistant plants. While the farmer was not obliged under contract not to replant these seeds, the act of planting was considered patent infringement.

Personally I'm not a fan of the laws that allow this to happen, but probably this was a good legal judgement. It is important to get the fact right, though. I would have no problem with a seed company selling seed under a contract. I have a fairly big problem with the concept that planting a seed is patent infringement. But that's what the law allows right now.

Random guy here. I may be wrong, but I think you are confusing inflation with deflation. The value of BTC is rising against real goods. So in other words, it costs less in BTC to buy things today than it did last year. This is deflation.

I have been watching Bitcoin with interest to see what it will do. In hindsight, if I were to criticise Bitcoin, I would say that it is too difficult to receive BTC. It is interesting that the very thing that makes it secure has the potential to limit its distribution. As the price of BTC goes up, it becomes more lucrative to mine. This increases interest in mining and encourages people to invest in hardware to mine. This, in turn, increases the difficulty, raising the barrier to entry. So new BTC are likely to remain in a relatively small group of people.

Of course, people can buy BTC, but if they do so speculatively, they may be loath to part with the BTC until they have made a profit. This can further limit the spread of BTC. In other words, you could get into a situation where people holding BTC are largely those who have spent a large amount of money mining it, and those who are speculating on its value. For those who wish to use BTC as a token of exchange for goods and services, it can be difficult/expensive to acquire in any quantity.

I think it would have been better to encourage inflation. In an inflationary system, currency essentially expires. The longer you hold it, the less value it holds. This is an excellent feature because it encourages the use of the currency, allowing it to get into the hands of people who will use it for true growth (i.e., producing something that has tangible value to someone else). If I can not get my hands on currency, or the barrier to entry to getting currency is too difficult, then my potential productivity is wasted. I can't obtain the resources I need to do my work. The currency has failed to do its job.

Obviously this topic is too broad to discuss intelligently in a /. post. However, I would encourage Bitcoin developers to look at modern economics with a more critical eye. I think many people are unwisely discarding a lot of economic theory without really understanding it properly.

He's a contractor. Win, lose, blame, credit; what does it matter to him?

People hire contractors because they have problems that they can't or won't solve themselves. This is the nature of the job. A good contractor, one that gets hired again and again, doesn't panic just because the job is difficult. Even if the job is impossible, he simply says so before he carries on anyway.

Relax. Write code. Get paid. Drink Beer.

Try to find small towns on the coast. The ocean is dark, which helps a lot. You will probably have to stay overnight, but if you are travelling anyway, I guess that's not such a big problem. I lived for 5 years in a small town on the coast in Japan. I could see the Milky Way every clear night on the ocean side. Couldn't see squat on the land side... Now I'm living in Watford. Last night it was clear enough that I could see a dozen stars and I was thankful for it. Can't wait to get back to my small town.

I am probably unusual in that I have both worked as a teacher of foreign languages and as a computer programmer. The key here is, "What is a foreign language?". In the US, Spanish is designated a "foreign language" in most school districts. There are even areas where Spanish is the dominant language and Spanish is designated a "foreign language". Many of my colleagues and I have argued that we should be teaching a "second language" rather than a "foreign language". The distinction is small, but important. Foreign language teaching is aimed at teaching a language which is not in use near the student. The student doesn't have ready opportunities to acquire the language through their own efforts and must rely on the teacher to provide everything in the classroom.

Teaching a "second language" (or third or fourth -- "second" is a technical term that refers to any language that is not your primary language) is focussed on teaching the student skills to acquire language under the assumption that they have the means to act on their own initiative. It assumes that the language is accessible in some form to the student outside of the classroom.

I am not in favour of forcing students to learn "foreign" languages in high school. This pretty much guarantees that the majority of students will have difficulty finding any relevance for the subject in their lives. There are benefits, to be sure, but those benefits are aimed squarely at only a handful of students who already have an interest in foreign countries, etc. I would vastly prefer helping students with the mechanics of language acquisition and leave it up to them to explore ways in which they use the language (watching foreign TV/films, reading foreign books, talking to people on the internet, listening to foreign music). In fact, in my classes I avoided overt cultural references as much as possible, while encouraging my students to pursue whatever interested them outside of class.

From that perspective, I fully support the idea of teaching programming as a "second language". I actually teach programming using the language acquisition techniques that I learned as a language teacher. Don't worry, it's not the "Memorize a million words of vocabulary and try to fit it into arbitrary grammar rules" style of teaching. I teach programming as an application of language acquisition and it is extremely effective. Computer languages are very small and simple. Programming idioms are also (by and large) few and logical. In my opinion, this is a great first step before tackling a human language. Once you get the language acquisition techniques down (which aren't particularly difficult or numerous), it is easy to apply to a more difficult problem.

On the other hand, I have sympathy for those teachers who truly want to teach foreign languages for the benefits that they bring. I just feel that such classes should not be required for all students.

I know this sounds crazy, but quite a long time ago I realized that I was approaching my retirement planning the wrong way. I was trying to amass money in order to support a lavish lifestyle. This approach has a lot of drawbacks. The biggest of them is that you end up spending the majority of your life chasing after money.

Instead I decided to learn to be happy living on $10K a year. It means I have make hard decisions. I don't have a car and instead ride my bicycle or take public transit. I live in a small apartment in the middle of nowhere. I cook for myself every day. I watch over-the-air TV. I don't have kids. Instead of going to see a movie, for instance, I stay home and make beer. I don't work crazy overtime and instead focus my energies living well every day.

I'm much better off than I used to be. I'm happier, and healthier. I save more money, and since I increasingly have less use for it I have the feeling of being wealthy. The money I save is not to live a lavish lifestyle but rather to support me when my health fails and I can not support myself.

I know it's not for everyone, but less really is more for me.

I used to be an Emacs guy, but I've switched to Vim. Most text editors have functions that can be accessed by keystrokes. You can think of this as vocabulary in a language. Each key press is a word. But Vi also has a grammar. Keystrokes don't just happen individually, they happen in bunches that are kind of like sentences.

In a normal editor you move your cursor and then edit what's under it. But with Vi you can say things like "Modify the 3rd word on this line". It takes time to get used to it, but when you do, it is considerably more efficient. I don't know of any other editor that has this capability. Even the Vi mode in Emacs only really rebinds the keystrokes -- you can't edit in the same fashion that you do in Vi.

No offense, but I think you are suffering from being used to one thing and missing it when you don't have it. I've worked 20 years as a programmer, about half in a Windows environment and half in an embedded/Unix environment. When programming in an embedded or Unix environment we always used the GNU tool chain because it's what all of the programmers preferred.

Anyway, I vastly prefer the available free software tools over any proprietary platform. For example, for source management, nothing beats Git (well, I can understand why some people prefer Mercurial, but that's free software too). I've used Perforce, Clear Case, and (god help me) Source Safe. They slow me down dramatically. For build management, a lot of Windows programmers use the tools built in to Visual Studio, but this makes continuous integration virtually impossible. I want a continuous build running. I want to know if a check in broke the build immediately, not a day later. All of the best continuous build tools are free software (and many of them have Visual Studio plugins in case you just can't wean yourself from it). Are there any TDD frameworks that aren't free software in existance??? I don't know of any. For build tools, if I'm writing C++ or C the Auto tools are dramatically better than anything I've ever seen on Windows (though I admit they are *very* cryptic and require time to learn). For other languages, I just tend to use whatever the language provides -- Ant for Java, Rake for Ruby, whatever. There are some IDE tools, but they only really work in Mickey Mouse situations, not in large software projects.

There are a couple of places where I'll give the nod to some of the proprietary software tools. Personally, I like vi (and even Emacs -- I'm bilingual) along with exuberant ctags. I'm dramatically more productive with that than with any IDE I've tried (and I probably have tried them all). The one place where Visual Studio excels is in refactoring tools. But in the end, not having them doesn't slow me down enough to use VS. If you are used to VS, I can see why you wouldn't want to learn anything else. Editors are really personal. It's a pity that people choose to learn tools that are only available on a single platform, but there you go...

For writing a manual.... Seriously, Word???? That's just nuts. You can't write a decent manual in Word because you just don't have the typesetting features. I suppose if it's not a professional manual (which is why a programmer is writing it)... I wouldn't use Open Office either. If I had to write a manual, it would certainly be LaTeX, which would give me good output and would be much easier to write to boot. You do have to learn, it though. Having said that, there are no particularly good typesetting packages available in free software that a documentation expert would likely want to use. But Word also fits that description.

As for having to use the command line... You *are* a programmer aren't you? Seriously, scripting is your friend. You save soooo much time. I think you are used to doing things one way and even though the new way is dramatically better, you aren't used to it. There's a reason why people used to working on Unix like systems haven't embraced the point and click programming IDE. Command line interfaces and specially built tools that do their task exceptionally well are much, much, better.

It's a pity, because I've met many programmers like you when I worked in Windows-only shops. It doesn't take that much time to show the benefit of the tools available in a free software environment. But if you don't know, then you don't know.

RMS has discussed the issue many times before. My recollection of his stance (you may want to verify it) is that he is in favor of "free culture" ideas. But this is not his focus. He is concentrating simply on software. He feels that the issues in other "free culture" situations are probably quite different and he doesn't have the time to think through them all. So while he's happy with "free culture" other than software, it's not something he champions.

When it comes to games, there is a component that is software and there is a component that is not software. He is concentrating on software. He can see arguments that the non-software components may need to be restricted. However, he would like the software to be free (as in freedom).

I get the impression that he would prefer that games be completely free, but that he hasn't puzzled through all the issues and hasn't decided for himself whether there is some moral imperative to push for it. Thus he accepts non-free games whose software is free.

I believe there are a handful of games on steam that are dual licensed, but I don't use steam so I can't verify it.

I tend to see this move similarly to when Corel made a Linux distribution. Steam is being orders of magnitude smarter about it and so probably won't fail the way Corel did, but it's essentially the same from my point of view. When selling a suite of software, there are certain advantages in being able to control the OS. Corel thought they were essentially going to be able to get a free (as in beer) OS and control the platform from top to bottom the way MS does. This would allow them to sell entire office solutions without having to deal with MS. Having their own OS, even if it was free software, would allow them to lock in their customers.

In a similar way, Steam can build a Steam system that works they way they want it to. It gives them the control to fix or modify things that aren't working for them. However, they are being considerably smarter about it. For example, they aren't trying to control everything from top to bottom. Corel just couldn't get out of their proprietary mind-set and decided they had to create their own distro. Steam is building on the work of others and ceding control in areas where they don't care. They are working with others to meet their goals, dramatically cutting their costs in the process. In some ways, they understand the point of open source better.

Now, they are still trying to sell proprietary software on top of that platform. The argument for open source gaming is a lot weaker because it's difficult point to people who have a successful business model. I'm a free software advocate and I think we have a lot of work to do in this area. But I don't think Steam will actually impede progress. If they are successful in creating a kind of proprietary gaming appliance/platform on top of free software, it will make it easier for free software games to get into the market. Right now free software games are just not commercially successful because we haven't developed the business models. (Don't get me wrong. There are very successful free software games. They just don't make millions of dollars).

This is where I differ from RMS slightly. I really believe his original approach to software freedom advocacy was the best: write code. People like Steam are adopting free software platforms because they exist and the business practices are proven. Companies are starting to understand the point that collaboration in areas that aren't their core business gets them where they want to go faster. We need more code and we especially need more proven business models. Morality may be our motivation, but it can not be our method. Steam entering this sphere gives us somewhere to go.

See this is the tricky part. Free software is a movement dedicated towards customers. It grants more freedoms to customers than they otherwise would have. If you buy (or are given for free) software that is Free as in "freedom", you can do more things than you can with software that is not Free. Though somewhat ironic, more developers care about free software than non-developers. Partially this is because the freedoms that you get as a customer are mostly useful if you are a developer. As many developers are also customers, they understand these freedoms more than non-developers.

The open source world is very similar to the free software world. The main difference is that open source advocates noticed early on that not only did software freedom help customers, but it led to many advantages for the original developer. Many open source advocates sold the idea as being "pragmatic" for developers. It doesn't mean that customers don't also get benefits, but the main selling point was "pragmatism" and value for the original developers.

So we have a situation where users customers can benefit from software freedom, and the original developers can benefit from open development using a consortium-like model with low barriers to entry. Unfortunately, there are some losers. These are the businessmen who insist on adhering to business models that are incompatible with free and open source software. There are others who complain that many free software models do not allow them piggy back on the work of the original authors to produce competing, closed products. Hopefully those losers will start to see the benefits and adjust their approaches.