My good friend Webster defines “Ultimate” as “the best or most extreme of its kind”. Needless to say that writing the Ultimate Guide to anything is no trivial task. But in this case it’s not too difficult, simply because of a loophole in the definition of the word. “The best or most extreme of its kind” implies “currently in existence”, and currently there is not much good information online with regard to this topic. Most (if not all) information online is bad, wrong or simply to basic to be useful. There are some good tips, but nothing that outlines a holistic, consistent, effective strategy to conducting and effective online job search. This article aims to do just that.

Truth be told I don’t really know if this is the “Ultimate Guide to Conducting and Online Job Search” or not. The reason I put the word “Ultimate” in the title is because adding that single word will likely double the readership of this article. It was put there for marketing reasons more than anything else, well sort of; it was actually put there to make a point about conducting a job search. That point being an online job search is an exercise in marketing, and marketing matters.

Some time ago, I decided I wanted to move into Sales Engineering, So (as per my article Managing your Career in IT) I decided to shore up my sales skills (I already had solid engineering skills) and then convince management to officially move me into a Sales Engineer position. I already often helped out the sales team developing prototypes, proof of concepts and tagging along on sales calls as a “Technical Expert”. Unfortunately I was too valuable an asset as Tech Lead & Project Manger, so I was shot down, and shortly thereafter I left the company. (See: So you want to be a Rock Star Developer? Maybe you should reconsider.) As part of my self training I read the book SPIN Selling (recommended by red-dirt in this now deleted question).  SPIN Selling, a book on sales, turned out to be hands down the best book on job searching I ever read!

The premise of the book is fairly straight forward, 1) there is a big difference on how you sell low end (low cost) products and high end (High cost) products 2) To sell high end products you really need a very targeted and often elongated sales process. Often you have to get through a gate keeper to reach the real decision maker, and then you need to understand what the real decision maker is looking for, and then target your pitch exactly to that. This turns out to be very similar to what you need to do when conducting an online job search. And this brings me to my second point of this article: Just like a book on sales can be a valuable reference to one conducting a job search, so too can your skills be used in a variety of ways, (hence the importance of choosing to learn transferable skills). So, you need to understand how your skills can be used, and more importantly how to explain the transfer-ability of the skills (to the skills your potential employer is looking for) in such a way that the gate keeper can effectively sell you to the decision maker. (Read that sentence again) How to do this will be extensively discussed in Parts II & III of this article.

Your online job search had two (overlapping) phases

1)      Marketing: Finding and advertizing your self to potential Employers. This is everything you do up until you get a person on the phone discussing a specific opportunity

2)      Sales: Direct contact with a potential employer where, building on your marketing, you sell yourself as the perfect candidate for the job.  (Unfortunately, in today’s job market beating out the competition is not enough; you need to be the perfect candidate). This is every thing you do from the moment you get a person on the phone discussing a specific opportunity and afterward.

Your Online Job Search “Sales Process” should look something like this:

1)      Marketing

1. Look for Markets – ie. Research where (what roles\position\industries) that there are good opportunities for your skill set and will position you for growth.
2. Generate Leads based on your research
3. Qualify your Leads
4. Market to your Leads – By sending a targeted Cover Letter & Resume
5. Get Responses
6. Qualify Responses
7. Postmortem

2)      Sales

1. Develop\fine tune a targeted sales pitch for each response (These are no longer leads, These are now Opportunities)
2. Make first (direct) contact.
3. Recruiters\HR
4. Phone screen(s)
5. In Person Interview(s)
6. The Offer
7. Negotiation
8. Postmortem

The Marketing Phase is used to bring in leads, qualify those leads (eliminating the ones you aren’t interested in) and hopefully converting the few that you are into Opportunities. During the Sales Phase you focus on closing those opportunities. Each step in the above sales process has its own set of techniques and strategies. You need to constantly analyze the techniques and strategies you are using for each step and look for ways to improve upon them. This is particularly true if you change a strategy, you need to know if that change is working for or against you. Lastly if you are not happy with the conversion rate from one particular step to the next, you should be asking your self “What am I doing wrong here and how can I improve on that?”

Here’s what my “Sales Pipe” looked like towards the end of my last Job search. (Conducted between Feb. & June of this year)

So basically, I know that if I sent out 100 resumes to qualified leads, I would get about 20 call backs; I’d interview for about half of those, and wind up with 2-3 offers. I honestly don’t know how good this compares to the average; I simply have no statistics on it. But I will tell you this; my numbers have vastly improved by doing using the strategies and techniques I will describe in the next two parts of this article. (I’m sure the sorry state of the economy didn’t help things.)

Part II of this article will focus on Marketing, specifically: looking for markets, how to qualify a lead, composing a “Flexible” cover letter & resume so it can be easily “customized” and targeted, and qualifying responses.

Part III will focus on Sales, specifically: Developing targeted sales pitches, First contact, dealing with Recruiters & HR, Phone screens, Interviewing, and Negotiating offers.

Parts II and III will be published in the coming weeks, so stay tuned…..

One last thing: this article deals exclusively with conducting an online job search, there is an obvious missing piece here, and that piece is the importance of “Networking”. Unfortunately I don’t consider myself an authoritative subject matter expert on Networking. I am simply not going to give out advice that I feel is unproven, and for that reason I won’t be writing about it. On that note, we are always looking to expand our blogging team, if you would like to write an article on Networking or any other subject matter that is of interest to the Programming Community, please drop us a line in the Programmers Community Blog Chat Room.

Recommended Reading

SPIN Selling

When I started writing this article I ran into a serious issue, defining exactly what a RockStar programmer is. The Term has the “God Problem”¹, a problem that atheists and physicists who dabble in philosophy face on near daily bases. Lawrence Krauss actually spend the better part of the preface in his book A Universe from Nothing: Why There Is Something Rather than Nothing explaining it. He practically throws his hands up in frustration stating you can’t prove that something can be created from nothing without the existence of God to someone who defines nothing as “That in which God creates from”. Being a somewhat religious individual I have decided to adopt that definition of “Nothing” (now a proper noun) because of its sheer strength in defending the necessity of God’s existence. But (hopefully) to prevent such arguments here, I will define Rock Star for the purpose of this article. Then if one wishes to argue if such a person exists or if it is a good idea to be such a person. It can be argued by means of saying “A Rock Star programmer as defined by Morons…”

So here is how I (Morons) define a Rock Star programmer: An individual who is a top level performer (let’s say more than one standard deviation). This person, when assigned work, regularly and consistently completes that work in a fraction of the time allotted without sacrificing quality, then spends the remaining time helping his teammates (by giving guidance, not by doing their work) complete their tasks on time, singlehandedly improving the performance of the whole team.
(The same definition can be used for Ninja or Jedi or the various other terms used to descried programmers of exceptional talent)

The reason I chose this definition is because I feel it is more in line with that a true exemplary developer is. The most common definition of a Rock Star is a programmer who is an order of magnitude (10x) more productive than the average programmer. I don’t believe such people exist but there are definitely people who are 5x more productive than the average. Even if you hold to this definition, the remainder of this article still applies.

(See: Are there studies clearly illustrating the great discrepancies in programmer productivity?)

Regardless of the definition, it’s becoming increasingly common in the programming community to say that Rock Star programmers don’t exist. These naysayers are absolutely wrong, these people do exist. But they only exist in an environment that allows them to exist. In such environments the average programmer is easily 2-4x more productive than in environments that are not conducive to productivity. If you don’t believe me, I ask you this: how much more productive are you working at home on your pet projects than when you are in the office doing salaried work?  There are entire books written on the subject of making environments conducive to productivity.

Employers love Rock Stars; they give their employer a tremendous value and have a positive effect on everyone around them. But that doesn’t mean it’s what’s best for you. What’s worse than being a Rock Star is striving to be one. Before you read the next sentence, if you haven’t already, you need to read my last blog article, if you don’t, the next sentence won’t make any sense… I’ll wait….Back? Good. The reason being a Rock Star is bad is because it is a lousy position to be in. The reason striving to be one is worse is because that means your entire career goals are wrong and you are striving to put yourself in a lousy position. Once you are in that position, your employer will do everything to keep you happy in that position, throwing money at you if necessary. But the day will come when you will want to move on, and that day will be a Terrible, Horrible, No Good, Very Bad Day.

As previously discussed the key to professional growth is learning new skills, putting them to use on the job, asking for more responsibilities and then for a promotion. The Rock Star doesn’t do this, the Rock Star spends years finely tuning his relatively small set of skills to the point of absolute perfection. This makes him less marketable, he can only sell himself on a very small skill set, and effectively selling himself as the absolute best to a potential employer is very hard ( if not impossible).

The Rock Star is highly valued by his employer and his job will be very secure, he will also (assuming he has some level of negotiating skills) be paid at a rate significantly higher than the industry average for his position. These two things actually work against him.  Once in this position, there is no opportunity for professional or serious financial growth.

Consider the following:

• The Rock Star can learn new skills, but can’t put them to use. His current employer doesn’t want him using his newbie skills; he wants him using his Rock Star Skills! That’s what he is being paid such a high rate for! But here is the kicker; the Rock Star is only being paid well relative to the market value for his skill set, but not relative to someone with a more valued skill set. Learned skills that have not been used on the job have very little market value. The Rock Star is stalled in terms of professional growth. The Rock star has been typecast and can’t change roles. If the Rock Star threatens to quit, his employer will let him go. If the Rock Star is not doing his Rock Star stuff, he is a regular expendable employee (who happens to be overpaid).


• If the Rock Star asks for a raise, his boss says “You are paid 25% more than any other dev on the team, your salary is on par with mine!, Sorry, no can do, maybe next year” The Rock Star has no negotiating position with his current employer; His current employer thinks to himself “Where is he going to go? No one is going to pay him as well as I do.” And his employer is right. The Rock Star is stalled in terms of financial growth.
  (See : http://blog.hirelite.com/what-developers-think-when-you-say-rock-star )


• If the Rock Star decides to look for a new Job, he will quickly realize his boss is right. There is no way to prove oneself is a Rock Star to a potential employer. There is no Rock Star Test. Nor is there a Rock Star market. He will be forced to accept a position as a mere Sr. Dev (a step down professionally) at less salary (a step down financially), hopefully this new position will offer him the opportunity to put some of his other skills to work and attain some professional growth which will then lead to financial growth.


• Even if he could attain another Rock Star role, at Rock Star pay, being a Rock Star is so dependent on the working environment of his new employer, there is a high chance of failure (to live up to expectation).


• If the Rock Start chooses to start his own business or go into consulting, he can, but he didn’t need to be a Rock Star to do this.


• How many years did it take to attain that Rock Star Skill level? Those years could have been put to better use learning new skills and moving up the corporate ladder.


• All of the above could be summed up with the following: The Rock Star is underemployed, but well paid for the job he is doing. The high pay mentally locks him into this underemployed status. His employer treats him well, is nice to him, gives him creative freedom, and a pleasant work environment. All of those things reduce his motivation to better himself, so he remains in that Rock Star position long term with little professional or financial growth. The longer he stays on this path the worse off he is.

Yes, I am actually saying it’s better to be underpaid than over, because you should have never gotten to the point where you are overpaid. You should have been promoted and taken the salary increase that comes with that promotion (so that your position is in line with your salary.) If you are overpaid you did something wrong, you should correct that mistake, in the interim take the money.

Lastly, I know that to many what I described above sounds like a dream job (an employer pays him well, treats him well, gives him creative freedom and a pleasant work environment). It is nice, but the fact of the matter is that those conditions weren’t created for the Rock Star, but are the only ones in which a Rock Star can exist. Those conditions where there when the Rock Star joined, and would likely still be there had he never become a Rock Star.

If you feel you are that skilled and want to reach your full potential with that skill, I urge you to reconsider. People who are that skilled should be running industries, not working in them.

Recommended Reading:
Peopleware: Productive Projects and Teams (Second Edition)
A Universe from Nothing: Why There Is Something Rather than Nothing
Alexander and the Terrible, Horrible, No Good, Very Bad Day

¹Any question where in trying to answer it results in an endless argument over definitions. All “God Problem” questions are off topic on P.SE as unconstructive.

One of the most persistent questions I see on Programmers.SE is “What language should I learn?” and its endless legion of variations. These questions seem innocuous enough; beginners looking for insight into the hideously complex and bewilderingly partisan world of software development. It’s more than just languages too. Languages all have attached cultures and ecosystems. Not to mention an endless parade of varying implementations and the other attendant issues like third party libraries and the melting, gibbering insanity that is the world of software licensing.

The problem isn’t that the question is invalid per se. It’s more that the motivations for asking it are typically suspect. People typically ask the question for one three reasons: They want to be magically employable by learning language X, they want to solve a problem automatically via language Y, or they want to expand their programming horizons but don’t have the research skills to do a proper job on Google. I’ll address these and several edge cases.

Speaking to Power – Languages that Employ:

The problem with “What language should I learn to get a job” is the nature of the market for languages. Companies are typically invested in a technology stack such as .Net on Windows or Ruby on Rails on Linux or something like that. You have the language, the development environment, the operating ecosystem, the deployment environment which may not be the same at all and numerous other considerations. Changing a development stack is non-trivial. It involves more than just installations. There’s training your team to deal with the code and/or the new elements of the refactored stack. There are business and legal considerations too like the cost of licensing. Individual use of a technology stack is often free. Company use tends to be much less so. Thus, companies tend to be more wary of the “new hotness” if they have a process and stack that generates money.

So you come to another case here, which is “I don’t like the stack I’m using and I want to change it without changing companies”. This is related to the second category I mentioned above about magic solving of problems, except that it is trying to magically solve your dislike of the tools you are given. Sometimes, this problem can be solved by using a cross-platform language like IronPython for .Net but often the support simply isn’t there for Language Z trying to make it into your company’s stack. Smashing the Stack is very real business concern if you’ve got a working process. Any disruption even if it’s just the injection of one new programming language can mean the difference between a profit and a loss. It’s natural to want the best tools but sometime the best tool is to adapt to the existing stack rather than wish for something “better”.

The root of this matter is the idea of the “silver bullet”. The problem is that programmers and engineers are trained to find optimal solutions. We naturally seek the best solution possible within constraints. The issue is what to do when those constraints are our own prejudices/desires? At that point it’s time to try and take a step back and see if what we are proposing is a realistic solution. The question to ask is:

“Are we fighting Werewolves?”

If you are fighting Werewolves, then using silver bullets makes total sense. Sometimes though you don’t have any silver. So the question is how to silver bullet without silver (or sometimes even bullets). The answer to be good enough at the fundamentals to hack together a solution. I know that aesthetics are important, technical debt is important but when it comes down to shipping a working product in an ugly language or 6 months late and beautiful; beautiful will leave you broke.

Putting Holes in Wizards – Magic Bullets for Personal Projects:

The same goes for people trying to get a language to silver bullets for a personal project. There is no one right answer. Everything is good for something. It depends more on a solid understanding of the problem domain of your project than a magic code from the beyond that swoops in save you the trouble of actually thinking. Sometimes languages make a world of difference but these tend to be domain specific like R for Statistics or a general language that has a particularly good setup for something like Perl’s Regex functions or Fortran’s numerical capabilities. Fundamentals are again key. Know what algorithms you need and how they fit into your problem. Solve the problem then figure out what language features you need to solve it most effectively. Then pick a language that does that optimally. Tada! “Magic” Bullet!

GoogleFu Programmer Style – How to Do Research in 2012:

If you plan on spending any amount of time doing any kind of research on the internet. Learn How to  Google. I’m dead serious about this but it particularly applies to programming where the situations are often very time sensitive. Language learning for personal growth is a great thing and usually not as time sensitive but it is no less imperative to learn to research effectively before asking around on the Stack Exchange, or anywhere else, but particularly on the Stack Exchange. Doing research often requires dialogs and discussions and that’s not something SE is particularly kind toward. Fundamental knowledge again helps here; it allows you to ask the right questions using the right words. Most languages now have websites and user groups. Once you get a targeted question, rather than a nebulous notion, it’s time to go ask it on the Stack Exchange. Examine the FAQs for your particular question category. If you are unsure ask on the site’s Meta. That’s what it’s there for.

Closing Arguments – Think before Asking and Never Panic

Language questions tend to Gorilla vs Shark more than most and I hope that this examination will help avoid that. Most of the time the answer is “whatever your boss/teacher told you to learn or why aren’t asking them this question?”. We are programmers and software engineers; Logicians, not Magicians.

The last piece of advice I’d give is to rubber duck your question: Read your question out loud at least twice to a nearby inanimate object. If you can’t explain what you’re trying to ask to the “rubber duck” you need to more carefully consider exactly what you are asking. Tight deadlines can be panic inducing but don’t fret. Take a deep breath and focus. Laziness is a virtue in programming in the sense that it makes you want to be efficient. Learn to efficiently research and communicate effectively with people and you will have a much easier time asking questions on the Stack Exchange, programming language learning related or not.

Working in a distributed team is becoming more and more popular. With the power of Internet, today we can easily work together without worrying about physically travelling to work. It saves time, fuel, and personal energy. Can anyone imagine anything better?

But, all the convenience comes with a price. Co-located workers have the advantage of direct communication, which is often underestimated. When you have all of your coworkers in a room, they will answer you immediately when you ask, “Is that document is ready?” or “Can our original design support these new requirement changes?”. When the team are distributed in many locations (and possibly many time zones), things are quite different. We must wait for our emails being answered, or the chat reply message, while the others are on their other tasks. We may get stuck and need help from another team member who are sleeping while we are at work. That’s not only irritating, but also become a real challenge for any distributed team want to push their productivity toward their maximum potential.

I have been in this position more than once. Some were school projects, some were start-ups with my friends, and some in my work elsewhere. Some of them failed desperately, the rest succeeded. What I learned from them is: the way we do things as a programmers have a big impact. And success is not only for the Project Manager – it’s something we programmers can be proud of – when we contributed in it.

There are three key principles to success: Communication, Trust, and Enthusiasm

Communication

Communication, communication, communication. I can’t stress this enough. Making sure everyone is on the same page is critically important, especially when you’re building a product a continuously changing product. In a fast-paced environment, a developer may take harmful shortcuts or forget important details if the rest of the team is not aware of their actions. Many times, I had to remind a team  member about a requirement he forgot, or explain the reason for our design the third time to the same person. It’s annoying, but it’s far better than letting developers make assumptions and cause irrepairable damage to the project.

Given that the team is potentially distributed all over the world, communication is harder but not impossible. All the team should sit together (via Skype or similar) to agree on a “communication plan”. In our case, we had two teams: client and server which works on different places with different time zones. we decided that everyday the server team would build a new version at 12:30 pm, then the client team would check to see if there’s any problems. Then, at 4pm when everyone in the server team went home, the client team will begin their work and give feedback to server team by the next day. The check at noon guarantee s that the build is not broken so badly that the client team can’t fix it.

One of the other ways to enhance communication is building a “responsive” culture. “Respond early – respond often” – that’s our motto. When you get an email and don’t have the chance to read it thoroughly, just mark them as “to read” and send a message that you’re doing on another task and will look at their problem as soon as you’ve time. That will help the people on the other end switch to another task in the meantime. (*)

Trust 

Believe me, trust is very important. If people think you are not doing your best, they won’t either. Trust others and they will trust you. Do your work so that your team can trust you, and they will be much more inclined do their work. Be as transparent as possible. Make it clear what you’re working on. All of those things are easy to say, but it requires attention and care to get them done.

Once, I joined in a start-up where everyone was eager about what we were going to build. But we were located in different countries, and also had day jobs. Several weeks passed and we got our infrastructure setup ready. But then we got stuck in a vicious cycle: late response time, endless discussion about what the project will do, and soon everyone was tired of meeting without seeing anything done. The project got cancelled.

The lesson to be learned here is: we wanted to build something, but we failed to show each other that we wanted to put forth our best effort. As a result, any trust could have been cultivated was destroyed.

Enthusiasm!

Share your vision. If you don’t love what you’re doing, you are killing the morale of others. We all love working in a enthusiastic environment, so just make it :-).

Being passionate about the project’s goal is a sure path to victory: I have noticed that when myself and other team members have a positive attitude, all team work better with less conflict and miscommunication. We even feel much better.

Enthusiasm is infectious. Coming up with new ideas (sometimes stupid) is a way to show passion. That means you don’t only do your work, but you do it with heart. If you think of any cool idea, tell others right away. Don’t be lazy and say: “I will catch up with him tomorrow” because that tomorrow will never come. Tomorrow, other tasks will pull you away along with your best ideas. If you think the idea is not mature enough to present, put it off somewhere you will absolutely look at when you have free time. I feel that a sticker right beside the monitor is not a bad idea.

Last but not least, keep a close eye on what’s going on. Revise early, revise often. No matter what you’re doing, which role you’re playing, you should be responsible about project’s success. Tell the people in charge about any risk early.

In closing, a programmer is not simply a technical worker. That’s not the spirit – any laborer can learn their work for once and apply it the same way for many years, but that’s not us. We live and breath in the ever-changing technology environment, and we come here because we love it. Working in a distributed team is not only a difficulty, but also a challenge that many of us seek to overcome.

(*) Manage your time wisely. Time management: Answer too many requests and you will not get anything done. Don’t answer then they will wonder why you don’t respond. They can’t see you are busy. Balancing the workload is an art. But for starters: Speak the truth and try to be as simple and as clear as possible.

(**) The images used in this post are credited for Stock Exchange

One of the things I like most about working in software development is the fact the for the most part you get to work with fairly intelligent people. I’ve always wondered why so many smart people manage their career so poorly.  If I had to guess, I would estimate that close to 35% of people in this industry don’t manage their career at all. Now I have a theory about why this is¹, but the fact of the matter is that explaining to that 35% the importance of managing one’s career is an utter waste of time. Today I want to focus on helping those who do manage their career, do so more effectively.

The key to understanding how to properly manage your career is to understand the importance of positioning, not where you are currently, but positioning yourself for growth (ie. You want to put yourself in a position of high growth potential).

The IT world changes so rapidly I nearly burst out in uncontrollable laughter the last time and interviewer asked me “What is your 5 year plan?”. Though its true things change so fast in IT that it’s difficult to plan long term, you should plan none the less. But your plan should be in terms of actions that will position you to take advantage of opportunities for growth; ideally those actions will also immediately contribute to your growth.

The two basic types of career growth are Professional Growth and Financial Growth.

Positioning yourself for Professional growth

Professional growth is generally thought of in terms of skill sets, you want to continue to improve on you current skills while acquiring new complimentary skills. Once you learn the basics of those skills you should put them to use on the job by asking for more responsibilities then a promotion.

Choose Skills that compliment your current skill set:

Because learning takes time and time is limited you need to ensure your time is well spent by learning skills that will best position you for growth. This is why it is so important to choose skills that compliment your current skill set. (If you already know C# WinForms learning ASP.Net will contribute more to you professional growth than learning Java.)

Having a large well complimented skill set does not make you a generalist; it makes you a well-rounded expert. Calling yourself a generalist implies that you can do many things at a mediocre level. Do not accept that label. Conventional HR wisdom is that you can only be an expert in one or two things. Don’t be afraid to challenge that, say directly and proudly, “I can do a lot of things, and I can do them well!”

Choose Skills that are transferable and Soft

Transferable soft skills should not be neglected; you should put as much effort into them as you do into learning hard skills. As you advance in your career you will find that Soft skills are of much higher value than Hard. Plus they don’t depreciate in value with time as tends to be the case with technical hard skills. Transferable skills are great because they complement so many other skills.

Choose Skills that are Marketable

This is key, if you developed all the skills in the world but can’t put them to use, you accomplished nothing. As I stated above, once you learn the basics of those skills you should put them to use on the job by asking for more responsibilities then a promotion. If no such opportunity exists with your current firm you need to look for a new job that will put you in a position to take advantage of such opportunities.  This means you must choose skills that are marketable. By their very nature marketable skills have market value, which leads us to the second half of this article…

Positioning yourself for financial growth

Financial growth usually follows Professional Growth assuming you are in a position to take advantage of your Professional Growth to earn more money. If you have positioned yourself with a solid set of marketable hard and soft skills that complement each other well, you are off to great start. But you need one more thing: Negotiating Position.

To have a strong Negotiating Position you need to:

1)      Market yourself Internally (to your current Employer) and Externally to the Job Market

2)      Have Options and Know your next best Alternative should negotiations Fail and Know your Market Value

Marketing yourself internally

Even if you are happily employed you need to market yourself to your current employer. But because your job performance is under constant scrutiny at work, you need to be what you are selling. If you are marketing yourself as that employee who should be trusted with additional responsibility (as required for Professional growth) you need to be that someone who can be trusted with additional responsibility. You simply can’t fake this for long. You need to consistently do good work and act (and dress) professionally manner and ensure you are getting proper recognition for you work. I can’t stress this enough, you need to ask for additional responsibilities and then, when the time is right a promotion. If you get shot down, you should have a positive attitude and negotiate. “What do I need to do to ensure I get that promotion next January?” Then Follow up in December.. (But you better have lived up to your half of the bargain). If you are not happy with the results of these conversations or your employer is not living up to his end, you need to look for opportunities else ware.

You should act as if you care about the company and your job performance but like you don’t need the job. You want your employer thinking “If I don’t work with him/her, he/she may just up and quit on me.” You need to have a demeanor the projects a strong personality as someone who is not going to be taken advantage of (in a professional and respectful manner). Your demeanor should suggest loyalty but with limits.

One last point on this: You should market yourself internally even if you are sure you won’t be with the firm long term. When looking for a new job you really want to spend your time and find that job that will give you the growth you are looking for, and in today’s job market that could take well over a year. If you are that guy with a positive can do attitude, constantly improving yourself and taking on additional responsibility, no employer in his right mind would let you go. When layoffs are coming, these people are literally pulled aside and told “Don’t worry”.

Marketing yourself externally

Marketing yourself externally to the job market is a bit different than internal marketing. With external marketing you can literally outright lie about everything you ever did, and be met with some success. Doing so may get you a job, but once on the job you will never be given additional responsibly or a promotion, you will be first on the list come layoffs time, and quite frankly it’s dishonest.

Conducting a job search is simple (and outside the scope of this article): You need to have a plan, you need to put you plan into action and you need to reassess and refine you plan over time and iterations.

Options

If you are offered a new job or are negotiating a promotion with your current employer, you need to know your options if you are to effectively negotiate. That means you need to:

1)      Know your plan of action should negotiations fail.

a) If you are currently employed you always have the option of staying where you are while you continue to look. Don’t make the mistake of saying “

well this is better than what I have now”

b) If your plan is “Negotiations can’t fail” your plan is sh*t.

2)      Know how long it will take you to find another Job and at what salary.

a) If you are currently employed, the answer is “I have a job!”

3)      Know how long it will take you to find the job you want.

4)      Know what accepting this opportunity will mean in terms of long term growth.

5)      Know what accepting this opportunity will affect your external marketing strategy for your next job search. (In terms of skill set and position)

6)      Know your market value.

a) Think in terms of your whole skill set, you should be compensated for as much of your skills as possible. This is why complimentary skills are so important.

7)      Know how long you can go without income & how much you have in your emergency Fund.

8)      Know the Value of you current and proposed benefits package.

9)      Know your ability to do good work and market yourself internally once you accept the opportunity.

Knowing all of the above will enable you to negotiate stronger and with more confidence.  Don’t be afraid to negotiate everything and anything. You will come off as more confident, more capable and a more appealing Candidate. Not only that but you will be more confidant you made the right choice.

In Summary: Continually improve your skill set (hard and soft), Market yourself internal & externally, Have a plan, Negotiate.

Recommended reading

The Hard Truth About Soft Skills: Workplace Lessons Smart People Wish They’d Learned Sooner
Corporate Confidential: 50 Secrets Your Company Doesn’t Want You to Know—and What to Do About Them

¹So why do smart people do stupid things-A Moronic view of Free will
There’s an old saying: “God helps those who help themselves”.  But this is not quite true; it’s more of a half-truth. The full truth is “the ability to help ones self is the help God gives”. Unfortunately god doesn’t give everyone the ability to help themselves, for  those incapable, God has no choice but to help then directly as they are helpless. So I ask you, who is more likely to make a good decision? A) The smart helping themselves or B) The Stupid with God’s help?  Stupid people make quick decisions without thinking, smart people think things through, than choose wrong or choose inaction (analysis paralysis). Simply stated smart people have the free will to f*up, as God trusts them to act in a prudent manner.  “ … Key feature of stupidity is that its power lies in its abundance. One stupid person is helpless, a herd of stupid persons can be invincible….”

One of the very first ideas we had for this blog was to convert some of the wonderful gems of the early era of our site, the undisciplined period, to blog posts. Questions that were once enthusiastically received by the community, but no longer fit Programmer’s scope.

The first deleted question I’ve chosen is Jon Skeet’s “What’s your most controversial programming opinion?” question (available only to 10K+ users, sorry), a +391 scored question that was originally asked on Stack Overflow on January 2, 2009. What follows are twenty of the highest voted answers, in random order…

1. Programmers who don’t code in their spare time for fun will never become as good as those that do.

     I think even the smartest and most talented people will never become truly good programmers unless they treat it as more than a job. Meaning that they do little projects on the side, or just mess with lots of different languages and ideas in their spare time.

   by rustyshelf

2. Unit testing won’t help you write good code.

     The only reason to have Unit tests is to make sure that code that already works doesn’t break. Writing tests first, or writing code to the tests is ridiculous. If you write to the tests before the code, you won’t even know what the edge cases are. You could have code that passes the tests but still fails in unforeseen circumstances. And furthermore, good developers will keep cohesion low, which will make the addition of new code unlikely to cause problems with existing stuff.

   by Chad Okere

3. The only “best practice” you should be using all the time is “Use Your Brain”.

     Too many people jumping on too many bandwagons and trying to force methods, patterns, frameworks, etc. onto things that don’t warrant them. Just because something is new, or because someone respected has an opinion, doesn’t mean it fits all.

   by Steven Robbins

    

4. Most comments in code are in fact a pernicious form of code duplication.

     We spend most of our time maintaining code written by others (or ourselves) and poor, incorrect, outdated, misleading comments must be near the top of the list of most annoying artifacts in code. I think eventually many people just blank them out, especially those flowerbox monstrosities. Much better to concentrate on making the code readable, refactoring as necessary, and minimising idioms and quirkiness. On the other hand, many courses teach that comments are very nearly more important than the code itself, leading to the this next line adds one to invoiceTotal style of commenting.

   by Ed Guiness

5. “Googling it” is okay!

     Yes, I know it offends some people out there that their years of intense memorization and/or glorious stacks of programming books are starting to fall by the wayside to a resource that anyone can access within seconds, but you shouldn’t hold that against people that use it. Too often I hear googling answers to problems the result of criticism, and it really is without sense. First of all, it must be conceded that everyone needs materials to reference. You don’t know everything and you will need to look things up. Conceding that, does it really matter where you got the information? Does it matter if you looked it up in a book, looked it up on Google, or heard it from a talking frog that you hallucinated? No. A right answer is a right answer. What is important is that you understand the material, use it as the means to an end of a successful programming solution, and the client/your employer is happy with the results.

   by PhoenixRedeemer

6. Not all programmers are created equal.

     Quite often managers think that DeveloperA == DeveloperB simply because they have same level of experience and so on. In actual fact, the performance of one developer can be 10x or even 100x that of another. It’s politically risky to talk about it, but sometimes I feel like pointing out that, even though several team members may appear to be of equal skill, it’s not always the case. I have even seen cases where lead developers were ‘beyond hope’ and junior devs did all the actual work – I made sure they got the credit, though.

   by Dmitri Nesteruk

7. I fail to understand why people think that Java is absolutely the best “first” programming language to be taught in universities.

     For one, I believe that first programming language should be such that it highlights the need to learn control flow and variables, not objects and syntax. For another, I believe that people who have not had experience in debugging memory leaks in C / C++ cannot fully appreciate what Java brings to the table. Also the natural progression should be from “how can I do this” to “how can I find the library which does that” and not the other way round.

   by Learning

8. If you only know one language, no matter how well you know it, you’re not a great programmer.

     There seems to be an attitude that says once you’re really good at C# or Java or whatever other language you started out learning then that’s all you need. I don’t believe it- every language I have ever learned has taught me something new about programming that I have been able to bring back into my work with all the others. I think that anyone who restricts themselves to one language will never be as good as they could be. It also indicates to me a certain lack of inquistiveness and willingness to experiment that doesn’t necessarily tally with the qualities I would expect to find in a really good programmer.

   by glenatron

9. It’s OK to write garbage code once in a while.

     Sometimes a quick and dirty piece of garbage code is all that is needed to fulfill a particular task. Patterns, ORMs, SRP, whatever… Throw up a console or web application, write some inline SQL (feels good), and blast out the requirement.

   by jfar

10. Print statements are a valid way to debug code.

      I believe it is perfectly fine to debug your code by littering it with System.out.println (or whatever print statement works for your language). Often, this can be quicker than debugging, and you can compare printed outputs against other runs of the app. Just make sure to remove the print statements when you go to production (or better, turn them into logging statements).

    by David

11. Your job is to put yourself out of work.

      When you’re writing software for your employer, any software that you create is to be written in such a way that it can be picked up by any developer and understood with a minimal amount of effort. It is well designed, clearly and consistently written, formatted cleanly, documented where it needs to be, builds daily as expected, checked into the repository, and appropriately versioned. If you get hit by a bus, laid off, fired, or walk off the job, your employer should be able to replace you on a moment’s notice, and the next guy could step into your role, pick up your code and be up and running within a week tops. If he or she can’t do that, then you’ve failed miserably. Interestingly, I’ve found that having that goal has made me more valuable to my employers. The more I strive to be disposable, the more valuable I become to them.

    by Mike Hofer

12. Getters and Setters are highly overused.

      I’ve seen millions of people claiming that public fields are evil, so they make them private and provide getters and setters for all of them. I believe this is almost identical to making the fields public, maybe a bit different if you’re using threads (but generally is not the case) or if your accessors have business/presentation logic (something ‘strange’ at least). I’m not in favor of public fields, but against making a getter/setter (or Property) for everyone of them, and then claiming that doing that is encapsulation or information hiding… ha!

    by Pablo Fernandez

13. SQL is code. Treat it as such.

      That is, just like your C#, Java, or other favorite object/procedure language, develop a formatting style that is readable and maintainable. I hate when I see sloppy free-formatted SQL code. If you scream when you see both styles of curly braces on a page, why or why don’t you scream when you see free formatted SQL or SQL that obscures or obfuscates the JOIN condition?

    by MustStayAnonymous

14. UML diagrams are highly overrated.

      Of course there are useful diagrams e.g. class diagram for the Composite Pattern, but many UML diagrams have absolutely no value.

    by Ludwig Wensauer

15. Readability is the most important aspect of your code.

      Even more so than correctness. If it’s readable, it’s easy to fix. It’s also easy to optimize, easy to change, easy to understand. And hopefully other developers can learn something from it too.

    by Craig P. Motlin

16. XML is highly overrated.

      I think too many jump onto the XML bandwagon before using their brains… XML for web stuff is great, as it’s designed for it. Otherwise I think some problem definition and design thoughts should preempt any decision to use it.

    by Over Rated

17. Software development is just a job.

      I enjoy software development a lot. I’ve written a blog for the last few years on the subject. I’ve spent enough time on here to have >5000 reputation points. And I work in a start-up doing typically 60 hour weeks for much less money than I could get as a contractor because the team is fantastic and the work is interesting. But in the grand scheme of things, it is just a job. It ranks in importance below many things such as family, my girlfriend, friends, happiness etc., and below other things I’d rather be doing if I had an unlimited supply of cash such as riding motorbikes, sailing yachts, or snowboarding. I think sometimes a lot of developers forget that developing is just something that allows us to have the more important things in life (and to have them by doing something we enjoy) rather than being the end goal in itself.

    by Greg Beech

18. If you’re a developer, you should be able to write code.

      I did quite a bit of interviewing last year, and for my part of the interview I was supposed to test the way people thought, and how they implemented simple-to-moderate algorithms on a white board. I’d initially started out with questions like:

    Given that Pi can be estimated using the function 4 * (1 – 1/3 + 1/5 – 1/7 + …) with more terms giving greater accuracy, write a function that calculates Pi to an accuracy of 5 decimal places.

      It’s a problem that should make you think, but shouldn’t be out of reach to a seasoned developer (it can be answered in about 10 lines of C#). However, many of our (supposedly pre-screened by the agency) candidates couldn’t even begin to answer it, or even explain how they might go about answering it. So after a while I started asking simpler questions like:

    Given the area of a circle is given by Pi times the radius squared, write a function to calculate the area of a circle.

      Amazingly, more than half the candidates couldn’t write this function in any language (I can read most popular languages so I let them use any language of their choice, including pseudo-code). We had “C# developers” who could not write this function in C#. I was surprised by this. I had always thought that developers should be able to write code. It seems that, nowadays, this is a controversial opinion. Certainly it is amongst interview candidates!

    by Greg Beech

19. Design patterns are hurting good design more than they’re helping it.

      Software design, especially good software design is far too varied to be meaningfully captured in patterns, especially in the small number of patterns people can actually remember – and they’re far too abstract for people to really remember more than a handful. So they’re not helping much. And on the other hand, far too many people become enamoured with the concept and try to apply patterns everywhere – usually, in the resulting code you can’t find the actual design between all the (completely meaningless) Singletons and Abstract Factories.

    by Michael Borgwardt

20. Less code is better than more!

      If the users say “that’s it?”, and your work remains invisible, it’s done right. Glory can be found elsewhere.

    by Jas Panesar

What do you think? And more importantly, what’s your most controversial programming opinion?

Update

A few more controversial programming opinions:

• Hopefully More Controversial Programming Opinions, by James Hague,
• 12 (Really) Controversial Programming Opinions, by Bill the Lizard.

Some time ago, the development team at my firm staged a revolt against the sales team and senior management: our demand was that no Statement of Work was to be sent to a customer without first being reviewed by a member of the development team.

The message was clear: “We refuse to be held responsible to deliver on terms in which we had no say”. Today it’s not uncommon for a senior member of a development team to author a SOW in its entirety. In many ways they are better equipped than sales staff to write a SOW. They are good with documents (questionable), are very detail oriented, are great at finding loopholes, and at breaking down large ideas into small, manageable chunks. Today I would like to explore an important aspect of any Statement of Work: the pricing model.

Though there are countless pricing models in use throughout the world, the two that are most prevalent in the IT world are:

• Fixed Price (also referred to as Fixed Fee)

Both the price and the scope of work are set in the SOW and neither change without agreement from both parties. I, (seller) will provide you (buyer) with X, Y and Z in exchange for $A.

• Time and Material (T&M)

The buyer agrees to pay a set amount per hour plus the cost of materials and other expenses. I, (seller) will provide you (buyer) with X, Y and Z in exchange for $A per hour of effort needed to produced, Y and Z. You (buyer) will also reimburse me (seller) for any expenses I may incur (Hardware, travel etc.).

The major difference between these two is who bears the risk if you exceed the estimate. With Fixed Price, it’s you the IT professional who bears the risk. With T&M it’s your client. Regardless of what pricing model you choose, you will need to estimate what it will cost to perform the work (even with a T&M contract the client is going to want an estimate before signing it). As the professional, it is you who are responsible for the estimate, and logic would follow you should stand by your estimate and accept responsibility if it is off.

That said, any time you take additional risk you should be compensated for it. As a rule of thumb I would recommend charging a 20% premium on a fixed price contract over a T&M one. So the same contract under a T&M pricing model (assuming you are spot on with your estimation) will be 20% less than a fixed price one.

Based on the premise above, I propose the following: You should adopt a policy of always choosing Fixed Price over T&M unless you have a good reason not to. Before I delve into the details of what exactly is a good reason to choose T&M over Fixed Price, I want to dispel a few myths:

Myth: Risk is bad

Fact: Risk is an opportunity to make (or lose) money. It’s neither good nor bad. As I have stated above you can easily earn 20% more just by accepting the risk associated with your own estimate.

Myth: T&M pricing protects you if you exceed your estimate.

Fact: If you exceed your estimate, even with a T&M pricing model your client will fight you tooth and nail over the overage, even small overages (This is even more true in today’s world of tightened budgets). Often he will refuse to pay above the estimate forcing you into a compromise. Getting new business from this client will be substantially harder next time.

Myth: With T&M you don’t need a change control process.

Fact: You will need to show hard evidence explaining why your estimate was wrong. The only evidence worth anything is client signed change control documents that clearly outline the cost of the change.

Myth: With T&M, the client benefits if you are under your estimate.

Fact: Consulting firms will simply not leave money on the table.

Myth: Incompetency in your firm’s ability to accurately estimate is a good reason to choose T&M

Fact: Unless you are upfront with your client about your inability to estimate a project choosing this reason for T&M is unethical. You (your firm) are professionals; you sold yourself as experts with statements like “We’ve done this kind of stuff a hundred times before!” If you cannot properly estimate a project, you have no right to call yourself experts on the subject matter. If you would never tell your prospective client the real reason you are proposing T&M, your reason for choosing T&M is simply not valid, and likely unethical. You did the Estimate, you are the expert, and it’s your job to know how long it will take and what problems may arise. (I’ll say it a second time: You are a professional; accept responsibility for your estimates)

Myth: Double your estimate, just to be safe.

Fact: This myth comes in many varieties, which can range from adding 15% to quadrupling your estimate. The truth is, doubling your estimate will simply make your bid uncompetitive (or unrealistic), and you will lose the contract to a competitor. (Three’s a charm: You are a professional; accept responsibility for your estimates)

Myth: Developers don’t need to know the pricing model.

Fact: Everyone on the team needs to know the pricing model. It effects every decision the team makes that involves effort. Who is paying for the effort is always a factor in such decisions.

Okay, so what is a good reason to choose T&M? A good rule of thumb is “If you are unable or unwilling to give your client a solid estimate AND you can explain the reason you can’t (or won’t) in a way your client will understand and respect you should go with T&M”. Keep in mind that just because you can’t (or won’t) estimate a particular task, doesn’t mean that the entire SOW must be T&M. You can specify T&M for some tasks and Fixed price for others). Here are the most common examples:

• Insufficient data to properly estimate it: Your client is asking you to migrate data from an internal proprietary system to a new system you are implementing. Your client says the data is clean and properly normalized. Because you have nothing other than your client’s words to go on, your client should accept the risk of his information being wrong.

• Your client wants to take part in the project in any way: If he is providing resources (ie internal developers or another vendor is participating that the client is managing) or if you are working on site, you should go T&M. You should not be held accountable for the performance of your client’s resources where you are obligated to ensure they succeed. Chances are high that you will wind up performing this work in its entirety, while fearing to tell the client that his trusted employees are incompetent.

• Your client has a culture of excessive meetings and bureaucracy: This kind of culture tends to exist with larger fortune 500 type firms. The only way to work with this kind of client on a fixed price basis is to specify in the SOW exactly what kind of documents will be submitted and how many hours of meetings will be attended. Often the client has to do days research just to get you a list (and templates) of documents that need to be submitted in order for the system to move from one environment to another. Unless you have a history with the client this is hard if not impossible to estimate.

• Your client insists on T&M: This usually happens after you have built a relationship with your client; he trusts you and no longer wants to accept the risk and rewards (the 20% discount) of T&M.

• Your client is looking for a support contract: With support contracts, instead of defining specific work to be done, only the type of work to be done is specified, and it is performed as needed.

The last point I want to make is this: if you are bidding on a very large project I would strongly suggest that you split the project into phases with separate contracts. The first phase will deal with requirements gathering and system design. Once that phase is done, you will be in a much better position to properly estimate the effort required for the development phase.

When your estimates are accurate everyone wins.

There was a great question on Programmers about graduating with a programming degree, but not knowing how to program. I see this kind of question a lot, and I felt the same way when I first got my degree, so I thought I’d write about my experiences and what I learned when first started programming.

Start with baby steps

First off, don’t expect to be able to code enterprise-level applications or the next Facebook right away. You really can’t become a good programmer without a lot of practice, so practice any way you can. This can include hobby projects, reading books or source code, or even answering questions on Stack Overflow.

The book Outliers: The Story of Success frequently states that to become a master in any field you need to practice it for a total of 10,000 hours. In case you don’t want to do the math, that’s about 3.5 years of programming 8 hours every single day. If you only program during business hours at work, that’s almost 5 years.

Don’t discount your education

When I first started working, I felt my education was worthless; that it just taught me stuff that was never used in the workplace. I soon realized it provided me with something better than syntax: it provided me with a good foundation for programming. For example, it didn’t teach me design patterns, but it did teach me what design patterns were and how / when to use them. And I might not have built a data access layer in my class projects, but I knew what they were for and when to use them.

It also provided me with resources such as books, an online library, and networking contacts in the industry. In addition, it gave me a fancy piece of paper which can be very useful for getting your foot in the door when you don’t have experience.

Of course, it didn’t teach me everything. Looking back, I wish I had been taught about things like Version Control and Unit Testing. But the institution did their best to provide me with a solid foundation to build upon in the short time I was there, providing I was willing to go out there and keep learning.

Always be learning

One of the first things I got taught in college was that to be an IT professional, you really need to be a life-long learner. You can’t just graduate and expect you’ll have everything you need to get a high-paying job for the rest of your life. You’ll need to be willing to spend the rest of your life learning new technologies and languages.

Whenever I come across something new, something I don’t understand, or something I’m not sure of how to do, I Google it. Most of the time I can find a simple definition or samples, and I can start from there. If I do start from samples, I hate just blindly copying/pasting. I always take the time to understand what the code does. It might be slower to start with, however once understood it makes me that much better of a programmer.

Remember, N years of experience means nothing if it was simply 1 year repeated N times. There are plenty of jobs out there that are that will let you accumulate years of experience without you ever needing to learn anything new, however I feel you simply cannot be a great programmer without continuing to learn.

Steps to success in programming projects

Here is a list of steps to success in any project as a new programmer:

• Be positive when asked if you can do something.
  
  

  If someone asks you if you can do something, be positive in your response. Answering negatively, or even indecisively, will often result in a lost opportunity to learn and grow, so avoid that unless the task is truly outside the realm of possibility.

  I usually use terms like “I don’t see why not” or “shouldn’t be too hard”. You may not know how to do it right away, but you should have the tools (Google!) and intelligence needed to figure out how to get it done. I like to avoid actually saying “yes” unless I know I can actually do what is being asked.

• Determine requirements.
  
  

  Sit down with your client (boss, customer, etc) and figure out what they want. I’m not going to go into details of gathering requirements here, but do take the time to draw out the screens they expect to see, and to determine the expected input / output. My favorite tool for screen mock-ups is Balsamiq.

• Figure out how to build it.
  
  

  This is one of the most important steps. A huge part of programming (especially early on) is figuring out what your client wants, and then learning how to do that. Don’t just stick with your own knowledge base!

  For new programmers, I would suggest just focusing on just getting the desired results. Don’t get bogged down trying to learn design patterns, architecture, test-driven development, etc. Learn the basics of how to program first, then expand on that knowledge. And remember, keep it simple! You don’t need an enterprise-level solution for the FizzBuzz problem.

  At this point, if you determine that the project is completely out of your scope, say so. Even if you determine the project is far too large or complex for you to build, you will have at least increased your own knowledge, so I always see it as a win-win situation.

• Build it.
  
  

  You might think this is the hardest step of all, but in reality it will eventually become one of the easiest ones. Gathering the requirements and figuring out how you’re going to build the application are much more important, and if done right, it will make this step a breeze.

  Of course, early on in your career this step will be the most time-consuming and frustrating one. It will likely consist of a lot of trial and error, but don’t be disheartened because this means you are learning! We learn much more from our mistakes than from our successes, and the more you learn, the better your programming skills will become.

Summary

So to summarize, don’t worry too much about not being able to build/understand enterprise-level applications straight out of college. Start small, and keep an always be willing to learn. Work on programming for results first, and worry about best-practices later on. Hobby projects are a great way to gain experience. And remember, don’t ever stop learning!

Students programming in main room

Each year the Belgian Microsoft Innovation Center (MIC) runs a program to introduce future graduates in software development to local startup companies. The students come with their enthusiasm and eagerness to learn; the Startups arrive with innovative and exciting projects and the MIC provides the infrastructure and support. This year I had the pleasure to manage 24 students over 19 projects. I’ll explain how we did it.

In addition to the equipment necessary for project implementation (laptops, office, subscriptions, software, etc…) we organized many activities. The purpose of these activities was to increase significantly the level of our future developers’ professionalism while ensuring the proper conduct of the projects for our local businesses. These activities included among others: training, collective code reviews, coaching and each trainee had to give presentations.

Training

Controlling a claw built with Lego Mindstorms with his mind using Emotiv Headset

There was nothing very special about the training except the emphasis we gave to interactivity. One thing we noticed was that instead of covering new topics we were trying to complete the learning that students had achieved during their studies. Here are some of the topics we covered:

• Coding guidelines
• Source code controllers (We used Mercurial on BitBucket.org)
• Unit Testing
• Design Patterns
• C # in depth (inspired by the book of the same name)
• Agility in general
• Scrum in detail
• Effective Logging & debugging
• Basic concepts of project management software such as backlog management

We believe that these issues need to be fully integrated into university/college curricula. This would allow us to focus on even more advanced subjects.

Collective Code Reviews

a Collective Code review session

I regularly organized what we call a collective review of the code. This does not mean that everyone read all the code – that would be inefficient.

I read each trainee’s code and when I came across a problem, I would put a screenshot on a powerpoint slide. The next slide was a copy of the previous slide but with arrows showing the errors and a third slide was a screenshot of the code as I would have liked to have seen it. One type of error was added to the presentation once. For example, “poor management of exceptions” was examined only once even if it was a widespread problem found in most projects.

All the students would gather in the conference room to see the presentation. For each problem the first slide is shown so that the group could review it and identify potential problem with the code. Very often, one of the interns suggested the right solution straight away. The slide that highlighted the errors was then displayed and a discussion took place. Finally an example of corrected code was shown (third slide) so that everyone would get the benefit of the “lesson”.

Occasionally, good practice was suggested which always generated discussions and suggestions.

The learning method proved very effective. Students loved the performance aspect since it is very interactive and it always close to the problems they face.

Coaching

A student programming Nao

In addition to formal learning, intensive coaching has been implemented. At any time, I could intervene to help trainees to advance the project. I was fully dedicated to that during the whole period. They also had the opportunity to come and see me to ask technical questions whenever they could not find a solution online in less than 10 minutes (on Stack Overflow for example). Rather than handing out fish, the technique of coaching was to teach them how to fish. We placed an emphasis on developing the student’s capacity to learn while giving them the ideal conditions for the rapid acquisition of new knowledge. Coaching also included informal learning and covered all the things that are more difficult to cover during presentations to the group. Here are the different subjects which have been covered:

• Continuous integration
• Blogging
• The use of a project tracking tool (we used Trello see below)
• How to write an effective resume
• How to interview
• How to gain certifications (Microsoft ;))
• The attitude to adopt in the business environment

The last point was particularly important to me. Throughout the internship, I stressed the one point that I think will make the difference between them and other developers: the ability to solve problems and not create new ones.

Project Monitoring

A team using Trello with the Microsoft Surface

Managing the project was a very important part of the project. In fact, following 24 people in 19 projects is not an easy task. We naturally chose to set up Scrum and used a task management tool of the kanban type. Trello was chosen for its ease of use.

We formed four “virtual” teams based on project similarities, included in these “virtual” teams were two real teams of 2 or 3 people, Alongside our desire to maximize the output, we had a secondary objective to get the trainees to live Scrum and agility in general through real scenarios, some exactly as in a large company. So we had the daily scrum, the sprint review, the retrospective and a lighter version of the sprint planning.

Scrum has proven very effective in this type of program. We plan to integrate even more companies in the process. Although I took the role of “Product Owner” on this occasion we think it would bring more if the course tutors played this role, after training.

Trainee presentations

Students had the opportunity to prepare and make presentations to the group of students. These presentations were in addition to what was originally planned in the program and has allowed the students to practice the art of presentation but has also allowed them to share their new learning with the other trainees. Subjects covered were:

• Introduction to HTML5
• MEF (Managed Extensibility Framework)
• Work with Blend interfaces
• Introduction to Windows 8
• Introduction to XNA
• Introduction to ASP.NET MVC
• Deploy a WCF service in Azure
• Object Mocking
• Get organized with GTD
• The pattern MVVM
• Introduction to Programming Kinect
• Which company to choose?
• Introduction to Silverlight
• Debugging with Visual Studio.

We believe that a great developer must learn to communicate his knowledge and this exercise is therefore one of the things we will continue in the future. Indeed, in addition to these presentations, we encourage our trainees to develop a presentation video by making the appropriate equipment available. In business, those who are able to communicate well are often those to whom we entrust the most responsibility.

Conclusion

Programming the Kinect for Windows

How will we know if this program will lead to better performance from the students in comparison with other internship models? That’s the question we asked ourselves last year.

This year we have developed a proficiency test that measured several dimensions that we believe a developer must master. As we predicted, the score at the start of the program was pretty bad. At the end of the course this score had, on average, doubled!

Despite this result, we cannot say today that our program will have had an effect significantly superior to another approach, simply because we did not have a control group. We hope to do this in 2013.

I sincerely hope that other companies will be inspired to create a similar program within their specialism. I am also very interested in any form of feedback or to hear of your experiences – you can contact me in the comments.

You can see a video introduction to the program here.

In addition, one of the project participated in the Imagine Cup 2012 and you can watch the video here.

Programmers have to work with large amounts of bad code. Sometimes its your own code, but other times its another programmer’s code. If you have to frequently work with another programmer’s bad code, you will eventually wish to approach them about their code quality, however how to do this without causing offense or resentment is not always easy. This article is about the approach I would take when wanting to casually talk with another programmer about their code quality.

Determine the problem

First off, determine what exactly the problem is, and verify that it is worth bringing up. Ask yourself:

• Do you work with this person on a regular basis?
• Will you be working with, and maintaining their code in the future?
• Is this an actual problem that harms productivity, performance, or security, or is it simply a case that your preferences are different from theirs? For example, simply complaining that “your naming convention doesn’t match mine” is not a very good reason, however saying “your naming convention makes it hard to understand what is going on in the code” is a much better.

If you answered yes to all of those, then it sounds like you might have a good reason to approach someone about their code quality.

Gather your arguments

Once you’ve determined there is a valid reason for trying to change the way another programmer does things, get your arguments prepared. Identify why the code is harmful to the development environment, and figure out the ideal way of coding it instead. Pick some code samples illustrating the problem, and write your own way of coding the same piece. Determine what your arguments are for why your code is better than the existing code sample. Don’t use arguments such as “it’s best practice”, but instead explain why it’s a best practice (readability, maintainability, reusability, etc)

Approaching the other programmer

Now that you know your arguments for why you think your code is better than theirs, and have a clear idea of what the ideal code should look like, arrange a time to talk with the other programmer.

This could be a casual conversation, or it could be setting up an appointment to talk with them about your concerns. How you choose to approach your co-worker is based on your level of comfort with them, the organization’s environment, and both of your ranks within the organization. For example, if I wanted to talk to the programmer next to me, I might simply ask them if I could have a moment of time whenever they’re available to talk with me about a piece of code, however if it’s my boss, I might send him/her an email asking if I could setup a brief meeting with them to discuss some code I’ve been working on.

Some people might argue that approaching a boss is different than approaching a co-worker, however I feel they are both people and both deserve equal respect. The only real difference I see is that your boss’s time is usually more valuable to the company, so be aware of that when talking with him/her.

What to say

When you actually talk with the other programmer, I usually find a good way to start the conversation is to ask them to explain their code. Ask if there was a reason for their style of coding, or tell them you’ve never seen something coded that way, and ask them why they chose that method. Really listen to what they have to say during their explanation. It could be that their way is right, and you are wrong, in which case take notes and learn from it!

If you still think the code is bad and worth changing, show the other programmer how you would code the same piece of code, and tell them why you would code it that way over his/her way (better performance, fewer chances of errors, easier for other programmers to read/maintain, etc).

Focus on why your method of coding is better, and not why their method is worse. Nobody likes being accused of writing bad code, although in reality we were all new once and I’m sure we’ve all written some horrendous code at some point in our lifetime. Be sure to keep the conversation focused on the code, and avoid turning it personal by talking about the person who wrote the code. It is always best if you can show that you understand that sometimes bad code gets written, whether it was due to time constraints, inexperience, or simply a bad day.

In addition, don’t try and get them to change their old code (unless you are their boss and want them to spend time doing so). Your goal is to educate them so they stop making the same mistake in the future, not berate them over past mistakes and punish them by extra work.

Afterwards, see if he/she still supports their coding style over yours. If they are open to improvement, they will likely change their way of coding going forwards. But if they still prefer to use their coding style, you are not likely to change their opinion, so drop the subject and don’t bring it up again unless their code is actually harmful.

Conclusion

Remember, nobody can write perfect code, and good programmers are always looking for improvement. The world of programming is so big that its impossible to know everything. It’s very likely that the other programmer doesn’t know there is a problem with their code, and would appreciate the input, providing you do it in such a way that you are teaching them, and not insulting them.

So don’t be afraid to approach another programmer about their code quality. I know I would appreciate the conversation, and I think you would too.