Be a more productive coder – Some metrics you should use

What does make a good coder ? Is it the number of lines of code they write in a day ? How about the number of work hours they put in the office? Maybe it’s how fast they code, how quickly they solve any given issue? Well, as you might have guessed by now, I don’t fully agree with any of these statements. Here are some metrics that better reflect your proficiency as a  code writer.

Is your code easy to understand

You should always write readable code. I have an article here if you need a more in-depth opinion on what good code means. Being a productive programmer it’s not just about you. Your part of a team, a team of programmers who need to spend time understanding, maintaining and changing your code. If you have to spend a few more of your minutes to spare a few more minutes of some of your teammate’s time, then you have made the whole team more productive. Neat, isn’t it?

Forget the clever hacks and neat tricks you are tempted to use. I know, it’s hard to give up on a clever little idea you have. It happens to all of us, all the time. When it makes the code hard to read, it’s probably not worth it.

Is your code correct

This should be pretty obvious: Don’t write bugs. What it’s not obvious, however, it’s how costly bugs actually are. Tiny, little bugs cause big overheads. The QA need to file a bug report, it needs to be prioritized, scheduled into the current development cycle (call it sprint, or whatever you are using). Someone needs to pause their assigned work and start fixing it. This means they need to get up to speed with the area of the code the bug lives in, write the fix, review, and the QA needs to test it again. When you think about it this way, adding a few more automated tests and spending a couple of minutes manually testing your code doesn’t seem that bad. Am I right, or am I right?

Is your code flexible

To know if you are doing this, just remember what were your feelings the last time you were asked to change something you wrote. If your first though was: Noooo! Please don’t make me do that!!! then you should pay more attention to this. Keep in mind that requirements change all the time, and that the code is something that is constantly evolving. Therefore, you should write the code on the assumption that you will need to change it at some point, because it’s a safe bet you will. If you spend your time wisely now, you will save a lot more time later. Flexible code is an investment in your future productivity.

An important disclaimer here. Don’t overdo this. It’s a fine line between keeping your code flexible and spending waaay too much time preparing for a change that may never happen. If you are unsure, just ask someone. The PM/tech-lead/client should know how likely a change is, hence they should be able to give you the answer if it’s worth doing it. Design patterns are a good way to ensure you’re not overthinking the issue. Use them!

Summary

In the end, it’s not about how many lines of code you can write, neither about how fast you go through this current development cycle. What makes a good coder is how good they prepare their code for the next issue, and the next and so on. Therefore, in the long run, you are way more productive if you spend some time today to make your work easier tomorrow.

Do you know any other useful metrics that a programmer should use?

How to meet your deadlines – A quick guide to ensure you are never late

Oh, the dreaded deadline! You have a week’s worth of work to do by tomorrow. If that has ever happened to you, then you should know that feeling well. In the following lines I will try to give a few tips that should alleviate that feeling. Let’s begin!

Don’t underestimate the work

This is something that needs to be done in the planning stage. Estimating the amount of time a piece of work is going to take is as much an art as it is a science. It takes a great deal of experience to do it right. In most cases things are going to take longer than expected. A process that works really well for me is breaking down the work into the smallest piece of self-contained work (call them tasks, tickets, whatever you want, the concept remains the same). It is much easier accurately estimate a small piece of work, than a big one. When you have a list of small and self-contained tasks you can begin to add estimate them. At the end, add the values together and you have a deadline.

Give yourself some slack!

Estimating a task involves accounting for the unexpected. Unexpected events have an unbalanced effect on the deadlines. This is a fancy way of saying that bad things happen much more often than good things. Things will break, and they will need to be fixed, you will have to wait for other teams to be done with their work, specs and assets will be late, computers do break from time to time and that will certainly affect your deadlines. The more dependencies you have on your task, the more slack you need. This may sound extreme, but I usually add a 30% slack on the dev time and even that proves to be insufficient from time to time.

Be honest with the stakeholders

Do not commit to more work than you are able to do! Remember, in the long run, doing things right is much faster than doing things fast. If you need to rush through work, you will unavoidably make mistakes that tend to add up over time and slow down future development time. You have probably heard this before, but I’m going to say it anyway: Do quality work from the start, even if it takes slightly longer now, it will save you tons of time later down the road.

Track progress as you go along

It is much easier to make corrections to your course as you are traveling towards your destination. How does this translates into a helpful tip? Glad you’ve asked! To sum up: It’s easier to correct for small delays than large ones. That sounds reasonable enough, right? The trick here is to spot delays as early as possible. If you have a timeline for your project, you should be able to say at any moment if you are on track. When the work slips, it’s going to be easier to account for a small delay. By doing this regularly, it should never come as a surprise to have to do a month worth of work withing a week.

That’s all we have for today! Hope you have enjoyed it! See you next week!

How to write better code – 6 things I did not found on the first page of google search results

I know there are millions of answers to this question (I for one get 484,000,000 hits on google when I search for How to write better code). They all seem to revolve around the same general idea, so I will not be repeating that. You are free to do a google search yourself and read through those.

I will however, be sharing some tips that I picked up that you may find useful. Here we go:

1. Do not compromise

We all know when we are doing a hack, or a nasty work-around because the right way takes too long. We know it, and we still do it. Maybe it’s late in the day, and we just want to go home, maybe the deadline is closing fast and someone is going to be really mad if the project is not done on time or maybe we just can’t be bothered to do things the right way. My advice to you here is, you guessed it, do not compromise code quality. Compromises made now will slow down development in the future, which will in turn lead to more compromises and so on and you will end with a mess of a project that you will need to maintain. And that’s no fun 🙁

2. Less is more

A programmer’s proficiency is not measured in the number of lines of code they write, it’s more like the opposite. The more code you write, the more chances to break said code. The odds are against you. If you have to think twice as long on task to write half the code, do it, it totally worth it.

3. DRY

Don’t repeat yourself! I’ll say it again: Don’t repeat yourself! (pun intended). In my experience, the worst codebases I had to deal with are the ones which chose to implement the same logic in many (and often quite creative) different ways. Don’t do that to the person maintaining your code. If you have to use the same logic in two different places, be sure to have the code in one place.

4. Follow the existing pattern

This is an extension of the previous topic. Please try to avoid adding a new pattern to the project, unless it’s really necessary. One style of doing things should be enough for one project. I accept that this may be hard. Especially if you are just starting on a new project that seems to be doing things differently from what you are used to, but don’t give into the temptation. Keep the project simple and follow the existing pattern, even if it means more work for you now. And remember: It will get easier with time.

A notable exception to this rule is the process of replacing the existing pattern with new and improved one. If you are doing that you can have two patterns in the project at the same time, while the old one is slowly retired.

5. Automated tests

I really don’t see nearly as much as these that I would like to. If, at any point in the development process, the thought that you need more tests crosses your mind, you are probably right. As you might have guessed if you follow my blog, I’m a big fan of automated tests (maybe enough to write an article about them some day). Automated tests are great, and they have many advantages to them. They give you the confidence that what you just changed did not break any hidden functionality. They serve as an always up to date documentation for the project (as long as they are passing).

6. Common sense must prevail

We need to take a step back now and acknowledge that each and every one of the points above can be taken to extremes. As you might expect, taking internet advice to extremes is not advisable. So I leave you with this: Whatever you do, don’t forget to use your basic, human, common sense. You are free to bend and adapt the rules so that they make sense given the situation.