Skip to content

Go Team!

Dear Reader,

I talk a lot about software development teams. I am a firm believer in the importance of teams and teamwork in software development. However, great teams take great team players and professional developers understand how to be a great team player.

I Hate Lone Wolfs

Lone Wolfs are the developers who take a task, hole up in their office and don’t communicate, or don’t check in code regularly. They just code like a mad-man till it’s done and then toss it back over the wall. I go so far as to say that I hate the Lone Wolf programmer. If you are a Lone Wolf, you may feel that you are being productive, you may be able to crank code like a mad-man, but if you are part of a team, you are hampering the team. Ultimately, you will hurt the project more than your code helps it. That’s a bad thing.

Professional programmers, are team players, even if you are on a team of one. This means that even if you are the only programmer on the project, you need to act like you are on a team. You need to communicate regularly, you need to check your code in regularly, you need to not break the build, you need to stick to the coding standard. Everything you normally do when on a team, you still need to do when you are working alone. If for no other reason than to build good habits so that when you are on a team, you don’t have to remember how to be a good team player.

Part of being a team player means moving with the team; moving as part of the team. Most people don’t consider NASCAR to be a team sport. (I am not interested in whether you think NASCAR is a sport, work with me here.) NASCAR to me is a great example of the discipline it takes to participate in any team activity. Most of the time, the focus is on one person, the driver. Going around the track, swapping paint with other drivers, avoiding crashes, etc. However, even when the focus is solely on the driver, the team is involved. If you’ve ever listened to the radio frequency for a given driver, you know that they are in constant contact with their crew chief, their spotter, constantly talking to them, letting them know how the car is handling, or asking for reports of what is going on ahead of them. Even when the focus is on one person, it is still a team effort.

The unsung heroes of NASCAR however are the pit crews. You only see them when the driver comes in for fuel and tires. They aren’t standing around picking their nose the rest of the time, they are mentally preparing themselves for action. They know what is coming next, so they are mentally rehearsing their part of the next pit stop so that when the time comes, they can do their part. When the driver pulls in, the crew is ready. They move as one, each person accomplishing their task with military precision. Get in, get it done, get back over the wall, debrief and figure out what did not go smoothly, get ready for the next tone. Sounds a lot like Agile programming to me, with 12 second sprints. :)

Here is what you do NOT see in a NASCAR pitstop.

  • You do not see one of the tire carriers deciding they want use a different tire than everyone else because they understand it better.
  • You do not see the “gasman” decide to try a new fuel one stop because they read on Stack Overflow that it is faster.
  • You never see one crew person suggest that they switch from Ford to Chevy because people on Reddit mock Fords.

Everything is planned out before the race starts. Yes, things change during the race; accidents happen and everyone on the team has to adjust. But they plan for change, they know how to adjust as a team because they have practiced it. They still work as a single unit, not as a gaggle of individuals.

The takeaway is that if you are going to be on a team, BE ON THE TEAM! Understand your part on the team, accept your place on the team, own your place on the team. When the team swings into action do everything that is expected of you and give 100% to the project.

Show Up or Leave

There will always be times when you disagree with the direction your team is going. Professional programmers know when to voice their opinion and fight for their cause, and when to get on board and work as part of the team.

I actually wrote about what to do when you disagree with your team’s direction a few years ago because a friend of mine wrote me and asked my advice. The gist of it was that a technical decision had been made that my friend disagreed with. He felt that this decision would lead the project down a bad path and eventually lead to disaster. During the discussion phase, he voiced this opposition several times. Then he found out that the decision had been made to do it anyhow. Enough of the team decided that it was the right way to go.

In this story, it doesn’t matter who is right or wrong. What matters is that a decision was made. My friend now had another decision to make and that’s why he wrote me.

I told him he had 2 choices.

  1. Get on board with the direction of the team and give it 100% of his effort.
  2. Leave

It boils down to that. If you are on a team, you were put there because someone thought you could do the job. Disagreeing with the technical direction of the project doesn’t give you the right to dig your heels in. You are being paid to do a job, do it or get out. You owe it to your team.

If you decide to leave, that’s fine. That’s a valid decision and you are to be applauded for understanding that you will never be ok with this project so it is better for everyone that you leave. Now, be an adult about it. While you are looking for your next great adventure, you still have to give 100% to the current project and team. Yes, it is gonna suck. yes, you are going to have to hold your tongue, and sometimes your nose, to do the job. You owe it to your team to do it. To give 100% until you can find that next great adventure.

Once you are ready to leave, leave gracefully. Rage-quits feel awesome, for a day. Then you begin to realize that the people you just quit will probably tell others how you quit. Those others might be potential clients or employers in the future. Rage-quits don’t hurt the team you are leaving, they do hurt your reputation. Be an adult, leave with grace.

Professional programmers are team players because they know that even if they are the only programmer on the project, they are working with a team.

Until next time,
I <3 |<
=C=

Can we talk?

Dear Reader,

Many people outside of the programming community (muggles?) have the idea that we sit in the dark, stare at bright screens, and only communicate via irc, twitter, hipchat, skype, or email. Most of the time they don’t even know what those terms mean, but they heard their niece talking about using them, so they throw the terms around to sound important.

How We Communicate

Sadly, in many of cases, this is a true description. It’s not sad that we use these tools. As developers, most of us have found the best way to communicate with our peers. What is sad is that we forget sometimes that the rest of the world doesn’t use these tools, and may not feel comfortable with them.

Case in point. I was trying to get some help from someone I work with recently. This person is not a programmer, even though they work at a high-tech startup. I saw that they were on-line on HipChat so I popped in and said “ping”. I got no response back. No “pong” no “ack” not even a “nak” for they are busy. Nothing.

Later on in the day, I went old-school and sent this person an email asking them my question. The response I got back was “Next time just send me an email, I’ll get to it faster.” FASTER? Faster than an instant messaging system? What they meant was that they will respond faster because they are more comfortable with the medium of email than that of hipchat.

See I wanted to communicate in the way that I thought was “fast”. I just had a simple question. My co-worker though, not being comfortable with IM clients, simply ignored my question. I had to find a way to communicate with them that made them feel comfortable.

The same goes with our clients. We have to find out how they want to communicate and then make sure we talk to them that way.

How We Say What We Say

Another thing we have to worry about when communicating with non-programmers, specifically those that we are working with, is how we say what we say. As developers, we have our own Domain Specific Language. (DSL) Most everyone reading this communicates in English, but within English, we have a specific way of talking to each other. We use industry terms, acronyms, memes, inside jokes, all of these and more. Your client isn’t going to get that.

More though than just making sure you steer clear of “Inside Baseball” lingo, you have to listen carefully to your client and how they speak. See, funny thing, we developers didn’t actually invent Domain Specific Languages, your clients have one too. Their industry has their own slang, acronyms, memes, and inside jokes. You, as the developer, need to understand how they speak and then translate “developer speak” into their DSL. I call this translating “Geek to English”.

It is your job as the developer to communicate not only your ideas, but your statuses to your clients in a way that they can understand.

How Often We Communicate

Finally, you as the developer have to make sure you communicate to your client in a timely manner. Timely manner can mean a lot of different things. I’ve had clients who would just throw specs over the wall and didn’t want to hear back from me till it was done. Other clients like to hear from me at the end of every day with a paragraph or two on what I accomplished that day. You don’t get to decide the cadence for communicating with your client, they do. it is your job to respect it. If your client doesn’t specify how often you should communicate with them, err on the side of over-communicating. I have yet to have a client tell me they knew too much about what I was doing.

On the other hand, don’t swamp them with nit-pick details.

I worked with a developer one time who was in a feud with our boss. This particular developer got so fed up with being berated for not getting the boss’s tasks done that the developer started keeping a log…in 5 minute increments. At the end of the day, the developer would turn in the log as proof of work. The boss didn’t understand that the requests being made were not reasonable. The boss also didn’t understand how to manage developers, but that’s a story for a different blog post.

The point is that the developer – in a fit of rage – chose to inundate our boss with minutia. Don’t go that far but make sure that your client understands what you are doing, how long you have been working on it, and approximately how long you expect it to take to finish the task.

  • Talk to your clients in a way they are comfortable
  • Talk to your clients in their language, not yours
  • Talk to your clients as often as they are comfortable

Epilogue

The developer mentioned above – who was a very good developer, but a little hot headed – was soon transferred to another department at his request. The boss was fired about six months later for explaining to a female business analyst in another department that he could train a german shepard to do her job. – True story bro.

Until next time,
I <3 |<
=C=

Photo Credit:Jeremy Kendall
Photo is (c) Jeremy Kendall. All Rights Reserved
Photo is used by permission of Megan Kendall, the subject, and wife of the photographer. Cuz, well, we know who is in charge.

Let’s be honest…

Wile E CoyoteDear Reader

Let’s be honest with each other, shall we? Most of us – at least I hope most of us – consider ourselves honest people. We don’t purposely lie or mislead people. But we are developers, and as developers, sometimes ego and enthusiasm get in the way. As developers, most of us are optimists. We look at a problem and say “yeah, I can solve that”. Most of the time, we are right, we can solve that, but not usually in the timeframe we originally estimate.

How long will it take you?

As developers, we see projects not as a job that must be done, but as art that can be created, as a project that needs to be crafted. It’s not a spreadsheet of numbers to us, it’s a sketch on a napkin of something we want to build. As such, we see the big picture, but miss the details. So when we tell a customer/client/family member “Yeah, I can build that this weekend”. In our mind, we mean it. We honestly think the project is simple enough to be built in a weekend. It rarely is though.

I worked with one professional services company that even though they had professional developers estimating their projects, their average estimate was +/-100% of actual. It wasn’t because they were bad developers, and it wasn’t that they were liars. It wasn’t that they wanted the job so bad that they overpromised and underdelivered either. The problem they had was that they looked at their projects wrong. They looked at the big picture, saw the framework they had to put up and even fleshed it out a bit. But they refused to dig down into the project. To ask additional questions, the break tasks down into small enough tasks so that they could be fully understood. because until you do that, you can’t give an honest estimate of how long it will take.

Can you really do it?

A professional developer can also tell if a project is above their skill level. We’ve all done it, we tell someone “I can build that” when what we really mean is “I want to learn how to build that and this project seems as good as any to learn on”.

That’s not always a bad thing, as long as you are honest with the person you are talking to. If this is your own personal project, sure, why not, you are only answering to yourself. If it’s for a family member (and is unpaid) then yeah, it’s probably ok, but I’d still let them know. If it’s for a customer/client/family member/boss, you owe it to them to let them know that you are using this as a learning opportunity.

When will you be done?

Finally, a professional developer is honest about the amount of time they have to dedicate to a project. Remember Clock time !=Calendar time It’s not enough to say “This project will take 2 weeks” if you have other projects you are working on in those two weeks. Make sure you tell your customer/client/family member/boss/neighbor how many hours it will take to accomplish the task, and how long it will take you to slot those hours into your schedule.

Professional developers are honest.

  • Honest about how long something will take
  • Honest about their skill levels
  • Honest about how much time they can devote to a project.

Be honest with your customer/client/family member/boss/neighbor/significant other, but more importantly, be honest with yourself.

Until next time,
I <3 |<
=C=

Understanding

einstein2Dear Reader,

“If you can’t explain it to a six year old, you don’t understand it yourself.”
  – Albert Einstein

As a developer, your customers or clients – both internal or external – come to you because you understand something they do not. You understand how to architect applications on the web. You understand the tools that you use, you have a deep understanding of your technology stack.

I had a boss one time that insisted that because he had a copy of PageMaker installed on his computer, he could publish a magazine. I mean, how hard can it be to use a piece of software that a cost over $2,000? Right? He thought he understood, until he actually fired it up and tried to put together his first edition. Yep, you know the rest, after about a week of fiddling around, he hired someone with a deep understanding of how PageMaker worked, and how to get things done with it.

As a professional developer, you are the expert. You are expected to know not only the buzzwords, you have to understand the concepts behind them. You can’t just say “Cloud”, you have to understand what it means in relationship to your client. It is your job to understand these things just as it is your client’s job to understand what they need the application to do. You cannot help people solve problems with technology if you don’t understand the technology yourself.

This doesn’t mean you have to know all the answers. To the contrary, some of the worst developers are the ones that won’t admit that they don’t know all the answers. You don’t have to know all the answers, you do have to know where to find all the answers.

I interviewed once with a company that expected me to know all the answers. As I sat in the conference room, my interviewer walked in with a stack of old-school computer books. You know the kind, the ones that were sold by weight. By that standard, these were some of the most expensive books I had run across. Each book had dozens of post-it notes sticking out the top. He sat down, opened the first book to the first post-note and proceeded to ask me a question about what was being talked about in the book at that point. Of course I did not know the answer. I was honest with him and told him I did not know exactly and described how I thought I could figure the answer out. He then moved to the next post-it note.

Long about the third post-it note, I stopped him because I could see where this was going. I explained to him that we could go on this way for a bit, but the chances were very good that I didn’t know the answer he was looking for on any of these questions. The thing I did know is where to find the answers should I ever need them. I could feel the recruiter who got me the interview crawling under the table.

The point was that I was not a walking encyclopedia. I did however have a good understanding of the technology that they wanted me to work with and knew how to fill in the gaps in my knowledge when necessary.

By the way, they called back and wanted to hire me. I decided however that it wasn’t really the kind of place I wanted to work and I was lucky to be in the position to be able to pass on the offer.

It’s ok not to know all the answers, as long as you know where to find those answers. Sometimes you will find the answer on Google. Sometimes, you’ll use IRC. Sometimes, you’ll ping that weird guy you met at a conference last year who said drop him an email if you ever needed help. Whatever works for you is the right way.

However, without a deep understanding on the technology stack you are working with, you won’t understand enough to even start to find the answer.

Invest your time in learning your tools as you spend time looking at new tools. Understand what you are working with so that you can help others create awesome.

Until next time,
I <3 |<
=C=

Curiosity didn’t kill the cat, falling behind did

Dear Reader,

If you aren’t curious, you won’t try new things. If you don’t try new things, you won’t learn new things. If you don’t learn new things then you are a paper weight. Curiosity isn’t an optional trait for programmers. Look at the speed at which things change for us.

First, let’s look at PHP. PHP is enjoying a resurgence. We went through a rough patch there for a few years. The core developers lost their focus, the language started to stagnate, and for a while things did not look good for the PHP community. Then recently, things started picking back up. Yes, we went through some upheavals and I won’t say all of them are done, but we are now getting new language features and regular releases. PHP is changing for the better.

Now that it is though, our jobs just got harder. We as developers have to keep on top of all these changes. This doesn’t mean we have to implement them for the sake of implementing them , but we do have to be familiar with them and what we should use them. To stay on top, you have to be curious, even if you are just faking it until you feel it. You have to keep at it.

That’s just PHP. There are changes happening in all aspects of web development. Changes in how we structure applications. Changes in the technologies we use to build the front-end of our apps as opposed to the back-end. Changes in infrastructure we build our applications on top of. The worst part of it is that nothing we learn today is carved in stone. A good portion of everything we are investing our time in right now will be outdated and useless in 5 years. (Can anyone say Silverlight?)

With all of this pressure, what can you do? You have to stay curious, you have to keep learning, and you have to keep experimenting.

  • Start a side project that has no meaning other than for you to experiment on
  • Play with a new technology in your side project
  • Participate in an online discussion about what you are working on

You have to keep at it. You have to keep up, but it doesn’t have to consume you. Just discussing new technologies with other developers is good way to keep abreast.

Keep up, keep at it, be curious.

Until next time,
I <3 |<
=C=