Entries Tagged 'Becoming a Better Developer' ↓

Many of you gasped at the title of this post:

“Become a manager? Has he lost his mind?! I’ll be a coder ’til the day I die!”

I’m not implying that you should give up your coding gloves and step into the ranks of full-time management, but you gain incredible perspective about what makes good and bad developers once you’ve managed a few of them. Even if you never become a full-fledged supervisor, managing a project, being a technical lead, or running your own business are all suitable ways to experience what makes a “better” developer from a different angle.

Before working in software I was a project manager for a large electrical contractor in the bay area. So naturally, when I began my technology career, I quickly moved from writing software to leading projects and managing other developers. Over the next few years I continued to function as a lead/PM until I became the manager of 10 DBAs and developers for the City of Pasadena. And let me tell you, I learned more about what makes a good developer from a management perspective in my short tenure at the City, than in the previous two or three working as a consultant.

Lesson #1: What Makes Someone the Best
One of the first things you’ll learn is who your best developers are and why. And it’s not what you think; often times it’s not the most technically savvy person in a group, rather it’s the one who’s able to make things work with the least amount of management intervention. If you think you have a lot of things to worry about, your manager has to put up with 5 or 10 times more context switches than you do. And when your most critical asset is time, someone who may not be the end-all be-all of personality or technical ability, but who’s able to do a lot of coding without bothering you every few minutes, that developer is worth his weight in platinum.

Lesson #2: It’s Easy to Complain about Your Boss Until You Have to Do His Job
I can’t tell you the shock I felt when I realized for the first time that as a manager the success or failure of a project didn’t rest solely in my hands. The project’s success, and ultimately my success, rested in the hands of programmers whom I had to motivate, work with to ensure they were building the correct software to our development standards, all the while being told by customers and management that we should be doing it faster, for less money, and with less people. It was a horrendous tug-of-war with me in the middle.

In software, as in business, every decision is a compromise. If you’re on the losing end of that compromise it’s easy to complain that the person made a bad decision. For the most part, unless you have an evil boss, she is trying to make the best decisions she can. Trust me, someone who makes a compromise is better than someone who makes no decision at all.

Lesson #3: How to Self-Manage
As a supervisor you can’t get any work done unless your developers learn to be self-sufficient. A large portion of your time should be spent putting out fires (since there are always ample fires to fight), not performing basic developer-related tasks (”For the hundredth time, we use i for our For-Loop variable, not j!”). So as a developer, if you can make something work while bothering your boss even one less time per day, you’re taking a huge burden from his shoulders.

Lesson #4: Do What It Takes to Achieve Results
I’m not an advocate of an unhealthy lifestyle, in fact I’m the guy who takes three week vacations to Africa, but one of the facts of our industry is that there are times when it’s necessary to work overtime. Do what it takes to hit the deadline; don’t make your boss ask you, or worse, order you to stay late. As a developer you can read the writing on the wall and should know well in advance when you need to tell your spouse you’ll be late for dinner.

When it comes time to play, show up and get the job done.

Lesson #5: No Surprises
Surprises are never a good thing in the business world.

I remember being told the day before launch that we weren’t going to hit the deadline. I asked how long they’d known about it and they said a week and a half. Ugh.

If your boss doesn’t require email updates, drop her a 1 or 2 sentence email twice a week letting her know what you did over the last few days and how things are going. I bet it will become standard practice for the entire group. “Pushing” information is a big help when trying to manage many people, and it helps eliminate surprises. Don’t be afraid to share bad news. Bad news in advance is 10-times better than bad news the day everyone else hears about it.

Walk a Mile in My Shoes
Even if you never become a manager, try to walk a mile in your boss’s shoes once in a while. It won’t take long to realize how much you can learn from looking at your job from a different perspective.

[ Bookmark this post with del.icio.us (What is del.icio.us?) ]
[ Submit to Slashdot ]

A friend of mine once worked with a developer who, as everyone else fired up their copies of Visual Studio.NET (Microsoft’s graphical development environment that has all the bells and whistles you can imagine), would start a UNIX emulator on his Windows XP machine and crank up Emacs, an ancient, stripped down, no frills text editor.

When I heard this my jaw dropped. To make matters worse, anytime this guy had difficulty with indentation or line wrapping (since he could only see 80 columns) he would rant and rave at the other developers, telling them how their code should be formatted this way or that way to match some archaic standard that somehow made developing in a 20+ year old text editor seem to make sense.

I don’t doubt that Emacs is a good editor (I used it for a few years back in the early 90s, actually), but the bottom line is that as computer languages have evolved so have the tools we use to work with them. There’s a reason we don’t build web applications with COBOL…it’s not the right language for the job.

I know the learning curve of switching tools is painful, but in the long run you have to use tools that make you the most productive and that don’t wreak havoc on the rest of your team.

If you’ve used the same knife for 20 years there’s probably a sharper one out there.

There’s an old story that goes something like this:

A visitor arrives at an IT department and approaches a software developer. He asks him what he’s doing, to which the developer replies:

“Writing code.”

He walks to the next cubicle and asks the same question of another developer. He replies:

“Building a web page.”

He walks to the next cubicle and asks the same question of yet a third developer, to which she replies:

“Writing a piece of web-based software that will make it easier for our customer service reps to assist customers.”

Why are their answers so important?

Knowing Where You Fit
Someone who knows what they’re building can see their place in the big picture. They realize the importance of their work and know without explanation why it’s important. If the application begins to crash in the production environment and someone comes running for the developer, won’t they have a greater sense of urgency if they know it’s affecting the company’s bottom line?

A Sense of Purpose
People who know what they’re building have a sense of purpose. It makes them feel as if they are serving a greater good, whether that good is a single person, a department, or the entire company. Purpose makes people work a few extra hours to finish a project on time. Purpose makes developers take one more crack at fixing a hard to find bug.

If You’re a Developer
Ask about the big picture. Find out why it’s so important that all of a sudden every button on the account summary page has to be red instead of green. Ask your manager, his manager, or the guy in marketing. If you ask questions with an obvious posture of learning, people will notice and appreciate the fact that you care.

If You’re a Manager
Educate your developers. Talk to them about what the company does from a broader perspective, and make them see why it’s so important that an application works. Show them how it helped generate a huge amount of revenue for the company, or how it allows the finance department to reconcile month end numbers in an hour instead of three days. At the beginning of every new assignment, ask them if they know what they’re building.

I’ve received a lot of feedback on my article Using Technology to Fight Poverty (in addition to several links - special thanks Scott Mitchell and Adnan Masood and Mike Gunderloy). Thank you everyone for your emails and continued support!

Here are a few of the comments I’ve received:

“I hope it makes an impact on everyone who reads it.”

“Trust me, I have no idea what the answer is. At the very least we can not consume more than we need, but even at that, we are impacting the planet and it’s people radically. Maybe even that sounds over inflated, but I really believe it. We read an article in National Geo about our consumption of oil on the planet, and if other countries had the same level, we would deplete the resource very quickly.”

“I think your article is thorough and a great resource for people with a heart and affinity for technology (or who see the value in it).”

“It’s an interesting idea, although I wonder how much of that profit margin will see its way to the actual drum makers. (Call me cynical.)”

“I read your article today. I’m impressed with the work you’re doing, and it made me feel like such a slacker — the amount I spend on coffee alone made me guilty.”

My reply: The objective of this article is certainly not to make people feel guilty; awareness is the goal, since that will have a more lasting impact.

“Thank you for being moved by what you saw. Thank you for bringing it to others and using your gifts of practicality and ingenuity to show us the disparity in the world. Your admonition does not fall on deaf ears. Thank you for reminding us of our obligation to others. It is too easy to forget.”

“A must read for everyone who believes in ‘One does evil enough when one does nothing good.‘”

I’m writing this while sitting on a beach chair overlooking the Gulf of Guinea near Cape Coast in Ghana, West Africa. Although it’s slightly overcast the view is amazing, with whitewater stretching out in both directions as far as my laser-corrected eyes can see.

Being in a foreign country is one of two experiences that allow me to take a step back from my life and look at it with a fresh pair of eyes (backpacking is the other). Being away from home and having no day-to-day responsibilities has the effect of a sculptor’s chisel; it slowly knocks away the ever-present and intense focus I have on getting things done. After about a week I can see a noticeable difference in the way I’m able to analyze my life back in the states. Gaining this external perspective on life, or what I call the panoramic view, is a critical part of becoming a better developer.

Focus and 19th Century Prisons
Most programmers, by nature of our jobs, are highly focused individuals. We get so engrossed in our work that we have trouble noticing the passage of time, and we also become pretty good at tuning out the outside world and distractions such as the people walking by our cubicles who never discovered the concept of an “indoor voice.” How often have you been so wrapped up in your code that that you suddenly realize that the biggest movement you’ve made in hours is to shift your hand to the left to hit Ctrl-s?

While this trait can lead to periods of intense productivity, it tends to be less of a blessing when it comes to managing life. How many developers do you know who can write excellent software but can’t pay their bills on time, have no social life, and live in squalor reminiscent of a 19th century Turkish prison? That’s because they’re so heads-down productive that they don’t want to take the time to look up and notice or engage in what’s going on around them. But that’s another article altogether.

This type of focus causes people to obsess on one task after another, working on whatever’s in front of them but rarely, if ever, evaluating whether the task is actually worth doing. This is how most people live their lives to one degree or another, and it’s what I like to call tunnel vision. Living this way is a lot like pulling out of your driveway and thinking so much about pushing the clutch in that you never look to see if you’re headed into a crosswalk full of nuns.

Why Should You Care?
One thing I’m sure you’re wondering by now is how does having a panoramic view make you a better developer? The whole concept is similar to that of a sabbatical, which is widely accepted in academia, and which Joel Spolsky talks about here. The goal is to renew focus, intention, purpose, and a passion for life and work. Each of us could use renewal in these areas from time to time.

In addition, when you have the big picture in mind you’re able to withstand a lot more frustration without breaking down, because you know what is truly important and what is simply a detail of life. This makes you a better person, and being a better person is good for the psyche and the soul (on this you can cite the authority of my wife who is in the last stages of finishing a PhD in Clinical Psychology and a Masters in Theology, and who talks to me incessantly about how to become an optimally-functioning human). The Questions
So what do I think about once I’ve spent this week away and can suddenly see the panoramic view of my life?

Here’s the list of questions I’m thinking about this time around. I started by taking the questions that are still relevant from the last time I ran through this exercise, which was about a year ago in Costa Rica. I realize they are somewhat general, but I use them as a starting point to get me thinking about specific themes in my life which I follow up with more specific questions. You can use them as a starting point, but I encourage you to come up with your own set that’s relevant to your current situation.

Life
What do I like most about my life?
What do I like least?
What is my concept of the “ideal” life and how is mine different from that?
What do I want my life to look like in 5 years?
What do I need to do to prepare for those changes?

Work
Am I happy with my job?
Do I get excited when I tell people about it?
Am I expanding my skills?
Are there skills I should be learning that I’m not?
Is there anything else I’d rather be doing?

Most of these take around 30 minutes to think through, though some take 2 or 3 hours. I make lists of answers and jot down additional questions that come to mind. The most difficult part is genuinely and thoughtfully questioning the basic assumptions of my life. The transparent view helps with this, but it still takes a substantial amount of time and effort.

And now, story time! Here’s the way this process began in my life and why I feel it’s so valuable:

In the days of yore, like every recent college grad with a guitar, I wanted to make a living from music. During the day I worked a 9 to 5, but every evening I dreamed the dream as I wrote and practiced my songs.

Periodically I would reflect on my rock star progress (or lack thereof) and feel incredibly frustrated and dejected. During a trip to Europe, after years of following this same cycle, I realized that although I had the desire to play music, I wasn’t living the life it takes to make the goal a reality. Although I spent a lot of time practicing and writing, I wasn’t ready to give every part of my life up so that I could make it in the unforgiving business of music. The more I thought about it, the more that became okay. I have been happy every since knowing that when I sing, play, write and record, that I’m doing it for fun, not for a goal that will weigh on me but that I will never achieve.

The bottom line of all this is to be intentional about what you do with your life and your work. Don’t live in a tunnel, never stopping to reflect on what you’re doing and why you’re doing it. Taking the time to renew your focus and passion is a critical part of becoming a better developer. And watch out, you may even find yourself turning into a better human being.

I leave for Ghana (West Africa) in 48 hours.

Lately, my mind has been filled with thoughts of how a for-profit technology company could be run with social justice as its focus, and along a related line how technology can be used to fight poverty. The reading and writing I’ve done in the past few months has culminated into a new question for me:

What’s the point of technology if we’re not focusing on people?

I don’t mean that we focus on people so we can get more work out of them so we can turn a bigger profit. I mean make people the focus above everything else, even shareholder value. What would that look like?

Stay tuned to hear more.

An excerpt from my new article:

How many times have you heard this:

Marketing guy: I know it’s only four days before launch, but we need to make sure that people with green eyes aren’t allowed to buy our fantastic new product, the Squash Organizer.

Developer dude: That’s going to create a problem. The way the database tables are set-up we actually perform two outer joins to find out if the person has green eyes; once to get their genetic pre-disposition and a second time to get their actual eye color. But this join can’t be done until we’re at step 4, and since we’re storing values in the session and the dna object is not instantiated yet…

Marketing guy (interrupting so he doesn’t have to hear a 10 minute explanation complete with poorly-drawn white board sketches): How long do think this change will take?

Developer dude: Well, aside from the issue I mentioned, this raises questions like: is it both eyes or only one? Can people with green eyes still buy a Zucchini Organizer? What if they choose a Zucchini Organizer and then later change to a Squash Organizer, do we have to repeat the validation?

Marketing guy (defeated, with hands in the air): Can’t we just add a boolean field to the database called “HasGreenEyes”?

Programmers don’t speak the same language as the rest of the world for one simple reason: you can’t see a project from two altitudes at once.

Read the entire article here.

For years business consultants have instructed businesses to “know your core competencies.” What this means is “know what you do well and stick to it.”

For example: Harley Davidson makes great motorcycles. But they’re probably not so good at making perfume.

Smith & Wesson makes some of the best six-shooters around, but I question whether their bicycles will be a smashing success.

McDonald’s is…well I won’t say they’re very good at making food, but they are pretty good at selling a ton of it. But they should never, and I mean not between now and the day that Eternity decides to cash it in and become a Las Vegas showgirl, make a Lobster Sandwich.

As a developer knowing your core competencies can help keep you out of trouble. I’ve been building web applications for most of my career and I’d like to think that I’m pretty good at it. But there are certain things I’ve never done and would not do well right off the bat: writing a compiler, building a super-fast search application, and implementing my own encryption algorithm are a few that come to mind. This reminds me of a story…

I was co-maintaining a successful e-commerce website and we were looking for a way to encrypt passwords so they wouldn’t be stored in plain text. The site was written in Java, which I had used for the previous 6 months or so, but even after 6 months I could not for the life of me find anything in Sun’s documentation (does anyone know how to effectively use their search tool?).

After literally hours of combing through the documentation I gave up and decided to write a quick, simple encryption algorithm to hash passwords. Take the ascii value of each character, add something to it, divide by something…whatever, it’s all just numbers, right?

Oops.

I implemented it. We launched. And sure enough, within a few days people were complaining that they couldn’t login. I thought surely we had a bizarre coincidence on our hands; ten people all at once misremembering their passwords. I was ready to call the papers until, after about 20 minutes of investigation, I realized that my encryption algorithm didn’t really work for a couple of characters at the edge of the visible ascii range. It processed the values, but the encrypted result was actually an invisible character, also known as a “control” character.

Control characters can create difficulty because anytime they cross a boundary, whether from the database to the application, or the application to a web browser, they run the risk of being accidentally changed up by a mis-encoding between the layers. Sure enough, some of the decrypted ascii values were incorrect resulting in a handful of people who couldn’t login.

On that day I learned the importance of sticking to what you do well. After many successful launches we had our first setback; luckily we were able to fix it without a lot of effort.

This doesn’t mean that you should never branch into new things. On the contrary, you must constantly build on your core competencies or become outdated. But be smart about it.

Realize that moving from building web applications to desktop applications is not a huge stretch. Moving from web applications to compilers, while possible, is going to take more than browsing an online tutorial. And stay away from encryption; it’s a nasty beast!

When dealing with tasks completely outside your realm of knowledge expect to spend a lot of time researching, becoming familiar with the subject, and learning it slowly as opposed to copying and pasting the first code sample you see.

I can make web applications like it’s nobody’s business, but don’t hire me to work on your next compiler.

This is the first of what I hope to become an ongoing series about non-technical ways to improve yourself as a developer.

Becoming a better developer involves more than learning new technical skills; learning about your company and co-workers will dramatically improve the software you build. One of the most important lessons I learned during the first year of my career is to be so nice to the people around you that they can’t help but become your biggest fans.

When I graduated from college I began working for an electrical contractor in Northern California; the company where my dad has worked for 37 years. My first year of management training was spent shadowing the Chairman of the Board followed by a foray into managing construction projects. During that first year I was anxious to be accepted by the office staff and tried my best not be viewed as the kid out of college who was given a job because of my dad. As a result I went out of my way to spend time talking to people around the office, asking about their lives and families, and making conversation with pretty much everyone I met. Word got around quickly that I worked hard and I was a nice guy.

I didn’t realize the side effects of this reputation until a year later, when I went into the field and began managing projects.

The first projects were overwhelming for me. I’m the type of person who needs to be in control, and on a construction site everything feels out of control until you get used to how it works (and even then everything’s out of control). So I was constantly calling the office, asking for favors and looking for answers to question. To my surprise people were willing to help me. It was like someone had gone around and asked everyone to make sure I was taken care of. And one day I realized it: unintentionally, that someone was me.

When I invested time in my co-workers I was unconsciously making them see me as someone they could talk to; someone who cared about them. This empathy meant that when I called they took the time to understand my dilemma and did everything in their power to ensure I got out of it alive, even if they had to drop what they were doing to help me. This is the power of making fans.

As an aside, I’m not suggesting that you build false relationships in pursuit of fans. That’s a lot like writing fake grass-roots letters in hope of creating a buzz; you’re going to get caught and it’s not going to be pretty.

I am suggesting that you invest in building genuine relationships with your co-workers, especially those in other departments who you would normally not have contact with. If nothing else you will learn to empathize with them so you can one day feel good about dropping everything to help them out.

Here’s an excerpt from my new article, Warning: Bad Specs Hazardous to Productivity:

“So Joe Developer is handed a spec that provides a nice, high-level view of the project and tells him where he needs to end up. He breaks it down into smaller steps, then perhaps into even smaller ones. He takes those tiny steps and begins to translate each one into instructions the machine can understand (aka “writing code”).

Soon after the first or second step he comes upon a task that he can’t easily translate into code. Perhaps it’s a piece of data he needs to display that doesn’t exist in the database, or a conflict emerges that would break existing code if implemented. Not only does he have to stop what he’s doing, but he has to make a phone call, walk to someone’s office, or schedule a meeting in order to get the answers he needs to continue. This is not only a tremendous waste of time in the sense of “he wasn’t at his desk for nine minutes while he asked this question,” but it takes his “flow” and sends it via Pony Express to the other side of the universe.”

Read the complete article here