Dominic Burford - Professional Profile

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

The definition of a programmer[^] Laugh | :laugh:

"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

It's frustrating when you put your heart and soul into an article only for someone to quickly dismiss it by giving it a poor mark. It takes time and effort to write an article. Researching the subject matter, proof-reading etc. And it can take a second for someone to dismiss that effort with a poor mark.

Don't get me wrong, I welcome constructive criticism as I certainly don't profess to have all the answers, and I enjoy learning as much as I do teaching.

But when someone gives you a poor mark for an article, and then cannot justify that mark, is very frustrating.

To mark an article I would expect (demand) the following criteria are met as an absolute minimum.

1. Have read the article in its entirety.
2. Be sufficiently familiar with the subject matter of the article to constructively criticise it.
3. Ensure you have fully substantiated your mark with detailed technical information.
4. No personal attacks, sarcasm or other similar derogatory language. Comments should only address the technical content of the article.

If these criteria are not met then don't expect me to take your mark or comment seriously.

"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

Some developers seem to want to post questions on technical forums such as this one, and be supplied with a fully qualified answer, without so much as lifting a finger to research the answer for themselves. This is just laziness. How will they ever learn to find information for themselves?

There is a skill in finding information, and gradually solving your problem. I have got stuck many times finding a solution to a problem, and will explore many alternatives and sources to exhaustion before I post a question on a forum.

All developers should read this article before posting on a technical forum http://mattgemmell.com/what-have-you-tried/[^]

"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

A pet peeve of mine is the use of the var keyword and especially for declaring value types such as int, bool etc.

C#

var mBool;
var myInt;

These are value types and IMO should be declared using their intended type. Why let the compiler infer the type at runtime when you already know the type at compile time?

The same can be said for reference types too.

C#

var myString;
var myCustomer;
var myTransaction;

I can see why you would use the var keyword when working with LINQ (where the var keyword was actually intended to be used), but fail to see why you would use it elsewhere.

modified 23-Oct-14 2:58am.

Dominic Burford - Professional Profile

Summary

Reputation

Privileges