A++

If you were only able to choose one book to make you a better programmer, that book would be Code Complete. There is a reason it’s the highest voted answer to the StackOverflow questions What is the single most influential book every programmer should read? and What development book made the most impact on you as a developer? as well as many others. Notice that second place for both questions is Pragmatic Programmer, you should go read that too, after Code Complete.

There really isn’t anything I can say about Code Complete to describe how truly awesome it is. From your future self and all of the people you work with please buy it and read it from cover to cover. I’m not kidding, you might think you know everything it covers, and if you’ve been programming for a few years you might even be right, but you won’t have thought about each of the topics explicitly and in the detail covered by Code Complete.

Reviews Book Reviews

Pop quiz: What are the different levels where you can catch defects in your code? Try to think of at least 5, I’ll wait …

I came up with nine:

1. Compiler
2. Static Code Analysis
3. Code Contracts/Assert Statements
4. Developer Testing
5. Unit/Regression Testing
6. Code Reviews
7. Dynamic Code Analysis
8. QA Testing
9. Users

This is an important list to have in the back of your mind as you program because as defects travel through what I call the Circles of Defensive Programming they get more difficult and costly to fix. If a bug gets all the way to your users it can become very costly for you and your company to fix. Now, not only will it take a lot of time and money to fix the bug, the solution will need to be deployed at an additional cost and your users probably won’t be too happy either.

So how can we make sure that any bugs that manage to get past our amazing coding skillz get caught as quickly as possible? I don’t know. If I knew I would be a multi-bazillionaire and I’d take over the world by systematically buying it (My easiest and most likely plan for world domination by the way). It takes hard work and dedication from the entire team at every stage of development just to make software that isn’t bug-filled trash. There is no silver bullet that will allow you to build quality software except hard work . But, there are some things you can do to catch defects as quickly as possible and make sure few if any get to your users.

• Make sure you have a good system at each of these levels. Each is good at catching different kinds of bugs and missing even one leaves a large gap in your bug stopping defenses. Get a system in place at each level and constantly improve it by making the weakest level stronger. How do you know which circle is the weakest? Keep track! Every time you find a bug figure out which circle should have caught it. That circle is weaker than it needs to be and if you get a few bugs that all point to one area you know where to focus your improvements.
• Automate as much as possible so it doesn’t take extra time from anyone. Bug checking that isn’t automatic and painfully simple (i.e. part of the automatic build process) is one of the first things to get tossed when things get a little behind schedule because, after all, we all write perfect code and every minute spent bug checking is a minute that could be spent trying to catch up to the schedule.
• Make all of the circles as tight as possible without making them burdensome. Strict checks will catch more defects but if they get too strict they might start finding a lot of false positives or make the code more difficult to work with, taking up more time and money than they save. That’s not even considering the fact that programmers do what they do because they like to solve problems. If your bug catching system becomes a problem they will solve it, and almost always in a way that is less than optimal for either of you. Experiment with how strict you can make things, don’t try to go too fast, and don’t forget to collect and listen to feedback from the developers.
• If a bug gets past the level of Code Contracts/Assert Statements don’t just fix the bug and move on! Fix the bug and try to write the code in such a way that the next time it happens it gets caught at least one level sooner. If you can move the check all the way to a compiler error the program won’t even be able to be built until the bug is fixed. At that point the cost of fixing the defect might as well be free.

Okay, okay, I know what you’re thinking. “That’s all well and good Bryan. I’ve heard of unit testing and code reviews but I don’t even know what static or dynamic code analysis are and since I’ve never needed them before they can’t be that helpful. Can they?”

You have a valid point. You probably have never heard of static or dynamic code analysis before and I’m sure no bugs have ever been deployed to your customers right? I thought so. Well first I’d like to tell you that if you use a modern IDE you have used at least rudimentary static and dynamic code analysis, apparently without even knowing it, and I bet it helped you catch a lot of bugs before they got out the door too. It’s probably best for me to just explain each of the levels of maintainability and give an example of each (from the .Net stack).

1. Compiler – Your first line of defense against things like typos, misspelled variable names, access violations, and all manner of other problems that mean what your trying to do is illegal in your chosen language. It catches so many bugs that some programmers will say “It builds, ship it!”, we call these programmers interns who will never be hired. The compiler is your first and most powerful line of defense against bugs, everything else is just the reserves that get called up when things manage to slip past. So Use It! Listen to compiler warnings (most result from static code analysis done by the compiler by the way), turn all of them on and get rid of the ones that are there. True, sometimes they are superfluous but you can suppress them on a case by case basis. Always treat a compiler warning just like an error and you’ll spend less time tracking down bugs and more time actually getting stuff done.
2. Static Code Analysis – Most modern IDEs have some static code analysis built in. Many of the warnings your compiler generates are the result of static code analysis. A more powerful analyzer like FxCop, StyleCop, lint, or to some degree ReSharper will let you know if you do things that probably weren’t what you intended. Things like “you never used this variable”, “you’re assigning in this IF statement rather than testing equality”, or “you’re raising the PropertyChanged event with a property name that doesn’t match the property it’s in”. Okay, I don’t know if any of them will give you that last one but it would be really helpful if they did. Interestingly enough, you can make it easier for a static code analyzer to find possible bugs by doing the same things you would to make a program more readable for a human. Most of the problems people tend to have with using a static code analyzer is that they don’t actually use one daily. Make it an automatic part of the build process if it can complete without doubling the compile time of your application. Otherwise make it a one-click process for a developer to run and put it on the build server as well. If the analyzer on the build server flags something then consider the build broken.
3. Code Contracts/Assert Statements – First, I’m just going to say assert statements when I mean both because code contracts are usually just a more powerful framework for assert statements. I always thought asserts were great for the hardcore anal-retentive types but they were superfluous in the real world because “I’m never going to be stupid enough to call this function with a negative number.” I was completely wrong. Assertions document the assumptions your code makes so that other developers know that null is never a valid argument for this code. If you have asserts throughout your code you’ll catch most instances of bad data as soon as it’s generated. One of the best things about asserts is that they are usually made so they don’t show up in release builds so you can happily assert away and know your team will be seeing error after error if the code is wrong but your normal error handling mechanisms will take care of the job when the code is actually released. This is a key point: Assert statements are not a replacement for proper error handling! You still have to handle any errors as if the assert statement wasn’t there. An assert statement is for documentation and catching things that, while they won’t throw an error, will cause your program to go all wonky. So how should you go about using Assert statements? Start in your Select-Case statements, if the case statements should run the whole range of inputs then you should assert that the default case never hit. Next go through the public functions of your classes and put some asserts in there to catch unexpected input arguments, but you need to make sure you still handle any errors that result from bad input. You’ll find many other places for a few nice assert statements but those should get you started. I know you’re thinking “Why should I use an assert rather than throwing an exception when I have to do both anyway?” That’s simple. An error can be caught and handled without anyone ever knowing it, an assert can’t. You can also add an assert while handling the invalid input nicely so the developers know it’s an error but your program continues to act normally. Even if you aren’t convinced, take the time to check out Code Contracts, I promise you won’t be disappointed.
4. Developer Testing – A lot of companies put way to much emphasis on developer testing. If the developer had thought of the error or missed requirements already they would have put in code to handle it. Developer testing is a good way to make sure the code does what the developer intended it to do in the cases they thought through. Unless some unexpected input is received the developer is only going to find and fix the most obvious bugs and then send it on. Even if you have a policy that the developer tests everything extremely thoroughly before it’s checked in they still won’t catch most of the bugs and it certainly won’t be the most cost effective way to get rid of defects in your program. Don’t get me wrong, developers should still test all of their code before checking it in but you shouldn’t expect them to find a very large percentage of the bugs that have survived until this point.
5. Unit/Regression Testing – Unit testing and Test Driven Development (TDD) are all the rage nowadays, and for good reason. Unit tests exercise the code with a large range of inputs that you aren’t likely to encounter in standard testing and regression tests make sure you don’t repeat bugs you’ve had before. There’s a lot of literature out therestating the case for unit testing much better than I ever could, take a look. Reading about unit testing might make it sound like it is the be-all and end-all of software quality and bug fixing. It isn’t, it is merely one more piece of a much larger puzzle. It’s also worth the time to check out Pex. It hasn’t yet reached its full potential but it’s developing quickly and will be incredibly powerful when combined with normally written unit tests.
6. Code Reviews – If you don’t have some sort of peer code review system in place, do it now! I’m not kidding. My company started using Code Collaborator around six months ago and it has proved invaluable. I’m planning on writing a review of it later but I’ll say it’s a great choice and well worth the price. Code reviews catch a large percentage of the defects that get to this point, IF the reviews are kept simple and only do one thing at a time. Fix one bug, implement one feature, etc. I’ve found that many developers don’t completely grok source control so multiple change-sets and switching among difference views can get confusing quickly. Keep it simple and you’ll find a lot of bugs, let the review get more complex and you’ll only find spelling errors. What code reviews do is get more sets of eyes on a section of code meaning more error conditions thought of and guarded against, less confusing code (reviewers should always speak up if they don’t get what the code is trying to do), and dissemination of knowledge of how the section of code works. Take Code Collaborator for a spin (they have a trial) or at least take a look at the articles, blog posts, and book they’ve put out on the best practices for performing code reviews and start reviewing your code.
7. Dynamic Code Analysis – Dynamic code analysis is usually used to find memory leaks, security errors, and sometimes Heisenbugs. Most modern IDEs also contain some dynamic code analysis, most commonly referred to as the debugger. Basically they watch your program as it runs to make sure it’s not doing anything it’s no supposed to. You can also use them to track memory usage or execution time if you have constraints on either of those. Honestly, outside of the debugger and profiling there aren’t a lot of compelling tools out there that I know of at this time but they are coming along quickly with the recent rise of dynamic languages. If you are running in a memory or execution time constrained environment they are definitely something to look into now, otherwise there will be some excellent tools coming along in the next couple of years so you should keep your ears open.
8. QA Testing – Testers are your last line of defense against bugs getting out to your users. It’s their job to test the program in every way possible and figure out the steps to reliably reproduce every bug they find. They will also probably give a lot of usability input. Not just anyone can be a tester, it takes a very rare person and there will be as much variability in the skills of the testers as there is in the skills of developers. Don’t skimp on your testers! Make sure the good ones are well paid, not bored, and have a clear career advancement path. Also, good testing takes a long time, don’t expect someone to be able to go through an entire application in many different situations before lunch. Delegate time to test a feature just as you did to implement it.
9. Users – You can always hope that no bugs actually make it to your users, but we all know that some will sneak out. Make sure you have a good support staff with an actual human on the phone and quick response times. They should be capable of troubleshooting the problem and collecting all of the information that is relevant. Once they get it to developers and get their feedback they can give the customer a good idea of when to expect the issue to be fixed.

Recommended References:
Code Complete 2nd Edition by Steve McConnell, specifically Chapters 20-22
Best Kept Secrets of Peer Code Review by Jason Cohen
Microsoft Devlabs: Code Contracts

Maintainability Code Collaborator, Dynamic Code Analysis, Software Quality, Static Code Analysis, Testing

No matter what you do with WPF you’re going to run into panels at some point. Having a good understanding of the available panels and what they do is essential to creating or modifying a UI in WPF. People keep asking for a basic overview of the panels so this is my attempt to shed some light on the situation. Questions? Something you don’t understand? Put it in the comments and I’ll do my best to explain the concept.

Canvas
A Canvas allows you to precisely position elements within a region. This is also one of the few panels that allows elements to easily overlap (the other I know of is the Grid). In many cases you might think you need to use a Canvas, you don’t. Much like the GOTO a Canvas is a royal pain in the butt to maintain and it tends to break layouts when changing window sizes or adding new elements. The only possible reason I have ever seen for using a canvas is when laying out drawing elements (e.g. Path, Shapes) or when you’re Bea Stollnitz making a cool example.

DockPanel

The DockPanel allows you to dock UI elements to the edge of the panel while letting another element fill the rest of the space. It is a great replacement for most uses of the Grid because of its lighter weight.  The DockPanel is one of my favorite panels for larger scale layouts and should become one of yours as well.

Grid

The Grid is probably the most powerful of all panels. It is also one of the heaviest in terms of CPU and memory usage. That isn’t to say that you should avoid using a Grid if you need one, just don’t use it in every place you need a panel if another type of panel (other than Canvas) will work just as well. With a Grid you can make any layout you could make with HTML tables. You can size columns and rows either based on their content (Row Height/Column Width=”Auto”) or based on what the Grid is contained in (Row Height/Column Width=”*”).

StackPanel

The StackPanel is the bread and butter of many layouts and especially within control templates. Basically the StackPanel stacks items either vertically or horizontally. One thing to be careful of: the StackPanel is unconstrained in the direction it is stacking, e.g. you could stack buttons right off the screen and even if you add scrollbars depending on the visual tree they may never appear.

UniformGrid

The UniformGrid is an interesting control. It lays out elements in as near to a square grid as it can without having to specify the number of rows or columns within it. The most common use I’ve found for this is as the ItemsPanel in an ItemsControl. Say you want all of your items displayed in two equal columns. All you have to do is tell the UniformGrid you want two columns and it will make two equal columns and fill the items into however many rows are required.

WrapPanel

The WrapPanel acts much like a StackPanel except that when the items stack to the edge of the panel they wrap. The same caveats with scroll bars apply, in many cases you have to set a height or width to get it to wrap items properly (since the height and width properties are basically evil try using MaxHeight/Width).

Edit: Here is a similar post on Code Project with some more advanced examples.

XAML Fu basics, Canvas, DockPanel, Grid, panels, StackPanel, UniformGrid, WrapPanel

You know how sometimes you run into problems that you know should be really simple but you just can’t manage to solve them? Well one of those problems for me was making a grid an ItemsHost and actually having it work. Sure you can always set IsItemsHost=”True” but you’ll just end up with every item in your ItemsSource all stacked on top of each other. A few weeks ago I ran into this same problem again and couldn’t find a way around it. So after beating my head against the wall for a few hours I finally gave up and posted on StackOverflow, within a half hour I had the answer I’d been trying to figure out for the better part of a day.

It turns out that setting IsItemsHost to True on a panel creates the required ContentPresenters and nothing you can do will let you get at them directly (believe me, I tried). The solution is to create a keyless style that targets ContentPresenter and let this style take care of the dirty work.

Without furthur ado, here’s an example.

The Data

Class DataPoint
	Private myRow As Integer
	Public Property Row() As Integer
		Get
			Return myRow
		End Get
		Set(ByVal value As Integer)
			myRow = value
		End Set
	End Property

	Private myCol As Integer
	Public Property Col() As Integer
		Get
			Return myCol
		End Get
		Set(ByVal value As Integer)
			myCol = value
		End Set
	End Property

	Private myText As String
	Public ReadOnly Property Text() As String
		Get
			Return myText
		End Get
	End Property

	Public Sub New(ByVal x As Integer, ByVal y As Integer)
		Me.Row = y
		Me.Col = x
		myText = "Column " + x.ToString + ", Row " + y.ToString
	End Sub
End Class

Load the test data and set it as the data context for the window

Class GridAsItemsHostExample
	Private myTestData As TestData

	Public Sub New()
		InitializeComponent()

		myTestData = New TestData()
		Me.DataContext = myTestData
	End Sub
End Class

Class TestData
	Private myDataSet As List(Of DataPoint)
	Public Property DataSet() As List(Of DataPoint)
		Get
			Return myDataSet
		End Get
		Set(ByVal value As List(Of DataPoint))
			myDataSet = value
		End Set
	End Property

	Public Sub New()
		Me.DataSet = New List(Of DataPoint)
		For x As Integer = 0 To 1
			For y As Integer = 0 To 1
				Me.DataSet.Add(New DataPoint(x, y))
			Next
		Next
	End Sub
End Class

And finally the window, note the ContentPresenter style.

<Window x:Class="GridAsItemsHostExample"
		xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
		xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
		Title="Grid As ItemsHost Example"
		SizeToContent="WidthAndHeight">

	<ItemsControl ItemsSource="{Binding DataSet}">
		<ItemsControl.ItemContainerStyle>
			<Style TargetType="ContentPresenter">
				<Setter Property="Grid.Column"	Value="{Binding Col}"	/>
				<Setter Property="Grid.Row"		Value="{Binding Row}"	/>
				<Setter Property="Margin"		Value="5"				/>
			</Style>
		</ItemsControl.ItemContainerStyle>
		<ItemsControl.ItemTemplate>
			<DataTemplate>
				<TextBlock Text="{Binding Text}"   />
			</DataTemplate>
		</ItemsControl.ItemTemplate>
		<ItemsControl.Style>
			<Style TargetType="{x:Type ItemsControl}">
				<Setter Property="Template">
					<Setter.Value>
						<ControlTemplate TargetType="{x:Type ItemsControl}">
							<Grid HorizontalAlignment="Stretch"
								  IsItemsHost="True"
								  ShowGridLines="True">
								<Grid.ColumnDefinitions>
									<ColumnDefinition />
									<ColumnDefinition />
								</Grid.ColumnDefinitions>
								<Grid.RowDefinitions>
									<RowDefinition />
									<RowDefinition />
								</Grid.RowDefinitions>
							</Grid>
						</ControlTemplate>
					</Setter.Value>
				</Setter>
			</Style>
		</ItemsControl.Style>
	</ItemsControl>
</Window>

Code Samples Grid, ItemsHost, WPF, xaml

This is Part 3 of a 3 part series on how you should go about figuring out if a company is right for you during the interview process. In Part 1 I looked at how to evaluate the people you see outside of the interview and the equipment you’ll use, Part 2 examined some of the questions you should ask your interviewers, and in this final part I’ll look at evaluating the company’s software and development tools/methods. I’ll preface this post by stating that this is a huge topic of which a large part involves personal preference, take everything I say with a grain of salt (as you should everything you read) and feel free to comment if you have other opinions.

• Language(s)
  • What programming language will you be working in?
  • Is it a language you’re comfortable working with?
  • What is the age of the language? If it’s really old it could be a sign of a shop that doesn’t rethink its tools and methodologies very often. If it’s extremely new you might have problems finding help with problems you have. Using extremely new languages is also a sign of management that is constantly chasing buzzwords or a “silver bullet” (hint: There’s no silver bullet) to cure their software development woes.
  • Is the language still active? If the language isn’t being used anymore there’s usually a reason. Programs may be impossible to write, difficult to maintain, or the libraries just never got up to snuff. Whatever the reason, a dead language should be left that way. From a career development point of view you will be gaining few skills that will further your career (unless it’s COBOL and please don’t cause yourself that pain).  In addition to any problems with the language and/or its libraries you will probably find it difficult to get or find much help if you run into problems.
• Source Control
  • Do they have a source control system set up? I really don’t care what reason(s) they might have for not having source control, if they don’t have it you need to run. Run like the wind and never look back. I don’t care if the only development they do is for one internal user and made by one developer, lack of source control should be a deal breaker. I will modify my initial statement slightly, there is one and only one reason for not having source control and that is if you are being hired as the company’s very first developer. But on the day before you are hired they had better be asking what kind of source control you’d prefer to have. In case you’re wondering, doing diffs on archived directories is not source control.
  • It’s not Visual Source Safe is it? As much as I like to joke around I’m serious on this one. In my experience VSS might be even worse than not having source control at all. At random times it will decide to drop your files from source control while at the same time corrupting them on your local machine. I hope a coworker has a fairly recent copy and you don’t need any previous versions. Have fun.
• Bug tracking and fixing
  • Do they track bugs and does everyone use the bug tracking software? You can’t do your job well without (at the very least) some sort of bug list as well as a fixed/outstanding status. I don’t care if it’s a shared Excel spreadsheet, they have to have something.
  • Does priority go to bugs or features? This probably should have gone somewhere in Part 2 but there wasn’t a good place for it. Priority should almost always go to bugs, otherwise you will be building new features on the top of bugs and possibly relying on buggy behavior in the feature. This might be something you can help change later so it isn’t a deal breaker but you should take it into consideration.
• Testers
  • Does the company have testers? They should. That being said, I have yet to work at a company with testers. Fact: Developers are rarely good testers and are never good testers of code they’ve written. If a developer thought of a bug or security hole then they’ve already guarded against it, it’s the ones the developers don’t think of that are the problem. Good testers are deliciously, diabolically evil. They’re the type that introduce Little Bobby Tables to your search text boxes, just to see what will happen and, oh yeah, do it while using a screen reader. Is that in your normal testing repertoire? I didn’t think so.
  • Does the company have enough testers? I don’t know how many is “enough”. Testers come with a range of skill levels and, just like developers, the best will be an order of magnitude better than the average. My best guess is no fewer than 1 tester for every 10-15 developers should be the lower limit.
• Development Environment
  • Are you comfortable using it?
  • Is it the newest version available? If not is there a very good reason? Cost is not a reason, if it saves you five minutes per day the upgrade will pay for itself in a month or two. Always make sure you’re using the sharpest tools possible.
  • It’s not vi is it? Remember vi is a subset of all evil.
• Code Reviews
  • Do they do them? Code reviews are something that I’m really starting to think signify a really good software company. They help developers exchange ideas and methodologies (read: learn from each other). In the worst case the best developers raise everyone else up to near their level. The slightly less amazing developers might not always know why they should tackle a problem in this way rather than that way but they will know that they should. In the more normal case everyone learns from everyone else and code quality and maintainability go up. This means everyone gets to have a much better time getting things done rather than trying to stack kludge upon kludge to get a feature to work. There are so many benefits for the developers and yet the biggest benefit comes from code quality (see Code Complete chapter 21). Getting a second set of eyes on the code finds more bugs and other defects than almost anything else you can do. Even with all of the benefits of code reviews it doesn’t seem like most software companies do them so I would give a company that has a code review policy a major bonus over a company with no code reviews.
• Specs
  • Do they make specs before coding starts? Many companies don’t do any planning up front either out of laziness or a misunderstanding of XP practices. While this might result in an early rise in some manager’s percent completed report what it really means is more bugs, headaches, and a slower project in the long run. At the very least the overall structure of the program needs to be laid out, a feature list made, key data structures chosen, and there should be some indication of the features most likely to be added in the future. Specs are also the only way a true unit tests can be written. If tests are not written with a spec you are testing what the code already does, or if you practice test-first methodologies then you are testing what you are going to write the code to do in 10 minutes.
  • Is the spec kept up to date? If the spec is allowed to go out of date then no one will use it and the time spent making it will be wasted. Even worse is if the spec goes out of date and someone follows it. Then you have time wasted in creating the spec, time wasted writing code to match an out of date spec, and then time wasted fixing the code to make it what it really should have been in the first place.
  • How formal is the spec writing process? As much as specs help there is a big difference between writing enough of a specification to get the work done and specifying so much of the program that you essentially write the entire program during the spec-writing process (UML I’m looking at you). If the process is too formal projects tend to take even longer and the program ends up so rigid that adding features in the future will be like pulling teeth from an angry ferret.

At this point I think I would be remise without the obligatory link to The Joel Test which contains a similar list by someone I have a lot of respect for. I hope this guide has helped you to decide if that company you’re looking at is right for you. You might even be someone with the capability to make changes within your own organization, in which case I hope I’ve given you some ideas and enough of the reasoning behind them that you don’t just dismiss them out of turn. Good software, really good software, can be made. It can be done without causing ulcers, without a terrible death march at the end of the project, without having to rewrite the software with every major revision, and without that terrible dead feeling inside you that comes from something you used to love so much sucking all of life out of you.

Hiring & Interviewing

This is Part 2 of a 3 part series on how you should go about figuring out if a company is right for you during the interview process. In Part 1 I looked at how to evaluate the people you see outside of the interview and the equipment you’ll use, in this part I’ll look at questions you should ask your interviewers, and in Part 3 I’ll look at software and development tools/methods.

• Technical Manager
  • What would you say your job is/What are your day-to-day tasks? With this question you’re trying to build up a good feel for the manager’s style. What do they say they do and what does it really mean? You should watch out for any managers that think they make decisions (or even help make decisions) about anything technical. A manager’s job is to point their programmers in a certain direction and then make sure absolutely nothing gets in the way, not even themselves. If you haven’t already you should go to www.joelonsoftware.com and read everything he has to say about management style.
  • Do you/how do you evaluate a programmer’s performance? No matter what some people may tell you, your performance as an employee is and must be evaluated in some way. Without some sort of performance evaluation there is no way to separate the wheat from the chaff, the superstars from the cave trolls. The danger is that some managers like to try to make their job easier by using metrics which are almost always gamed by programmers. Seriously, we are programmers, it is our job to figure out how a system works and either make it work better or use it to our advantage. Run as fast as you can from anyone that claims to use a metric and especially if it’s a “secret” metric that they came up with. Metrics like number of lines of code (ever seen Hello World take up 200 lines of code?), bugs per feature (guess how much time the team will spend fighting over easy features), and most insidious of all, how “interesting” is the solution the programmer came up with (I’m not kidding, I’ve heard of this). If you ever see the last one even being hinted at you need to run away screaming and try to rescue as many of the poor saps trying to maintain all of those disparate “interesting” solutions as you can on your way out.
  • What is your development process? Please God let there be a development process. You’re going to ask this question of everyone who interviews you that has anything to do with the development process. It is very illuminating what the different levels claim the development process at a company is. You should trust the lowest level you talk to the most but never bring up the differences during the interviews if you want to get the job (not to mention that it will probably skew the answers if you mention it beforehand). Watch out for managers that claim they practice agile or extreme programming and actually just use that for an excuse to never design or architect a solution before coding starts. Even with those practices there is a lot of architecture and design required before the first line of code, just not nearly as much as with a waterfall methodology. Also you shouldn’t necessarily be afraid of the waterfall model, in certain circumstances where requirements are going to be relatively static or well-known in the beginning the waterfall model works just fine.
  • Have you programmed? What languages? Not really a big deal, a good question to start off with. One thing to watch out for is someone who’s programmed a little bit but never really produced anything (programmed in school, as a side project, etc). Some of this type think they know how to program and don’t listen to the people who actually do when it comes time to make a decision. At best their expertise is likely just out of date (look for the shops writing programs in C that are not for small embedded systems).
  • Do any upcoming technologies excite you? Why? You need to have some idea of what’s coming down the pipe to ask this one because you want to be able to have a conversation. Count the buzzwords, if they make up more than 30% of the total word count you’re dealing with someone that probably doesn’t have a clue. Currently (beginning of 2009) buzzwords to watch out for are “the cloud”, “meta”-anything, and if you hear the words “Web 3.0” you probably just want to thank them and leave. This is the person you have to trust to aim you and your fellow programmers in a direction that will be profitable, not into the ground. If they don’t know what they’re doing you shouldn’t waste your time.
  • Have you read Peopleware, Mythical Man Month? Not a requirement but give this guy a gold star. Just as with your colleagues, you want to try to gravitate toward managers who are intent on furthering themselves.
  • What is the turnover rate of your team? How many have been hired in the last year? How many have left/been let go? Long story short: high turnover is bad. High turnover indicates a crappy place to work, if there are more than 10 people and the turnover is more than 10% don’t even bother unless you want to hate your life. Closer to 5% seems more normal.
• Project Manager
  • What do you do/have you done when a project is not going to meet a deadline? What would you do in the future? First, you should know that the correct answer is to cut features. Actually the correct answer depends on how far you are away from the deadline and how far behind they project is. If the deadline is still a long way off you start by prioritizing features, evaluating your process, making any changes where it is lacking while implementing the highest priority features and evaluating the changes, and then cutting features as needed until the deadline and estimates match back up. If the deadline is not so far away you cut features and cut them deep. Only if the project is going to be less than a week late is “crunch time” an acceptable answer.
  • How and by whom are schedule estimates prepared? How are they adjusted as the project goes on? Here’s a fun one. Why is it that so many times it is not the people who will be doing the actual coding that make the time estimates for the schedule? You wouldn’t trust a guy who’s never touched a hammer to tell you how long it would take to make a house but for some reason many people who’ve never coded a day in their lives seem to feel qualified to make time estimates. Inevitably at these places the schedules will be unrealistic, deadlines will be passed, features will be cut, testing will be non-existent, etc. If you avoid every company that does this you would only have the option of about three companies in the world to work for, but take it into consideration.
  • Roughly what percentage of projects meet their estimates? Short schedules suck, if many projects don’t meet their estimates it means you will get at least one unrealistically short schedule in your time at the company.
  • Have you read Mythical Man Month? I know I said it wasn’t required reading for managers, but PMs are different. They had better at least know what the myth of the man-month is and be able to explain it forward and backward to their boss.
  • How are decisions about requirements/features made? You’re watching out for anything like “the sales guys come to us with a list of features the customers want”. Seriously? Do you also go down to Home Depot, tell the guy at the counter what lumber and parts you’ll need, and have him tell an interior designer what to design? A programmer’s job is to find solutions to problems and then steadily make those solutions easier until you don’t have a problem anymore. The sales guy’s job is to find the people with problems (customers) and convince them that their programmers can solve said problems. Do exactly what an interior designer does: figure out what the problem is, find out the customer’s preferences, make some mock ups and present them to the customer, and then make the best mock up. Let the programmers figure out the features. Many large, successful software companies have a special position for this or have it be part of the program architect’s job.
  • What is your development process? Like I said, ask everyone, look for differences, and analyze what those differences may mean.
• Team Lead
  • In what way do you carry out your leadership role? Most team leads are simply the best or most experienced programmers on their team. Unfortunately, little thought seems to go into whether or not this person can be an effective leader. So what ends up happening is that the team takes their best or most productive programmer and cuts down the amount of time they can spend programming to around 50% while getting no or even a negative benefit as far as team leadership goes. Team leads should be mentors, leaders, and firefighters. They are the ones who delegate tasks, interface with management, keep the team on track, mentor new/younger programmers, and frequently fight the little fires as they occur. If they think they are do or are going to do and significant development work either they’re delusional or some aspect of what their job actually should be will suffer. Since this person will directly effect how the kind of experience you will have at this company make sure that you will get along well and they are competent enough that the team will run smoothly.
  • What would you say your split is as far as programming/management? As I said above, programming is only a small part of a team lead’s job. If they say the split is anything above 50% programming ask some more questions to figure out just how delusional they are. Hopefully they just think of keeping the team on track, mentoring, and fighting fires as part of the programming aspect which isn’t really a bad thing. Personally I would include mentoring and fighting fires as part of the 50% that is programming.
  • How do you train new people/bring them up to speed? This will be your first few months even if you’re an experienced programmer. Make sure the process will meet your needs.
  • What is your development process? This is probably the person with the most accurate handle of what the development process actually is, pay close attention to their answer.
  • Why do you use [whatever language]? What are the benefits and drawbacks of using it on this project? Every language has pros and cons for every application. A team lead had better know what they are and why this language was chosen for this particular project. Make sure they have actually considered the pros and cons and the decision wasn’t “religious” in nature.
  • What are each of your team member’s strengths and weaknesses? As team lead they have to know how to use each team member to the best of their ability and potential. While they probably shouldn’t want to name names you need to make sure that they recognize that each person is not interchangeable and certain people are going to be better or worse at certain tasks.
  • How long have you been at [company]? What did you do before? A team lead should have been at the company for a year or two or they will not have gained the sufficient trust from management to be able to do their job. They also should probably have had at least one other job at another company to make sure they have seen other ways of doing things. Also make sure they aren’t the type that hops from one company to another every two years. You want to join a team that is stable and that stability comes directly from the team lead.
  • Did you go to college? What was/were your major(s)? This one might not matter to some but if you want to make quality software the team lead had better have taken at least a few university CS classes. You learn many things learning to program on your own and people that learn to code on their own are almost invariably the best programmers. However, you have to have a solid foundation in algorithms & data structures, memory management, and a host of other topics that you really only learn in a CS program in order to be able to make good and informed decisions that a team lead has to make every day.
  • What programming/process related books have you read? What did you think of [any that you've read as well]? A team lead has to keep learning, period. If they haven’t read any books about current programming languages and tried them then they won’t know they benefits of other languages and which is the best choice for this particular project. If they haven’t read about different processes or teamwork methodologies then your team won’t be operating at full potential. Just make sure they read and it isn’t only Teach Yourself Head First PHP for Dummies in 7 Days.
• Colleague
  • Did you go to college? What was/were your major(s)? Ask this question for the same reason you asked the team lead. You will be having to maintain each other’s code. If you’re constantly having to refactor because your colleague uses an array when they should use a linked list or they don’t know what recursion is you’re going to get very annoyed (or at least I would). Additionally, if the company is having this person interview you they are probably considered one of the better people on the team. Try to aim for a company where this person is better than you so you can continue to learn.
  • How long have you been at [company]? What did you do before? The reasons are the same as for asking the team lead. You’re hoping they’ve been there for a little while but have still seen some other ways of doing things.
  • What programming/process related books have you read? If you want to be on a good team your colleagues need to keep learning as well. Some people can program for 3 years and get 3 years worth of experience. Most do not. Most people will program for 3 years and get 1 year worth of experience 3 times. Reading, learning, and applying new ideas is the only indicator you have of which kind of person you will be working with.
  • How does your team lead go about leading? Find out what they think the team lead does. You’ll have to actually analyze the likely sugar coated answer but the results can be very illuminating.
  • How does your manager go about managing? For the same reasons as the question about the team lead. What you don’t want to hear about is how they swoop in and make decisions that are technical in nature.
  • How realistic are schedules? What happens when a project is behind schedule? Make sure their answers jive with the PM’s.
  • What is the skill level of the team?/Where do you think you fit within the skill level of the team? If the person has been their for a while they know who’s good and who isn’t and in which area each person excels. Try to use this information to figure out how good the team is. If you think you’re going to be the most skilled person on the team you should either realistically evaluate yourself or look at another company.
  • Does the team go out for lunch or happy hour occasionally? A team needs to mesh to reach its full potential. To do this you have to occasionally do things together outside of work. Make sure the team gets along and has a good dynamic or you will only be about half as productive as you could be.
  • What are the specs of the computer you use? Are they adequate? If you’re not going to have the best computer you can utilize (within reason) then you are wasting your time here. I don’t care if it’s the latest and greatest computer, if it saves me 5 minutes a day then it pays for itself in a year. Also having fewer than two monitors is unacceptable, if every programmer doesn’t have two monitors on their desk just leave. No, I’m not kidding.
  • What about your chair/desk? Are they comfortable? You’re going to be sitting there for 8 hours a day 5 days a week. You’d better be comfortable or you’ll be fidgety and unable to get in the zone (flow, whatever the word is this week). This will make the day go slower for you and your day be less productive for the company. Therefore you being comfortable at your desk is a win-win for you and the company.
  • What is the environment around where you’ll sit like? Noisy? Foot traffic? Climate controlled? Once again you want to find out about comfort and ability to focus. If you can’t focus you’re wasting both your and the company’s time. I don’t know about you but I have much better ways to waste my time than being unproductive at work.

A quick word about panels – Panel interviews are terrible for evaluating the company. It’s rarely possible but see if you can speak to individuals during at least one round of interviews. If you can’t you have to take into account the makeup of the panel and try to get a feel for the company by questioning the people there. Realize though that the answers are likely to be more guarded and glowing. Panelists are going to be paying more attention to what they say because they are talking to more people and there is probably at least one boss/employee relationship in the bunch. Do the best you can.

Hiring & Interviewing

Great, you’ve done a lot of research into companies you’d like to work for, sent off an application or three, and gotten an interview. Have confidence in yourself and your skills and have a good conversation with the interviewers. Don’t worry, you will get an offer. The real question is whether you should accept it. How do you know whether this will be a good place to spend half of your waking life? That, my friend, is a mystery and one never covered by career councilors. I’ve now gone through the process twice, which isn’t nearly enough to make me an expert, but I will pass on what little knowledge I have. In Part 1 I’ll look at how to evaluate the people you see outside of the interview and the equipment you use, in Part 2 I’ll look at questions you should ask your interviewers, and in Part 3 I’ll look at software and development tools/methods.

First things first, pay attention to everyone you meet. You are looking for signs of stress. Usually stress manifests in facial expressions, overall body tension, and weight gain.  Do people look generally happy? Are there smiling faces around and maybe a couple of people conversing in a break room or at a desk (note I said “conversing” and not “having a meeting”)? Do people who are actively working look slightly frantic? Make sure you see the people you will be working with are included in the assessment, there are countless cases where it is only one project that is on a Death March while the rest of the company is doing great.

Look at how everyone is dressed, they should look clean but comfortable. If the programmers are dressed as well as you are during your interview you need to turn and run. If you’ve read Peopleware (see my review) you’ll know that this is a sign that either the management doesn’t know how to manage knowledge workers or things are not going well at the company and they are trying to fix things by making company-wide “professionalism” policies. Both are very bad signs. Of course the opposite is almost as bad. If people are in ratty jeans and don’t look like they’ve showered in the last week they either haven’t had time to go home to shower and change, they really don’t care about their job, or they are the reason for the dirty computer hacker/nerd stereotype.

The next thing to look at while walking around is the equipment the programmers are using. Does everyone have two monitors (hopefully at least 17″ LCDs)? Studies have shown that the one surefire way to improve productivity in programmers is to give them more monitor space. Even if it only saves 5 minutes in a day that second monitor will pay for itself in two months at a programmer’s salary. If every programmer does not have two LCD monitors it’s time to turn and run. Is everyone using fairly new computers with lots of RAM? Try and see if you can get the exact specs of someone’s machine. 64 bit and multicore are nice, RAM is essential. At least 1 gig is a must for anything that isn’t running Vista and 2 gigs for a Vista machine.  Make a note of the software the developers are using. Is it up to date? We’ll cover the software in detail in Part 3. Take a look at the chairs. Are there quite a few chairs that were self-bought or have extra pads and lumbar supports added on? You’re going to be sitting on your butt for most of the day, a good, comfortable chair is essential. Just like with formal dress if you are not comfortable you will not be able to concentrate and you will be in the zone much less often leading to reduced productivity and a literal pain in your butt.

Finally take a look at the noise level around where you would be sitting. Would you have an office with a door that closes? If not, are you near enough to sales/support/marketing/anyone else that’s constantly on the phone or otherwise talking? Are the cube walls tall enough to provide a sound barrier? Do phones ring constantly or is there a paging system that hasn’t been turned off and burned? Extra noise is distracting and keeps you out of the zone more often than not. Will you have a window within view or at least something in the distance you can focus your eyes on? Staring at a screen 2 feet away for 8 hours at a time will cause eye strain unless you have something at a distance you can focus on periodically.

I hope this has given you a good idea about what you should be looking for as you interview. Don’t forget to check out Part 2 and Part 3.

Hiring & Interviewing

A-

Peopleware: Productive Projects and Teams is one of the best books you can read if you work in collaboration with others. Primarily focused on managing and working with programmers to build the most productive teams and individuals possible, Peopleware covers noise and distraction in the workplace, creature comforts, “real” amount of work done vs seat time, building productive teams and “teamicide”, and quite a bit more.

This is a must read for anyone in a supervisory position over knowledge workers, whether you’re a team lead or CEO. Overall it is an excellent look at what factors influence the productivity of people around you  and how to many them happier and more productive. This is primarily by realizing that people are people and not cogs (the common management codeword is “resources”). It does assume a lot more control over the workplace than anyone really has, including the top executives, and I feel it sometimes goes overboard nearly to the point of absurdity on some of its topics. However, if you read with a certain degree of skepticism, as you should any book, you will find many strategies to help improve your productivity and that of those around you.

I strongly recommend (re)reading this book anytime your job changes. If it’s to a different company you will learn what to look for as you interview the company, and if it’s a promotion with more authority it will help you handle that extra authority.

If you are in a management role I would also recommend reading this short article about compensating agile teams by Mary Poppendieck as it also has some good advice about team building and destruction which aren’t covered in Peopleware.

Other reviews of Peopleware:
Joel On Software
Coding Horror
Cool Tools

Reviews Book Reviews

I intend for this blog to be a space to chronicle my learning and advancement as a developer. I will post interesting code I have written and found, post reviews of books about software development and related concepts, and write about other software related subjects I think need attention.

Uncategorized