I wanted to create a quick and to-the-point tutorial to help people hire programmers more effectively. Programming is a very broad field and it’s essential for any game (even showcases can benefit from tasteful application of code). Consequently, lots of project leads and solo developers require programmers, but — if they aren’t a programmer themselves — might wonder why their job listings aren’t getting the bites they want. Most of that comes down to a few small — but critical — misunderstandings and/or mistakes.
Required years of experience
This is a tell-tale indicator of a bad job listing, because it’s generally an inconsequential piece of information. What is the difference between 2 and 3 years of programming experience? Familiarity, concept exposure, number of projects worked on? Maybe. But how do you compare someone who codes ardently for a year, someone who has coded off and on for 4, and someone with a degree in software engineering but only got into Lua half a month ago? There’s many ways, but asking for years of experience is not one of them.
Fix this ^ by instead being specific. Here are some examples of better characteristics you might want in your programmer:
“Six months experience working on/maintaining a game with 500+ DAU (daily active users).” This will get you programmers that have experience with already active games.
“1 year experience consistently developing an experience from the ground-up (experience can still be in progress)” This will will get you programmers that have experience coding experience from the beginning (and laying the foundation for a solid project).
“Minimum six months experience working with an large studio (e.g., Uplift, Twin Atlas, etc.) maintaining a game with 500+ DAU.” This will get you programmers who likely pursue game development as a full-time job, have experience with planning/production meetings, and professional management.
Here, too, make sure you’re not just throwing a number like 500 around arbitrarily. If you think 500 DAU is the minimum number of players to determine a ‘lively’ game or anticipate your project ultimately having a similar player account - then sure, go for it. If not, reevaluate. More broadly speaking, do not give specific numbers/figures unless you have a reason. If you can’t concretely explain why you are writing down 1,000 versus 2,000 of whatever you are talking about, rethink what you are asking for in the first place.
Requirements for prior experience
(Disclaimer: there is a balance to this, use your best judgment but consider the following).
Requirements for prior experience in a specific niche can sometimes backfire. Take this analogy: programmers are like authors. While authors typically write in a single or few genres, they are highly skilled at developing stories, conveying thoughts, etc. Suzanne Collins, the award winning author of the Hunger Games series, writes mainly in the dystopian fiction and fantasy genres. However, Ms. Collins could likely write a pretty good historical fiction thriller if she put her mind to it and put in the time. Why? Because the core skills of plot pacing, managing/timing the reader’s expectations and emotions, developing robust characters, and pursuing a few central themes are universal to writing fiction.
Which brings us back to the topic at hand: requirements for prior experience. Skilled programmers are going to be very adept at managing a game’s infrastructure, developing efficient frameworks upon which your game becomes defined by, honing game mechanics, etc. Therefore, does it always make sense to build hard requirements for prior experience? For something simple, ex: a simulator, it might not make much sense at all. For something very specific (ex: a sci-fi first person shooter where players dynamically run up walls and flying through low gravity environments), it might be.
Fix this ^ by considering the expertise that your project actually requires. It may end up that it is just a preference that your programmer has experience coding the type of game you are envisioning vice a requirement. If you arbitrarily declare it a requirement when it really does not need to be, you are telling an enormous amount of talent not to apply for your job listing.
Throwing around buzz words (i.e., "OOP", "Full Stack", etc.)
Ever seen a job listing that reads something like “Must be a full stack programmer with experience using OOP and Knit”
Excuse me, that almost knocked me off my feet. What does this mean and why?
These requirements usually get tossed around because non-programmers (and this no shade to you all) see these words thrown around on the forums and equate this to “things that good programmers do”. And they want good programmers to apply to their job listing. It’s an honest mistake.
However, why are these ‘requirements’? Let’s break some of them down.
Full-stack is already a somewhat debated term on Roblox development - at best it means something a bit different to everyone within the context of Roblox game development (very rarely are any of these listings talking about website development or anything like that).
OOP is a situational programming tool that is useful at times and a waste of energy in others. I will confess, I don’t know OOP by heart, because I personally don’t find it that useful to my own coding style. When I use it, I reference my own code to review best practices for implementation. I’m thoroughly comfortable with OOP, but I’m nearly disqualified from our example requirement above if taken in a literal sense. More broadly speaking, all programmers have niches and experience, but that doesn’t mean that experience cannot be applied to other niches/aspects to get a handle on it quickly.
All programmers do research — it’s part of learning. If we don’t know something off the top of our head, give us time (it might only take 5 minutes if it’s something simple like a well documented engine feature) to look it up and get comfortable with it. The better the programmer, the more adaptable they should be, and if they already have exposure to it, all the better. You do not need someone with a PhD in OOP for your project.
Knit is one of many ways to structure a game. Like all frameworks, it’s good for some situations and bad for others. Even if a non-programmer reads the description of Knit and says “wow, this looks like it fits the bill for my project” it’s still possible that an alternative (and less widely known) or completely custom designed framework would be better. If you aren’t the programmer, why are you predetermining the framework of code you probably aren’t going to touch?
(Disclaimer: this isn’t directing any hate towards Knit. It’s a good example here, because it is popular and well-known, and thus often thrown around arbitrarily in job listings)
Food for thought. Be cautious about throwing around buzz words. You risk tossing out talent or giving off the impression that you don’t quite understand what you are asking for. And if you don’t have a solid grasp on what you want, why would any programmer want to work for you?
Fix this ^ by being knowing what you are saying/asking for. If you want to really impress (and probably get a better product), you can always mention something like “The game must be structured with a framework to ensure tidy organization of the code. As the subject matter expert, I would like to get your thoughts on the appropriate framework prior to implementation”. Know what you don’t know and leverage the expertise that you are hiring.
Conflating programmers and UI designers
Programmers are not UI designers
Programmers code UI and breathe life into the art that another designer creates. If you want a programmer that can do both - be specific and clear. Recognize, too, that you are essentially asking for someone who to produce quality work in two distinct fields, which will always dramatically reduce your application pool. This is the same thing as hiring a builder and also tasking them to do particle design. Another example is having an animator create sound effects for the weapons. In all cases, the second task you ask them to do is related, but these are different fields that typically require significant amounts of time and effort to get a solid handle on.
This mistake can again betray the fact that the person hiring does not have a complete understanding of a programmer’s role. It can also lead to pain on both sides, when the programmer (or builder and animator in the above examples) attempts to accommodate with minimal experience and produces something that is sub-par in the eyes of the project lead (well what did you expect!). These little bits can then easily stall a game’s development or burnout the hired programmers since you’re asking them to expend lots of effort into something they probably don’t enjoy or consider their job.
Fix this ^ by having UI assets ready for your programmer to implement or allowing the programmer to create ‘dummy’ UI that will be filled in later by the actual UI artist.
This lets your programmer focus on the job at task: programming. Remember, if you do ardently want the rare brand of developer that can skillfully do both, be clear about it and recognize that you are reducing your talent pool vice hiring one of each.
Misunderstanding programmer experience levels
I would broadly classify programmers into the following categories:
Just getting a handle of coding/Roblox Luau. Probably not working on commissions. Like anyone learning a new language, their code may be functional, but have efficiency, security, or scalability concerns. Beginners may be risky investments incorporating into teams, because their experience with large-scale or long-term development is going to be much smaller.
Knowledge a few inches wide (and growing!) and an inch deep
Solid handle of Roblox Luau. Is either working commissions or small development teams (maybe for groups). Code is going to be functional and will be the product of experience (and consequently mistakes made and learned from). Their understanding of Roblox as an engine is going to be higher than the average player. At this point, they probably have begun leaning into one or two niches (ex: ranged weapons, vehicles, ‘backend’ architecture, game mechanics, etc.).
Knowledge a few feet wide, several inches deep, and a foot deep in some areas
Strong handle of Roblox Luau. Unlikely to work commissions unless for a sizeable figure of currency or money paid per hour of work. Generally more focused on long-term work, either of their own projects or a few others they may be associated with. Likely to having a decent grasp of the expectations of higher-end game development, team dynamics, and production expectations. Expectations for the project lead will be high. High understanding of the Roblox engine. They have leaned deeply into several niches and are broadly knowledgeable. Code can be expected to be performant, efficiently designed, and flexible. Ideally, you should expect that they’ve identified ways to mitigate burnout and sustain creative drive (at the same time realize that very short turn-arounds requested by the project lead might be rejected for this reason)
Knowledge a mile wide, a foot deep, and a meter deep in more than a few areas
Full time programmers specializing in Roblox game development and doing this professionally. Unlikely to work commissions, unless the price matches or surpasses the amount of a working professional (i.e., hiring a professional programmer on commission financial equates to temporarily hiring an employee). Strong expectations and experience with professional game design. Knowledge of the Roblox engine is going to exceedingly detailed and intimate. Code will be well-written, efficient, clear, and performant. All traits about burnout/creative drive mentioned above apply, but coupled with the commitment to meet reasonable deadlines as a working professional.
An ocean of knowledge
So why the list? Because project leads often write listings for a programmer at a level higher than what they are looking for/actually need.
But if I need an intermediate programmer, wouldn’t it be better to land an advanced programmer?
Not necessarily. Here’s why, given the above example:
Good well written code often takes longer to write than code that just ‘gets the job done’. The higher the experience you are paying for, the better the code should be (the programmer will make less mistakes and line by line, will be coding faster), but they are also going to be more detailed, preparing for edge-cases that you probably haven’t thought about that ultimately you will be glad to have, but will cost you more (for example: your code simply will break less frequently, because they’ve already considered and caught potential problems - ironically though, you will never see this, because you will never see the problem in the first place). If you can’t discern (or don’t care about) the difference, the price tag is not going to make you happy. Consider the following: if you just need something to make coffee, why get a coffee maker with all of the bells and whistles that cost 3 times more? Same idea.
At the end of the day, remember you aren’t just paying for someone to get things done for you. You are also paying for their time
If you just want something whipped up for your group or simulator game, do you really want to hire (or waste your time trying to entice) an Adopt Me gameplay programmer? At the same time, keep a good idea out for talent. It’s possible you might have someone with the skill of an Advanced programmer, but their portfolio or past works indicates they are an Intermediate programmer. If they are trying to make the jump up to Advanced by strengthening their portfolio, you might be able to get a great deal with someone who has the skills, wants to build their portfolio, but isn’t at the point where they are charging rates associated with an established Advanced programmer or someone straddling the line between Advanced and Professional.
To round this point out and loop back to a point I’ve been making throughout this, if you write requirements that only allow a programmer overqualified for the task itself to apply, you are denying yourself a huge amount of talent that might be glad to work for you (for less).
Not giving the full task details or payment amount of your project
This is a simple mistake, so I won’t spend too much time here. List exactly what you need done in your job posting. Statements like:
- “Full details will be revealed in DMs”
- “You will need to create X, Y, Z, A, B, C, and various other small tasks”
- “You will be paid depending on the quality of what you created, with a maximum possible payment of $100 USD”
- “Integrate existing scripts that our old programmer made into our new project”
… are huge red flags
Let’s break them down, quickly, and describe what these read as:
“Full details will be revealed in DMs”
At worst, the person trying to hire you is inexperienced. At best, they are wasting your time by not giving you the full details to help you decide whether you want to apply to work for them. Why would you spend time reaching out to this person, waiting for them to reply, just to figure out what their listing is even about (all because they gave you zero details on the listing itself)?
“You will need to create X, Y, Z, A, B, C, and various other small tasks”
“various other small tasks” could be a laundry list of things. While this looks like a quick commission/job, this could turn into a huge ordeal powered by “oh yeah, this also needs to get done too”'s
“You will be paid depending on the quality of what you created, with a maximum possible payment of $100 USD”
There’s a chance this person accepts the work I do for them and then pays me, perhaps substantially, less than the maximum amount. I have no idea how much I’ll actually get from this - they could pay me $10 for my work and say “well $100 was only the maximum, you were not guaranteed to get it and we used the money elsewhere”. Hard pass.
“Integrate existing scripts that our old programmer made into our new project”
What are these scripts? Does it even make sense to integrate them, or am I going to end up rewriting all of these?
Fix these ^ by being specific about what you want them to do and how much they are going to be compensated. List exactly what you want them to do. Tell them exactly what you will you pay them (as well as how/when - ex: a proportionally with each task accomplished, at quarterly progress points, etc.).
Now, I understand if you are a non-programmer it can be daunting, because how do you know all these microsteps that go into getting your game complete? After all, that one time you asked for a system that displayed player kills on the leaderboard, your programmer mid-way through let you know that they needed to adjust all of the weapon scripts, now you needed something called ‘Datastores’?, and all of these extra steps would increase the cost, so wouldn’t it be so much more convenient to just add something small at the end like ‘assorted tasks that appear’…
No! If you’re concerned about this, just build in a clause like the following: “If any additional tasks are discovered during the process, we will discuss these separately and offer the accepted programmer priority to complete those tasks if it is determined another listing needs to be created provided they are still working on their original tasks”. Bam, now your programmer knows that there won’t be any fuzzy situations where they do the work but a mysterious new task appears and also sees that you are committed towards maintaining a good relationship with them. At the same time, you give yourself an off-ramp to prevent your programmer from suddenly revealing a bunch of ‘tasks’ that aren’t covered by the listing, since you can always decline to create a listing until after they complete the work for you.
I hope these help people’s success creating listings on TalentHub or other such mediums. The tutorial ending up being longer than I expected, but that’s to make the point clearly to people who might not be as familiar with programmers, what they look for, and how they work. Ultimately, there’s a lot of good programmers out there eager for work, but often times a bad listing/application either deter them from applying or arbitrarily disqualify them.
Feel free to drop any feedback about the contents of the tutorial. I’m already aware it’s long, if that’s your feedback