Hello,
I am no longer posting to this blog. Please check out my new blog at mylifeforthecode.com.
Thanks,
Shawn Rakowski
My Beef With Goldilocks The Three Bears
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.
There, off my chest. Please, someone talk some sense into me…
Advice to Computer Science Students On Writing Resumes
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.
Hack Night Dreams
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.
I’ll let you know if it works out.
Babby Formed: First Look At The Spawn Of…
My wife and I had our ultrasound today… I am going to be having an amazing little girl sometime in June :).
Accents and Dialects… and Coding Standards
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.
Tagged with: Coding, Coding standards, language and programming, Software
Posted in Advice, Software Construction, Software Engineering
Posted in Advice, Software Construction, Software Engineering
Changing The World and Taming The Spirit
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 :).
Tagged with: Coding Hermits, Mentality, Software Engineering, Training
Posted in Advice, Career, Mentorship, Software Engineering
Posted in Advice, Career, Mentorship, Software Engineering
Initiatives and Mandates, or, Why We Try To Shove Square Pegs Into Round Holes
Imagine that you have a board in front of you with a series of holes. Each of these holes are different shapes and sizes. In the pile to the left of you is a is a set of pegs, of all different shapes and sizes. Your task is to fill all the holes in the board.
To complete this task you would probably analyze each hole, get a feel for its size and shape, possibly make some measurements and take some notes. You would then go to your pile of pegs and find the peg that most closely matches the hole you have analyzed. Maybe the peg you find doesn’t fit perfectly, but it fits well enough to plug the hole. Accomplishing this task may not be easy, but with the plethora of pegs available to you there is a good chance you will finish it.
Now imagine if you were given the same task, but were told to use only square pegs. Some of the holes could still be filled, and filled well, but most likely your task would become exponentially more difficult, and you would be left trying to fit these square pegs in round holes.
Software development is problem solving activity, much like filling holes in a board. As software engineers we are presented with a series of problems (holes in a board). We analyze these problems, come to an understanding about how they could be solved, and then go out and find the solution that best solves them (find the peg that fits the hole the best). When mandates are places on the solutions we are to develop, there may be some cases where those mandates are helpful, but more often than not you are left trying to solve a problem that cannot be solved or solved well with the mandated solution (shoving square pegs into round holes).
What do initiatives have anything to do with all this? First, let me say what I mean by an “initiative”, it’s a strategy to fundamentally improve the quality of the software solutions we develop. Examples of initiatives include striving to become platform independent, moving to component based software engineering, or finding ways to utilize cloud computing technologies. Initiative are positive, awesome things. So why am I calling them out?
The devil of initiatives is in how they are implemented. Too often those making the decisions hear an initiative and interpret it as a mandate, or feel that the best way to achieve the goal of the initiative is to make mandates in support of it. This is completely counterproductive to an initiative. The problem with mandates are that they can overrule the best solution to a problem. If the purpose of initiatives is to improve the solutions we develop, then it doesn’t make sense to build inferior software in support of the initiative.
It’s not just the quality of software that can suffer from mandates. Mandating a software engineer make the wrong design decision in support of an initiative creates frustration for them. It is counter to everything an SE stands for. It just doesn’t feel good. This frustration can affect teamwork. When you are developing a component under a mandate and all you are doing is churning out kluges in attempts to find a way to fit that square peg into that round hole, more likely than not the members of your team will have a hard time understanding why you aren’t done building it yet and why it isn’t of the highest quality. You begin to hold up their progress, and then they get frustrated with you. Suddenly everyone’s opinions of each other begins to drop, and you are left with a dysfunctional team.
So, what’s the solution? We need to understand initiatives and stop the mandates!!!
The best way to view an initiative is as a green light to extra devote money and resources in support of it, but only when it makes sense to do it. For instance, if you have an extremely performance sensitive application, and the initiative is to move development to python, don’t mandate it be written in python! C is far better suited for performance sensitive applications. Bottom line, you can achieve the goal of an initiative by allocating resources and money towards the pursuit of it, not mandating that everything be done in support of it.
Tagged with: initiatives, mandates, software development, Software Engineering
Posted in Advice, C, Software Engineering
Posted in Advice, C, Software Engineering
Legacy System Replacement
Its funny, when you tack the “legacy” adjective to a system it suddenly is something that must be replaced. However, like any other asset whether or not a legacy system should be replaced is determinable by a cost-benefit analysis. The following matrix is a good way to decide whether to replace a legacy system:
| High Business Benefit | Low Business Value | |
| High Quality | Maintain | Maintain |
| Low Quality | Replace | Scrap |
If a legacy system is a high quality system then there is no need to replace it. This follows the old cliché: “don’t fix what isn’t broken”. If a system has low quality and low business benefit (measured by how many people use it and how vital it is to their job) then its better just to scrap the system and not replace it. The only place where it makes sense to replace a legacy system is when it has a high business benefit but is of low quality.
This was a question on my last exam, I felt it was worthwhile information.
Training SE’s: Top-Down Vs. Bottom-Up
As I blogged about a few weeks ago, I am now responsible for training new developers at my place of employment. The training program is in need of an overhaul and I am exploring options. One of the things I have considered is switching from a bottom-up approach to training to a top-down.
Let me explain.
Currently we train developers on the language we use, then we teach them to use some of the libraries, then we start adding some business logic, and then they go on to learn more about the business as the develop. Basically, we start at coding (bottom) and work our way up to learning business. I would like to change this so that they start by learning a bit about the business, and then work their way down to coding. They would start by learning about the functional business areas, then about IT and the SDLC processes, then a high level look at the systems that support the business, then an architectural overview followed by an in-depth look at the architectural mechanisms used in the areas they will be working in, and end it all by learning how to code in the languages used in their areas.
The bottom-up approach has some problems. First, the languages taught are not always the languages the developer will be using in their functional area. They don’t really get an understanding of where they fit in the company and how the company uses what they develop. These things would be corrected with a top-down approach.
So… I am really looking for opinions, any thoughts out there on what’s the best way to train new developers?
Tagged with: Approaches, SDLC, Software Engineering, Training
Posted in Advice, Career, Education, Software Engineering
Posted in Advice, Career, Education, Software Engineering
Shawn Rakowski 