I put my daughter to bed most nights, and just about every time I do I read her various books. One of these books is the story of Goldilocks and the Three Bears. There is a section of this book that drives me mad, and if it wasn’t an ancient golden book that my daughter enjoyed so much I would have tossed it out many months ago.

What drives me nuts? It’s not that there are three personified bears. It’s not that it is a story about home invasions by scary girls. It has everything to do with the porridge…

So… the mid-sized bear (that’s the mama bear) makes some porridge. It’s too hot to eat so the bears take a walk in the woods. Later, Goldilocks invades the bear’s home and spies the darn porridge. She proceeds to try each of them. The large bowl is too hot. The middle sized bowl is too cold. The small bowl is just right…

wait.. wtf…

In what universe does a medium sized bowl of porridge dissipate heat faster than a small bowl? I guess there is the unlikely scenario that the mother bear liked her porridge cold so she poured it early and let it sit prior to pouring the large and small bowls, but really? This inconsistency completely ruins this book for me.

One of my responsibilities at work is to help in the recruitment process for entry level software engineers who are mostly recent and soon-to-be graduates in computer science. While I’ve had this responsibility I’ve reviewed a good number of resumes, and I cannot believe how many are poorly written. I’ll generally overlook it and check for other redeeming qualities, but if your resume stinks you’ll immediately start off on my “B” list. Here are some simple tips you can follow to ensure your resume doesn’t suck.

Seriously, do some grammar and spell checking. This does not mean running the grammar and spell checking tool in Word and calling it good. You’ll want to do this, obviously, but there is plenty that even the best spell checkers will miss. On one resume we received, a student described their responsibility to customers as “making the happy”. If you read some of my blog entries you’ll probably find that I am not a grammar/spelling Nazi, but glaring mistakes like this, while entertaining, are not going to land you on my “A” list of candidates. Read your resume through out loud, and have someone else take a look at it.

Make sure your contact information is up to date. This last recruiting cycle we received an otherwise impressive resume from a candidate, but when we tried to email him the messages would never deliver. We eventually contacted him by other means, but when asked about it, he had to embarrassingly admitted that he intended to set up the email address to look more professional but never did. Hopefully someone else didn’t get all hyped up about landing and interview. Don’t be a knucklehead, make sure we can contact you. Furthermore, if you are looking to land a job check your email everyday.

Put your majors, minors, expected graduation date, and GPA near the top of your resume and make them bold. When we are glancing through these things we look for this information first. Please, do not make it hard for us to find.

Unless you have major software development experience, please put your education first and your work experience second. When you are fresh out of college your education is really all you have. I don’t care that you fabricated quality hamburgers while shift leader at McDonald’s, or that you formatted a spreadsheet for some company. Put this information on there, but in a less prominent position than your education. Furthermore, only put undergraduate and graduate level education on your resume. Most likely there is nothing you did in high school that matters to me.

Make your resume clean and professional. Don’t use flashy designs to try to convince me you’re creative. If you did well in school I’ll know you are. Flashy designs are a distraction.

If you have links to projects you’ve done, a portfolio, or an extended online resume then please hand type these into a browser yourself and make sure they go to a working page. I don’t know how many times we’ve had dead links in a resume. It’s annoying.

Your resume should be one page. Period.

Don’t create your resume alone. Most universities have a career center that is itching to help you find a job and will help you create a near perfect resume. If you aren’t using these resources then you’re not very resourceful are you?

That’s all I can think about right now. Resume writing is not rocket science, or computer science for that matter >.<, and you shouldn’t be putting out sub quality resumes if you expect to be considered for a position at any company.

There are many things I miss about my college days, but if there was one thing I miss more than anything else it was the energy of the computer science lab late night the day before a big project was due. A slurry of creative minds working at full speed to make something out of nothing. The clasp-fizz of Mountain Dew and Red Bull cans. The aroma of Pizza or other snacks. Music drowned out by the clicking and clacking of mice and keys as line after line of code is written, tested, written, and tested again. The back and forth of ideas for how to carry out the task, and the shared frustration as someone screams “why isn’t it working?” The sudden euphoria when you realize you’ve actually created something, and the surprise when you look at the clock and its beyond 3 am. It was a magical time, when you could sit down at 4 or 5 in the afternoon and less than 12 hours later produce a fully functioning piece of software that was sure to land you a big fat A. In those moments we didn’t know nor care how difficult the task before us was, we knew if we just put our minds to work we could get it done… and we did.

Now, 3 years and nearly 5 months removed from those nights in the computer science lab, and coding seems so much less magical than it used to. Much of the passion I have for coding has diminished, and I am left dreaming up ways to recapture the energy of those late nights on campus. In the past year or so, as my Twitter usage has grown, I began to encounter tweets about various “hack night” events scheduled in larger cities. There is little information about hack nights if you Google them, but here are a few of the better pages I found on the subject:

I believe this is exactly the type of thing that could bring back some of that energy and passion I once had for this subject. The problem is I am not sure I could convince anyone to go along with it. I have pitched this idea to a few friends/colleagues of mine, but I was met with much skepticism. They point out that it would be difficult to get everyone on the same page, they doubt we could really accomplish anything, and they note their fatigue with already spending their day at the keyboard. I fear they have forgotten the time we spent in the computer science labs, and what we were able to do then. Just imagine what we could do now with our experience!

Recently, a senior coworker shared his belief in a diminished vigor among the developers we work with to put forth new and innovative ideas. The first article I linked to above seemed to prescribe hack nights to help combat such a thing. With that, I think it might be worth while to pitch the idea of sponsoring a hack night for our developers as a team building exercise with the hopes of renewing some of the energy we all had when we graduated from college. I really think spending even one night a month getting together to learn and hack away on the things we personally want to work on would do wonders for productivity.

In college and in my career I have regularly worked with people who originated from foreign countries. Their home may have been China, South Africa, Korea, India, UK, or any number of other countries. One thing we all have in common besides our desire to build rockin’ software is that we speak a common language (i.e. English). However, often they might as well have spoken a completely different language because I fail horribly at understanding them some of the time. And I am sure they have an equally difficult time understanding me some of the time.

Isn’t that strange? If we speak the same language, shouldn’t we understand each other? What could explain this phenomena?

Okay, those were rhetorical, its our accents and dialects! We grew up in different parts of the world. We learned to speak the same language in different ways. And now, while we share the language we have a hard time learning or working together because we just can’t seem to overcome the differences in the way we deliver the same language.

Now imagine a world where a language came with a unified accent and dialect that all people using that language must use. You marry the language in all of its glory with the style of how its delivered. In that world you will have solved the problem of two people struggling to communicate using the same language.

Obviously this would be very hard to accomplish in the world of inter-cultural communication, and that isn’t what I am trying to get across.

When people use the same language and deliver it the same way then communication is easy. Then you share a language, but the delivery is different, then communication is hard. This applies to the way we write our code, and is one of the reasons why coding standards are important.

A world with no coding standards is a world full of accents and dialects. The language may be the same, C, C++, Java, etc, but the way it is delivered differs. Like an accent or a dialect the style of delivery affects the ability of the parties sharing that code to understand it. The code we write is a form of communication. Like a book, when we read the code we see the application unfold before our eyes. It tells the story of how a problem is solved. When we read code that isn’t consistent, and the styles differ so much, our brains spend so much time trying to synchronize the delivery with our own style that it makes understanding the heart of the program so much more difficult.

Unlike inter-cultural communications it is incredibly easy to marry a delivery style to a language, or at least it should be. Coding standards marry set accents and dialects to a language. They define the delivery. The benefits are the same as a language free of accents or dialects, i.e. improved communication.

The hard part of implementing a coding standard is the same as if you were to try it in a spoken language… which accent and dialect would you choose? A person might agree with you, but if they have to give up their coding style they are against it.

The easy way to solve this? Grandfathering. Everyone who was “born and raised” using a particular style can continue to use it, they are “grandfathered” in. Every new person must follow it. Languages and coding differ in that style is easily enforced. A quick review tells you whether someone met the standard or not.

I started training a great group of new hires at work this week. This is my first time training a group and it’s been exciting. Today I had something interesting pop up that brought me back to something I blogged about awhile ago. We got on the topic of what I like to call “changing the world’. Developers leaving college have a fresh idea of the latest and best practices in software engineering. When they enter the workforce they can easily see the “wrong” in everything we do in the industry. At that point they get the idea that it is up to them to “change the world”. That is, they must change the processes we have and supplant them with the “right” processes they learned in school. What they tend to misunderstand is that everyone who has come before them have already explored the move to better SE practices, and with experience they have learned when it is proper to spend time adopting new practices and when that should be put aside.

Now, I didn’t actually talk to them about the “changing the world” mentality. They asked about using new processes or implementing better ones. I started to go on about how it is okay as long as it doesn’t disrupt getting projects to market. I noted that after a while in the industry you start to shift away from the focusing on trying to change everything and realize what you’re responsibilities really are. When I was searching for words to describe this, one of them chimed in with the words they thought I was going to say: “they broke your spirit?”. The “they” used metaphorically. At the time I couldn’t yet articulate my response well, and so I responded, “no, I’ve grown up.” However this doesn’t quite grasp what I wanted to say, and it could probably be taken out of context as condescending since “growing up” usually implies the adult-child relationship. The words I should have spoken were: “I’ve tamed my spirit”.

But the truth is that I haven’t fully tamed my spirit. As a grow as a developer I am slowly gaining that wisdom I admire in those that have gone before me, but I haven’t reached the level of control and understanding they have. It’s a constant battle when you are this new in the industry to keep that urge to change the world in check. I touched on this slightly in a blog post I did awhile ago giving advice to new developers. I told them to realize that they are not “coding hermits”. This is what I use to keep my spirit tamed. When you realize that the code you are writing is for a purpose and the adoption of new SE practices can be expensive and distracting the mission of getting things to market, you realize that in many cases you really shouldn’t just try to change the world.

Blah, I am having a hard time writing about this tonight. Training is draining me! I may go through this again in better detail in a future post. Thanks for reading :).