After 16 years of developing Internet based software, I’m about to take a very new direction in my career. No, I won’t be MMA fighting nor am I becoming a nutritionist or an interior decorator, though all three I’ve considered at one point in time. Instead, I have an amazing opportunity to leverage all I’ve learned since I first entered the professional field of Software Engineering back in 1998. Starting in late July, I’ll be joining Iron Yard full time as a Ruby on Rails instructor here in Tampa Bay.

What led me to this

Few of the applications I have created over my career are still up and running. The many Miley Cyrus sites I built are long gone. The billing hub I helped architect and develop for IBM has since been replaced as has the encouraging support app for the New York and LA Marathon’s. Apps I created on my own (WeAreTampaBay.com, PeepNote.com and others) are also all since shutdown. All these apps effected people on a daily basis for the period of time they were in place. Most of the apps listed above resulted in thank you notes from it’s users (except the billing hub). But it’s inevitable in this fast paced industry that software will be replaced on a regular basis. We understand this as developers and we deal with it and move on. Yet still, it’s difficult to look back and see very few evidences of your life’s work still in place.

I grew up a teacher’s kid and then eventually a pastor’s kid. Both can be difficult labels to overcome as a child, but I wouldn’t trade it for anything. I had the blessing of seeing the lives my father touched on a daily basis. Even to this day, I bump into students of his from more than 25 years ago who still remember how my dad touched them and educated them.

Similarly, what remains to this day of my development past are the relationships and the people. I’m still in contact with at least one person from eleven of the twelve companies I’ve worked for. While at ValPak, I had the opportunity to hire several non-developers and mentor them toward becoming developers. Most are still in the industry full time. For me, it’s always been about effecting people and improving their lives. That’s why I write software and that’s why I’ve always enjoyed mentoring, teaching, and coaching.

Over the last year I’ve been pulled more and more toward the idea of training even though I didn’t realize it was happening. In fact, I’ve been involved in teaching in one way or another all my life. I tutored in college. My wife and I made the decision to homeschool 11 years ago. I’ve taught Sunday School at my church. I founded Commendable Kids in 2010 and still work on it to this day. Last year after freelancing for years, I interviewed for two positions: a well known online code school and a position on the Training team as a developer at GitHub. I honestly didn’t even realize the similarity between the two positions until recently. I ended up joining GitHub to work on some training software and while there, I clung to the training team and loved to watch them teach. The teachers on that team made a huge impression on me that I now believe moved me even further in this direction. When that software project was canceled and I was no longer needed on the training team, I had little interest in joining another part of the company. At the time, I didn’t realize why all of this was happening and what effect it was having on me.

A few months ago, a company I’d never heard of, Iron Yard, was mentioned in conversation to me three times in the span of a week. Even then, my first thought was, “I’m a developer, why would I do that?” Thankfully, my family pushed me to reconsider and be open to something outside my immediate comfort zone. As I began reading about the Iron Yard and then talking with the founders, one after another, I felt such an instant connection. It was an opportunity to use all the experience I have to help others and impact them far longer than any application could.

Eventually I visited the Iron Yard in Atlanta and I was hooked. Even the short time I spent there with the students and staff was invigorating. Teaching students in 12 weeks is a challenge for sure, but to see them working hard, struggling, but persevering and becoming better people for it is so rewarding. It reminded me of the journey I began when I was 7 and am still on today.

In the end, I accepted a full time teaching position with the Iron Yard and I could not be more excited to help bring them to Tampa Bay. I’ll be teaching Ruby on Rails and also helping do all we can to support the tech community here in the area (another passion of mine as many of you know).

I won’t say it’s going to be easy, but I’ll do my best to help the students become the best developers they can be. If I can pass along some of my skills and experiences to them, and help them realize their dream of becoming software developers, it will be beyond amazing. I’ll continue to develop Commendable Kids and other apps on the side as well, because I’ll always love writing code.

The Iron Yard is doing some amazing work and it’s only the beginning. It’s such a blessing to be on board with them and I cannot wait to get started. If you aren’t familiar with them, check out their site and feel free to ask me any questions.

Or, more specifically, I am not a code developer. I wrote my first bit of code when I was seven, and have been writing software pretty much non-stop since then. I don’t know if I’ve gone more than a week, in almost 35 years, without writing code. Crazy.

As one might guess from that amount of experience, I’ve mostly always had a job that carried with it the title of ‘developer’. In the true sense of the word, that is very true. I do indeed ‘develop’ something. But in my industry, the term developer usually focuses on writing code. Once again, technically that’s true, I do spend most of my time writing code. Where I differentiate myself is where I place my focus.

Though I may often write as much code as any other developer, my focus is never on the code itself or the enjoyment of coding. From the very beginning, I’ve always written code so that I could have the resulting functionality: a drawing program (pre-Photoshop and Paint), a comic book tracker, a baseball stats tracker, accounting software for my church, a note taker for people I meet on Twitter (PeepNote), a motivational service for children (Commendable Kids), etc. I’m always creating something. Even as a kid I would spend my summers writing software all day.

In order to make a living, I’ve also, of course, written software for other people, organizations, and companies. The catch for me in those situations, was that since I don’t write code because I like the resulting code, I have to have an interest in the particular project I’m being paid to work on. This is possible to some extent when taking a full-time job, but very hard to do as a freelancer. In the latter case, I found myself sometimes having to work on projects I really didn’t care about, which results in me just writing code. Since that is contrary to what I’m passionate about, I lose energy and focus, and lack the feeling of real accomplishment and that I’m helping improve life using technology.

In the end, it’s about creating solutions and the code is simply a tool to get them built. If I were a building architect, I would care more about the resulting building than I would about the materials, tools, or methodologies used to build it. I do work on learning and refining those things, and often teaching them, but that isn’t where I get my sense of satisfaction, nor my energy.

I don’t get that excited finding new ways to code things, or fine tuning a loop to shave off a millisecond just because I can. I do enjoy streamlining the development process, even creating ways to be more efficient, but all of that is focused solely on the goal of creating a specific, helpful, life (or job) improving software solution. I just happen to write awesome code to do it.

One element of the modern web development movement that has long bothered me is to see how it ignores long established software development principles. Some act as though the only way to be “modern” and use modern technologies is to throw out the old and come up with all new. While development languages might improve, and we certainly learn new things over time, I don’t believe that these important software development principles, that have been figured out over years from trial and error, even from extreme failure, suddenly become invalid because of new technology developments.

The implementation of these principles may need to change, but never the underlying principle. Sadly, I would estimate that a majority of those calling themselves “developers” today don’t know the first thing about development. They have studied a language, whether it’s Rails, PHP, whatever, and they have learned it well enough to develop an average application that works. But without learning important software patterns and processes of development, all their skills with a particular language are built on a very shaky foundation. One that crumbles underneath the weight of a full size, heavily used application, and one that deteriorates over years of iterations on the same software code base.

Most developers today have never maintained the same application for years and have no concern in ensuring they can. They build it to get it out the door and get it online. They get paid. They close out with the client, and they move on. I see these apps on a regular basis and I have to fix them. Sadly, it’s usually at considerable expense to the owner, often having to start from scratch because the application’s fondation was so poorly constructed.

It’s far more important to understand these basic software engineering principles than it is to “master” a language. It’s great to think “outside the box”, but never just for the sake of doing it, or for the sake of being the person who came up with a great new concept. Solve problems that still exist, don’t solve problems again and again that already have a sound, established solution. Learn from others, particularly those who have more experience than you. Find out why senior developers work a certain why. Don’t assume that because they are “senior” their ways are the old, outdated ways, to be ignored and replaced. Sound principles and wisdom based on experience never lose their value.

As I transition from full time employment to being fully self-employed (starting in September), I’ve had the wonderful opportunity to talk with a number of potential clients from all industries, with all types of past experiences and varied budgets. In the last month alone, I’ve talked with over 20 different companies. During these talks I’ve learned one major thing that surprised me. I suppose because I’ve been working for individual companies for so long I didn’t realize there were so many misconceptions about developers, web development, and productivity out there in the business world.

Read More »

Recently, Matt at 37signals wrote a post about taking a break from your programming task after four hours.

The comments of the post took a detour from the main point, which was to stop and take a look at the task and your direction with it. However, most of the comments seemed to focus on taking a break when you are stuck. It’s true if you hit a wall, you should take a walk and try to get some distance from the problem. You’ll often then be able to see over or around the wall, or realize the wall is actually only a figment of your imagination.

But I think the point to this post was to take a break from your task, after you’ve spent about four hours on it (though the time should be in relation to the size of the task), and reassess your current status and direction, and most importantly, if the task should even continue to be done.

Sometimes we think of a solution, but while working on it we hit road blocks; things that we weren’t aware would be a problem. An example might be using a new technology we thought would solve the problem, but in doing so we introduced new problems. As programmers, as thus problem solvers, we get so focused on solving the problem at hand, we need to take a step back and realize that the direction we are going is more work than our nifty solution was worth. Adding this new technology, for example, might turn out to add far too much complexity, and require too many other solutions to get it to work.

There may be times where, after taking a break and re-evaluating, we have to go back to the Project Manager, Team Leader, or whomever you report to, and let them know the task is not nearly as simple as you thought, and more time needs to be allotted. After reporting this, you may find that the task you are assigned to is no longer quite so important to management, knowing it will cost them more.

I’d like to add, that taking breaks from tasks, and taking time to clear the mind, and step away, is such a vital part of being a problem solver, and yet it is discouraged by the very nature of the 8 hour work day modern IT management stubbornly continues to conform to. My personal belief, is that some days should be 5 hour work days, and others might be 10. Or, you may work four hours in the morning, and four in the evening. We need to be free to stop what we are doing when it becomes clear that we are no longer making progress for whatever reason. We could be tired, we could have hit an unexpected wall, we could have a personal issue that is distracting us. In many of these cases, its much more efficient to stop, and do something entirely different and come back to your work later, than to attempt to press through, and possibly waste countless hours making absolutely no progress.

This requires management to assess your effectiveness by what you accomplish on the project and with the team, as opposed to what hours you are sitting in front of your computer monitor. For some reason that shift in people management has been very slow in coming. I know some companies, teams, and managers that understand it, but I think the majority are still far behind; still stuck in the industrial age of management styles.

Read the entire 37signals article, “Four hours upfront and then reevaluate“.