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.

Programming and Philosophy

“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

“That forces you to sort it out in your own mind. And the more slow and dim-witted your pupil, the more you have to break things down into more and more simple ideas. And that’s really the essence of programming. By the time you've sorted out a complicated idea into little steps that even a stupid machine can deal with, you've learned something about it yourself.” --Dirk Gently’s Holistic Detective Agency, Douglas Adams

I once read a posted question from a person asking advice on what degree to pursue in preparation for a computer game programming career. My answer, in its entirety was:

Although it's been awhile since I left college, I know several universities are starting degree programs that are geared more toward practical applications of programming skills. Whether it's called "Computer Engineering" or "Informatics" (A word that's always somewhat bewildered me) these degrees are more centered on applying the concepts of Computer Science.
In other words, you won't learn how to write sorting algorithms, but you will learn how to use them in various platforms. Take for what you will.

Personally, I don't care. Give me someone that can mentally deconstruct a problem and think through a practical solution. They can be taught to be good programmers, assuming they haven't already learned. In a lot of ways, I'd take someone with a philosophy degree. Someone who is used to asking what the nature of an object is and it's role in the system it resides in is a heck of a lot more useful than a "Cowboy Coder" that just blasts through something to get a project done.

 Without software development, programming is ultimately a pointless exercise. Computer Science is intellectually stimulating and a necessary part of software development. However, unless applied for some practical use it is nothing more than theoretical pedantry. And while Computer Science is encompassed by Software Development, it is by no means the most important aspect.

Software development is about solving a problem. Whether it’s “I need an online application to sell my product” or “I need a game on my mobile device to pass the time”, software development fills a need. And in order to fill a need, you first have to understand the need and the domain in which that need will be filled. These are not trivial points, nor are they tasks left to a business analyst or some such, although it is up to such a person to help the development staff understand these things.

A teacher of mine, back when I began learning about software development, told me that programming is about creating idealized models of real world concepts. In order to implement a payment processor, for instance, you need to create a software analog of the concept of a payment. Of the machine that accepts the payment. Of the items you are paying for. And in order to create accurate models of these real world ideas, you need to understand them, what they do, what they know and are responsible for, and how they fit into the whole. Again, this is not a triviality. Creating a model of a payment that knows about the items being purchased causes problems when it is time to create a new kind of payment or a new way of representing the items being purchased. Just as creating a shopping cart that knows how to pay for its contents causes problems when a new kind of cart or payment is needed. This is a fundamental concept in software development and one that can not be properly implemented by someone that doesn't understand the problem to be solved or the domain in which it is to be solved.

This is the reason for my comment. I don’t care if you can swap variable values without an intermediary variable. I don’t care if you can hand-code a sorting algorithm or think you can write a better encryption scheme or algorithm. In fact, in order, I say “Who cares?”, “Use a tool”, and “No you can’t. Use a tool.” I care if you can ask the questions “What is this? What does it mean to be this? What does this thing do and what does it know?” I want someone that can deconstruct a problem and break it down into little steps that a stupid machine can understand, thus increasing his own understanding of the problem. Without these abilities, a developer’s actual programming ability can only be properly applied by accident. In other words, in order to become a successful software developer, one must first become a philosopher.