tsJensen

A quest for software excellence...

What’s Wrong with Technical Recruiters

I’ve had a series of ongoing discussions with a friend who is also a senior software architect. In recent months he’s become quite dissatisfied with his manager specifically and employer generally. He has put his resume out on the typical job search sites, Dice, Monster, TheLadders, LinkedIn and others, and has been sorely disappointed with the result. Technical recruiters seem to be, with rare exceptions, a sorry lot of would-be telemarketers rejected for lack of integrity by the local call-center-for-hire.

On a daily basis this friend of mine receives emails and calls with a hot job listing that do not generally match his skills or experience like the one that he forwarded to me today, not because he might really be a match but in hopes of sparking a conversation that goes something like this:

  • Recruiter: “I know you may not be a good fit for this job, but do you know anyone who is?”
  • Candidate: “No. I do not know anyone with this skill set and experience level interested in a 6 month contract.”
  • Recruiter: “Okay. I’d like to keep in touch with you and I will definitely call you if something comes through that is a better match for what you’re looking for.”
  • Candidate: “Okay, sure. Thanks for the call.”

My friend reports that he has at least three of those conversations per week and at least two or three such emails as the one below per day. I’ve changed the company names and the place to avoid the chance of embarrassing any of them, especially since one or two of them is a household brand name.

Hello,

I am Recruiter with XYZConsulting (formerly ABCConsulting), a dedicated QRS contractor sourcing service, managed by TenCharms. We recruit solely for QRS Contract Positions. Should you accept a contract position, it will be through our preferred partner TenCharms, an independent vendor chosen to manage this program for QRS.

I saw your resume on a job board. I am currently recruiting .net Consultant for a 12 months contract project with QRS – Chicago, IL.

Email me a copy of WORD formatted resume, along with these details:

  • Best time & number to speak to you:
  • Location:
  • Visa Status:
  • How soon you can start:
  • Work mode, W2, C2C (if self-incorporated):
  • Expectations on Compensation:

Position’s name: .net Consultant

Assignment period: 12 months
Location: Chicago, IL

Required skills
Primary Skills: asp.net, vb.net, Oracle / SQL Server, SQL. Secondary Skills: C#.net, MS Access / VBA

As this is an urgent requirement, kindly respond to it at earliest possible.

Best Regards,
Bad Excuse (name changed to protect the guilty)

Recruiter | XYZConsulting (formerly ABCConsulting)
A TenCharms Solution
Dedicated QRS Contractor Sourcing Services

My friend has shown me many other emails that are far worse than this one. Many of them are poorly written, lacking proper grammar and teeming with spelling errors, yet they claim to represent well known companies. I wonder if these companies for whom these recruiters work ever bother to review the practices and general quality of the communications of their agents. Somehow I doubt it.

In some of the emails my friend has forwarded to me, it becomes clear that the recruiting company has employed some shoddy keyword matching algorithm to select from a list of candidates who have put their resumes out into the swamp of job sites (see above mentioned sites). In some of these I have been able to identify one or two specific keywords that match my friend’s resume. I should know. I helped him write it.

Sometimes the keyword match is even close, such as, “architect” or “jQuery.” But since my friend is a .NET architect and the job is for a J2EE architect who also knows jQuery and PHP and Oracle while my friend does not mention Oracle or PHP on his resume at all, it is clear that the recruiter’s matching algorithm, whether it is their own or provided by one of the job sites, is severely lacking in even the most basic intelligence.

Either that or the recruiter is far more interested in spamming the candidate with a job posting that is clearly not a fit in hopes that the candidate will do the job of the recruiter for him or her or it.

To all such recruiters, please for the love of Pete, what’s wrong with you? Stop wasting my friend’s time!

Ruck Software Development Process

I have worked in several development teams that have a Scrum-like development process where the team has adapted Scrum to their own team dynamics and organizational needs. I was intrigued by a recent MSDN article called Visual Studio ALM Rangers—Reflections on Virtual Teams that formalizes one of these this Scrum-but-not-Scrum processes and calls it Ruck. Here is the authors’ loose definition:

“To ensure that we don’t confuse anyone in terms of the methodologies or annoy process zealots, we provisionally chose to call our customized process ‘Ruck,’ which, in the rugby world, means ‘loose scrum.’”

The article authors share their experience in Microsoft’s ALM Rangers team and “provide guidance for working with teams in less-than-ideal distributed and virtual environments.” I found this introduction compelling and I wanted to try to restate their approach here with a few of my own thoughts mixed in.

The ALM Rangers’ Ruck process is very specific to their needs and team: a highly distributed team and a high degree of variability in team member availability where team members have multiple professional obligations that take higher priority than their work on the team. This is a very challenging situation for a team trying to be Scrum-like and may be closer to many popular open source projects with multiple contributors from around the world, with one very important exception: a fixed ship date.

I’m not advocating that any specific team adopt the ALM Rangers’ Ruck, but the choices and approach taken by this team could be very valuable to other teams faced with creating their own Ruck because they cannot, for whatever reason, get close enough to Scrum to really call their process Scrum.

One of the most important points I found the authors making had to do with adhering to the agile principle of self-organizing teams. They found that their “belief in letting developers choose work from areas in which they have interest” required that they allow teams to self-organize around these areas of interest rather than specific geographies or time zones.

One of the most difficult challenges facing enterprise software development projects is team size and how to break up larger projects into smaller chunks that can be addressed by smaller, more agile teams. The authors observe:

“We’ve learned that smaller projects and smaller team sizes enable better execution, proper cadence and deeper team member commitment. Also, it seems it’s more difficult for someone to abandon a small team than a larger team.”

Another interesting area the authors cover is that of project artifacts used to manage and break down the project into actionable tasks. The particular names of these seem less important than the fact that they are well defined and communicated and used consistently within their Ruck. In creating your own Ruck process, do not skip this important element.

Roles are also well defined. Knowing what position you play on the team at any one given moment can eliminate the need for over-the-shoulder management because each team member knows what their responsibility is. The task of the manager becomes one of coach rather than hall monitor, communicating these roles and responsibilities to team members rather than asking the question, “so what are you working on today?”

One more critical area to define is meetings. Don’s skimp on structuring meetings to achieve what you need to achieve without wasting too much time. As my brother tells me, “It takes a really good meeting to beat no meeting at all.”

And finally, I want to share one more brief excerpt from the authors. Their top recommendations:

“There are many recommendations, skills and practices that will help you improve the virtual team environment, the collaboration and effectiveness of each team member, and the quality of the deliverables. For us, the seven top recommendations include:

  1. Clearly define and foster a team identity and vision.
  2. Clearly define the process, such as the Ruck process.
  3. Clearly define the communication guidelines and protocols.
  4. Clearly define milestones, share status and celebrate the deliverables.
  5. Implement an ALM infrastructure that allows the team to collaborate effectively, such as TFS and associated technology.
  6. Promote visibility and complete transparency on a regular cadence.
  7. Choose your teams wisely, asking members to volunteer and promoting passionate and get-it-done individuals.”

Thoughts on 9/11

I normally use this blog to write of technology but today is a justifiable exception. Today I am reminded of and enjoyed reading again the words of a Prophet of God, Gordon B. Hinckley, spoken in a conference just a few short weeks after the fateful day ten years ago. I invite you to read his entire address, but here are a few excerpts:

You are acutely aware of the events of September 11, less than a month ago. Out of that vicious and ugly attack we are plunged into a state of war. It is the first war of the 21st century... But this was not an attack on the United States alone. It was an attack on men and nations of goodwill everywhere.
...
Religion offers no shield for wickedness, for evil, for those kinds of things. The God in whom I believe does not foster this kind of action. He is a God of mercy. He is a God of love. He is a God of peace and reassurance, and I look to Him in times such as this as a comfort and a source of strength.
...
Now, all of us know that war, contention, hatred, suffering of the worst kind are not new. The conflict we see today is but another expression of the conflict that began with the War in Heaven. I quote from the book of Revelation:

“And there was war in heaven: Michael and his angels fought against the dragon; and the dragon fought and his angels,

“And prevailed not; neither was their place found any more in heaven.

“And the great dragon was cast out, that old serpent, called the Devil, and Satan, which deceiveth the whole world: he was cast out into the earth, and his angels were cast out with him." KJV, Rev. 12:7-9

From the day of Cain to the present, the adversary has been the great mastermind of the terrible conflicts that have brought so much suffering. Treachery and terrorism began with him. And they will continue until the Son of God returns to rule and reign with peace and righteousness among the sons and daughters of God.
...
Are these perilous times? They are. But there is no need to fear. We can have peace in our hearts and peace in our homes. We can be an influence for good in this world, every one of us.

May the God of heaven, the Almighty, bless us, help us, as we walk our various ways in the uncertain days that lie ahead. May we look to Him with unfailing faith. May we worthily place our reliance on His Beloved Son who is our great Redeemer, whether it be in life or in death, is my prayer in His holy name, even the name of Jesus Christ, amen.

Update: Please read commentary posted by Thomas S. Monson, a living Prophet of God, in the Washington Post.

Why I Would Work for Eric Sink

As I sit here nursing a head plagued with a migraine, I read with great interest Eric Sink’s latest in my RSS reader about his experiences learning Scrum, a paper submitted for the proceedings of Agile 2011. Here’s my favorite part:

“I have come to think of our daily standup as being similar to a security guard at a bank. Most security guards stand around for their entire career without ever firing their weapon. It's probably a boring job. But the consistent presence of that security guard probably prevents some big problems from ever happening. Our daily standup is the same way.  Nothing exciting ever really happens. But we can confidently assume that many big problems have been avoided because we regularly take the time to get synced up.

“The culture of Scrum teams seems to be built on working together in shared spaces. In contrast, our company has always placed a high value on each person having a private office.

“We are aware that there are tradeoffs here. A private office gives each person a quiet place to work, but it also creates the opportunity for people to get isolated. So even as we provide private offices, we create ways to drag people out of them, including soda in the kitchen, lunch together on Wednesdays, a pool table, and a video game room.”

For this I would consider relocation to Illinois. And I always tell recruiters I’m not interested in relocating.

The Two Keys to Programming Productivity

Occasionally other developers with whom I work will comment on my productivity. For example a couple of weeks ago, after working hard one day and delivering an urgently needed service to the team the next morning, one developer said in standup, "You're an animal. You wrote that in one day and it would have taken me two weeks to do that." I’m a little embarrassed by such comments and have often thought about what makes me or any programmer productive, so today I enjoyed reading parts of Neal Ford's book The Productive Programmer and wanted to share some thoughts on programmer productivity.

I loved the forward by David Bock of CodeSherpas. He writes, "The individual productivity of programmers varies widely in our industry. What most of us might be able to get done in a week, some are able to get done in a day. Why is that? The short answer concerns mastery of the tools developers have at their disposal. The long answer is about the real awareness of the tools' capabilities and mastery of the thought process for using them. The truth lies somewhere between a methodology and a philosophy, and that is what Neal captures in this book."

Ford suggests there are four productivity principles for programmers.

  1. Acceleration: speeding things up. Keyboard shortcuts, searching and navigation.
  2. Focus: eliminating distractions and clutter, both physical and mental.
  3. Automation: getting your computer to do more. Put your computer to work.
  4. Canonicality: doing things once in one place. Also known as DRY or Don't Repeat Yourself.

These are all good and important. For me the most important item in Ford's list is number two: focus. And I would add one more: conditioning. Focus and conditioning are the two most important keys to successfully improving your programming productivity.

Programming Productivity Key #1 – Focus

Start by eliminating mental and physical distractions. Remove the clutter from your mind and your desk, but most importantly, eliminate the distractions caused by environmental disruption. Find or create a quiet place where you can focus on the task at hand, where you can put your entire mental energy into what you are doing. Distractions are a HUGE productivity destroyer.

Cubicles are of the Devil. They may be great for a sales team or reporters who thrive on eavesdropping, but chit chat does not get code written. Cubicles foster incomplete and sporadic communication that becomes a crutch for broken requirements and shoddy analysis resulting in an unsearchable and unsellable body of knowledge persisted only in the fragile collective of a distributed and disconnected human neural network that often cannot survive the loss of one or two key nodes.

Ford suggests instituting "quiet time" where, for example, there are no meetings or email or talk during two two-hour periods each day. He claims to have tried this in one of the consulting offices where he worked and the organization found that they got more done in those four hours than was getting done in the entire day before implementing the "quiet time." This is not surprising to me at all. Ford writes, "It is tragic that office environments so hamper productivity that employees have to game the system to get work done."

While I have the luxury of working from a home office at the moment, I have worked in a number of cubicle environments in the past and probably will in the future. The most common technique I see other developers using to create their own "quiet time" is the use of a very expensive pair of noise canceling headphones piping in whatever tunes or white noise that developer finds most conductive to focusing on the task at hand. Do whatever you have to do to achieve focus.
 

Programming Productivity Key #2 – Conditioning

To play at the top of your game, you have to condition. You have to practice. You have to study. You have to prepare your body but most importantly your mind to execute. And you have to condition your attitude. You have to be excited to write code. You have to get a thrill out of making it work and work well. You have to condition your mind to expect excellence and then work to achieve that.

In conditioning, there are mechanics you must learn. Spend time studying and using your IDE's keyboard shortcuts. Regularly study and practice using the base class libraries of your platform so you don't end up wasting time writing code that a solid community or well heeled development team has already written and tested heavily for you.

More importantly, spend time reading about and learning new techniques and technologies from open source projects to gather at least a passing understanding of the problem they solve and how you might use them even if you choose not to do so. Pay attention to the patterns, the naming and organizational patterns, the logical patterns and the problem solving patterns that you find in these projects. Even if you do not use them, you will be storing up mental muscle memory that will serve you well when you need a way to solve a new problem in your own projects.

Most importantly, learn from your own work. Repeat your successes, taking patterns from your past and improving on them. Avoid your failures, being honest with yourself about what did not work in your last project and finding ways to avoid or even invert the mistakes of the past, turning them into strong successes.

Conditioning is not about solving a problem for a specific project in which you're working now. It's about preparing your mind to be at its most productive when faced with programming problems you've never seen before. It's about creating mental muscle memory that will kick into overdrive as you solve the problems you have already faced, the code spilling out of your brain through your fingers and into the keyboard.

Conclusion
No matter how fast or slow you are as a programmer, you can improve. If you improve your focus and put your body and mind through regular conditioning, you will improve. And as you improve, you'll get noticed. And as you get noticed, you'll get rewarded.

Visual Studio LightSwitch 2011 May Bridge the Gap

Microsoft announced recently that Visual Studio LightSwitch 2011 will be released on July 26. I’ve been watching the development of this product with keen interest for the last year or so. I’m looking forward to evaluating it more in-depth soon.

Building common line-of-business (LOB) applications in today’s enterprise development stacks can be too complex and too costly for today’s tight budgets. For this reason alone there are “literally millions” (exaggeration license: 02389-872.159-034) of LOB applications being created by non-programmer Office users. These “applications” most often get pushed around in Excel via Exchange. Many live in a hastily created Access database and shared clumsily and un-securely on a workgroup file server.

Still others are somewhat more sophisticated and are hosted on products such as QuickBase from Intuit. This latter category resolves many of the problems inherent in the emailed Excel spreadsheet and the Access fileshare such as security, reliability, common user interface, ease of use, etc. There are many more specialized web-based SaaS offerings that solve specific business problems. One notable vendor who led the way in this area is 37 signals.

But these solutions are not always enough to meet the needs of the business. There is a gap between these “entry-level” (ELOB) applications and what I will call primary line-of-business (PLOB) applications. The PLOB is a custom developed, sophisticated enterprise application with complex business rules, sometimes even more complex user interfaces, and far more complex data and integration requirements, upon which the business relies for its core service offering or mission critical systems.

Somewhere between ELOB and PLOB there has to be a middle ground. Let’s call it the mid-line-of-business (MLOB) application (FLA creator license: FOLK-LANG-MAKE-UPPR-WXYZ). There are plenty of “app generator” and scaffolding tools that claim to live in the MLOB space. I’ve never been too impressed with them. They always seem to lose their way in convention, diverging from business requirements too greatly to meet business needs.

So I am hopeful that LightSwitch will fill the MLOB gap. We’ll see. Time will tell. In any case, it should at least be fun to find out.

Winning Teams Have Winning Coaches

How many games will an NFL team win if the coaching staff and the owners remain in the locker room during practices and games, coming out only at half time and between quarters to ask the team members what they can do to win the game?

ESPN’s Worst NFL teams of all time include:

#1. 1976 Buccaneers (0-14)
It was their season debut. They were shut out five times and averaged fewer than nine points per game. Defensive lineman Pat Toomay said, “The coach stopped talking to us after the third game. During the week, he wanted nothing to do with us.”

… (You can read more on the page linked above. I’ve included snippets here of the two that I felt illustrated my point.) …

#9. 2001 Carolina Panthers (1-15)
”The energy has been sucked out of our organization and our fan base,” said owner Jerry Richardson, after firing head coach George Seifert at the end of the year.

Great players cannot win consistently without great coaches. The same is true of software development teams, or any other type of team for that matter. If the coaches remain in the locker room, the team, being paid professionals, will still play, and they might even score, and with ideal conditions, they might even deliver a win or two, but a losing season can be guaranteed when the coaches and owners can’t be bothered to be a part of the game.

On the other hand, we have great examples such as Vince Lombardi who went to work for the Packers and turned a 1-10-1 in 1958 team into one of the greatest teams in the game and with five NFL championships before he left nine seasons later. He was in the game. He was a motivational leader. He was a great coach.

Or how about Tom Landry and his goofy hat who coached the Cowboys for 28 years and had a 20 year winning season streak. He was a great coach.

This list of winning coaches is long. Only the losing players on a losing team remember their losing coaches beyond the losing season. Winning coaches are remembered and revered long after they’ve left the field.

And how many games do you think those winning coaches missed?

Who was your greatest coach? And why? I want to hear from you.

Windows 8 Preview Elevates Touch and HTML 5 and JavaScript

In a press release from Redmond today, we get a little preview of what is to come with Windows 8 and it is HTML 5 and JavaScript.

I have mixed emotions about all of this. Some may say that it’s like putting lipstick on a pig, but in fact I don’t think Windows 7 is a pig at all. It beats any other desktop OS, bar none, and no, I don’t want to hear it from the Mac crowd (see my previous post). For me, it feels like putting an enhanced Windows Phone 7 wrapper on the desktop OS. This is great news for the upcoming Windows 8 tablet user and market. For me, for now, it feels like my phone UI is getting in the way of my desktop UI. I’ll probably get used to it later, but for now it just feels strange.

In any case, the press release and the little demo video seems to answer three primary and critical questions. Here are my first impressions and a few key frames from the video to tease you into watching it.

What is a Windows 8 App?
Based on this press release and quick demo, we can assume that a “Windows 8 App” is a touch enabled HTML 5 and JavaScript application running locally on the IE 10 engine. This seems to directly integrate IE technology into the OS. I wonder if Eric Holder will care. I assume that if I can still make another browser my default, we’ll all be safe from the clutches of the U.S. Justice Department.

start
The touch enabled Start Desktop

What is Windows 8?
Aside from assumed improvements in the kernel, driver infrastructure, etc., we learn from this demo that the primary target UI is the touch interface with cool split thumb-friendly touch keypads for all platforms. Of course support for the 20th century input devices formerly known as the keyboard and mouse continues to be available. Behind the new touch enabled "Start screen" with smart app tiles, the old "Start button and menu" and desktop interface can be found underneath the covers. So you can have your touch-cake and eat your mouse and keyboard driven app-cake too. Smart.

start2
Dragging the next desktop pane into view. Note the distinctly non-Windows 8 Word icon.

What Should a Developer Know About Windows 8?
In addition to your bag of tricks you currently maintain, you'll need to add HTML 5 and JavaScript if you don't already have them. And if you are not already learning HTML 5 and getting past the 'alert' statement/method in JavaScript, you are standing on the dock and the boat is hoisting anchor. Get with it. Buy some books. Watch some tutorials. And start writing your own "Hello Touch World" Windows 8 App now.

tweetsheet
Tweet in your Windows 8 App while balancing the budget in your mundane Excel spreadsheet.

It will be fun to watch this latest incarnation absorb some of the best of its competitive predecessors. It will be more fun to read about their indignation. It will be less fun if Microsoft prematurely releases and we have a Vista-like PR disaster regardless of the basic goodness due to a few unpolished bits. Either way, I’m heading back to my HTML 5 and JavaScript study group.