Dunning-Kruger, no matter that it doesn't predict the competence of a person based on their confidence, has significant consequences. For example, take a large group of people. Note that their competence in some field is a random variable with probably a gamma distribution. In other words, most people are around average competence and as you move into higher competence, there are considerably less people. Now allow those people to self organize and choose leaders. To make things simple, lets split everything up into groups of 10 people. 10% are leaders. They are chosen for their self confidence and outgoing nature.
Interestingly, this will favour the less competent people, because they will be more confident. In fact, because most people are grouped around the middle, it will be difficult for them to distinguish competent from incompetent. This could make the incompetent candidates very much more successful. Now consider a second round. We are going to take 10% of the leaders and make them super leaders. They will be chosen by their peers based on their self confidence and outgoing nature. But now most of the people making the decisions are of lower competence. This will favour the incompetent even more.
This is the beginning of a "talent inversion". Incompetent, but confident people rise to the top while competent, but cautious people stay at the bottom. Now imagine the politics that will evolve from this very simple starting point. Every time an incompetent senior person asks for the impossible, an incompetent junior person confidently strides up and promises results. Because they are both incompetent, they can happily fail, but convince themselves that they have actually succeeded. If you have ever worked in a big company, then you probably don't have to imagine.
In other words, because of Dunning-Kruger life is unlikely to be a meritocracy. There are clear advantages to being competent, but one should not overlook the network effect of a group of confident, but incompetent people. Understanding that *you must deal with these people to ensure success* is key. In my career, I have found that borrowing some confidence from an "incompetent" co-worker, while lending some of my "competence" has been very successful. In fact, it is so useful to me that I have redefined my definition of competence. In truth, I was never very successful until I learned to look at things from other perspectives. No matter how right you are, if you can't act on it, it doesn't make much difference. And even if you are very wrong, acting often wins the day.
It's a bitter pill to swallow for someone whose ego is bound up in their competence. But life is not fair.
Re:Sort of spammy, also not convincing
on
Tetris Is Hard To Test
·
· Score: 3, Insightful
Code coverage tools will not tell you if your tests are sufficient. They simply tell you what lines of code were hit. They don't tell you whether or not the line of code was hit while doing a meaningful test. In fact, it is trivially easy to write "tests" that exercise 100% of the code but have no expectations at all.
What code coverage tools tell you is what code you definitely haven't tested. If you haven't run that line of code in your tests, you definitely haven't tested it. This is useful information, but not essential if you have a good team. My current team is quite comfortable writing tests. We do most things TDD and without trying hard our average code coverage is 96%. I occasionally wander through the other 4% to see if it is worth testing and most of the time it isn't. Occasionally I will find the odd piece of logic that was jammed in hurriedly without tests, but on our team it is quite rare. On the other hand, I have worked on teams that were not comfortable writing tests and mostly wrote them after writing production code. On those teams we would get about 75% test coverage with holes you could drive a bus through. A code coverage tool was very useful for educating people on the need to improve the way they wrote tests.
I feel very confident I could TDD my way through a tetris implementation and get 100% code coverage without undue effort. I don't think I would find all of the corner cases without help, though. A code coverage tool wouldn't help me in that instance.
There is a big difference between teachers and programmers. I know because I've done both jobs. Teaching is the more difficult one to do well. Good programming requires rare skills and an ability to concentrate more than most people can imagine. Good teaching does not need any unusual technical skill. The material you are teaching is really quite easy compared to what programmers have to contend with. The tricky bit is turning around lives that have been destroyed by circumstance and incompetent parents. Excellent programming requires a top notch mind and a devotion to learning. Excellent teaching requires a damn near miracle of people skills and good judgement.
Here's the kicker. If you staff your programming team with poor performers, chances are (sooner or later) your business will die because of them. The complexity that bad programmers add to a problem when they are coding eventually becomes so heavy that you just can't move forward. If you staff your school with poor performers, the students still graduate. The schools still operate. In fact, you can cut the budget of a school just about as far as you want, driving out any teacher that cares about money. The students still graduate. The school suffers in that it becomes a center for incarcerating delinquents, but the students still graduate. You just keep lowering the standards and society pays the hidden price.
A gifted programmer can name his price. A gifted teacher? Gets lost in the shuffle. His only reward is what he makes of it.
When I was living in Japan, a friend asked me to send him a copy of Inu Yasha volume 1 so he could give it to his daughter. She wanted to use it to help study the Japanese language. It was her favorite anime and she wanted to read the manga. I was about to send it to him and noticed that there is a scene with Kagome (the heroine) bathing naked. She's meant to be 14. Not wanting to get my friend involved in importing child porn, I ended up not sending it. It is a shame that a 14 year old girl can't read her favorite manga because there is a picture of a naked 14 year old girl in it. Laws are laws, though...
Not sure how many employees Cisco has left (didn't RTFA), but a quick glance at Wikipedia indicates that they still probably have more than 50K employees. Of course not all of them are engineers, but I have worked in organizations of that size before. If my experience is common (and I believe it is), they have already gone well pas the point you indicate. Even if they only have 5,000 engineers, it is practically impossible to hire anywhere near that many good people. You are stuffed to the rafters with dead wood. Not only that, but quite a lot of that dead wood will have made it up to management level -- the engineering and political skill sets are orthogonal, and people who are good at politics get promoted.
This means that the management probably has absolutely no idea how to separate the good engineers from the bad. In other words, just by growing the company to the size that they have, they are in a position where they can't evaluate talent. A 30-50% turnover rate is another way of saying 2-3 year attrition rate. I agree with the manager. This is common in large companies. Because they are unable to distinguish good from bad, they simply cycle through the available talent in a random fashion. They have chosen to go with quantity over quality and his statement makes absolute sense.
I don't think it is possible to do (for a variety of political reasons), but lets pretend that a company of 5000 engineers could cut back to their top 10% of talant. You'd end up with a solid core of 500 good engineers. Then, let's pretend that you knew how to do whatever it took to keep that talent for 10 year. Would the company be better off? I'm not so sure. I work in a former start up that is trying to scale itself up now. Since I'm fairly senior (possibly indicating I'm better at politics than engineering???;-) ) I'm exposed to more of the business end of the company. The CEO is demanding that we double our development group. He knows that this will throw the group into chaos, but he also sees a way to grow the revenue of the company by an order of magnitude if we can do some very specific work. Crucially, it doesn't really matter how badly we do it. It just needs to mostly work.
Which is better? Grow your revenue by an order of magnitude today and destroy your development team, or carefully grow your development team and trust that opportunities will show up when the team is able to handle them? It's a very difficult call. Personally, I can't fault companies who expand quickly (like Cisco did) and who take the opportunities that were presented. That's what the business guys are paid to do.
Luckily, the company I work for is wholly owned by the CEO and he has decided (for now anyway) to adopt a more sustainable growth for the company. Again, I am very lucky that our CEO views our team as being the engine of the company and values long term viability. He doesn't have investors trying to take their money out and has the ability to make the choice that leads to a very good place for me to work. Not every company has that luxury.
I use Arch for my day to day programming machine. I would not use it for an outward facing server mainly because it does work as well as some other distros for nailing yourself down to a known, stable set of versions. For a dev platform, though, it is fantastic. I've got bleeding edge everything (in fact, it is hard to stop it from being bleeding edge) and it is highly configurable.
The best thing about Arch is that most of the configuration for packages is not done by default. You have to do it yourself. While this is indeed a pain in the neck most of the time, it is awesome for keeping bloat away from your machine. The netbook I'm using to type this post on, does not have NetworkManager, Avahi, Pulse Audio, etc, etc, bt *does* have Gnome Shell on it. Try doing that on an Ubuntu machine... I use this box for hacking around on the train and for practicing programming, and despite being many years old it's absolutely fine. My main dev is also running Arch, manly because I get rolling updates and bleeding edge updates. Occasionally I have problems with stability, but nothing I can't deal with fairly quickly. It is much, much better than having the big bang upgrade every X months.
At work the other day someone said to me, "I've heard a lot of devices are running Linux, but they don't do the stuff that I want. For example, I don't want Android. I want something like my Linux desktop, but I don't know what to call that".
It was the first time that I could say to a normal user, "What you want is called GNU". I will know I've lived too long when normal people start asking for software freedom, unprompted. But the world is changing. What used to be flame war material for programmer geeks on obscure mailing lists is now starting to be relevant to the average person. Already I have people telling me how they just heard how stupid software patents are and how I have to get behind the movement to stop it. Most of the 20 or so programmers on my team have never programmed using proprietary software libraries ("What do you mean you don't get the source code? How would you be able to use it?")
I think what you say is probably true for the moment. I wonder if it will be true forever.
OMG! A rant about Emacs vs VI with a sub-rant about indenting with spaces vs tabs!!! And you even throw in a story about locking someone out of CVS (although in my day we used RCS and we were damn happy to have it).
The cool thing about Gnome shell (for a programmer) is it's customizability through Javascript. I was perusing the documentation for the Mutter bindings and the things you should be able to do is incredible. I don't know... maybe things don't work (I've never actually tried it), but I wonder if programmers are overlooking just how powerful Gnome shell extensions can be. Do you *really* want to set options through endless dialog boxes and wizards????
I have to admit that I use Awesome most of the time these days, but I would love to get a very minimal Gnome shell (with none of its assumed dependencies that bloat everything to hell) and hack out my perfect workflow.
The first 2 have been banned on my machine for quite a while (many years). The third I picked up because Gnome forced it upon me. I have now abandoned Gnome.
The other system that is off my machine for good is Network Manager. If I could find a replacement for Bluez I might even be able to have a stable machine...
From my experience, normal JR rail is almost as punctual. They have special gear that goes out and checks the rails after every earthquake. Typhoons usually don't even make the trains late. I got used to that service when I was in Japan. In 5 years I can only remember the train being late twice (both due to suicides on the track). I spent the last 2 years in England. They don't even count the train as late if it is less than 10 minutes late. Even with that, the train near me is late nearly 20% of the time (some times in the year it is late over 25% of the time). I'm glad I have a forgiving boss. I come in 30-60 minutes late at least twice a month due to the trains:-P
Not all places are like that. A friend of mine put if very nicely the other day. He said he spent a long time wondering if IT was for him. It seemed really destructive to his life. He came to the conclusion that IT was great. His specific job was not. He started to look for the job he wanted.
Another wise person once said, "Not everybody needs to be a programmer". You could be a waiter, for instance (not me -- that job is waaay too hard). After 20 years, I took "a year off" to teach English in Japan. I was working 35-40 hours a day. It seemed like part time. I enjoyed my life, got married and even wrote open source software. It was Idyllic. After 5 years of my "year off" (long after I thought I would never return to IT), I suddenly came back. I'm in a great team, working 40 hours a week and having a blast. We're a bit of a crazy team and are extreme, even for extreme programmers. I don't have a huge amount of time at work to write open source software, but I don't work stupid hours and my boss recognizes the value of giving me time to work on my own projects.
Sometimes it is easy to get trapped in the box thinking that there is only one way forward. Programmers are problem solvers. I don't know exactly what the solution to your problem is, but I feel certain that you can find it if you are creative enough. Don't give up!
I have had similar experiences with pre-hypertension and having no real success lowering my blood pressure -- except with the DASH diet. Like you, after a fairly short time with DASH, my blood pressure became normal. However, if you read the studies behind DASH (rather than the pamphlet on the website) you will find that the diet is geared around the hypothesis that increasing potassium and magnesium is the mechanism for lowering blood pressure. The sodium reduction is just kind of stapled on. The original paper shows that the DASH diet tended to reduce blood pressure at all sodium levels (although it appeared to reduce it more with lower sodium intake). Unfortunately, I couldn't tell from the paper what sample sizes they were using and I have grown cautious about the statistical abilities of nutritional researchers. The published DASH pamphlet is also faulty (IMHO) as it does not follow the diet used in the studies. It has a *much* higher calcium intake. I suspect (but have no evidence to support my feeling) that the published pamphlet has been prepared with "input" from various special interest groups.
There a some other papers available on the internet as well. I would read these and ignore the various other websites/books with information about DASH.
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.
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.
Slashdot Mirror
Dunning-Kruger, no matter that it doesn't predict the competence of a person based on their confidence, has significant consequences. For example, take a large group of people. Note that their competence in some field is a random variable with probably a gamma distribution. In other words, most people are around average competence and as you move into higher competence, there are considerably less people. Now allow those people to self organize and choose leaders. To make things simple, lets split everything up into groups of 10 people. 10% are leaders. They are chosen for their self confidence and outgoing nature.
Interestingly, this will favour the less competent people, because they will be more confident. In fact, because most people are grouped around the middle, it will be difficult for them to distinguish competent from incompetent. This could make the incompetent candidates very much more successful. Now consider a second round. We are going to take 10% of the leaders and make them super leaders. They will be chosen by their peers based on their self confidence and outgoing nature. But now most of the people making the decisions are of lower competence. This will favour the incompetent even more.
This is the beginning of a "talent inversion". Incompetent, but confident people rise to the top while competent, but cautious people stay at the bottom. Now imagine the politics that will evolve from this very simple starting point. Every time an incompetent senior person asks for the impossible, an incompetent junior person confidently strides up and promises results. Because they are both incompetent, they can happily fail, but convince themselves that they have actually succeeded. If you have ever worked in a big company, then you probably don't have to imagine.
In other words, because of Dunning-Kruger life is unlikely to be a meritocracy. There are clear advantages to being competent, but one should not overlook the network effect of a group of confident, but incompetent people. Understanding that *you must deal with these people to ensure success* is key. In my career, I have found that borrowing some confidence from an "incompetent" co-worker, while lending some of my "competence" has been very successful. In fact, it is so useful to me that I have redefined my definition of competence. In truth, I was never very successful until I learned to look at things from other perspectives. No matter how right you are, if you can't act on it, it doesn't make much difference. And even if you are very wrong, acting often wins the day.
It's a bitter pill to swallow for someone whose ego is bound up in their competence. But life is not fair.
Code coverage tools will not tell you if your tests are sufficient. They simply tell you what lines of code were hit. They don't tell you whether or not the line of code was hit while doing a meaningful test. In fact, it is trivially easy to write "tests" that exercise 100% of the code but have no expectations at all.
What code coverage tools tell you is what code you definitely haven't tested. If you haven't run that line of code in your tests, you definitely haven't tested it. This is useful information, but not essential if you have a good team. My current team is quite comfortable writing tests. We do most things TDD and without trying hard our average code coverage is 96%. I occasionally wander through the other 4% to see if it is worth testing and most of the time it isn't. Occasionally I will find the odd piece of logic that was jammed in hurriedly without tests, but on our team it is quite rare. On the other hand, I have worked on teams that were not comfortable writing tests and mostly wrote them after writing production code. On those teams we would get about 75% test coverage with holes you could drive a bus through. A code coverage tool was very useful for educating people on the need to improve the way they wrote tests.
I feel very confident I could TDD my way through a tetris implementation and get 100% code coverage without undue effort. I don't think I would find all of the corner cases without help, though. A code coverage tool wouldn't help me in that instance.
There is a big difference between teachers and programmers. I know because I've done both jobs. Teaching is the more difficult one to do well. Good programming requires rare skills and an ability to concentrate more than most people can imagine. Good teaching does not need any unusual technical skill. The material you are teaching is really quite easy compared to what programmers have to contend with. The tricky bit is turning around lives that have been destroyed by circumstance and incompetent parents. Excellent programming requires a top notch mind and a devotion to learning. Excellent teaching requires a damn near miracle of people skills and good judgement.
Here's the kicker. If you staff your programming team with poor performers, chances are (sooner or later) your business will die because of them. The complexity that bad programmers add to a problem when they are coding eventually becomes so heavy that you just can't move forward. If you staff your school with poor performers, the students still graduate. The schools still operate. In fact, you can cut the budget of a school just about as far as you want, driving out any teacher that cares about money. The students still graduate. The school suffers in that it becomes a center for incarcerating delinquents, but the students still graduate. You just keep lowering the standards and society pays the hidden price.
A gifted programmer can name his price. A gifted teacher? Gets lost in the shuffle. His only reward is what he makes of it.
When I was living in Japan, a friend asked me to send him a copy of Inu Yasha volume 1 so he could give it to his daughter. She wanted to use it to help study the Japanese language. It was her favorite anime and she wanted to read the manga. I was about to send it to him and noticed that there is a scene with Kagome (the heroine) bathing naked. She's meant to be 14. Not wanting to get my friend involved in importing child porn, I ended up not sending it. It is a shame that a 14 year old girl can't read her favorite manga because there is a picture of a naked 14 year old girl in it. Laws are laws, though...
Not sure how many employees Cisco has left (didn't RTFA), but a quick glance at Wikipedia indicates that they still probably have more than 50K employees. Of course not all of them are engineers, but I have worked in organizations of that size before. If my experience is common (and I believe it is), they have already gone well pas the point you indicate. Even if they only have 5,000 engineers, it is practically impossible to hire anywhere near that many good people. You are stuffed to the rafters with dead wood. Not only that, but quite a lot of that dead wood will have made it up to management level -- the engineering and political skill sets are orthogonal, and people who are good at politics get promoted.
This means that the management probably has absolutely no idea how to separate the good engineers from the bad. In other words, just by growing the company to the size that they have, they are in a position where they can't evaluate talent. A 30-50% turnover rate is another way of saying 2-3 year attrition rate. I agree with the manager. This is common in large companies. Because they are unable to distinguish good from bad, they simply cycle through the available talent in a random fashion. They have chosen to go with quantity over quality and his statement makes absolute sense.
I don't think it is possible to do (for a variety of political reasons), but lets pretend that a company of 5000 engineers could cut back to their top 10% of talant. You'd end up with a solid core of 500 good engineers. Then, let's pretend that you knew how to do whatever it took to keep that talent for 10 year. Would the company be better off? I'm not so sure. I work in a former start up that is trying to scale itself up now. Since I'm fairly senior (possibly indicating I'm better at politics than engineering??? ;-) ) I'm exposed to more of the business end of the company. The CEO is demanding that we double our development group. He knows that this will throw the group into chaos, but he also sees a way to grow the revenue of the company by an order of magnitude if we can do some very specific work. Crucially, it doesn't really matter how badly we do it. It just needs to mostly work.
Which is better? Grow your revenue by an order of magnitude today and destroy your development team, or carefully grow your development team and trust that opportunities will show up when the team is able to handle them? It's a very difficult call. Personally, I can't fault companies who expand quickly (like Cisco did) and who take the opportunities that were presented. That's what the business guys are paid to do.
Luckily, the company I work for is wholly owned by the CEO and he has decided (for now anyway) to adopt a more sustainable growth for the company. Again, I am very lucky that our CEO views our team as being the engine of the company and values long term viability. He doesn't have investors trying to take their money out and has the ability to make the choice that leads to a very good place for me to work. Not every company has that luxury.
I use Arch for my day to day programming machine. I would not use it for an outward facing server mainly because it does work as well as some other distros for nailing yourself down to a known, stable set of versions. For a dev platform, though, it is fantastic. I've got bleeding edge everything (in fact, it is hard to stop it from being bleeding edge) and it is highly configurable.
The best thing about Arch is that most of the configuration for packages is not done by default. You have to do it yourself. While this is indeed a pain in the neck most of the time, it is awesome for keeping bloat away from your machine. The netbook I'm using to type this post on, does not have NetworkManager, Avahi, Pulse Audio, etc, etc, bt *does* have Gnome Shell on it. Try doing that on an Ubuntu machine... I use this box for hacking around on the train and for practicing programming, and despite being many years old it's absolutely fine. My main dev is also running Arch, manly because I get rolling updates and bleeding edge updates. Occasionally I have problems with stability, but nothing I can't deal with fairly quickly. It is much, much better than having the big bang upgrade every X months.
At work the other day someone said to me, "I've heard a lot of devices are running Linux, but they don't do the stuff that I want. For example, I don't want Android. I want something like my Linux desktop, but I don't know what to call that".
It was the first time that I could say to a normal user, "What you want is called GNU". I will know I've lived too long when normal people start asking for software freedom, unprompted. But the world is changing. What used to be flame war material for programmer geeks on obscure mailing lists is now starting to be relevant to the average person. Already I have people telling me how they just heard how stupid software patents are and how I have to get behind the movement to stop it. Most of the 20 or so programmers on my team have never programmed using proprietary software libraries ("What do you mean you don't get the source code? How would you be able to use it?")
I think what you say is probably true for the moment. I wonder if it will be true forever.
OMG! A rant about Emacs vs VI with a sub-rant about indenting with spaces vs tabs!!! And you even throw in a story about locking someone out of CVS (although in my day we used RCS and we were damn happy to have it).
You know how to make an old man feel young again.
The cool thing about Gnome shell (for a programmer) is it's customizability through Javascript. I was perusing the documentation for the Mutter bindings and the things you should be able to do is incredible. I don't know... maybe things don't work (I've never actually tried it), but I wonder if programmers are overlooking just how powerful Gnome shell extensions can be. Do you *really* want to set options through endless dialog boxes and wizards????
I have to admit that I use Awesome most of the time these days, but I would love to get a very minimal Gnome shell (with none of its assumed dependencies that bloat everything to hell) and hack out my perfect workflow.
The first 2 have been banned on my machine for quite a while (many years). The third I picked up because Gnome forced it upon me. I have now abandoned Gnome.
The other system that is off my machine for good is Network Manager. If I could find a replacement for Bluez I might even be able to have a stable machine...
From my experience, normal JR rail is almost as punctual. They have special gear that goes out and checks the rails after every earthquake. Typhoons usually don't even make the trains late. I got used to that service when I was in Japan. In 5 years I can only remember the train being late twice (both due to suicides on the track). I spent the last 2 years in England. They don't even count the train as late if it is less than 10 minutes late. Even with that, the train near me is late nearly 20% of the time (some times in the year it is late over 25% of the time). I'm glad I have a forgiving boss. I come in 30-60 minutes late at least twice a month due to the trains :-P
Not all places are like that. A friend of mine put if very nicely the other day. He said he spent a long time wondering if IT was for him. It seemed really destructive to his life. He came to the conclusion that IT was great. His specific job was not. He started to look for the job he wanted.
Another wise person once said, "Not everybody needs to be a programmer". You could be a waiter, for instance (not me -- that job is waaay too hard). After 20 years, I took "a year off" to teach English in Japan. I was working 35-40 hours a day. It seemed like part time. I enjoyed my life, got married and even wrote open source software. It was Idyllic. After 5 years of my "year off" (long after I thought I would never return to IT), I suddenly came back. I'm in a great team, working 40 hours a week and having a blast. We're a bit of a crazy team and are extreme, even for extreme programmers. I don't have a huge amount of time at work to write open source software, but I don't work stupid hours and my boss recognizes the value of giving me time to work on my own projects.
Sometimes it is easy to get trapped in the box thinking that there is only one way forward. Programmers are problem solvers. I don't know exactly what the solution to your problem is, but I feel certain that you can find it if you are creative enough. Don't give up!
I have had similar experiences with pre-hypertension and having no real success lowering my blood pressure -- except with the DASH diet. Like you, after a fairly short time with DASH, my blood pressure became normal. However, if you read the studies behind DASH (rather than the pamphlet on the website) you will find that the diet is geared around the hypothesis that increasing potassium and magnesium is the mechanism for lowering blood pressure. The sodium reduction is just kind of stapled on. The original paper shows that the DASH diet tended to reduce blood pressure at all sodium levels (although it appeared to reduce it more with lower sodium intake). Unfortunately, I couldn't tell from the paper what sample sizes they were using and I have grown cautious about the statistical abilities of nutritional researchers. The published DASH pamphlet is also faulty (IMHO) as it does not follow the diet used in the studies. It has a *much* higher calcium intake. I suspect (but have no evidence to support my feeling) that the published pamphlet has been prepared with "input" from various special interest groups.
The original DASH paper is available here: http://www.nejm.org/doi/full/1...
There a some other papers available on the internet as well. I would read these and ignore the various other websites/books with information about DASH.
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.
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.