I'm in a funny spot as a guy frequently described as either, "the most technical person on a non-technical team," or "the least technical person on a technical team". The little I know gets me in a lot of trouble, but still I feel it's crucial to understand at least the outline of what your engineering team is doing and why. There are too many reasons to describe here, but one of the most important is making sure that both your creatives and devs feel each other "get it". That's no small task!
On our team we have the good fortune to be working with absolutely top-notch engineers who are also blessed with "big picture" thinking. Let me describe what I mean with a counter-example... I once heard a story of a wizard who created a golem; an unthinking automaton that carried out its tasks precisely as described without cognition. This wizard instructed his golem to move some earth from one part of the garden to another, then died unexpectedly. Centuries later, that golem was found was found still moving sand, the cause of a giant wasteland.
When people of different disciplines talk, they're often baffled by the decisions the other makes. An artist can feel like they asked an engineer to put on shoes, and checking on progress a week later suggest the engineer untie them first. An engineer asked by a business person to make a hammer can deliver the perfect hammer and be criticised because it doesn't paint over nail holes. These are ridiculous examples, but a few people are probably nodding and thinking, "yeah, I've felt that" right now.
What point am I making? I guess just that I'm really grateful to be working with engineers who'll tell me when they don't understand why I'm asking for something or how it will help our game. Half of the time it's because I've failed to communicate what's in my head, and the other half of the time it's because my idea was bad in the first place. They work hard to make sure that everyone has at least some understanding of why they're working on something, even if we don't really understand how it works. So... thanks guys.
Also, to any server folks that were drawn in by the title, I should share some stuff I half understand. Here's a summary I've put together of the tools and structure we're working with, nabbed from a doc the engineers helped me put together a few months ago. I'd love your input if you have any suggestions, or if I'm simply mistaken about the way I've described something!
The server is currently written in CoffeeScript (a language that compiles into JavaScript), running with Node.js, and using MongoDB as the storage database for game tables on the server to accept that object and store other information about pending games and games in progress. This setup should be fast and leave a small footprint as we expand. We are currently using Javascript Object Notation (JSON), but may also use Binary JSON (BSON) later. Further, we're using Representational State Transfer (REST) API structure, but we are only using POST (insert, update) and GET commands currently, whereas a true REST API would do updates with PUT and deletes with DELETE HTTP commands.
No comments:
Post a Comment