What makes a good software developer?

What makes a good software developer? I've been thinking about this question quite a lot in the past few years, even more so recently since I've been involved in interviewing candidates. 

Many people with much larger brains than myself have written about this, but here's my take. Knowledge and experience are very important. I could make a list of technical skills I think are essential for a job on the team I am currently part of. If someone else were to write a similar list I've no doubt it would be different. This is why I think knowledge and experience definitely play a big part in what makes a good developer but it's a good attitude that is key. 

What constitutes a good attitude? Here are a few things that I believe are important:

• Enjoyment - You must enjoy creating software. This is absolutely fundamental. It's impossible to be good at something you don't enjoy 
• Learning/self improvement - I'm not saying you need to spend hours reading books or creating software in your own time, although that will get you far, I mean at the very least take time to improve at work. Identify weak skills, learn from more experienced colleagues, read blogs when you have ten minutes spare
• Caring - Please give a crap! Care about writing good code, care about coming up with the best solution possible, don’t settle for the first idea that pops into your head. Care about your team, care about your culture, care about everything!
• Be open to new ideas - Don't reject something simply because it's new, you don't know much about it or it's not the way you’ve always done things
• Take responsibility - Don't just complain about problems or leave them for others to fix, take action 
• Simply doing what you've been asked to do is not enough - Typically companies want developers to build features and fix bugs as fast as possible. Unfortunately a codebase is like a car, it needs servicing, regularly, otherwise small problems become big problems. A good developer will identify and fix these problems

Devweek 2014 - Day 3

Already familiar with ASP.NET Web API? You sure? - Ido Flatow

I had no idea Web API was so extensible and configurable. You can change pretty much everything in it’s pipeline; message handlers, filters, parameter binding, formatters and so on. 

Turns out Web API can be cached, but you have to do a bit of manual coding to enable it. Essentially it’s a case of using max-age or expires headers as appropriate. Or, ETag headers can be used to version your cache. I can see this being quite a clever way of caching but it requires more setup.

Culture of review - Austin Bingham

I’m very much sold on the benefits of reviews so much of this talk was familiar. But, saying that, I’d forgotten a few important things.

• Research has been done in this area. All the research mentioned in the talk suggested that code reviews are a effective way of finding code defects
• Taking your time is important. Don't review in a rush
• 200-400 lines of code per review is optimal based on research done at Cisco

Better code through bugs - Seb Rose

The question this talk was trying to address was how do you know you have a high quality test suite? In short, you don’t, there isn’t a reliable way to measure. This is where mutation testing comes in. Mutation testing is a fascinating concept. The framework being demoed, pitest, introduces bugs, called mutants, into your code. There are several different types of mutations. Examples include conditions boundary mutator, which changes conditional operators; increments mutator, which changes increments to decrements and visa versa; math mutator, which changes math operation operators. 

For example, the conditions boundary mutator can change a >= to a >. Once the mutation is made your unit tests are run. If at least one test does NOT fail, you have a problem. It may be that you need another test case or there may be some other issue which needs to be fixed.

It sounds like a really interesting and potentially useful technique, but, there are problems. 

• It can be slow
• You may not be able to achieve 100% pass rate. Some issues cannot be fixed
• There’s no good .NET mutation testing framework

Devweek 2014 - Day 2

How frameworks can kill your projects and patterns to prevent getting killed - Sander Hoogendoorn

This talk wasn’t entirely about bashing frameworks but the speaker was keen to point out numerous problems associated with their usage:

• Cost
• Learning curve
• Convincing management it’s a good idea
• Convincing other developers it’s a good idea
• Finding the right one
• Missing features
• Changes between releases
• Development may be stopped at any time

A further point was that people often think of the frameworks they use as their architecture. This shouldn’t be the case. You should work out the requirements of your architecture and choose frameworks to fit.

Test smells and fragrances - Kevlin Henney

Must of the information in this talk was fairly familiar. Don’t reassert anything that has already been asserted, test only one behaviour in each test, when using the SetUp method ensure tests remain individual, tests should accurately describe the code, that kind of thing.

One very interesting point was made about test naming conventions. Kevlin is particularly keen to make the test names as descriptive as possible. To this end he suggested avoiding using “should” as it’s unnecessary, it doesn't add any useful meaning to the name. Also it’s uncertain, unsure, not definite. There is no “should” in tests, it either passes or fails. The speaker also favoured descriptive names with underscores rather than camel case names because they’re easer to read. I have to agree. 

For example a simple test class was created called Cup. It could be drunk and emptied. Here is an example test case using our current naming convention and the one Kevlin suggests.

Fill_CupIsFilled_IsEmptyReturnsFalse

 A_cup_filled_with_water_is_not_empty

Applied NoSql in .NET - Michael Kennedy

The big take away from this talk is that while I’m convinced NoSQL is an good solution in certain scenarios, you really need to understand your chosen framework before you start.

It turns out MongoDB, the subject of this talk, is not capable of cross document transactions, which could be extremely problematic. Take the following scenario; an application successfully takes payment from a user. Two things must occur now, firstly the details of the payment must be recorded and secondly the user’s balance must be updated. Both of these must occur otherwise your data will be inconsistent. The only way to ensure these two actions are completed as part of the same transaction in MongoDB is to include them in the same document. I.e. The same object. Further explanation here. It occurred to me that you really need to know this before designing your object model.

IIS for developers - Ido Flatow

This talk contained a bunch of useful information about IIS I wasn’t aware of.

• Feature delegation allows you to choose what features can be controlled in your web application’s web.config
• Various useful options exist on app pools
• CPU limiting. E.g. Limit the app pool to 25% of the CPU
• Process orphaning. This allows process to be kept in memory after they have crashed. It is then possible to create a script to save the dmp file to disk. In addition this dmp file can be opened in Visual Studio and you can debug it to find out exactly where it crashed. I had no idea
• Dynamic compression isn’t enabled by default, but is potentially very useful. Ido demonstrated a 1MB JSON file being compressed to around 270KB
• Default IIS logging is rubbish. The IIS advanced logging module is much more useful as it logs more information. IIS 8.5 comes with this as standard
• Log Parser Studio is a great app for parsing IIS logs and other logs

Day 3 >> 

Devweek 2014 - Day 1

This was the first paid conference I have attended so I was expecting big things. By big things I mean lots of free stuff and nice food, oh and some good talks. I didn’t finish the first day empty hearted. There were lots of good talks, two memory sticks of unknown size, two pens and some nice food.

Death by dogma versus assembling agile - Sander Hooendoorn

This guy is a fantastic speaker. Funny, informative and really gets his point across. 

The talk centred on the fact that agile is everywhere nowadays. It’s huge buzz word. Everyone has to be seen to be doing agile, whether they really are or not. With that comes a host of problems, not the least of which is that agile, or in particular Scrum, can be seen as a silver bullet. It’s not. There’s also a lot of people getting certified as Scrum Masters then being thrown into a project, which can lead to a very dogmatic approach. Everything must be done to the letter because that’s what the “certified process” says and Scrum Master doesn’t know another way.

Sander’s main point was that if you take this dogmatic approach to agile, it’s not really agile. In fact it’s the opposite of agile. He suggested you should assemble your own method, find something that works for your team and stick to the basic principles of agile:

• Work iteratively 
• Have small units of work
• Plan continuously
• Deliver early and get feedback
• Simplify communications

Integrity driven development - Roy Osherove

Roy is another absolutely cracking speaker and not a bad singer (the talk ended with a song). Unfortunately I’m finding it difficult to summarise the gist of his talk so I’ll pick out a few interesting points.

One subject which struck a chord with me is was what Roy called survival mode. Essentially this is a team that is overloaded so they are too busy to learn and practice. Obviously this is incredibly bad. It’s bad for the developers because they’re stressed and the work is less gratifying because there’s pressure to cut corners. It’s also bad for the employer because developers will be less happy and so more likely to look elsewhere for employment. Roy suggests a couple of ways to get a team out of survival mode; remove over commitments and increase time estimates to include quality.

Another interesting technique cover was using a decision matrix. Surprise, surprise, this is used to make decisions. In short, you list our options along the top and your values down the side then rate each one between 1 and 5. The option with the highest total is the one your use. Simple.

The final point I want to cover from this talk is this; “great teams are grown, not hired”. I’m not sure I agree 100% but I really like the principle. To me this says focus on building the skills of your current team and be willing to invest time and money. Roy suggested several ways of doing this:

• Challenge your team
• Give them the time to practice
• Include learning time in estimates

Obviously this is easier said than done, but as I said I like the principle.

Introduction to the reactive framework - Richard Blewett

The Reactive Framework (Rx) is all about providing a powerful wrapper around IObservable and IObserver. The interfaces are also fluent, making it very easy to read. Another particularly useful application is to wrap events. Rx provides various extension methods for handling events. 

To be honest, this is a very difficult thing to explain without examples. The talk was essentially one big demo with a few slides thrown in so did a very good job of explaining things. Unfortunately I don’t have those samples so the Rx getting started page is probably a good place to find out more information.

Individuals and interactions over processes and tools - Kevlin Henney

Again this is a talk which is difficult to summarise as a huge amount was covered. Kevlin is one of those speakers who gives the impression they could speak for hours and hours on their chosen subject. So again I’ll pick out a few points that stood out. 

Many of the points made in this talk were along similar lines to the assembling agile keynote. Agile should be flexible. There is no one way to rule them all. It was also pointed out that the idea of being a certified Scrum Master is a little ridiculous. What’s the point of being certified in a process that shouldn’t be defined rigidly?

Estimates are tricky. One figure, for example three weeks, is not sufficient. There is a probability associated with an estimate being correct so it’s better to suggest a time period. E.g. Two to three weeks. Also units should be chosen with care. Fifty two weeks sounds much more precise than one year. If a team member estimated a project would be completed in fifty two weeks, how much time either side would you give them? One week? Two weeks? If they said the project would take a year, it’s sounds much more fuzzy, much more imprecise, so it’s natural to assume there are bigger inaccuracies in the estimate. Perhaps you would allow one or two months leeway. 

Apparently a study has been done about what motivates people. For us knowledge workers the top motivator was not money or recognition, it was progress. Now that is interesting.

Practice programming, what’s the point? Ben Lambert

I’ve been a fan of this idea for a while now. The idea is you practice programming in much the same way as you’d practice a sport, or playing a musical instrument. Why would you do this? To improve your skills, to learn something new, to challenge yourself. This can be done at work, but ideally it’s done in a no pressure situation. Then you can take your time and have fun. But, saying that, Ben pointed out that it is important for your employer to give you the time to practice. To understand something fully you need to take your time, which can be difficult at work.

• What kind of thing can you do to practice programming? Ben gave a few examples:
• Write the same task in different languages
• Solve the same problem in several different ways
• Learn something completely new
• Write a simple game, or anything else you find interesting

Day 2 >>

Software development is difficult

Sometimes I find software development a little depressing. It gets me down, so I thought I'd have a bit of a rant about some of the reasons why.

You're never right and nothing is certain

You're doing it wrong. You're never right. Ever. There's no such thing. Just accept it. Everyone has a different take on what is good and bad practice. Everyone has their own ideas on what works and what doesn't. You will find people who agree with you, but you'll find just as many people who don't. There is no black and white, it's all one gigantic grey area. To make matters worse, I have a computer "science" degree but many people will tell you that software development isn't really a science. Much of what we do is based on very little evidence, a few success stories, the spouting of an enthusiastic evangelist or perhaps some misguided beliefs. All of this means that it's almost impossible to be sure that you're doing it "the right way". It does my head in.

How good am I?

How do you know if you're a good programmer? By what yardstick do you decide? Salary? Fame? What you build? Contribution to open source software? How much you blog? Your Stack Overflow reputation? How many books you've written? The size of your team? The super clever, better than everyone else's, framework you've written? How much public speaking you do? The number of followers you have on Twitter? The quality of your code? That's another debate of course. The number of visitors to your site? How much money you've made? 

Is it important? Probably not. Arguably the most important thing is that you enjoy what you do. Some would suggest that you can't be a good software development unless you enjoy it. I certainly believe that. But is that enough?

Knowledge

You can't know everything. You can't even know a little. The breadth of knowledge required for software development is immense, the total amount of things you can learn is ridiculous. But what should you learn? The skills required to do your job obviously. But how about the things you think would be useful, or the latest framework/tool that people are raving about, or maybe just something you're interested in. Don't forget staying up to date with all frameworks/libraries/techniques/tools that you're currently using. They're all being developed at 100mph. 

That's only technical knowledge of course. There are many other skills you need to be a good software developer. Requirements gathering, version control, motivation, writing, teaching, documentation, time management, prioritisation, learning (I consider it a skill), problem solving, testing, typing, to list but a few. My head is going to explode. 

It's not all bad

I'm probably complaining for no good reason. It's not like I have a hugely stressful, mundane or dangerous job. In fact I consider myself lucky to have a job that interests me and that I find challenging. In this industry, provided you have the right attitude and motivation, you never stop learning, growing and progressing. I'm rarely bored, and there's nothing worse than being bored.