For a while now I have been sharing some of my blog posts on the Dzone website.


The Dzone website allows users to submit links to content and I have been submitting the content I have created on this website. This is how Dzone describes themselves:

With over 1 Million members, is one of the web’s largest communities and publishers of technical content for software professionals. Developers from all over the world come to DZone for the latest and best content to hone their skills and advance their careers.

DZone MVBWell this week I have been invited to join the MVB (Most Valuable Blogger) programme. The hope is that more of my readers will find my content from the DZone website.

The DZone team will soon start sharing my content on the DZone website and I hope this will result in even more people reading what I have to say.

If nothing else this is clearly telling me that my blog is making a difference, people are taking note of me and what I have to say. I need to keep going and keep writing articles and be more consistent.

7 Warning Signs that you’re a Bad Programmer

you_are_coding_it_wrongAm I a good programmer or a bad programmer?

Here are 7 signs that might mean you are more towards the bad end of the scale.

1) You fail to plan before you start coding

I am very guilty of this, I love to jump into the code before thinking. But I am slowly starting to see the advantages of sketching a few things out before I write any code.

Most of my coding recently has been SQL based and I am starting to like sketching out table designs.

2) You fail to use version control

I have blogged about using version control in the past but it really is a very useful technology. It not only keeps track of every file in your solution and stores its entire history, but you can separate different versions into branches and see who changed what and when (and if the commit message is detailed enough why).

3) You use bad variable names

Whats wrong with variable1 and variable2 as variable names? Variables should be named after what they do or what they contain, but it is very easy to start copy and pasting them and before you know it you have a variable1 and variable2 situation. Remember that Visual Studio has some powerful refactoring tools so relatively easy to get them back in order.

4) You repeat your code

I’ve been reading Pragmatic Programmer and one of their first tips was DRY – Don’t Repeat Yourself. They go to extremes with nothing being repeated anywhere in your code, but I don’t think you need to go too far, you can be reasonable. If you have the same code repeated four times, then creating a function for this code will dramatically improve your code.

5) You struggle to understand your own code

Why did I do it this way? I feel like I am always trying to remember the reasons I chose to code the way I did previously. Part of the reason for this is that I am constantly learning at the moment, but there is more that I can do to help myself understand in the future.

6) You are selfish and don’t share

I am not selfish, if I learn something really cool I have to tell someone. I like writing stuff on here to share with the world. I am thinking of news ways to train my staff.

7) You work on multiple projects

Yes Guilty as charged with this one. I have multiple projects that I am working on at work, I also have a fair few personal projects that I would like to work on. Not sure I completely agree that multiple projects equals bad programmer.

Developer Personality Test

I was sent a link to a developer personality test earlier. The test aims to give you a look at your developer personality similar to the famous Myers-Briggs personality test. A shorter version of this test can be found here.

19etmksoopu2ojpgMyers-Briggs tells you if you are Introvert (I) or Extrovert (E), Feeling (F) or Thinking (T), Perception (P) or Judging (J) and Sensing (S) or Intuition (N).

This test however tells you if you are:

Independent vs Collaborative

Abstract vs Low-Level

Frontier vs Conservative

Generalist vs Specialist

Idealist vs Pragmatist

You prefer to spend most of your time working in an isolated environment.  You rarely want to collaborate because you have a better chance of solving problems on your own.  If you do have to collaborate on the direction of a project, you dislike it when you have to defend your position or when others try to muddy your plans for the project.  It’s better to have one strong vision for a project from the lead programmer on that project.  Having a large team or allowing others to have significant control over the project risks communication errors, a muddied code base, and inefficiencies.  If one developer has a firm grasp on the entire codebase, they’ll be much better at fixing and improving it quickly.

Good code doesn’t happen in a vacuum.  You need a team to keep you energized and on your toes so that you’re constantly improving the project code using the entire team’s varied experience and strengths.  You like to talk frequently with colleagues and discuss ideas so that you can learn from others and spark ideas.  It doesn’t matter what their experience level is, you can always learn something by including everyone.  A solo coder can’t possibly code a large software project with the speed and quality that a team can.

You prefer to write in languages and frameworks that simplify development as much as possible and use as few characters and lines of code as possible. The trajectory of software development has always been toward making life easier and error-free. Programming has always been about adding more abstraction layers to simplify tasks, so why not trust the technology on your layer and don’t worry about handling the lower layers?

The more abstraction tools and high-level languages we build, the further we get from understanding and controlling the deeper components in our programs.  This means lower performance and endless bug searches.  Developers today need to have a stronger understanding of compilers, memory management, pointer arithmetic, and other low-level topics.

You like to work at the cutting edge.  Using too many old languages and technologies bores you, and it severely hinders your software’s potential to keep outdated technologies in it for too long. Developers need keep their ears to the ground for new technologies and new versions of tools that they already use.  Even if the community and maturity of the project isn’t at a level that most enterprises would consider “safe,” you’re willing to be an early adopter if you believe the community and the technology has momentum.  Development technology is changing faster every day, and we need to constantly be adopting new tools and methods to keep up.

It seems like every 10 years we forget all the problems we solved in the previous decade and start to build ‘new’ tools that solve the same problems, even though there is a perfectly good solution that has existed for years.  Enterprises have it right when they make conservative decisions about their technology stack. Why would you hang your business on a technology with only a few years of maturity in just a handful of production use cases?  Technologies like PHP, Java, and SQL have been mainstays of the development industry for years, and it takes a lot of time for new technologies to make it into that maturity tier.

You like to be known as a “Jack of all Trades” and a reference for others on your team. You jump at every chance to enhance your skills in a wide variety technology topics, not just the ones that apply to your day to day work.  You don’t always know when it might be useful to have these extra skills, but when the time comes, you are ready.  If more developers took the time to learn other skills outside of the ones relevant to their project, they’d work more seamlessly with the rest of their organization because they’d have more empathy and understanding of the challenges that their colleagues face.

If you’re a Jack of all Trades, you’re a master of none. Mastery in one or two areas is what makes you valuable.  What’s the point of learning skills for other jobs you don’t have and can’t control? When you plan for a project or do technical research, it’s always focused on something you’re working on. You don’t get side-tracked. If you learn a new skill, it’s because the project requires that you do it. Most or all of your hobby projects are also building your mastery of the skills you use at your job.

You believe in the power of well-defined processes. It’s crucial to an organization’s success that they create and follow appropriate and effective processes for building software. Trying to improvise or play it by ear invites the possibility of workflow errors that can decrease the quality of the software or even cause major product failures. Planning is also extremely important to you.  You like to research all of the things you will need to know before starting a project.  It’s important to find out the best architecture for your software beforehand, and then strictly implement that architecture with objective best practices.  The more planning and scaffolding you do in the beginning, the less overall work you will have to do to complete the software.

Speed is your best weapon in a competitive industry, and to quickly prototype and build new products, you need to have a flexible, pragmatic process.  You don’t have a few months to plan your projects, you need to just start coding and a good path for the project will reveal itself.  Great products are made through frequent feedback and releases, so why shouldn’t your plan be just as adaptable? Your plan should be adapted to changes in the software, and your expertise should be adapted to the project. You shouldn’t spend your precious time studying a problem that you’re not certain to run into while coding your projects.  Trying to build test coverage for every possible scenario and having long meetings throughout the process are a waste of time and distract you from doing more productive work.

I am not going to admit where I came in this test as being a newbie developer my answers are very subjective and I don’t believe I have enough experience to really say where I lie on many of these issues.

I only have experience of working on my own and in very small teams, while I think working in a bigger team would have benefits I have no experience of this.

Don’t Live with Broken Windows

1-ucIHdOcnByPsF5eX0j_mhgLast night I started reading The Pragmatic Programmer by Andrew Hunt and David Thomas.

tppOne practical tip that immediately jumped out at me as useful in my quest to be a better programmer: Don’t live with broken windows.

The theory goes like this: an abandoned building with a single broken window attracts additional broken windows, graffiti, litter, and a sense that no one cares about this building. However this can be avoided if the authorities repair the window straight away.

You can apply this theory to other walks of life, too, like keeping your kitchen clean. After you’ve spent hours cleaning your kitchen to make it spotless, you make an effort to keep it clean. But if your kitchen is piled high with dirty pans, leaving out an extra mug or dirty bowl isn’t going to feel like it makes any difference.

The software engineering implications of this theory are that if you take care to keep your code tidy, it will stay that way. If you know something is broken but never make time to fix it, other bugs and issues will creep into it, until it’s a mess that no one dares touch.

We have a website that is starting to get a bit buggy. It’s not broken, but it’s been a while since anyone has given it any love. Bits of its functionality are starting to get flaky.

Being the only programmer in my place of work, I seldom have time to think about this website — let alone sit down and maintain it.

But the number of related support calls have been gradually increasing — more windows are breaking — and I’m spending more and more time patching its bugs to keep people happy.

Know that I’m aware of the broken windows principle, I know exactly what to do: sit down with this website for a couple of days and find out what exactly is causing these issues.

Then I’ll rebuild the flaky bits, replace the proverbial cracked glass, and wash down a few walls while I’m at it.

Source Control Fail

Every developer uses source control, it is a great tool for keeping track of changes to your code, seeing who has done what.

However I keep messing up, my use of it. I am fairly disciplined when creating new features, all my changes will get committed to source control and when I am happy I will deploy these changes to the live system. But as soon as there is a bug, especially one where the client is chasing for a fix, I will deploy a fix as soon as humanly possible on to the live system.

At first glance there is nothing wrong with what I have described but what happens the next time I deploy a new feature. Yes the bug the client was complaining about gets deployed with the new feature as the fix was never committed into source control. The client gets angry as the bug he was screaming about is back again.

Every change you make to the system MUST be committed to source control. If it isn’t that change will look like it never existed. I have worked with source control for over 5 years why do I keep making this rookie mistake over and over.

Troy Hunt has a blog post about the 10 commandments of using source control. His number two commandment is “If it’s not in source control, it doesn’t exist” He talks more about code you have written being not saved into source control, but the principal is the same for my example as his.

There are ways to automatically deploy from source control, however most of the time you don’t want your live database being rebuilt because you fixed a typo. Additional steps will need to be implemented and there is still the chance that you might want to bypass these steps to fix the urgent problem. The only way past this problem is for you and everyone on your team to be disciplined and only ever commit to source control first, and only after that deploy live (either automatically or manually)