Ben Northrop


Decisions and software development


5 Tips for New Developers


(1 comments)
August 1st 2011


A couple weeks ago, I came across a good post, lessons for software industry novices, and it inspired me to add a few more just for the heck of it...

1. Don't check in code right before you go home

It's 6:00, the [wife|kid|girlfriend|dog] is expecting you home in 30 minutes, and you just finished a really simple change. There's no harm in just checking this code in now before you go, right? DON'T DO IT! I swear I have been burnt by this too many times to count. If the build breaks or some bug pops up, you won't be there to resolve it...and every minute it goes unresolved you'll be losing good will with your fellow developers and testers. Obviously I always run a local build before checking in, but now I go a step further and try to hold off on any check-in if it's within an hour of me going home - better safe than sorry!

2. Batch your questions

As a new developer (or developer new to a team), you'll have loads of questions. This is good. Don't keep these to yourself, however don't ask them one-by-one as they pop into your brain. Write them down on a list, and only when you can go no further, then ask the tech lead/analyst/business owner all of your questions in one batch. People are almost always happy to help, but if you can limit the interruptions, it's always appreciated.

3. Stop complaining!

Yes, the system you work on is insanely complex/convoluted, the business owners are totally irrational, and the development team dysfunctional. Still...don't complain. If enterprise software development was easy, businesses could (and would!) hire people a lot less smart than you, and pay a lot less money. The fact that things are frustrating just means that talented developers are needed, and that we make a good living. If things are so bad, then quit - there's always a market for good developers. Otherwise, do what you were paid to do: make things better!

4. Keep it Simple - Format Matters

We all know the virtues of writing clean, readable code, but we don't always apply this rule to the artifacts we produce: emails, documents, models, etc. Spending time tuning/formatting these other products not only makes our ideas easily digestable by others, but it makes our ideas more persuasive as well. The minute it takes to tune an email for the people reading it is well worth it.

5. Be Nice!

I'm not talking about "nice" in the traditional sense, but rather in a game-theoretic sense. Many development activities can be boiled down to simple prisoner's dilemma situations: e.g. if we all comment our code we're better off, but individually it's more rational to be a free-rider and just take advantage of everyone else's comments (which is why it's sometimes irrational to comment code. It's been found that many people naturally play a tit-for-tat strategy, meaning if everyone else is "nice", they'll be nice too, but when someone free rides, they'll follow suit. Given this, it's always good to play the nice strategy and help others (review code, unit test, etc.). As soon as you don't, others won't either, and your development team can quickly turn to an every-man-for-themselves.

I believe that software development is fundamentally about making decisions, and so this is what I write about (mostly). I've been building software for about 20 years now, as a developer, tech lead, and architect. I have two degrees from Carnegie Mellon University, most recently one in philosophy (thesis here). I live in Pittsburgh, PA with my wife, 3 energetic boys, and dog. Subscribe here or write me at ben dot northrop at gmail dot com.

Got a Comment?


Sign up to hear about the next post!

If you liked this article and want to hear about the next one, enter your email below. I don't spam - you'll only receive an email when there's a new post (which is about once a month, tops). It's all low-key, straight from me.

Comments (1)

August 08, 2011
I really enjoyed the original article, but I like your #2 tip.

I've always found that making frequent interruptions are a good way to piss off your boss, but not asking questions at all gets the same result. The best approach is to make as few interruptions as possible, but ask all your questions at once.