Practices of a proffesional developer

Over the years I have picked up a list of practices that I think are essential to a professional developer - these are of course my opinions - other may disagree.
We don't expect our customers or managers to ask for these things - but rather as professionals we do this because - well we are professionals. When estimating a task at hand we don't add "unit testing" tasks 'cause these are just things we do
Just like at doctor does not expect his patients to ask him to wash his hands - neither do we expect customers or managers to ask us to do unit testing etc.
Big books are written about each of theªse subjects, hence I don't go into much detail about each - I just list them.
Either research on the internet or find a good book if you don't understand an item.
I am mostly a web developer, so these practices apply to that space - but most also apply to other spaces.

Development, Integration, Test and Live environment

As web developers we are not satisfied with the "it works on my machine" mantra, we want to check that the code works elsewhere - since most users wont come to our machines.

• The development environment is on the developers machine preferably with everything needed on this machine (including db et al.).
• The integration environment is for automated tests on the continuous integration system, the system should be deployed automatically here whenever code is committed. This is where we discover when our code does not work well with other code.
• The test environment is for QA folks to test stuff, the system is deployed automatically here by a push of a button.
• The staging environment is for smoke tests before going live, the system is deployed automatically here by a push of a button.
• The live environment is where end uses meets the system, code is pushed here automatically by a tester or product owner.

I have lived without the test and staging machines - but do not recommend it.

Use the best tool available

In the .Net world it is very normal to use Visual Studio as your tool of choice - actually I would postulate that almost 100 % of .Net developers use Visual Studio. People in this space seem to uncritically choose this tool without checking out the alternatives. For instance you could use another editor and use msbuild on the command line to build the site. You could run IISExpress from a powershell psake task.
Of course this is just an example, the important thing here is that you should choose your tool not just gravitate towards the default. The reason for this is that these are tool you use 8 hours a day - why not find the best?

Automatic test - prefer TDD

When we use the bathroom we wash our hands - when we code we unit test - these are things we don't question.
We know the difference between unit testing, integration testing and functional testing. We might not call it by these names - but we have a definition on our teams and we use them.
Some people think unit testing their code is hard - as James Gray II said on the Ruby Rogues "Testing is just using your code - so if you code is hard to test - its hard to use"

Continuous Integration

Well what is there to say if you don't know about this - stop what you are doing and find out.
This is a practice we use to always keep our code in good shape.

Automatic deployment

In general developers should not have access to the live environment or even the test environment. These environments should be stable and not fiddled with by developers.
If a SiteOp person does not exists a careful developer should be choosen for this role.
By the way many people decide to not do this until the project is finished, and then when the project is about to finish they don't have the time to create an automatic deployment .... hmmm....

Automation

In general if something is done over and over again - it should be automated.
Remember "If humans do stuff that computers can do, computers gather at night and laugh at the humans".
So many really cool tools exists these days, like gulp, grunt, rake, powershell psake etc. It is so easy getting started with these tools that no excuses exists!

Iterative Requirements

Requirements are not carved in stone - when a customer sees working software he will get a better idea of what the software is and hence the requirements will change.
If requirements are not clear reject - and help make the requirements clear. Question the requirements until you understand them - remember you have to implement this stuff
Requirements are, as stated above, not carved in stone, but to start work on something you don't know what is, is ridiculous. Make sure you understand the task at hand - and of course things will change...
Preferably a QA person should be on the team and help with requirements. Usually QA people are people with other skillsets than developers. Developers usually have a mindset of "ok i got it, I understand the whole picture now", whereas good QA people have a mindset of "What did I miss? How can I break it? Maybe its already broken?".
If QA people are not on the team choose a developer who has this responsibility.

Communication

Stand-up meetings with Product Owners and the team every day is the best way to communicate. Just answer the three scrum questions.
Furthermore short informal meetings about requirements is a good thing. Written communication is often misunderstood and hence should be kept short.
If we have problems we communicate about it

Ask for help

If you don't understand the tech or problem you are currently working with - ask for help! Don't just sit there - ask for help.
On the other hand don't disrupt co-workers too often as a disruption brings them out of their concentration.
Research on the pomodoro technique if you have problems with interruptions and communication.

Informative work spaces

The work space is where we live everyday - so we want information radiators telling us if our code and project is in a good state
A kanban/scrum board and an information radiator from the CI is a minimum - and probably is ok. Don't radiate so much information that something is overlooked.

Working software

At all times we should have the software working and ready to deploy, hence we branch out our code in the version control system we use - I didn't list that you should use some form of a dvcs (like git or mercurial) - because we do this as naturally as breething.

Collective Code ownership

The code does not belong to one person on a team, everyone is allowed to touch it and everyone should have access to it. Unit tests help us be more confident touching code we don't know well.

Coding standards

One way to make it easier to share code is to have coding standards and to have the CI environment break if the standard is not kept - or event better have a tool reformat the code to live up to the standards

Understand the balance

Everywhere in life we need to balance - its that way in code as well.
Understand how to balance between "Organizational needs", "Technical needs" and "Personal needs". To understand more about this read the book "The Art of Agile Development" by James Shore and Shane Warden

Quick becomes Quicksand

We all know how we sometimes have to rush to make a deadline - well often times we dig a hole for ourselves.
A long time ago i wrote a blog post about this topic

Diagnostics and logging

As proffesional developers we think about logging and diagnostics as part of our programs, since one day our programs will be deployed to production and erros will occour.
In order to not look to stupid in front of our customers we add logging so we can find errors and quirks quickly.
Of course monitoring like pingdom and logstash is preferable

• Image courtesey of https://www.flickr.com/photos/davegray/*