Improving the Developer Culture at Your Workplace

Here are some of the things we do here at BancVue to help keep our developer culture healthy and strong. They are things you can do to improve the developer culture at your work. Many of these things can be started by anyone at the company, though a few may require management approval or financial support. However someone needs to lead the charge. If you want to change the culture, it has to start with you.

Start a Developer Book Club – Here at BancVue, we have a developer’s book club that meets each Wednesday over lunch. The group decides what book they want to read, and then takes it a chapter (or sometimes a section) or so each week. We discuss what we have read and learn from one another to help keep our skills sharp.

Hold Weekly Dev-Shares (Knowledge Shares) – Each week we have a different developer share something they have learned, something they have worked on, or some other presentation that would benefit the other developers. Its a great way to spread knowledge or promote new technologies. We identify topics the developers as a whole need to know and ensure those topics are discussed. However, most of the time it is whatever the presenting developers choose to present. Its a great forum to show ways other developers have found to make your work easier. Its been used to discuss company tools or how to overcome common problems in the codebase or toolset. It helps increase the collective knowledge of the teams.

Get Safari Subscriptions – BancVue provides several subscriptions to Safari Books Online that the developers have access to. This is a great resource for the developers to learn from. Several members of the book club use it to read the books. I have used it on many occasions to learn more about technologies relevant to whatever project I am working on.

Start a Developer Library – I personally bring up several of my development books and have them at my desk for any developer who wants to read them. I have seen places that sponsor a company library that is stocked with current books to help developers learn.

Practice Pair Programming – If you aren’t doing pair programming, you are really missing out on a learning opportunity. Pairing is a great way to transfer knowledge. Each developer has their own bag of tips and tricks they have learned over the years. Paring allows the whole team to leverage this knowledge.  This is also true of domain knowledge. A great way to grow a junior developer is to pair them with a senior. Even the senior devs will benefit. I have learned A LOT through pairing, even from devs that are many years my junior.

Start Mentoring – Another way to really help developers grow is to assign them a mentor. Ideally each developer is both being mentored, and mentoring others. Senior devs mentor mid-level devs, who mentor junior devs. Senior devs can be mentored by other senior devs who have more experience, etc. Regardless of whether this is done formally or not, encourage the developers to take on an attitude of mentorship.  Everyone should be continuously learning from each other.

Ask for a Training Budget – Ask management to encourage outside training by providing funding for it. BancVue has a budget for training that can be used for conferences, online training or other courses. Some good examples would be attending JP Boodhoo’s Nothin but .NET course, or Udi Dahan’s SOA course, etc.

Use Screencasting – At BancVue, we screencast our dev shares. This way anyone who missed can still see it, plus, as we bring new employees on, they can benefit from them as well. We also have used them for training on company tools and walkthroughs of common tasks. A good example would be a screencast on how to set up a developer’s box.

Get Training Videos – There are many video training resources available. Some are free, and some are for purchase. There are many great free videos out there. The purchased ones, however, often cover the topic in much more detail, but this is not always the case. Get videos that cover the technologies you are using, or the techniques the team needs to learn. Make them available to all the developers on a drive share or wiki. Make sure you watch the videos (or a sample of them) before making them available. You want to make sure they aren’t a waste everyone’s time. Some good sources for videos are:

  • Free
    • – A great site with short 10-minute videos on all types of development topics. The length is perfect for the ADD-impaired (like myself).
    • Virtual Alt.Net – This site holds a collection of virtual meetings/screencasts on various topics. Check out the “Recordings” tab.
    • InfoQ – This is far more than videos. It constantly has great new content. I suggest subscribing to their newsletter, which is just a concise set of links to all their new content.
  • Paid

Broadcast Useful Resources – When you learn of upcoming user group meetings or training opportunities, let all the developers know. I do this often. When the Austin Code Camp comes around each year, I personally invite every developer to come. When I find a great link that I know others would be interested in, forward it to them. I am always trying to make resources available to those who could use them.

Start a Blog – Starting a blog is not only a good way to learn technology yourself, its a great way to teach others what you are learning. If you want to lead others in your company how to use a particular method or tool, what better way than to write up a blog post and refer them to it. You will not only help the developers you work with, but you will be contributing to the developer community at large. I can’t count how many times I have directed others to my blog for something they have questions about.

Give a Presentation at a Local User Group – Find a topic you are passionate about, and give a talk on it. It’s a great way to get people to come to the user group who may not otherwise come. They may come just because its you. It also encourages other developers to start doing the same. They see that you don’t have to be a genius to do these things. It ups their confidence. Not only that, but in doing so, you will learn a lot. The saying is true, “If you want to learn something really well, teach it.”

Keep up with Twitter – To get a lot of resources and stay current, follow leading developers on twitter. The resources you can get from there are great. I find myself relying more on twitter and less on my RSS feeds for current information these days.

Read Books – This will help you stay current and keep your skills sharp. Aside from the obvious benefits to yourself, this also lets you determine what books you may want to suggest to others, or to the book club.

Well, that’s a lot of tips. The bottom line is, the change starts with you. I encourage you to implement some (or all) of these tips. Not only will you grow to be a better developer, but so will everyone around you. You will be a blessing to your company and your team, and create a better place to work in the process. Go for it!


Posted in Continuous Learning, Leading, Mentoring | Tagged , , , | Leave a comment

Be a Mentor, Not a Critic

This quote was posted on twitter last week and really stuck with me, "Be a mentor, not a critic." I don’t remember who posted it, but it really made me think about my attitude at work.

I like to think of myself as a mentor. I try to help others become better developers. I make it my mission at work to teach and instruct every chance I can. When I do so, however, I can often be critical. I can easily resort to tearing people down by criticizing their code rather than building them up by encouraging them and teaching them. There is a huge difference between the two, and I need to constantly remind myself of this.

It makes me think of how Jesus could hang out with prostitutes and sinners, yet still be a mentor and guide for them. He demonstrated what was right by his life, and told them what was right in his speech, but he never pointed the finger at them. These people wanted to be with him, even though his life and teaching showed them that their lives were wrong. He was a positive influence on them, without being directly critical of them. He told them the truth when necessary, but did so with love.

So I have to ask myself, am I building people up, or tearing them down? And I ask you the same question. I challenge you to make it a priority to join with me and set the criticism aside. Be a positive influence on those around you. Teach others what you know, and learn from others what you do not.

Be a mentor, not a critic.


Posted in Leading, Mentoring, Soft Skills | Tagged , , | Leave a comment

Antipattern: The Bloated Configuration File

Configuration files should contain only the values the end users will need to configure. Everything else should be in code.

One problem with WCF is the size of the configuration files. They contain so much data they are unreadable. Its such a problem that Microsoft provides the WCF Configuration Editor to ease developers pain when editing them.

This is even more of an issue when users need to edit them. I have user-editable configuration settings in my app.config, but since the  WCF settings also reside in that file there is a risk that users will accidentally change them and cause failure. Not good.

WCF is a good example of a bloated config file, but the problem is not isolated to WCF. Anytime a config file contains non-configurable concerns, it is bloated.

You see, a bloated config file contains 2 types of data:

  1. User-editable configuration settings
  2. Static application configuration (should never change…in my case, this is WCF binding configuration).

This violates SRP. Yes, I know, the Single Responsibility Principle applies to objects/classes, but it often applies beyond that scope as well.  In this case it applies at the file-level. A config file should have one and only one responsibility: user-configurable settings. Anything beyond that introduces confusion and increases risk when editing the file. If the users should never edit the WCF bindings, keep them out of the config file.

So how do we fix it? Configure the WCF bindings in code rather than the config file. Expose only the WCF settings the users should modify as settings in the config file (endpoint addresses, timeouts, etc). Express everything else in code or in another file, safely out of reach. The result is clean config files that users can understand and edit without the fear of changing something they shouldn’t.


Posted in .NET, Configuration, Principles | Tagged , , | Leave a comment

Entities, Services & Resources—Three Categories of Objects

After working with domains for several years I find that there are three major categories of objects I work with: Entities, Services, and Resources. There are clear distinctions between these categories in their purpose, content, dependencies and roles. Understanding these categories clarifies what dependencies I should allow, what purpose the objects serve, and how I should test them.

Purpose / Content

Entities are the domain objects. They model the data that gets persisted to the database. These objects are mostly data, and have little behavior.

Services are the workhorses of the application. They perform the majority of the business logic. These objects have little to no state, and are almost pure behavior.

Resources are the objects that interface with outside dependencies like the file system, database, etc. These objects only have the business logic necessary to interface with these outside dependencies. They are used to decouple the application from the dependency itself. A good example of a resource is a repository—which serves as the source for entities.


Entities only have dependencies on other entities through relationships, such as, an order having line items. An entity should never depend on services or resources.

Services can depend on anything. Services require dependencies on other services or resources to perform complex tasks—per the Single Responsibility Principle.

Resources generally only depend on the underlying subsystems they are encapsulating. Resources don’t depend upon other services, but may depend upon other resources.


Entities require the least amount of testing. They are mostly data and have simple behavior—there is little to test. But entities are used heavily in testing other objects. The serve as input and expected values when testing services and resources. Because there is so little behavior, it is easiest to use entities directly in the tests rather than mock them. (This is where frameworks like Fluency come into play to help create these objects in a state containing valid anonymous data. What mocking is to Services and Resources, Fluency is to Entities.)

Services require a great deal of testing since they are mostly behavior. Unit testing them requires mocking any other services or resource they depend on. Any entities needed to test them are created and used directly.

Resources cannot be covered in unit tests. Because they interact with underlying systems (disk, database, network, etc), any test against them is, by nature, an integration test. Resources are always mocked when unit testing other objects since they represent dependencies that we want to decouple our tests from.


Entities are the core of the Domain Model. They represent the business domain directly.

Services can be part of the domain model or a part of the infrastructure model depending on the behavior they are supporting. For instance, a notification service would be an infrastructure concern while a loan calculation service would be a business domain concern.

Resources are always part of the infrastructure for obvious reasons.


Are there any other observations you can make about these three types of objects that can help us in our thinking? If so, please add your comments. I would love to hear them.


Posted in Design, Mocking, Patterns, Principles, Testing | Tagged , , , , | Leave a comment

Fighting Perfectionism—What Is Good Enough?

Perfectionism is a disability deceptively disguised as technical proficiency. It is adds risk to a project while deceiving the developer to believe they are doing the right thing. Where do you draw the line and stop refactoring knowing the code is good enough?

Perfectionism is something I have struggled with for a long time. I often feel dissatisfied with my code because the code is not “just right”. Time and time again I have found myself up against deadlines trying to clean up code that I should have left alone. It is something I have resolved to overcome, and if you suffer from this handicap, I urge you to do the same.

So what is good enough?  How do I know when to stop?

This is a hard question to answer. To get started, we need to know what good software is. I would propose that good software is software that works,  is understandable, maintainable and usable. Given this, the question can be rephrased as four smaller questions:

  • Does it work well enough?
  • Is it understandable enough?
  • Is it maintainable enough?
  • Is it usable enough?

Answering these questions should give us a good understanding of what is good enough, and perhaps help us overcome our perfection fetish.

Does it work well enough?

This is a question of requirements. Does the software meet the requirements? Is it stable? Does it meet the defined SLAs? If the answer is to any of these questions is no, then the software is not good enough. If the answer is yes, then we can move on.

Is it understandable enough?

Is the code clear? Can other developers read and make sense of it? Could they pick up development on it if you were hit by a truck?

Is it maintainable enough?

This is where I always get trapped. Can you reasonably modify the code to handle unforseen requirements changes? Is it flexible where the business rules are flexible? If not, can it easily be refactored to be flexible? I have trouble deciding what refactorings to do now, and which to save for later if we need them.

I am often afraid of painting myself into a corner—its a fear of being unable to change when necessary. I recently realized that following good agile practices (TDD, etc…) makes it much harder to paint yourself into a corner. Test coverage and good design allow you to easily refactor yourself out of any pinch.

Remembering to embrace change rather than fear it helps me to put off till tomorrow those things that are not necessary for today.

Is it usable enough?

Can the user accomplish the tasks they need to with the software? Can they do so efficiently and without complaint? An application that is not usable is useless. An app that is overdesigned, however, is wasteful and expensive.

A word of caution

I am not advocating that we develop mediocre software with mediocre design. Please realize that this is written to those developers who have a perfectionist bent, who see great software and great design as something that could be must be improved. Their “good enough” is everyone else’s “great”.

In the competitive world of software development and its pressures to deliver, we must strike a balance between quality and cost. The higher the quality of our code, the longer it will take to develop. In this world, the perfectionist will be forever unhappy with their results given the short time they are allotted. They will never be satisfied, that is, until they can overcome their perfectionism.

Fight Perfectionism! Know when to say when. Then move on.


Posted in Agile, Perfectionism, Soft Skills | Tagged , , | Leave a comment