Andrew’s Blog

I have been spending some time today mentally preparing for the upcoming week. We are getting ready to begin planning and architecture on a big project at Live Oak, and it is bringing many new technical challenges that I have not directly dealt with before. I have been stressing for the last couple of weeks to figure these things out: which libraries and frameworks to use, issues with scalability and extensibility, the database layer and ORM, the list goes on. I want it to be utilizing only the newest and greatest techniques, but there are so many options out there that I don’t know where to begin.

As I think about it today though, I am feeling  better about these details. It is not that I have figured everything out in some kind of master plan. Rather, I have begun to think about this project from the other side of the screen: the end user. Like a novel, every line of code that we developers write translates into a unique experience for the end user. Applications, like philosophy or a work of poetry, can either take the end user to a place that is more clear and understandable or can lead to frustration or disconnect. The important thing to remember though is that no technology in and of itself necessarily creates this dynamic experience for it’s users.

Think of your favorite application - what does it convey to you? Gmail is one of my favorites. Gmail tells me that I can make sense of a barrage of information through filtering and tagging and stringing together threads of communication. Moreover, it is an inspiration in the sense that it is as fast and efficient as a desktop application because of the awesome architecture under the hood. I have been using Gmail since very early in it’s life in 2005, and have seen many different technical iterations that were inspired not just by new cutting-edge browser technology, but rather by painstaking attention to what would create the best user experience. That is to say, the client experience necessitated the cutting edge technology and not vice versa.

I think it is easy to forget this as a developer. We spend so much time working on the nitty-gritty details that make things work - which is essential, but often uninspiring. We want to see cutting edge techniques and elegance under the hood. But when this becomes frustrating to do, it is easy to become disillusioned with the whole process. In short, we often put the cart in front of the horse. I think this is less of a danger when the technology that we are utilizing has been carefully chosen to create a particular user experience. It is no longer an issue of technology as an end in and of itself, but rather as a means to something greater.

So I am going to try this week to remember the human side of the software that we are envisioning and architecting. The important thing to think about at this stage of the game is not the inevitably complex architecture of what we are about to do. Rather, we need to develop a clear understanding of the experience that we will be creating for the end user. Once we have paid adequate ettention to these big elements, the rest will be easier to conceptualize and architect.

As I was writing in my journal this morning, I started thinking about the many events in my life that led me to my current career. I’ll spare you the gory details of the typical “college grad meets the real world” story, but there is one factor that cannot be underrated in my journey to become a software developer: mentoring.

Coming from a nontraditional background, I never learned programming in any kind of academic environment. I picked it up while working customer service at a small software company, and played around for months before I tried writing some demo apps and then later started working on some of the internal applications that were used by only a few people. I found programming syntax to come pretty easily since it is just applied logic. However, it was the application architecture that started to get the best of me when I realized that I was running into common problems that had to have simpler solutions than the ones from which I was approaching them.

At this point there were several key people who I turned to when I got really stuck, but one in particular really took the time to actually mentor me and began to patiently sharpen my programming mind by teaching me about design patterns (or more importantly, how to use them to solve real life problems), showing me examples of code that he had written, and describing lessons that he had learned. I am not sure that I understood how important this was at the time, but looking back it is clear to say that I would not be where I am today were it not for his involvement at this pivotal point in my life.

This brings me to my reflection in my journal from this morning (and maybe a little call to action). I am no expert and most certainly have a long way to go still. However, I have learned a few lessons and am beginning to wonder if I may may be able to also play an important part in an upcoming programmers life. The most important thing about mentoring is not knowing every little detail, but rather, encouraging someone to stick with it and to either develop their love for it, or to realize that there is something better on the horizon. As such, I think there are a few key characteristics of successful mentoring in the world of software:

• Take risks - there is no reason to protect a new programmer from your code (that is what version control is for), assign real tasks that will stretch his or her abilities. It is this kind of real world trust that builds confidence.
• Don’t give too much preemptive advice - Allow him or her to take a stab at a problem and then help when asked.
• Frequent code reviews - Once the code is working, walk through it and spend time identifying patterns, pointing out optimizations, and talking about alternative approaches. This helps to frame all of the explanations in relation to problems that have been recently addressed by the programmer
• Warn against pre-optimization - Teach that the first priority is to get something that works, second to that you figure out if there are any bottlenecks that need to be optimized. This one took me a long time to learn, as it was made apparent to me that I spent way too much time analyzing problems because I was so worried that I would slow down the application. I became much more efficient when I learned this simple lesson.

I am sure that this list is not complete - so please add on in the comments if you have any other suggestions. In the meantime - get out there and see who you can encourage someone in their quest to become a good programmer!