We seldom ask someone the reason why one chose some profession, unless that profession is unusual. Thirty years ago, choosing to be a programmer did raise those questions, but not much anymore.
Still, what drives people to become programmers has a great impact on their work, and do tend to nicely fit in a few stereotypes I've noticed over the years. Now, people aren't just collections of stereotypes, so my attempt to list them here is an attempt at drawing comedic caricatures that should leave nobody unscathed, including myself.
Let's start with the cliché. The hacker program only to help them break rules. Anything that may be perceived as authority will be seen as a target. The fervour of the cyberpunks are not necessarily done out of ideology: quite on the contrary, they tend to be "digital anarchists".
Sure, over time "hacker" meant any programmer that like tinkering with software and electronics, just to learn and have fun, but these "Wozniak"-style programmers are just normal programmers. No, the cyberpunk would not even care about programming if it didn't attack an authority.
Thankfully, that anger is typical of teenagers, and cyberpunks tend to migrate to becoming "normals" during their adult life, or "selling out" in their terms. Still, teen angst at least introduced a lot of teens to computer science, so it's not a wasted thing.
Some people become programmers because it pays well with reasonable effort, and nothing more. These are the ones counting the number of days before their retirement. They don't like programming, but they can endure it.
During the "boom" phase of the cyclical "boom and bust" of hype around software technologies, the tales of big paycheques and lavish workplace perks attract anyone dreaming of a comfortable life. Parents oriented their kids ambitions towards medicine or law, now towards programming. When a student decide to become a "9 to 5" programmer during the "boom" phase, often it is done without any consideration to talent; It wasn't unusual in the late 90s to see students that do poorly at mathematics seriously considering programming as a full-time profession. Effectively, interest in programming is so broad that the competence landscape of these new programmers tend to be similar to the proportion of talented programmers in the general population, meaning a fraction of a percent.
Not all "9 to 5" programmers started as that. Some became "9 to 5" programmers as a result of disillusionment, and caring about the "important things in life". These are good programmers, but don't care much to be excellent ones.
The net effect is that "9 to 5" programmers, regardless how they became one, do not care much about the quality of their work, inasmuch as it doesn't impact their employment. They would creep into comfortable corners of large corporations, where their mistakes are shielded and hidden by layers upon layers of bureaucracy and quality control without accountability. Still, as long as they fit within those protective bureaucratic layers, they may be sufficiently useful if they have a modicum of competence.
The most dangerous form of "9 to 5" programmers are ones that, due to delusions of grandeur, the lust of a greater paycheque or a nagging spouse, have the ambition to raise in the ranks of the company, creating the "Dilbert Principle". While some argue that ineffective programmers are better suited in management roles, their authority may negatively impact the quality of the product far more than an individual programmer, and with even less accountability due to their embellished image.
On a positive note, the "9 to 5" tend to have the best "real life" outside of work, maybe to counterbalance their dreary work environments, something that is also distinctive of other bureaucratic professions. This mentality does shield them from the sheer amount of absurdities that would drive anybody else insane.
For the "problem solvers", software is just a means to another end. What is valuable isn't the software, but that other thing. For computer scientists, that "other thing" is the theorem or the algorithm they wish to prove. For other scientists, it's the result of the data computation. For computer engineers, it's the hardware components. For game designers, it's the game itself. I can go on.
Why are those disparate sets of people grouped together as "problem solvers"? It may be because they share a clear disdain for the quality of the software they produce beyond simple effectiveness. Their code is unreadable, unmaintainable, ignores all software development best practices, and so on.
From their perspective, all that is needed to write software is raw intelligence and a minimum of learning about the programming language they have to use. Worse, they do tend to create domain-specific programming languages that fit well their domain but completely ignore any understanding of computer architecture, or any older languages too.
Sure, their target domain is well understood by the problem solvers, but the domain's conceptual model doesn't show at all in their code beyond basic mathematical conventions for naming single-letter variables. Which, of course, completely fails when the mathematical conventions call for using greek letters subscripts, in which case they tend to make up multi-letter variable names devoid of meaning.
What I'm trying to say is that problem solvers suck at software design. They can rarely work in teams without clear APIs, generally have no sense of "taste" in software development, and often just simply suck at using computers. If you've done any IT for master- or PhD-level computer science students, you know what I'm talking about.
Superficially, web programmers are similar to "problem solvers". While problem solvers do seek programming to achieve another goal, web programmers actively avoid programming as much as possible. Any form of programming is seen as an obstacle to achieve some design of functionality "vision". This also makes them distinct from all other programmers that merely do software development that targets web sites.
When web programmers make a poor choice of a programming language to learn, usually badly designed programming languages, it is their hammer, and everything looks like a nail. For example, this wall, representing the effort that lies between them and the desired product, is also seen as a nail, and they will use their poor-quality hammer to punch holes into the wall until, with prodigious effort, it finally collapses.
Hence Node.js.
While it may sound wise to simply ignore those pseudo-programmers, their incompetence do lead to the vast majority of security and privacy breaches that exist on web sites.
Until recently, programming was the hallmark of being a nerd. There was no social cachet about it, so much so that until the 90s (more so in the mid-2000s) it was often considered to be a low-cachet woman's job. Things began to change with video game programming, and even more with "web site programmers". Now, with "star programmers" being celebrated in the US startup culture, there are many that seek that stardom.
Generally, programmers tend to love new technologies, often merely because they're new. Being aware of what's new and being a trendsetter can be highly valuable. Since few have enough influence to set new trends, those seeking admiration and approval from their peers can become cheerleaders for nascent new trends that achieve some consensus amongst the hip clique, giving them their cachet without much effort. Essentially, they're buzzword machines, repeating "talking points" endlessly trying to look cool. They do not form their own opinion, but are easily swayed.
The net effect is that fame-seeking programmers spend more effort to create an aura of "coolness" than being good programmers in the first place. Instead, they reason that they are inherently smart, and just by being smart in a clique ought to be sufficient to warrant promotion. Half of their careers is about selling themselves, and it shows.
The "brogrammers" are the result of private colleges that value social influence and belonging to an elite above anything else, hence perpetuating an higher caste while presenting an aura of being inherently better than everybody else through genetic ancestry. What is actually learned in those colleges have little to no value in the workplace other than proving that the students adhere to strict social values and unnecessarily difficult exams.
Basically, brogrammers are there because they have rich parents that could afford a private college (or are snobs), or simply because they are good friends with the boss. Since their entire career depends on "networking", they defend their group of friends above anything else, especially any form of criticism. On the other hand, any outsider that may be a threat (due to their competence, etc.) ought to be crushed by social and political means.
It's as if the jocks invaded the safe haven of nerds. Oh, and women are not allowed.
Once in a while, some programmers have delusions of grandeur. They imagine their works to be on par with Art or Architecture that will stand the test of time and be admired for generations to come. And once that delusion starts, it often comes with the realization that "mere programming" is beneath them, and their greatness should stay at a higher plane of architecture and design.
The hidden truth is that they want to become architects because they love bossing around programmers that used to be their peers. It's like raising ranks to become a manager, but without those annoyances from the business side like revenue, marketing, competition and so on.
They defend their authority with countless bureaucratic rules, and delightfully enjoy enforcing tools and conventions to the "lowly programmers" that are completely out of touch with the rest of the industry, or that are complete hindrance to productivity. Some architects even have the ego of reinventing the wheel, such as introducing a home-made programming language, writing from scratch a database engine, or custom build and release systems, while at the same time summarily dismissing the better standards for dubious reasons.
Architects also love mingling with higher management, especially if management are clueless about programming, since through those friendships management become isolated from the lowly programmers, and makes it easier for management to blame the programmers when the architects' decisions cause devastating effects.