Know the business

Financial markets continue to plummet.  Apparently.  I had no idea until someone mentioned it.  I've been avoiding all info about markets and financial turmoil, though I didn't realize how out of it I had become.

Which is odd because all my life I've preached that coders should deeply follow what's going on in the world of our users, which in our case is the financial markets.  It's a requirement for being effective.

I guess this proves, once again, the wisdom of the old adage, "There's an exception for every rule." 

I followed the previous meltdown, late 2008 through early 2009, intensely.  My workload was pretty light those days, so I had plenty of time to read everything about events as they unfolded.  On the day before the unveiling of TARP, I felt genuine fear for perhaps the only time in my adult life.

As a result, my productivity plummeted.  For months after things leveled off and things returned to normal, I struggled to regain my balance.  I had developed bad habits.  (First thing to do when arriving at work: catch up on all the financial blogs!)

I don't want to be trapped in that hole again, so I learned to ignore the daily ups and downs, and maintain a narrower focus.

And I was reminded that even immutable requirements need to be open to re-evaluation.

Interesting thoughts

It's so easy to have interesting thoughts these days: the thoughts of the greatest and most interesting minds on the planet are, for the first time in history, available to us in near real-time.  To read them is to have them.

The richest man on the planet tackling the world's biggest problems.
Nobel prize winners on the economy, incentives, environment.
The top experts in any field you care about.

In the past, we'd have to pay thousands of dollars or buy a book of dated thoughts or know someone who knew someone.  Today, you can get the vast majority of it for free.

In a sense, expertise is becoming rampant.  How are you going to compete in such a world? 

The good news for you is that you only need one job.  Expertise in the current job will lead to the next opportunity.  Repeat.

Tailor your solutions to the situation.  In that domain, however narrowly defined, you can be the expert.  It will still require a great deal of knowledge, diplomacy, effort, risk-taking, commitment, and discipline... among other things. 

At the same time that it's never been easier to have access to expertise, it's never been easier to be your own expert.  Think about your unique domain, your unique job situation, and come up with your own interesting thoughts.

How much is a year worth?

Suppose your job has become slow and boring, but you're planning to go to med school in a year.  You could stay at your current job, or take a more interesting one-year job at a non-profit for 1/3 less pay.  Or, your company put you through school, and if you leave within the next year, you owed them $30,000. 

In these cases, do you stay at your job even though you aren't learning anything?

The question boils down to a year is worth to you. 

One-third less pay, or $30,000, whichever works for you, sounds like a lot of money.  On the other hand, sitting around not learning has three very real costs: 1) being bored sucks, 2) your skills are actually declining, and 3) you're foregoing the chance to branch out to new areas.

Our brains can quickly grasp the value of 1/3 of our paycheck, but the other costs, though more numerous, remain vague and thus valueless.  We end up calculating this as $30,000 vs nothing.

Of course, that's completely wrong.  First of all, all learning comes to use.  Second, think of how much more satisfied you'll feel at the end of each day.  And third but not least, you can use the year at a new job to take risks that could blow up -- oh, so that's what happens when you frankly tell VPs when they're wrong in a meeting -- or could turn out to be amazingly successful.  You can take the risks because, at worst, you'll end up out of a job in a year, which is where you'd be anyway.  At best, you might end up shocked at what you accomplish.

Unless you're retiring soon, or you're living on steamed rice and frozen vegetables and you literally need every dollar of your paycheck to get by month-to-month, the intangible costs will be far more valuable in the long run.

The fast-moving world of dentistry

Many programmers do their jobs, do it well, but never train themselves beyond their time at work.

I was thinking about this at the dentist's office recently. My dentist is not young, but she follows the latest practices. She replaced drills with air tools, which offer precision and obviates the need for anesthetic. She installed a laser for some of the gum work. Numerous other improvements have been made over the years.

This is dentistry we're talking about. Not exactly a lot of unexplored frontiers here. Yet, she clearly spends many off-hours staying up to date, obtaining information, and training herself. All that occurs when the office is closed, and no patients are around.

If that's the slow world of dentistry, what are the implications for the fast-moving world of software development?

If you're serious about having a successful career as a programmer, you need to be training yourself. Don't expect to do it on your company's time or your company's dollar. If you really can't afford it, at least park yourself at your local bookstore and read the books for free. Most of them have free wi-fi, so take your laptop and do the exercises.

While you're on a project, marching to a deadline, you should already be fully trained in the skills you need -- just as you wouldn't want your dentist to be pulling that laser out for the first time when you sit down in her chair.

Great traders and great programmers

I talked to an intern trader who recently finished his gig. His mentor told him at the beginning of the summer, "When you finish, I'm going to ask you what makes someone a great trader."

At the end of the summer, the intern gave some generic answer about financial calculations.

The mentor said, "What makes someone a great trader is what he does when things are slow."

How true, and the same could be said for programmers.

For any job that requires creative, highly educated people to work toward high pressure, difficult to move deadlines, the long-term differentiating factor will be how the person invests in him/herself. And slow times provide the only opportunity for that, whether 5 minutes or 5 days long.

Connect

Ever notice how some people become very active on LinkedIn when they start looking for a job? They join lots of groups, make lots of connections.

Or they start emailing old co-workers and managers. "Haven't talked to you in a long time -- how's it going? Any openings over there?"

Unfortunately, this is the wrong time to try to breathe some life into their network. They should have been doing that all along.

The ex-colleagues you know well enough to email in your time of need? Why not drop them a note now and then? "Hey, I saw this article about local micro-brews. I recall you had a big interest in that." Or "Here's an event next week with free activities for kids, thought you might want to take yours."

Cultivating contacts well takes time, whether they're people you worked with or new ones you've met in professional groups.

Does this sound manipulative? As if you're treating everyone as a tool for your own gain?

Here's a crazy thought: you could actually be interested in these people's lives! You got along well enough with your co-workers to feel comfortable later contacting them. Sending an email costs you nothing, and you could actually be doing them a favor. That's trying to connect with people, not just link in to them.

Give away your recipes

While trying to learn how to make sourdough bread, I ran across this site. The author gives away all his recipes and techniques in elaborate detail. Meanwhile, he's also trying to sell those same breads and get people to enroll in baking classes to learn those same techniques.

Doesn't seem too smart -- why bother to buy or attend class when all the facts are right there?

Surprisingly, that's actually a great way to build your career: once you establish your expertise, teach it to someone else.

One of two things will happen when you try to train others in your expertise.

1. they will learn it. That means it wasn't that complicated, not worth keeping to yourself, and likely to be "discovered" by other person soon enough. At least you got some goodwill out of it.
2. they won't learn it, or at least not as well as you. This will impress upon them how deep your knowledge is and cement your standing as the expert.

For the sourdough man, all those details hint at so much more that could be gleaned by spending a day with him. And given his command of all those details, his bread must taste awesome.

This strikes me as a kind of personal freemium strategy, involving one's own know-how.

More importantly, this demonstrates how mentoring, sharing your knowledge, and training your replacement are fundamental ways of advancing your career -- all riffs on the same theme, under different circumstances. Giving away your recipes is another way to say it.

After you become the expert, take a stand

You don't need to be a schmoozer or extroverted center of attention to be a leader in your department. You can also just know your stuff and be willing to stand up when your issues come up.

The Ben Bernanke that emerges from this account of the height / nadir of the financial collapse provides a fascinating example. (Unfortunately requires subscription.)

When White House officials first interviewed Bernanke for the post of Fed chairman, he was so quiet they worried that he lacked, as one put it, "assertiveness."

Sounds like the wrong guy for the job, and his television appearances haven't won any glamor awards.

But later, people scoff at his idea to give $85bn to AIG.

"Do you have eighty-five billion?" Representative barney Frank asked.
"I have eight hundred billion," Bernanke said, referring to the Fed's balance sheet.

You can almost imagine him thumping his chest.

Then, he needs to convince Hank Paulson to take drastic action beyond anything being contemplated. Keep in mind that Hank Paulson is as intimidating and strong a personality as you're likely to ever meet.

"Hank! Listen to me," he interrupted. "We are done!"

It was the first time Fed officials had heard him raise his voice.

"The Fed is already doing all that it can with the powers we have," Bernanke continued. One participant recalled, "Ben gave an impassioned, linear, rigorous argument explaining the limits of our authority and the history of financial crises in the US and abroad.... It was an encyclopedic tour de force."

It was as though Bernanke were the professor and Paulson the student. Bernanke's comments lasted about fifteen minutes, and Paulson was uncharacteristically silent until near the end.

The article mostly focuses on the other names, particularly Paulson, as you'd expect. These are just a couple snippets that I pulled out.

Bernanke doesn't really have a gift for gab, nor does he seem to like attention. However, he clearly inserts himself when he has to. He takes an informed stand, defends it, and is willing to suffer the consequences should he be wrong. None of these things Bernanke proposed had ever been done before.

Obviously, none of us are dealing with issues of this magnitude. Scale it down.

What major decisions are being made in your department? Which ones should you take a strong stand, even though you're not 100% sure it will work? The margin of error in our field is surely more forgiving.

Added value vs upside

How do people get paid? Often, the notion of added value comes up. Here's a classic description:

What you’ll find is that as you offer more “value” to the company, the more valuable you become. As a result, you’ll be the one most likely to get that promotion and/or receive higher compensation.

That's from an article about getting wealthy, which is ironic because I think that's exactly the wrong way to think about it. If a bigger paycheck is the goal, then you need to distinguish between "added value" and "upside".

Added value is backward looking. It's what you've accomplished. If you added value -- brought a project in under budget, on time, or with better features -- you will be paid an average salary plus compensation for the value you added. Therefore, it's true that the more value you add, the more you'll get. But, the company will pay you, by definition, only the amount that you added. Value out = value in.

Upside is an entirely different equation. That's because upside is forward looking. It's what you might accomplish. Since no one knows what that is, someone who thinks you have a large upside might pay you many times over what much you eventually add in value.

Here's some real-life differences between upside and added value.

Upside: 1st round draft pick. AV: 4-year steady veteran.
Upside: coding starts on new app. AV: 4 weeks after app delivered.
Upside: growth stock. AV: value stock.
Upside: MBA student graduating next year. AV: MBA who graduated last year.
Upside: first kiss. AV: marriage.

The hope that the big draft pick could be the next Michael Jordan always results in crazy money being thrown at him, even though its more likely they'll fizzle out. Similarly, dot-coms didn't have to have any earnings to have astronomical stock prices. And try getting a big bump in salary based on the MBA you got last year; the degree starts losing value the minute you get it, like a new car being driven off the lot.

In other words, people will pay based on speculation, until they know what you can do, and then you're capped.

Become the expert

Lately, I've been reading several Ralph Kimball books on data warehousing. If you want to learn about data warehousing, you start and often end with Ralph Kimball.

Years ago, when you wanted to learn about Oracle PL/SQL, you had to read Steve Feuerstein. For advanced SQL knowledge, Joe Celko was the dominant guy.

When Java was being democratized, Bruce Eckel reigned for a while, at least in my neighborhood.

I remember them because they were the top experts in their niche, so their names came up constantly. Truly remarkable knowledge, excellent teaching techniques, and unremitting enthusiasm on their topics, which they turned into great careers.

Now think about you career. It might be tough to be the national leader on C# or real-time trading, but how about something smaller?

How about being the expert in your own department on your internal data feeds or reporting capabilities? Or even better, a business-facing issue, like how you've implemented risk calculations or the workflow tracker?

To get there, first you have to know so much on your subject that meaningful conversations about it can't happen without you. But second, and this is easily overlooked, you have to be able and willing to teach everyone else, constantly and creatively.

Without the first, you're not an expert. Without the second, you're not someone others really want to confer with regularly. Combine the two, and you can discuss your subject at 14 different levels, from intern to senior management. Powerful.

The subject, of course, has to be somewhat deep and difficult, otherwise there's no need for your expertise. If there's a subject / business module / set of jobs that comes up a lot, and when it does, other developers try to deal with as quickly as possible (throw a patch at it and get out), that could be a good place to start.

The best early career advice

Every year a large number of "kids" enter our doors, fresh out of college, for their first programming job. After time-consuming and nerve-wracking selection processes and interviews, it is considered an honor and an accomplishment to be chosen.

Yet, I can't really figure out why. I can't think of one career-enhancing reason to start an IT career here.

And I don't mean just our bank, I mean all big banks. And really I mean all big companies, around the world presumably (though I haven't worked for big companies except in two countries, so that's speculation).

The best thing you can do at the beginning of a software career is to work for a small company.

After thinking about the many jobs I've had and the many careers I've seen start here, I could only come up with 2 solid reasons why someone might want to go big:

1. money
2. vacation time

The money is often better in larger companies, especially on the upper end. But, the money differential now is peanuts compared to the difference 3 years later between someone with deep, hands-on skills versus a mediocre programmer. Taking a job just because it pays more is like dropping out of college to help the family by working. Do it if you truly have to, but it's mortgaging your future away. Live at home or squeeze in an extra roommate, instead.

Bigger companies usually give an extra week of vacation. At small companies, a missing pair of hands really hurts because it's such a big percentage of the total. But what's that vacation for, anyway? I doubt anyone uses it to spend more time with the parents. OK, you'll probably have one less trip to the Caribbean every year, but if that's where your priorities are, then this post isn't really for you anyway.

Note that neither of these reasons are career-related, and that's my point.

Now consider the advantages of working at a small company. All of these come from simply being in an environment where there's fewer people.

1. constant direct, hands-on experience
2. more responsibility than you're qualified for
3. close proximity to or direct involvement in major technical decisions
4. constant interaction with senior developers
5. satisfaction of contributing a large, noticeable percent of the code
6. frequent interaction with company senior executives
7. easier to adopt new practices like scrum or kanban or whatever
8. frequent feedback (believe me, you will know whether people think you're doing a good job)

I could go on, but that's a decent high-level short list.

The early part of your career is the time to focus entirely on learning. Take from the experts; no one expects you to give back yet. It's almost unfair, but go ahead and be selfish.

Even if you've been working a couple years, as a mid-level coder, it's still a good time to jump to a small company. Come back later if you really want that extra week of vacation, and they'll probably throw a title and even more money at you.

It's like riding a bike

Think of your career as though you're going on a bike ride.

During the uphill stretches, it's tough to pedal, each crank a real struggle. Other times, coming downhill, it takes no energy, and you just enjoy it.

How many times have you heard about a friend of a friend who works at the cushiest job, comes in late, leaves early, takes a long lunch, works out and surfs the Internet for long stretches of the day, basically does his job in an hour or two? Naturally, your first reaction is, "Wow, that sounds awesome."

This guy is coasting downhill -- fun times, indeed.

Your second reaction is, "Why am I working so hard?"

Coasting is a blast, but every moment spent going downhill is an uphill climb you'll have to make later.

Meanwhile, if you pedal uphill, you know you can look forward to some relaxation later. Too much hard pedaling all at once, though, you'll get burned out, so you have to mix in a some easier times -- patches of level ground or slight downhill grades. Too much coasting, and you'll end up with a deficit to make up at the end.

Some people have coasted so long, they can't even contemplate making the uphill climb. You know some of these people, perhaps not personally, but you see them at large corporations or government agencies. Their only hope is to ride their current job and pray it doesn't go anywhere. When they're 50 or 60, their worries multiply, as they become less physically and mentally able to do something new, even if they could muster up the desire. They might hate their mind-numbing job by then, but what else can they do?

So, if you're pedaling hard, take comfort that you're building muscles and saving up for a nice, pleasant ride later.

Common knowledge that needs research

We already know this:

New research shows that 13 of 14 common workplace-relationship problems, such as broken commitments, mistrust and misrepresentation of information, occur more than twice as often with virtual teams, as opposed to teams located in the same building.

In short, the survey finds that distance ultimately does more harm than good.

We know this from experiences with off-shore development, which usually fails not because the workers off-shore are dumber or unskilled, but mainly because they are so far removed from the users and the power center.

I feel the gap of distance when half the team sits at a different location only a few miles away, and even though we all speak the same language and meet every couple weeks.

If the guy is next to me, I can see when he's got a free minute and I'm not interrupting him, so even though I might interrupt him constantly, it doesn't feel negative. He'll feel more interest in working on a problem with me, because I'm right there and we're talking, not some nagging email, another task to check-off.

Frankly, I notice the difference even between the guy sitting next to me, and other coders who sit a few rows away.

We know all this, so isn't research like this ridiculous? Sadly, no.

Managers like to create stories about how technology and virtual teams enable cutting costs, with no downside.

We developers like to believe we don't require personal interaction with our users, we can just send an email. Or we don't really need to collaborate, we can just work on our own hours at home.

Yes, some of the trouble can be mitigated with superior technology and tools. But there is always a cost.

If you're someone who works at home regularly, understand that it will be very difficult for you to grow your career. Perhaps you are looking for more balance in your life anyway, so that's fine with you. But if you still want to be on a growth track, you'll have to outperform by double or triple people who just show up.

Dead zones

Dead zones occur when the app you work on or the business you support stops growing and starts shrinking.

At first, it's not too bad: there's too many people, and so plenty of hands can help with any problem. Occasionally turf wars break out if people find others encroaching on their traditional area.

Then, inevitably, layoffs reduce the numbers, and the survivors take on larger work loads, usually involving mundane tasks far below their pay grade. Prospects for promotion or developing on new technologies plummet. Morale suffers. Welcome to the dead zone.

The first instinct is to run to your headhunter. I recommend regularly evaluating one's position for learning opportunities and career growth, so this obviously is as good a time as any.

But I also maintain that a dead zone offers some interesting aspects that can be learned from. Here's a brief list:

1. refactoring. During growth times, everyone pumps out code quickly. Slow times can be useful for revisiting things and doing it right.
2. good coding methods. While refactoring, basically you're learning how you should have done it. Next time you build something, you can now do it correctly from the start.
3. processes. What could have been changed in the org so that the "right way" could have happened the first time? Code reviews? Automated unit tests?
4. innovation. During growth, the solution to almost every problem is more people and more code. With strictly limited money and people, think of elegant and creative solutions.
5. expectations management. "No, can't do it" may become the answer to an increasing number of work requests. Learn how to say it while maintaining good ties with users and your boss, and without becoming Mr. or Ms. Negative.
6. team motivation. A stock-picker finds out how good they are in a down market, not by making 30% when everything's up. Same if you're a leader: are you really a good leader or just been getting by because things have been going well? Time to find out.
7. org experiments. Often, org resistance is down because people are trying to figure out what's going on. This is a good time to suggest things you haven't tried before, for example, iterations or daily scrums. Or, more radical things like combining the QA and analyst roles. You can sell almost anything as long as you can make a plausible argument around "efficiency" or "new skills".
8. new responsibilities. People will leave, responsibilities will open up. While some might not be that desirable, and some are, and can be claimed just by doing the work. Should things turn around in the group, you'll emerge as one of the veterans.
9. recharge. The overall pace may slow a bit. Invest in yourself: sleep more, read books, learn new technologies or skills.

The financial world, in the absence of being able to create new financial products, is creating lots of dead zones. They go by the name of wind-down groups and "bad banks". Other industries face similar situations.

Do not stay in this situation out of laziness! If that's in your nature, then force yourself to leave. But if you're a naturally ambitious person, this can still be an interesting, educational time.

Pride

After I recently graduated with my MBA, my dad said, "You must be proud of your accomplishment." My response: "Actually, I'm probably more proud of being able to swim a mile everyday!"

Over the past 2 years while in school, I went from being able to do about 12 laps max, to doing 32 laps on a regular basis.

In school, the curriculum was set up; I just followed the path. It takes work to get out, but it takes true incompetence and an unwillingness to make an effort to get bad grades in b-school. At graduation, they give me a fancy diploma and a big ceremony.

Meanwhile, the swimming was completely optional. Everyday, I set my own goal and then decided whether to meet it. Nobody else cared. Because of that, the swimming required real mental effort, real commitment.

Your job is the same way. Your boss and co-workers require things from you. But what are you doing that you're proud of?

Excellence is the best job security

A few months back, a friend asked me a question.

He was in the middle of developing several new major features for his application at his investment bank. Meanwhile, he expected layoffs within a few months. As a result, new features weren't being discussed until the layoffs occurred. Was it wise to finish off his work, even though that would leave him with nothing to do at the time that layoffs were likely? Isn't that like asking to be laid off?

Situations like these make me re-examine my motto "always put yourself out of a job." Maybe this -- a crisis of a lifetime in his industry -- was the exception to the rule.

But I told him that he should continue to work at his best rate. By pushing himself, he'd keep his mind sharp. He'd get to finish the project and understand it thoroughly. He'd burnish a reputation as a professional programmer who did excellent work. Whether or not his name ended up on the list, all of these factors would make him either a stronger developer at his current place of work or a stronger candidate for the next one.

Last week, his company did have those layoffs. But, we'll never know if he was on the list, because a couple weeks before, he accepted a great new job. Some of the experience he earned in his last project made him very attractive to his new employer.

I take no credit for his success; obviously, he did all that on his own. But it is nice to see one's personal theory get validated in real life, especially in a tough market like the current one.

Simple things to help keep your job

These days, lots of people worry about losing their job.

You might feel more comfortable if you knew all the source code intimately, were a technical genius in every architecture and language, and knew as much about the business that your app is used in as the people who use your app.

All good things to work on, but this post is about things you can do that take almost no time, effort, or money.

1. Show up on time. Most dev shops have fuzzy start times and fuzzy end times. Most developers start late and work late. Yet, consistently showing up on time signals that you are reliable. It helps others include you in important conversations or events. Few of us are morning people, but this is a small price to pay.

2. Call ahead when you're going to be late. I once got a call from someone at 11 a.m. saying they were going to be late and they didn't want me to wonder if they were coming in. Uh, I was already wondering. Again, the primary issue here is that you want to give the impression of being reliable. In addition, there's no excuse to call when you're already half way to work; call when you get up and it's already obvious you'll be late.

3. Attend group social events. If the team is getting a beer after work, you could get a soda if you don't drink. You don't have to spend a lot of money, just buy one drink and nurse it. This is actually a great way to strengthen your work relationships. Your interactions become more natural, and that can help you when, for example, you need to bother someone to get help sorting out your java threading issues.

4. Volunteer for internal groups. If your department needs a social planning committee, or the company is looking for members to join a diversity group, sign up. This will take a few hours of your time, which you shouldn't let interfere with your work, but you'll be making contacts outside your team. You can also try out some new responsibilities, like project management or dealing with vendors.

5. Give a presentation. What have you been working on? Offer to give a training. It will seem as if you are doing the group a favor; meanwhile, you're actually practicing your public speaking skills, sharpening your thought organization skills, testing yourself on how well you know your work, creating documentation, and interacting with people you normally might not or at least in different ways.

6. Be courteous and treat people with respect.

7. Tell your manager as soon as you think you might take a day off. Someone told me once at 5 pm on Thursday that, "oh by the way, I booked myself on a weekend getaway, so I'm taking tomorrow [Friday] off". Again, perception of reliability is being hurt, and you might be causing your manager real scheduling pain that could easily have been avoided. Maybe you're afraid that you'll change your plans? I'm sure you're boss won't mind if you decide to work on that after all.

In a sense, these things are free, always have been, and yet it surprises me how often people don't do them. Maybe the current job climate will generate a few converts.

One way to know you are good

Everyone thinks they're exceptional. After all, 70% consider themselves above average.

You can test how good you are by taking a job where you are expected to be a senior person: project or team lead, architect, technical expert. The newer the better: new industry, new programming language, new tools, new responsibilities.

Now, how long does it take for you to make a contribution to the team, to go from being a net receiver of information to a contributor, or, said another way, becoming someone who answers more questions than asks? How long does it take to generate unique insights about the application or the team's problems? How long until you become the go-to person in certain areas? How long before things emerge that only you can do?

If you have truly exceptional skills, the answers to all these questions will be "very quickly" or thereabouts.

Sometimes, you find out that what made you strong was just having been in your previous position for a long time or you've just been doing it longer, not that you were particularly gifted. Nothing wrong with that -- that's highly valued by any manager.

But keep that in mind when new people come, and they need your help or they don't seem to be as quick as you are.

Seth's blog

Seth Godin doesn't talk at all about software development in his blog, so I was surprised it at #3 on Jurgen Appelo's list of top 100 blogs for dev managers. Presumably most of those hits are coming from marketers, not software managers.

Yet, his is one of the first blogs I read everyday, and much of what he says directly relates to having a software career based on excellence and demonstrating importance through daily effort. As he marks his 3,000th blog post, he comments:

The hard part, as you can guess, is the first 2,500 posts. After that, momentum really starts to build.

He started back in 2002, so that works out to aboue 415 posts a year. Yup, he's definitely a guy who believes in daily effort.

Here's a fairly recent post -- a typical example of why I read him. It's aimed at marketers, but highly relevant to anyone building their IT career.

As you consider marketing yourself for your next gig, consider the difference between process and content.... As the world changes ever faster, as industries shrink and others grow, process ability is priceless. Figure out which sort of process you're world-class at and get even better at it. Then, learn the domain...

In IT, it's easy to get obsessed about content. Our resumes overflow with acronyms and languages, versions 3.7 through 8.13. As we work longer, we might pick up some knowledge about the industry we're in, such as financial services, so that goes in the resume too. It's all stuff we "know".

Meanwhile, what's really valuable is the process. Capturing that in your resume or identifying which job applicants understand the process is the challenge and the goal. How do you identify what is important to your user? How do you effectively test your code?

Practices such as Agile help draw focus to the process, but sometimes that just turns into another list of domain knowledge. What's a product backlog? How many weeks do your sprints last? This is all content.

The more important questions lie underneath these details. What's the purpose of a product backlog? Name some other ways to do the same thing, and why are they better or worse? That's process.

I highly recommend Seth's blog for anyone interested in thinking about how to do their job excellently.

Path to excellence

How can you excel in your job? Go deep and go wide (but not at the same time).

Going deep means becoming an expert. This can simply be a manifestation of doing something very well: learning about what you're doing, instead of just trying to get it off your plate as fast as possible.

One person who worked for me coded up some trade feeds for regulatory purposes. As she went along, she spent the time to learn a lot of fine-grained details about the regulations and what that meant for our system. Eventually, every meeting involving coding changes (because the regulations regularly change or have exceptions) required her presence.

Another guy wrote a feed to send some data to a central database for management reporting. The feed required some calculation pre-processing, but otherwise, it was pretty straightforward. In doing his work, he came to fully understand the nuances of the calculation on our side and how any changes would affect the aggregation. Eventually, he learned so much about this overall business process that he stopped working for me and started working for the business side.

By going deep, you become the go-to person on a subject. You can go deep on a technical language or a complex application module. You become the state of the art for that art. You demonstrate high competence in a public, understood way.

Going wide means picking up new skills or knowledge. The key to going wide is that the value is unlocked only when you combine the new with the old.

My friends who worked on the trade and data feeds combined their programming skills with a business process they previously knew nothing about. They did an excellent job of combining the two.

What you can't do is learn something totally unrelated to what you are doing now. Eventually, this could pay off for you, but it could be a long wait, and it won't help you excel today. You are a newbie in the new field; your only advantage is your accumulated unique experience that you bring with you.

Here's a fascinating example of a guy who repeatedly goes deep, then jumps to something new but related, then goes deep in that. He started with industrial engineering, becomes an expert in gun manufacturing ("I probably know as much, or more, as any one single person about manufacturing guns," he claims, credibly), moves into robotics. Then,

A few months ago, Baber decided to design his own mini-helicopter, one light enough to disassemble and carry in a backpack. After a successful test flight in January, he is currently busy building [modifications].

Yes, these are all related fields for him. This example shows that, if you truly master this process, you actually create your own "industry". Here's the summary (and the full article, requires free registration).