Dominic Burford - Professional Profile

In a recent blog entry[^] by Andy Hunt, one of the original authors of the Agile Manifesto, he openly criticizes the current state of Agile adoption. He makes the argument that far too often, Agile is adopted in a prescriptive and inflexible way. The whole point of Agile, as indicated by its eponymous name, it that it should be “agile”. Many proponents instead have taken the Agile Manifesto as a prescriptive set of doctrines to be slavishly followed. Agile however was never intended to be a process, but instead a set of best practices that could be implemented to align with the needs of the business.

Just like a design pattern is a general solution that is intended to be implemented in a way that fits the needs of the application, so Agile is a set of best practices that are intended to be implemented to meet the needs of the business.

The blog posting offers a way to power out of the rut, however, and it centers on a method that Hunt refers to as GROWS, or Growing Real-World Oriented Working Systems. In other words, software grows and changes based on real-world feedback and actual evidence, until it reaches a state in which it actually works. Hunt advocates the use of the Dreyfus Skill Model within this framework, as a way of on-ramping less-experienced developers while allowing their veteran counterparts more flexibility.

Quote:
“Whatever we attempt here has to work for the whole system, not just the developers, not just the managers, not just the testers, not just the users, not just the sponsors,” Hunt concluded. “There is no ‘us’ versus ‘them.’ There is only us.”

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Further to my previous blog post[^] on learning Node.JS, I want to recommend another book on Node.JS. In my previous blog post I had purchased a book called The Node Beginner[^] which is an excellent introduction to anyone wishing to learn Node.JS.

I have since bough the follow up book called The Node Craftsmean Book[^] by the same author Manuel Kiessling[^]. This book is every bit as good as his first book. It picks up where the first book left off by going through some more advanced aspects of Node.JS such as callbacks, asynchronous execution, event emitters and working with MySql and MongoDB. You then use these techniques to build a fully working Node.JS application.

The writing style is simple and easy to understand and by the end you have a fully working application.

I highly recommend both of these books to anyone who either wants to learn Node.JS from scratch or for those with some knowledge who want to dive a little deeper.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Well, my new laptop has arrived and I've been setting up my development environment. With so many free tools around these days it's easier to geek out than ever before.

So far I've installed Visual Studio Code, Visual Studio Community Edition, Reach.js and Node.js. I intend to install SQL Server Express and / or MySQL.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

This article[^] makes a good point. Great programmers write code that can be easily debugged. One of the first things I always add to my own applications is error and diagnostic logging. I do this as part of the underlying architecture, not as something I add later on (when it is obviously much more difficult to do so).

Whilst no software developer wants or expects their application to throw an exception, when inevitably it does, they will need the tools to track down and fix the problem. Without adequate logging this is almost impossible to achieve. It is a long and painful process of trial and error. It is a false economy to deliver an application more quickly without logging, as you’ll simply absorb all that time during the lifetime of the application thereafter.

Logging is not just a nice-to-have luxury, it is an underpinning part of the architecture.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

In the article In Praise Of The Average Developer[^] Jacob Kaplan-Moss asserts why the myth of the 10X programmer is so destructive.

As developers we all admire those who are on the bleeding edge, those who work tirelessly to stay on the crest of the technological wave and are constantly trying to break into new territory. Those developers who are writing articles about a new technology before we've had a chance to even download it. As developers we are excited by new technologies.

The harsh truth is that the vast majority of us are not like this though. As with any distribution, the majority of us will sit on the top of the bell curve somewhere. And there is absolutely nothing wrong with that.

The rock star developers may be awesome at coming up with fantastic new solutions and implementing new architectures using the latest bleeding edge tools. They may not be so good at fixing bugs and the other mundane tasks that are fundamental to the work of a software developer.

If the industry was filled with these creative geniuses then who would fix the bugs? The harsh reality is that the industry contains far more average developers than rock star developers. Not everyone is able or even motivated to work extra hours researching new technologies. But that's absolutely fine. Whilst the average developer may not set the world alight, they play a vital role nonetheless.

Whilst the industry needs rock star developers to keep pushing the boundaries and seeking out new solutions, it also needs the reliable, hard working average developers too.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

The annual Future of Open Source survey confirms what we all suspected: Open source has won[^]

With the mighty Microsoft now fully embracing open-source with many of its developer tools, open-source is now hard to ignore, even for the enterprise.

Quote:
The survey reports that 78 percent of its respondents are now running their businesses with open source software, and two-thirds are building software for their customers that’s based on open source software. More significant, the percentage of respondents actually participating in open source projects has increased from 50 percent to 64 percent, and 88 percent say they expect to contribute to projects within the next three years.

Open source is now no longer viewed as hobbyist projects developed in the spare time the closet geek, but is now viewed with (almost) complete parity with its shrink wrapped cousin. There is still some way to go, but this is certainly very encouraging progress.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Software development is full of best practices. Indeed entire books have been written on the subject of best practices covering every aspect of software development, from design to coding to methodology to name a few.

I thought I'd throw my own weight into the arena and list a few. These are in no particular order.

Agile methodologies are huge these days. There is an entire industry now dedicated to helping companies adopt agile practices.
Automated testing is something almost universally agreed upon as a laudable goal.
Test driven development may fall more on the controversial side, but there is no shortage of developers out there that think of this as a best practice (certainly when used strategically rather than in a purist manner).
Continuous integration, as opposed to developing in silo branches and then having extensive merging efforts, is also largely viewed as a benefit.
There was the original, so-called, Gang of Four list of object oriented design patterns, but the list of patterns has grown beyond the ones suggested by this group of authors to include many more. All taken together, using these patterns strategically is considered to be a best practice.
Code reviews are widely considered to be indispensable ways of promoting code quality.
Pair programming takes code reviews to the next level and has development performed in a constant state of review.
One click, automated builds are considered an important goal for most organizations, in stark contrast to the practice of having someone labor for half a day to get the software into a deployable state.

I could list many more, and may do just that in a future post. But I think those make a good start.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

In a recent discussion with a colleague we were talking about the analogies between the civil engineer and the software engineer. In order for the software industry to be given equality with the civil engineering industry, then it should adopt the same underlying principles.

Rigorous requirements
Rigorous design
Repeatable processes
Entry qualifications and external assessment

These are very worthy criteria to aim for, and I would definitely advocate their use. However, there are certain key differences with software engineering.

Software engineers are expected to be able to fit new features onto existing solutions. Imagine if a civil engineer was asked to amend their bridge so that it could accommodate trains as well as cars after it was completed? The civil engineer would quite rightly say that this was impossible or at least so financially costly as to be unworkable. The software engineer however is expected to do exactly this with the solutions they build.

I would definitely like to see more engineering disciplines filter through into software engineering. Particularly entry level qualifications and external assessment. To become a civil engineer and build a bridge you require certain minimum qualifications that have been verified by the industry. In software almost anyone can enter the industry with little or no qualifications and go on to build critical software applications.

There are certainly things we can learn from civil engineering, but there are also key differences between the two industries that we shouldn't forget.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

This article[^] makes for some very interesting reading.

Quote:
Web developers should learn .Net, Java and C# to improve their employability but will not make as much as other IT roles in the UK despite high demand, according to new research.

To me this seemed a rather strange statement as these are the key skills that many web developers would have anyway. I suspect they may be confusing web designer with web developer.

Quote:
Similarly, customers of all industries are demanding more intuitive applications to interact with businesses. Thanks to this trend HTML 5, Java Script and CSS were the top three front-end skills in demand so far this year.

It's fair to say that web developers are expected to be full stack developers who are comfortable working on the back-end business processing code as well as creating interactive and intuitive UIs.

At the end of the day you should love what you do and do what you love. Money can't buy you happiness.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

I recently came across this article[^] that demonstrates a high precision Pi calculator written as a Windows batch file.

As someone who got started in programming by writing Windows batch files longer ago than I care to remember, this is certainly impressive.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Whilst working a lot recently with various Javascript frameworks ((React.JS and Node.JS) I came across this fantastic unit testing framework called Jasmine.[^]

Quote:
Jasmine is a behavior-driven development framework for testing JavaScript code. It does not depend on any other JavaScript frameworks. It does not require a DOM. And it has a clean, obvious syntax so that you can easily write tests

If you're developing any sort of application that uses Javascript then you need to check this framework out. It's very easy to use and can be used in a TDD style approach.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

The following article[^] outlines the ways in which enterprises are failing to fully grasp the importance of open source software.

In a nut shell.

Quote:
Enterprises continue to fumble open source, largely because they misunderstand its value

Just as there is more than one way to swing the proverbial cat, so there is more than one way to increasing the bottom line. Selling software is certainly one way, but it isn't the only way.

Open source is a great way to advertise your skills, products and services. It can lead to higher quality software by allowing other developers to sweep through the code and find and fix defects. Apart from the development side there is testing, documentation etc that can also be harnessed by the open source community. The key word is community. To fully embrace open source and to maximise the benefit you get from it, you need to build a community around what you do. You need look no further than the mighty Microsoft and its recent strategy of opening up its development code bases (C# compiler, MSBuild, ASP.NET) for proof that the strategy can be an extremely successful one.

Giving something away may just be the best way to increase your bottom line.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Software craftsmanship is more than simply having pride in one's work. It's a two-way street. A craftsman approach also helps increase the respect of the business for their IT professionals, who bring high-level expertise and a sense of purpose that will advance the business. In software, developing a deep obsession with the customer's needs is part of being a craftsman approach. After all, obsession with customer satisfaction is what helps business succeed at the highest level.

A few years ago, these values were enunciated in the Manifesto for Software Craftsmanship[^] (with more than 16,200 signatories so far), citing the following values:

Quote:
As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
- Not only working software, but also well-crafted software
- Not only responding to change, but also steadily adding value
- Not only individuals and interactions, but also a community of professionals
- Not only customer collaboration, but also productive partnerships

The manifesto has a very similar vibe to the Agile Manifesto[^], and that's no accident. Agile principles are an important part of software craftsmanship, which also advocates a higher-order role for developers:

Quote:
Although software craftsmanship is not a methodology, it strongly recommends the adoption of certain technical practices and disciplines, mostly the ones defined by Extreme Programming. With a great synergy with Agile and Lean principles, software craftsmanship promises to take our industry to the next level. Professionalism, technical excellence, and customer satisfaction are the main focus of software craftsmanship. One of its main focuses is changing the perceptions that software developers are like workers on a production line and that software projects can be run as if running a factory.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

I have long been an ardent advocate of open-source software, and happily contribute to it when I can. I posted my Subversion to Bugtracker.NET application on my Github[^] page for example.

This article[^] nicely summarises why open-source software is becoming more than just a hobbyist past-time but increasingly becoming part of the enterprise software landscape.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

To say that Javascript frameworks have been in a state of constant change over the last few years wouldn't take a genius. Every developer involved with web development picked up and used JQuery to a smaller or larger extent. This remained the de facto Javascript framework for several years and everything ticked along very nicely thank you. But recently we have had Knockout, Backbone, Amber / Ember and Angular to name just a few, each one the flavour of the month in quick succession. I have often felt that I was spending more time attempting to learn the strengths and weaknesses of each Javascript framework than I ever did actually writing any code in them.

Too many of the other frameworks which I looked at seemed to take a "my way or the highway” approach, requiring you to rewrite everything from scratch. You had to follow that framework's ideology and force you to subscribe to its own idiosyncrasies. If you needed to follow a slightly different path to achieve something this usually involved a lot of pain.

Angular’s “directives embedded in HTML” approach, in particular gave me cause for concern. From what I've read on various forums, the two way data binding that is one if Angular's big selling points seems to cause as many problems as it solves, especially when applications scale up.

Angular certainly has a lot of developers using it. How many of them still like it now is another question. Backwards compatibility does not seem to be one of its core strengths. I’ve seen the up-and-coming Angular.js 2.0 described as a "course change", a description that should send a shudder through any developer that's relying on it. How many of those developers are going to take kindly to rewriting their entire code base from scratch. I think many of them may just look elsewhere instead.

I believe Angular.JS is heading for a demise that’s going to be even more rapid that was its original rise.

Enter ReactJS
For my money, Facebook's React.JS[^] Javascript library is set to dominate the web programming world. Even if it doesn't get as many developers as Angular or Ember, the latter two libraries are rapidly assimilating many of React's best ideas, so React will win out one way or another.

React's best features:
1. Encourages component-based design based on composition. Practically mandates it, in fact.
2. Implements a one-way, top-down data flow.
3. Has a super fast diffing engine that minimises updates to the DOM (always a performance pain).

With React.JS on the client and Node.JS on the server, the future of web development and Javascript in particular looks very bright indeed.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

As always I like learning new technologies. To this end I've been spending time learning Node.JS[^]

Quote:
Node.js® is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

Within the content of the Node.JS language HTTP is a first class citizen which gives you access the the HTTP request and response streams.

I bought myself a copy of the The Node Beginner Book[^] which is a tutorial that takes you step-by-step through building a simple application. For anyone who is interested in learning Node.JS I highly recommend this book. It's very easy to follow and understand.

I'm hoping to upload an example Node.JS project to my Github[^] account at some point in the near future so watch this space for more details.

It really is a fantastic platform to use. If you enjoy getting under the bonnet (or hood) of the web then you'l love Node.JS. As long as you have a good grasp of Javascript then you shouldn't have any problems learning Node.JS.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

The survey results[^] makes for interesting reading.

It also confirms the point I made in my previous blog. Javascript is officially the most used referenced language on Stackoverflow (which is a good indication of its use throughout the industry).

Quote:
JavaScript is the most-used language. 55% of developers use it plus 13% use Node.js and 13% use AngularJS. Of course, JavaScript is required by nearly every web development project.

A very useful survey that is definitely worth a read.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Javascript has always been the language of the web. Whilst HTML describes the page to the browser so your content appears, Javascript is what makes all of that happen in a more efficient way. Just try to imagine browsing the web without Javascript! It would be unusable. Pages would take an age to load and refresh and the user experience would be awful.

Recently there has been a huge increase in Javascript frameworks appearing. There is Bootstrap, Angular, React and Node to name just a few. With more frameworks appearing on an almost daily basis. This is in addition to already established frameworks such a Jquery.

To my eyes at least, Javascript is gaining in popularity with far greater numbers of developers seeking out ans learning these Javascript frameworks. For my own part I'm learning React and Node.

Quite frankly, if you're a web developer and you're not using Javascript in your applications, then you're not doing it right. If you develop web sites, then you absolutely, positively need to learn Javascript. No excuses.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

I have just finished reading the book “Domain Driven Design – Tackling Complexity in the Heart of Software” by Eric Evans and am very impressed. Despite being over 500 pages in length it is very readable. The basic principles underpinning DDD are a set of practices and techniques that help ensure that your software design exactly matches the domain upon which the software is modeled. So whether your domain is shipping or insurance or some other domain, your software should exactly match the rules within that domain.

The book provides techniques for defining the domain, isolating the domain (from the rest of the code) and for integrating the domain (such as with a legacy system). All of this is achieved using examples from Eric’s extensive experience and is backed up with plenty of diagrams to help understand the ideas he is describing.

This book is invaluable and should be read by anyone who builds software. Whether you are a developer, architect or analyst, you will find this book incredibly useful. It bridges the gap between conceptual, abstract models of the system, and the domain you are modeling. DDD marries your design to your domain and produces models that are intuitive and supple.

I would recommend anyone who works with software as a living to read this book.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

I heard this phrase recently and it struck a chord. As software developers we are passionate about what we do, trying to build the best solutions we can with the tools at our disposal. We try to employ good software practices through the use of design patterns, abstractions, re-usability, loose coupling etc. We try to come up with the best design we can to fit the problem at hand.

When we blindly implement whatever can of spaghetti is asked of us, then we have reached the point of software bankruptcy. Anything goes, no matter how much of a maintenance nightmare it might produce, no matter how big the ball of mud it will create.

Pressure from the business to meet a deadline is often the trigger for bankrupt software. But equally, we need to stand firm and make a stand for quality. If we fail in that task, can we really call ourselves professionals?

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Came across this blog [^] by Steve Yegge recently and thought I'd share it. It describes very clearly the mind-shift that is needed to move from a language such as Java (where nouns are king) to a language such as Javascript (where verbs are king). A great piece of writing.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

A colleague recently asked the question as to whether they should learn the language or the framework that implemented the language. Specifically they were wanting to learn JQuery and Angular.JS, but didn't know how much effort they should invest in firstly learning Javascript.

My suggestion was that they should definitely learn Javascript first. Then when they have become proficient at that, then they could look to learning one of the frameworks that uses Javascript.

You won't know what the framework provides, or where the language ends and the framework begins, without firstly having a solid understanding of the underlying language. It will also make learning new frameworks much easier.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Came across this interesting article by the .NET Junkie and found it very interesting.

I would like to remove the entire async programming model. Asynchronous methods tend to spread through your application like a virus and make both programming and debugging your application much harder. Yes, this asynchronous programming has become much easier than it used to be, but it is still harder than synchronous programming and it will probably stay harder until the .NET runtime has been re-written from the ground up to support such a programming model.

I know this is against popular opinion, but there is hardly ever a reason to pollute your entire code base with this asynchronous programming model. One of the main reasons for Microsoft pushing this programming model really hard is because it is more efficient when running in the cloud. This makes sense, because in Azure, you pay per CPU cycle and per the number of machines you need. But on the other hand, asynchronous programming costs way more developer cycles, and because developers are quite expensive, it is quite unlikely that your savings on the Azure bills will actually compensate the extra developer costs. But obviously, you will have to do the sums yourself.

Don't get me wrong, of course we want - and need - responsive UIs so we might need a few async/await calls inside your Window, Page or View Model classes in our presentation layer built with WPF, Silverlight, Win Forms or some other client technology. You can still do this, even though your whole code base below is synchronous, with synchonous calls to the database, web services and the file system. When doing that, you will still be able to make your UI responsive, but the only difference is that you'll have a background thread sleeping most of the time, instead of using I/O completion ports. But I've never ever worked on an application where having this single extra background thread was a problem. Even for Windows Phone applications this is a non-issue.

Asynchronous programming may be the new shiny thing in the .NET world, and with some training and experience, we can become quite effective as developers in applying it, but even then it is more painful than synchronous progamming (which is hard enough by itself), and instead of spending money on training developers on how to do async, I would rather spend this money in training them to learn the SOLID design principles, Test Driven Development, Functional Programming or writing clean code. There are so many other skills that are probably more important and more effective in writing good software, that I would rather spend my money on that first.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Came across this in the Lounge and it seemed very apt Help Vampires[^]

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

I have often pondered what traits make for a great software developer. There is an abundance of good ones, but what are the traits that make a truly great one. Here are my own personal thoughts on what separates a good software developer from a great one.

1. Technical skills and knowledge. This obviously goes without saying. A great software developer must possess strong technical skills, be a fountain of knowledge in their chosen field (whatever that is), and be the goto person who has the answers (or at least can point you in the right direction). This person has a solid understanding of their chosen technology and regarded highly by their peers and associates.

2. Is not precious about always being right. They are happy to be proved wrong, and embrace the opportunity to learn something new from a given situation. I have come across many developers who are quite combative in their approach, and rigid in their thinking. They think that their way is always the best way (or worse, the only way). Instead, a great developer will go "Wow I never knew that, that's a great idea". They embrace new ideas and are willing to learn from situations in which they arise.

3. Remains calm under pressure. I have worked with many developers who simply crack under pressure, and create a lot of negative energy around them when they do so. They get frustrated, angry, and snap at other members of the team. As the pressure increases, so does the amount of friction and negative energy that they create. They are not good to be around under pressure situations.

4. Willing to make a stand for quality. I have admiration and respect for those people who are willing to make a stand for quality. Those that care about the end product because they see it as an extension of themselves. Their name is associated with the product, so they want to ensure that it is of sufficiently high quality. That doesn't mean spending endless time implementing every design pattern and new feature, but someone who will ensure that the product has gone through the appropriate checks and processes to ensure that it is of the highest quality possible given the constraints of time and budget and is willing to make a case to the business to ensure that this happens.

5. Passion. For me this is the defining quality between a good developer and a great one. They get excited about technology; they want to get their hands on the new shiny tools and technologies as they emerge. Software development is more than just a job; it is an integral part of the person's personality. They love nothing more than discussing technology and passing on what they know to others. Their passion is infectious and is always invaluable on any project in which they are involved.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Home | LinkedIn | Google+ | Twitter

Dominic Burford - Professional Profile

Summary

Reputation

Privileges