Among some of the more interesting feedback were some requests for some links and an overview of the things mentioned in my talk.

Slides

I’ve put them up on Slideshare though without the context of the talk they might not be much use. I used the Bangers font from Google web fonts and the tech light palette from colourlovers.

Talking points

Standards

I made the point that standards are important for putting the focus on the logic of the code rather than its layout. However, not to worry too much about what the standards are, so long as they are consistent.

If I have to put standards into place I will generally point to the canonical standard for that language such as the C# Coding Conventions on MSDN though if there is a tool that can automate compliance such as StyleCop I will favour that as it settles all arguments.

Code reviews

I believe peer code review to be one of the most effective ways of sharing knowledge and improving the quality of a code base. Pairing comes close but I see that as more beneficial in that it gets two heads together to solve a problem. Code reviews have the benefit of the reviewer coming in cold with little context. This helps them identify inconsistencies a pair will also think of as obvious and flaws that a pair will have helped create.

I’ve used pieces of paper, email, and bug trackers for code reviews but I would recommend the ability to annotate the code inline that you get with Github or the open source Review Board. The additional context to the comments given make them much more effective and removes ambiguity over what is being discussed.

Business analysis

Ah, the difficult practice of listening and understand something completely foreign to you. The art of knowing what question to ask and when. The practice is made much more apparent when you are talking to someone non-technical but should extend to how you discuss topics with your technical peers.

I’ve never found a shortcut for this one and no resources are coming to mind. I think this is one of those skills that takes time, practice, and of course failure, to get better at. You can observe someone who is good at it and that will give you pointers but putting it in to practice is a different kettle of fish.

Learn constantly

No-one else cares about your career and improvement as much as you do. Often companies will support you in your efforts by buying books and so on but you need to be the one pushing for it.

It doesn’t take masses of effort, a couple of hours a week will get you through most technical books in a month or two. However, be sure to maximise your return on investment. By that I mean don’t read books where you’ll know 90% of the content. Pick a book on a new subject, particularly one that will give you tools you can use every day over one about development in the language you use each day.

Books that fall into this category for me:

• Patterns of Enterprise Application Architecture
  • a more practical, hands-on version of the Gang Of Four
• Peopleware
  • a great primer on managing people and teams
• Driving Technical Change
  • learn how to put your ideas into action more effectively

Learn new languages

If you want to invest the time in learning a new language, again maximise your return by learning a different style of language. You won’t learn much from Java that you don’t know from C#. Instead pick a different class of language: a dynamic one such as Python, Ruby, or Javascript, a functional one like F#, or Haskell, or something in between like Scala or Erlang.

You’ll find you’ll become a better better programmer in your original language as it will give you a different perspective on problems. Hell, you could hit a problem and say “Erlang is the perfect language to solve this” and end up writing an application in that language.

Testing

Testing is all about increasing confidence in a codebase. The difference between believing something works and knowing is massive. Automated testing is about reducing feedback loops from the point of code being written to knowing it works.

The smaller the feedback loop, the faster you can go as the easier problems become to solve. If you’ve changed one line of code since you last knew it worked you can be pretty sure that one line of code is where the problem is.

If it’s been two months since you threw that code over the wall to the test team you’re going to have a hard time knowing where the problem is and you won’t have the knowledge required at the very front of your mind any more.

Automation

Once you have automated tests it seems a shame to not have them run regularly one check-in. It then seems a shame to not automate the deployment of that code to a staging environment. Once you’re there it should be pretty easy to deploy to production so you may as well do that as well. This again reduces the feedback loop from developer machine to production, generally reducing the amount that is released at once helping your narrow down the problem space when issues arise.

The question isn’t “why should I automate that?” it’s “why shouldn’t I automate that?”.

Know when to move

Sometimes it’s not possible for you to achieve all that you want at your current company. It’s a shame but you need to recognise it and make a decision whether you need to move company to avoid the glass ceiling you’re under. However, have a conversation with your current company first to see if they can help you achieve what you want. It’s always worth asking.

Know what you want

If you decide to move companies, make sure you know what you are looking for. Interview your interviewers as to what they can offer you, the commitment of a new job is two-way after all. Push them on the points that really matter to you. If you’ve ever interviewed anyone before and found their CV is an exaggeration of the truth, don’t think a company’s job description is any different.

A new job is a commitment for a year or more of your life, do whatever is needed to find out whether you’re committing yourself to the right company.

New jobs are scary

I made the point that joining a new company is always a bit of a scary time. Will you fit in? Will you find out you’re a fraud? Was everything you were told in your interview true? Will I achieve what I want?

Rather than trying to ignore it, embrace the fear and channel it into positive action.

Leverage experience

Particularly when joining a new company leave your assumptions at the door. Just because something was accepted as the right way at your previous company or companies doesn’t mean it has or will be accepted here. Similarly what you think of as common knowledge may be completely foreign.

Introduce useful tools and practices. Send around links that “everyone must have read already”. At worst you’re going to end up with strong agreement, at best you can make a real positive difference to the company.

Prove yourself

The first thing you need to prove yourself to is yourself. That will give you self-confidence which will help you win everyone else over. Focus on yourself and everything else will sort itself out.

Be assertive

If you have an opinion and the forum is right for it, make it known. Just be careful to not go overboard and shout down any conflicting opinions. Remember the skill of listening.

Document everything

When developing code you have this mass of knowledge in your head about how the code you are writing works. Document that knowledge before you forget it. The next time you return to the code you’ll read that documentation and you’ll be able to load the knowledge required to make the change much quicker.

The only argument I hear against this is that stale documentation is worse than no documentation. That’s right but it’s the same as badly maintained tests being less than useful. Should I worry that test is failing or is it just out of date?

Add reviews of the documentation to your code reviews. If the code changed did the documentation change? Does the documentation still reflect the implementation? Again, the act of someone coming in cold to review the code helps here. If they read the documentation first it is much easier for them to pick out inconsistencies than the person who made the change.

Preconditions

Preconditions are the simplest form of code contracts, but to me the most effective. They can be easily implemented in any language and enforce the concept of fail-fast. The deeper you go into a code-base the more they help eliminate code as you can rely on assumptions that must have been verified further up the stack.

Without such enforcement you often end up with large amounts of “null checking” code at the very point you want the most clarity.

It also lends itself to more useful error messages. Your preconditions should always come with descriptive messages so that when they are triggered in development they can be resolved as quickly as possible.

Logging

Logging in its various forms is the only way you can peek into the guts of a production system. You can’t just attach a debugger or write a unit test on a live production system. All you have are your logs.

The habit use it to avoid using the debugger in development if at all possible. The urge to hit the debugger to check the state of a variable is a smell that I’m missing a log statement. It might be that it’s a debug one that will be disabled in production but if it’s there you can enable it if needed.

Also, as systems become more distributed, aggregating your logs through the use of tools such as Logstash is a great way to get a “whole world” view. If you aren’t logging then this isn’t possible.

Experiment

If you’re introducing or doing something for the third time, try something a little different. The first time would have been a learning experience, the second would have proved the first time wasn’t a fluke. The third time you should experiment a little to see if you can find a way that’s even better. At worst it will be no better and you can easily fall back to what you know, but you could discover something that’s massively better.

Stages of learning

I mentioned the Dreyfus model of skill acquisition and my preferred moniker of Shuhari.

Teaching other people is fun but you’ve got to let them stub their toes a little so they experience at least a little of the pain that make your best practices understandable. The journey is as important as the destination when learning new skills.

Goals

If there was one thing that I would highlight over all others that has made me the developer I am today it would be goals. Ones I’ve set myself, not those given to me in my annual company review that are forgotten until two weeks before the next one. Having these goals helped me focus my personal development and make the day-to-day decision that compound upon one another.

Wrapping up

Those were the points covered in my talk. There’s about 10 practices and 9 opinions in there.

A few people mentioned my nerves and yes, I am well aware of them but I thought I got them under control after the first 5 minutes or so. This was around my fifth talk ever and I reckon I doubled the number of people I’d ever spoke in front of in that one hour. If you thought I was nervous in that one you should have seen the other four. It’s a scary experience but it’s also something I want to be good at so I’m going to keep doing it.