«    »

Learning in the Workplace

As I discussed in my earlier article on Perpetual Learning, I think it is important as a professional to always be growing and learning. If you work full-time, you'll have less time to spend learning at home, especially if you have other demands on your personal time (i.e. family). So you need to be able to maximize the learning that happens at work. The good news is that spending lots of time at work doing professional activities (i.e. software development) provides many opportunities to learn. However, it can also be challenging to learn at work: you may have many administrative tasks to do, or be doing lots of repetitive, uninteresting work, or are working on software or tasks you are extremely familiar with and don't really need to think about to do.

If you are really lucky, your employer will let you spend some fraction of your time investigating new technologies or product ideas. Google, for example, lets employees work twenty percent of their time (one day a week) on personal projects (some of which have ended up being adopted by the company and publicly released). Most of us are not that fortunate. So what can we do?

It primarily comes down to your mindset: you need to really crave learning opportunities. This means not only latching on to such opportunities whenever they appear, but pro-actively creating such opportunities as circumstances permit. You need to be willing to take risks and try new technologies or techniques, instead of always doing things the same way. And finally, you need to reflect on your work to look for places where you can improve. You might be thinking: great sentiments, but how do I do this in practice, in my day to day activities? Let me provide some examples.

If there are repetitive or routine tasks I am stuck doing, I look to automate them, especially if I have to follow the same manual process time and again. The classic example is the build and release process. It is fairly common for projects to have an automated build process, but fewer projects have an automated release or deployment process. Too many times I've seen a developer manually ftp the constructed software to the respective server, when a simple script can be written to do this automatically. Automating a task requires you to know a scripting language or two (I often use the java-based Ant build tool and scripting languages such as Perl), which is a learning opportunity. Furthermore, reducing the time spent on the manual task in the future provides more time to work on more significant tasks.

As I read about new technologies or techniques (outside of work), I am thinking about whether there are opportunities to apply what I've read to work. When I first learned about AJAX web application techniques for improving the usability and responsiveness of web applications, I realized there was some functionality in the application I was maintaining at work that would be greatly improved through the use of AJAX. I proactively suggested the functionality improvements (on the basis of improved usability, not for technical reasons) and they were improved, so I was able to implement some AJAX functionality and learn while doing it. Care does have to be taken that you don't choose a technology only because you want to learn about it (or so you can put it on your resume, which I've heard called resume-driven design).

A great opportunity to learn at work is by getting exposure to software written by other people. That's why I don't think it is healthy to work on the same application / set of functionality for ten years in a row - you probably aren't learning much after the first three years. I am always excited when I get the opportunity to work with a new piece of software, despite the initial painful learning curve, because of the great learning opportunity. As I study and become familiar with the new code base, I'm trying to understand the overall design and why things were done the way they are. I'm also looking for new techniques or design approaches that I like to make a mental note of them.

For example, a while back I was on a development project that was given an architectural prototype as a starting point. The application was a java applet that communicated with the server via serialized java objects. What I found really innovative was how the undo feature was implemented in the applet's GUI. The data loaded from the server for a particular screen was copied in the applet (via serialization) before being displayed to the user. The copy was stored as the original data. If the user made changes and then performed an undo, a new copy of this original data was made to display in the screen, wiping out the old, modified data. I thought this was a neat implementation of single-level undo in part due to how this same approach could be applied without modification to all the screens in the application, without additional coding.

Somtimes I am disappointed when I study and/or use a new code base: perhaps the code is poor quality or the design is messy and hard to unravel. But this too is a learning opportunity. Reflecting on why I don't like the code or why the design is hard to work with or modify clarifies my thoughts regarding software design and coding, which in turn influences how I develop software. For example, I am a fan of long descriptive names for fields, variables and methods, in part because of all the code I have had to read over the years that used short, obtuse names.

Fellow coworkers are an excellent resource for learning. I find it important to know the background and skill sets of each of my team members, as this makes it easier for me to pick the right person to go to when I have a question about a particular technology or technique. For example, if I need to improve the performance of a SQL query, I'll go to a DBA with experience in query optimization. But if I am interested in an evaluation of a Java library I've never used, I'll go to another Java developer who has used that library on a prior project. I also like to have more general discussions with senior developers in different groups to find out what they are doing, what technologies they like (or not), etc. It is hard to make such discussions happen, especially if different groups don't interact as part of day-to-day business. I've seen managers from time to time try to encourage such sessions - one popular format is the lunch-time presentation, where someone presents on a selected topic. However, seldom do such presentations result in good conversations - there are either too many people, too structured a format, or just lack of interest in the topic - and the presentation is about as effective as a blog article. To be successful, I think a discussion group should be around three to six people and should form on its own (i.e. with volunteers). A group can meet only once or regularly, but having a specified topic seems to be helpful.

As an example, I was a member of a design patterns discussion group, studying the design patterns in the book Design Patterns: Elements of Reusable Object-Oriented Software. Four of us met regularly every second week to examine one of the design patterns in the book. We had a designated facilitator assigned each week to initiate and encourage discussion. (We used this information on running a design patterns study group.) We did meet outside of work hours, so perhaps this isn't the best idea of learning while at work. A better example is the time five developers including myself met to discuss the configuration management practices being used for the applications we represented. In that meeting I found that all the other teams had some kind of versioning or tracking process for determining which version of their application was in each environment (i.e. user acceptance test, production). I hadn't set up anything formally yet, and had actually been debating with myself whether to do so, so hearing that others were doing it and finding it useful helped me decide to put a similar process in place for my application. (Over the next few months, there were occurrences that made me glad I had done so.) In this case there was only the single meeting, yet it still proved useful.

There are many other examples I could provide about learning opportunities at work. Despite all the learning opportunities that may or may not be available, your day-to-day work on software development tasks provides the best opportunities to improve your craft - your ability to design, code, test, etc. But in order to improve at what you are doing, you need to receive feedback and reflect on what that feedback is telling you. The importance of feedback to learning will be the topic of a future article. In the meantime, happy learning!

If you find this article helpful, please make a donation.

«    »