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!

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:

What are you trying to solve with the project ?
What is the workflow of the project ?
What is the expected load (now and in the future)
What is the most important feature ? If you have to settle for three features, what would they be ?
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!

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!

Keep meetings short

We have all suffered through meetings. You know that meeting that seems to just go on and on and on without an end in sight. I you hate them as much as me, then this article might just be for you. In the following lines I will share some tips and tricks that helped me organize and partake in pleasant, useful meetings.

Meetings are a necessity

As the size of the team grows and there are multiple parties involved in bringing a project to an end, the overhead associated with coordinating these multiple armies of people become significant. Meetings are just one of the tools that helps to keep people focused and on the right track. Meetings are also a distraction. They take people away from their daily work, it breaks rhythm and whoever took part in the meeting needs a bit of time to get back in the zone, and be a productive little bee again. Given the high cost that meetings have, it’s worth doing them right so you can get the most value out of them.

Establish an agenda and stay on it!

Meetings should have a purpose! They should have a clear and precise purpose. If you are just sharing information, as in there is nothing to decide, you just want to let your team know something, that’s not a meeting, that’s a presentation and it’s a whole different story on what makes presentations useful. Meetings should be about deciding things. They are the much nicer alternative to huge email chain.

Getting back to the point. Before you start a meeting, you should know what needs to be decided. This way, if the discussion goes of track you can quickly spot it and steer it back on point and shave some minutes off there.

Let participants know what the agenda is.

The meeting will go a lot smoother if participants know what they are getting themselves into. They can do a bit of research beforehand, in the safety of their own desks. The more prepared participants are, the less time they need to learn what they need to know to reach a decision, the faster the meeting ends. Simple, right ? If you are a participant to meeting, feel free to ask what the meeting is about and get all the relevant information you need to prepare.

Get the right people in the room

This one is more for the person organizing the meeting. Everyone in the room should be there with a purpose: they either have the knowledge to answer a question, or the power to decide on a course of action. Everyone else can be briefed via email after the meeting ends. Getting only the relevant people in the room saves a lot of the debate that arise from either explaining a decision to someone without sufficient knowledge on a particular subject, or dealing with opinions from people that ultimately have no saying in the project. Remember less (people) is more (useful meetings)!

Take things outside (of the meeting room)

I’m definitely not suggesting fighting when you don’t agree in meeting. Keep things civil, we are professionals after all! This bit is more about the kind of discussions that are still in the scope of the meeting, but are at a high level of detail, so that only a couple of people care about it. If most people are not getting anything from what is being discussed, then you don’t have the right people in the room and you are wasting their time. When people get into such an argument the right thing to do is to call time out and suggest they (and only they) continue this chat in private and let you all know how it went.

That’s it! Try to do that so you get to enjoy the meeting you take part of, and, on top of that, feel like you’re actually doing something useful with your time while you are at it. Cheers!

A super short crash-course in negotiation

I’m sure that at some point in your career you will be in a situation where you need to negotiate. It can be a negotiation with your boss about that big promotion you were hoping for, with a client about the shiny new project you want or maybe with a colleague about the temperature of the AC. Well, whatever that situation might be, it’s better to go in prepared. Here are a few tips and useful advice you can use.

Know what you are negotiating for

The first thing you need to know when you are about to start a negotiation is what do you want. Sounds simple enough, however it’s an important part so DO NOT SKIP OVER THIS! You need to have a clear idea on what you want from the negotiation. Make a plan and stick to it. This is the ruler you evaluate the negotiation on. It’s pretty much the one thing you should not compromise on.

BATNA

Again on the preparation side of things: Batna stands for Best Alternative a Negotiated Agreement (some background on the term here). In short, BATNA is your backup plan in case the negotiations break down. It’s the worst case scenario, if you are unable to reach an agreement. You need to have a plan on what to do if things go south, what will it cost you and how you plan to deal with it. You’ll use that in your negotiation to gauge the value of the agreed solution, and quickly dismiss solutions that are worse than your BATNA so you don’t waste time on them. Also it should help you keep calm if you know you’re covered (sort of speak) if things don’t work out. The better you BATNA is, the better the position you are negotiating from is, so pay attention to this!

Establish rules

Negotiations should be fair (or at least you should try to make them fair). Fairness is a relative term and people don’t often agree on what it means exactly. Before you start negotiating, you should first agree with the other party what fairness means. As a professional (and I assume you are one) you should always negotiate fairly (this means do not try to cheat, it’s bad form). If you cannot reach an agreement on what fair means, you can just defer that judgement to someone else. Basically ask a friend you all trust if he thinks you’re being fair. It’s not that hard is it ?

Lateral thinking

OK. So much about preparations! It’s time to start negotiating! Yay! Lots of people tend to think about negotiation as a zero-sum game, if one party wins, the other certainly loses. Spoiler alert: It’s not! You should keep in mind the reason you are negotiating (see first part), but other than that, everything goes. Most often than not your main focus it’s not the other party’s main focus so it’s entirely possible for both of you to get what you want. Try to find things to sweeten the deal. Things that are cheap for you to offer, but have a big impact for the other party. For example, to make a project more appealing for a customer you can offer training sessions for the users, or provide some form of documentation. You get the idea!

Well, this is pretty much all I had to share about negotiations. Hope it helped! Cheers!

The tells of good feedback

So, what makes a good feedback ? I know there are a lot of articles out there about this, but that doesn’t stop me from giving my two cents, so bear with me.
Weather you’re giving feedback or receiving feedback, I find there are some attributes that make some feedback’s better than others.

Actionable

The purpose of feedback is to help someone improve. If the person receiving the feedback has no idea what they can do to improve themselves, then the feedback is like a bald hedgehog (pointless). If you want meaningful feedback, then it should refer to specific actions the person can take to improve themselves, which leads me to the second point:

Concrete

You’ve all hear it: You are doing perfect, keep it up! (followed by a warm pat on the back). This is useless! First of all: I have no questions that you are an overall great person, but, whoever you are, there is no chance that you cannot improve! And second (and this is more to the point): What am I supposed to to with that information ?! Where do I go from here ?! Certainly there are some things that I am doing better than others and I would like to keep doing more of those. Feedback should focus on concrete facts. Even if you are a superstar and you are good at everything you do, there must be some aspects of your work you could be great at, so try to focus on those.

Short

This one may sound a bit off at first, but feedback should be short. You do not want a laundry list of items on your feedback. We are not good at multitasking (regardless of what you might think), so focusing on a lot of things is just not going to work. For feedback to be truly useful you should find a few points that you can improve upon. I would recommend 3 or 4 key points so you can focus on those. If you tend to get a lot of items on your feedback list, it’s probably a sign you should have feedback chats more often.

Measurable

This one is sort-of dependent on the type of feedback you are getting, so it might not apply in some cases. It feels good to know you are making progress, and it’s useful to know when you are not, so why not have that information available for you to judge. This is easy if the feedback is accompanied by some kind of metric.

And now for the fun bit! Here are some examples of feedback that can be improved upon (granted there are a bit extreme examples, but I trust you’ll get the point)

“I liked your presentation! It was wonderful! You should do more presentations like that! ” versus “I liked your presentation! It was the graphics that I liked the most! They really help get the point accros! Keep doing those!”
“That meeting went bad! The clients are not happy with us! We should change that on the next meeting!” versus “The meeting went bad! We went in there unprepared and we were not able to address their questions! On the next meeting we should make sure we fully understand the requirements before the next meeting.”
“You have been missing your deadlines lately. You should focus more on being on time.” versus “You have been missing your deadlines lately! Can you think of anything that takes time necessary so you can remove those ? “

How to deal with issues in production – the short version

Okay, imagine the following scenario: You’re happily going about your day, coding away, without a worry in the world, and then this hits you: “There is something wrong with the production app” (well, maybe not this exact message, but you get the idea). What do you do?! How do you go about fixing the problem and go back to your everyday life?

1. Calm down

Yes, things are bad at the moment. However, this is not the time to lose your head and run around with your hair on fire. You need to have a clear mind in order to focus on the problem and easily find the solution. Go to your happy place and come back when you are ready to get to work.

2. Calm down some more

If you are anything like me then you probably are not calm enough to think clearly. You should calm down some more.

3. Investigate the issue and understand it

OK, now we are ready to start doing something about the problem. The first step is to understand the root cause of the issue. Maybe someone deployed something they shouldn’t have, maybe the data became corrupted or maybe, and this only happens once in a blue moon, maybe there this is just a misunderstanding and there is no issue at all, in which case: Congratulations, you solved it.

At the end of this stage you should be able to at least answer the following question: When exactly does this happens ?

4. Estimate the impact

Now that we know when the issue occurs, we can start thinking about who does this issue affect. A quick and dirty estimation should be enough. Some useful classifications are: critical (everyone is affected and everything is broken), medium (there is some impact, but the project will probably survive), low (this issue affects only a handful of clients/users), minimal (yes, there is an issue, but unless someone looks really, really hard they’re going to miss it).

Based on the impact of the issue you need to decide if you should fix this now, or later.

At the end of this stage you should be able to at least answer the following question: How bad is it ?

5. Calm down some more

OK, things are starting to clear up a bit now. You know what the problem is and how bad it is. Take a deep breath, decide when this needs to be fixed: either now or later.

6. Track down when the issue was introduced

If you use a versioning system (if you don’t you really, really should), use that to track down the commit that caused the issue. Look trough the code and use a sandbox environment (if any available) to figure that out.

At the end of this stage you should be able to answer the following question: What is the exact cause of the issue ?

7. Fix the issue

Now that you know what causes the issue you are in the best position to start fixing it, so go do it, be a hero and save the day.

Congratulations!! You fixed it! You can go back to your happy life – crisis averted.