No developer is an island
Developers love writing code because they get to invent things. But someone else has to use the code, operate it and even pay for it.
When I order a dish in a restaurant, I expect the chef to prepare what I order - and to make it more delicious than I could have done myself. Even if I asked for vegetarian and the chef prefers a bloody steak and hates salad, I would not be content with a few slices of cucumber, just because they were the remains from preparing the burgers. I imagine that the chef takes pride in her work and is affirmed when her product satisfies customers.
We as software developers like our jobs too. So let’s make an effort to satisfy the people we interact with during development. When we are given a task, when turning it into code, and when putting the software into the hands of users.
When you are handed a task, make sure it is described so you know what you have to do. There must be a definition of done. How do we know if it is working? Who is the recipient of the work? What will an end user be doing? What indicates whether the task is done right?
You may expect your product owner to have groomed the task in sufficient detail before handing it to you. But if they haven’t, for some reason, raise the questions that you need answered.
Imagine that you are the end user facing the software for the first time. You expect things to just work and you definitely aren’t going to read any instructions. So throw away your assumptions. Don’t be a technical apologist.
When you throw yourself at coding a new project, take a moment to orientate yourself in the code base. Where will the code go? Figure out what the existing code does by running associated tests and reading the code. Plan how your user story can be described as unit tests.
Sometimes we feel we don’t have time to care about clean code just for this task.
But then try to imagine: How would you like to come back to this piece of code in six months from now?
Would it be clear to read? Would you be able to test that some new changes did not break anything?
Take care to not leave legacy code behind.
Look at your diff before you create a review request, because at that point you are asking someone else to spend time looking at it.
Write a meaningful commit message.
Reviewers are not psychic. They do not know what you thought about when you designed the solution or wrote the code.
Put yourself in their shoes: How would you like to review your code with that commit message, that structure of code and that kind of tests? Would you be able to understand it?
Think about the stack on which your code will run. Are you able to run your code change in a production-like environment? Imagine the people who will operate your code. What if a service fails to start, but doesn’t provide a meaningful error message? Consider how much configuration is needed before the code can run. Does an operator need to follow a long list of instructions?
Consider whether log files are easy to find. Try reading the log messages after running the code to see if they are useful. The log should provide error details when something fails, but on the other hand shouldn’t be filled with stack traces just because of user errors.
Consider how the code can be monitored. Should your application expose custom metrics to collect data about usage, resources or events?
You may encounter problems implementing a story as it was specified. It may be after most of the estimate is already spent. Be open and make it visible on the daily standup. It may or may not be your fault. Product owners will appreciate fast feedback and will rather adjust expectations than have grumpy users. QA engineers will appreciate a functional but limited setup, over stumbling upon bugs you tried to hide. Operations will appreciate knowing a performance limit, because it means you have given it some thought.
How can we possibly achieve this, when we are so busy? There is always a pile of work waiting for us. To see why it is worth it, rephrase that last sentence: There will always be that pile of work, even if you code as fast as you can, skip writing tests and don’t talk to anyone. By making an effort, you actually end up saving time. Everything you clarify about the world around the code leads to better code. You may save time otherwise spent on a bugfix, supporting a user or trying to understand your own code six months later.
Put yourself in the shoes of the people you collaborate with. What do they expect?
Do you have a tendency to use the backlog as an eternal placeholder? If so, you probably have a lot of clutter that’s creating a lot of frustrations for your end-users. In this post we’ll show you how to clean up your Jira issues and reduce the backlog with some basic JQL queries.
Tips to improve project management in the Atlassian suite
How to test Kubernetes artifacts like Helm charts and YAML manifests in your CI pipelines with a low-overhead, on-demand Kubernetes cluster deployed with KIND - Kubernetes in Docker.
Low overhead, on-demand Kubernetes clusters deployed on CI Workers Nodes with KIND
Had enough of sluggish polling? With instant Artifactory event triggers you can give responsiveness in Jenkins a real boost. Here’s an easy way to set it up.
A super easy configuration guide
With the arrival of microservices code is becoming disposable. Does this mean that we no longer need maintainable code? Is it the end of refactoring?
Still relevant or increasingly redundant?
In software development tight coupling is one of our biggest enemies. On the function level it makes our application hard to change and fragile. Unfortunately, tight coupling is like the entropy of software development, so we have always have to be working to reduce it.
How to safely introduce modular architecture to legacy software
I am an Atlassian certified trainer and over the years I have been spending much time with clients and their Jiras. In this blogpost, I have collected some small tips and tricks that will make your Jira usage better.
Jira Software is a powerful tool deployed in so many organizations, yet in day to day usage people are missing out on improvements, big and small.
In this post, I’ll take a closer look at the version of Jenkins X using Tekton, to give you an idea of how the general development, build, test, deploy flow looks like with Jenkins X. How does it feel to ship your code to production using a product coming from the Jenkins community that has very little Jenkins in it?
A crash course in Jenkins X and how to test it out on a local Kubernetes cluster
In this blog I will show you how to create snapshots of Persistent volumes in Kubernetes clusters and restore them again by only talking to the api server. This can be useful for either backups or when scaling stateful applications that need “startup data”.
Sneak peak at CSI Volume snapshotting Alpha feature
When I read Fowler’s new ‘Refactoring’ book I felt sure the example from the first chapter would make a good Code Kata. However, he didn’t include the code for the test cases. I can fix that!
Writing tests for ‘Theatrical Players’
Nicole Forsgren and the Accelerate DORA team has just released the newest iteration of the State of DevOps report. The report investigates what practices make us better at delivering valuable software to our users as measured by business outcomes. Read on for our analysis of the report, and how it can be best put to use.
The latest drivers of software delivery performance
Hear about upcoming events in Scandinavia, latest tech blogs, and training in the field of Continuous Delivery and DevOps