Hi everybody! Hope you're all doing good.

Today, I'm gonna talk about 5 tips that you can easily apply daily to give better results when writing code working with a strict deadline

Sometimes we find ourselves not writing exceptional code. That's part of the life of software engineers. That could happen for many reasons, and one of the commonest is working with strict deadlines.

The chances that you're going to deliver poor code when dealing with very strict deadlines are high. Maybe because you didn't have enough time to test, or refactor, or review, or add that fancy feature you find some days ago.

But, we can mitigate that. I'll present 5 tips on how to overcome that without asking to extend a deadline. All the tips may or may not be applicable in your work environment, but I hope you'll find at least one useful:

1 - Try to break down the feature (or user story) into more tasks

Usually, that's part of the job of other folks in the team, like product managers or scrum masters (if you're in a Scrum team, but you got the idea). But, they are not always aware of the complexity attached to that feature. They just want that feature out to production., and is part of our job as Engineers to analyze and size complexity.

To help ourselves, we need to understand the scope of that particular feature and try to reduce that as much as possible. For instance, a feature to be fully working needs a coding effort at two different components of the application. This example feature can be broken into two user stories with reduced scope: one for component A, another for component B.

How does it help anything?

Well, there are some reasons:

• You can parallelize the work with other teammates, letting two people work on the same feature without overlapping their code.
• If you happen to deliver component A, without delivering component B, that's fine. Even if the feature is not fully working yet, it is clear what was already delivered.
• Giving full attention to component A, you'll be more capricious with your code.

The idea here is: Always try to understand the complexity and break down features into more tasks. Analyzing and breaking down complexity is a job that engineers can and must do.

2 - Elaborate a high-level approach and code

One thing that you want to avoid is to approach a problem in a certain way, then finding out that this way is not correct. Or, someone tells you that this way is not correct. Either way, you'll need to come up with a different solution and re-do all the code you wrote. And finally, your coding activity was just a waste of time.

How to overcome that? Fail fast.

This is a fundamental step in your coding process. Think about the problem for a while. Draw some sketches. Show up your work to others. Ask more senior folks to help you understand the problem and agree on one solution if you can't do that by yourself.

Let's imagine you have 5 days to deliver one task:

• If you write a very high-level solution and show up to others in 1 day and fail fast, you still have 4 days to come with another solution.

• Or you can spend 3 days doing the whole process of thinking and writing code, and discover that the approach will not work because of a minor detail you didn't notice. Your solution will not work, and now you have just 2 days to deliver the task.

You'll likely rush with another solution, test and review your code poorly, and finally deliver a poor code.

So, the golden rule: Fail fast. The job is to come with a solution, but it is also part of it to discover approaches that don't work.

3 - Write unit tests

Do this step for the same reason that you need to write a high-level approach. To fail fast.

Unit tests are the easiest and cheapest kind of test. Meaning that you can easily run it in your terminal in a fraction of seconds. That is so powerful.

We don't want to have a "surprise" when your code breaks in a stage/production environment. You can create lots of tests in your application, using lots of test scenarios, and again: fail fast. If your code doesn't work it's better to be at localhost.

There are many kinds of strategies on software testing out there, like TDD, BDD, whatever. One simple strategy for testing is:

• Write your high-level production code.
• Write test scenarios for it. Your test will most likely fail at this point.
• Improve the production code until you pass all the tests.
• Improve the tests.

Tests will help a lot to get the core functionalities implemented. Also, it will help a lot to refactor code. When refactoring big chunks of code, you don't want to break anything with non-functional changes. So, your tests must be written in a way that they do cover you to refactor properly.

If writing tests are not part of the culture of your company, you should propose to start doing so.

4 steps: Write a high-level solution. Write basic test scenarios for that solution. Improve the solution to pass all the tests. Improve the tests.

4 - Refactor and pay tech debt as you go

Sometimes we simply want to add more code to the codebase and finish our task. We implement the feature collected from the backlog and that's it. There's nothing wrong with that, but I'm a real fan of people that refactor and clean the codebase.

By improving, I mean refactoring and paying tech debt. Let's take a look at those:

• Refactoring your code refers to improve the current architecture/design. For instance, you break down one method into two, or you change a specific pattern used in the code or changed a variable name, etc.

• Paying tech debt refers to resolving something wrong in the codebase that was there before you touched the code. For instance, you can remove dead code from the codebase or refactor something that you've found. So, paying tech debt can be a form of refactoring.

And why these two things are important to write better code?

Because you become aware of possible improvements in your code while writing it. After some refactorings, you'll be more and more comfortable doing it. You'll start doing that naturally when writing new code from scratch. At that point, you'll see a huge improvement in your code quality.

So, rule of thumb: If you are well covered with tests, pay tech debts! Refactoring will become natural to you and you'll start to write much cleaner and better code.

5 - Review your code (and show it to your teammates)

Finally, code reviews. Code reviewing is an important step in any software project.

Do you ever feel like your code is awesome, and no one can do better than that? Well, try showing up your code to others :D. They'll find things that you didn't notice when writing the first time. Or maybe they'll find an easier way to solve the problem.

My point is: not everyone knows everything. People are different and have different experiences. What you know can be useful for other people, and their experience can be useful for you too.

So, talks to others about your code and ask for feedback. Also, you may want to open a PR (pull-request/merge-request) early for others to take a look at. Why do we need to talk about our code, or why do we need suggestions from other people?

One of the reasons is again: to fail fast.

Maybe you started something that could be improved right in the beginning and you didn't notice that. Someone can take a look and suggest an improvement.

Maybe you choose one path of coding that is not correct and will not solve the problem properly. Again, your teammates can suggest something.

Also, don't forget to review your code. That's important too. You may not want to spend other people's time on something that you could do alone.

And finally, review other people's code properly! Suggest something that you find that could be improved.

Golden rules here: Be open to suggestions. Open a PR fast and thus fail fast (or succeed fast). Spend a good time reviewing other people's code.

Conclusion

Software Engineers usually work with strict deadlines, and therefore the code can be delivered poorly. Maybe because we didn't have time to test it properly, or to refactor, or to use new and better technology.

We can not always change the deadlines for our tasks, but we can definitely change our workflow. The main idea in this post is to fail fast. And failing fast is important because it lets us know early what may or may not work. This is crucial to work with deadlines. Closing one door will let other doors open. Discovering right away that a solution doesn't work will give you time to think about other solutions.

To use this model, you need to start doing at least three of the tips listed here:

• Write a high-level abstraction before start coding
• Write lots of unit tests
• Open PR's early and be open to suggestions

And keep practicing refactoring code and breaking down tasks. This can be quite useful to write good quality code.

See ya!