Personal Best

I ran a personal best (PB) time for ten miles yesterday.  The past couple of months, I've been building up my speed over distance and yesterday I went for it.  I blew my previous time ten mile time away by 4:27.  It was hard - VERY hard - but felt pretty darn good when I saw what I'd accomplished.

It got me thinking...  What does it take to achieve a personal best?  What does it mean when you hear someone say they got a new PB at something?

It means you did more then you've ever done before.  Or less, or faster, or higher, or whatever the goal was.  It means you tried harder, went further, lifted more, lost more weight, whatever, then EVER before in your whole life.  That sounds pretty daunting.  What does it take to achieve that?  It takes your best effort.  It takes better than your best.  It takes all you've got.  It's worth it though.  Setting a personal best is enormously satisfying.

I don't know if I'll ever run ten miles faster than I did yesterday.  I may try for a different record next.  Maybe push-ups.  Maybe I'll shoot for a new PB half marathon.  Maybe I'll set a goal for an app to set an uptime record.  I'm not sure yet, but I'll definitely set a goal and go for it.

I think this applies to business too.  We can set PBs at work.  I've found them to be satisfying also.  In my line of work, the goals tend to not be so physical, but more like:  number of projects delivered on time, or least amount of production incidents in a month.  That sort of thing.  The same MO applies: you've go to do something better than you've ever done it before.  It takes hard work and determination, but you can do it.

For the detail-oriented or the just-plain-curious, here's a link to the run stats from my Garmin Forerunner: http://connect.garmin.com/activity/228975117

Shameless plug:
I have spent the past thirteen years writing code and managing teams of software engineers in the financial services industry.
To learn more about me, look up

Ruthlessly pursue your goals

In a previous post, I talked about asthma, diet, getting fit, and other life changes.  I have continued running as a regular part of my fitness routine.  A few of months ago, while I was logging a run on the Garmin Connect web site, I ran a report of all my running activities since I started using a GPS-enabled running watch.  It turned out that I was just a few hundred miles short of 1,000 all-time recorded miles.  In my case, "all-time" means since Father's day, 2011 - about 14 months ago.

I calculated my average miles per week to-date and set a weekly mileage goal for myself that was slightly higher than that average.  Based on that miles-per-week number, I also set a date to hit 1,000 recorded miles.  The date was August 31st, 2012.

Then I went about meeting or beating my goal each week.  In the end, I beat both my minimum per-week miles and therefore, I beat the date too.  As of today, I have recorded 1,000 running miles!  It is enormously satisfying to set and achieve a goal like this.

Is there a lesson to this story?  Maybe.  If you like lessons.

Ruthlessly pursue your goals and you can achieve great things.  Set a big goal.  Break it into smaller, more immediately achievable goals.  Get to work.

Now if you'll excuse me, I think I'll go for a run and ponder my next goal.  Maybe 1,000 miles in a calendar year?


Shameless plug:
I have spent the past thirteen years writing code and managing teams of software engineers in the financial services industry. To learn more, look me up on LinkedIn.

Recruiting dev talent

In previous posts, I've written about retaining developers and one important thing to look for when hiring developers.  But what are you doing to recruit dev talent?  Maybe it's time to replace someone who's left.  Or your want to add to your team because the business is growing.  Perhaps you've had to let a poor performer go.  Whatever the case, what do you do when the time comes to hire?  Do you have a pile of old resumes you've saved from searches past?  Do you call a headhunter and start reading the resumes they throw your way?  Do you have an active recruiting lifestyle with a candidate pool veritably on tap?


Headhunters are good.  Very good sometimes.  In fact, I'm working with a couple right now as part of my opportunity search and I am very pleased to have the use of their talents and connections.  However, you need to help yourself too. Your headhunter(s) won't know everyone.  You need to be building some buzz out there on your own so people start to seek you out.  You don't need to be Groupon of Facebook to attract talent, you just need to work at it.


Your firm's web site should have an Open Positions section.  You should have a Life At Our Firm piece too.  Include as much as you can about what makes your company a great place to work.  Things like technology examples and how the firm gives back to the community through donations and/or charitable works should be featured prominently.  Also include as much as you can about the great benefits your firm offers to its employees.  If your office space looks cool, by all means, include some pictures.  When considering your place of business as a possible destination, prospective employees will check out your site.  Make sure you put your best foot forward.


Internal referrals are a great source of talent acquisition.  If your team is fully motivated and involved, they shouldn't hesitate to recommend your firm to their friends and likely candidates.  The firm would do well to have a referral bonus program in place to encourage this behavior.  A referral bonus would probably be a lot cheaper than a headhunter's fee, and I dare say you'll get candidates more likely to stick too.  The key here is having employees that are happy enough to want to recommend your firm.  If you aren't getting any internal referrals to your open positions, I bet you have a morale problem.


Attend college job fairs.  A lot of them.  You should know the campus job / placement people at several schools.  Don't restrict yourself to local schools.  Think bigger.  Go a little further.  Get out there and sell your firm.


Develop a recruiting lifestyle.  You've got to invest up front to have a talent pool on tap.  It takes effort and, yes, some money.  Attend industry events and keep the world aware of what a great place to work your firm is.  Network.  All the time.  It might even behoove you to have an internal recruiter who's job is to be on top of this stuff.  Not a part time HR generalist.  They won't have enough time to devote to recruiting to do it right.  Invest.


These are just a few ideas for shortening your recruiting cycle next time you need to hire.  I'm sure there are more and probably better ideas out there.  How does your firm do it?


Thanks for reading.




Shameless plug:
I have spent the past thirteen years writing code and managing teams of software engineers in the financial services industry. To learn more, look me up on LinkedIn.

Hire programmers by attitude

How to hire a programmer? Start with some basic research: Google it. There's a lot of material and opinions out there. Read some of it and then come back here and read the rest of this short post.


Done?

OK, so now you have lots of ideas about how to hire programmers. Phone screens, certifications, education, code tests, estimating skills, riddles, blah blah blah. I'm going to focus on one element in particular that I think is the best predictor of a new hire's success: attitude. Not to be confused with aptitude.  Yes, aptitude does matter too.  You need a decent feel for the candidate's skill set relative to the role you are hiring for. But I submit to you, dear reader, that aptitude will ultimately count for less than attitude in determining your new hire's success or ultimate failure at your firm.


I've seen this more than once: brilliant guys or gals that can't play nice with others or don't "fit" with the team. That's one type of attitude issue that will sabotage your new hire and potentially cripple your team's productivity. Certainly those with poor communication and / or people skills will have a hard time of it and may ultimately wash out. However, what I'm talking about is a different kind of attitude.


Here's what I look for when I interview programmers. I want people that want the job. I want people that want to learn and grow. I want people with a thirst for continuing growth and knowledge. I want the kind of programmer that noodles around with code for fun on their own time (and can prove it - show me a program or portfolio).  I want programmers that truly like to program.


Comparing a good attitude to a good aptitude: I can teach you programming. I can teach you skills and languages and systems and processes. I can teach you the difference between an INNER join and an OUTER join. I can get you training for skills that you are lacking. What I can't teach you is a good attitude. Everything else being equal, I'll take a gal with good attitude and a thirst for knowledge and growth over a more skilled but less enthusiastic counterpart any day of the week.


So how can you interview for the attitude you want?  Ask a lot of questions.  Have a conversation about the candidates favorite or most recent project that they did for fun.  It can be tough to try to figure out what makes a person tick in a brief thirty or sixty minute interview.  Now that you know what to be on the lookout for, you're tuned in.  Knowing is half the battle.  I don't have a silver bullet for this, you'll have to figure out what works for you.

Follow this advice and you will build successful teams of motivated people that get things done. Because, in the end, that's what we all want: to get things done.  Motivated people with good attitudes will get more done than unmotivated people every day, all day.


I'm a fan of Jeff Atwood's Coding Horror blog. I think he's probably written the definitive article on hiring programmers (although I might say that following all 6 steps might make for an arduous process).  I especially like the idea of asking potential hires a FizzBuzz question.  But take my advice on the attitude piece and add it to Jeff's thoughts about hiring for cultural fit.


Thanks for reading.




Shameless plug:
I have spent the past thirteen years writing code and managing teams of software engineers in the financial services industry. To learn more, look me up on LinkedIn.

5 Things to Get Right to Retain Developers

Software developers aren't satisfied to just sit in a cube and pound out code day after day. Like their not-as-nerdy counterparts in other parts of the company, they need more to stay engaged and happily productive. There is a lot of talk about the poor job market out there lately. Don't be fooled, your dev talent can find other work. The reality about top developers is that they aren't locked into one market segment or vertical. Your awesome JScript guys can go write websites for anybody. Your competitors might be happy to steal some of your talent away too. Don't let all the company knowledge and history that is stored in their heads just walk out the door. Do something right now to keep your development machine humming.

Compensation

Let's go ahead get the tough news out of the way. You're going to have to compensate your developers. You don’t have to over compensate to get good retention – especially if you get the rest right - but pay a salary commensurate with skill level and industry. Do some market research to find out what those numbers might be. Remember, talent won't be cheap, but is almost always worth some extra money. Another thing you need to do about compensation is to have a very clear and well communicated plan for both base salary increases (AKA raises) and bonus payments (if applicable). There must be a clear path to making more money over time. Without good communication about salary, bitter disappointment awaits both the firm and the developer. Part of this plan should include a proper performance review and clear goals. (That's a whole other article.) In most cases, people will expect at least a COLA to keep up with the proverbial price of bread. Have a plan and discuss it with the team either as a whole or individually.

Product delivery

Developers like to deliver. It's satisfying. When priorities shift and they have to move from one project to the next before the first project is finished it can be frustrating. This is known as context switching. Everybody understands that it happens sometimes. Sometimes is ok. Priorities do shift and projects do get canceled. Understood. However, if your dev team is getting yanked around from project to project without being allowed to finish anything, they will get frustrated. They will feel like they're working hard and have nothing to show for it. Frankly, if it's happening all the time, you are probably suffering from questionable management. Pay attention to context switching feedback. Watch your project portfolio and manage it carefully. Let your teams deliver.

Culture

It's not just about the cool code they get to write. Developers like to play too – and not just video games. You've got to provide and build an environment that people want to work in. Your culture will be uniquely your own. It will be made and nurtured by your people. Don't trample it – grow it. Encourage and organize group outings. Foster an atmosphere of positive feedback and teamwork and participation. Ask for and accept real and honest feedback in meetings. Don't just say “my door is always open” - that's lame. Reach out and pull people through the door. Much has been written about company culture – read up and embrace. The more you can create a sense of family and teamwork, the closer knit your team will be. Not only will they be happier, everyone on a close-knit team is more productive.

Use the right tool for the job

Some managers think that all developer resources are completely fungible. There can be a feeling that if project X is running late, you can shift someone from project Y to fill the gaps and pick up the slack. This is not true. Well, not all the time. Developers have strengths and weaknesses just like other humans. If you put someone that lacks the right skill set on a project, you will hurt the project, the team, and the new developer. Put the right people on the right projects. Know their strengths and weaknesses. Become familiar with their skill sets. Now here's the rub: when you have identified a weak spot, you must seek to build that skill up. If you have a developer that isn't up to speed on a particular project, develop a program or a plan to get them cross-trained. This accomplishes two things for the organization: 1) You wind up with one more trained resource that can fill in on that project when needed. When someone is out on vacation, you have bench strength to take over. 2) You keep that developer's interest by offering something new to learn. As a rule, developers love building up their skill sets. Cross training is vital to your organization and to your individuals and will help you always have the right tool for the job. Be careful not to confuse cross-training with resource allocation or moving people around to try to meet deadlines faster.

Educate

Educate your team. Pay to train your developers in new technology or to refresh or polish old skills. Yes, pay. Budget for it. It may not be reasonable for your company to formally train every developer on something new every year. That's ok, but you need to have a plan. Publish it. Make it fair. As in the previous point, developers like to build skills. If you help them, they stay engaged and grateful. Bear in mind, you shouldn't be training them to leave your company. Learning new tricks should benefit the firm too, so the plan must have a clear set of mutually-beneficial goals. Allowing self-study through book or online purchases is definitely a good thing and should be encouraged. Letting your dev team buy books is a pretty cheap way to keep them learning. However, that cannot be the sum total of your plan. Look for conferences, training classes, technology seminars from gurus, and the like.

I wish I could say that if all companies got all this stuff exactly right that there would be zero percent voluntary turnover. The truth is that some people will choose to move on even if you create the perfect place to be a developer. There are a lot of reasons why and not all of them are about you or your company. However, I can say with some certainty that, based on my personal experience, the more of this stuff you get right, the lower your turnover rate will be. The opposite is also true, if you erode any of these principles or just don't think they're that important, you will start to suffer some brain-drain. Don't let it happen, take some positive steps now to build up your development staff.

This article is intended as five quick bullet points with just a smidgen of info on each point. There is a ton already published out there on each of these topics. Start researching and learning more if you think you need help in any of these areas.

Thanks for reading,

Eric

Shameless Plug:

I have spent the past thirteen years writing code and managing teams of software engineers in the financial services industry. To learn more, look me up on LinkedIn.

Money pic from: http://flic.kr/p/az2SCh

Wrenches pic from: http://flic.kr/p/3YSKJ

Incremental Sustainable Change

Over the course of the past few years, my life has changed a bit.  Some changes have had external causes and some were internal.  In other words, some things changed because I changed them and some things have been beyond my control.  I suspect this isn’t much of a revelation to most readers.

The changes I have made myself have been an intentional part of my midlife journey.  I’m going to focus on one specific area of internal changes for this article.  No, I don’t call it a midlife crisis.  I refuse to label a series of positive, life-altering changes as a crisis.

As I was about to turn forty, I found myself engaging in some soul-searching.  What am I doing?  Am I happy?  Am I fulfilled?  Pretty typical fortieth year stuff, I think.  I hear a lot of folks do this in some way or another.  I was questioning myself, my career, all of it.  I decided, vaguely, to make some changes.  I wanted things to be different.  I was out of shape, a little overweight, etc.  You get the idea.  What follows is one piece of my overall journey and how I did it.

As I looked at the list of things that I was dissatisfied with, it a rather long and a bit overwhelming.  There were too many!  I couldn’t imagine all the changes I’d have to make to gain any headway on the list.  It’s not a new concept, but I decided to take a modified One Thing At A Time approach.  Yes, there was a daunting list, but if I could just focus on one item at a time, maybe I could make progress.  We’ve all heard the proverb that “a journey of a thousand miles begins with single step.”  I wanted to put that into action.  However, I needed more than just doing one thing at a time, I wanted to make lasting changes.  To become someone or something new, I needed to make new habits and replace old ones.  I set about doing this by making small, incremental changes that could be managed and nurtured into habits.  Over time, the collection of these new habits would define a new lifestyle.  I called it Incremental Sustainable Change, or ISC (yes, I’m a TLA nerd.)

I had no idea how disappointed I was with myself for being out of shape until I started exercising.  My first goal was a little vague, improve my lung function, asthma, and breathing.  Some more focused thought distilled it down to this: I didn’t want to run out of breath going up the stairs anymore.  That was my goal.  I started on a Wii Fit program.  Yep, I started with our Nintendo Wii.  It was like having a coach.  It helped set goals and track progress.  I started a short Wii routine and committed to doing it regularly.  After a few months of Wii-ing, when I’d proved to myself that I was serious about this fitness stuff, I thought about the next step.  I’d been doing some running in place with the Wii and that was getting tiresome.  Considering my goal of getting up the stairs without huffing and puffing, I knew I needed more cardio exercise.  I bought an elliptical trainer and started another new habit.  One habit at a time - that’s how ISC works.  I added cardio on the elliptical and kept strength training with the Wii (such as it is).  Soon enough, my elliptical training became habitual.  I was doing it regularly and seeing some benefits in my breathing and stamina.  Once again, I felt ready for the next step in my evolution.  I decided to try running.  At first, I could barely make it around the block.  Our “block” is about one mile around and it turns out that running outside is vastly different from the elliptical trainer.  I kept working at it - increasing my pace and adding distance just a little at a time.  Before I knew it, I was running miles.  It’s been a few years since I started all this and looking back, it’s hard to believe how far I’ve come.  I run for distance on Saturdays now, going for 10, 13, even 18 miles.  I’m even considering marathon training.  Just a couple short years ago, I couldn’t walk up the stairs without running out of breath!  Now, I’ve gotten my asthma medication reduced and the stairs don’t bother me anymore.  ISC has been bearing fruit.

As my running odyssey was evolving, I added some dietary ISC too.  One small change at a time.  I switched from a sugar cereal to Cheerios.  Once that was established, I added a salad to dinner.  And so on.  I’ve tried several dietary changes, but what has worked the best for me is a low carb, high protein diet with plenty of hydration and vegetables. It's sustainable - that's the key. It's not a crash diet to lose weight NOW. It's a new lifestyle that got me to an appropriate weight and keeps me there.  Oh, cutting out the mass quantities of candy and sweets helped too.  Sometimes that’s still a tough one for me.  One increment at a time.

I only ever made a change to my lifestyle or habits that I could sustain - and only one small change at a time.  No huge chunks.  I would only change something small enough that I could keep doing it over and over until it become a habit.  I didn’t start out running 10 miles.  I started with a short Wii routine and built up new habits over time.  I devoted myself to the process.  ISC became a habit itself.  I’d find myself asking, “what’s next?” and even look forward to the next change. 

Over the past few years, I’ve set and achieved many fitness and health goals.  I’ve run races, I’ve lost about thirty pounds, I eat healthier, and I move some weights around too (no more Wii - I've graduated).  All of these things come through ISC.  Make one Incremental Sustainable Change at a time, and you can meet your goals and keep them.

I now find myself considering the next step of my career journey.  That’s my next change.  I’d be lying if I said it wasn’t a little daunting.  I’m going to handle it with the same type of process that’s worked for me so far - make one Incremental Sustainable Change at a time.

Thanks for reading,
Eric


Afterward:
I’ve been on the software development and management side of the financial services and trading industry for the past 13 years.  To learn more about me and how I’ve applied ISC to software development, or to discuss career opportunities, look me up on LinkedIn.  http://www.linkedin.com/in/ejohns