The Binary Fallacy

Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth;
-Robert Frost, The Road Not Taken

Binary Thinking is the process of thinking of things in terms of two opposites. You can either do A or it's opposite B. But that's it. In Neuro-Linguistic Programming, it's a technique for manipulating someone into making the decision you want by framing the choice as a matter of either the thing you want them to do or the opposite, presented as a harmful choice. In Cognitive Behavioral Therapy it's a pattern to be broken to help people gain more control over their lives. In Software Architecture it's a warning sign.



If stuck between two different ways of designing something, the answer is always door number three.

Why do humans think like this? Why didn't Frost just keep walking straight through the woods and not worry about the roads? Why didn't The Clash stop worrying about staying and going and just Rock the Casbah? I don't really know. I'm not a psychologist. I'm just a software architect who's familiar with Analysis Paralysis. The phenomenon of getting nothing whatsoever done because you're locked up in the decision making process. And after years of trying to figure out how to avoid this, I came to one inescapable conclusion.

When you're in analysis paralysis it's because every path you're considering is wrong

In my opinion, this happens when you realize deep down that you're looking at the problem wrong and considering bad options. You can't decide because you know your options are both bad.

So what do you do? Well, that's the tricky part and adages about in which part of the box to think aren't as helpful as people who use them think they are. If thinking of something new was as easy as the realization that we need something new then Elon Musk wouldn't be quite the icon he's become. The important question is HOW? First, you just need to stop and accept the fact that you need to come up with something different. Your first decisions were wrong and you need to set them aside. Don't go back to them. Then I recommend you look at the great Stoic thinkers. You start by asking "What is this and what is it for?" I often tell developers to answer those two questions for every application, for every class they build, for every database and table they create. And you don't build the thing in question until you can answer those questions.

Then you ask if a thing is needed or just wanted. If it's not something you need, based on the answers to the above questions, then you leave it out. You strip away the irrelevant. Often I find myself locked up because I can't find a clean way of integrating the irrelevant into my design. Once I stop and realize the piece that doesn't fit doesn't need to fit, things get easier.

I've often said that software development is 90% thinking and 10% typing. If you understand how to think clearly, how to organize your thoughts, and how to tell the difference between the necessary and the unnecessary then there's little that can keep you from being a great software developer.

You've Got One Job

"If you choose to not deal with an issue, then you give up your right of control over the issue and it will select the path of least resistance." -Susan Del Gatto, Creating Balance in a World of Stress: Six Key Habits to Avoid in Order to Reduce Stress

Never forget that your only job is to provide a solution to a problem



Stick with any career long enough and you start to develop a set of principles that guide your approach to your job. Call it experience, call it being set in your ways, even call it wisdom if you dare. But we all do it. I've got about twenty of them, which I realized after an NCIS binge when I started writing them down Gibbs' Rules style. Rather than blasting them out all at once, over the next several articles I'm going to talk about each one. There's no particular order, other than the order in which I wrote them down. However, if I had to pick one to be the most important, it's the one I'm starting with.


Even at the beginning of my career, I never really thought of myself as a software developer. Rather, I thought of myself as a problem solver, albeit one who tended to approach solutions with code. But that idea has always stuck with me. Always be solving a problem.

Now, not all problems are created equal. Some are quite big. For instance, Linus Torvalds solved the problem of having to pay money for an operating system. Some seem almost insignificant. Recently I've been working on the problem of "I don't know Python as well as I'd like to". Something of import to almost no one other than myself. But that's the point. It's someone's problem, and it's getting solved.

Of course, what I'm really getting at is why you write software professionally. And while we all basically realize that we need to fulfill requirements, implement stories, or however we get the list of stuff we're supposed to write, it's easy to lose track of the big picture when you're in the weeds of the little picture.

The problem is that we, as software developers, don't just like to develop software. We like to develop cool software. However we define that, but usually as "the last new idea I read". Admit it- you do it, too. Goodness knows I do. We like to learn new things, we like to try new techniques, because we like, no we need to grow. This rule is to remind me not to take that too far. Ultimately, it's not about what I want, it's about what solves the customer's problem. Because if I'm not doing that, I'm wasting everyone's time.

I've also ran into situations where solving the problem didn't have anything to do with new software, custom software, or even software at all. I've on occasion been able to trim large portions out of a project with suggested business process changes. Or by pointing out that the requested software doesn't actually solve their problem, and on occasion might even compound it. A good software developer knows when to not develop software.

The idea of solving a problem is a big one, and one that spans several of the principles on my list. But this one gets its own item because it all boils down to this simple concept. You're not writing software to write software. You're solving a problem.

                                                                 

Dear Entrepreneurs

"Regard your soldiers as your children and they will follow you into the deepest valleys; look on them as your own beloved sons, and they will stand by you even unto death." --Sun Tzu

An open letter to entrepreneurs, from someone who has worked for quite a few of you.

Normally, I go through a lot of examples and points and then summarize at the end. This one is important to me, though, so I'll give you the summary now. Up front.

Your company is your baby. Not mine. You're invested, not me. To me, you're a job. Just another employer. Unless you do something to get me invested.

In my experience, a good number of entrepreneurs don't quite get this. I get that your company is your baby. You've worked for it, lost sleep for it, and probably skipped a meal or two for it. To you, this is personal. But it isn't to me. Not right away, and not just because you hired me. If I'm going to be personally invested in your company, in your idea, you need to give both reason and opportunity to do so. And it's worth it. If you're just a job to me, I'll walk away as soon as a better one comes by. If I'm invested, I'll have to be dragged out.

To that end:

Just because you believe, doesn't mean I do.

Most software developers I've encountered fall into one of two categories. First you have the mercenaries contractors. They work for the people who give them the best compensation. And I don't just mean money. Pay, benefits, environment, all goes into it. But as soon as they see a better place, they're a developer-shaped puff of smoke in the air.

Then, there are the developers who want to work for the company they work for. Because they want to be a part of what that company does. Believe me- those are the guys you want. But you have to give them a reason. And that's the bit that, in my experience, many entrepreneurs overlook. They think that the fact that they know how awesome the company is, then any employee should, too. Automatically.

Look- I'm a software developer and I'm familiar with the territory. A lot gets asked of us, and we take a great deal of professional pride in delivering quality work. But there's got to be a better reason than "Because I said so". If I'm working 50-60 hours a week just because "That's policy", then I'm probably going to have my resume out in a couple of months. Definitely before my one year anniversary. If I care, then I'll do what needs to be done, but you have to give me a reason to care. 

I've worked at both extremes of this. One entrepreneur mandated 50 hours a week, minimum, 24/7 support, and made us track our time down to the quarter-hour. For few benefits, and frequent communication that profit sharing and ownership would only come to those who deserved it. Which was, at least at the time, no one. I had taken the job in order to gain a specific skill set. Once I felt I had it, I moved on. I had no investment in the company because the founder hadn't given me a reason to care.

I went to another startup. The CEO gave regular meetings, not just on how the company was doing but why they were doing certain things. He told us quite frequently that his vision was to change a market in order to put more power and more control, and thus more opportunity, in the hands of customers. He ended every meeting with "Welcome to the revolution!" He believed. More importantly, he got others to believe. Nights? Weekends? No problem. Answer questions while on vacation- sure. Why? Because I wanted that company to succeed- still do, even though we've parted ways. And even so, I'm a touch sad about having done so. Because I believed.

New Challenges

"Be careful of what you wish for. You might get it".

Hard to say where that comes from, although some cite it as a misquote of Goethe. The image, of course, is from the amazing mind of Bill Watterson and his Calvin and Hobbes comic.

Regardless, that is kind of the source of why I haven't been writing much lately and why I'm starting again. I tend to write about what I'm seeing and experiencing. Which, over the last few years, has become fairly routine. After writing a good bit about my thoughts on Software Architecture, it became the task of taking my own advice.

So what changed? A chance to get what I asked for, namely a chance to go from helping insure quality in a software system to helping insure quality in a development team. The company I work for has a relatively new development team that operates fundamentally differently than our other teams. This team doesn't support a product. Instead, they handle smaller projects that have a more rigid "Definition of Done", as opposed to continued development and support of a product. This has come with more than a few challenges. Challenges that I have a pretty free hand to solve, but challenges that will take a lot of solving.

All this has put me in an interesting opportunity. Processes are getting built from the ground up. We have leave to borrow from other teams the processes we feel are helpful, as well as to ignore the things we feel won't benefit us. The end goal is increasing the rate of shipping quality software, and with very few exceptions I don't think the head of software development much cares how it happens. This gives me the freedom to take my biggest piece of advice to anyone designing software. Or, for that matter, anyone currently living and interacting with the world in any way:

“This, what is it in itself, and by itself, according to its proper constitution? What is the substance of it? What is the matter, or proper use? What is the form, or efficient cause? What is it for in this world, and how long will it abide? Thus must thou examine all things that present themselves unto thee.” --Meditations, Marcus Aurelius

In other words, "Question everything". Some ideas are worth leaving alone. Questioning the necessity of engagement between the business and development is a lot like questioning gravity. Feel free, just stay away from ledges. But how do you do these things when the business units aren't used to that engagement and don't understand the value in it. And that's not looking down on anyone- how can you know the value of something until it's been shown to you?

Beyond that, what traditional roles in Agile projects do we need? Which can we live without, and which should we live without? What do these roles mean, and how do we make sure everyone knows what an iceberg is?

What about the team? What common practices do we need? What offers us the best value in our situation. Not just what others are doing or what generally works well, but what works well for us?

These are the questions I'm asking myself and the ideas I'm exploring. I'm sure we'll go down some odd paths, and probably even the (hopefully) occasional bad path. And hopefully, my philosophy that understanding the world leads to understanding software still holds.

Dear Recruiters

Start with what is right rather than what is acceptable." --Franz Kafka

An open letter to recruiters. Mainly recruiters for software developers, but I suspect much of these are reasonable requests for all sectors.

1. Please stop saying "Leading provider of". Sure- you want to give the idea that your client is A Major Player. Fine. All good. But using rehashed buzzwords doesn't convey that idea. The phrase is like the paintings in a hotel room. If you even notice them, they have no real meaning. Instead, tell me why your client leads their industry. What have they accomplished? How do they lead? Is it through use of new technology? New innovations? Say something meaningful. Something that will have an impact.
2. Please stop telling me how many years your client has been in business. This may be useful information for clients, but potential employees aren't looking to retain their services. They're looking for a culture that fits. Generally, the amount of time a company has been in existence is irrelevant. Instead, talk about the culture. Not everyone wants to wear a suit and tie and interact with a rigid corporate structure. But not everyone wants to work in shorts and sandals, sitting on a bean bag, and walking into a Director's office for casual conversation. Laying this out will help find candidates that are a good fit for the company.
3. Proofread your communications. Twice. When I see "I think you'd be a good fit for [Job Description]", I delete the email. Same with blatant misspellings. Anymore, any text entry application comes with an automatic spell checker.
4. Read the resume. The most recent position is where your candidate has moved in his career and it's reasonable to think that that the position on purpose. If your contact is in a leadership, planning, or strategy position, it's probably a waste of time to offer direct development work. Your contact has moved on to something else and it's fair to assume that, barring unemployment, moving back isn't likely to happen.
5. Be specific. "Maintaining large applications" or "Excellent communication skills" doesn't tell me anything. Again, these are hotel room paintings. What I want is a good snapshot of my day-to-day activities. Does "Sr. Application Developer" mean "Application Developer with a lot of experience"? Does it mean "Responsible for the work of a development team"? If I don't know, I'm less likely to take a chance. And that's exactly what you're looking for. Someone who will take a chance on your job offering being better than the current one.
6. This is likely somewhat out of your control, but stop with the "X years of experience". While I realize that your client is telling you that, under the misapprehension that years of experience is an accurate measure of anything, you shouldn't have to tell that to candidates. If you can't tell from the resume how many years of experience the candidate has in the necessary technologies, then the resume has been badly written.
7. Same with this "Degree needed" or "Degree or relevant experience needed" silliness. Aside from this not being any measure of anything important, it's pointless to include in a communication to a specific candidate. If your candidate doesn't have the necessary degree, don't bother. Likewise with "Degree or relevant experience". If your candidate doesn't have either, they clearly aren't a good fit.

So, what's the bottom line here? Much like the fact that a good candidate needs to stand out in order to be seen as a good candidate, recruiters need to stand out in order to be seen as a good recruiter. You can't afford to be a carbon copy of everyone else. You can't just be hotel room art, and you can't hand over a vague description with ubiquitous buzzwords and expect to spark any interest. Instead, you need to capture the candidate's attention. You do this through clear and concise communication of what your client is looking for. You do this by standing out.

A thought to keep in mind. All the advice recruiters give to job seekers about how they present themselves through resumes and interviews? That should apply to your communications with candidates. Especially your first contact.

A New Perspective

"I believe everyone should have a broad picture of how the universe operates and our place in it. It is a basic human desire. And it also puts our worries in perspective." --Stephen Hawking 

"Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth." --Marcus Aurelius 

This  article falls more heavily under the "Musings" title of my blog. I'm less making a point than I am thinking out loud. As always, feedback and insights are always welcome.

My job responsibilities are changing. I phrase it like that because I doubt my actual title will change, merely the meaning of that title. I rarely handle project level work anymore. Rather, I'm more involved with enterprise level architecture decisions. I haven't implemented a design pattern in quite awhile. I find myself, instead, setting the standard of what patterns are best to use or avoid in certain situations. Or what frameworks we will be using or whether we will use an off the shelf solution or build our own. In other words, my implementation decisions are becoming less important than my opinions and experience with those decisions. I find this a very new perspective and more than anything else, I find myself more and more writing about new perspectives on old ideas.

For instance, take our current investigation into unit tests. The discussion started with "What mock object framework should we use?" We quickly boiled down to "Which framework will be unduly burdensome to the development staff?" This actually eliminated a couple of frameworks at the beginning. But when we settled on two that are, more or less, of equal use the conversation quickly changed to unit test standards. I have a few strong opinions on the matter. I believe that unit tests should cast a wide loop so that behavior consistency can be assured. If that means mocking Internal methods to assure their consistency, then so be it. If that means only using strict mock objects, despite their fragility, then so be it. In fact, I like fragile unit tests. If the behavior of the class changes then the tests should break. I realize that my opinions are not shared by the community at large, and I'm okay with that. I'm always open to debate, but I approach things somewhat differently than normal. I think I've made that clear. Now, of our enterprise level architects, one disagrees with me and the other is still weighing arguments and that's great. That kind of conversation is a new perspective for me.

So what's this new perspective and what does it give me? Because I'm no longer considering patterns and practices for a given set of circumstances, but rather to be followed in the enterprise, I have to more seriously consider the pros and cons of those patterns and practices. I find that thinking of effects of standards on the enterprise at large makes me think differently about the effects of my design decisions at the project level. Not just "Does this work here" but "Would this work in other, similar, situations and if not, why not?" If the answer to the second question is "No", then should I reconsider my decisions at the project level. Note that I'm not offering concrete conclusions here. I'm expanding my perspective and thus expanding the pool of questions I ask myself before making a decision.

Maybe that's my point here, although I expect I'll be getting comments about my approach to unit tests. That's fine, too. The day I stop listening to others is the day I stop being useful.

Tips for Standing Out

"If you don't get noticed, you don't have anything. You just have to be noticed, but the art is in getting noticed naturally, without screaming or without tricks. --Leo Burnett"

Recently, I have been going through our family digital pictures. There's quite a lot of them, and I'm afraid that I haven't been great about any sort of categorizing or even avoiding duplicates. So, with literally thousands of digital pictures, I'm sorting, organizing, and moving them to cloud storage. In going through them, I started wondering. I had just gone through 30+ pictures of dolphins at a zoo and was currently looking at almost fifty pictures of a gift exchange at Christmas (more pictures than there appeared to be attendees), and I started considering the value of an individual photo in the age of ubiquitous digital cameras.

Sure- I could have organized the images in a given folder by general context and then subordered the images within a context by general worth. Color and lighting quality, view of the subject of the photo, etc. Establishing a baseline to determine which photos are worth keeping and which are not. And after a great deal of time and effort, I could have come up with the absolute best images to keep.

I didn't. I deleted something like 80 images because after picking out a few that represented the scene or event, even going through the rest of them to see if there were any other good images simply wasn't worth the time. The value of each individual image was very low. If it didn't immediately stick out as worth keeping, it wasn't even worth the time to look further at the image.

It shouldn't be difficult to see where this is going, but let's keep moving, shall we?

So how do we, as developers, stand out from the crowd. It's tempting to believe that consistently delivering quality work will to this, but let's face facts. In this world of development teams, project teams, and managers that have so much on their plates that things just naturally fall through the cracks, this simply isn't true. Nope- not even for you. (Mostly directed at 10 Years Ago Matt, who honestly believed just this.)

So what helps people stand out? When a manager thinks of your department or wants to assign a person to a task, what can make you jump into mind?

How to Stand Out

1. Don't be afraid to pitch ideas. Don't come off as critical and certainly make sure you aren't taking time away from something else. But don't be afraid to try. Code is best communicated through code so don't rely on the clumsiness of spoken word to communicate your code ideas. Build a demo. Cite sources. Make a pitch.
2. Talk to people. When you talk informally with colleagues or even, if your organization allows this, superiors, you have an opportunity to discuss ideas outside the delicate context of "Here's a change I think we need to make". This gives a degree of safety to the discussion- you're not proposing invasive changes, you're talking shop. You're exchanging ideas rather than making a pitch. Again- don't be critical and don't be a pest. But participate in the developer community of your office. People remember contributors. "Head down, mouth shut" often also means "forgotten".
3. Don't be afraid to ask for things. Is there a project you want to be a part of? Is there another role you'd like to fill? Ask. Maybe the decision maker will agree with you and maybe not. But your odds of getting what you want increase sharply when you communicate what you want.
4. In order to do #3, you really need to take this step. Be honest with yourself on what you want and what you can do. A central theme to everything I've said here is that you cannot properly use something you don't know and understand. That includes you. Want to become a Development Lead? Understand, then, your leadership abilities and how you can best display the skills necessary for the job. Asking is important, but if you can't show that you fit what you want, then you won't get what you want.
5. Be the guy that asks questions and offers solutions. Everyone can criticize. Even if they're not being critical, any good developer can summarize a problem. The trick is to be the one trying to help reach a solution.

How to NOT Stand Out

1. Brag. We've all created elegant code and we've all come up with clever solutions. And we all like to talk about them. But there's a line between talking about things you've done and bragging. If you never talk about your accomplishments, chances are that no one will recognize them. If you brag, chances are no one will care.
2. Butt in. Again, there's a fine line between offering help and butting in. Chances are, if you're the guy that always has a better solution and can't let even the smallest issue go by without comment, you've crossed that line. This, too, will make you stand out.
3. Criticize. You want to offer solutions because they think they can help. Great. But if you want to offer solutions because you think the current implementation is bad/stupid/incompetent then you'll definitely stand out from the crowd. Just not the way you want.

Let's face it. There are a lot of developers out there. There are even a lot of good developers who deserve to stand out. But it's not the job of other people to notice you. It's your job to be noticed for adding worth to what you do.

Why Bad Code Won't Die

Let's face it. Code goes bad. Maybe, due to technical debt, it started out bad and now it's time to pay the note on your debt. Maybe, due to a new version of your software platform, there's a better way of handling what your application is meant to handle. And maybe your application is now handling situations that were not taken into consideration during development, whether anticipating them was reasonable or not. Whatever the reason, what was once perfectly acceptable code often becomes obsolete.

The challenge isn't writing code that won't go bad. You do your best, with the realization that it might just happen anyway. The real challenge is getting the situation resolved, because you can't just charge in and make changes- at least, I hope you can't. It's a sad fact of the developer's life that projects like this may be necessary, but are often rejected, leading to frustration and a lack of confidence in leadership.

It's a common failing in communicating with others. You assume that things that make sense to you make sense to others and that things that have value to you have value to others. It's human nature, really, to assume that the context in which you view life is the context in which others do, too. Because improving the quality of your code is important to you, makes sense to you, and is just intuitively obvious to you, you tend to assume that it is to others. Then you construct your communication, consciously or not, along that assumption.

The problem is that most development managers and just about everyone higher than that on the corporate totem pole view project priority in a completely different context than developers do. And since they hold the final decision on whether or not a development project gets green-lit, it's critical to understand why "Yes" to projects, why they say "No", and the thought process that goes into that decision. If you can tailor your pitch to the way upper management thinks then you can at least communicate your need in a way they understand. This, of course, doesn't guarantee anything. But you at least avoid getting in your own way.

Developers tend to consider a well structured application as the end goal in a project and as the motivation for taking, or not taking, action. Which is good- that's what they're there for. The problem is that upper IT management rarely, if ever, evaluates projects through that lens. To them, risk is the key decision point. Not just the risk of breaking something else due to the changes, either. Risk to the project schedule as a whole. Risk involved in an application changing- even if it's for the better. Users get used to the way an application works and there's often resistance to change. The unfortunate truth is that, in the mind of an upper manager, "This is better code" never trumps "This is currently working". Attempting to approach a "Code Improvement" project from a technical point of view will rarely work. In fact, it has never worked for me. Not once.

The first thing you need to do is explain the necessity for the change in the point of view of what is important to upper management. If you can't do that, learn to suffer in silence because this change will go nowhere. Since upper management's priority is a low risk of interrupting business processes, it is critical to show that not making the desired changes will lead to a greater risk of interruption than not making the changes. Risk of application failure is a great thing to focus on. So is inability to support known, or likely, business needs in the future. If the current state of the code is no longer performing well due to increased load, point out the trend in increasing load and try to project a timeframe for the application no longer functioning. Are there upcoming needs that either can't be supported given the current state of the application or can be implemented in a greatly reduced time given a change? Have hard numbers and facts. State the known needs that can't be implemented and how that impacts the business. Show how a project can be completed more quickly if the desired change is done now. Remember- upper management cares about how well the IT department, as a whole, can support business needs as a whole. Present your case in terms that are important to your audience.

Second, have a plan. Don't just outline a problem and dump the mess in someone else's lap. Explain how the problem can be fixed. Go on from there to how long you think it will take- remember, your audience is thinking in terms of a schedule of many projects. Scheduling an unanticipated project impacts the rest of the project calendar. Make sure your audience understands the impact and that the impact is worth it. Then outline the risks. This is important because as soon as you give your opening argument, your audience has already started thinking in terms of risk. Then present how you will handle that risk. Will other applications be affected? How will you minimize the impact on those applications. Will this change business processes? How can IT work with the affected business units to make sure they understand how to interact with the changes. What happens if something goes horribly, horribly wrong? What failure points will you be looking for and what will you do if they do fail? How will you minimize the impact of a massive failure on the business, how will you fix the failure, and how much effort might it take? How will the project calendar be affected, what projects may have to be put off in order to do this, and what can be done to minimize the overall delay?

None of this, of course, guarantees success. I've made pitches like this and heard the equivalent of "I understand, but we want to focus on new feature development". Or, "I'll take a closer look at this and see if we have time on the project calendar." Which is often a long way around of saying "No". Sometimes upper management simply isn't interested or just doesn't want to accept the risk. This happens. But management is never willing to accept risk they don't understand or change that doesn't seem beneficial. It's your job to communicate the need to fix bad code in a way that the decision makers will consider a high priority. If you understand how the decision makers think, you understand how to communicate with them.

Which, if you think about it, goes for life in general as well.

You're A Contractor

"If it looks like a duck, and quacks like a duck, we have at least to consider the possibility that we have a small aquatic bird of the family Anatidae on our hands." --Douglas Adams, Dirk Gently's Holistic Detective Agency

If you're not reading Hayim Macabee's Effective Software Design blog, you probably ought to be. His Continuous Learning post is an important read and got me thinking. The article is about how important it is for software developers to never stop learning and improving their skills. Which is true and something worth reminding people about periodically. But as I read, it occurred to me that continuously learning is only half the answer.

I started out in ColdFusion professionally, back when ColdFusion was actually a profession. (Sorry, Ben) There are a myriad of reasons why ColdFusion isn't a viable career option, some fair, some born of real misconceptions, and all irrelevant, for practical purposes, to a developer who has realized that he's in a dead end specialty. The reality of the situation was that I was working in a rapidly shrinking circle and it was time to get out.

Learning a new language isn't difficult. Getting someone to hire you for it is something else altogether. My employer at the time was generally unwilling to pay for training and even less willing to put new technologies or techniques to use. I had to rely on personal projects, online learning, a ton of reading, and the one Java bootcamp I could convince my company to send me to. I eventually found myself in a position where I was competent in both C# and Java and felt I could handle a development position using either language. But with no professional experience in either, getting a recruiter- much less a hiring manager- to agree was a challenge. And so I found myself in a Joseph Heller Catch-22. I couldn't get the professional experience I needed to get out of ColdFusion without first getting out of ColdFusion.

I have a lot of people to thank for helping me break out of that career black hole. A recruiter who knew me well enough to trust me when I said "Just get me the interview. I promise you I won't embarrass you". A hiring manager who believed me when I said "Learning C# is easy and you don't have to teach me how to be a software developer." A technical lead that didn't believe me when I said that and sat for almost an hour making me prove it. And finally (Warning- blatant sappy moment) a dad that taught me to bet big on myself.

The problem I had at the time was that the way I was viewed professionally did not match what I needed it to in order to advance my career where I wanted it to go. It was +Tom Searcy at Hunt Big Sales who put the problem, and the solution, in sharp focus for me. Everyone is a contractor. With that simple phrase, he put into focus everything that had been a problem for me when I was breaking out of the ColdFusion world. Ultimately, I work for myself, you work for yourself, and it's up to you to make sure that how you are seen professionally is how you want to be seen. This isn't about "job hopping" and this isn't about always being prepared to switch companies. This is about making sure that you can direct your career the way you want to direct it.

You direct and take control of your career path by both learning what you need to know and by getting seen being the kind of professional you want to be. Neither step is useful without the other. It hasn't been a good idea to try and bluff your way into an IT career for a long, long time now. And it does little good (Trust me!) to know how to handle the position you want if no one sees you as competent. You must do both. Hayim Macabee has outlined some excellent ways of handling the former. Thankfully, there are now more ways than ever to manage the latter.

Social Media

Not so much Facebook as Google+ and Linkedin, although that might just be my personal preferences. If you want to be seen as a skilled software developer, start by looking at the information people can readily gain by looking you up. Does it show you participating in software development discussions? Are you interacting with others? Asking questions? Offering advice? Joining, or even starting, conversations?

No? Then why not? A duck doesn't have to tell people that he's a duck. He quacks.

Projects

It used to be that recruiters and "resume specialists" would tell you to leave personal projects off your resume because they were no more relevant than hobbies in the job search world. Whether or not they still do, personal projects can be made relevant to how you are viewed in the industry. We all know that developers learn by doing. Now, it's easy to show people that you're both learning and doing. Got a project you're working on? Put the code on GitHub. Tell people what you did, why you did it, and ask them to use it. Is anyone going to hire you over a project you put out on GitHub or BitBucket? No. Probably not. But if you use these tools, then you are getting seen acting as the kind of software developer you want to be. It's part of managing your professional perception.

Blog

Go start one. Now. No- wait. Finish reading mine, then go start one. Be seen publicly talking about the things you want to be known for. Then tell me about it, and I'll put it on the list of things I read. And then I'll write about the stuff I think about when I read what you have to say. Talk about the subjects on which you want to be known as an authority. Then go talk to other people on their blogs.

Software Developers have to be continuously learning. But that's half the issue. If you want to be a duck, it's time to get out in public and quack.

The Ant, The Tiger, and The Programmer

“You have power over your mind - not outside events. Realize this, and you will find strength.” --Marcus Aurelius

“My weaknesses... I wish I could come up with something. I'd probably have the same pause if you asked me what my strengths are. Maybe they're the same thing.” --Al Pacino

Consider the ant. While pound-for-pound one of the strongest animals out there, since it weighs in at a stunning 0.0003 grams, that metric is less than useful. No, the greatest strength of the ant lies in a colony’s sheer number of ants and the fact that they can act with a single-minded determination to get a task done. Very little short of poisoning the lot of them interrupts their task once they begin and they have the ability for hundreds, if not thousands, act as if one being.

Consider the tiger. Tigers are not pack animals. Add a second tiger to a tiger’s territory and you’ll likely end up with a dead tiger. They do not like competition. And yet, as hunters go tigers are frighteningly effective. They can get to be 4 meters long (13 feet), weigh 600 kg (1300 lbs), can run at about 90 kph (55 mph) nearly silently, and are powerful enough to bring down a rhino or an elephant. Where the tiger walks, things that don’t want to be lunch best move carefully.

Two remarkably effective animals. One that can only follow orders, but carries out its task with a determination and undeterrence rarely found in nature.  The other nearly unable to work with others of its kind, but with a frightening level of individual ability. Both achieve their goals but in opposite, and incompatible, ways.

Despite having just called the two “incompatible”, a development team must be a colony of tigers. Considering the dev lead as the colony “queen”, each developer must be able to accept their marching orders and complete their assignments with the level of determination of an ant. Yet they must not be the mindless workers that ant embody. They must have the individuality of a tiger and a tiger’s ability to successfully determine how to achieve a goal and then the ability to actually achieve it. And the “Colony Queen”, i.e. Dev Lead, needs to understand that the tiger is not a mindless implementer of tasks and if treated as such then the overall effort is endangered.

We all know developers that are like the ant. Practically useless on their own because they can’t hold an application in their head or understand how various objects should relate or even how various pieces of functionality impact each other. But hand them a task and they complete it. We all know developers that are like the tiger. Highly skilled, able to intuitively understand the task at hand and how best to implement it. But get in his way, critique his code, touch his check ins, or even talk to him when he’s in the middle of something and he’s going to bite.

As a developer it is critical to your career development to embody the strengths of both the tiger and the ant while taking on none of their weaknesses. You must be a colony member that hits his tasks reliably. You must be a tiger that can rely on your own skill and experience. However, when your ability and understanding seems to conflict with your direction, you must be able to do something that neither ant nor tiger can do. You must be able to communicate your results and opinions to team leadership, do so clearly and helpfully, and understand that your ideas will not always be taken.

Make no mistake. This is the difference between a successful software developer and one that is perpetually wondering why he can’t keep a job. It’s not ability. Every developer I've ever worked with is either a tiger or an ant. The successful ones are the developers that can maintain those strengths without succumbing to the weaknesses. Are you an ant? Don’t become so focused on carrying out tasks that you forget that you can contribute your knowledge and experience. Not just repository check ins. Are you a tiger? Remember that at some point, you’re going to be overruled. Learn why, rather than biting. Is there a non-functional limitation, such as time frame or lack of stakeholder buy-in, that simple cannot be controlled? Is your preferred path incompatible with another development team’s work? Remember that setbacks are learning opportunities and treat them with grace. Remember also that others have skill and experience as well and respect that. Especially if you disagree with them.

Neither the tiger nor the ant will ever be anything more than what they are. Their weaknesses insure that they are only useful in narrow circumstances. Take on the strengths of both and the weaknesses of neither and you will quickly find that your organization find more and more situations where you are considered useful, or even necessary.