Microsoft Programmer Mentality

Meaning some of the programmers on platforms that use a Microsoft OS, not employees of Microsoft. In that case, please refactor to PcProgrammerMentality? or ComparativePathologyOfProgrammers, as this page is about people with limited views into the world of programming who are filling the world with naive implementations, not about Microsoft.

These are programmers who begin with simple things on PCs. In the past a quick dBase or Clipper program. Now a simple VB app.

They then progress to more complicated things and become ProfessionalProgrammers. I italicize it because I don't mean they program in a professional way, rather they make their living programming.

Often times these people have much experience which isn't worth much. The reason is that when they are learning new technologies (a new programming language, a new set of APIs, a new operating system) what they do not do is ever ask the question "how do I become a better programmer". (HowToImproveProgrammingSkills)

They are the biggest buyers of IdiotBooks, and steer away from any BooksThatAdvocateProgrammingStyle?.

They are a menace for two reasons:

They don't realize the poor programming techniques they propagate.
While selling themselves as experts (which make convincing management that they are wrong hard), they use bad programming practices.

: Two examples are: if two classes in a hierarchy need a method which has the same code, they will use CopyAndPasteProgramming, rather than refactor the method up the hierarchy. If a problem comes up where one class needs to access a private member of another class, they will advocate adding get/set methods instead of reworking the design.
: Worst they will be strong advocates for using bad programming methods to solve problems in meetings.

I will admit that sometimes the methods they suggest are necessary, but only as a last resort. The problem with these programmers is that they jump on these solutions first, and never see the problems inherent in them.

There's a tendency on wiki to split blame equally when it clearly shouldn't be. Or just be nice in general, which is admirable, and says a lot about the people here. But let's not get carried away - there are topics like this one that are clearly very true in reality, and trying to soften the blow or be equitable where it's unwarranted is intellectually dishonest.

Stereotypes vary from have a little bit of truth to a lot of truth. In my experience this one has a lot.

One of the problems is that they don't generalise at all. Generalisation leads to one of the most powerful tools of programming: abstraction. In fact it has similar etymology to the term generic.

Many of the most powerful additions to programming in recent years have been related to abstraction, so these people miss out on all those wonderful techniques. --ThaddeusOlczyk

One such person told me "I can't wait for all the command-line UI's to die."

This comes from a person who's only ever used the COMMAND.COM prompt. People who are anti-command line usually aren't even aware of the potential benefits of such an interface. (They haven't piped, scripted, run loops, done substitutions with ^^ and so on.) Command lines are effective when you actually want to manipulate symbols and get a lot of automation. (See "Shell Games" and "Ubiquitous Automation" in ThePragmaticProgrammer.) This sort of person often queues up to use a Unix/Linux workstation when they could have just telneted in from somewhere else.

It's also amazing how many people I know were impressed by the long filenames in Windows 95 ;-) (That's another sad Microsoft-only giveaway.)

Long ago, a friend of mine whose experience was all on IBM MainFrame was raving about the wonders of a new feature: you could actually create a file from within a program, and not have to either use JobControlLanguage or special IBM utilities! I decided not to rain on his parade by telling him how CP/M had the same facility. -- Robert Field

Having said all that about Microsoft only people, probably the most harmful "prior experience" that one person I know had was JCL. This person latched on to the goto command in PascalLanguage within 5 minutes of his first prac session and used it everywhere (!)

It's a shame that most people aren't taught the sort of skills described in ThePragmaticProgrammer. It's as though people are taught the syntax and told to get on with it.

Before anyone else brings it up, see AntiMicrosoftBiasOnWiki -- some guy

Perhaps I should have called it PcProgrammerMentality?. The reason they come from this area is that there is a low barrier to starting here.

Others (such as the mainframe examples) are generally forced into it (usually by one of two methods: "I need to eat, I'll get a job as a programmer" or "We desperately need someone in this office to program. Bang, you're it!").

It is also easy for these people to develop a narrow vision of computing because it is easy for someone new to computers to fall into the MicrosoftInventedComputingFallacy?. The shame is that many never transcend it. -- ThaddeusOlczyk

In every profession and trade, there are people who don't care about beauty, and don't see the link between elegance and practicality. Computer programming is no different, and this phenomenon has existed in computer programming since way before Microsoft was on the map. Check out SturgeonsLaw. So this is the way it is and we've recognized that. Now what? You can either work with these people or find some way not to. Or do you think that you'll change them?

A lot of the messes I've seen stem from ignorance rather than stupidity or carelessness. IMHO the pattern literature goes some way towards remedying this. -- some guy

There's a lot to be said for the skill of grabbing 3rd party controls/tools/code, slapping it all together quickly, and shipping business functionality out the door quickly. Because, after all, our objective as developers should be to deliver (appropriate) functionality to the users quickly and at low cost.

The failure of these PC hackers, as I see it, is in their failure to recognize the risks and limitations of their approach: Complex programs tend to be unmaintainable, and reliability can be a real problem.

I respect the volume of productive work they can do when working in the right domain, but fear the amount of damage they can do when applying their approach in inappropriate situations. -- JeffGrigg

I observe that such people tend to think that programming is about tools, rather than that ProgrammingIsInTheMind. It does not seem to occur to them that they need to work on the quality of their thinking, hence the avoidance of literature that addresses style, etc. -- RobWilliams

I observe that programmers, even those who say ProgrammingIsInTheMind, must resort at some time to the realities of transferring their programming skills via tools into realized and functioning code, and then rely on the tools of Editors, IDE's, Debuggers, Compilers and/or Interpreters to make their programs functional.

Is there any use of this page other than starting a flame? It seems this page is made due to a single person's personal experience and not due to facts. It seems to suggest to me that people who made tools like RationalRose and countless other applications come under this category.

I agree. There is nothing specific here that could not apply to any newbie or evil-doer with any tool. There are stupid mainframe programmers, stupid UNIX programmers, and stupid VB programmers. Stupidity is all over. I would note that in larger programming groups there is perhaps more feedback against problem designs, and thus more correction. This may imply that learning on teams is better than learning alone. Further, there is often no incentive for good designs. Making a mess that only you understand is job security. Aside from having Style Police on patrol, there is often no easy fix.

(I disagree. This page has a lot of great discussion, and I would deem it a great shame if it was deleted or refactored away for PoliticalCorrectness.)

It would be inaccurate to split the blame equally. There certainly is a bigger contingent of VB idiots running around than say, RubyLanguage idiots. Obviously Microsoft software is more familiar to these people from day one.

I don't know about that. A mad Ruby fan may use complicated GOF patterns or reverse multi-closure neural net recursion and the like just to use them, not because they improve the result. IOW, MentalMasturbation.

I think there is meat here for refactoring. There are various kinds of bad programmer who are restricted by their initial experience. Bad programmers who started with PC-level drag'n'drop application building tools are different from bad programmers who started with 8-bit home computers, and also from bad programmers whose minds were crippled by COBOL. There is room for a comparative pathology without denying that those who broaden their experience and keep learning can become good programmers. -- AndrewMcGuinness

ComparativePathologyOfProgrammers - genius!

More often than not the programming and computing practices are a product of the organization in which the programming and computing occurs. Organizations which employ inefficient and impractical approaches also employ inefficient and impractical programmers. Organizations in a hurry to improve the bottom line often are found with people and projects with a rush to ship mentality. Such is not the case in a LearningOrganization.

This is pure elitism. Everyone starts somewhere, then improves. (Except for the ones who don't improve.) And if you examine the arc of a programmer whose sole purpose is to satisfy some real-world demand -- not theorize about the joys of software, or purity, or extreme salad or whatever, but to Get Something Done -- then the arc of that (class of) programmer says as much about the tools and languages available to that programmer, as of the programmer herself. For example, if this hypothetical goal-oriented programmer writes bad code -- let's say she uses the Forbidden But Available GOTO -- who is to blame? Her? Or the tools that still expose the evil?

As a much more common example, consider all of the absolutely HORRID code written in C/C++, where the horribleness is confined largely to memory management. People who are trying to get some real job done -- not preen themselves on the purity or elegance of code, but actually achieve something that is useful to someone else -- these programmers tend to just wale away at malloc/free until the code mostly behaves. This kind of mentality -- coupled with the weak, defective environment! -- creates applications that are notoriously unreliable, unmanageable, and just impossible to work with, past a certain complexity.

So who is to blame? I blame the tools, languages, and environments. And I also blame the managers that continue to mandate that C/C++ be the language of choice -- who begin with a decision that should be a conclusion reached after examining the problem at hand, and the available tools/languages. C/C++ MUST DIE, at least for common commercial development. Unmanaged memory access must be relegated to those programmers who truly its understand the implications and responsibilities. And the elitism that often accompanies that same community of programmers MUST BE ELIMINATED. We should not be surprised when newly-minted programmers shoot their feet off, when we give them such dangerously defective tools.

-- ArlieDavis

How curious: You blame everyone but the programmers who failed to design a workable memory management strategy and wrote the buggy code. C++ is a power tool; it exists for a reason. It's possible to DesignByContract and write code in such a way that memory management bugs manifest as compile errors, making leaks syntactically impossible. The BestPractices I've seen for this are Nitrogen's Owned and Shared templates, which are like std::auto_ptr and boost::shared_ptr respectively, but operate on any resource with ownership semantics (not just pointers) and are slightly more sound. This requires writing and using wrapper functions, e.g. an object source that returns an Owned<Foo> instead of a Foo, but this discipline pays off in performance. Using ownership transfer semantics (i.e. auto_ptr, Owned) is much more efficient than shared resource semantics, which is a waste if you never have more than one claim on the object at a time. Garbage collection is even more expensive, and therefore even more of a waste if you don't need it -- if you don't have cyclical structures, then reference counting suffices.

Maybe you're not aware of what's possible in C++ because you're confusing it with C. There is no such language as CeeCeePlusPlus.

By the way, I find it hard to take you seriously when you keep throwing around fanatical comments, pitching what amounts to a FinalSolution?. Please, leave "MUST" to the standards documents.

-- JoshuaJuran

I blame kids and mortgages. It is these two things that (typically) take people's time away from learning new stuff outside of work, and sap financial resources which could otherwise be built up so one has the courage not to buckle to management when management demands would seriously harm the ConceptualIntegrity of the software.

That's not to make value judgements about kids and mortgages. Just that if you want to know why a lot of this crap happens, you can often trace it to these two things.

The solution to better software is then to hand out condoms at MS trade shows.

This is not eliteism. Eliteism would be talking trash about new developers. This is talking trash about developers who believe the be all and end all of programming is about which languages they know, and how many acronyms they can put on their resume, instead of learning about design patterns, refactoring, etc.

I have also noticed that the MicrosoftProgrammerMentality generally favours the off-the-shelf component method of fixing a problem, rather than a tutorial or OpenSource based solution. For example, (quite) a few years ago I needed to deal with file uploads under ASP with IIS. I could find reams of Java Servlet Code that did it, but the only solutions available for IIS were 3rd party components costing money. The experience is equally true today. -- JonathanArkell

I have seen a lot of damage caused by avowedly anti-Microsoft people. Anyone who comes out with statements like the one at the top of MicrosoftProgrammerMentality is not someone I want to work alongside. I say this as someone who works in Linux, Solaris and various flavours of Win32. I would rather deal with someone who realises their limitations, than someone who feels they are an untouchable guru and entitled to sneer at others instead of helping them. I realise there are a lot of awful programmers out there, but conflating that with the concept of Microsoft tool users is to confuse cause and effect.

I tend to think that this mentality is not uniquely associated to Microsoft. There are also bad Java programmers. Today's VB programmers replace yesterday's Cobol programmers, which arguably is a far worse language than VB. The thing is, Cobol and VB have been created with non-programmers in mind. These people are not supposed to have any knowledge of computer science. However, when large projects in banks are written by non-programmers, non-programmers get leading positions perpetuating bad programming practice and asking for badly designed functionalities.

However, in the process, there are some unwanted casualties, namely high-level, FunctionalProgrammingLanguages. Although they are extensively used by the best programmers, they are too conceptual for VB programmers, and they are unfortunately assimilated to VB-like languages by seasoned C/C++ programmers.

I'll second the notion that the problem is not unique to Microsoft nor VB programmers. I have seen some pretty ugly Unix Shell Scripts that go on for pages as well as embedded C routines that were borderline impossible to read or modify. Part of the problem is that until recently, software programming (as a technology) has not been mature enough to actually discuss programming style. I feel, despite all of the various language specific coding standard books, the first to actual discuss this was MartinFowler in RefactoringImprovingTheDesignOfExistingCode.

I second that the problem is spouses and kids. I refactor to "spouses" instead of "mortgages", in order to cut through the PoliticallyCorrect BS and be honest about why we have those mortgages. Trying not to be sexist, but I think there is a legitimate gender difference here. Not too many guys are all gung-ho about going deep into debt and slaving away like a sherpa at a job you hate, just to have a beautiful "dream home" that you never spend any time in unless you're fixing stuff on it. I find that urge more common on the X chromosome: even amongst women who out there slaving away at jobs they hate too (in areas like SF where two or even three incomes are a requirement for homeowners), or even carrying most of the burden themselves in paying for it. Same with kids, unfortunately. I love my kids, but it was my wife's decision (er, ultimatum!) to have them, not something I chose to do. Single people have more flexibility and control over their lives and careers, and there's no PC way around that. The sure-fire way to avoid work-related stress is to stay single and don't breed. Then you can quit whenever you want, speak up at meetings, engage in work actions, organise unions, go freelance, start your own business, whatever puts you back in control. Otherwise, the best you can hope for is to manage stress, never to eliminate it.

I think that it is worth clarifying that the use of "Microsoft" programmer mentality appears to be a reference to a programming paradigm (see JavaAndDotNetPhilosophies) named after Microsoft because they are the best known illustration/propagation of it.