Software Tools That Shape You

At work, we’ve recently begun the transition to a new task management toolset. Since before I was brought aboard, the team has used JIRA for issue tracking and bug reporting. This is my first experience with JIRA - everything I’ve worked on up to this point utilized physical Scrum boards. The interface with JIRA is a bit overwhelming, and it took our team a considerable amount of time to figure out why one team member was receiving multiple emails every few seconds regarding open issues. Yikes!

A few months back we transitioned to a physical Kanban board for our day-to-day doings, and most recently we made the next logical step to a digital version, through Trello. I would always recommend a physical board over digital, but we lack a highly visible location for such a board for long-term work. JIRA has the means for tracking in-progress work, but overall, it felt very cumbersome. Trello’s interface and iOS/Android apps, on the other hand, instantly felt superior. I can easily make a board, set up some swim lanes, and get to business. I’ve read of others using it for personal organization (i.e. non-software development tasks, such as planning a garden, laying out housework, or sorting comics. Neat!). I’ve used it for breaking up tasks into bite-sized chunks. Note-cards or scrap paper may work just as well, but personally, I don’t feel that the software gets in the way so I'll continue to use it.

I ran across an interesting thing the other day as I took a break to read a post by Joel Spolsky, talking about having a inventory of software: 

Trello works great for a reasonable amount of inventory, but it intentionally starts to get klunky if you have too many cards in one list. And that’s exactly the point: it makes inventory visible so that you know when it’s starting to pile up. (read the rest here: Software Inventory)

If you’ve used Trello much, you know what he means. Those swim lanes fill up quickly, and it’s not super easy to dig down and drop or pick up a card at the bottom of the list.

This is an interesting example of a tool shaping one's habits - the software doesn’t make it easy to use it in a way that the authors decided was inefficient. It almost forces you to think about how many tasks are in a given column. 

Another example of software shaping the worker comes in the task, bug, and estimate tool I alluded to my team transitioning to: FogBugz, which is developed by the same team who spawned Trello, Fog Creek Software. I won’t hash out what FogBugz is and isn’t, because honestly I don’t completely know yet, I’m still feeling it out. But one aspect of it that I have touched already is the estimation portion. FogBugz allows teams to set up milestones, create tasks, and provide estimates, all in the aim of creating mathematically-sound delivery dates. It becomes more accurate over time, and it has a lot of features packed into its dense interface. FogBugz helps shape developers when tasks get estimated: the first time the developer places an estimate, FogBugz saves that estimate as the “original” estimate, even if it was very wrong! I learned this the hard way. The software reminds you that your original estimate was inaccurate, it forces you to at least think about it. Now, you can hide individual columns, so you're not stuck staring at it for the next few months, but the first time you realize your first estimate sticks, you'll start being a bit more aware.

At the very least, I'm now a little bit more aware of my own tendency to jump into things quickly, and I'll think twice about my estimate the next time I fill one in.

Want more info on FogBugz's Event-based Scheduling? Check out this link!

Survival

In the past four months, I have:

• searched, interviewed for, and landed a job
• graduated from college
• bought a house and moved my pregnant wife and I in (with her help!)
• presented my work's products at Infocomm 2012 in Las Vegas
• welcomed my family's first child into the world --- a very beautiful, healthy girl!
• recovered from oral surgery, spawned by the discovery of a benign tonsil growth (scary!)

2012 has been a whirlwind of life events for me and my family.

When my wife and I met with our pediatrician for the first time, she told us two things. You can't develop bad habits in the first 3 months, and the name of the game is survival. Her advice was directed toward raising a child, and I completely agree; sleep has been a scarce commodity. But this blog space is (mostly) focused on technical reflections.

Having started working full-time at a software company, I realized recently that my pediatrician's advice is pretty applicable to starting a career, especially in the software industry. "Survival" is one's goal, and keeping up with one's work is paramount. You have few habits, so don't worry about being a well-oiled machine quite yet. Get your bearings and learn every day: names of coworkers, the culture of the company, all the way down to how your fellow code-smiths build software. Sponge it all up, and if you get bogged down take notes!

As I gain more experience with some of the technologies I'm using, I'll try to backup my tips & lessons learned here. My current plan is to write a small Pomodoro application using MVVM and Test-Driven Development. For some reason, all of the Pomodoro Windows applications I've found are pretty minimal, and I'd like to add some features to them, such as a tracking log to see how well the user is sticking to following the Pomodoro schedule. It might be interesting to turn it into a game of sorts, similar to TDGotchi, but I'll work on getting a functional basic application first.

Until then, I'll keep on surviving.

(survival is really only present in the title of this song;
I just like the band and the song is kind of fun, if a bit cheesy :P )

Honesty & Lessons at the VBC

For the past 15 weeks I've managed to not write about one of the best learning experience I've had in my college career: developing a game, full-time, with twelve other students. I'm disappointed in myself, but to be fair, this semester has been kind of a blur. Commuting an hour each way every day and working on only one project this semester —no standard classes, no homework, no tests — has been a mentally exhausting process. It has been challenging, but it is a near perfect conclusion to my time at Ball State University, and I'll look back on my time at the Virginia Ball Center very, very fondly.

I sat in my car after quittin' time one day this past week, soaking it all in. It's hard to believe that soon I will graduate college and dive into the new job, my wife and I will move into our first home, and we will welcome our first child into the world. It all has come so quickly, and I've tried to absorb as much of it as I can, even if sometimes it feels like I'm trying to grab a hold of a passing train.

 With production of the game complete, the members of Root Beer Float Studio took an academic look at what we've learned this semester. Many, many concepts were mentioned during our time-boxed 50 minutes, the topics ranging from technical skills to the more transferable skills, such as communication and commitment. All of the students took different things away from this experience, which is one of the great things about the teaching capabilities of what Ball State calls "Immersive Learning": a group of people can take part in one project, but come away with wildly different skills and abilities.

The four graduating Computer Science students involved with the project, including myself, discussed what we took away from this semester. One of the bigger pluses of this experience was being able to have a real-world software development experience without the fear of financial repercussions for failure. We also noted that we learned a lot about ourselves; I, myself, learned as much about what makes me tick as I did about C# or test-driven development. Speaking of TDD, we noted that at a point in the semester we, as a group, abandoned it. Much of that had to do with the Unity3D environment being a pain to test, but the four of us agreed that we would be more vigilant in our professional careers to hold true to best-practices. It's great that this experience has us asking these questions, questions of professionalism and commitment.

 This morning I was reading a blog post by Jeff Atwood, titled Trust Me, I'm Lying. In it, he talks about absolute honesty as a way of avoiding white lies and building stronger relationships. As I was reading his post, I realized that I could generalize nearly all of my non-technical take-aways from this semester into a single word: honesty. Being honest about commitments that I don't truly plan on fulfilling, being honest about what I think of the music in the game, being honest about how someone isn't being accountable: these all are areas that absolute honesty could have benefited the project and the people working on it. Sure, it helps to tell white lies to avoid hurting feelings, but I wonder if being 100% truthful would've avoided some of the pitfalls we fell into.

There are a lot of life-long lessons that I've learned this semester, most of which I won't even realize for a considerable amount of time. I know this semester has prepared me well for the demands of full-time employment, such as what 40 to 50 hour work weeks feel like. I've experienced hours of sitting in front of a work computer, as well as stressful team collaboration, but I've come through the other side a stronger person. If you would like to read more about the game(check out the team blog!), or even play it(!), check out this page:

Design an Exhibit home page.

An Afternoon with Version Control

I've had a few interviews that have stressed introductory-level concepts, such as data structures and algorithms. It has shown me how in the past couple of years I've gotten out of practice with some of these ideas.

With that in mind, I decided to write a few of my own data structures. My thinking was, by implementing my own I will be more aware of how lists, maps, and others really work, which would allow me to make good decisions as to which one to use when problem-solving.

I started writing my own List implementation, but I realized I was doing things wrong.

First off, I implemented without much of a plan, which wasn't really a huge misstep, but I realized that I could use this opportunity to practice some test-driven development. So I wrote a few tests and worked on getting them to pass.

I realized my second mistake immediately after: I didn't set up any version control. I had been hacking away and I went to commit my code, but I realized I couldn't. So I stopped and backed up.

Setting up a repository took longer than I thought it might, mainly because I've never really set up my own. I've used BitBucket before, so I went there and made my own repository. I tried cloning it, which I could do easily enough through the Mercurial Eclipse plugin, but I couldn't create files; Eclipse screamed about how "the source folder is not a Java source folder." I looked at it for a bit and was somewhat stumped.

Instead of solving that problem, I thought perhaps I'm doing things backwards. So I looked into creating a repository locally and pushing that. I searched the internet about how to turn a project into a local repository and found TortoiseHG Workbench. After installing it, all seemed to be going well, until I tried to push changes. Nothing seemed to be getting pushed, and the BitBucket repository wasn't being updated. The error I was getting was pretty vague ["push aborted, ret 1"]. I'm sure it was user-error, but this path didn't seem to be getting me any closer to my goal.

Hmmm...

I backed up and went to the Mercurial wiki and found the help I needed. It looked like I would need to use the command line, which worried me slightly. I haven't had a great deal of experience utilizing terminal commands, but I figured out what I needed to do and successfully pushed a few changes.

To summarize:
Before you can commit anything, you should set up the URL of the repository in the .hgrc file. Per the recommendation of the tutorial I was following, I set up my username and repository location as follows:

[ui]
username = Josh Hurst <myEmail>
[paths]
default = https://bitbucket.org/..../

Then, I performed the following:

1. via the command line, navigate to the project folder you wish to have as your repository 
2. execute hg init
3. execute hg status, which shows you which files have not yet been "added" to the repository
4. execute hg add, adding the files to the commit
5. execute hg commit -m <Insert your commit message here, exclude angular brackets>
6. execute hg push, which will push to the URL you've provided

This is one of those things that once you do it, it's much, much easier to do again. I'm probably not using all of the features available to me, but setting up my own sandbox to commit things and have access to them, regardless of my latitude and longitude is awesome.

Hopefully as I work on this, I can get some experience with the terminal. It's an area where I can grow as a developer, and my inexperience with it shows how I grew up using GUIs (Windows 3.1, Win95, etc) and not the command line. It makes me wonder how the next generation of technology users will fare due to the huge push toward touchscreens and tablet PCs.

I Programmed Today

Despite having no homework, tests, or commitments outside of class, I've found it difficult to make time to write this semester. The type of thinking I do most days leaves me drained, and whatever energy I have left is typically zapped by my evening commute home.

At any rate, today was such a good day that I can't help but write a bit. I'm working on a project at the Virginia Ball Center, which has been a very rewarding project. I've had the chance to work with some quirky, brilliant people. As a group, we've been doing game design and internal play testing for the better part of two months. Game design uses a part of my brain that I find very taxing, but today was a bit different.

As our project moves away from game design and into software design and development, I get the chance to actually write software. I'm not resentful for things taking as long as they have; at any point, I could have said,"I don't feel like prototyping any more, I'll just write some code." But I feel that I have a good idea as to the creative direction that the game is going in. It wouldn't be fair to drop someone else into this role, I have too much momentum to do anything other than hashing out game mechanics,IMHO.

With most of the game designing done, I was able to focus some attention today on a programming task. I jumped into things via pair programming. I navigated, while a team member steered. We employed the builder pattern for the section of code we were working on, which I had not had the chance to work with yet. Today was also one of the first chances I've had to make use of some of the concepts within Clean Code, by Robert Martin. The Computer Science students within the team are reading through this book together, and we've all found it very informative.

Once our code was refactored and we determined that no code smells permeated the air, it was lunch time.  After some discussions around the dining room table and our respective meals, the Computer Science students involved with the project came together and put in some really solid collaborative work regarding use cases—something none of us were proficient with yet.

Overall, the project is beginning to really come into focus. The game is taking the shape of a game, and it's hard not to be excited! Throw some gorgeous leap-year day weather into the mix and it's easy to see why today was so great! I'm looking forward to the lessons I'll learn and the tools I'll pick up in the next two months.

Global Game Jam and the Missing of the Point

This past weekend a few of us Ball State folk journeyed to Columbus, Ohio to the campus of The Ohio State University. The point of our trek was three-fold: to meet up with an old student, for our mentor of the group to network with a well-known individual within the gaming industry, and to take part in the Global Game Jam.

Game Jam 2012 theme

The Global Game Jam, if you've never heard of it, is a 48 hour event in which teams build a working game, based upon a provided theme. The game may be digital or analog.

The theme this year was Ouroboros. It was a vague enough of a theme that one could spin an idea (pun-bearable!) in many directions. Good choice IGDA!

I wanted to work with people that I didn't know, since, to me, the point of going was to socialize; I could just as easily make a game by myself from the comfort of my own home. Ideas spawned from the group based on the theme, and I gravitated toward a specific idea, which led me to work with people I had traveled with from Muncie. "Oh well," I thought.

However, something occurred near the end of the first night that I felt odd about. People from OSU started mentioning things like, "so and so is going to show up in a bit, and he's awesome at 3D animations." Similar phrases were mentioned 5 or 6 times. This idea popped up a few times throughout the next 24 hours.

This kind of irked me. If you feel this way, in my humble opinion, then you've missed the point of the Jam. The point was to make a game. Not necessarily a good looking, or mechanically "tight" game. Just a simple game. If you feel comfortable enough to enroll in a Jam, then chances are you don't need a lot of help to create a very simple game. And there's nothing wrong with making a somewhat ordinary game. The joy is in the creating, not the creation.

As far as my group's submission, here it is: Heads Are Tails. There is a readme and plenty enough instruction to get the gist of the game on that site, so I won't analyze it in this post (and honestly, it's very, very simple; an analysis wouldn't make sense).

Our group used the skills and tools available to us, and I'm definitely proud of what we were able to accomplish. If we were to sit down again this weekend and hammer out another game, the quality would definitely improve, but our game is an artifact that represents the sum of our talents at that point in time.

Our artist sketched us as we were between expletives

Jamming was a great experience and I look forward to participating again next year, hopefully.

Have friends, will graduate

With a busy semester in my rear view mirror, I'd like to quickly point out something that has been on my mind for a bit.

I was asked a few weeks back to speak in front of a few prospective students and their parents regarding my involvement with Immersive Learning projects at Ball State. I prepared nothing, thinking I'd be speaking in front of maybe 100 people (which of course turned into upwards of 600 people!). One thing I managed to talk about, despite my nerves, was the friendships which I have gleaned from these projects.

I tend to keep small circles of friends; I'd rather they mean a great deal and have fewer of them. The friends I've made within my program have been a great blessing to me. They've been motivators, instigators of growth, and sources of stress release. A silly Youtube video after eight straight hours of work can do wonders.

If I could talk to 2006 Josh, one thing I would tell him would be that everyone feels more or less like you do. It's scary being in an entry level class, thinking that everyone knows how to program at the onset of college. This is obviously and absolutely false. I wish I was able to get over that mental barrier but some lessons take time. Getting close to a few classmates showed me that; not everyone knows what they're doing all of the time. And that's OK!


Making friends absolutely had a huge effect on my college career, and I have the few Immersive Learning projects to thank for that. Not only do they pit students against challenging problems, but they might just coax someone out of their shell, which can make all the difference.