5 Tips for New Developers

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'm an "old" programmer who has been blogging for almost 20 years now. In 2017, I started Highline Solutions, a consulting company that helps with software architecture and full-stack development. I have two degrees from Carnegie Mellon University, one practical (Information and Decision Systems) and one not so much (Philosophy - thesis here). Pittsburgh, PA is my home where I live with my wife and 3 energetic boys.
I recently released a web app called TechRez, a "better resume for tech". The idea is that instead of sending out the same-old static PDF resume that's jam packed with buzz words and spans multiple pages, you can create a TechRez, which is modern, visual, and interactive. Try it out for free!
Got a Comment?
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.