Why do I write code? That question, and many others, answered here …
How long have you been programming?
Can’t believe I’m about to say this, but going on 39 years (38 professionally). This all started back in 1981 because of a pompous jerk who insulted my dad. One of my older sisters visited with her boyfriend. While getting to know our dad, he mentioned how my father “would not understand” how great it was that he sat in an air-conditioned office all day “programming.” That Christmas, my parents gave me a Heathkit “kit” computer and I was on my way. I learned how to solder, build the computer, and started learning how to program. Admittedly, at first I wasn’t actually competing with the guy. However, a year or so later, he ended up buying a simple video game from me so he could resell it. The lil’ shopping spree which followed had me hooked. The thought of someone giving me money for something I actually enjoyed doing was a high. The fact that this egotistical oaf paid for it was simply icing on the cake.
So, why are you still writing code?
That “high” I mentioned above has never gone away. The act of breathing life into an idea, and seeing someone actually enjoy using it, will never get old. Some guys come home from work and turn a wrench as a hobby. Fortunately, I found a way to make a living with my hobby. There’s also something thrilling about brainstorming and building something with a team. In keeping with the “turning wrenches” analogy, it’s like working with a team to build a race car. Everyone has ideas and visions. There’s no real “winning” or “losing” within the team. You may be changing a tire one day or working on aerodynamics the next. That collaborate effort… the occasional pressures and accomplishments… it’s an amazing feeling almost every day.
What types of applications do you create?
Although they’re not as glamorous as an “Angry Birds” game, I prefer creating line-of-business (“LOB”) solutions. In short, these are the culmination of creating multiple “apps,” services, and databases to provide a much more significant “system” or “solution”. This type of effort also involves the creation of many utilities and processes (both manual and automated). I find these most enjoyable because they are directly responsible for allowing a company or organization to either overcome a hurdle or improve their business overall. They’re also chock full of countless opportunities for accomplishments. For example, delivering an improved user interface often means actually improving the way a group of people perform their job. Seeing the happiness in an end user’s face is incredibly rewarding. Even the unseen widgets one must create along the way are rewarding. Every time you implement a piece you are able to improve a process, increase reliability, decrease operating costs, or in some other way make the overall solution better. In short, this type of solution is almost a never-ending path of challenges and accomplishments. And, above all, the amount you learn about the company or industry, along the way, is invigorating. It’s almost like you’re watching a glowing “power meter” increase above your head.
Do you prefer back-end or front-end?
Both. While I realize there are people who mainly want to write pretty UI’s and others who prefer never looking at anything but text, I don’t think I would truly be happy in a position where I must always do one or the other. Even if my initial responsibility on a team is one end or the other, there are countless leaning opportunities when you jump into whatever that other area may be. For example, digging into the data helps you understand the “bigger picture” and business needs. This translates to being able ensure the middle layers work more intelligently and that usually allows you to trim out what the front end needs to worry about. Likewise, working with the front-end, and listening to feedback from users, allows you to optimize the user experience and build an app that people will actually enjoy using.
What is your favorite role in a team?
There’s an old saying, “Lead, follow, or get out of the way.” Let’s face it, I’ve been writing code longer than many of my teammates have been alive. I’ve run teams, architected products, built and sold companies, invented patented technologies, etc., etc., etc. However, none of those past experiences mean I am all-knowing or that I’m the greatest whatever. Every team is different. Every person is different. And, let’s face it, the technologies we used when I started are long gone. Heck, the technologies we used five years ago are virtually dead. What my 40’ish years have given me are experiences in a wide breadth of technologies, concepts, tools, and lessons learned. It’s also given me a solid belief that the best role for any person is one where they are both capable and needed. If the team needs me to act as a BA, work with the business, and write documents, then be it. If we need someone to analyze CPU and memory footprints to squeeze the last drop of performance out of a process or database query, then I will happily be there. Like I said, just having a seat at the table with your team, and participating in breathing life into that overall solution, is such a rewarding experience that the role or title itself if irrelevant.
How do you remain current?
After being asked this one a few times, I started using it when I interview people… mainly to determine what type of worker a person will be. Are they a “9 to 5’er”? Are they a geek? Or, are they just chasing a six-figure paycheck? While there are some useful “go to” sites or blogs that you may find out about when asking this question, however what I am generally looking for is how wide-reaching their resource list may be. There’s not a “correct” answer to this question. If people are genuinely in this field because they enjoy the technology, then there’s a almost a permanent “feed” of knowledge. It’s almost as natural as breathing.
Do you prefer technology X vs Y?
This is another one of those loaded questions. Granted, it’s a valid question, but it is one which cannot be answered correctly without knowing the context. Not every tool fits every scenario. And it’s not all about comfort either. What you are comfortable with today is not necessarily what you were comfortable with, or proficient in, two years ago. Now, there are reasons why I may choose one technology over another. For example, if I am working with an established team, then we need to think of their strengths and the amount of time required to “ramp up” with a certain technology or pattern. Finances are also a concern in most cases. Everything from the cost of licensing software, to purchasing or maintaining hardware, to the cost of finding or keeping qualified developers is a variable. Software develop is not free nor is it instantaneous. Bottom line is that there is not one “correct” technology.
