Tips to incrementally check in code without breaking the build

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/tips_to_incrementally_check_in_code_without_breaking_the_bui.htm]

No one wants to break the build. However, every time you check in code, you risk breaking the build. This leads some developers to avoid checking in for days (or weeks!) until they have a dangerously-big component. That has its own problems. Integration is pay-me-now-or-pay-me-later. I'm a big fan of paying upfront with small, continuous check-ins. Here are some tips to do check-ins without breaking the build:

• Try to do multiple smaller commits as opposed to one giant commit.
• Where reasonable, try to keep a component split into multiple smaller files instead of one giant file, especially if these files are updated by many developers. This reduces contention, and hence likeliness of breaking the build.
• Check in a file that won't hurt anything, like a class file that's not added to the project yet.
• Make sure you understand how code-generation integrates into your build. It's easy to have the code "work on your machine", only to have a code-generated script on the build server overwrite your changes and break the build. Make sure all your local code is in sync with what will be actively code-generated.
• Make sure you always check in all the needed files, especially files that get "registered" with a master file list. For example, C# files get registered with a csproj project file.
• Use a source control that allows merging (SVN, not VSS)
• Split your code into isolated components - i.e. reduce dependencies in your code.
• If you're working on a unit test, and you "need" (?!) to check in a partially-completed test that currently breaks, then consider applying the "Ignore" attribute so the test doesn't run yet.
• If you really need to check it in, perhaps comment out the breaking section.
• If you're checking in to send code to another dev, consider not checking in, and sending them a patch instead
• If you're checking in to the global trunk just to "back up" your work, consider checking into your own private branch.

The non-financial resources at a manager's disposal

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/the_nonfinancial_resources_at_a_managers_disposal.htm]

A good manager knows what resources they have at their disposal, and how they can exchange those resources for other things. The most basic resources are budget and headcount. But a creative manager can find a lot more:

• Offering interesting projects and opportunities
• Letting developers work from home (less driving is good for the environment too!)
• Offering your time to hear out the devs.
• Opportunity - If a dev is interested in a certain new technology, consider offering that if they research this task on their own, then potentially the team can leverage it - which means they can learn a ton more about it.
• Work hours - to avoid rush-hour, or coordinate with work-life balance, let the devs come in an irregular hours (like 6am-3pm).
• Offer encouragement - some developers are motivated knowing that their boss supports them and publicly appreciates the good job they've done.
• Permit devs to install safe games on their laptop.
• Give them a "free" PTO day to go to an in-town conference (Yes, time is money, but for some reason, mgrs and bureaucracies are more apt to give you time than money).

Even a little money can be stretched a long ways:

• If they're working overtime at the office, consider at least buying them lunch or dinner. I remember on a death-march consulting gig when my manager kept bringing us lunch. He explained that if we're working 4 hours of overtime (say $400 billable dollars), he could at least help by getting us a $10 lunch. I thought he was a really good manager. Sure, he got the better end of the deal, but it was still a nice gesture.
• Buy a book to encourage them to learn. Yes, it's ultimately the developer's responsibility to learn, but if they're going to spend 20 hours pouring over a book to learn a technology that helps the company, a $30 investment is a no-brainer.

We need to get this done

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/we_need_to_get_this_done.htm]

Anyone can say “we gotta get this done ”. Sometimes this is just a broken record - everything is top priority and needs to be done now - but sometimes a specific task is truly on the critical path and is blocking other people.

Telling a developer to essentially "hurry up" won't get things done faster, it will just annoy the developer, or perhaps make them hurry and write sloppy code which will cost you more in the long run.

While I'm certainly no management expert, I'd expect at least a few questions you could ask any developer are:

1. Everything considered (other tasks, meetings, misc distractions, research time, expected delays, possible overtime) - what date and time can the developer have this done by? Note that you want a date, not "how many hours do you think this will take". An 8-hour task may spread across 3 days if there are other distractions. Get an honest, unrushed date based on the developer's estimate. Note that you also want a time. Does "Wednesday" mean 8:00am, or midnight? This also gives the developer a concrete goal to shoot for, as opposed to "get it done real fast".
2. Is there anything that can help the developer get this done faster (delegate sub-tasks, better hardware/software, tools, a technical roadblock holding you up, pair programming with another dev)? The goal is for the manager to offer practical help by shifting around resources. If this task is really so important, then it is important enough to provide extra resources too.
3. Acknowledging that surprises do come up, so you understand if the date cannot be met, but the developer should at least alert you as soon as they reasonably think they can no longer meet the date - and provide an updated estimate. The goal is to not get suddenly surprised on the target date with a late feature.

Of course, it also helps to work in smaller increments with verifiable milestones along the way. It can be easier to manager 5 small 1-week "milestones" than a single big 1-month project.

All of these involve give and take. Yes you can have it be a certain date, but the developer determines what that date is. Yes you can have it earlier, but you need to provide the developer more resources. Yes you won't be surprised on the target date with bad news, but that's because the developer is encouraged to tell you the bad news up front.

Consider nixing the projector for quick demos

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/consider_nixing_the_projector_for_quick_demos.htm]

Say you want to do continuous development, with quick demos to management (or business sponsors) every week. One thing I've found useful is to nix the projector. I've been in places where in meetings, you can't show something on a computer unless it's on a projector. And of course for large meetings and official presentations I can see the benefit. However, if you want just a small and quick sanity-check meeting, there are several benefits to nix the projector:

• Faster setup - I've seen endless problems trying to hook developer machines up to a seemingly innocent projector (can't turn on the projector, need to install special sofware, your laptop won't register, the screen doesn't show, different resolution sizes, adjust the font size, bad glare from the windows, etc...). If you only want a 10-minute "spot-check" demo, you don't want to waste even 5 minutes setting up a projector.
• Smaller crowd - Something about human nature seems to be drawn to a presentation on the big screen (Maybe people think the bigger the screen, the more important, and they don't want to miss out on important things). However, by having just a laptop screen, it forces you to have a smaller crowd - maybe 5 or 6 people at the most.
• Easier for multiple machines - Switching a projector between multiple laptops can also be risky (see "faster setup"). If for some reason you have multiple laptops (say you haven't integrated all the pieces for the demo onto a single machine yet, or you're showing very different scenarios that don't "fit" on one laptop), not having to worry about switching the projector can just make it more convenient.
• Easier room requirements - A lot of offices only have a few "special" rooms that contain projectors - and these rooms are usually already booked. Not needing a projector means you aren't limited to these special rooms, and therefore have far more room options available.

I realize it's trivial in the scheme of things, but not needing to worry about the projector can eliminate some of the red tape and setup that distracts you from the things that aren't trivial.

Chicago Code Camp website is live

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/chicago_code_camp_website_is_live.htm]

The LCNUG and ALT.Net groups are pleased to present the Chicago Code Camp on May 30th at College of Lake County. We've got the website up, and it will continually add more details there.

So far, we're expecting a broad range of talks from many different speakers.

As a reminder, this is a free event.

(Previous: First code camp announcement)

You are not alone

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/you_are_not_alone.htm]

I continually try to get more involved in the developer community (such as via user groups and tech events). This gives me the opportunity to talk to developers across a wide spectrum of different projects. One type of developer, for whom my heart really goes out to, is the lone developer struggling in isolation. They're trying, but they're on a team of one - the only consultant on a project, a remote developer working from home, or the only developer in a one-person "department" of a small company.

The problem is that software engineering is too hard to do alone. It's easy to feel like you're on the outside looking in - while other departments have niche experts and devs to cover your back, you're left all by your lonesome to figure out the entire thing yourself.

Sometimes you can get out of the situation - switch jobs or press the business sponsors to hire a secondary dev (do they really want the entire project resting with one person, without any backup if you become unavailable?)

However, even if you cannot change your department or project's headcount, you are still never alone. Especially with the online developer community, blogs, forums, user groups, conferences, books, and the like. It is one joy of software engineering in today's world - you are never alone.

Related: What if you're a big fish in a small pond - life without a mentor?

How will you learn the next wave?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/how_will_you_learn_the_next_wave.htm]

New technology is constantly coming out. Some of these are small - a new tool, a special trick, or some open source library - and these can be learned easily enough. However, every few years, there's a fundamentally new wave of technologies that makes the previous wave obsolete. For example, classic ASP to ASP.Net 1.0, to ASP.Net (3.5 with Ajax, JQuery, and MVC) to Silverlight. - every few years there's a significantly more powerful UI technology.

So, the question becomes, how do you continually keep up with the next wave?

You have three main categories of options:

• Your company trains you. This was popular during good economic times. Some companies have a training budget based on a percent of the employee's salary.
• Your company doesn't train you, so instead you train yourself.
• You don't keep up, and eventually become obsolete.

The last option speaks for itself - but there's a difficult balance between the first two. Every developer should be able to ask their manager "What role, if any, does the company have in assisting me to learn the next wave of technologies?" Every manager should have a ready answer.

Realistically, you need both internal motivation and external support. For example, if your company won't even pay for a $30 book on a hot new technology, then you're screwed. On the other hand, you simply can't learn a whole new technology by passively skimming blogs during your lunch hour.

Personally, I'd emphasize the concept of an upward spiral. If you want to be a decent developer, be prepared to invest:

• Time - prepare to spend on average of at least 8-10 hours a week doing continual education. Maybe you're working 60+ hour weeks at your company, and the 10 hours is part of that. Maybe you have a "cushy" 40-hour week job and you do the 10 hours on your "free time". Sure, there are weeks (or even entire months) where life needs you to take a break. Likewise, there will be other times when an in-demand tech first comes out that you may be sprinting.
• People - Try to get to a live-person event at least once a year, such as a user group or conference. Also, explicitly seek out peers who you can collaborate with (even doing informal code reviews with your coworkers, or discussing ideas during a lunch break).
• Blogs - Use a blog aggregator to continually monitor the industry leader's blogs. This will give you a heads up of new techs coming down the pipeline, so you can prepare. If the tech actually has potential (as opposed to just some other buzzword), you'll see it light up on multiple people's blogs.
• Books - Especially for a new wave, or for matured design patterns on existing techs, try to read a full book at least twice a year (I think once every other month is more ideal, but there's a balance).
• Projects - If you have the opportunity, put in the extra work to get on a project that uses a new technology that appeals to you. Ultimately, the best way to learn a new tech is to actually use it, and unless you use it on a real project, you'll always remain a hobbyist.

Essentially, learning a new technology takes hard, pro-active, work, which many devs are already willing to do. The question becomes how to best maximize your investment on that hard work.