Difficult College Projects and Finding a Sustainable Style of Work

My college computer science program was like many others around the US: challenging and sprinkled with professors who cut their teeth on COBOL and Fortran. As a student, I had a difficult time connecting with a few of these professors. Many of them were my three times my age, so there was definitely a generational gap at play.

Oftentimes they would assign the same projects, year after year. Some of these projects' requirements had not changed in nearly a decade. I can remember the frustration I felt with these seemingly impossible assignments.

Now, a little over a year into my professional software development career, I'm reminded of those difficult tasks. I work for a small company, so a large amount of individual responsibility is given to figuring out how to solve difficult problems. In a way, those difficult projects in college prepared me for having to solve difficult problems later.

In the business world, just like academia, people get sick, they take leaves, they quit abruptly. To students, I say: get used to being mentally taxed and seek healthy ways of handling that stress and responsibility. You're sheltered to an extent in the academic world, so establish those healthy habits now. To other professionals, I say: help guide your new hires and encourage them to find healthy outlets. You set the example that they will follow, so set the bar high. If you take walks or shoot hoops at lunchtime, invite them along.

This post was inspired by recent conversations with colleagues and the short TED talk linked below. I'm lucky enough to work with people who understand the importance of finding a healthy and maintainable style of working. Here's to finding that balance!

The time LinkedIn got me a job

A little over a year ago, with college graduation looming I began my job-seeking efforts. I amassed all of my related work experience and managed to whittle my resume down to a single page. There's so much advice online regarding what to do to help land a job; one tip I read was to get it all down to a single page. It's ironic that, while the resume was necessary, its importance was dwarfed by a mouse click on a social networking site.

After my resume was crafted and sufficiently edited, I turned my attention to LinkedIn. I figured having a profile couldn't hurt, so I used my resume as a guide.

A month or two passed with me posting my resume to countless job sites and other company websites that caught my eye. I fielded more phone calls than I care to think about, for more jobs that I ultimately didn't want but went after out of fear. I distinctly remember pacing around the attic of the Virginia Ball Center, answering questions from an Amazon recruiter, thinking that this was the beginning of a crazy journey to the Pacific Northwest. That journey was not to be, much to my wife's relief. But the anxiety of not having a job and having to deal with the headhunters and the off-the-wall questions from interviewers was taxing. It took me a few weeks to disassociate my phone's ringtone with the panic of an impending interview.

Around March I received an email from a potential employer. The author introduced himself, and I later agreed to visit the company facilities for an interview. I loved what I saw, and things proceeded over the next few weeks, ultimately leading to a job offer and my acceptance of their offer. I later found out that the reason I was contacted originally was because I had clicked on the profile of one of their senior software developers; he had noticed that I'd looked at his profile and passed along my info. I was a bit confused, but when I looked a little more closely at my profile, I could see the number of people who had looked at my profile recently, a feature I had never noticed before:

Perhaps your LinkedIn viewcount is higher than mine; in that case, well, aren't you special.

Clicking on this number shows you the profile of those who've viewed your profile lately (at least it does sometimes - LinkedIn tries to hide some of them to entice you to pay for their premium account support).

I can't say that LinkedIn single-handedly landed me a job, but it certainly opened the door. For that, I give LinkedIn my thanks. The job-seeking game is not an enjoyable one for the college graduate, and utilizing connections and introductions through social networking feels more human than trying to game your way to the top of the recruiter's resume stack.

Making a game in a weekend - Global Game Jam 2013

This post is a peek inside the development of a game I helped make, during a weekend at Global Game Jam 2013. If you'd like to play the game, skip to the end of the post. If you'd like to see the how the game was developed, read on.

Global Game Jam 2013 came and went this past weekend, and I was among the throngs of enthusiasts who spent my weekend crafting, cursing, and coding. I participated last year, but this year I decided to go to the jam location being held in my backyard of Indianapolis.

If you're unfamiliar with a game jam, it's a weekend spent developing a game (either digital or analog) given an announced theme. What makes Global Game Jam special is it's a world-wide event, thousands of people take part all around the globe.

At the Jam I met up with a former professor of mine, Paul Gestwicki, who I've developed a few games with while I was attending Ball State University. We quickly started coming up with ideas based off of the theme, which was purely auditory: the sound of a heartbeat. We checked the list of diversifiers, which are ways to make your game more interesting or difficult to design and implement. Some of them are silly, while some of them are quite hard. One from 2012 comes to mind:
9. Kiloplayer
(1024 players or more at once)
The game supports 1024 players (or more) simultaneously.

One of the 2013 diversifiers piqued our interest: pulling in data from an outside source that affected gameplay. At first I suggested using trending Twitter topics. Upon some quick research we agreed that the Twitter API was a bit too limiting (I may be wrong, but it looked like it only allowed us to pull in the top 10 trending topics). Next, we checked out Google Trends. In our mockup, players would input topics that were currently very popular, and then they would input topics that weren't currently trending. We'd calculate the difference and then...well, we didn't have a definitive game design spec but we had roughed in some kind of combat of sorts based on this difference.

Randy Savage vs. Punxsutawney Phil, a battle for the ages. Also, Punxsutawney is hard to spell.

 But after a few minutes of research, we realized that Google smartly obfuscated the code, and there were not free or easily implementable means of tapping into this data. Blast...So we were back to square one.

We thought for a bit, searched online for a bit longer, and decided to try to find a different data set. To complicate issues for us, we didn't have a dedicated server that we could use to get the data for us, so we'd have to get a little creative. There's quite a bit of easily accessible data out there in JSON format, but we'd need to find a server that was configured to let us wrap a JSON query in a callback function with JavaScript, called JSONP (P standing for with padding, more info here: http://en.wikipedia.org/wiki/JSONP). Eventually we found that Wikipedia's servers would allow JSONP formatted queries. Huzzah!

We knew from the get-go that we'd use Google Web Toolkit, since our collective experience (admittedly, mostly Paul's) with Java & GWT was stronger than our collective Javascript knowledge. Looking back, I think we could have built something very similar with Javascript, though we definitely would've been slower developing with Javascript.

Using a mostly test-driven approach with Java + GWT saved us a lot of time and headaches. There were a few bugs that shipped out with the code, but we avoided many by having our unit tests guide us. I don't know if I'm drinking the GWT Kool-Aid quite yet, though. It was odd that some (most?) of the Java libraries are supported in GWT, but certain key ones aren't - such as java.lang.string. I'm sure there are good reasons for not being able to use it, it's just odd. It was also mindbending to write native Javascript code in Java, which we had to do a few times but not often. GWT as a whole felt like a roundabout way of getting things done, but I'm sure I'd understand the benefits of GWT if I researched it and used it.

One thing I'd look into ahead of time before my next jam is web hosting. Paul has some server space within the Ball State Computer Science Department, but it wasn't ideal for hosting much traffic or proxy'ing the data for our game. At work, we utilize Microsoft's Azure cloud hosting service and many tools connect to it seamlessly if you're developing in the .NET realm. Going from that, to using Dropbox for hosting our game's website was an underwhelming compromise. If Paul and I were able to host the game somewhere (for free), it might have given us some more options, such as avoiding the headache of JSONP altogether. I was a bit surprised that Facebook or Microsoft, who were sponsors of the event, didn't give the participants anything tangible. But hindsight is 20/20, and using more tools brings on more headaches. Perhaps less was more for the development of our game.

It's been about a year since I graduated, and I definitely felt more capable as a developer during this jam as opposed to last year. I would've liked to have done more to aid Paul throughout the weekend, but he has years of development experience over me. Even with a year of experience under my belt, I still have a lot to learn. It was nice to be reminded of that and to watch him work, to see the code grow and shrink quickly. The codebase was small enough that I could understand all of the parts, and getting back into the Red - Green - Refactor test-driven development way of thinking was encouraging. I'm hopeful more collegiate students get to work with their professors like I was able to while in college. My opinion is that novices really need to work with experts, especially in my field.

If you'd like to play the game, titled WikiBeat, navigate on over to the game's GGJ Page: http://globalgamejam.org/2013/wikibeat. Also, check out Paul's take on the weekend.

Special thanks to my wife for sacrificing parts of her weekend to watch our little one while I made a game. 

A Brief Issue with Visual Studio 2012

Hopefully this brief post can be helpful to someone. When I installed Visual Studio 2012 the first time, I wasn't sure which profile to select as the default type. What I saw was something similar this:

I selected something (I can't actually remember, now - probably General Development), but after using Visual Studio for a while I realized I didn't have many of the menu settings that my colleagues did. Important menu options were missing, such as Analyze, SQL, and Test. Looking online wasn't terribly helpful; I wasn't able to come up with a clear term to describe my issue. There wasn't any obvious way to access these "missing" features.

Short of reinstalling Visual Studio, I decided to wipe my profile & settings and see if that may help. Luckily, this solved my issue and I could see all of the menu items that I should have seen all along. Talk about frustrating!

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.

Taking a Page from the Programming Competitions

Having done a few programming competitions, I know firsthand how it's important when developing software solutions that the developer utilizes a sound approach. A lot of times a brute force approach will suffice, but issues arise when the software is put through the torture test of a large set of data.

In a university setting, Computer Science students are asked to come up with solutions for fairly trivial problems, at least in my experience. Coming up with the first 50 prime numbers isn't that challenging. Coming up with the first 500 or 5,000 might be more difficult. The first 50 primes might take seconds, if that. But try your code with an order of magnitude larger of a value and you might sit. With as powerful as even the cheapest machines are these days, sitting for more than 10 seconds, depending on your computation, might suggest that your approach is poorly designed or executed.

In my program, many of the projects are one-off assignments where the goal is to do X objective. Students have generally been punished, grade-wise, for uncommented code, but that has been the extent of the requirements in most cases. A brute force approach will work most times, but the code isn't well designed.

A possible solution to this is to treat the assignments more like those problems assigned at programming competitions: use a large, varied set of data when computations are being performed, and require a reasonable amount of time to finish the computation. Build a decent approach and your computation is done lickity split, but attempt to do things in a brute force manner and you just might sit and wait for seconds, minutes, or hours.

There are few things more satisfying in this discipline than coming up with a great solution for a problem that has  given you fits. I've found a good resource in the Project Euler questions. Working on problems that require a good approach gets you thinking about how to keep your algorithms lean, and it'll help you know the limitations of the language you're working in (i.e. limitations with using integers vs. floats vs. longs, rounding errors, etc.)

TechPoint Innovation Summit Overview

Ball State had a series of booths at the TechPoint Innovation Summit to showcase some technologies and student-led projects. Morgan's Raid was featured, and I and another student involved in the game's development were there to answer any questions passerbys might have.

Overall, we received a lot of positive feedback. Those people who stopped were interested and impressed (or at least they pretended to be) with our work. Even the fellow Ball State-related individuals seemed impressed and could understand how much work went into it.

The crowd at the event was overwhelmingly business-folk, which was perfectly fine. Not everyone was interested in our work, which is understandable. I am, however, glad that I took some advice from someone and suited up. There were plenty of potential employers on-hand, and I would rather err on the side of business attire than on casual, but I'll talk more on potential employers in a moment.

My colleague and I didn't get a chance to hear many of the talks/presentations other than the one directly after lunch (speaking of lunch - it was fantastic!). We were pretty busy chatting with the folk that came by our booth.

As far as potential employers, there were the expected Indianapolis companies, Interactive Intelligence, ExactTarget, etc. Anacore had their Synthesis technology on-hand, and the demonstration was impressive. It looked very fluid, very easy to use.




There were plenty of other companies that my partner in crime and I spoke with, and I'm glad that I went. Even if I don't land a job from any of my leads, getting out there and speaking to professionals is a worthwhile experience. It definitely eased some of my anxieties, and I'm thankful to be entering into a field that appears to be very healthy, despite an uncertain business world.

Whirlwind

It seems I have reached the point in the semester in which everything comes due and everything occurs. Hopefully I've navigated it well enough to get through this semester with all of my hair. Time will tell.

I never summed up my thoughts on the ACM programming competition, which shows how much I prepared for it: very little. I'm disappointed that my schedule ratcheted up from "slightly busy" to "incredibly busy" at seemingly the worst possible moment, but such is life.

The competition itself went decently. Our team performed acceptably, and I'm confident that the majority of our issues stemmed from all of us being plain-old too busy to prepare. The skill in these competitions is (quickly) seeing the mathematical question within the prompt paragraph(s). That and I/O. After the competition at Huntington University over a month ago, my team was pretty prepared for any potential I/O hiccups.

My teammates and I were not aware that we would not be using Eclipse. It wasn't an unreasonable request by the competition operators to not allow us to, we just hadn't read the fine print to see that we would be, basically, using notepad and compiling via command line. This isn't a difficult task, but by never having done it we were  more than a little frazzled when we didn't see our most familiar IDE. After a quick "Hello World!" introduction to our software, we were back in business.

The questions for the competition were reasonably harder. The competition itself was interesting because every team received a balloon (balloons are the competitions "theme", if it were to have one) whenever they achieved a correct answer. By the midpoint of the competition, our team had no balloon (because we had no correct answers) which took a fun thing (receiving a balloon) and turned it into a sad, depressing thing. We managed to get a single correct answer and were in the process of getting another correct before the competition ended. Bummer, I still want my balloon! It's an interesting thing to provide a resource, make it scarce, and then see how people will be excited and motivated just by the idea of receiving that thing.

Overall, it was a lot of fun. I obviously wished I had invested a bit more time to prepare, but, if it wasn't blazingly clear: my life is quite busy. I would highly recommend any undergraduate student to take part in a similar event. It may not make you a better professional programmer, but they make you think critically about a problem. They force you to come up with a solution, which can expose some shortcomings in your own thought process. An example: I've been interested with the Sieve of Erastosthenes, which comes up with the number of primes up to a number n more elegantly a brute force approach. A problem (Question D of the pdf in the previous paragraph) during the competition required us to check a large set of numbers to see if they had a certain mathematical quality. Our group had a lot of back and forth discussion about whether we could compute a master list of numbers we would look for, and save them in an array or list. Then, we could check the input to see if the number was in our collection. A member of our team took the stance that it could not work. We talked it out, tried a different strategy, and then came back to my idea (it was one of the few good ones I had that day!) and voila! It worked! Our initial approach took far too long to compute the answer, so thinking of the Sieve helped me develop a better strategy. Sometimes you can get away with brute force, but some questions expose how poor of a choice that really is.


I wish I had another year to compete in these kinds of competitions, but, barring any catastrophic events, I'll be ineligible this May when I graduate. Darn!

I'm really looking forward to the spring, so I'm having trouble keeping my eye on the prize --- the prize being this semester as a whole ending well. Our group for the spring met at the Kitselman Center and discussed some preliminary ideas about what we want to work on. The center itself is a great old building. I was a little disappointed that it didn't have more wide-open spaces, large rooms that could accommodate the entire team easily. But my concerns melted away when I saw the attic! It's a large, open room that could easily hold all of us in a work environment. My jaw might have hit the floor when we walked in. I could easily see us modifying it and having a stellar studio setting, if we can successfully reserve the room. Exciting stuff, and I'm looking forward to wrapping up this semester and getting a chance to work with some great people!

My Review of 97 Things Every Programmer Should Know

A month or so ago, my wife and I were glancing through the local library. I, naturally, gravitated toward the tech section to see what they had to offer. There were some behemoth books, including Java In a Nutshell, which appeared to be about 8 inches in diameter.

I continued to work my way through the iOS books, the For Dummies titles, until a small, purple colored book caught my eye. The book was titled 97 Things Every Programmer Should Know. It's billed as the "Collective Wisdom from the Experts", and I found that to generally be true.

The book is arranged in very tiny gulps. Each topic has a separate author and spans all of 2 pages. It's a very approachable read, and it's one that you can safely pick up for 20 minutes and set down for a week.

The concepts are mid-range, technology-wise. You'll get a few code examples and references to specific hardware/software, but I never felt that the concepts were far over my head.

The authors seem to be experts or, at the very least, professionals with years of experience. The only one I recognized by name was Robert Martin. Over the duration of each article, I grew to trust each author's advice.

Generally, I knew 90% of what I read, which probably suggests good things about me. The big thing that I'll take away from this book is the idea of thinking of the opposite side of the work equation when I'm coding. Meaning I should try to think of the user, the tester, the manager when I'm working. I don't have a lot of experience with Quality Assurance testers, but I understand their role and I'm better equipped to work with them having read this.

Another concept that came up in a few different ways was to continue learning. Several of the authors recommended learning new programming languages regularly, reading the humanities, or learning other spoken languages. Communication is obviously pivotal when it comes to programming, and the advice in this book made that much very clear.




In the nugget "Pair Program and Feel the Flow" I enjoyed this particular part:
(By Gudny Hauknes, Ann Katrin Gagnat, and Kari Røssland)

Reduce the "truck factor": It's a slightly morbid thought experiment, but how many of your team members would have to be hit by a truck before the team became unable to complete the final deliverable? In other words, how dependent is your delivery on certain team members? Is knowledge privileged or shared? If you have been rotating tasks among pairs, there is always someone else who has the knowledge and can complete the work. Your team's flow is not as affected by the "truck factor."

Robert Martin had this insight to share:

What is a professional programmer?

The single most important trait of a professional programmer is personal responsibility. Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship. A professional programmer does not pass that responsibility off on others.

• If you are a professional, then you are responsible for your own career. You are responsible for reading and learning. You are responsible for staying up-to-date with the industry and the technology. Too many programmers feel that it is their employer's job to train them. Sorry, this is just dead wrong. Do you think doctors behave that way? Do you think lawyers behave that way? No, they train themselves on their own time, and their own nickel. They spend much of their off-hours reading journals and decisions. They keep themselves up-to-date. And so must we. The relationship between you and your employer is spelled out nicely in your employment contract. In short: They promise to pay you, and you promise to do a good job.

• Professionals take responsibility for the code they write. They do not release code unless they know it works. Think about that for a minute. How can you possibly consider yourself a professional if you are willing to release code that you are not sure of? Professional programmers expect QA to findnothing because they don't release their code until they've thoroughly tested it. Of course QA will find some problems, because no one is perfect. But as professionals our attitude must be that we will leave nothing for QA to find.

• Professionals are team players. They take responsibility for the output of the whole team, not just their own work. They help each other, teach each other, learn from each other, and even cover for each other when necessary. When one team-mate falls down, the others step in, knowing that one day they'll be the ones to need cover.

• Professionals do not tolerate big bug lists. A huge bug list is sloppy. Systems with thousands of issues in the issue tracking database are tragedies of carelessness. Indeed, in most projects the very need for an issue tracking system is a symptom of carelessness. Only the very biggest systems should have bug lists so long that automation is required to manage them.

• Professionals do not make a mess. They take pride in their workmanship. They keep their code clean, well structured, and easy to read. They follow agreed upon standards and best practices. They never, ever rush. Imagine that you are having an out-of-body experience watching a doctor perform open-heart surgery on you. This doctor has a deadline (in the literal sense). He must finish before the heart-lung bypass machine damages too many of your blood cells. How do you want him to behave? Do you want him to behave like the typical software developer, rushing and making a mess? Do you want him to say: "I'll go back and fix this later?" Or do you want him to hold carefully to his disciplines, taking his time, confident that his approach is the best approach he can reasonably take. Do you want a mess, or professionalism?

Professionals are responsible. They take responsibility for their own careers. They take responsibility for making sure their code works properly. They take responsibility for the quality of their workmanship. They do not abandon their principles when deadlines loom. Indeed, when the pressure mounts, professionals hold ever tighter to the disciplines they know are right. 

Here are a few of the topics that I found interesting, but in consideration for keeping this short, I'll just link directly to them:
Comment Only What the Code Cannot Say by Kevlin Henney
Continuous Learning by Clint Shank
Learn to Say "Hello, World" by Thomas Guest
Read Code by Karianne Berg
Ubuntu Coding for Your Friends by Aslam Khan
WET Dilutes Performance Bottlenecks by Kirk Pepperdine


And a list of all of the contributions in the book:

97 Things Contributions

Overall, I enjoyed the book. I took a while to read through it since I had a lot of things going on, but the book is cut up into small enough portions that anyone could read for 10 minutes and get something out of it. I'd especially recommend it to junior or senior undergrads. There were a lot of great concepts, but even if the reader knew them beforehand (as I mostly did) the book serves as a great motivator.

CCSC: Programming Competition Thoughts

Last weekend, several CS students from Ball State traveled to Huntington University, in Huntington, Indiana for the Consortium for Computing Sciences in College. We listened to several talks on various topics relating to CS. We also presented on our experience with Scrum and Agile, in addition to the Morgan's Raid project. Our topics were well received, and the team as a whole had a great deal of fun.

In addition to the talks and presentations, we six students also participated in the programming competition, in groups of three. No one on my team (myself included) had ever done a programming competition before, so it was a bit of a change from the usual. The other BSU team had a few members who had been before, and it showed. They ended up placing 3rd out of 16 teams, with our team placing 8th.

I wasn't upset with our showing, and I was happy that the other BSU squad did well. My team had slight issues with some basic parsing that we probably shouldn't have, which leads me to a few thoughts on the event:


Parsing, Parsing, Parsing
    All of the problems required the teams to parse data that was input by the judges. There was some confusion as to what the end of document character was. If I was going to study one thing to prepare again, it would be basic I/O.

Divide and Conquer
    Our team developed a strategy in the midst of the chaos. One member had a good hold on one of the problems, so we turned the keyboard and monitor to him and let him run. Myself and the third remaining member turned our collective attention to another problem. We ended up running out of time, but this approach seemed to work. I worry about putting a lot of faith in one person understanding something. If they end up faltering, that's a lot of wasted time.

Three Heads Are Worse Than Two
   I'm used to doing pair-programming, so doing trio-programming was strange. We weren't sure how to divide the work. We had a single machine and a single (very small) monitor to share. We made use of extra desk space and spare paper to write out code by hand. If I had to do it over again, I'd suggest having the three of us look at all of the problems, decide which ones are easiest, and work through them in that order - splitting off and working in pairs when necessary.



I had a lot of fun, and I look forward to doing the ACM International Collegiate Programming Contest in less than a month. It'll be a bit more difficult, so I'm working through some Project Euler problems to help prepare. I'll be sure to chronicle the events leading up to the contest.

CCSC: Quick Thoughts

The Ball State crew got back this afternoon from the Consortium of Computing Science in Colleges Midwest Conference, which took place at Huntington University. I'll probably take some time to think of some larger ideas, but I wanted to jot down a few thoughts and reactions before I retired for the day.

Overall, I had a lot of fun. The group we went with was interesting and quirky, so the conversation was always chuckleworthy.

Four of us from the Morgan's Raid project presented on Scrum and demoed Morgan's Raid itself. The feedback was very positive, and those that came to see our poster/presentation asked great questions. It's harder to explain something to someone else than it is to think about it yourself, so it was a good exercise.

The Programming Competition was fun, too. My group of three had never participated in anything like this before, so we aimed to take it seriously but have fun. I was a little disappointed with our results(2 successfully completed problems). The winning team had 6, and the other BSU team had 5, I believe, placing them 3rd. I was happy to hear that they placed in the competition.

My team was a few minutes away from getting at least two more problems submitted. Could've, would've, should've I guess, but after discussing the whole competition there was mention of going to another, larger competition in November. My guess is that we'll try to do it. Travelling is fun, and four out of the six of us who traveled this weekend will be graduating next May, so we're all trying to get as much out of the time we have left. We also got to work and socialize with two of the other BSU CS students who will be involved with the Spring Virginia Ball Center project. I hadn't really met them until this trip and they seem like good fellas, so I'm looking forward to things a bit more than I was (which was a lot already).

Huntington University had some great architecture and a nice campus. While I wish I had attended last year, I am happy that I had another chance to experience it. I'd highly recommend attending it as an undergrad.

I'll look at the Programming Competition in my next post.

CCSC Midwest Conference

The Consortium for Computing Science in Colleges is having their Midwest conference at Huntington University next weekend, up near Ft Wayne. During the conference there will be a few presentation sessions, several talks on various topics, and a programming competition. I've never attended, so I'm paraphrasing their website. Somewhere along the way I made it a goal of mine to participate in the programming competition. I've had a few friends who did it and it sounded like a blast.

I'm happy that the four of us leftover from the Morgan's Raid spring team were able to come together and get the paperwork in on-time to present on not one but two topics. We'll be presenting/demoing Morgan's Raid. We also will be submitting a competition poster about our experience with Scrum as undergrads. After writing the abstract, I'm not looking forward to making a scholarly poster. Another reason why I wouldn't want to be an educator: scholarly writing.

We'll see how the programming competition, the presentations, and the demo shake out, but it should be a great time. I haven't worked with two of the guys going with us, but the other five of us have a great working relationship, and it's always fun to get to meet other people from your field.

SCRUM for Two

The Digital Archaeology Simulation project is still alive. If you're unfamiliar with it, it was a 5 week course this past summer that attempted to create a video game geared at 4th graders which realistically depicts the anthropological and archaeological process. It was quite the courageous endeavor, as starting something like this and expecting to finish it completely in 5 weeks is borderline insane. So with that in mind, we set out to complete the guts of the game, and complete them we (mostly) did.

A fellow member in the project and myself are finishing things up(applying the shiny graphics) by working with a few artists, but it's proving to be quite difficult. After having SCRUM guiding us (and some stellar Product Owners), we're now on our own. We both have a lives and other obligations/family outside of schoolwork, so finding time to work on this is proving to be challenging.

I mentioned that we were guided by SCRUM. I really miss it. I don't know how to translate standup meetings, the retrospective meetings, the product backlog, all down to a level that makes sense for two people. We just don't need the daily standups, but the standups definitely helped me personally to stay motivated. Maybe we need them more than I realized. If they last a minute, but that minute saves hours, then it's worth it in my book.

However, not having a strong product backlog might be the biggest issue. Two-player development may not need the hand holding that a large dev team might, but having something to look at and know where you're headed next is invaluable. We could get away with not having daily standups, but a well-maintained backlog would be a game-changer.

The biggest reason we don't have a lot of this nailed down is because we don't have a set time and place to meet and work. Our schedules are too different this semester to sit down daily. Working on this project this past summer, colocation was a given. In the spring during the Morgan's Raid project development, we had a lot of success mainly because of this time and place that was established and well-structured through the course.

This past week we both sat down and worked on a quick backlog, just to give us some bearings. We also received some graphics which we had been waiting on, allowing us to get them in the game. I've said it before, but it still blows me away to see a game take shape right around me. In our case, it really changes the way the game feels.

I feel that we're on the cusp of wrapping up the brunt of the pre-alpha work and we're both excited to get things into the hands of testers. Here's to continuing our progress...one foot in front of the other.

An Update On Things

It's been over a month since I last blogged, which is longer than I meant. Needless to say I've been busy.

The biggest of my tasks involved our(my wife and I) move from Muncie to Fishers. Meaning I will have to commute every day to class for the next 9 months. Quite a bummer, but we decided it was easier for her (being the sole bread-winner for the time being) to live closer to her work.

I also started back in with classes this past week. I'm excited for a lot of things about school this semester. This will be the last batch of classroom classes that I'll be taking, as well as the last on-campus classes I'll be taking. In the spring, as I've blogged about, I'll be taking part in a Virginia Ball Center project about the Underground Railroad. It'll take place off-campus, so this is sort of the beginning of the end.

My classes won't be too challenging, I don't think. I'm finishing up a couple requirements: a statistics class, a course on Theory of Computation, a 3D Graphics class, and finally an independent study where I'll be doing some Kinect development.

I'm also planning on attending CCSC programming competition and potentially presenting on something.

I'm enjoying the 2 hours of commuting every day as well as anyone can. I'm looking into some books on tape, since radio gets repetitive quickly. Also, my automobile's A/C went out yesterday, so lets pray for cool weather(!).

My wife and I are really enjoying the area we moved to. The apartment complex is quite a bit nicer than where we lived in Muncie. They also have a pool, a (small) workout facility, and an indoor (carpeted, whaa?) half-court basketball court. My better half has had a bit of time off until she starts working, so she's been enjoying some R&R while I'm away in Muncie.

This past weekend we checked out the local library and we were pleased. They have a lot of books (surprise!), so we were both able to check out something that interested us. I stumbled upon the technical books, so I picked up 97 Things Every Programmer Should Know. It's a decently short book (< 250 pgs), and each "thing" is only 2 pages long. My instincts say that lists of important concepts like this aren't usually objective, so you're taking a risk that the author knows what they're talking about. In this case, the "things" are written by a slew of industry experts. I recognized a few names, so I thought I'd give it a whirl. It's proven to be a good book to pick up for 20 minutes and set down.

So far, I've known just about everything I've read. This is comforting. Sometimes I don't quite know the technical terms the author(s) use, but I know the concepts once they explain them. The fact that I know the majority of what I'm reading is a testament to the education I've received, which I've realized that (like a lot of things in life) it's really what you put into it. If you go to class and that's it, I don't think it'll completely prepare you for the work that awaits you. I've been fortunate to bump into some great people and situations, and I've learned a lot from these experiences.

We'll see how my classes go. I'll definitely blog about the programming competition, as well as the Kinect development if it gets interesting (which I think and hope it will).