Good Code and The Art of Programming
To Senior Developer John Cooley, programming is simple. But producing good code is an art, and achieving it is a lifelong journey. We sat down with him at the Engineering Industries eXcellence headquarters to pick his brain about his work and what Manufacturing Software Development at Engineering is all about.
Q: In a nutshell, tell us about what you do.
A: My role is traditionally as a backend developer. I have a niche specialization in system integration, particularly ERP integration to MES. I probably do the best job and have the most fun whenever I am trying to translate a set of data from one system to another, and figuring out similarities and differences between them.
That is what I’m good at, but every project is different. And a big part of my job is being able to be thrown into a situation where you have no prior knowledge, then having to research and use existing resources to try to find a good solution. Another big job requirement is a certain confidence level and absence of fear when working on something highly specialized or technical that you haven’t seen or touched before. I don’t know if that is easily packaged into a job title.
Q: Why programming? How did you end up in the virtual world of code?
A: My first experience with programming was around the age of 14. It was in the age before MySpace, so if you wanted to have any web presence, you had to have your own website. As a young teenager, I had an overinflated opinion of my personal art, about which I was very passionate. So, I decided to learn HTML in order to build my own website. Ever since then, I have continued to teach myself coding on the side. I started with HTML tables and frames and moved all the way to server-side programming with PERL and PHP. All self-taught. I thoroughly enjoyed it.
When I started college, I wanted to go into biology. Halfway through the first semester of my freshman year, I came to a startling realization that I loved learning about biology, but I had no love for doing it. At the time that I realized biology wasn’t for me, I was already running a server out of my dorm room, hosting my own web pages, and I thought maybe that was the right road for me. Initially, I was deciding between electrical engineering and computer science. I was interested in both. In electrical engineering, you can do anything. I mean, you can build your own computer if you want, but it would take forever and be functionally useless. I ultimately enjoyed computer science more, because it had a better awesomeness to effort ratio. I found an environment I flourished in and I never looked back.
Q: Every developer has a belief system. What’s yours?
A: In the strictest sense, programming is really simple, and I believe it can be done by anyone. But the real difficulty in programming, which is a lifelong journey, is producing good code. There are more books than could fill a whole library written on what is and isn’t good code. To me, “Good Code” is like the Taoist concept of enlightenment; who knows if it can ever really be achieved in one lifetime or career...
Q: So how does one produce “Good Code”?
A: I don’t believe that programming is a strict science. There is definitely an artistic and creative side to it. I always think of programming as half art and half science.
In the earlier days of programming, say the 1960s and 1970s, a good indication of your ability to program was very directly related to your experience and knowledge of mathematics, and how adept you were at math. Now, using the more modern paradigms like object-oriented programming, a greater indication of success is your ability to think abstractly, to form hierarchies between concepts and really understand what similarities and differences they have, to categorize things so that they fit into your program. That’s easier when you are talking about a physical object, but it is much harder to do with an abstract concept.
As a programmer, you’re always fighting to write and design software that will make your job easier rather than harder in the future. You can write something extremely abstract and generic, a set of tools that can be applied to anything, but the result will be huge, convoluted and complicated. It will take a lot of effort to apply to each individual requirement. Or you can write something more specialized, but then you run the risk of not meeting a new requirement and having to retract, rewrite and restructure your program. In the end, your job and goal should always be to find a balance between these two.
Q: How do you make sure you continue to grow as a developer?
A: Especially at the beginning of your career, no matter what approach you take, things will inevitably go wrong. But you learn from your experiences and try to adapt moving forward. You create checks and balances organically through your mistakes. Every success and every failure creates a new set of tools to utilize and a new set of pitfalls to avoid. Basically, you remember the pain. And the next time you are writing, you take those past learned lessons and apply them. The more experience you have, the more it helps you grow and become a better developer. It pushes you towards a middle that works.
Q: How do you help customers?
A: There is no size that fits all design, no design that meets all requirements. If such a Holy Grail of programming existed, there wouldn’t be hundreds of frameworks and languages out there. There would be 1 book with 1 answer. And if that were the case, there would be no need for my job! So much of my job is taking my skill set, experience, knowledge and the information available out there and leveraging it to figure out how all of it fits into what the customer in front of me is telling me they want.
Q: Talk about working at Engineering and your team here.
The best thing about working at Engineering for me: everything is different on every single project. I have been here for 3 years, but it has felt like I have had 8 different jobs during that time. Every project you join here is usually with a whole new company and a whole new set of clients. A lot of the time it also means a new team of Engineering employees you never got a chance to get to know and work with beforehand. Every customer is a blank canvas, another puzzle to be solved. You are always on your toes. It’s never monotonous. It’s exciting, challenging, and it gives you the opportunity to be learning and growing continuously in your work. I wouldn’t have it any other way.
Meet John Cooley
Where You Were Born/Grew Up: Lake Forest, Illinois
Your Education: Bachelor of Science in Computer Science from Bradley University
Your Title: Senior Analyst Consultant
Your Practice @ Engineering: Manufacturing Operations
Your Office Location: Chicago, IL, USA
How Long You’ve Worked @ Engineering: over 3 years
Your Areas of Expertise: Software & Application Development, Manufacturing System Integration, System Design
