10 posts

Archive for the ‘Software Career’ Category


He crossed the line–testing to development

Posted by Patti Murphy   July 12th, 2011

Michail the friendly, programming vampire.

Instead of fomenting dissent (that barely exists) in a brazen attempt to boost readership, I’m changing tactics to look at ways in which testing and development are complementary, beyond their common goal of releasing quality software products.

What can I say? After my previous post, How developers drive testers nuts–let’s count the ways, I’m clearly getting less edgy.

I approached our newest addition to the Klocwork development team, Michail Greshishchev. While he’s a new full-timer, Greshishchev is not a new face around here.

The recent Carleton University engineering graduate did two co-op terms here–one in professional services and the other in testing.

So I asked Greshishchev how his stint in testing affected his development. Here’s exactly what he said:

  1. Writing short, efficient unit tests comes naturally after dealing with mammoth testing frameworks. Most of the code I write are tests – the techniques and skills I’ve learned in testing are fully applicable to development.
  2. Developers have no idea how to execute a test in our automated test system (I don’t blame them–the test machine is a large, well-oiled beast distributed over dozens of operating environments). Having the knowledge to run test team tests on developer builds means I don’t need to wait for nightly build test results to address issues. More importantly, I can add my own tests to the test team’s automated test system.
  3. It’s common for a developer to request more information about a tester’s problem report. My experience with the test team allows me to access the information on test machines myself, saving time for everyone.
  4. The test report pages actually make sense. This allows me to investigate test failures in the nightly build before a tester comes to my desk to tell me I broke something.

His experience as part of the test team has been win-win for him and his colleagues. Testing and development sound like allies, don’t they? Well, as much as werewolves and vampires can be allies, I suppose. And he was such a nice guy too, but the change is upon him.


The Co-op Experience (Part I)

Posted by Kevin Welsh   January 27th, 2011

After six years of post-secondary education, my first day of the real world had finally come.   As I approached the doors to Klocwork, I realized it was time to put all my years of education to the test.

Straight out of high school, I had little idea of what career path I should take. Four years of university passed and I graduated with a B.A. in English, but still, I didn’t feel prepared. Another two years of college in media-related studies and, ready or not, it was time to make the leap into the working world.

My first day could be described in exactly two words: a blur. Between getting set up at my desk and meetings with my superiors, it was easy to feel overwhelmed. Nevertheless, after I got past the initial nerves of starting a new job, I felt ready for whatever was to come my way.

As it was put in my very first meeting at the company, I would be given “a taste of everything”. A taste was exactly what I had needed to get myself started and get some experience under my belt.

Fast forward almost two months and the experience has been nothing short of a rollercoaster.

One of my most rewarding and yet most challenging experiences since I started here has been a project which consisted of redesigning part of the documentation wiki. One of my colleagues, Patti, has been in process of designing a new landing page, and I had been asked to carry her design over to the wiki. While the task might seem simple, it has been challenging.

When I first glanced at the page, it didn’t think there would be many issues. I’m not afraid to admit that I may have made a poor assumption.

One revision after another, I faced one obstacle after another. Problems ranged from something as simple as getting the correct spacing to more complex issues dealing with specific browsers. The end of the week was near and I felt as if I was getting nowhere.

I let myself walk away from it for the weekend and came in the following week with a refreshed mindset. While it was quickly becoming evident this particular design would not work, there was still light at the end of the tunnel. With some guidance from the documentation team, we quickly got back on track.

Now with the page’s design nearing completion with approval from the key players, it’s something I certainly feel proud of. It’s a prime example of how much I’ve learned in the short time I have been with Klocwork.

While I know work may not always be fun (a few repetitive tasks come to mind), at the end of the day, I think it is projects like this that make it all worthwhile.

In my next post, I’ll share some more of my experiences working with the support, documentation and training teams.


A new Android freshly baked!

Posted by Vahid Jozi   December 23rd, 2010

In my last post, I talked about some of the reasons why I started developing Android apps. The new Android 2.3 Gingerbread is even better than Froyo. I’m talking about a whole new Nerdy and the Droid factory.

With Gingerbread released and rolled out on the new flagship phone, the Google Nexus S, the developers’ wait is over. Some of the new features and functionalities baked within Gingerbread are:

1.    More power under the hood

My Nexus One lasts me about a day running Froyo. Android is now way smarter in managing its electrons with Gingerbread. With new interface design, smart process management and improved power management, it has increased the battery life significantly.

2.    Near Field Communication

NFC provides high-speed, short-range wireless communication capabilities and is responsible for most of the Gingerbread hype. NFC has introduced many new playgrounds for Android developers such as mobile tickets, mobile payment, identity documents, smart posters, electronic keys and more.

3.    Improved audio and graphics

Gingerbread now supports extra-large screen sizes and resolutions in addition to audio, graphic and input enhancements. This is a red carpet invitation for game developers to knock themselves out!

4.    Session Initiation Protocol VOIP telephony

SIP VOIP allows enhanced video and audio calling. It also supports video conferencing, streaming multimedia distribution, instant messaging, file transfer and online games.

5.    Native sensor support

Gingerbread now natively supports sensors such as the gyroscopes and barometers.

And let’s not forget new features like concurrent garbage collection, multi-touch software keyboard, enhanced support for native code, multi-camera support and new download management.

With all these new building blocks, I can’t wait to see what new apps are going to show up on my App Market!


Happy coding!


Why Android is such a developer magnet!

Posted by Vahid Jozi   December 21st, 2010


The open-source, Linux-based and hardware-independent Android mobile OS, with the new Android 2.3 Gingerbread release is giving mobile developers a whole new ball court to play in. Android is the fastest growing mobile OS among its competitors and with its share in the Smartphone user market growing, Android is attracting more and more enthusiastic developers.

Being a Java developer I jumped right into Android development about a year ago. There is a whole list of reasons why I chose to develop Android apps over other platforms and here are some of them:

1.    Low development costs and high returns

There is almost no cost to develop an Android app. There are no required licenses, specific IDEs or limited distribution channels. You may end up spending money on development and testing expertise, use of specific app stores and the purchase test devices, but the sum of all that is still a fraction of what you would pay to develop on other popular mobile platforms.

2.    Open and free

The two words every developer wants to hear are ‘Open’ and ‘Free’. Now you can have that on your mobile! This baby is license and royalty free because its underlying SDK architecture remains open source. The entire environment is available for customization, and developers and organizations can provide as detailed feedback as they want to the Android development team and watch as their issues get addressed in frequent new releases.

3.    Various distribution channels

Developers are not limited to the Android app market or any other channels to get their apps on consumers’ phones. Apps can be legally downloaded and installed from any unknown sources.

4.    The good old Java

Being Java based, Android uses a rich pool of libraries that provide extreme flexibility and room for uncapped creativity. Android’s topnotch documentation means virtually anyone with a working knowledge of Java can get Android applications off the ground.

5.    Flash Love!

Before Android gathered its well deserved power and popularity, Flash was thought to be a dying technology since it wasn’t supported by other mobile industry giants. There is obviously a ‘but’ here! The green robot embraced flash and took mobile web surfing to a whole new level.

6.    A little piece of the cloud

Android is heavily meshed with the cloud and it carries superior Google connectivity solutions. Google’s cloud tools are already soaring on the popularity list and they come right to the palms of the users’ hands with Android. One can also take advantage of browser connectivity solutions for Chrome and Firefox. In addition, Android provides open Bluetooth communication, something that is missing on some other popular platforms. Versions 2.2 Froyo and later allow the phone to become a portable hotspot. Now that is cool!


The awesome obviously doesn’t stop here. In my next post, I’ll talk about Android 2.3 Gingerbread features and what there is for us mobile app developers to play with!


Happy coding!


Top 5 time wasters for developers

Posted by Patti Murphy   December 1st, 2010

Klocwork developer Russ Sherk sporting his mo'stache. It's hair today, gone tomorrow.

Time’s a precious resource, so the saying goes. Don’t waste it. That’s particularly true for developers, who live in the critical path lane.

And if there’s someone who knows a lot about time management, it’s Russ Sherk, an intermediate developer here at Klocwork, and the father of three young ‘uns. Russ works on our Klocwork Review and Klocwork Inspect products and handles licensing.

For Russ, these are lessons learned over his six-year tenure at Klocwork.

“These are things you need to think about or you won’t progress as a developer,” he says.

Here’s what to do if you want to waste time:

1. Code without a plan

It’s easy to get carried away with ideas about cool features, Russ says. This is how you burn through the days–by doing a lot of things that don’t need to be done.

The fix: Classic agile philosophy. “You have a story. Then break it up into a list of features that must be done. You take those features and you break them down into tasks taking less than a day, Russ explains. A task taking two to four hours is optimal. The team here uses XPlanner for project/story/task management. You can always augment with pieces of paper.”

2. Switch tasks constantly

Mental switching eats up a lot of time because you need to evaluate where you were before you switched gears, and then go through it again when you switch back.

The fix: Get to a completion point before switching (if you can).

3. Take the idealistic approach to bad or “delicate” code

Inheriting problem code makes debugging and feature work more difficult and error prone, Russ says.

“It’s tempting to want to fix it all–but that will always set you back.”

The fix: Fix what you touch to the best of your ability. Schedule larger-scale refactoring and reorganization work separately.

4. Build infrequently

This strategy goes beyond the individual developer.  There was a time here when there were only weekly builds (Egad! Say it ain’t so!). Even 15 minutes per build slows you down, Russ says. The push by development managers for frequent builds has paid dividends.

“Now, I can go through a build process in 2-4 minutes,” Russ says. That translates into 10 to 15 builds a day.

The fix: Frequent build cycles allow you to make your changes, verify them, and handle bugs quickly.

5. Optimize early and over-engineer

This is the dark side of planning. Over-planning and perfectionism can be paralyzing.

The better approach is to keep it simple, he says.

The fix: Plan the bare minimum to get your feature working. After the feature is in place, it’s time to optimize and refactor.

And there you have it. Surprisingly, World of Warcraft didn’t even make the list.


Recruiting software developers remotely: a cautionary tale…(part two)

Posted by Carolyn Perkins   September 23rd, 2010

As promised….

In my last blog, I promised a joke about recruiters.  And here it is…the classic recruiting joke.

A recruiter was hit by a bus on his way to work one day, despite the excellent medical care he received, he unfortunately died on the operating table.

According to the After Life Standard Operating Procedure, the recruiter was told he had to visit both Heaven and Hell before making his choice of where he would like to remain.  He told them there was no need to visit Hell, he would just go to Heaven…however, SOPs being what they are (eerily similar to HR policies, in fact), he was required to visit both Heaven and Hell.

First up was Heaven, he went through the Pearly Gates and was greeted with peace and quiet, lots of lovely clouds, gentle, soothing music, angels floating around and it was all very serene and very nice.

Then he went down to Hell.  Much to his surprise, he was greeted by the Devil, who appeared to be a very friendly, fun kinda guy.  He could tell great jokes, made the recruiter laugh and then he took him on a tour of Hell.  It was nothing like he imagined…yes, it was hot, but people were standing around in groups, laughing and appearing to have a very good time.  He was treated to a fabulous BBQ buffet, full of delicious meats cooked over the fires of Hell.  After his buffet, he was entertained by a very talented band called the Hounds of Hell, and he thoroughly enjoyed himself.

He was brought before St. Peter after his tours, and he was asked how his day was and was told he could now make his decision on whether he wanted to spend his afterlife in Heaven or Hell.  After much hemming and hawing, he decided that based on his tours, he would prefer to go to Hell.  St. Peter asked if he was sure, because that really was a surprising decision and it was final, the recruiter said, yes, I am sure and he was sent back down to Hell.

When he arrived back in Hell, he was once again greeted by the Devil…but this time the Devil grabbed him, attached chains to him, and gave him a shovel.  He pushed him into a fiery pit with the rest of the people in Hell who were also all chained and toiling away with picks and shovels.  The recruiter looked up at the Devil and said, “What happened?  This is not how Hell looked when I was on my tour”  The Devil gave him an evil grin and said “Before we were recruiting you, now you are considered an employee”.


Recruiting software developers remotely: a cautionary tale… (part one)

Posted by Carolyn Perkins   September 16th, 2010

There have been a number of stories about internet dating gone bad lately.  One regularly hears stories about how people misrepresent themselves on dating websites; use old pictures, or even someone else’s pictures to lure unsuspecting love interests in.

These type of experiences are not limited to those seeking love…it also happens to those seeking a job, or those seeking an employee.  Technology is a wonderful thing but should never be used in place of the good old face to face meeting that must happen in the recruiting process (and in the love match process) .  I made a rookie mistake way back at the start of my career that reinforced this for me.   I was working for a high tech company that shall remain nameless, as I was not the only idiotic one in this story and I must protect those who are not as forthcoming about their idiocy.  We were looking for a developer, and the search was not going well.  Finally, we came across a resume from an individual, and it looked quite impressive.  As the individual lived in a different city, we set up a phone call for the interview.  It went well enough for us to want to have a technical interview with the individual, so in the interests of saving time and money, we also set that up by phone.  I am not sure I would have been able to tell there was anything amiss if I had been on that call, but in hindsight, I should have at least placed the call, or sat through a few minutes of it.  The technical interview went very well.  Then… we made our big error in judgement, we extended an offer without having laid eyes on the person, the offer included relocation costs.

Within 2 hours of the person starting, the hiring manager came to me in a panic.  Apparently, she was quite certain that this was not the same person she had interviewed over the phone…this became blatantly obvious as time went on.   We are still  not entirely sure what happened but we suspect the candidate had someone else do the technical interview for him…and since it was over the phone, we had no way of knowing.  Needless to say, the new employee did not stay an employee for very long and I learned a very valuable lesson.

This goes both ways…it is worth the trip to check out an employer face to face.  I have no doubt that candidates have been wooed by companies that were far less than they appeared and had a face to face meeting at the company’s site been conducted, lots of relevant and valuable information would have been gathered.  Do your due diligence in looking for a job, don’t accept what a recruiter says at face value, there are some wonderful jokes about recruiters and I will share one in my next blog.


How to decode a software development job description

Posted by Carolyn Perkins   August 24th, 2010

Fooled by the job description

So you are not really happy with your current position and you are starting to sniff around.  You might go to Monster and check out some of the jobs that are posted there. You may check out some companies’ websites and see what open positions they have.  Regardless of how you go about looking for a new job though, you will run into job descriptions.  There may be a few job descriptions out there that excite you and motivate you to apply because you can totally see yourself working for a company that writes such a perfect job description for you; however, the majority of them will cause your eyes to glaze over and probably bring on a few face splitting yawns.

Bear with us, there is reason to our insanity when it comes to job descriptions.  When recruiting for any position, but in particular for technical positions, we must pull together something that provides some guidance to job seekers.  And while I am at it, I will be completely honest and admit that sometimes I get the requirements for the position and realize I have no clue what the manager is talking about.  But the manager asked for it so it gets incorporated into the job description.

Job descriptions can be incredibly useful if you know what you are looking for.  They should give a feel of the company, the job and even the team.  I am sure you have all seen those blogs or websites that provide humorous takes on particular phrases, and admittedly some of those have a ring of truth to it.  Yes, sometimes seeing the term “start-up company” can be a rather unsubtle hint that the compensation package maybe more creative than you had bargained for.  “Team Player” can indicate that your team may be challenging and difficult to get along with or…it might mean that the manager wants someone who can play nice with others, because mean people do not do very well in that environment.

The job description does describe the ideal candidate, and really, we do not expect to see the ideal, but we do want a person who fits the job description.  For example, if the job description asks for 5-7 years in C/C++, and you have 3 years of C/C++, then by all means apply. If you have 0 years in C/C++, then do not apply.  The skills are listed there for a reason.

Since you are reading this, you may be on the Klocwork website.  If so, check out our careers section.  You might read a job description on there that appeals to you, and if you do, send us your resume.


I have the software skills; I had a decent interview; why didn’t I get the job?

Posted by Carolyn Perkins   July 13th, 2010


It was a mistake for Eric to wear a t-shirt to his job interview, and it was a bigger mistake to wear that particular t-shirt.


People who do not get hired after an interview second guess themselves; they look for concrete reasons as to why they were not hired for that particular job.  They might justify it by saying the company sucked, the interviewer was an HR douchebag, the hiring manager did not know their stuff.  Of course, they may be correct in passing these judgments, however, chances are there simply was a mismatch between the person interviewing and the company.  When this happens, count your blessings that the people doing the interviewing for the company knew that.  Being brought into a company that is a mismatch with your values and attitudes can impact everything you do, not to mention, make you downright miserable.

An interview is an opportunity for you to interview the company…to find out if you like them.  It is not just about sitting in front of some scary people and answering the questions they fire at you.   For most people, interviews are not pleasant experiences.  However, they are an evil necessity, until a more effective way of assessing people is invented.  And this brings me to the point of this blog…how the hell do you get through an interview?

  1. Be prepared, know the names of the interviewers, know the company business and feel free to bring in notes.  It is entirely reasonable to request more information from the company representative setting up the interview.
  2. Appear enthusiastic and interested (but not so much that you are confused with a salesperson!).
  3. Dress appropriately.  This generally means clean trousers and a shirt with a collar, maybe a tie for the men, a clean skirt and a blouse for the women.
  4. Answer the questions, and if you do not know the answer, let the interviewer know with the promise to get back to them.
  5. ASK QUESTIONS…find out enough information to determine whether you want to be an employee.
  6. Finally, follow up…if you like what you heard during the interview.  Just an e-mail will suffice, and believe me that will set you apart from 90% of the candidates.

How not to submit your software developer resume…

Posted by Carolyn Perkins   June 22nd, 2010

I like developers.

I have spent a career hiring, motivating, confusing, annoying and retaining developers.  I am not going to go so far as to say I understand you guys, but I do know what makes a good developer.  More importantly, I know what makes someone a bad fit for the team I am recruiting for.

First impressions are important. Yeah, I know, it sucks and your technical prowess should speak for itself, but it doesn’t.  Let’s face it, if you forget the “L” in Klocwork in your cover letter, I’m laughing too hard to pay attention to your superior coding skills.

If you continually refer to me as “Sir”, my feminist nose gets a bit out of joint; resumes filled with spelling errors throw into question your attention to detail and your level of concern for putting forth solid code.

While I am on the subject of resumes, it’s very impressive that people have the experience to fill up 15 pages of a resume. Maybe it’s even impressive that they have the time to type out a 15-page resume, but no one else has the time or the inclination to read a 15-page resume.  To date, the record length for a resume that I have received is 25 pages – this person is not employed here.

Being in this industry and in HR for as long as I have, I have learned something shocking – people stretch the truth on their resumes!  Imagine that!  And then imagine a company having the audacity to have someone in for an interview and test the person to assess whether what they claim on their resume is actually the case.  Of course, as a candidate, you should then take great offense to the fact that my colleagues and I called into question your integrity, your intelligence, and your worth as a citizen of the world.  In fact, you should probably follow up your interview with a strongly worded e-mail addressed to Sir at Kocwork.  Or maybe you shouldn’t.

Just…don’t…do…that.   We are not attacking your credibility. We do not enter the interview room thinking you are a lying, worthless waste of skin. In fact, we are pretty excited to meet you, so far we have liked what we have seen, otherwise you would not be here.

We will remain excited to meet you, right up to the point where you show up half an hour late, wearing a questionable outfit covered with what appears to be last week’s Sunday dinner.  Maybe you will look me in the eye, or maybe you will direct your eyes to my chest and keep them fixed there throughout the interview.  When that happens I like to observe where your eyes remain clamped when my male coworkers are interviewing you because inevitably it has nothing to do with what is on the interviewer’s chest. It’s just a convenient place to rest one’s gaze.  However,  between you and me, it kinda freaks me out.

I found this blog to be rather cathartic. I have more, so much more and if I am invited back as a guest blogger, maybe my therapy bills will go down.  Until we meet across a table in our interview room, I wish you good luck and good code!