On the Treatment of Coders
Letters to the editor
Applying for Wizardhood
- Selina Kelley
Playing vs Coding
- Arjen Reudink
Starting a Clan
- Shade of Nessalin
The Only Two Guilds on Your Mud
Explorers have more fun.
- Lord Ashon
An Introduction to MUSHes
- Ervin Hearn III
Cartoon - The Mud Slinger
- Rebecca Handcock
Enter your email to be informed when this site is updated.
On the Treatment of Coders
One of the sad truths of the mud world is that there are never enough
coders. Builders aplenty, brimming with fresh idealism and plans for
entire zones, appear (and sometimes disappear) at the drop of a hat.
But coders are the unicorns of the mudding world, rarely glimpsed and
ardently pursued. We are lucky enough to have three dedicated coders on
Armageddon: Morgenes, Tenebrius and Tiernan, as well as a few other
staff members willing and able to wade through the bugs file and tinker
with things upon occasion. How, then, does an administrator keep these
beasts happy? The following four steps may help.
Aiming for a target.
1) Communicate: When asking for new code, try to let the coders know
exactly what is desired. For example, instead of 'Let's make archery
more complicated," a staff member might propose "Let's put a range on
archery, so the farther away the target is, the harder it is to shoot
it." A full description of the the idea, perhaps including examples,
such as fake logs showing what the idea will look like when being used,
helps make sure the originator of the idea and the coder are on the same
track as far as things like syntax and usage are concerned.
The same holds true for bugs. Describing how it's supposed to work as
well to how it's working right now helps clarify ideas. Coders want to
know if the bug is REALLY a bug, or something being reported because it
doesn't work as the reporter feels it should.
With bugs, give the coders as much information as possible, including
how to reproduce the bug. Examples by way of logs are great, and if
they include some form of error message (or message that they're
getting that shows it's an error), it often allows the coder to track
down what section of the code needs to be worked on.
Make sure people aren't bumping into each other. On Armageddon, we've
got a coder's board, where people post changes as they make them. This
alerts fellow team members to what they're doing and is also helpful if
unexpected bugs crop up, enabling people to track exactly what got
changed and when. Two people should not be working on the same idea at
once unless they know it, and can divvy up the work accordingly.
2) Have a purpose: Will it get used? Is it something players are asking
for? This one is a matter of ego, but we're all human and we all do
have egos. Seeing their work getting used, regularly and as envisioned,
is a reward beyond any thanks or congratulations other staff members can
give a coder. Track player requests, through entries in the
bugs/ideas/typos files as well as emails to the account and posts on the
general discussion board in order to convince a coder that the players
want, and will use, something.
Generally, with new ideas figure out how they are moving towards some
goal. A piece of code like a new skill is going to sound more
interesting if it fits into some overall purpose, such as a master plan
of non-combat related skills for the economy than it would if it is just
a random idea. You are also going to end up getting more out of the idea
if it is part of a greater whole.
Make it innovative. Some coders like to be trail breakers, to feel that
they're not just playing catch-up with another mud, but are creating
ideas and concepts new to the mud community. Some ideas get requested to
'balance' things out between groups:
guilds, or races, or mount speed. When a coder starts to feel like the
code they're doing that day only works to nullify a change made last
week, then they're going to start wondering what they will be asked to
3) Share the work: Do as much of the grunt work as you can for the
coders, including helping thoroughly test, providing help files and
documentation, and fleshing things out. In testing, give coders
information about what is not working and how to recreate the result. Be
precise about what needs to be changed: not 'the plague of locusts spell
needs to do more damage', but 'it needs to do about twice the damage it
is now.' When something requires a new help file or modification of an
existing help file, do not expect the coder to do it, but supply it
yourself. If it is something that requires building, provide the items.
Teamwork of this kind, when it is working well, is terrific, and will
often produce amazingly cool results.
4) Appreciate: Good coders can never be praised sufficiently, in my
opinion. We try to make sure that players know who is responsible for
new and interesting changes, by posting information about them in the
news as well as in our weekly update, which is a mailing our players can
subscribe to, which provides information about changes, staff and world
news, upcoming recommended playing times, etc. When players write in
with compliments or feedback on a code change, make sure that the note
gets passed along to the person , as well as that the coder knows how
cool or slick you think the ideas they have implemented are as well.
There is a tendency sometimes to regard coders as resources that spit out
code at request. The fact of the matter is that treating coders in that
way will frustrate both sides, leading coders to become discouraged and
unmotivated to implement new ideas and builders to feel that their
coding needs are not being met. Working on the four areas above may help
avoid this sort of frustration.
April 2001 Imaginary Realities, the magazine of your mind.
© Copyright Information