Pragmatic Programmer

Disambiguate:

http://www.pragmaticprogrammer.com/
ThePragmaticProgrammer, about the book The Pragmatic Programmer: From Journeyman to Master

During time spent consulting to project teams, AndrewHunt and DavidThomas observed many different individual styles of programming - ways people addressed their jobs and their professions.

Almost universally, we noticed that effective programmers all share a number of traits:

they care about their work, and accepted responsibility for it - they value craftsmanship
they are always learning - languages, tools, techniques and methods
they enjoy change
they value the depth and breadth of their experience, and are constantly looking for ways of applying it to the issues at hand
they are highly aware of what they were doing
they treat analysis, design, implementation, testing, and support as different facets of an overall process, rather than as discrete activities

We adopted the term Pragmatic Programmer to label individuals who embrace these traits. The pragmatic aspect comes from their approach to problem solving. Pragmatic Programmers are not wedded to a particular methodology, language, operating system, notation, whatever. Instead, they use their experience, combined with research, to choose the most appropriate combinations of tools for the job at hand. Pragmatic Programmers are not hammer wielders in search of nails.

These people are in the minority!

PragmaticPatterns? include:

General principles:

PowerOfPlainText

Alas, the programmers with the traits you describe are at a disadvantage seeking positions that include requirements such as "N years experience in language X using technology Z." Those descriptions are almost guaranteed to attract code drones with narrow skills, little interest in their craft, and a demonstrated flair for not advancing. -- JimRussell

Many places have the broken HR division that has a first-pass filter consisting of buzzwords. If you don't fit enough of them, you don't get into the interview pile. I once tried 3 times to get a friend into an interview, and his resume never got past HR, even though the company was desperate for competent programmers. -- Pete Hardie

More proposals for the list of attributes of PragmaticProgrammers:

they would be MethodAgnostic, and highly skilled in identifying the current ProblemFrame with its associated techniques. -- AnonymousDonor
they tend to think more and code less, not acting until they know what they're doing. Maybe this is only a result of the fifth point. -- ManfredSchaefer

I would consider myself as a PragmaticProgrammer and a SamGentle type. The irony is that as a PragmaticProgrammer I don't really have time to read Wiki or place this comment. -- DavidBriant

Wow, I'm a type now. Does that mean I can instantiated or am I an abstract type? -)) -- sg

I'd add these additional classifications mainly because identifying the developer type can lead to a better understanding of how they can be effective. Labels can often have bad connotations, however the right labels can be contribute to strong patters. The PragmaticProgrammer is a great ideal to strive for, however in practice it's hard to find these guys. Please don't get offended by the names, they are working ideas, I'm open to change if anyone has suggestions. -- CarlParziale

Additional Types:

I have to say that this section makes me nervous. It seems to be somewhat cynical: label people so you can control them. The motivation behind PragmaticProgrammer was different: learn to take responsibility for yourself, and apply your experience to what you do. I wouldn't want the term to be used in the kind of ingredients list that lazy recruiters and project managers use when staffing. -- DavidThomas

I feel the same way. CodeMonkey is in many ways descriptive of me (and I don't think that's a bad thing), and I find the "How to Utilize" a little bit unsettling and also plain wrong. -- LukeGorrie

I mean no disrespect (hence my willingness to change the names), however let's be honest, just because there are a ton of programmers out there who want to develop, that doesn't necessarily mean that they are good, OR that they care to get better (bill long and prosper). Some developers ARE more equal then others (sorry for the Orwellian reference). I have discussions all the time with very strong developers whose code is not maintainable nor production worthy. If you feel your code IS maintainable and IS production ready, then maybe you're not a CodeMonkey? If you don't produce code that ever reaches "production", who cares where you might fall? My main connection I'd trying to make here is that certain types of developers may NOT be suited well for XP. If so, how do you hire the right ones and avoid the others? And again, I don't like classifications myself, but it's a pattern. In fact, the entire Wiki knowledge base can be reduced to names/labels for everything in here (I've gone astray ... sorry I'll stop now). -- CarlParziale

I think it's the entire approach that is questionable, which means I don't think changing names will improve things. I don't like the idea of classifying people into arbitrary categories beyond perhaps as a party game. I do like the approach of saying "it's good to get better by always learning", "it's good to have maintainable and production worthy code", etc.

It seems you're saying that you want to able to say this person is a CodeMonkey and therefore s/he should do this job and will be successful at it. But how do you decide whether someone is a CodeMonkey? And how do you know that a real person classified as CodeMonkey correlates well with what you think an ideal CodeMonkey is? It just seems like too much of an overgeneralization. You can have an AntiPattern about a process that produces unmaintainable, non-production quality code but it becomes questionable (both in accuracy and purpose) when you generalize the AntiPattern to describe the actual person.

Also, PragmaticProgrammer seems more like an approach/process/ideal rather than a generalized classification. -- JasonYip

Do you consider yourselves PragmaticProgrammers? Do you think others agree with you? That's what really matters, not what you tell yourself. Do you have the cognitive ability to understand why you can't just hack code together and throw it into production?

A ProgrammerStereotype