The Three Ages of A Developer

Our growth as developers goes through many stages as we learn more skills and gain experience but an important aspect of this development is how we view the world and our role in it.

We basically always think we know it all, we just change out minds about what it is, and why its important we know all about it.

The Science Bit

As fresh faced graduates we've been through years of hard work to learn the science of computation and the essence of technology. Then we discover the world doesn't welcome us with open arms.

The problem with many technology courses at universities is there not vocational, science has very little involvement in the day to day life of a developer. Should we be teaching the Shannon Sampling Theorem or Source Control, Diffie–Hellman Key Exchange or Debugging, Tree Models or Testing.

Obviously to produce a well rounded graduate education should be a mixture of all of these things but this lack of a real world view point is what produces the shock most graduates feel when they make there first steps into world of work.

Engineering The World

As we take on-board the skills a successful developer needs we make the transition to being a software engineer.

We understand the value of SOLID design principles, we know the importance of testing our code and we value the code quality in the systems we deliver into the world.

The next bump in the road comes when we realise business's and users don't actually care about any of this stuff.

Users obviously want products to be well engineered because they want them to work but they don't have or want to have any appreciation for what's going on under the hood. You want your car to be well engineered but you don't want to have discussion with the mechanic about the inner workings of the engine.

Business's are all about the development of product not the development of code. Their view point is similar to that of the user, they want what they want, the details are your problem.

This lack of appreciation for engineering is sometimes a difficult pill to swallow, the important thing to realise is that both business's and users do care they just don't know they do.

Badly engineered code will impact both at some point either via things breaking or via the production line grinding to a halt because of a fragile unmaintainable code base.

The Realist

The differing viewpoints of engineers and business's often leads to mistrust, engineers doubt the business's competency in knowing what they want and business's don't understand developers reluctance to build what needs building.

This mistrust is a shame because everyone ultimately wants the same thing.

As developers we must take on-board defining the right product is difficult and as such there will be many changes in requirements along the way. Its because of this that good software should deal with change and product should be delivered too users early and often.

Business's must realise that developers want to feel proud of the code they work on and as a result can be protective about anything that they think will affect this quality, they also don't want to store up trouble for themselves further down the line by making bad choices.

Ultimately as developers we must be realistic about the purpose of what it is we do, our job is to use the high degree of skill we have to help the business to produce products that users want to use. We are in the business of product development and we use engineering to get their.