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.