Note: This is Part III of a three part series; it is recommended that you read Part I – The Basics & Part II – Marketing first. 

A quick Re-cap

I previously defined the Job search Sales phase as “Direct contact with a potential employer where, building on your marketing, you sell yourself as the perfect candidate for the job”. This is everything you do from the moment you get a person on the phone discussing a specific opportunity and afterward.

Also previously stated is that the Sales process looks something like this:

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

Sales is a direct extension of marketing, the key to success in the sales phase is to back up everything you said thus far and then surpass it. If a potential employer is talking to you, it’s because he is interested what you said thus far and wants to hear more. Specifically they have two questions they want answered:

1. Do you really live up to your “hype”? i.e. What you claimed as part of your marketing.
2. Do you meet all the unwritten requirements?

Most interviewers suck at interviewing, I mean they just really stink at it. By that I mean they simply have no clue as to what they are doing. And when I say “Most” I mean “All”. When it comes to interviewing nobody knows what the f* they are doing. They rarely put any effort in choosing the right questions to ask, and don’t spend any time thinking about what they expect to learn about the candidate by asking those question. They will routinely interview 5 people (ask each of them and entirely different set of questions) then pick the “Guy who worked for Google”, even though they build POS Systems because obviously “Google is better at picking good people then we are”. They ask questions about skills that can be learned in less time than it takes to answer the question, Then disqualify the applicant for answering incorrectly (because they failed “the test”, this is a direct result of not thinking about what to ask and why).

Interviews are conducted by people with no training and no (or little) planning. Unfortunately this is just a fact of life; there is not much you can do about it. You are going to interview for jobs, and you will be rejected for no good reasons. Understanding this is critical, accept it as fact; and don’t let it affect your confidence.

The hiring process can be summed up as follows: Phone screen\ interview a bunch of people based off their marketing material, and then go with your Gut. (It’s a well-documented fact that employers will choose drinking buddies over talent). As flawed as this process is, it actually works surprisingly well.

Getting back to the two questions: Question one is an honesty check asking “Is this person lying?”. For question two, the interviewer doesn’t even know what the unwritten requirements are, and isn’t even conscious he is asking himself this question. These two may look like different things but they are not, simply stated likeability is the single most important unwritten requirement. If the interviewers like you, and clearly see that you meet all the written and unwritten requirements, you will get the Job (because their Gut will tell them that you are the right person for the job). Nobody likes a liar and nobody hires people they don’t like. Well most people don’t like liars…

<StupidStoryAboutIntentionallyHiringALiar>

While working for a professional services consulting firm, I was asked to help out with the technical assessment of a candidate. So I join the VP, practice manager and the candidate in the conference room and told the candidate “I want to get a good understanding of your level of knowledge of the different aspects of product X, so I am going to ask you a whole bunch of questions where you will get things wrong, that’s ok, nobody could know all this, don’t let it throw you off.” Asking him about one particular advanced feature of the product, I asked him “Have you ever configured feature X”, the candidate responded “Many times!” I say “Great, tell me how the feature works”, he then proceeded to give me a very plausible answer, good if I was asking him to design such a feature, yet entirely wrong in terms of how it actually worked, making it clear that he never configure or even used this feature, not once.

After the interview, in discussions with the VP and the practice manager, I expressed by concerns of the candidates ability (and audacity) to lie with such confidence.  To my surprise their reaction was “That’s what consultants do!! He’s a natural!” he was offered the job and accepted. (I eventually became good friends with the candidate as we worked very closely together. He’s a good honest guy overall) this is the kind of thing people talk about when they talk about “Cultural Fit”.  The VP and practice manager simply liked him.

</StupidStoryAboutIntentionallyHiringALiar>

The important thing to remember about unwritten requirements is that just because you may not be asked about them doesn’t mean you won’t be judged on those requirements (Subconsciously by the interview’s gut). If these requirements are not addressed at all, it will count as a strike against you. This is particularly true if another candidate does address them directly, forcing them out of the interviewer’s subconscious.

So what are the Unwritten Requirements?

Here is a list of the most common unwritten requirements:

1. Likeability – Likability, nobody hires people they don’t like
2. Honesty – We already covered why this is so important.
3. Communication Skills – Solid Communication skills are a MUST.
4. Confidence – being confidant demonstrates your ability to do the work. It also goes a long way to likeability.
5. Enthusiasm for the Job – Nobody wants to work with a miserable f*. Also if you like your job you are more likely to stick around a few years
6. Salary- Will you be happy with the salary?
7. Cultural Fit – This is very similar to Likeability, but extends to the working environment. (ie. Structured vs unstructured environments)

The rest of the unwritten requirements vary from job to job, you should be able to figure most of them out when you are analyzing the requirements to put together your elevator pitch (See Part II), the rest you’ll have to figure out along the way.

Make first (direct) contact.\Recruiters\HR

First direct contact is really a transition phase between Marketing and Sales, I discussed most of what you need to know previously. Everything previously stated stills hold true: you have 3 basic goals: (See Parts I & II)

1. Learn more about the position
2. Pitch your elevator pitch
3. Discuss next steps.

If you are dealing with a Recruiter

Dealing with recruiters is a marketing activity; treat it as such, that means you need to focus on efficiency. Never go out of your way to meet a recruiter in person. If they insist, offer a Skype interview, if they turn that down, politely tell them you just don’t have the time, and pass on the opportunity. (If they offer to come to you, accept)

If you are dealing with HR

Remember your 3 basic Goals; this should get you a phone screen with the hiring manager. Send a thank you letter to HR personal after speaking with them.

The Phone Screen

The phone screen is conducted by the hiring manager or a member of his\her team. This is the true start of the sales process. Insist on a phone screen even if you are offered an in person interview off the bat. (Say something like “Would it be possible to have a brief conversation with the hiring manager prior to coming in? I think that will go a long way in making the in person interview more productive.” – I have never had someone say “No” to this.) The Phone screens serve two purposes:

1. Confirm what you heard from the recruiter and \or HR, and determine if you are still interested
2. Prime the Interviewer for the in person interview

Get Confirmation of the details: The recruiter’s and HR’s goal is to get the position filled. The hiring manager’s goal is to get the position filled with a qualified candidate (in terms of written and unwritten requirements). Because qualified is something only the hiring manager cares about, often the Recruiter and HR “fudge” things to get you more interested. For example recruiters will tell you there is tremendous room for growth, or lie about travel requirements thereby increasing your Enthusiasm for the Job (an unwritten requirement) this is the time to set the record straight.Remember you are screening them too, if you are not happy with what you are hearing don’t waste your time with an in person interview.

Priming: The fact of the matter is that external forces effect how people think of you. If you are being interviewed 20 min after the interviewer got a raise, he\she will be in a good mood, and that good feeling will be somewhat transferred to you. If the interviewer just got reamed out by his\her boss because the server crashed and now the interviewer has to waste 20 min talking to “another looser candidate” you haven’t got a shot in hell of landing that job.

By priming the interviewer during the phone screen you are taking control of the interviewer’s first impression of you. He\she can’t see you so all his\her superficial biases are out, and he\she is left with nothing to judge you on except for content under your control (Assuming you don’t have a heavy accent).  Now that you control the picture, you can push the messages you want to get through: you have the expertise and experience they are looking for (your elevator pitch), and you are a great person to work with (your likability). You want to leave them excited about your candidacy and looking forward to meeting you in person. (Priming goes a long way in effecting someone’s Gut feelings toward you)

While on the subject of priming and likeability, here’s a Random tip: : Lighten the mood from hello, and keep the energy level up. Because of basic phone protocol, 98% of phone interviews start with “How are you doing?” This is great chance to lighten the mood, answer with “Great!” followed by some silly anecdote explaining the “Greatness of the day”, that gets the interviewer smiling. Score #1 on the likability scale plus puts the interviewer in a happy mind set.

Send a thank you letter after the Phone Screen.

The in Person Interview

If you did your job right during the phone screen they should be excited to meet you in person.

Here are my best Interviewing Tips: (Many of these also apply to the Phone Screen)

1. Dress Like an Oracle DBA – (Unfortunately some people still don’t get this)
2. The night before, review the requirements and all your notes, go through each and every requirement and think about how you experience can be transferred to meet that requirement. Research the company’s and understand their business model. that the Take your Elevator Pitch expand that out into a comprehensive Pitch covering every single written and unwritten requirement. If you don’t have a solid answer to how your experience relates to a requirement you had advanced notice of, shame on you, there is no excuse for this.
3. Know who you will be interviewing with : Research them (Check LinkedIn and Google them). Know their role in the company. That will tell you who are the real the decision makers are. It will also tell you who cares about which requirements. (I.e. The technical people will be judging your technical skill, Business people what to know that you understand the industry and that you are someone the can work with. Your would me manager wants to know the he can put you in front of a business user\client without having to worry you embarrassing him)
4. Build a Targeted story: At some time during the interview you will be asked to “Tell us about yourself”, be prepared for this, you should be able to start at the bottom of your resume and tell the story of your career, at each stop along the way (Every job change, every role change, every promotion) tell how you grew as a professional better preparing you for the job you are currently interviewing for.  For every position you should explain how that experience relates to the job you are applying for. (targeting specific written and unwritten requirements, the full bullet list created as part of your marketing strategy will come in handy here)        
5. Bring Print outs of everything.
   
   • The job ad
   • The cover letter you sent
   • Copies of your resume on resume paper
   • A copy of the Email that has the interview location and time
6. Arrive early, stop at a Cafe and review the requirements and your pitch, make sure you can pronounce everyones names, use the bathroom, chew some gum, and relax your nerves. Arrive at the interview location 5-10 min early.
7. Let them talk first, again tweak your pitch, if necessary
   • Start high level and go into details when asked.
   • Details are the key to believability and they show your breath of knowledge. This is how you showcase what you can do for them
   • Ask question that demonstrate your understand the business they are in, and that you know what they are looking.
8. Reinforce likeability
• Smile and joke a bit, mock there procedures if you can pull it off!
9. Ooze confidence, borderline cocky. This demonstrates talent and adds likability.
10. Communicate clearly. If needed ask for a few moments “To find the right words” (Avoid thinking sounds, “umm”, “err”, “uhh”, “Like, you know”.. it’s better to pause silently, this takes some practice)
11. Focus on the written (core) requirements but also remember the unwritten requirements
12. Think about the intent of every question; ask yourself “what are they really asking here”?
    • Answer both the question and the Intent, if you don’t know, ask what the intent is.
    • If you answer only the intent you look like a Politician avoiding the question, also you may be wrong about the questions intent.
    • Example: if the interviewer is asking “At your last job did you use Erwin?” The interview is really asking “We use Erwin here, how comfortable are you with it?” – Infer your experience (SPIN Selling) Remember your Bullet List! (Again see Part II.)
13. Understand the Difference between Elimination Questions & Qualifying Questions
    i. Elimination Questions – The sole purpose of these is to eliminate you as a candidate.
    • Answer briefly, details can only hurt you.
    • Example: “Why did you leave your last job?”
    • Most technical questions are Elimination questions. All “Have you ever” Type questions are Elimination questions
    ii.      Qualifying questions
    • Here details are your Friend! Remember- Details are the key to believability and they show your breath of knowledge. This is how you showcase what you can do for them.
    • All “Have would you” Type questions are Qualifying questions
14. Watch out for Trap Questions – These questions leave you with no clue as to what is the “Right” answer, the key here is to identify the intent of the question and then infer your experience. (Again see Part II!)
    • Example “What Methodology did you use on your last project?” –Correct Answer “We use Methodology Y, What do you use here?” – “We use X”, – “We Considered Methodology X but it wasn’t the right fit for us because of ABC, Methodology Y fit better because of XYZ. I did use Methodology X a few years back when I was …” – Trap avoided, and you get to showcase you knowledge of different methodologies!!
15. Wrap it up!
    • Ask for the Job! – Express Interest
    • Reiterate why you feel you are a strong candidate – remember your elevator pitch!
    • Thank them
16. Ask about Concerns – Toward the end of the interview ask “Do you have any concerns about my Candidacy?”, This gives you an opportunity to address those concerns directly, plus this info is invaluable during your postmortem analysis. (If you don’t get this info during the interview, you will never get it.)
17. Ask about Next steps
18. Send a thank you letter

If you are unemployed

There is a horrible trend now days, where employers think that if you are unemployed you must be an untalented lousy employee. This has gotten so bad that here in NYC a law was passed making it illegal to reject a candidate because he\she is unemployed. Studies have shown that employers are more likely to hold long term unemployment against you then they would a criminal record. I hate to say it, but I think IT shops are the worst offenders. This is a despicable practice and truth be told employment status does not gauge talent or work ethic in any way. Because of this, if you are recently unemployed and it is feasible I recommend you lie about being unemployed. I know I’m going to take flak for this, I don’t care; I think lying is justified in this case.

The Offer

Congratulations! If you did a proper job qualifying the lead the offer should be in the ball park of what you expected. If it’s not, you need to reevaluate your lead qualification process.

Negotiation

See: Managing your Career in IT

Postmortem

As I stated above you will not be offered every job you interview for. That’s ok, the key is to understand why, learn from your mistakes and adjust. This holds true for just about everything in life.

Recommended Reading
The Hoboken Chicken Emergency

As a veteran of applet development (see credentials below), I think it is high time to make a call that teachers should stop teaching applets in general, & especially AWT based applets. Applets are an advanced and specialized type of app. that has little place in the real world around us (most things that are done by applets can instead be better achieved using Javascript and HTML 5).

It saddens me to see new students ‘tossed in at the deep end’ to learn how to make an applet.

The reasons are multiple, but first, I’ll look a little at the history of applets and why applets were ever considered a good idea for teaching small, simple projects.

Applet vs. Frame

The simplest applet is:

import java.applet.Applet;
import java.awt.Label;

public class HelloWorldApplet extends Applet {

  @Override
  public void init() {
    add(new Label("Hello World!"));
  }
}

Looks simple, right? This hints at the primary reason that applets were taught.

It only takes a handful of code lines to see the end result.

But an applet gets a size & position on screen from the HTML that loads it. So an applet also requires a little HTML E.G.

<html>
<body>
<applet 
  code=HelloWorldApplet
  width=400
  height=200>
</applet>
</body>
</html>

This makes the total for a working applet 17 LOC. Not looking quite so simple now. Worse, many developers think ‘any old mark-up will do’ when that is very much not the case. Missing opening or closing elements make the HTML invalid and how a browser will interpret it is anyone’s guess.

Compare that to an application that behaves in as smooth a manner:

import java.awt.Label;
import java.awt.Frame;


public class HelloWorldApplication  {

public static void main(String[] args) {
    Frame f = new Frame();
    f.add(new Label("Hello World!"));
    f.pack();
    f.setVisible(true);
  }
}

So, while it takes just 9 lines of code for the simplest of applets (even including the @Override notation), while 12 LOC for the application doing the same thing, add the HTML and it becomes 17 lines for applet/HTML vs. just 12 LOC for the application.

AWT vs Swing

Time moves on, and the Swing component toolkit was introduced as a replacement for AWT. Nobody uses AWT anymore. Most Java GUI developers started using Swing, and those that have used AWT have largely forgotten the finer details.

This is relevant to the student in terms of getting help when they get stuck. It does not matter who we are, when approaching new areas of CS, we all tend to reach for whatever resources might help us understand the new technology. For a student the best resources are firstly the text books and class notes, but those typically only go so far at explaining, and the rest is from things like the JavaDocs, the Java Tutorial, searching the net, or asking for clarification on forums.

Those last two are particularly relevant in that:

• There is a slew of extremely poor AWT based code available on the net.
• There may also be some poor Swing based code out there, but usually there is a Swing programmer nearby that can point out the deficiencies in it.

Industry uses Swing and that is all that Swing programmers know and remember. AWT is obsolete, and a dead end in career or learning.

So let’s now look at the proper way to write a Swing applet & application. The Java Tutorial warns us that all Swing code should be started and updated on the Event Dispatch Thread, which (ironically) is an AWT based Thread.

A simple Swing applet might then be:

import javax.swing.JApplet;
import javax.swing.JLabel;
import javax.swing.SwingUtilities;
import java.lang.reflect.InvocationTargetException;


public class HelloWorldApplet extends JApplet {

@Override
  public void init() {

@Override
Runnable r = new Runnable() {
  public void run() {
    add(new JLabel("Hello World!"));
  }
};
try {
  SwingUtilities.invokeAndWait(r);
} catch(InterruptedException ie) {
  ie.printStackTrace();
} catch (InvocationTargetException ite) {
  ite.printStackTrace();
}


}
}

This is slightly verbose (25 LOC) for strict clarity, but could be reduced to:

import javax.swing.*;


public class HelloWorldApplet extends JApplet {

@Override
  public void init() {
    Runnable r = new Runnable() {

  @Override
  public void run() {
    add(new JLabel("Hello World!"));
  }
};
try {
  SwingUtilities.invokeAndWait(r);
} catch(Exception e) {
  e.printStackTrace();
}


}
}

It could be further shortened (from 20 LOC) by declaring the Runnable inside the SwingUtilities method call, but I find that notation to be confusing & prefer to separate the Runnable into a clearly defined instance.

And now the Swing equivalent application, using the same ‘short guidelines’.

import javax.swing.*;


public class HelloWorldApplication {

public static void main(String[] args) {
    Runnable r = new Runnable() {

  @Override
  public void run() {
    JFrame f = new JFrame();
    f.add(new JLabel("Hello World!"));
    f.pack();
    f.setVisible(true);
  }
};
SwingUtilities.invokeLater(r);


}
}

Just 18 LOC in total.

Not very much coding to see our simple message on screen, in a free floating Swing component.

Embedded vs. not embedded

Security

Why won’t the applet load my input file?

By default, Java applets run in a security sand-box that prohibits many actions which might be damaging to other applets, the browser or the user’s machine.

While the security sand-box is of great benefit to end-users, it makes the life of the developer difficult. And it has just become that much more difficult in Java 7 update 21.

In Java 7 Update 21 Security Improvements in Detail Markus Eisele notes:

With the introduced changes it is most likely that no end-user is able to run your application when they are either self-signed or unsigned.

While that warning is a little extreme, I agree with the underlying point being made. A user (or in this case you, the teacher) will need to OK some very scary dialogs, and possibly lower the default Java security to an unsafe level, before being able to view an applet.

Error reporting

My applet is broken but shows no errors! Where are they?

The System.err stream used for displaying stack traces appears on the command line (or in the IDE) when running an application. When a stack trace occurs in an applet it is sent to the Java Console, which is (by default) not configured to be shown.

Class caching

I changed my applet but the browser shows the same!

Many times I have responded to applet problems where the questioner swears they have changed the code & recompiled it, yet the browser is still showing the old values. The solution is relatively simple when you know how – flush the class cache from the Java Console. To someone learning, it is typically a complete mystery.

Embedded conclusion

Those 3 problems alone have probably earned me a quarter of the reputation points I’ve so far gained for applets on Stack Overflow. They pose huge problems when developing and debugging applets.

Conclusion

The question really comes down to:

Are you teaching Java/CS or how to deploy applets?

If the former, use JFrame based applications and side-step all the problems that are inherent to an embedded app. And don’t even consider teaching AWT components – they are obsolete & Swing takes only a few more LOC to get something on-screen.

Author Credentials

So who am I?

• Top ranked provider of answers on Stack Overflow for the applet tag.
• The developer of Appleteer.
• Host of many applets on my site.

So you’ve been working as a programmer for a couple of years, and you want to become a good programmer. But not just a good programmer, you want to be a GREAT programmer. You want to paint with ALL the colors. Hell, you want to paint with all the dimensions. You want to be the GURU of programming – not just some nerd that’s stuck in corner that knows every namespace in the .NET API and can punch out a website in a day – you want to be a Michelangelo. A Picasso. Programming isn’t a science, it’s an art. You want to be respected.

Boy that’s a big ask.

So how do you get started?

By now you’ve hopefully realized that what makes good programmers great isn’t necessarily their technical skills. Your technical skills can be AWESOME, but if you don’t know what your customer wants, they amount to diddly squat. Of course if you know what your customer wants but don’t have the technical skills to back it up, you’re also up the creek. So what are the technical things you want to learn?

* How to write “DRY” code. DRY stands for “Don’t Repeat Yourself”. Copy and paste coders are not real coders. If you find yourself writing the same (or similar enough) lines of code more than once, it needs to be cleaned up so that you don’t have duplicate code all over the place. This will actually keep your codebase smaller, easier to maintain and reduce your bug count. People call this refactoring and it’s a daily part of our job. It’s not an optional extra for the end of a project.

* How to keep it simple. Once you’ve got the hang of refactoring and cleaning up your code as you go, you’re going to have to learn the next principle of keeping it simple. Too often once programmers have got it into their head that they need to not repeat themselves, EVER, and so many code bases grow to be an abstracted monstrosity. I’ve seen huge heaving code bases that take minutes to compile, but the application itself hardly does anything. Keeping things simple above all else is your goal.

* Learn the principle of YAGNI. You Ain’t Gonna Need It. All too often as programmers we want to make sure that we cover all our bases. The customer has asked that the application is to do X. If that’s the case, then they’ll probably want it to do Y and Z too. We might as well spend another 3 days putting that in, after all they’re going to ask for it anyway. Once again, you end up with a much bigger codebase and app than you need, and half of the code in there isn’t being used. Keep it simple!

This can be a very difficult concept to master. Making your solution flexible, customisable and forseeing future requirements is a very important part of our job. This is where I think that programming can be shown to be an art – there’s no hard and fast rule here. Ultimately it’s up to the programmer(s) discretion over how flexible a solution is – it involves constant judgement calls and a weighing up of the pros and cons. Normally the questions that you want to ask yourself are:

“How much extra work will it be to make this more flexible?” vs

“How much time do we have?” vs

“Will they really need it?” vs

“is this making the code worse or better?”

These kind of questions are very difficult to answer on your own. Two heads are so much better than one! Often just talking through the problem and the solution with another guy can help you work out the right approach yourself. Even picking up the phone to call another programmer to see what they think can save you a lot of pain.

* How to constructively review other people’s code. Code reviews can send a shiver down the spine of the most experienced programmer. They can be harrowing, aggravating and an ultimate waste of time. They can also be a delight, an opportunity to learn from others and to improve your skills! The most important aspect of code reviews is not what technical details you are looking out for, but the attitude and expectations that people approach the review with. If you’re dying to bag out someone’s code and make them feel bad, if you’re on the witch-hunt to see how many bugs you can find, then you’re going to be in trouble. People will resent these code reviews, nobody will want to help anybody else and most importantly, your code will not get any better!

The approach that you want is for everybody to go in with the mentality that “we’re here to learn from everybody else and to improve the code”.

* Design patterns. Reading the classic book on design patterns can give you a lightbulk moment – “oh, THAT’S how I solve that messy coding problem”. The danger that most people have is overapplying design patterns and you end up with a bigger mess than you started. Once you’ve learnt how to use a hammer everything starts looking like a nail. So don’t overzealously use them for the sake of it.

* Keep up to date with frameworks & libraries. You don’t have to use them, but you need to know what they do and their pro’s & con’s. A great example of this is SignalR - before this came along I would have been adamant that there is just no way that you can easily do realtime notifications within your web application. Turns out that before signalr there were libraries like pubnub who do this kind of thing with ease – but I had no idea! If I hadn’t kept up to date I could have been the one spouting rubbish (well, more often than usual, anyway). Keeping up to date with libraries and frameworks will also show you how if something seems way too hard to do then there’s probably (hopefully) a much easier way of doing things. Don’t write your own service bus layer when there’s MSMQ.

* How to comment your code. If you’re not commenting code then you’re making your life more difficult. When you come back to that function you wrote 6 months ago you’re not going to have a clue why you wrote it in such a convoluted way. Hey, it turns out that you did it that way for a reason! And BTW you shouldn’t simplify this mess because you’ll actually break it!

You also want to learn how to write down that complicated algorithm in a flowchart or just write it out in english. Don’t expect that someone will spend 2 days trying to reverse engineer your code. Don’t expect that people in the business will learn/remember/understand that complicated logic that they asked you to do. You’re going to end up pulling out this flowchart in at least 3 meetings in the future whenever people say “So what happens when x happens and then y?”

* How to write unit tests. Writing tests is a great way to ensure that your code will continue to work, even when some dufus comes along and modifies the database schema without telling you. Okay, well your code definitely won’t work, but now you can catch it the very day that someone renames a column. Instead of catching it three weeks later and finding out that your application hasn’t been calculating numbers properly. You’ll also want to learn what TDD is and see if it’s a good fit for you.

* What dependency injection / IOC is. A contentious argument for sure, but one you want to be well informed of. It’ll also give you a massive leg-up on when you see your first project that uses DI. If you don’t know what’s going on, you’d swear the code is backwards and insideout.

* How continuous integration is your saviour. I can’t imagine working on a project these days without CI. If I didn’t have a build running everytime someone checked in some code I would be quite terrified. It’s your safety net, your progress indicator and your one-click deploy solution all in one.

* Know what’s going on under the hood. For example, calling a web service – what’s it actually doing? If it’s WCF it’s creating a SOAP service call – you should check out the actual data that is sent over the wire sometime. It’s massive. If I hadn’t peeked under the hood I would have had no idea just how much bandwidth it needs. When it comes to programming, nothing just happens magically.

* Learn the gist of quite a few programming languages. You’d be surprised what you can learn from other areas. If you don’t know how simple python is nor how easy a web application is in ruby on rails, then you’re only seeing one side of the coin. If you’re coming in from strictly typed languages then javascript is a bizarre world in itself! I’m a c# developer and I’ve found that java guys think very differently. So do PHP people.

* Peter Rowell has a great post on how to debug. I agree with everything he says – real programmers don’t guess, they debug. If you think or hope something is working, you’re probably wrong. You need to SEE it working and prove that it’s working. I can’t tell you the number of times I’ve looked at code and said “there, that will work” only to run it and see that it doesn’t. Actually while you’re at it, read his other answers. There’s a voice of experience.

* Make fun of the losers. You also need to learn which programming languages you can successfully make fun of without someone actually punching you in the face.

So what about the non technical stuff? These are the hard ones.

* How to justify your project to management. Management will continually conveniently forget what the point of your project is. You need to be able to explain it in 30 seconds, and then if given the opportunity explain it in 360 seconds. How it benefits the business and why. If you can’t articulate it, nobody else will be able to, and pretty soon people will be asking “why is that guy here?”

* How to explain to management what you’re doing and why. This is different to justifying your project. Some bosses like to know what you’re doing every day – when s/he does, you better have a good answer. “Working on code” is not a good answer. “Adding feature X that will solve problem Y” is a much better answer.

* How to clarify and write down what the customers wants (“requirements”). This is an art in and of itself. If you can do this, your programming job will be A BREEZE. You know all those arguments and problems that you had with people outside of IT? They can be resolved by writing down what people say. Write it down in front of them, during the meeting. Learn from technical BA’s – they are a Godsend.

* How to estimate. People will ask you for an estimate, be prepared. If you don’t know what you’re doing, multiply your estimate by three.  This is not to pad it out – this is to make it more accurate.

* How to plan your project. Remember, only 30% of your time on a project should be coding. That’s thirty percent.

* How to differentiate between a bug, an issue and a feature request. They are all different.

* How to direct other programmers without getting up their nose. You also want to know how to motivate them.

* How to get along with other programmers. We’re a strange breed. Getting along with us can be a challenge – you’re going to have to learn some ninja skills. I can recommend “how to make friends and influence people” by Dale Carnegie. A classic.

* How to work with maniacs, psychopaths and just plain crazy people. There’s a lot of them out there. You’re probably one of them yourself.

Phew.

So what’s the most important thing to learn?

How to GET STUFF DONE. All the theory in the world won’t help you if you can’t get stuff done. Everything above is a waste of time if you’re not getting stuff done. Can this be taught? There’s an interesting question.

Well, not yet, but possibly.

There’s a dispute going on between the Python Software Foundation (PSF) and a UK company over the name Python. A loss for the PSF could mean that they are no longer able to use the name Python within the borders of the EU.

The chairman of the PSF, Van Lindberg, posted a “call to arms” last Thursday on the PSF blog about the trademark issues:

For anyone who works in a company that has an office in a EU Community member state, we need your help. There is a company in the UK that is trying to trademark the use of the term “Python” for all software, services, servers… pretty much anything having to do with a computer. Specifically, it is the company that got a hold on the python.co.uk domain 13 years ago.

The company is POBox Hosting, formally Veber, an ISP based in the UK specialising in dedicated hosting. The Guardian newspaper quotes the managing director of Our Holdings (apparently another name associated with the company)  as saying

… that the PSF had dragged its feet after he had been in touch with it last year about applying for a trademark on python.co.uk’s logo – which also necessitates seeking a trademark on some uses of the name. “We were talking to them but they didn’t get back to us so we filed for the trademark. And now, with 14 days remaining, the PSF has got back to me at 5.30pm on a Friday.”

According to the European trademark database POBox Hosting registered the trademark in April 2012; the status of the application is now “opposed” since the PSF filed a separate trademark application on the 6th February this year. As with everything, it’s not that simple. The PSF needs help in opposing this application; they need evidence that they have more right to the name “Python” than POBox Hosting.

What is easy is what you can do to help. Van Lindberg writes (emphasis mine) that

[a]ccording to our London counsel, some of the best pieces of evidence we can submit to the European trademark office are official letters from well-known companies “using PYTHON branded software in various member states of the EU” so that we can “obtain independent witness statements from them attesting to the trade origin significance of the PYTHON mark in connection with the software and related goods/services.” We also need evidence of use throughout the EU.

If your company uses Python and has an office or hires in the EU, whether you’re in Austria or the UK, Malta or Germany, you can do something to help. Van Lindberg asks

Could you write a letter on company letterhead that we can forward to our EU counsel?

1. just a brief description of how Python is used at your company,
2. how your company looks for and recognizes “Python” as only coming from the PSF, and
3. your view that another company using term Python to refer to services, software, and servers would be confusing

This doesn’t need to be long – just a couple of paragraphs, but we would want any description of how you use Python for software, web hosting, Internet servers, VPNs, design and development of computer hardware or software, hosting websites, renting servers (like Openstack), or backup services.

Alternatively do you have, or know of, anything published within the EU that uses “Python” to refer to Python? Can you provide copies, pictures or scans of books, pamphlets, conference programs or talks, job listings, magazines or other publications or prospectuses.

All the above should be sent in PDFs to psf-trademarks@python.org

Predictably, and understandably, they’re also asking for money and ask that you consider donating to the Python Software Foundation at http://www.python.org/psf/donations/

One last point. The Guardian also reported that:

Poultney said that the issue… had led to him receiving death threats and that the python.co.uk website was receiving 250 hits per minute.

This was followed up by Brian Curtin in another PSF blog post

… it has come to our attention that the organization with which we are currently involved in a trademark dispute has been receiving messages from our community members, including threats. We ask that no matter who you support in this matter, that you remain civil in your communications and actions. It is important that we maintain the positive and friendly atmosphere that Python is known for regardless of the situation at hand.

Civility harms no one and threats and crashing the companies website could actively work against the PSF. Far more important is to get writing something relevant and useful to support Pythons everywhere.

Full details are available on the PSF blog post.

Note: This is Part II of a three part series; it is recommended that you read Part I – The Basics first. 

A quick Re-cap I previously defined the Job search Marketing phase as “Finding and Advertising yourself to potential employers”. This is everything you do up until you get a person on the phone discussing a specific opportunity. Also previously stated is that the Marketing process looks something like this:

Marketing

1. Look for Markets - i.e. 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

Confession: For a few years after I graduated college, I was a Cockroach. I had a solid resume for a Classic ASP Developer with SQL Server (What more could you need?!). I had a Basic cover letter (“I would like to apply for your Dev position listed in the NYT…”). I had Word Mail merge and a Fax Modem. I’d go through the Sunday paper, queue up my Faxer-Spam-A-Bot-umus, then bask in the glory of a full answering machine upon my return from work the next day.

After the Dot-Com Bust everything was online and there where oodles more Cockroaches to compete with (Mass emailing is massively easier than mass faxing). The going advice amongst the pros was that Cockroaches are bad, you need to be a Monkey. This didn’t sit well with me at all. How could I spend all that time customizing each resume I sent out? With each resume so customized, each was sure to have a few typos! I’d likely get disqualified on that alone, besides how long is the hiring manger going to spend looking at my resume? With so many Cockroaches out there I’d be lucky if my resume even gets looked at, and then I would likely only get a 15 second scan. It just didn’t seem right (or fair) to spend 2 hours of work (per job application) for that. Needless to say, that was not a fun job search…. I eventually joined a friend’s venture as a semi-partner, thinking I would do that until the job market picked up.

5 years later, I was ready to go on the hunt again, but I knew my Cockroach strategy was a failure. I needed to be a Monkey, but if I was going to be a Monkey I was going to be a Highly Efficient Monkey. I needed to optimize every part of my job search so I could apply to a large number of jobs that I actually want; I needed to be able to do that with no typos. The remainder of this article will focus on the different phases of marketing (see above) and how to do each in an efficient and effective manner. This is not a single linear process: you should be doing many of these in parallel, every day you should be searching the job boards, and you should be returning phone calls every day.

Disclaimer: All of the below is based on my personal experiences job searching in the NYC job market, this is in no way meant to be a one size fits all. You should test out these techniques, as well as others, and do what works best for you.

Look for Markets The key here is to research what roles\position\industries exist that there are good opportunities for your skill set and will position you for growth, these are the jobs you want. This process should be an ongoing process, you should decide what you want to do next, and then develop the skills you need (See Managing your Career in IT). If you didn’t do this and you find your self unemployed. You have no choice but to evaluate your skills, then look for markets where they are suitable.

Doing this is fairly straight forward, browse the Job boards looking at the types of jobs you want and make note of the skills you see coming up over and over again. (This is a great way of determining the marketability of a skill in a particular location, just search the Jobs boards and see how many come up! It’s not perfect but it works).

If you come across a skill you never heard of, look it up. GlassDoor.com is great for checking what particular roles tend to pay. You should always be looking for new markets even you are not conducting a job search.

Generate Leads based on your research

Finding potential employers is easy, all you have to do is go to your favorite Jobs search engine and type in a word and click “Search”. (My favorites happen to be Dice, Monster and LinkedIn).  Most sites have “Jobs Agents”, these will run a set of saved searches for you every day and email you the new listings for each agent. Jobs Agents are an unbelievable time saver, use them.

Making your resume searchable on job boards is common; I personally like the idea, though many people advise against it. If you do this, I recommend adding a “White List” stuffed with keywords to your resume (In a white tiny font so computers can see it but not people, think of it like Job Board SEO). This is a somewhat controversial idea, as many people believe it to be dishonest. In IT with so many acronyms and different terms that mean the same things, I feel this is a valid way to list all the different versions and acronyms that would look funny if you already mentioned them in a different way.

Qualify your Leads

You want to quickly scan each of your search results and only apply to the jobs you a) Want and B) Have a reasonable level of qualification. I briefly discussed this as a response to this now closed question. What I stated there still holds true. Scan the job posting much like the hiring manager will scan your resume. Look at the following and make a snap decision if you want to apply.

For me, the Quick Scan includes (You scan should include what you see as deal breakers.)

1. Job title
2. Pay Rate (Often not listed)
3. Location
4. Employment Type (Permor Contract, Contact length)
5. Requirements List \ Tech Used.
6. Then I start reading the Body.

The last thing you want to consider is the time it will take to apply: many companies\recruiters want you to reenter all your data into their proprietary system. Keep in mind that anything you enter there is going to be in that system till the end of time, and maybe used against you the next time you apply (if they see info that is inconsistent across applications). Any application that asks me to do more work, (e.g. retype my resume into a form) will also make me less likely to apply.

Market to your Leads – By sending a Targeted Cover Letter & Resume

For Monkeys this is, by far, the most time consuming part of the process; particularly if you are applying to a large number of jobs. The good news is that this is also the place where you will get the most gains in terms of efficiency. Before you apply, develop a basic “Elevator Pitch” for this particular Role. Put yourself in the employer’s shoes and ask yourself “What am I really looking for here?”. You should be able to define the job requirement in no more then 3 or 4 sentences. Everything else in the Job description is Fluff. Next, you need to develop a sales pitch that directly answers that description. This answer is your “Elevator Pitch”: it’s short, it’s to the point, and most importantly, it’s easy to remember.  This “Elevator Pitch” will stick with you through the rest of the process with regard to this particular job listing.

Suppose you read a job listing and you summarize it down to: They are looking for a Tech-Lead with 5-7 years of e-commerce experience within the high fashion industry. They use the LAMP stack and really need someone who can lead their team to success. (Note: they may not have used the words Tech-Lead or e-commerce in the job description; you need to read between the lines) ¹

Your “Elevator Pitch” should be something like this: I have been working for the past 5 years with the LAMP and the last 2 as a Tech Lead, including the roll-out of an e-commerce site for a small kid’s apparel company.

Note that you don’t have the high fashion experience; you are going to need to explain that Kid’s apparel is close enough. This is just one example; you will need to do this sort of thing constantly. You must understand how your skills can be used, and more importantly how to explain the transfer-ability of those 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. Your “Elevator Pitch” must be so simple that the HR drone or the recruiter can sell it effectively to the real decision maker.

Also note that your “elevator pitch” never said you used LAMP for e-commerce, that’s because you didn’t. You don’t need to highlight this, but if asked answer honestly, “It was not LAMP, it was package X, Everything I learned about e-commence rolling out that system will be invaluable should I be given this opportunity, I am confidant that I can repeat the success with LAMP”

This “Elevator Pitch” will be at the center of all your correspondence up with the Recruiter\Co until mid-way through the first in person interview.

The Cover Letter

The purpose of the cover letter is to do 3 things:

1. Introduce yourself and formally apply for the position
2. Explain why you are the perfect candidate, using your elevator pitch.
3. Express your enthusiasm for the job

And that is exactly what my cover letter looks like. A two sentence opening paragraph along the lines of “Please accept my application for the XXXXX position, I feel I am an excellent candidate for it because:”. I then have a list of reasons in bullet form, highlighting the key points of my elevator pitch. I then have a closing paragraph saying: I’m very excited and interested in this opportunity, thank you for considering me.

Clearly, the Bullet list is the core of your letter. Bullets are easier to read then paragraphs and more likely to resonate with the reader. The first few times you do this, it will be very time consuming. The key is to keep every bullet you write archived for later (re)use. After a while, you will have your cover letter template and a list of 30-40 bullets that you have written over time covering just about every single one of your selling points. Then, when applying for jobs in the future you can quickly assemble your cover letter by selecting the bullets that match your elevator pitch on a job by job basis. Each bullet should reference a specific job or project so the reader can easily find the details on your resume.

For the example above, your bullets would look something like this:

• 8 years overall experience working as a Business Analyst and Web Developer, Including 5 Years working with LAMP, JavaScript & jQuery.
• Proven Track Record Rolling out E-Commerce sites within the Apparel Industry, While at Kids-Yellow Corp, I successfully led the development and roll out of their E-commerce site fully integrated with inventory and order processing systems. The System was built to be scalable and is responsible for 35% of company sales, bringing in $35m annually. I am currently working as the tech lead rolling out the Mobile version of that same E-commerce site.
• Solid Understanding of SEO and Web Marketing, Worked closely with the Kids-Yellow Marketing team to ensure all web marketing activities are tracked and related back to E-commerce site visits and sales, allowing for internal analysis of marketing ROI.
• Certified MySql Developer

From the reader’s perspective, it’s clear you read the job’s description and know what they are looking for. It’s clear you have the skills they are looking for (or at least, why you think you do). It’s clear that you have some level of communication skills, and lastly there are no typos, because there is no original content. Also, notice how easy this makes it for the HR drone\recruiter to pitch you to the hiring manager.

While on the subject of Typos, here’s a Random Proofreading tip: Use Speech to Text software to proof all your correspondence by listening to it, grammar errors have a way of standing out when you hear them.

One last thing on cover letters, if you really want a particular job and you really feel you are the prefect candidate for it, include a sentence stating “I will follow up with a phone call later today”, and then do just that.

The Resume

You should have a separate resume for each role you are looking for, (So if you’re a looking for a Lead Dev role or a PM Role you should have 2 resumes). If you resume is well done, you shouldn’t have to customize it for each job you apply. That being said it doesn’t hurt to move bullets around if a particular listing really wants a skill that you have hidden.

There are whole books on the subject of resume writing, it really is an art. The key thing is that you need to be constantly working on it, and fine tuning it. That being said, my resume is laid out as follows: (Everything in Bullets, needless to say I prefer the classic chronological resume)

1. Name & Contact info, Including LinkedIn URL
2. Professional Profile – A bullet point list of who I am professionally, a high level overview. If someone read my whole resume, and had to describe me to someone else. This is what they would say.
3. Professional History, ordered chronologically with the latest first, I list the company, job title (if your job title is not very descriptive feel free to use a functional job title), accomplishments, responsibilities, methodologies & tech used, ect.
4. Education & Certifications
5. General Tech section – a list of Languages, Databases and Operating systems
6. Appendices with project level info – Because for most of my history I have worked within the professional services, I use Appendices to discuss in detail specific project details, I often swap out appendices based on the job I am applying to. I find this is a great reference when discussing my work history with a potential employer. I also include my white list as an appendix, so if someone does find it, it doesn’t look out of place.

Get & Qualify Your Responses

If you have a reasonably marketable skill set and do the above you will get responses, but you still have to manage them well. Here are a few pointers:

1. Have a dedicated Email address just for your job search. Preferably YourName@???.com. Once you job search is done, this account will get spammed for years.  This way you have established a quarantine.
2. Have a dedicated phone number for your job search. I recommend Google Voice.
3. NEVERever pick up this phone unless you are expecting a scheduled call; always let it go to voice mail.
4. Before calling a lead back, review the original job posting (most job boards track the jobs you have applied for, and you can review them at any time), visit the companies’s website, review the cover letter you sent them, remind yourself of your elevator pitch for this lead (adjust if necessary). If this is a direct hire (not a recruiter) and the salary is not listed in the ad, check GlassDoor.com. If you have any other questions make note of them, and keep your paper and pen handy. Now you are ready to call them back. Nothing is worse then taking a call for a job you don’t remember applying to; you can kiss that opportunity good by. I learned this the hard way.
5. On this first call back, you have 3 basic goals: learn more about the position, pitch your elevator pitch and discuss next steps. Let them speak first, let them tell you about the position. What they say should match the mental summary you made when you first read the job description, make note of the differences and modify your elevator pitch on the fly. Once it’s your turn to speak, if you are still interested blow them away by going through each of there requirements and knocking them down one by one (just like you did in your cover letter). Speak with confidence, show your excitement and personality. Finish by telling them “I think this is a great fit and great opportunity”, ask if they have any further questions and what are the next steps. (Next Steps are part of the Sales Process and will be the focus of Part III of this series)
6. If you are no longer interested, thank them for there time and for thinking of you. Ask them to feel free to call you again should another opportunity come their way that may be a better match.
7. At some point during this initial call, ask them the salary range. If they won’t tell you (or give you some crap about it being wide open contingent on experience) be insistent that they let you know before you go in for an in person interview, tell them “It’s to our mutual benefit to know we are on the same page and that you are just asking for a broad range, not an exact number”. The common advice is to never bring up salary until you have an offer. I adamantly disagree with this, more likely than not, a company that refuses to discus salary early on pays below market level and you are wasting your time talking to them. If push comes to shove tell then what you are looking for and ask them if that is within the range.

Postmortem

SPIN Selling

Hey all! Today is our second anniversary since graduation, Happy Birthday!

No, I don’t have any cake for you, I think by now, we all know the cake is a lie. Instead, I’ve a not-that-long blog post, summarizing all the awesome things that happened this year. We’ve certainly come a long way since our humble beginnings, the community is stronger than ever and the site has been steadily growing for quite some time now.

So, without further ado, here’s what’s been going on this past year:

Community Events

Programmers’ second year had some truly exciting moments. First, Anna Lear joined the evil corporate machine and we found ourselves short of a moderator. This prompted our second community moderator election, a process that I was very proud to be part of. The elections run smoothly, with surprisingly little drama and participation, although a bit low, was increased comparing to our first election.

Then, after the dust from the election settled down, we had our first ever contest. An exciting month long event that brought us some awesome questions, and some of the best answers I’ve ever read on the site. You can read more about the contest in this blog post, and it’s never too late for your feedback.

Which, of course, brings us to this very blog. The blog had a rocky start, although it was first proposed in June 2011, we didn’t really seemed to be able to get enough people interested in contributing. We went through various Meta discussions, two calls for contributors, a lot of candidates in the elections commited to make the blog happen, and finally we launched and posted our first blog post almost a year after the blog was first proposed. Kudos to the awesome blog team and everyone else involved for making this happen!

Lastly, starting from late January we undertook the monumental task of cleaning up our most problematic tags. The Structured Tag Cleanup started with the most bothersome of our tags, career and continued with software-engineering and software-development. The clean up effort ended on early April, at which point we’ve gone through 1000+ questions. Those of you who were active at the time may remember that we got at least a couple of blatantly off topic career questions per day, cleaning up 600+ broken windows in the various career related tags took care of that problem almost instantly.

We kick off our third year with the Hat Dash, a network wide event starting on Wednesday, it’s going to be fun!!!

Sister sites

The Stack Exchange network has grown rapidly this past year, right now there are 92 graduate and beta sites and a lot more are very close to popping out of Area51. Here’s a brief list of new technology oriented sister sites that you might find interesting (in no particular order):

• Computer Science
• AskPatents
• ExpressionEngine
• Robotics
• Salesforce
• Raspberry Pi
• Windows Phone

When Computer Science first appeared, a question was asked in our Meta about clarifying the boundaries between the two sites. Inspired by that question, and after a brief discussion with a CS moderator, Raphael, we decided to test those boundaries by re-asking CS’s highest voted algorithmic question on Programmers. The answers the question received on Programmers are surprisingly different than the ones it received on CS, which, at least to me, says that although the sites overlap a bit, they have distinctly different audiences:

• Why is quicksort better than other sorting algorithms in practice? (Programmers version)
• Why is quicksort better than other sorting algorithms in practice? (CS version)

And of course, although not a technology oriented site, The Workplace deserves an honourable mention. The site was initially proposed on Area51 to fill the gap for all those general career related questions we couldn’t really support on Programmers, and it was greeted with enthusiasm from Programmers’ regulars when it finally made it to beta. Even today, 8 months into beta most of the site’s high rep users are also Programmers’ regulars, and all four pro tempore moderators are significant contributors on our site. If you haven’t visited the site already, trust me, it’s awesome!

New features

There have been a ton of new features this year, with two very important changes for Programmers:

• We are no longer a migration target from Stack Overflow, and
• We now require registration for asking questions (but not for answering them).

Network wide the more significant changes were:

• Reputation history changes
• Flag weight was removed from user profiles
• Real time updates to questions, answers, and inbox
• Rejected migrations
• Community review tasks (aka the new review queues)
• Disabling migration for questions older than 60 days

Questions

I wanted to close this with a list of awesome questions from the past year. At first I wanted to bring some new attention to a few hidden gems, showcase posts from less popular tags, blah blah blah, but at the last moment I decided to go simply with the questions with the highest score. It might not be the best metric we have, but it’s the only metric that I felt would adequately represent the wider community. Here they are, our top twenty questions:

• My boss decided to add a “person to blame” field to every bug report. How can I convince him that it’s a bad idea?
• Is the use of “utf8=✓” preferable to “utf8=true”?
• What is the Mars Curiosity Rover’s software built in?
• I’m doing 90% maintenance and 10% development, is this normal?
• I’ve inherited 200K lines of spaghetti code — what now?
• Should I intentionally break the build when a bug is found in production?
• What software programming languages were used by the Soviet Union’s space program?
• Why can’t the IT industry deliver large, faultless projects quickly as in other industries?
• Torvalds’ quote about good programmer
• Should you keep a copy of all the code you write?
• Why is 80 characters the ‘standard’ limit for code width?
• Why was Tanenbaum wrong in the Tanenbaum-Torvalds debates?
• How do I review my own code?
• Why are shortcuts like x += y considered good practice?
• How to keep a big and complex software product maintainable over the years?
• Has “Not everyone can be a programmer” been studied?
• How do operating systems… run… without having an OS to run in?
• Is it just me or is this a baffling tech interview question?
• Is constantly looking for code examples a sign of a bad developer?
• Is the phrase “never reinvent the wheel” suitable for students?

All in all, it’s been an awesome year! Keep on rockin’, Programmers!

Keeping your hands healthy and pain free is something every programmer should be thinking about, minor hand injuries will affect your productivity, a major injury could threaten you livelihood. Hand injury is common problem amongst programmers, so it’s not surprising that the question “How do you keep your hands in good condition?” was asked here on Programmers (though closed as off topic).

Dr. Alan Gotesman an orthopedic surgeon with training in hand, microvascular & upper extremity surgery and friend to the Programmers Community has agreed to answer this question for us.

By: Dr. Alan Gotesman

Repetitive Strain Injuries of the Hand

Prolonged repetitive hand movements, particularly in awkward positions, can lead to strain injuries. It is important to be aware of these injuries and prevent them as well as treat them when appropriate. Some of the conditions may not necessarily be caused by repetitive stress, but many can be aggravated by it.  The following are some of the more common hand conditions encountered by hand surgeons in the setting of repetitive stress.

Carpal Tunnel Syndrome

The carpal tunnel is a narrow, tunnel-like structure in the wrist. The bottom and sides of this tunnel are formed by wrist (carpal) bones. The top of the tunnel is covered by a strong band of connective tissue called the transverse carpal ligament.

The median nerve travels from the forearm into the hand through this tunnel in the wrist. The median nerve controls feeling in the palm side of the thumb, index finger, and long fingers. The nerve also controls the muscles around the base of the thumb. The tendons that bend the fingers and thumb also travel through the carpal tunnel. These tendons are called flexor tendons

Carpal tunnel syndrome occurs when the tissues surrounding the flexor tendons in the wrist swell and put pressure on the median nerve. These tissues are called the synovium. The synovium lubricates the tendons and makes it easier to move the fingers. This swelling of the synovium narrows the confined space of the carpal tunnel, and over time, crowds the nerve. The synovial swelling can be caused or aggravated by repetitive motion. Direct compression of the carpal tunnel as well as extreme positions can also aggravate the condition.

Symptoms of carpal tunnel consist of:

• Numbness, tingling, and pain in the hand
• An electric shock-like feeling mostly in the thumb, index, and long fingers
• Strange sensations and pain traveling up the arm toward the shoulder

Prevention:

Prevention of symptoms should focus on proper hand positioning when performing activities, in particular typing. The wrist should be in a neutral position (not bent up or down) which is best done by a forearm rest. There should also be no direct compression on the wrist which can increase the pressure in the carpal tunnel. Occasionally, braces may be required to rest the wrist and if symptoms become severe enough, surgery may be necessary.

Tendonitis

Tendons are the connection between muscle and bones which allow us to move our joints. The wrist tendons slide through smooth sheaths as they pass by the wrist joint. These tendon sheaths, called the tenosynovium, allow the tendons to glide smoothly in a low-friction manner. When wrist tendonitis becomes a problem, the tendon sheath or tenosynovium, becomes thickened and constricts the gliding motion of the tendons. The inflammation also makes movements of the tendon painful and difficult.

The most common and consistent complaint of patients diagnosed with wrist tendonitis is pain over the area of inflammation. Swelling of the surrounding soft-tissues is also quite common. Repetitive stress can cause tendonitis by putting too much strain on the tendons.

Prevention:

Taking frequent breaks and not putting the wrist/hand in awkward positions can prevent these injuries. If symptoms appear, anti-inflammatories can be helpful as well as short periods of immobilization. Swelling can be brought down with ice and elevation. Cortisone injections can be helpful for symptoms that are not improving and surgery may be necessary if conservative modalities are failing.

Sprains

A sprain is an injury to a joint caused by a tearing/stretching of the ligaments. These are frequently acute injuries caused by trauma, however they can be chronic from repetitive stress across the joint causing stretching. Any joint can be affected, but the thumb can be particularly vulnerable as the ligament is often being stressed with daily activities. The increased frequency of texting, with the thumb primarily being used to depress the keys, has increased the incidence of this problem.

Symptoms consist of discomfort around the joint, particularly with any stress applied. There can be swelling in the area as well as tenderness directly over the affected joint. Extremes of motion can be painful as well.

Prevention:

Repeated stress across the joint, especially in one particular direction, should be avoided. If symptoms appear, alternative positions should be used and if possible, decrease the amount of activity. Custom splints can be helpful to support the particular ligament involved and decrease the stress across it. Anti-inflammatories can alleviate the pain and swelling. Infrequently, if symptoms persist, the ligament may need to be repaired or reconstructed.

Repetitive stress injuries of the hand can be disabling and appropriate measures to prevent them should be instituted. If symptoms persist, they should be evaluated further by a qualified hand surgeon for further treatment.

About The Author

Dr. Alan Gotesman is a board certified orthopedic surgeon with fellowship training in hand, microvascular & upper extremity surgery. He has a special interest in minimally invasive and arthroscopic surgery. He is in private practice in Rockland County.

Alan Gotesman MD
http://www.alangotesmanmd.com
Orangetown Orthopedics
99 Dutch Hill Road
Orangeburg, NY 10962
845-359-1877

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.