Soft Skill: What’s Important to Your Teammates

At my current job, we use FogBugz, which is pretty cool. It is also very flexible. There are lots of cool things you can do in FogBugz.

There are so many things you can do in FogBugz that it’s worth talking to your teammates about which things you should do. For example, I can change who things are assigned to. I can change priorities and milestones and add comments and edit previous comments and attach files and… Continue reading “Soft Skill: What’s Important to Your Teammates”

Soft Skill: What Would You Check First

One thing that will happen a lot in your first job programming (it’s certainly happened in mine) is that you will ask questions.

Asking questions is super important; in most cases, your employer would rather you take a few minutes of someone else’s time than waste hours of your own time. Also, the earlier in your employment you ask a questions, the more forgivable it is that you didn’t already know the answer. There will be posts in the future about when and how to ask questions, but I want to start it off with a very concrete, probable scenario and how to handle it. (By the way, in my first performance review, I was told that I do a good job asking questions, which I believe says something positive about my employer and about the contents of this post.)

Here’s the scenario: I am working on some code on a website, changing the business rules about validating the input on some page or other. I’m excited, because they’re actually paying me to write code all day! So I get some code written, spin up a local instance of the web server, click the button in my browser, and boom! A mile-long stack trace, most of which is in DLLs I didn’t work on, topped with some super helpful error like the famously unhelpful NullReferenceException.

So what to do? I will spend a few minutes reading code, checking for really obvious things. (See my earlier post about interrupting wheel spinning) After a bit, I conclude that I need a hand. So I send a very simple message to another programmer on the team: “I was just launching this website when [name of some library] threw a NullReferenceException. What would you check first?

When I first started my current job, I got a lot of practice asking questions, and that one is definitely my favorite. Here are some of the reasons:

  1. It has a definite, narrow scope. The other developer will not have to drop everything and read code for an hour to answer it. He or she can answer with some really simple things, like “I don’t’ know, ask Steve” or “Is your config file in the right directory?”
  2. The other developer will not waste time deciding how to answer the question because it contains the procedure for answering itself: “Imagine that you saw this error, what’s the first thing you would do?” He or she will likely know the answer, or at least that that he doesn’t know the answer, instantly.
  3. Point (1) and (2) combine into the question’s most important attribute: It is respectful of the other developer’s time. Interrupting and distracting programmers is expensive to your company and frustrating to the other programmers.

(Total aside: Interrupting programmers wantonly is bad.  I’ve heard the manager who interrupts programmers to check how the code is going compared to a gardener who pulls up flowers to check how their roots are growing. Gardeners do not recommend this practice.)

So, the next time you get a super unhelpful error message, and are in danger of losing piles and piles of time reading plumbing code trying to find the source of the exception, consider asking someone “what would you check first?” (Bonus points if you manage to ask while they are away from keyboard, so that you can be certain you didn’t pull up any flowers. )

 

Till next week, happy learning!

 

-Will

 

Mindset Post: Handling Discouragement

“If I don’t debug this graph search implementation tonight, I will be poor forever.”

I actually had that exact thought, verbatim, one night during year 2. I was up late. I felt like I was stuck; no matter what I did, I kept messing up the homework problem for one of the algorithms classes I was taking.

I was caught in the worst kind of programming vicious cycle; I would make minor changes I didn’t really understand, build, upload to the auto grader, watch in dismay as I either didn’t fix the problem or made it worse. I would repeat the process.

I let myself get stuck. I was more and more discouraged, and more and more frantic. How can this ever work? Does this mean I’m not a real programmer? Does this mean I should just quit?

There were a few things going on that, in retrospect, I should have changed immediately.

First, every “real” programmer, whatever that means, has certainly lost a few hours of his or her life to a stupid bug. It’s part of the job. (It’s not a good thing, of course, but it does come up.)

Second, life is long. The course I was taking was free. I had a job I liked. I was not out of retries yet. I could always try the course again, try the assignment again, sleep on it, whatever. Part of discouragement is thinking that any immediate failure represents complete failure. That is false. You can fail a lot (and probably will) and still do well. That is life.

I hate movie portrayals of hackers. There’s some kid who’s like twelve, and needs a shower and a haircut, who can make the world change by magically typing fast. That’s dumb. People who are good programmers study hard, learn a lot, do some work. It might not feel quite like work, because they often enjoy it so much, but it is not immediate. It might not happen in a classroom, and it might not look like the book studying that we saw in school, but everyone who’s good at something learned it somehow.

When you get discouraged, do not measure yourself against other people. That is inherently discouraging. It’s inherently discouraging because you see your own struggle, but the other person’s success. It’s like you’re measuring your worst day against their best; struggle is usually private, and success is often public.

Basically, when things are not going well, I have a few choices: I can (1) quit forever, or (2) quit for a little while, take a walk, get a good night’s sleep, and try again, or (3), press on. If you really want to do something, default to option 3, use option 2 when you need it, and never use option 1. That’s it.

I knew a guy who fixed a lot of things, like floors and sinks and whatever, and he had a good saying. Whenever a task was taking longer than he wanted, he would just say, “it can’t win” and keep working. He’s right – it’s not like the tasks you’re attempting actively oppose you. There are two outcomes: You succeed, or you quit. Notice that neither of those outcomes lies outside yourself.

So remember, when you’re discouraged, choose option 3, unless you’re really hungry or tired or your brain is full for the day, then choose 2. Don’t choose option 1.

Till next week, happy learning!

-Will

Soft Skill: Avoiding Arrogance

At my day job, I just had a code review. Code reviews are, in general, awesome, because you find out what you’re doing right and wrong, and you get to talk to other programmers; talking to other programmers is awesome because they know things you don’t, so talking to them causes learning, which is our goal.

Anyway, at this code review, we talked about some stylistic inconsistencies I had introduced into the code base. (In this case, using named booleans in conditional checks, rather than inlining the whole check, but that’s not what this article is about.)

One of my colleagues said something very wise (paraphrased heavily): Lots of stylistic decisions don’t matter that much, but introducing stylistic differences is bad; code is easier to read if it all follows the same conventions, even if those conventions are not the best conventions in the world.

Now, I knew I was introducing a stylistic difference; the problem isn’t that I wasn’t paying attention. The problem is that I thought I knew better. Maybe named booleans make if statements easier to follow, and maybe they don’t. But a code base where half the people follow one convention and half the people follow the other is definitely harder to read than a code base where people consistently follow either convention.

There’s a short, unpleasant word for making the wrong decision because you think you know better: arrogance. Looking back, I realized I was sitting there thinking, “these guys obviously didn’t read Code Complete enough times; I’ll show them.” Instead, I should have been thinking, “why am I the only one here whose code looks like this?”

I still like named booleans, because they tell future programmers what you thought the result of the conditional check meant, and in my own projects I’ll probably continue to use them. But I learned an important lesson at this code review: If you find yourself doing something the other developers don’t, because you “think you know better,” please reconsider. Or better yet, ask someone why they do it that way. But don’t sit in your cube, decide they’re wrong, and make the code a little uglier in the process.

Arrogance is a major obstacle to learning, and I’m glad I went through a code review before this particular instance of it went on any longer.

Here’s a thought: the next time you think, “this is an ugly method. I would have written a method that was elegant, and efficient, and easy to read, where everything had clear, even beautiful names. I could do so much better,” copy the signature of that method into a blank code file and try to write it better. There are only two possible outcomes of this exercise, and they’re both good: You’ll either come up with a better method, which you can suggest as an improvement. Or, and much more likely, you’ll realize that the problem that method solves is harder than you thought, and you’ll be a little more generous when you read code in the future. In both cases, you learn.

Till next week, happy learning!

-Will