Career advice

Facing job uncertainty? What steps are the right ones for your career?

I will have more to say about these issues later, but today, I just want to put out a simple, guiding maxim. Because it is simple, you can use it as the bedrock for deciding what to do. All my career philosophies flow from this starting point.

Simply put: Be Excellent.

There is a shortage of excellence, and there will always be a shortage. Managers kill themselves trying to find excellent people. Whatever your job is, be one of those people.

Yes, there are additional things you can do to help your odds, but all things start with your personal excellence. This is far more than half the battle.

When evaluating two jobs, take the one that provides the best opportunity to be excellent.

Do you find yourself stuck in a job that isn't challenging enough? Do your work efficiently, and then use the rest of the day on side projects. Come up some ideas that interest you. Dedicate yourself to them. You are truly reporting to yourself, and only you will know whether you "met your deadlines". The purpose is to challenge yourself, push yourself. To use a metaphor, if your goal is to run a good marathon, you have to be training constantly.

Excellence rises to the top. I fundamentally believe that. Stop worrying about the minor details, and focus on excellence.

Dogfooding

Jeff Atwood discusses a particularly vivid example of "eating your own dogfood". In software development, this means using the software you make, thereby displaying confidence in your product.

While I am a big fan of the philosophy, this doesn't really work if the software you make is not for a mass market or for developers. My jobs over the past decade have been creating trading systems and international shipping tracking. Not much use for that on my own desktop.

However, in an earlier post, Jeff says

if you can't dogfood, consider working the help desk for a few days. I'm serious. There's nothing quite as effective as sharing the customer's pain.

I can't agree more with Jeff's suggestion. Not only do you get a great view of what your customer is thinking, but you get a great view of what the team is thinking.

As managers, we sometimes get the idea, "Hey, I'm a manager now, I don't develop anymore." Or, as developers, we sometimes think, "Hey, I'm a developer, I don't do QA."

Yet, dipping one's toe in these other areas pays innumerable benefits. Some companies train their managers with a starting rotation on the front lines; I'm completely in favor of that.

In a previous job, I was put in charge of a fairly large group, where the programmers did both development and support. I took some shifts working the "hotline", taking calls from users.

Here are some of the specific benefits that came out:

• I got a deep understanding of the user's pain points (Jeff's point), which helped with decisions about priority.
• I talked to and developed relationships with a set of users I might not have otherwise me.
• I got a deep understanding of the cost of the user's problems, which helped with decisions about resource cost (for both fixing and not fixing).
• The technical and business skills and knowledge of each developer became apparent when trying to find the right people to help with a given problem.
• I combed through the code first-hand, getting a view of its quality and organization.
• I had to familiarize myself with the dev tools and processes.
• I received a first-hand view of how the team worked together.
• These activities were not viewed as "management prying" because they were part of an actual goal-oriented effort.
• Based on this knowledge, I devised a more efficient support and development schedule.
• Because the schedule was based on line experience, it naturally included many of the developers' own concerns, and not just a plan "dropped from the sky".

You will notice that almost all of these benefits accrued to me. Sitting on the help desk was not an exercise in altruism, or a heroic symbolic gesture.

This is not dogfooding in the traditional sense. However, being forced to live in the environment that surrounds you, that you contribute to -- developers taking a QA turn or going on a sales call, managers taking a developer turn or answering the hotline, etc. -- is the same philosophy applied differently.

Dogkenneling, perhaps?

Grass farming as software metaphor

Bruce Eckel writes that organic grass farmers show us something about software development.

What fascinates me about this is that it's the same old tools, applied differently. The farmer jokes about "being a grass farmer," but by seeing that everything hangs on growing the best grass that you can, I think he has cracked the code of farming.

The point is that you can drive revolutionary ideas by focusing on the most important input. I would add the same is true for driving excellence.

Best software dev books

I'm in the middle of reading Agile Software Development, and it has already cracked my top 5 favorite software development books of all time. A more detailed review will be forthcoming.

My five favorite software development books (with links to Amazon because the reviews can be helpful):

Code Complete by Steve McConnell
Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin
Effective Java by Joshua Block
Refactoring by Martin Fowler
Thinking in Java by Bruce Eckel

Also see this somewhat scientifically compiled list of the best software dev books of all time by Jurgen Appelo. Perhaps not surprisingly, three of mine show up in the top 10.

I see I have left off The Mythical Man-Month, which is a classic; very insightful and still highly relevant. That one probably would bump Thinking in Java, but I'm giving Eckel extra points for being a vanguard and publishing for free. I'm surprised more people have not followed this path -- and yes, I ended up buying a hard-copy. I haven't read five in the top ten.

On becoming a manager

I like this description of becoming a manager from Rands in Repose. If you're thinking you might want to be a manager, this gives you a pretty good idea about how you would spend your day if you're doing it right.

Your job as a manager is to scale the skills that got you the gig in the first place. You used to be the guy who did the impossible when it came to fixing bugs. Ok, now you’re the guy whose entire team does the impossible bug fixing.

One thing to keep in mind is the purpose of a manager. It's important to ground your daily maneuvers in a larger, meaningful plan.

I would summarize a manager's duties to the team as "empower, motivate, and mentor". It's that simple. Make sure your team has the tools. Remove obstacles. Find out what motivates each of them individually and figure out how to supply it. Personally train them. Use mistakes as moments for expensive learning, not prosecutions.

If you focus on these things, you will succeed. In focusing on these things, you will find yourself doing many of the items on Rands's list.

Software trade-offs

A couple of interesting summaries about very visible software problems.

1. Facebook algorithm to squash spam crushes real accounts. Does benefiting the vast majority justify screwing over a few outliers? Which trade-off better "serves the customer"?

2. On-line game Eve faces financial meltdown. The kicker is that, in a "Being John Malkovich" kind of irony, the real financial meltdown is causing problems for the software company that runs Eve. If money stops functioning in Eve, the game itself could suffer (who wants to be destitute in fiction as well as real life?) -- should the developers step in and fix things, as god?

Strange days

This is a weird time on the job. I work in the financial services industry, which gets hammered daily by new layoffs -- jobs that have disappeared and won't be back for many years, if ever.

And yet, right now there is a labor surplus. Because of all the uncertainty, many people don't have projects to work on, or their manager has been canned and no one's setting priorities.

Usually, people take an opportunity like this to relax. Phone's ringing? There's 3 other guys who can get it. New work request? I'll take a look after a long lunch, or maybe tomorrow since I'm leaving early.

Not these days.

Everyone senses that their job is tenuous. And for the first time in many of these people's careers, there's nothing to jump to.

So, instead, when the phone rings, it gets picked up during the first half-ring. I put in a PC service request that would usually take a few days to get responded to, much less resolved, and someone called me within a half hour, and then sat at my desk for the next 3 hours to solve the problem. People are helpful and polite.

Not to say that it was a bad work environment before. Just that people were very busy, and things often took a long time to get through the sausage grinder.

Just noticing the irony that the appearance of things getting done quickly and working especially well is actually being driven by things not working well.

Antipatterns by Philip Laplante

I loved the idea of this book. Knowing what you don't know, as a starting point, often helps you know more. True story: many years ago I considered writing a dictionary of what things aren't, an anti-dictionary. Some words are simply too big or too ambiguous to get boxed in. What is "life" for example?

Similarly, recognizing dysfunction can help you operate more functionally. This book tries to categorize the ways a manager or an organization can be dysfunctional.

One strong point of the book is that the list of antipatterns is pretty thorough. Most of them are instantly recognizable, especially if you've worked in a few companies. Some you recognize, but might not have thought of before as problems, like Warm Bodies -- people who should actually be let go, but just get passed around from one ill-fitting job to another.

The section I liked the best was "Identification". If you answer yes to the questions in this section, you may be facing this antipattern. Many times, these questions were not obvious, and helped illuminate the antipattern.

For example,

Everybody likes John — but no one can figure out what he actually does.

is a subtle way of identifying a Warm Body. I knew the antipattern, and have seen people like that, but never thought that the two might be connected (and of course they aren't always).

In addition, the writing was very accessible, and the authors allowed their personality to show, which always makes a book more enjoyable.

Noticeably lacking was what to do when confronted with one of these antipatterns. If you find yourself behaving this way, the advice almost always boiled down to "stop doing it." Not too helpful. Frequently, if you find someone else doing it, the advice was to "try to ignore it" or "schedule around it" or "sit back and laugh about it". Not too helpful.

An even bigger oversight was a lack of examples and explanations of why these behaviors occur, and what, if any, positives arise from them. They did a great job with Rising Upstart -- a young, very eager achiever -- recognizing that this is both a benefit and something that needs to be handled carefully. But most of the time, the antipatterns were treated as an illness that only ogres and irrational people would fall victim to. If these behaviors are rampant, there must be underlying causes.

For example, Mushroom Management -- the problem of managers keeping everyone in the dark (mushrooms grow in the dark) -- was rightfully decried as breeding suspicion, sucking down morale, and being ineffective. Still, some analysis about why managers do this would contribute to a richer understanding of how to deal with it.

One underlying cause is that more communication is not always better. In this depressed economic time, constant communication about the latest management thoughts on layoffs would be counter-productive. Management might be keeping their mouths shut because sensitive decisions are being made. Given that, what is the best way to handle the situation? That becomes a more meaningful discussion.

This book will be most useful to people starting their careers or those who are just beginning to think about moving into management. Many of the antipatterns can be avoided, and identification is half the battle. As an introduction to what not to do, this is a great start.

Cohesion and the financial meltdown

One fundamental attribute of good code is cohesiveness. A function with good cohesion does only one thing and does it well. There's plenty of material on this subject in books and on the web.

Sometimes, a good metaphor really brings it home. The current financial meltdown may illuminate the value of cohesion.

The problem with today's banks is that they were trying to do two things.
1. provide banking services to the public (individuals and companies): take deposits and make loans
2. trade and invest for profit

If a company loses money trading, no one really minds. If banks were only trading for profit (or a loss in today's market), we'd let them go under quietly, like the hedge funds.

Unfortunately, because they're also running banking services, people start worrying about access to their cash. The panic of a run on the banks would cause a global calamity. (We're talking large and institutional investors; deposits of small investors are generally guaranteed by the government.) In addition, because the banks need to manage their cash due to their trading and investment losses, they've stopped making loans. Solvent businessses who need a short term loan to expand or cover sudden cost spikes can't get funds.

As a result, we have to support the entire bank, even though we really want to only keep the banking services part. The cost of this lack of cohesion? $700 billion and counting. And that's just maintenance -- doesn't include refactoring.

Sadly, we once had a more cohesive system. It was called the Glass-Steagal Act, the expressed purpose of which was to "prohibit the large private banks whose chief business is investment business, from receiving deposits".

When was Glass-Steagall enacted? During the Great Depression, in order to prevent another global financial crisis.

What company was the the impetus for its repeal? Citicorp. They wanted to merge with Travelers insurance. Yes, the same bank that has received the most bailout funds and will be forced to break up. Here's a brief history.

Your code isn't going to cost $700 billion to maintain, no matter how badly written. But, as a percentage of your staff's time and budget, a systemic lack of cohesion makes a huge impact. Eventually, the changes required can overwhelm your ability to do anything without massive investment, e.g., throwing it away.

Open office spaces reduce productivity?

A recent study finds that open office space reduces productivity, results in more illnesses, and is universally disliked.

I'm going to take the unpopular side of this argument (with one caveat). I'm a strong believer in the social life of information, and I think cubes are a great way to facilitate that.

When I started working, everyone had their own office or shared one with one or two other people, similar to what Joel Spolsky advocates. This worked well, or maybe it just seemed normal because that's the way it was.

Sometime in the 90s, everything changed to cubes. I hated them. All cubes were the same then -- about 5.5 feet tall. They are the tall ones with the overhead storage in this picture. You could only see the tops of people's heads when they stood up. I would frequently think about how to enclose the roof and add a door. The lack of privacy really bothered me.

Then, around 2002, my new job had cubes about 4.5 feet high. It was a lot more open -- and I liked it a lot more than the taller cubes! If we had a production emergency, everyone could stand up and talk to each other. Communication was a lot easier. At some point, I was offered my own office (which had a good view), and I turned it down because I would be less productive: if I wanted any information, I would have to go around and ask people. In fact, I thought the partitions should be a little lower, maybe 4 feet.

Last year, I moved to a new location. The cubes here are about 3.5 feet high. Too low. You can see the person on the other side of the partition even when sitting down.

Based on these experiences, I think the optimal height is tall enough to not see anyone when you're sitting, but low enough to let everyone see each other when standing.

The caveat to this whole thing is that conference rooms that can also function as private phone rooms should be plentiful. Plentiful enough so that teams can usually meet at a moment's notice without a reservation. This alleviates the privacy issue and further encourages collaboration. You can actually take a tour of Joel's new digs.

Not having access to the study, it is difficult to know what it really studied. It's not clear whether loss of productivity is just self-reported, due to time out due to sickness and turnover, or actually quantified in some official economically measured way.

I'm also willing to bet that most of these offices didn't have enough conference / private rooms.

To do today

If you're a developer, you're asked to do a lot: deliver creative solutions on extremely tight deadlines that are robust enough to withstand unforeseeable and, frankly, unbelievable misuse and abuse from users. Meanwhile, you have to stay on top of technology, deal with the personalities around you, navigate all the infrastructure, and have a life.

I know all this. I once compiled a list of over a hundred attributes a coder could be evaluated on, and each of those could be decomposed into multiple sub-attributes, so believe me, I do know all this. I lived it for many years.

Still, I'm going to add something to your pile, near the top of the list.

Communicate with your user.

This means getting access as often as possible to product owners. Ask lots of questions right to the experts. Hopefully you do your own demos to them as well.

On a daily basis, you should see someone on the business. "Any reactions to the new order entry screen?" "How are the requirements looking for New Customer?" If it's 3 pm and you haven't talked to anyone on the business side, take a 5 minute break, walk to the trading floor or the sales cubes, or whatever business it is that you support, and ask "How's the market?" "You see what Competitor A released last week?"

If you don't have someone with whom you can do this without feeling awkward, that's a clear indication that you aren't doing this enough. Over time, you'll find some people who are easy to approach and open to talking to you.

Daily conversation keeps you in the loop. More importantly, it establishes a collegial basis on which to have difficult discussions that could come up later. It's going to be a lot easier to ask your sales expert questions about customer demand while setting requirements if it's not the first time in 3 months that you're talking to her.

Trade-offs

Possibly due to studying economics in college, I tend to see every decision as a trade-off. The absolute right decision in one situation may be absolutely the wrong decision in another, depending on the relative values of what is gained and what is lost.

Many times, a good answer arises to a question or problem, and we just go with it. It's a good answer, after all.

Still, I often like to review the other possible answers, even if we feel in our gut that they're obvious losers. If nothing else, it gives me peace of mind that I went through the due diligence. Even better, sometimes I learn additional aspects of what I'm trying to do by understanding the shortcomings of the other options. And then, of course, occasionally one of the "loser" options emerges as superior.

As I started my Python mini-project, I ran immediately into a decision: use 2.6.1, or 3.0? 3.0 is a major upgrade in the language, some of which is not backwards compatible. I hate to learn something that I know is going to be outdated, so I favored 3.0.

But, I decided to spend about an hour evaluating which version to go with. This was before I even knew any Python. Mainly, I got an assessment about the trade-offs.

First, I came to realize that, rather like a product owner on an agile project, I wanted to get functional value out of it quickly. If there was still time afterward, I could go back and learn more about the language (later iterations?), or improve the code.

Second, I realized I would likely want to use some library extensions to save time. Almost none of these have been ported to 3.0 yet. While there is a 2to3 migration tool, it is pretty primitive, and seems to only exist (as of this writing) for unix or linux, which I don't have access to right now. I also didn't want to risk having to spend time trying to figure out why a library wasn't working. Although that is a useful way to learn the language, in this particular mini-project, it would conflict with my first priority.

I found it somewhat painful, but despite my personal biases, I decided to roll with 2.6.1. I was willing to trade away being up to date for less development time (or just reducing the risk of greater time).

What do you do on your days off?

I'm not talking about your vacation days. On the days when things are slow -- you're a bit ahead, or you're between projects -- how do you spend your free time?

My theory is that your work on project deliverables solidifies your base. That's when you hone your abilities to write good code, create solid self-running tests. You take what you know and get much better at it. This is not the time to be learning a lot of new things, otherwise you'll never hit your deadlines.

But when are you going to try that new language, or test drive the new unit test components? Shouldn't there be time to learn about how the business works, develop better relationships with your customers, and see what cool things your colleagues have been coding?

That's exactly what you should be doing during your slow times.

When you're under the gun, that's when you're fine-tuning your expertise. When deliverables are not breathing down your neck, that's when you expand your potential expertise. You're like a crab going through molting stages; that's how you grow.

This may seem obvious, and if so, good for you. I don't think the majority of coders operate that way, so you have a leg up on them. They don't pick up a new language unless someone assigns them something that requires it, probably some maintenance work. The only parts of the business they know are the ones that have been assigned to them. If things are slow, that's a good time to shop online.

Some amount of frivolity is necessary for your own sanity. All work and no play makes Jack a dull boy. I've certainly taken my share of depressurization time. But be aware when you're doing it, and also think about taking a real day off on those days when it's slow and you need the break.

These days, on slow days, I've been experimenting with Python. I've had a vague interest in Python for some time, and have a silly web scraping exercise I'd like to do. It would be easier and more comfortable to do it in Java -- and actually that wouldn't be a waste of time -- but if I don't take the opportunity to learn Python now, when will I?

You are what you do... everyday

You are what you do is a popular phrase, and I'd add that you are even moreso what you do everyday.

For the last 6 years, I've played Go everyday for 10 minutes, because I think it's the best game in the history of the world, and slowly I've gone from having no idea what I was doing to being a middle-tier amateur. Someday I'll write a post about how Go relates to management, software design, negotiation, perhaps even the financial meltdown.

My plan is to write in this blog everyday (or nearly so). I want to take time everyday, even if only 10 minutes, to step back and think about what I'm doing or should be doing at work, or what's interesting in the software profession.

Similarly, a lot of Agile techniques have a daily focus. You don't build your test cases all at once at the end, you do it daily (assuming you're writing code daily). You scrum daily to check in with your progress and see where things stand. You rebuild at least daily. Doing things daily builds expertise, and let's everyone know that these things matter.

Part of why we, as an industry, have more than doubled our success rates on software projects is because we're smarter about our technique. We've created structure that creates successful behavior.

Think about what you do everyday, and there you will find that which you truly value. Does it match what's going to make you more marketable and build your skills?

Emergent Design by Scott Bain

Emergent Design presents Scott Bain's vision for turning software development into a respected profession. Just as medicine became professionalized as physicians replaced witch doctors, he argues software development can go through a similar transformation. Bain then runs through some principles, patterns, practices, and processes that reduce the mystery and thus the high fallibility of software development.

The industry has been on an upward trend, in large part to increasing acceptance into new organizational and coding techniques, including many that he discusses here. According to the Standish Group, the percentage of projects considered "successful" grew from 16% in 1994 to over 33% today. This book seeks to continue the progress by democratizing the latest development tools and concepts and increasing their usage through all levels of software organizations.

As a result, Emergent Design is primarily useful for three types of readers:

• junior to mid-level coders who have coded a bit and want to take it to the next level. Mid-level coders who don't think much about design and extensibility should be the first ones in line. Coders just starting out should probably get a few "Learn Java in 21 Days" type books under their belt first in order to see the benefits.
  


• experienced coders in procedural or older languages making a move to an OO language, and want to do it the right way.
  


• technical managers who are responsible for hiring and/or architecture, and ultimately responsible for the quality of the product that comes out of their shop.

The book covers a wide range of topics. It primarily focuses on key concepts of good code, design patterns, and test-driven development. The discussion on key concepts, for example cohesion, is particularly useful for the many programmers who didn't start out as computer science graduates, or as a review. His explanations run deep without being dry. The writing style is excellently conversational. He comes across as a teacher with lots of patience.

Bain's strongest skill is creating very simple metaphors to illustrate his points. Though simple, the metaphors really strengthened his explanations of the design patterns. I'll never forget the difference between the Decorator and Strategy patterns thanks to his metaphors. In fact, these metaphors help identify when patterns should be used, because unlike other pattern books I've read, he talks about what the pattern looks like -- in real life and in non-OO code. As a result you can recognize the need for the pattern as you're working out the business problem, not as you're writing the code.

As a result of reading his book, I've started following Scott's blog. He posts only about once a month, but they're good posts and, as expected, full of good metaphors.