Keeping Your Developers Up On Internal Practices

Question

How do you guys manage keeping your dev resources in tuned with the latest patterns for an application. Example, somewhere on how to handle exception handling, dependency injection, model binding complex objects, etc.

Do you use a big Practices doc? Or maybe you use an inhouse wiki. Maybe you have daily meetings for dev leads to preach. I'd like to see the options...

I'm not really looking for a generic standards guide (so many spaces for an indent, camel casing variable names) or a PnP site link. I'm looking for a way to better communicate internal practices. Thanks!

Answer 1

I've found an internal wiki to be a very valuable resource. If you have one available it can be the first place to go for developers to figure out the current best practice.

That said, you need to have a team willing to use the wiki as well. It may be useful to have a regular developer meeting to go over any new patterns, libraries, best practices etc that were created or started within the last month or two. If you back that up by documenting it on the wiki, then everyone is aware that these things exist and they have a place to go to reference it.

Best practices docs get very easily out of date in my opinion. People tend to treat them as written in stone. Wiki's lend themselves to being updated frequently.

The most important thing is to make sure your team is on board with how to use the resource you choose. If people don't use it/update it then it won't be valuable for long.

Answer 2

We maintain a coding standards wiki, but on top of that, and we have a "feature check-in checklist" that lists everything developers need to do before committing a major piece of code.

Any updates to standards are generally communicated to the development teams both in our standup meetings and via email.

The hard documentation allows new developers a good reference and speeds up the onboarding process, and the double communication of changes to our standards means that developers have no excuse to not follow them.

Answer 3

The best way to ensure that standards are being met -- as opposed to publishing standards that get ignored -- is to have code reviews.

If a particular piece of code doesn't meet the existing standards, it can be updated. More important, a group of programmers sitting together can think about how a particular problem should be solved, including the use of an appropriate pattern.

Answer 4

In my experience nothing spreads idioms and practices around an organisation faster than pair programming. Pairs see each other using idioms and pick up on it organically. No other method even comes close in terms of speed and painlessness.

Answer 5

We maintain casual list of "coding standards" that have been agreed on by all devs; there's always an open line of communication for anyone to nominate a new standard.

The wiki is good, especially for explaining internal portions of our apps. But the problem is that it isn't utilized much.

Intentional and open communication between devs about best-practices and keeping the environment open to healthy peer critique has been the biggest "sharpener" for our team.

Answer 6

Internal wikis can be good for sharing information, but I have found that they are not particularly useful in a workplace because people still tend to be in the mindset, "If it's not actually my job, I'm not going to worry about it." This leads to a lot of "wiki rot." Also, there are a number of resources on the web that better cover these topics than could be done internally.

What I have found useful is in-house "tech" meetings. Once a week, we pick a topic that everybody is interested in, and have an individual present on that topic in sort of an open-forum mindset. This is good because it allows individuals to practice presenting, it shares information, and it lets the group chat and understand new ideas in relation to in-house projects. If a topic is particularly "hot," we'll have further discussion in following weeks.

With all this said, there is no substitute for developers taking time to learn on their own and for individuals training each other and talking about ideas as a team during the normal course of everyday work.

Answer 7

I do two thins. First, I encourage my Devs to attend the monthly .net developer user group meeting. We get some great speakers and good topics and I feel it benefits me as a professional developer as well as my team. You can check INETA to see if there is a group near you.

Second, my team follows the Scrum process and the Sprint Retrospective is a key part of that process that you should not overlook. This event in the Scrum cycle is the perfect time to bring up new ideas that the team can then choose to adopt or not.

Answer 8

Apart from the various suggestions that has been mentioned here, we use some open source tools that measure if we have regressed from code quality. For example, in some of the Java projects that I have worked on - we have used tools like PMD, Findbugs etc., While by in itself, this may not be enough - but when combined with other processes like code reviews, JUnit coverage, this should give you a better sense of code quality.

Answer 9

Print out some A4-sized posters illustrating some 'best practice' and stick them on the inside of toilet cubicle doors. That way, your engineers have something productive to read during their most unproductive of times.

At least one large corporation does this for their employees.

(Hint: Begins with a G).

Answer 10

While code reviews, documentation and presentations are helpful, organizational culture, politics and budget constraints can have a very serious impact on the effectiveness of these practices.

I've found that the "free market" approach works best: implementing a standard set of libraries and project templates that make the right thing the easy thing. Its less confrontational, requires lss effort to keep employees in compliance and factors in the ubiquitous personality flaw found in almost everyone: laziness.