Category - Business

Over the years interns, junior engineers, aspiring programmers, and CS students have asked me what they can do to get better. I usually recommend some books that will help shift their thinking to the next level and try to direct them towards topics that interest them, such as GoF if they aspire to be an architect. There are a number of books I usually recommend, such as Effective Java. I was thinking about this question a bit this morning during my commute and concluded that there is a higher level to this answer than what I have been providing and it is industry agnostic. Learn to juggle.

I’ve found over the years that as my life and career has progressed that I have more of a need to be able to juggle many different aspects of my life, without forgetting or dropping any of them. There are a few distinctions when juggling. You can juggle small objects, large objects, or a combination of the two. Small objects are the light weight ones that are fairly easy to hold, catch, and throw and are thus not extremely important in contributing towards long term goals. Large objects are heavy, bowling ball like objects, that are very important to one or more of your long term goals. The importance of the object to long term goals is always going to be directly proportional to the size of the object. Considering this, the smallest object will always be the least important while the largest object will always be the most important.

The size of the objects may change over time. For example, early on family may not even be one of the objects however, as in my case, I found myself with a small object labeled “Girlfriend”. This object grew over time and became a large object labeled “Family”. This object has now grown to be the biggest and is thus the most important. Likewise, some objects may shrink or eventually drop off. For a long time the object labeled “Surfing” was my biggest but slowly shrank and eventually fell off all together.

When juggling there is always a threshold before things start hitting the ground. This threshold will differ from person to person and will vary depending on the type and number of objects being juggled. In addition, this threshold can be changed and will typically not require the number of objects in the air to be taken into account so much as the total weight of the objects. For example, if my threshold is 20 and I have 20 objects all valued at 1 then I am at my threshold. However, if I have only two objects, one valued at 20 and one valued at 1, I am over my threshold and something must give.

It is important to note here that there will always be some objects that are, in themselves, over our personal thresholds. These are items that we will likely be able to achieve, given time, but that we will have to drop all other things and get a lot of support for. For example, I theoretically could be the Mayor of my town. However, I don’t know much about the job, don’t have a political background, don’t have funding, and really don’t have a large constituent base. This doesn’t mean that I couldn’t do it but simply that the object is larger than my threshold so to even attempt such a large undertaking I’d need to drop the value of all other objects.

My juggling until last week when school dropped out (Original image borrowed from here)

I have taken the time to value my objects, though I have never actually assigned them numbers. For example, my “Family” object is the biggest, followed by career, and so forth. Understanding the ordering of your objects is the first step to being able to juggle well. The main reason for this is that as some objects grow and others shrink you will inevitably find yourself with a need to drop some things off. Without understanding the importance hierarchy, how would you know what to drop?

Finally, understand when your threshold changes. A number of years ago I found that I could handle far less than I can today. There are a number of reasons why this threshold can shift. The reasons why are not as important as understanding that your threshold can shift and always being able to gauge where it currently lies. Just because you could juggle 15 large objects last week doesn’t mean you still can today.

So, if you want to excel at anything in life, learn to juggle.

The software industry changes extremely quickly. As a result there is a need for companies to be highly mobile and have the ability to respond to threats, clients, or market changes in a fluid manner. Because of this I have seen countless examples of the organization changing at the cost of the engineer, which is one of the many reasons why some software engineers have such utter disdain for “management types”.

We have all met at least one engineer in the past that had a bitter taste in his or her mouth for corporate leadership. Why? Trust. There is a level of trust that must come between all leader and follower relationships. This trust is one of the most important things in the company as it ultimately drives the output and quality of the company. Many times, either correctly or incorrectly, software engineers feel that they are the first ones to do the heavy lifting but the last ones to get recognition for doing so.

Here are a five things that will help to improve relationships with your developers:

1. Listen.
Listen to everything and understand it before taking an action. Often times developers tend to “dumb it down” for the “manager types”, leaving out often pertinent technical details. If something doesn’t quite make sense, ask for more information instead of immediately passing judgment. Despite the fact that “dumb it down” implies lesser intelligence on the part of “manager types” it doesn’t actually mean anything of the sort. You wouldn’t expect a career software engineer to understand the intricacies of the corporate pro forma balance sheet so it only makes sense that he or she wouldn’t expect you to understand the intricacies of bit shift operations in a hashing algorithm.

Part of this item comes in the form of project management. If a developer states that it will take one week to complete a project then it will likely take a week to do the project. Before demanding a shorter time frame, throwing more people at it, or forcing overtime, understand what went into the estimate. You simply can’t make time out of nothing and, as the Mythical Man Month points out, adding more people to a software project will often increase the time it takes to reach completion.

2. Stick to your word.
If you tell people something, stick to it. If you can’t stick to it, make every attempt to explain why and to make things right. This applies from everything to projects to job role. I worked for a company at one point that had promised us over and over that a certain (bad) thing would not happen. Then it did. The senior management immediately lost all credibility and control of the organization.

3. Give recognition.
Unless projects are marveled at because of their ingenious engineering, engineers are often the last to be thanked but the first to begin work. My current company does a pretty good job of recognizing the hard work put in by their engineers however I have been in many situations (at other companies) where sales, marketing, senior management, and call center personnel were all repeatedly thanked for making a project a success but the developers that wrote the actual product were not even mentioned.

4. Promote education.
Engineering is a mental job. Most of what goes into designing and writing code takes place in a little box within the head of every engineer. When creating systems the complex relationships, object models, and business rules all come together in a mental map that allows engineers to simply transpose their creation to the screen. By promoting education employers can not only further the abilities of their developers but allow them to sharpen their skills. As Stephen Covey points out in The 7 Habits of Highly Effective People, one of the most fundamental things people can do is to sharpen the saw meaning, in a nutshell, take time to improve the self.

5. Foster downtime.
Despite the public perception, software engineers are just as social as the rest of us/you. They are not work horses that blossom under the constant crack of the whip. As with all people, downtime will often bring a much larger gain through employee happiness. Studies have shown that a happy and secure employee is always going to be more productive than a pressured and tired one.