Two weeks into the new app dev manager with a new organization. After moving through this transition a few times I can pass on the following advice:

• Start your one-on-ones or continue the existing ones.
• Spend a lot of time talking and walking around. Your brand new, and you need to get out and start getting a sense of the people and the organization.
• Gather your project and application portfolio. At this point the acronyms and lingo are still confusing, but you have to get a sense of where your projects are and whether any of them are struggling.
• Stay organized. You’re on a nasty learning curve for the first few months and the last thing you want to do is let your email, physical inbox, and voicemail start overflowing. (GTD works for me here.)
• Enjoy the surprises. Every organization has it’s own way of doing things and at least once a day for the first few weeks you’ll have some underlying assumptions shattered. In an earlier job in my career I remember picking my jaw off the floor about one week in. One of the developers on Project X Phase II explained Project X Phase I had never been deployed to production. Some unrelated projects had been rebranded as Project X Phase I so the team could declare victory on delivering phase I.
• Don’t make big changes those first few weeks. You don’t have the data yet.

This week I started fresh with a new company and a new title. After four years as a Software Development Manager and a short stint as an Enterprise Architecture Manager I’ve now returned to managing a group of internal IT developers. The current title is Application Development Manager.

The new organization is full of opportunities and challenges. Some of these include:

• Inheriting a senior development team.
• An organization which is still early in the process of formulating practices and process.
• High level support for process improvement a mix of CMMI, ITIL, PMI, and a bit of RUP at present.
• Systems with real high availability requirements.
• A JBoss shop.
• A QA team pushing hard to push for quality throughout the project and not just at the end. Plus they’re doing automation and load/performance tuning.
• Developers self-organizing a weekly gathering to discuss software topics.

I wake up about 5 am these days to go for a walk every morning. These days it’s a lot easier to bounce up and not just hit the snooze button. If I can get Perforce setup with a Hudson plugin I might just set up a continuous build box tomorrow.

A sense of fun can help new practice adoptions. After reading a post by Clint Shank on coming up with a continuous integration game Erik Ramfelt went ahead and created a Hudson plugin.

Currently the points you get are:

• -10 points for breaking a build
• 0 points for breaking a build that already was broken
• +1 points for doing a build with no failures (unstable builds gives no points)
• -1 points for each new test failures
• +1 points for each new test that passes

Looks like a good starting point. I really like the idea of getting points for implementing new tests.

As a manager of developers I have a goal of trying to provide at least one week of training per year at a bare minimum. For senior developers or even journeyman developers in transition the best available option is often a conference. The benefits far outweigh the costs:

• Exposure to software development outside of your small corporate IT shop. I know people read blogs and books about software, but talking to real people can bring the message home. I had been evangelizing things like TDD and continuous integration among my developers, but when I sent four of them off to a conference they all came back saying, “Wow, this TDD stuff, design patterns, and agile really are big deals. I had no idea.”
• Proving your company really is about the people in it by investing in them. There’s lots of talk at most companies about how much they value their employees, but when it comes down to it training requests are denied on a regular basis. And since so many companies pay lip service to training actually providing it can be a major recruiting advantage.
• One conference can pay dividends throughout the year. Your developers come back with lots of new ideas and continue to research and bring these ideas into their day to day development. Your code base will actually get better and your developers will be more productive. And that extra kick in their step around the office is the sign of a re-energized employee. Energized employees are a great asset.

Unfortunately this is the most common experience:

Nearly a year ago, I posted a question on Spring Forum entitled, “am I working for the wrong companies or is it just not that common to attend conferences?”. I’ve worked as a developer for over six years and as yet I’ve never had the opportunity to attend a single conference. I thought I might be alone in this, but I’ve spoken to a large number of developers who are in exactly the same position, some of whom have worked in the industry far longer than I have.

After some debating I came across the much talked about book, The Little Schemer, at the Borders near Union Square in San Francisco. It compelled me to make a purchase and I’ve slowly started going through the examples. I really like technical books where you don’t actually have to be on a live computer to constantly try the exercises. And the cartoon elephants make me happy.

Next steps:

• Install an xUnit in this case, SchemeUnit
• Install a text editor/IDE looks like DrScheme. (Even OS X screen shots)