Book: Code Leader

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

I'm always fascinated by the difference between average developers, and good developers. Therefore any book that helps explain how to go "to the next level" is going to capture my interest. Patrick Cauldwell's Code Leader: Using People, Tools, and Processes to Build Successful Software does. With a forward by Scott Hanselman, the book lives up to the hype. Patrick sees the big picture, and leverages his experience to explain a dozen concepts used by good developers - the ones who other developers look to as leaders (hence the title). I'm paraphrasing his chapter titles:

1. Buying vs. Building
2. Test-Driven Development
   1. "writing fewer lines of code should never be considered a design goal."  (13)
3. Continuous Integration
   1. "and developer time is always more expensive than hardware" (25)
   2. He emphasizes that while many projects are tempted to offload their build scripts to a junior dev (to free up the senior devs to do something "important"), it's really in the projects best interest to have your best talent create the build process as that immeasurably benefits every aspect of the project.
   3. "Nobody can check in changes at 5:00 p.m. on Friday before going on vacation." (39)
4. When is it done?
   1. "Nothing paralyzes a team faster than trying to reach consensus on every design point." (45)
5. Testing
   1. "Testing is perceived as less 'fun' than writing 'real' code." (57)
   2. "A clean build server is a happy build server." (89)
   3. "One of the most important parts of your strategy should be to demonstrate progress as early as possible." (97)
6. Source Control
   1. I love this: about source control, he mentioned that some are free - "(free as in puppy, not free as in beer)" (112)
7. Static Analysis
   1. He mentions several tools: NDepend, FxCop, Simian
8. Contracts and Interfaces
9. How to limit dependencies - an emphasis on Dependency Injection and Inversion of Control
10. Model-View-Presenter (MVP)
11. and more...

Overall, a very good book. It's filled with tools and practical examples. I think that every dev lead should be familiar with the topics that he discusses.

The problem with "would you bet your job on that?"

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

Here's a story:

Bob the developer is plugging away on his feature. He's made a detailed estimate. Bob's manager, Monty, asks for the estimate. "I expect 4 weeks," Bob answers, explaining the reasons for the proposed schedule. Bob is a developer, he just wants to dutifully get the project done, and he knows that the boss wants it done yesterday.

Monty is one of those managers who can squeeze the most from his employees, so he pushes back (half jokingly) with "Really, are you sure? Would you bet your job on that?"

Visibly flustered, Bob squirms in his seat, "Um, ah, I'm not fully sure, I can recheck things..."

"Aha," Monty quietly assures himself, "No developer is going to pull a shoddy estimate past me!"

As everyone leaves, Monty feels puffed up, and Bob feels like he's not worth two cents.

I've actually seen this sort of nonsense happen before (thankfully never at Paylocity). Sure, occasionally there are do-or-die decisions where the company goes under if the wrong action is taken. But the vast majority of the time, it's a hot-shot manager thinking that they're going to show "those developers" who really sees the big picture. After all, the manager is merely asking for a proper estimate (or feature, or technical component, or bug fix, etc...).

 

The problem with this managerial approach is that it's not a fair wager. The developer essentially puts up $100,000 (their job, which may include benefits and multiple year's worth of work), whereas the manager only puts up a nickel. Even if the developer is incredibly confident, it's still not worth the bet.

 

I'm sure somewhere out there, there is a perfect comeback. The best I can think of is (1) leaving that project (with a manager like that, the project is probably doomed anyway), or (2) calling out the manager and remaining confident "No, I'm not betting my job, I'm giving you a detailed estimate. Do you think there's an error in the estimate, or would you like to shrink the feature scope?" That puts the focus back on objective facts, pulls you back to the same side (you're both working together to get the project done), shows the manager that you're above silly games, and avoids an ego match.

Technical things that devs do besides coding

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

As Paul Glen pointed out in his good book Leading Geeks, while many jobs are based on visible action (i.e. a mechanic on an assembly line), software engineering is largely based on thinking - which is not a visible action. Therefore different rules apply. For example, a software engineer could be working hard, plowing through a complex design in their mind, but it may look like they're just staring off into space. The problem is when those software engineers have non-technical managers who don't understand this, and instead expect their developers, like any other type of good employee, to constantly be "working", by which the manager means "moving", by which they ultimately mean "typing keystrokes for new, production features".

 

But this is silly. Your best developers are rarely your fastest type-writers. The problem is that there are so many value-added tasks beyond just typing keystrokes:

• Learning

  • Researching new technologies and techniques

  • Learning a tool or DSL that helps you write better code in the future

  • Mentoring others

• People and Communication

  • Holding meetings

  • Documenting (like updating the team wiki)

• Non-production coding

  • Writing unit tests

  • Refactoring

  • Fixing bugs

  • Making reusable utilities and architectural components

Point is that an honest, value-adding developer could sometimes spend the whole day barely touching "new feature" code, yet still contribute tons of value to the project. My concern is that many developers seem apologetic for this, almost like "Gee boss, sorry, I had a slow day today, I'll work extra hard tomorrow to make up for it" You didn't have a slow day, you were just plowing through the unappreciated, yet necessary part of the project. It's much like building the car engine - you don't directly see the engine, but the car won't run without it. Just like it's a "first class" task for a mechanic to fix the car's engine, it's also a first class task for developers to do things besides typing keystrokes for immediately visible features.

The need and benefit of mentoring

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

Most software applications today are just too big for a single person to handle, therefore projects are built by teams of people. Often these teams have junior members, and therefore it's essential to help these junior members learn and grow - i.e. they need to be mentored. Now sometimes it's an "emergency project", and there simply isn't time to mentor someone, but this is a dead-end approach. The successful, on-going projects are constantly mentoring the junior guys so that they have an every-growing pool of capable developers.

 

The beauty is that if you've got an eager dev, and you spend a few hours training them on a task or technique, then they can handle that technique going forward. This frees you up from that type of task, and lets you focus on higher level problems. In one sense, if you're to "move up", you need to ensure that the current class of problems you have are handled. You have a few options here:

1. Work lots of overtime, so that you're handling both your old problems, and the new one's you'll encounter at the new position. This approach isn't sustainable.

2. Make those problems go away, usually by solving them properly and simplifying the maintenance with automation. This is a good temporary solution, but ultimately the automation breaks, or the process itself needs to be modified, and then you get blindsided at the most inconvenient time.

3. Mentor someone else to take over your automated process. This is ideal. It involved other people on the team, and encourages that newly-mentored developer to understand and improve the process you original set in motion.

I personally find a good way to mentor people (and be mentored myself) is to emphasize the skills that they like and are practical to them, initially work with them one on one, then let them toy around with it on their own, then connect them with another person who can answer questions (your "backup"), while always keeping your door open to questions.

 

I've seen many senior devs, with good intentions, declare that they're "too busy to mentor people right now". Sometimes this is because the company only rewards immediate coded features, as opposed to long-term team growth, and a dev isn't jumping to do what they won't get rewarded for. Other times it is because the dev just doesn't know about mentoring - no one mentored them and they "toughed it out" the "old fashioned way". Still, other times it's because the senior dev is, to put it politely, being short-sited. As the saying goes: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life."

 

If you spend 4 hours ("but that's half a day!") mentoring a junior dev on how to fix security hacking issues, or use the new validation framework, and they then do those tasks for the next year, which saves you even 2 hours a week  - you've just been spared 100 hours. So, there are many benefits to mentoring:

• An hour of mentoring could easily give you 20 hours back - now that's a good return.

• There's a great feeling in helping others.

• Perhaps someday that junior dev will learn a technology that's new to you, and they'll return the favor.

• Teaching something to some else truly forces you to understand it yourself.

• It helps build a closer team.

I think because of all this, the best companies will always be actively mentoring each other.

Does your team culture encourage learning?

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

In the ever-growing field of software engineering, continually learning is essential. While a lot of developers internally have the drive, they're stuck in a team that externally makes it difficult to learn. Here is a checklist of simple questions to gage how much a team encourages learning.

• Spending money

  • Will managers buy a technical book without giving the developer a hassle? For management to spend $30 on a book, for which a developer then spends dozens of personal hours digesting and learning a whole new skill, is an incredible rate of return. If management is too short-sighted for that ("aw, can't you get it online", "did you check your local library first", "the project budget can't afford that", etc...), then your team is toast. Of course a developer could abuse this by requesting to fill an entire book shelf, so common sense applies. A book is month is very reasonable.

  • Will management provide adequate resources to explore a new task? For example, if you're investigating continual integration, you will need a spare build server.

• Encouraging team collaboration

  • Can your team set up a wiki such that everyone can easily share trivia and knowledge?

  • Are code reviews encouraged by all the managers and influential contributors?

  • Do senior team members actively mentor junior members, or are developers too busy pounding out features to "waste" on mentoring?

• Scheduling

  • Do most features allot at least some time for research and improvement - even 5-10%? That means if you spend a whole week plugging away at a feature, management is okay if you take at least a few hours to explore a tangent, or incrementally improve the system?

  • Microsoft, as well as many user groups, occasionally sponsor free local events. Management may not pay thousands to send you to fancy training, but will they at least let you occasionally take the day to attend a free training session?

• Process

  • Do your processes display public results, and are those processes documented, such that anyone on the team can investigate and understand them? Or, are the processes cautiously guarded by some "builder master" guru or manager who doesn't want anyone else to see the big picture for fear that it would somehow "threaten" them?

• Features

  • Are the interesting features shared across the team, such that everyone gets a chance to explore cool technologies, or does the architect/team-lead hog the cool features for themselves and leave the boring work to others?

  • When your team needs a research project, is it assigned internally so that your own guys get the opportunity to learn about it, or is it sold off to some external consultants, or is research forbidden altogether ("we don't have time/money to learn to do things  better")?

• Management

  • Development requires innovation, which requires risk, which inevitably results in the occasional "failure". Does management allow developers to take a calculated risk (i.e. not belittling or embarrassing the developer when it doesn't work out)? If not, developers will be afraid to innovate, which means they're be afraid to apply what they've learned, which will reduce their incentive to learn new things.

  • Will management emphasize the total cost of ownership, which ultimately can only be reduced by continual education of the entire team? If managers only emphasize the current task ("we don't have time to do it right, we need to get this feature coded now."), and learning (even if it's for the current task) means you're not actually programming (i.e. "typing in keystrokes") at that moment, then managers will discourage developers from learning. In other words, is learning seen as a first-class task?

  • Does your promotion system emphasize career goals, which in turn emphasize some learning goal?

These things do not necessarily imply a good or bad learning environment:

• Sending developers to expensive training - Back during the .com bubble, there was plenty of cash to send anyone to training. However, as mentioned above, there are still plenty of ways for a company to encourage learning without sending the developer to a fancy training session.

• Asking you to handle an occasional boring task - Ultimately any engineering project will have something tedious and boring that needs to be done. This doesn't mean that the team is anti-learning. However, if every task is boring and hacked, then that's an obviously bad sign.

• Emailing links to "best practice" articles - Any kid can email links to coding guidelines or best practices that someone else wrote, and for which it requires the discipline of other developers to actually adhere to. There's nothing brave or helpful about yet another checklist.

Why play games instead of writing them?

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

I've met a lot of younger kids who say they like computers, by which they mean they "like playing computer games." I've seen these kids learn just enough about networking and hardware to get their favorite game installed, and then rot their brain with thousands of hours of un-educational video games.

 

Sure, a little game playing to relax and recharge is one thing. But throwing away the formative years of your career - i.e. high school, college, and post-college - is a sad thing to do.

 

It doesn't need to be this way. Programming can be fun, perhaps as fun (or even more!) than playing a computer game. The idea is that if writing a fun program (which has a huge learning benefit) is about as enjoyable as playing a deadbeat game (with no learning benefit), then obviously it's better to budget your time for more programming.

 

So, why is solving the nth level of Game XYZ fun, but solving how to code an algorithm or UI screen not? Let's look at several reasons, and see how programming could fulfill the same fun criteria.

 

Why game-playing is fun?	How programming can achieve the same result
The game is relaxing and takes less mental energy.	You can pick an easy, relaxing project.
The game offers you new and exciting things to explore (new level, creature, technique, etc...).	There's always new things to learn while programming, and these new things usually provide you with a marketable skill.
You can stop the game at any time.	You can take a break from your pet project at any time.
The game consumes your mind, and sucks you into its world.	Ditto.
You can play with your friends.	You can build an open-source project with your friends (such as using shared space on CodePlex), or share your new app with friends or coworkers.
You cannot lose at the game (provided you have the sufficient cheat codes).	Ok, so your program may crash and fail, but you can usually find help (such as on a forum or from a coworker), or reduce the feature scope.

 

My point is that many of the things that make game-playing fun also can make programming fun. And unlike game-playing, programming offers you tons of long-term benefits.

Book: Bringing Out the Best in People

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

Arguably the most critical component of a software application are the people who build it. If the team doesn't get along, or lacks the drive to learn new things, then the team will eventually fall apart, and the project will come tumbling down shortly thereafter. Therefore while technical books are important, "people" books are important too. With that in mind, I just finished reading "Bringing Out the Best in People" by Alan Loy McGinnis. It was a good, easy read. He wrote it in the mid 80's, but as human nature hasn't changed much since then, it's still very relevant.

 

He offers 12 main points, including:

• "Expect the best from people you lead" -  I interpreted this as giving people the benefit of the doubt, and encouraging them to tackle difficult problems that bring out their best talents.

• "Create an environment where failure is not fatal" - I've seen many ex-consultants who are terrified of failure. "One wrong mistake on this project, and I get replaced with a new contractor, so I better not screw anything up". Such fear paralyzes any normal person because you can't take any risk. But software is an innovative field, and innovation requires risk. Therefore having the schedule allow for some flexibility and giving people second chances are good things.

• "Place a premium on collaboration" - Some management structures over-emphasize "the star". Who single-handedly wrote the most code? Who fixed the most bugs? Who built the toughest features? The problem with over-emphasizing the individual (at the expense of the team) is that it often pits the individual members against each other. Then you get team members quietly asking themselves dangerous questions like "Why should I fix your bug." Think of basketball - yes there are stars, but the coach just wants to win the game - the coach doesn't care who the star is.

There's a lot to discuss about it. In short, it's nice to balance all the technical reading with a "people" book.