Things to do when you’re not writing code

programmer at work

If you’re reading this, I assume most of your hours are spent staring at an IDE, coding away. What about the times when you’re not building shiny new features. If you’re lucky enough, then you’re going to have a couple of hours of free time every now and then. What should you use that time for ? So many possibilities. If you want to become a better programmer, then these few hours can be incredibly valuable. I’m here to help you get the most out of that time.

Tinker with your process

This assumes you have a process you follow through your day. If you don’t have a process, build one. A good starting point is the organization process It doesn’t have to be perfect. It’s not going to be perfect. That’s OK. A good process should be a checklist you go through for every piece of work.

What makes a process useful is that it can be improved. So start with something, anything. Now think about your process. Did you miss anything lately? Did you break anything? Does your work take longer than expected ? Did you find yourself waiting for others for extended periods of time? These are all questions you should ask yourself, and improve your process to prevent that! Sticking to a process is hard work, however, it’s worth it!

Read around

Reading is an important part of your work. You should not underestimate the value of information. The world of programming is in constant shift. New frameworks, patterns and technologies emerge every day. If you want to be a good programmer, you should keep yourself up to date with the latest trends. The best way to do that is to read around.

You should, at least, read about the frameworks you’re using. Become a guru on the frameworks you’re using. Look at the documentation. How is everyone else using that framework ? Is there anything you can learn from them ? Reading the source code can be incredibly valuable at times. Take your pick, but get to work!

Think about dependencies

What is the next thing you’re going to work on and why ? More than once, I have started on a ticket only to find out there are hidden dependencies required, assets that I needed (which take forever to track down and acquire).  Think about the next piece of work and the following ones. Is there anything you should do now to save yourself some time in the future ? There are lots of little things that have the potential of costing you lots of time later down the road. The earlier you think about them, the easier your life is going to be. And who doesn’t like an easy life?!

Think about potential issues

The hallmark of a good programmer is the ability to think about the bigger picture, not just what you’re working on at the moment. How does what you’re working on now fit into the whole project? Is the work you’re doing now going to cause any integration issues. I’ll give you a spoiler: Most of the problems with software can be found at the joints. What external services does your ticket (and project for that matter) depend on ? What happens if that service is down, or slow, or wrong or any of the myriad of possible ways of things to go wrong with a service. Catch them early and not only you’ll save yourself a headache (and possibly an embarrassment when the project goes live) and you will prove yourself as an awesome programmer. Two birds with one stone.

In conclusion, if you find yourself with some time on your hands, don’t waste it, use that time to improve yourself, like a knight sharpening its sword before a battle (I always wanted to say that!). Thse thins are valuable in the long run. Instead of stealing some moments whenever you have them, try to make them. Take a break from writing code and improve yourself. You’re going to be better at it! Your project is going to benefit! Everybody wins!

What do you usually do when you have a bit of free time on your hands ?

L.E. As with everything in life, common sense should prevail. This does not mean you should drop important work when important work needs to be done, nor does it mean you should completely abandon your other hobbies and focus on programming 24/7. If you need a break from work, you should take a break!

How to step up your automated tests game

fixing unit tests

This is a follow-up of my previous post here. If you’ve ever had to write automated tests, you might have some bad memories lingering around. Automated tests have a way of becoming troublesome as time goes by. You end up spending more time fixing the tests than adding actual features. When that happens, you don’t care about test anymore, you don’t run them, you’re not worried when they fail and you just don’t add new ones. That leads to brittle code and things break really bad really fast. I’m here to tell you there is a way to keep automated tests manageable.

Simple is better

Simple tests are the better tests. They should be simple to read, simple to run and simple to add. Clean up the setup. Wrap complicated setup in nicely named functions. Keep the logic linear. You should never have an if in your tests and you should scarcely use for loops or other exotic structures and/or logic. It’s as simple as this. When you write simple tests, you get easy to maintain tests.

Be precise

It should be clear what you are testing. A very good tip I have for you on this is to use the given/when/then format. What is that, you ask?! It’s a way of explicitly splitting your tests into three distinct sections.

Given should deal with setting up the data. Everything your test needs to run smoothly. This includes, but is not limited to: seeding the database, adding any mocks required, pre-generating any data and constructing all the models that you will use later.

When is where the magic happens. You test whatever you need to test here. You should make sure it’s obvious what you are testing. If you feel you’re not being clear enough, then wrap the call in function and name it accordingly.

Then is where you check your data. You have to make sure your test did what you want after all. The checks should be clear and self-explanatory. Additionally, the checks should be the direct effects of the when section. Don’t do unrelated assertions, even if they are true, unless you like to fix unrelated tests for every change.

I prefer using comments prepending each of the sections to make the tests even more explicit.

Test one thing at a time

Try to keep your test scope as narrow as possible. There is a two-fold benefit to this approach. First you get a clean list of failing tests when you break something. Hopefully you have named them well enough to diagnose the issue with just that. Secondly, updating the tests to match the code after you make a change should be a lot easier.

As I have hinted, naming is important here. The test name should hint at the non-trivial setup required and contain the assertion being made. A big red flag is if you find yourself having to use and in the test name. Some examples of some good test names are:

if the user is unauthenticated the server should return unauthorized
if the user is unauthenticated the server should log the request

A bad test name would be:

if the user is unauthenticated the server should return unauthorized and log the request

You’re actually trying to test two behaviors here.

Can you think of any other useful advice that could help us all with our tests.

Testable code design patterns

As you might have realized by now if you follow this little blog (and you should), I’m a huge fan of automated tests. If you’re not, I assume it’s because you either don’t find them useful, or you find them hard to add.

Tests are useful because code breaks. My code, his code, everyone’s code breaks eventually (and that includes yours too). What you aim achieve with automated tests is to break your code before you deploy it. It’s much easier to think of a fix when you don’t have people running around with their hair on fire because the site is down. Also, it doesn’t do you any good as a programmer to write code that breaks as soon as they leave your door.

Now that we decided tests are useful, let’s see what we can to make them easier to add.

Write testable code

You should see testing as an integral part of development. In the same way a programming language and/or framework impose some patterns in your code, in the same way the decision that you’re adding tests should change your code. I’m here to tell you there is a way to make your life a lot easier. There are a lot of design patterns out there. Together we are going to riff through a few that should make testing your code a piece of cake.

If your code is easy to test, you will test it more. With this you can ensure a more resilient project in the harsh production environment.

Dependency inversion.

You have more details here. It sounds a bit fancy at first. It’s not. The idea is this: Whenever a function/class depends on another module, they should get that module as a parameter and not instantiate it themselves. Combine that with automatic dependency injection and you’re in business. Mocking and stubbing will never be an issue again. You can completely isolate modules and mock out their dependencies. From then on the sky’s the limit on what you can test.

State is evil when testing

This is not so much a design pattern, as it is advice. Nothing will make your head hurt more than handling global state in tests. Then why don’t you save yourself the trouble and keep the state to a minimum. As a rule of thumb, all functions should be stateless. If called with the same params, then they should always return the same result.

If you remove state from modules, the problem becomes how do you deal with modules that inherently should have a state, things like db connections and network connection. My approach on this is to isolate the state in a shared model. Then pass that model around anywhere it is needed.

Be in the right mindset

Accept the fact that you’re going to have to test whatever you are working on now. Always keep that in mind when writing the code. Thinking How in the world will I test this, is a good way to spot anti patterns and code smells early on.

You have to think about module dependencies and if you should another. Then where should the logic and state live. Every now and then, you get to a point where you need to do some hackish workaround because the testing framework just hates you. That is OK, it’s just like every other workaround you had to do to get past a framework limitations.

These may not all be design patterns. However, I do feel that the advice above covers the gist of what you need to do so that automated tests don’t become a burden. See you next time with some advice on how to write better tests for your code.

Soft skills do matter

Let’s start at the beginning: what exactly are soft skills ? Soft-skills, is an umbrella term, covering the less technical skills you need for your work. Stuff like communication, time-management, delegating and other fun stuff you have to do outside of an IDE. I sure hope you are one of those programmers that do consider these skills important. Whatever your beliefs are, stay with me and you might just learn something.

You work with people

Obviously, but think for a second of the implications. Your work is based on other people’s work. People decide your tasks. People evaluate your work. And, ultimately, people pay you for your work. When you think about it this way, it seems important now, to learn how to deal with people. This includes negotiating, giving and asking for feedback. Some of the most efficient programmers I know, are great at working with people. They know what the client actually means when they ask for something. They know how people react when they are given both good and bad news. I would argue that a big chunk of their professional success has to do with their people skills. I’m not saying that you can’t be a good code without people skills, I’m saying that improving your soft skills make you a better programmer.

Prioritize

You are a professional and you should treat yourself as one. You should work on the most valuable piece or work first, and then the next one and the next one and so on. Now, the most valuable task might not be the most fun to do, nor the most challenging. It’s not the work you want, but it is the work you need to do now. Do that! It’s that simple. If you put the project above everything else and you treat your time as a valuable resource (which it definitely is), then, what you should be doing now becomes obvious. Do whatever needs to be done to move the project forward by the biggest margin. Additionally, your time is a valuable resource. Don’t waste it on useless tasks, don’t slack off, and never ever half-ass the work.

Opinions do matter

Imagine this: Someone asks one of your colleagues to recommend an awesome programmer for this cool project they have going on at the moment. Will they pick you? Would you like them to pick you? Be aware of your colleagues opinion on you. There are two easy steps to get there: ask and then listen! Learn what your peers want, what they value and fine tune your discourse to emphasize what they value in your work. Now, this might sound a bit mischievous. My advice here is: be honest. There is no harm in glossing over the details someone does not care about, in order to focus on the details they do care about, but don’t lie to your peers.

Communication is important

If you stop and think about it. During your average workday, you have a lot of discussing to do. Some are not that important, like the ones about the weather, while other matter a lot more, like the ones about your promotion. You spend so much time communicating, why don’t you try to do it right ? Communications  are the result that the sum of all your soft-skills produce. You should start by listening to your manager and try to understand their motivation. Then, you should make sure you work on the most valuable piece of work available. Trust me that will make your manager really happy. Then, think about the way you are presenting your work. Does your manager understand that your task is difficult, does your manager understand that you care about the same things he cares about ?

I know this sounds tedious, trust me. However, the good news is this: these are all skills, and even soft skills can be learned and, when practiced, improved upon.

Greenfield project – how to get it right from the get-go

You lucky programmer you. You get to work on a new project. A shiny new toy for you. All the possibilities that lay ahead. Simply limitless! Now the only question is: how do we do this right? How do we make sure our little project does not end up a big ol’ mess that is impossible to handle.

Decide on the spec

Before you can get your hands dirty, you have to have a plan. Right? You should have a very, very good idea what you have to do. Here are a couple of questions that you should have the answer to before you start any work:

  1. What are you trying to solve with the project ?
  2. What is the workflow of the project ?
  3. What is the expected load (now and in the future)
  4. What is the most important feature ? If you have to settle for three features, what would they be ?
  5. Are there any risks you need to look out for ?
Start reading

Now that you know what you’re doing, start reading! Honestly, there is a lot of reading involved before starting a new project. You should know what the available frameworks are, what are their limitations, what are they good/bad at. Additionally, you should have a good idea what add-ons you should use for what tasks and how well documented they are. Another important thing you should look into if known issues. There is a lot of less-than-stellar code out there, you should make sure you’re not relying on one for your awesome project. So, start reading now and don’t stop until you know everything. Well, maybe not everything, but you have a good idea what adding a particular framework means. Little word of advice here, if I may, just because you have experience with something, it does not make it the right tool for the job. Don’t skip over this stage.

Decide on the tech stack

Decisions, decisions! There are a lot of choices out there. Some are more mature (like Spring), while others are quickly changing offering new shiny toys at every turn (like React). You need to make a decision now that will affect the project it’s whole life. No pressure, right ? This is also the stage where you decide the infrastructure: what database will you use ? Will it be hosted on your server, or somewhere in the cloud ? What OS will the server be running on ? How will you do the deployment ? All of these are important questions, so take your time thinking about them now. You’ll thank yourself later. This is also the stage where you are in a safe position to make promises about timelines for your project, set deadlines, milestones, you know, all those things.

Set some ground rules

The beginning an important time for your project! The rules and conventions you set here are going to stick around for a long, long time. Be careful what patterns you add to your project here, they can save you or hurt you easily later down the line. Read about your tech stack’s best practices and make them part of your project. It’s going to be a lot of chaos in the early days of the project. You should be vigilant, so that you spot the changes that go against your rules and correct them.

Good job bearing with me this far. Now it’s time to go out there and make your dream project happen! Cheers!

8 git commands I use everyday

If you are already using git, then you can skip this paragraph. If you are fist hearing this word, then I can give you the basics for now. Git is the most used versioning control system. It basically is a way you can track all the versions of the program without having to get creative with folder names (version1, version1final, version1finalfinal etc.). Git also provides a way for multiple people to collaborate on the same project without stepping on each other’s toes (most of the time). You can get started with this tutorial. If you don’t know git you should start learning it now. I can’t stress enough how important and widely used it is.

If you already know about git, then you should have realized by now that keeping the git history clean is really helpful. It makes it easier to see what is merged and what needs work. You see when the changes were made and you can search through them for something that you want. It worth the effort to keep the history nice and organized for everyone. Without further ado, there are 8 git commands I use every day

git log

This is a nice and easy one. It shows all the history of the project, commit hashes, commit times and commit messages. You can search through the history by typing “/” if you want to look for something in particular.

git checkout -b branch_name

This creates a new branch of my current branch and checks the new branch out. Nice and easy way to get the task going.

git diff --cached

Once you add the changes you want for your task, you can review the staged changes to make sure everything is as expected. This command, together with git status, should save you from any surprised when doing a commit.

git commit -m "first message" -m "Second message"

The first message is a short description of what the changes are in this commit. I provide more details on the changes on the second message, which usually spans across multiple lines.

git rebase -i hash

Generally, when I work on a task I end up with a lot of commits on my branch. You know the ones: attempt at something, first iteration on something else, some minor change, oh now there is a typo. I like to have my tickets in a single commit when merging. This way, in the unlikely event, that I need to revert a ticket I can do that with just one commit.

git rebase master

I rebase a lot. Anytime I want to merge something I do a rebase on master first. This way you neatly stack all the commits for a ticket together. Makes following the git history much easier and reverting a change is easy peasy lemon squeezy.

git merge branch --no-ff

I very much prefer merging without fast forward. You get a nice commit message to celebrate and an easy to find point in the past to checkout if the need arises.

git push --delete origin/branch

Now it’s time to remove your work in progress and start anew. Great job! I prefer the more verbose way of deleting a branch. It’s harder to mess it up.

Let me know what other git commands you use everyday ?

Async programming models part II

As promised, this is the second part of my pocket-book introduction to async programming. Let’s continue!

If this article does not make sense, please check part I before shouting at me!

Map-reduce models

The map reduce approach is widely used in doing big data analysis. The model itself it’s a variation on the split-apply-combine approach, which is pretty much self-explanatory. You split the data, you send to multiple threads to tinker with it, you combine the resulting data and you get the result.

What are they good for

Map-reduce models are good at doing the same operations on large sets of data. You need to analyze numerous files, do it with a map-reduce model. Any kind of data which you can safely split into chunks, you can process with map-reduce.

Problems with map-reduce

With this model, you don’t have that much control over the threads. You just tell the thread what to do, and, generally speaking, it’s the framework’s job to split the data. Additionally, all of your threads are applying the same operation to the data set.

Map-reduce is not that good at handling interactions from the outside. If you need to handle user input, maybe this is not the way to go.

Map reduce usually implements the fork-join model. I.e. before the data is processed, you need to wait for all the threads need to finish, so if you have long tasks, then you’re going to keep lots of resources busy. Moreover, if you have network calls inside the map thread and one (or more) of those requests hang, you’re going to be in some trouble.

Where can I find this

Java parallel streams

Scala parallel collections

C++ OpemMP (albeit OpenMP offers more options than just map-reduce)

Promises

Oh boy! Promises are my new favorite toys for a while now. With this model you need to define a chain of actions that need to be performed on the data. Each action generates data that will be used by the next action and so on. After you do that, each action will be completed eventually (presumably on a thread that is not doing anything important), then the data is going to be passed to the next action and the cycle repeats.

What are they good for

Promises are a good way to parallelize a wide variety of independent flows. You have precise control over the actions in the flow and the order in which they are executed (inside the same flow at least). They can be returned from functions and that helps you keep your code cleaner and organized. Even more, you can bundle them together into bigger and more complex promises. You can pass any data to each of the actions in the flow. However, at the same time, you can do type checking on the data.

To me, the promises model is the most flexible model out there.

Problems with promises

They are hard to keep. Well, maybe not, it depends! However, the promises model is a bit hard to get the hang of.

Even though actions in a flow are executed din sequence, you have no control on the order of separate flows. This can be a problem.

Before you can use the data from the promise in the main thread you need to wait for the promises to complete. However, if you do lots of waits, (and in the wrong order) you may in fact hurt the overall performance.

Where can I find this

Javascript promise

Scala futures

Java futures

 

Async programming models part I

Asynchronous programming is everywhere around us and it’s here to stay. You might have noticed that CPU’s keep getting more cores as time goes by. Therefore, it would be a shame to let all those cores go unused in your app. In this article I shall be your guide through the various async programming patterns that I have used.

Plain old threads

These are the most powerful tools at your disposal. A kind of all-purpose swiss army knife that you can do everything with. The basic pattern is that you have a function that is going to run on a separate thread. You pass in any data that the thread needs and you are good to go.  Every pattern we will cover here can be reduced to this model (because this is what computers understand).

What are they good for

Plain threads are good for long, custom tasks that you need to run in the background. Do you want to build a server that handles multiple requests at the same time, then this is the way to go.

The problem with plain old threads

Albeit they are very powerful tools, threads can be a bit hard to use. You need to make sure you are passing the right data. Then you need to make sure you are getting the right data from the thread. And you need to all of this while make sure you are not causing any synchronization issues. That is not as easy as it seems. All the patterns share the synchronization issues.

Additionally, you need to decide on the number of threads to use and this is not a trivial task.

Where can I find this

All programming languages worth a damn provide some sort of API you can use for this

Queue of events

In this async programming model you begin with a bunch of threads that idly wait for something to happen. You also have a queue of events that keep track of what happens. When something happens, one of the threads picks up the work(usually the first idle thread). Then it does the work. Then it goes back to twiddling its thumbs until something new happens.

What are they good for

You should use this pattern when you need to respond to something happening in the world. These events can be HTTP requests if you’re building a server, user actions or other threads work.

Threads can be added or removed from the pool as needs demand. Most of the times this can be done automatically, so this is one less thing you need to worry about.

In simpler terms: If your app can be described as When this happens, then this should happen!, you can use this pattern.

Problems with a queue of events

You have significantly less control on the threads than you would normally do. Additionally, you need to add all the info required by the thread in the event data. From time to time, this can be tricky.

The queue itself can be a problem. Events can keep piling up during busy times or if there is a deadlock with the threads. If the queue grows too big events can either be dropped (causing loss of data) or they can block the system (causing much worse damage)

Where can I find this

This is all for today. Map-reduce and promises coming soon. Are there any async patterns you want me to cover?

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 works 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!