One of my hobbies and fun things in life is to play tabletop role-playing games. I thought it might be fun to play with that a bit.
The system I’ve probably spent the most time in is Pathfinder 1st ed., though in college we used to play a whole bunch of Dungeons and Dragons 3 and 3.5 editions. These systems are all basically related, and there are some handy online references.
For folks unfamiliar with games, the setup is that there is a world narrated and simulated by a dungeon master (DM) which is explored and interacted with by some number of players. Players may explore fantasy lands, acquire special items and artifacts, combat enemies, and generally attempt to ruin the nice things their DM has put together for them. It’s a good time.
The non-DM players each have one or more player characters (PC). The abilities and actions of these characters are based on their stats, which broadly are their ability scores, alignment, class, race (in newer editions, ancestry or bloodline…think species), skills, and feats. These stats are then used to calculate derived stats like health, attack accuracy, attack damage, carry weight, move speed, and so on.
This time, I’m just going to go look at ability scores and alignment.
Here’s a quick recap of the character attributes in D&D-style systems:
|Strength||How strong a character is, how hard they hit, how much they can carry.|
|Dexterity||How quickly a character can move, how nimble a character is.|
|Constitution||How robust and able to take damage a character is, how well they can keep going in spite of interference.|
|Intelligence||How adept a character is at learning skills, solving puzzles, speaking languages, or applying knowledge.|
|Wisdom||How good at reasoning about consequences of actions, perceiving subtle environmental cues, seeing through ruses or certain types of magical effects.|
|Charisma||How persuasive a character is, how good at negotiating they are, how talented at magic.|
So, for developers, let’s play with this a bit.
Strength is the amount of code/infrastructure that a developer is comfortable working with on a daily basis. It’s a measure of how much a developer can keep in their head at a given time.
Dexterity is the flexibility of a developer in solving a problem and how quickly they can drop an approach and pick up a new one. It’s a measure of how quickly a developer can rewrite a codebase.
Constitution is the ability of a developer to persist in on a problem without giving up. It’s a measure of the resilience of a developer to a thorny problem.
Intelligence is the cleverness of a developer when coming up with solutions, whether by using multiple languages, paradigms, or techniques. It’s a measure of how “hard” a problem a developer can solve.
Wisdom is the ability of a developer to identify problems similar to what they’ve faced before and to look ahead at the possible constraints on and repercussions of the solutions they’re implementing. It’s a measure of how careful a developer is.
Charisma is the facility of a developer in communicating about their work, both in collaborating with teammates and doing discovery with other stakeholders. It’s a measure of how well a developer can interface with other people.
D&D is where the (often memed) concept of character alignments comes from. There are variousinterpretations of this system beyond the original blurbs in the rulebooks, but the gist is a 2-axis space of good vs evil and lawful vs chaotic.
Lawful vs chaotic is a spectrum with respect for authority and reliability on one hand, and flexibility and freedom on the other.
Good vs evil is, most simply, a spectrum with altruism and concern for others on one end, and selfishness and disregard for others on the other.
For developers, I think it’d be reasonable to change this to:
Lawful vs chaotic is a spectrum with desire for organization and structure on hand, and ad-hoc/free-form solutions on the other.
Developers that are lawful prefer to have neat and clear organization of their codebases, use languages with strong support for advanced typing, inheritance and interface hierarchies, rich tooling for static analysis, and so forth.
Developers that are chaotic prefer to have languages that let them switch easily between paradigms, enjoy languages with macros for making their own situation-specific tooling, aren’t concerned about codebase organization, and generally optimize for how flexible a solution they can create.
Good vs evil is a spectrum with desire for producing artifacts that are useful on one end, and the desire for having stimulating and fun production of artifacts–irrespective of their utility–on the other end.
Developers that are good are focused on creating things that are actually going to be used. They believe that the act of programming is ultimately about the value of the the thing that they create. At the extreme, they are willing to compromise other things in order to ensure that they are empowering people.
Developers that are evil are focused on the act of programming itself, whether or not it the end artifact is actually worthwhile at all. They enjoy the puzzle aspect of development, the weaving of code into neat patterns and forms and derive satisfaction from the act itself. At the extreme they are perfectly happy to throw away a program without ever shipping it or spend time finding neat implementations of algorithms with no practical value.
I’m contractually obligated to provide an interpretation of the chart given these definitions, so without further ado the developer career alignment chart:
|Good||Embedded engineers||Game developers||Web developers|
|Neutral||Compiler writers||Data scientists||Finance developers|
|Evil||Framework developers||Developer evangelists||Bloggers|
Have a good one!