Working With Me
Primer
As a developer I’ve had the chance to work with many teams, professionals, and hobbyists. Over the years I’ve really discovered what values I consider important to me while working, and I think those values would be useful to those who want to work with me in the future. Here you can get the best idea of how best to utilize my skills and worth ethics to ensure my productivity is maximized and your expectations are in line with what quality I can provide.
Key values
Learning is the goal
One of my major motivators is learning, everything else is second to that. I find enjoyment in learning new skills and applying them, and when I’m not doing that, it’s all just busywork. I don’t enjoy taking on projects that I know I can do, I prefer to push my limits and ensure I get the maximum value out of everything I work on. I enjoy problem solving, I enjoy what I do. Don’t make my work about money, I could work anywhere doing anything for money, If I agree to work on a project, it’s because I want to, not because I have to.
Documentation comes first
Product requirements, feature specifications, team agreements. Those should be a requirement before starting feature work. If the team isn’t on the same page it is near impossible to work together effectively. As a developer, I’ve always preferred a by-the-book approach to working in a team, without established guidelines, it’s very difficult to even begin working together, as naming conventions, coding patterns, and approaches to problems can vary wildly. Documentation ensures all developers are guiding the code in the same direction.
Code quality is non-negotiable
While developing, there’s a common saying: “Make it work, make it right, make it fast.” However, a lot of developers stop at making it work, and considering that “done.” This is especially prevalent under tight deadlines, and I’ve seen this time and time again at startups and in game jams. I believe, even under tight deadlines, at the very least, “make it right” must be reached. This means good architecture and code patterns, and being aware of when a pattern can become a problem.
Meetings should be collaborative and concise
If you want me in a meeting, serve a clear purpose. If you put me in a meeting where my participation is not explicitly required I will tune out the entire thing and socially auto-pilot my way through it all. I don’t actually mind meetings, I could sit in one all day, but you won’t get productivity code-wise out of me during one. I am near incapable of writing code while listening to people talk.
Still want to work with me?
Well, if you can get behind my key values, what I stand for as a developer, then feel free to contact me through any of the social buttons in the header. I’m open to working on anything, so long as I can learn from it.