Why do I write code? That question, and many others, answered here.
How long have you been programming?
I can’t believe I’m about to say this, but I’m going on 40 years (39 professionally). My addiction 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.” My parents gave me a Heathkit “kit” computer that Christmas, 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 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 enjoyed doing was thrilling. The fact that this egotistical oaf paid for it was the 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 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 collaborative effort — the occasional pressures and accomplishments — it’s a fantastic 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 improving how a group of people performs 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 can 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 intoxicating. 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 some people 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 learning opportunities when jumping 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 ensuring the middle layers work more intelligently, which usually allows you to trim out what the front end needs to worry about. Likewise, working with the front-end and listening to users’ feedback enables you to optimize the user experience and build an app that people will 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 unique. 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. My 40’ish years have given me experience 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 is irrelevant.
How do you remain current?
After being asked this one a few times, I started using it to 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 practical “go-to” sites or blogs that you may find out about when asking this question, I am generally looking for 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, there’s almost a permanent “feed” of knowledge. It’s nearly 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. However, without a bit of context, it is also impossible to answer. 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 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, we need to think of their strengths and the time required to “ramp up” with a specific 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 development is not free, nor is it instantaneous. The bottom line is that there is no one “correct” technology.
Have a question I didn’t cover here? Please shoot me a note at: email@example.com