• BeSpell
  • Gridus
  • Hamburger
  • Tug
  • Mood Board
  • Search results for 'work'

    It’s Sunday in indie game developer land. Sundays have the potential to be the hardest day of the week. The lack of material acquisitions (bagels, special coffees, etcetera) aside Sunday is the day I should be spending with my kids outside doing kid stuff.

    Instead I’m sitting in this room staring at screens trying to invent something. I’m not even interested in doing anything amazing; I just want something to show for my time. I can’t speak for anyone else but I think that I’m probably the most introspective person that I know. This means that while I’m in the process of creating something, I’m constantly doubting the facility or the utility of the thing I’m making. This means that I’m always fighting the “makers war” on two fronts.

    Can I be smart enough to do this thing in exactly the right way? The task today is creating tile sets for three dimensional environments. I need to craft content for the level designer to be able to plug in to his scene and have all the pieces fit together like we might have planned it. We’re constantly trying to keep things as loose and non-specific as possible, for as long as possible, right up until shipping. This task isn’t easy.

    Is this even worth doing? If we were a bigger outfit we might have already made a few passes at designing something like an overall map. We operate in some really grey hours though so instead we’re always shooting with one ball against the rail. Wouldn’t it be better to just model the whole thing in one whack and bake it out to the game engine? Or maybe I should make larger composite segments that fit together? Or maybe I should come back to the tile-based content idea and just focus on what we all agreed on me building.

    And so… I dither. This word is shaping up to be my drug of choice lately. Should I X or Y? It applies to an awful lot more than just the game development stuff as well which means little peace for the old thinkbox. Karl said I should write more about what I’m doing and the experiences I’m having transitioning from (whatever the hell it was that I was doing at Coalmarch) to being a full-time indie game developer.

    When I was a kid my dad spent all of his free time out in the woodworking shop he built onto the side of the house. Working with wood, making furniture and all sorts of other things has so many similarities to software development I think. I’m a lot like him in this way, right now, at least. I should probably ask him some time whether he ever doubted whether or not he was capable of figuring out dove-tail joints or putting together a bed frame with no nails. I wonder if he’d even admit it.

    6game development, games, game developers, work, working, art,

    Being Indie

    In an oddly-worded and overly-obvious twist of a personal-info-styled update: I’m going indie full-time.

    Last Wednesday was my last day with RxEOB.com. The team I worked with in Richmond was absolutely fantastic, some of the best people I’ve ever written on whiteboards with, they continually made me feel like the dumbest guy in the room.

    RxEOB does some amazing stuff in trying to fix what’s broken with our healthcare system in this country and I know they are going to continue to do well. The products we built together were some of the best I’ve ever made and sometimes I have trouble rectifying the fact that I had a hand in them at all.

    While I was there I kept finding myself thinking of the projects I was working on as my-own. I was allowed to feel a sense of ownership over the work I was doing and it was inspiring.

    Over the last few years since leaving Coalmarch I’ve been involved in a couple of different adventures. Chief among those is Mutiny, LLC a company that myself and a few others started-up to make independently produced games and software.

    At last check Harvest tells me that I’ve spent just over a full year in after-hours time (and weekends) working on Mutiny related projects since we started. This is staggering. Thinking about the work I’ve done for Mutiny, and the potential for doing even more meaningful work, is the primary reason I’ve decided to go indie full-time.

    Ultimately I’m excited to do this because it boils down to my core belief that:

    1. Making software is freaking awesome.
    2. Making software in a team sucks-less.

    We recently got a message on our Facebook page thanking us for writing Gridus. The person was coming at using the app from a direction that I don’t think anyone would have ever predicted and that tiny bit of gratitude was like rocket fuel.

    I’ve reached a point where it’s possible for me to make a move. I think I owe it to myself to give it a shot. I know that if I can put as much effort, energy and time into this as I have both the day job and my after-hours work over the last two and a half years, there’s no other option but success.

    One of the things I often say is that I like to look at making decisions from the perspective of the story you’d tell about the event five years later. When I think of this decision, all that it brings with it, this is the only logical choice.

    To quote one of the bigger career inspirations of mine:

    @brentsimmons: I am ridiculously, staggeringly, over-the-moon excited.

    Look for more amazing stuff very soon!

    ps. Because I found his article so moving I’ve copied the format he used for his announcement. I’m hoping he doesn’t mind too terribly much.

    6software development, indie dev, freelance, work,

    I Got Awarded on Flickr.


    Using “Merit” in Your CRB Process

    I don’t normally post about work related subjects. It’s just not something that I do. Lately we’ve been doing a lot of organizing around process at work (I work in Healthcare IT) specifically as it relates to product development. A few days ago and idea came to me during a call where a couple of our team members were absent.

    What about merit?

    You see, there are a bunch of people on this team. The ideas that we capture in Trello are all fantastic even if everyone knows we’re not going to be able to implement them. Someone takes the time to write down what they think will provide value for one of our products and it gets into the workflow.

    And then an interesting thing happens; nobody wants to carry the ball. What if, instead of having meetings at predetermined times to review all this stuff, we just let folks contribute as they have time in written form? That’s the merit I’m talking about here.

    If you contribute, you get to vote.

    Think about it. A world where those who take the time to participate get to shape the course of a product’s lifecycle or evolution. I can’t tell you how often some member of the team has had to rally around, “So-and-so feels really strongly that this is an important feature” only to find the note count on the Trello card at zero.

    Think about how fast things would move if people got used to taking the five minutes of their day when they’re checking sports scores or stock prices; and instead jotted down the first three things that came to mind on a feature request in the backlog. If you did this, you could easily start shelving anything that goes five business days without comment or augmentation. If you had such ruthless elegance behind your PDLC; wouldn’t the products you develop naturally be more valuable?

    The proposal is simple, design a process that’s so dead-simple that anyone can participate (Trello is great for this) and then apply some really basic, but cut-throat rules.

    1. Any feature without an defender for five days gets shelved.
    2. Any feature without a clear producible outcome for five days gets shelved.
    3. Any feature with an open, unanswered question gets shelved after five days without response.

    If you did this, your CRB would start to feel like it was powered by jet fuel, instead of coffee. You’d be able to audit the history of your products solely by examining the members that participated in the construction of the requirements used to produce it.

    You’d ultimately resolve to better outcomes because your development team would constantly be engaged in the creative process. The rate of response from your team would go up dramatically because everyone would know that they need to speak up or walk away. There’d be no in-between and lazy descriptions of functionality or proposed value.

    Anyone at your organization would be able to participate, from the mail room to HR; from the board room to QA. The rules are simple, you play the game to win; or sit down and watch it happen.

    You’d lose those features that we all despise, the contrived and inelegant solutions meant to serve a single customer with no real-world application beyond serving someone’s ego.

    Ultimately, you’d have fewer meetings altogether. The development team would be engaged and start reporting back immediately when they’ve made progress on something because they’d know that at least one person in the company thinks the feature they are work on is “cool.” Your management team would be able to spend more time dealing with scheduling instead of herding cats and planning reciprocal meetings.

    Maybe the proposal isn’t really clear. Maybe I’m just rambling.

    I’m pretty sure I’m right.

    6work, product development,

    Yeah, so - on the whole I’d say I’m killing it.

    62012, work, estimation,

    Follow me on App.net