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”

Online Course: T-SQL on EdX

When you’re starting out as a programmer, you’re going to need to know SQL. I know from experience. Before I started my first programming job, I’d taken some algorithms and data structures classes, done an internship, and learned lots and lots of syntax for C#, the language I’d be using. Then I got to work, was meeting people, and the first question my boss asked was “How’s your SQL?”

Here’s the thing: Lots of software runs on servers and interacts with data. Lots of data lives in relational databases. The lingua franca for getting data out of relational databases in SQL. Even if you are not a data base administrator, you are going to want enough SQL to do a few things: Continue reading “Online Course: T-SQL on EdX”

The Right Little Thing: Manage Complexity

Code Complete 2 is a book that I think every programmer should read. And, atypically for this industry, I doubt very many people will disagree with me.

There’s one particular quote, from chapter 5 (page 78 in my edition) that I think is worth buying the book just to have:

Managing complexity is the most important technical topic in software development. In my view, it’s so important that Software’s Primary Technical Imperative has to be managing complexity.

Continue reading “The Right Little Thing: Manage Complexity”

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!