WOW! It’s been so long since my last post here. So much has happened in the tech industry, and I’m back to share some insights into what I’ve been learning.

I explored in a previous post in 2023 how the LLMs are a great tool to help overcome the learning curve. After that, coding agents started becoming more powerful and independent.

Back to the core question of this article:

Does it even matter if we try to do good Software design?

Does it matter if we spend time doing code reviews so new code is readable, coherent, manageable for the future, if LLMs can handle it as is?

Who cares / Who should care?

I’m not big on click-baits, so I’m gonna give you the answer right away and then I’ll explain:

Yes. Software design still matters and there’s an economic argument of why you should care.

Let’s start!

First things first, what am I considering Good Software design?

I’m relying mostly on Kent Beck’s definition of software quality. As he rejects abstract definitions, he believes quality has an economic and practical definition.

Quality software is software that is easy to change.

That simple. Quality is not about elegance, technical perfection, or absence of bugs. It’s about the cost of future change.

The economic argument

Beck uses the metaphor of financial options:
- Well-structured code -> you have the option to change cheaply in the future
- Bad code -> every change is expensive, or impossible
- Tidying code is like buying an option -> it has a cost now, but reduces risk and future cost

Were you ever in a position that an apparently simple change became a nightmare? You only needed a simple new field on an API or change a color of a button, and suddenly, you cannot do it simply without disrupting the whole structure.

Practical Consequence

Code that works but is hard to change has less value than code that works and is easy to change. Even if they look identical from the outside.

This is the main thing that most people using LLMs to code are not realizing. It might seem cheaper to “vibe code” at the beginning, but the cost of future maintenance is going to skyrocket.

Code so humans can understand it. Then LLM will thrive on it.

I’ve come across this multiple times now. If you have code that’s very hard to understand, unpredictable, highly coupled, low cohesion… Then LLMs will also struggle on that and make LOTs of mistakes. Be careful in these scenarios.

On the other hand, If you have code that humans can understand easily, low coupling, high cohesion… all the good stuff from good software design: Congratulations. You now have code that’s cheaper to maintain, easier for humans to understand and the best part: LLMs will THRIVE on it!

That means we can delegate more things to the AI, with fewer risks that it is going to go the wrong route. In the “bad code” from our example, AI just makes lots of mistakes and gets off-track very easily.

Lastly… Beautiful code != functional.

When trying to be better at software design, some people try to make it more elegant, beautiful. That’s not what I mean here.

This is even a problem for me because the focus on the aesthetics can make it harder to spot the problems.

Instead, focus on:
- Structure and relationships of components: if A and B are coupled, every time you change A you also have to change B. Code so you diminish the dependency between components. This is the coupling principle.
- Cohesion: Keep things that are related to each other close in the code. It’s awful having to open 5 files to understand what a single process does.

What now?

If you’re interested in this topic and want to continue reading, my best recommendation is that you first read this book: Tidy First?: A Personal Exercise in Empirical Software Design

It’s by Kent Beck, the creator of the TDD methodology over 20 years ago. In this book he says that he took his whole career to be able to summarize the correlation between software design and cost… so you can tell that this is a take on the topic that’s worth reading, isn’t it?

Conclusion

This is a short insight, there would be so much more than I can put on a medium post. But feel free to reach out or comment below, I’d love to continue the conversation!

I love this meme. It illustrates how easy it is for people in software engineering roles to be highly stressed — Yikes!

I often talk to friends working in different, varied types of companies, and if they’re feeling stressed, I can usually pinpoint a few causes for that to be happening to them.

Some causes may be at an organizational level, but a many things can be solved at the individual level. And as soon as you have a critical mass of individuals doing the right things, organizational culture shifts for the better.

Let’s then cover a few reasons why you might be over-stressed at work, not to mention a possible downturn in productivity.

ℹ️ Hoard information for yourself

This is infallible. If you want to be miserable, treat information as currency and hold it as if your life depended on it. Sure, it would probably secure your job, as you’d be the only person knowing about a certain subject, but make no mistake: you’ll pay the price for it.

If you hoard information and overlook writing documentation, sharing knowledge, and presentations, you’re gonna be the only point of contact for that information and you’ll spend most of your days just sharing bits and pieces of information.

Good luck trying to schedule some time off, as even if you can get so, you’ll leave your team in a precarious position, and they may need to reach out while you are on time off.

Yikes! That does not sound fun.

Instead, sharing information will ensure you’ll have time for your meaningful projects. Check out the chapter Eliminating Toil in the SRE book to understand how you can eliminate tasks with documentation and automation.

👍 Always say yes

Another great way of becoming miserable is always saying yes to projects, demands, or asks, even when you are sure it can’t be done in the desirable time.

Many software engineers will accept technical challenges, knowing the effort needs more time than what is available. They may do this because they feel insecure about saying no to their managers or product managers, which is a valid concern.

But isn’t avoiding saying “no” and having a difficult conversation now, just pushing the issue to the future? If you know it can’t be done in time, it’s best to be honest, responsible, and do the right thing, even if it includes hard conversations in between.

I love the book The Clean Coder, by Bob Martin. The author stresses the need to be responsible and say no when it’s appropriate. Avoid overcommitting and be realistic about what you can accomplish within a time frame.

This is not to say “always say no”. If you have an unrealistic timeframe to work on, be open with your manager/product manager, negotiate with features you can leave out, and/or even ask for more time. Everyone will be happy in the end.

📈 Lose track of what matters

While the other 2 ways of becoming miserable are more “instant”, I’ll also offer you a way to be miserable in the long run.

The idea is simple: spend your time on anything you want, without evaluating how that things plays out in the long run. This will ensure that you won’t be focused, and will spread your energy across many things, without making any meaningful progress in any of them (see image above).

Well, if you don’t want to be miserable in this aspect, here are my recommendations:

• Always keep an eye on the big picture. How do projects correlate with the long-term goals?
• Constantly evaluate if you are spending your efforts on the right things. You may be spending all of your energy solving an issue that no one cares about and may not move the needle at all.
• Don’t treat time as an infinite resource. It’s easy to go down the rabbit hole in certain projects, but having a good sense of time vs. effortvs. benefits is key to getting this right.

The book Essentialism: The Disciplined Pursuit of Less, by Greg McKeown is a great recommendation on this topic.

Conclusion/Disclaimer

If you made it this far, you already get the idea. But to be crystal clear:

PLEASE DO THE OPPOSITE of the topics above.

Don’t Hoard information -> Share it instead.

Don’t Always say yes -> Understand when to say no and when to make compromises

Don’t Lose track of what matters -> Keep a close eye on the picture and pivot as needed to meet your goals.

This was a fun way to share a few of my thoughts on the subject, along with sharing some book recommendations in the process:

• 📕 Site Reliability Engineering
• 📕 The clean coder
• 📕Essentialism: The Disciplined Pursuit of Less

I hope this was helpful for you, and leave a comment to keep the discussion going 🙌

If you haven’t been in a hole for the past year, you already know that ChatGPT makes a great copilot when working.

We all have seen thousands of posts on how to get the best out of it, and since I don’t want to miss the party, today I’m adding my own tip to the pile 🌻

Today we are discussing how I’m beating the learning curve in Terraform using ChatGPT as my copilot 🙌

Context — What is Terraform?

Terraform is an infrastructure-as-code tool to help you define and provision infrastructure resources in the cloud.

Think about it this way: on any cloud provider, you’ll need to set up a few virtual machine instances, databases, platform-as-a-service apps, etc.

You’ll also need to connect those resources, like, the application needs to access the database. If you were doing everything manually, you’d create first the database, then the application, then manually include the secrets in the app.

With Terraform, you can automate the work of creating the resources, configuring some of the secret management, and getting everything up to speed. Amazing, isn’t it?

What about that learning curve?

I’m not new to Terraform, but the way it works always seemed to get the best of me 😂 I struggled a lot with the syntax, and how to put together more complicated use cases.

I always find the docs to be a great reference, but miss some of the recipes used in common projects — like separating environments, connecting different resources (like the app and the DB)

It had been a while since I touched Terraform, and recently I was trying it out again. This time, I used ChatGPT to understand some of those concepts. The result? Stay tuned 👇

ChatGPT as a copilot to learn terraform

Here are some of my questions:

How do I set up that cloud provider token again?

Among many options, this is what I needed:

The concept of `output`, how does it work?

This was really helpful, I wasn’t yet aware we could connect modules this way:

How do I interpolate the terraform workspace name into a resource?

It is that simple:

How do I access outputs from one module, in another?

My first question went like this:

How do I access outputs from other modules?

The answer was good, but it was not considering that I needed to use the output in a sibling module. I re-asked this way:

I need to access one module output, in another module output. how’s that possible?

I won’t copy the full answer, but then it got it right! Here’s what I needed:

• Define output in module A
• Define input variable in module B
• Use the main.tf to pass outputs from A into B

Then it worked ⚡️

Sorting out when something is not possible

I was trying to get something done that was not supported yet by the cloud provider. I was trying to get a Digital Ocean’s app platform IP, and here’s what I got:

And that was accurate once again!

Final Thoughts

I’m sure you already know but don’t trust ChatGPT blindly.

ChatGPT will have inconsistencies and mistakes, be sure to double-check the information in the official sources.

Quoting from a book I was reading on Plato the philosopher, here’s a distinction the author made:

The world has never had so much available information. Just search for a term, and you’ll get thousands of results. Now it seems that assimilating information is a trivial practice, but make no mistake. All of this available information isn’t always coherent and objective, therefore accessing information is not the same as acquiring knowledge.
From this book

That said, do your best to be critical about the information you consume.

Now, I’m off to go have fun learning concepts that once seemed too scary. Drop a comment if you liked this article 👋

Reverting git commits is that thing we don’t have to do very often, so we forget how it’s done when you need it the most (a failed Friday deployment, perhaps?)

Let’s walk through that in this small post, which serves as my own cheatsheet when I need it, and hopefully can serve you too 😄

Small disclaimer: This approach will work better when you already have changes merged in your main branch. We will create another commit reverting the changes. If you need to revert something and change the history, you'll have to use the rebase command instead.

Prerequisites

I'll assume the reader already knows how to use the following git commands:

• git log: shows the commit history. We'll need this to find the commit hash we want to revert.
• git add/commit/push: After you revert changes, you'll commit/push as you normally do.

#1 — Using git revert

To revert a single commit or an interval of commits, here's what you'll do:

# Find your origin branch, the one you want to revert things from
git checkout main 

# Use git revert, passing the -n option to generate a single commit 
# USe git log to find the hashs used bellow
git revert -n f21306c..e330c04 # OLD_COMMIT..RECENT_COMMIT
# For a single commit, you don't need the interval, so `git revert -n f21306c`

# At this point use, git status/diff to confirm the changes you want are there
git status # Shows affected files
git diff # Shows code changes

# If everything looks right, create a new branch and push:
git checkout -b reverted-branch
git add .
git commit -m "Reverted some commits 🙊"
git push origin reverted-branch

Note that I'm using the option -n on git revert. Without this option, changes will be committed right away to the working branch.

I prefer to take things more slowly and be sure of what I'm doing, so this option works best for me.

Feel free to omit the -n option as needed.

# 2 — Usando git diff + git apply

This is a more manual approach that will get the same result. Usually, git revert will be enough, but sometimes you may have a messier scenario that requires you to review more carefully each change. This approach may be useful in this case:

# Find your origin branch, the one you want to revert things from
git checkout main 

# Using git log, find the commit you want to revert
git checkout f21306c 

# Now, compare the current commit with main. 
# Confirm the changes you want are indeed present
# If they are not, you may be at the wrong history point
git diff main

# If everything matches, save the differences into a patch file.
git diff master --full-index > changes.patch

# Now go back to main, and apply the changes
git checkout main 
git apply changes.patch
rm changes.patch # Delete the patch file. We don't want to commit this.

# Now, checkout a new branch and push your commits 
git checkout -b reverted-branch
git add .
git commit -m "Reverted some commits 🙊"
git push origin reverted-branch

I hope this was helpful! If these tips saved a failed Friday deployment for you, drop a comment 🙌

Some time ago, as I was reading a book on Stoicism, I couldn’t help noticing some strong similarities between the two philosophies — Stoicism and Site Reliability Engineering (SRE).

Both philosophies strongly emphasize resilience, simplicity, proactive thinking, and personal responsibility.

Curiously, I could not find any other blog post linking the two philosophies, so here’s my compilation of the similarities I see:

Dealing with incidents

Let’s compare side by side two quotes.

First, let’s see a quote from the chapter Being On-Call from the 1st SRE Book:

To make sure that the engineers are in the appropriate frame of mind to leverage the latter mindset, it’s important to reduce the stress related to being on-call. The importance and the impact of the services and the consequences of potential outages can create significant pressure on the on-call engineers, damaging the well-being of individual team members and possibly prompting SREs to make incorrect choices that can endanger the availability of the service. Stress hormones like cortisol and corticotropin-releasing hormone (CRH) are known to cause behavioral consequences — including fear — that can impair cognitive functions and cause suboptimal decision making [[Chr09]](https://sre.google/sre-book/bibliography#Chr09).

Now, let’s look into a quote from The Stoic Challenge (by William B. Irvine). This chapter addresses how to deal with setbacks, which can be correlated to the incidents in SRE:

But when a water pipe bursts, the ruptured pipe is only one of the problems that confront you. Besides the problem of not having water where you do want it, you have the much bigger problem of having water where you don’t want it. The unwanted water might flood several rooms, and if the broke pipe is on an upper story, it might cause the lower-story ceiling to collapse. The flooding problem is much more serious than that of the break in the pipe itself. Consequently, when a water pipe bursts, your first response should not be to try to mend the pipe or to go out and buy drinking water so you can make your morning coffee. It should be to turn off the water supply, to prevent your dwelling from getting flooded.
In a parallel manner, when you experience a setback, you are faced with not one challenge but two, and the second — preventing a flood of negative emotions- is usually more critical than the first.

To my eyes, both paragraphs are saying the exact same thing. When you experience a setback or if you are handling an incident, preventing the flood of negative emotions (such as fear or anger) is the first thing to do.

Why? Simple: Fear and anger may cloud your judgment and cause you to make incorrect/suboptimal decisions that will ultimately make matters worse.

It amazes me how the first stoics, two millennia ago, figure out so much about human behavior. Many of those concepts were eventually backed up by modern psychology studies (see refs in The Stoic Challenge book), along with research on how certain stress hormones (cortisol) may impair our critical thinking.

Embracing simplicity

Simplicity is another common topic between the two philosophies and the reason is clear: simple solutions prevent complex problems.

Is important not to confuse being simple with being simplistic. Simplistic means that the solution was simplified to a point it no longer meets the requirements. Being simple means we are meeting the requirements with elegance and avoiding extra complexity.

Quoting from SRE, on the Simplicity chapter:

This chapter has repeated one theme over and over: software simplicity is a prerequisite to reliability. We are not being lazy when we consider how we might simplify each step of a given task. Instead, we are clarifying what it is we actually want to accomplish and how we might most easily do so. Every time we say “no” to a feature, we are not restricting innovation; we are keeping the environment uncluttered of distractions so that focus remains squarely on innovation, and real engineering can proceed.

Furthermore:

The price of reliability is the pursuit of the utmost simplicity.

Simplicity is also very common in the Stoic manuscripts. The goal in the Stoic philosophy is to attain tranquility, and keeping things simple will increase your chances of achieving that goal. One thing that caught my attention in my stoic readings is that if you lose the ability to enjoy simple things, your happiness is doomed. Wanting more things is part of human nature (due to the hedonic adaptation) and we should try as much as possible to enjoy simplicity.

Failure is inevitable

In the introduction of the SRE book, you can find that famous cliche phrase:

Hope is not a strategy.

Embracing risk lives at the core of the SRE philosophy. That is, accepting the fact that failure is inevitable and we should prepare processes to deal with failures when they happen.

Stoicism, similarly, teaches us to focus on the things we have control over and understand that bad things will eventually happen. See this quote from Seneca:

“Remember that all we have is “on loan” from Fortune, which can reclaim it without our permission — indeed, without even advance notice. Thus, we should love all our dear ones, but always with the thought that we have no promise that we may keep them forever — nay, no promise even that we may keep them for long.” — Seneca

In summary — both philosophies are similar in the sense that hope is not a strategy. Both also understand that failure is natural and the more prepared we are to deal with them, the better off we will be.

Conclusion

If you happen to have made it this far, here’s something you should know. I’m an imposter. I don’t have any formal study in philosophy, I’m only an enthusiast on the subject and yet here I am writing about philosophy.

If you do happen to be knowledgeable in philosophy, please drop a comment. I’d love to get insights on this article from people who studied all of this in-depth 😄

Nonetheless, this is a thought I’ve been meaning to share for a while now. I believe that knowledge is interconnected and we can draw valuable lessons from several disciplines. For the record, SRE has a chapter saying “Lessons learned from other industries", which does not mention stoicism directly, but mentions several other concepts from other industries applied in SRE.

References

Chapters in the SRE book:

• https://sre.google/sre-book/simplicity/
• https://sre.google/sre-book/embracing-risk/
• https://sre.google/sre-book/lessons-learned/

Stoicism books I’ve read:

• A Guide to the Good Life: The Ancient Art of Stoic Joy
• The Stoic Challenge

If you don’t know me personally, here’s something about me: I’m an awfully clumsy person. If there is a glass in the corner of the table, I’ll eventually knock it off to the floor. It’s not a matter of IF, but WHEN. I’m sure I’ll break stuff eventually if I have the chance to 😂

Ok, how does this relate to coding, then?

In my life, I developed a system to help me with my clumsy nature. I don’t leave glasses in the corner of tables, I don’t leave things in places that I know I’ll break/damage somehow.

I ended up learning the same precautions can be applied in my work/career to avoid breaking stuff — for myself and for others.

Here are a few common traps we leave in our code and how to overcome them

Low test coverage

Low test coverage in software means that not all parts of the code are being tested in an automated manner. This can have several negative consequences:

1. Bugs and defects may not be detected before affecting the real world
2. It is difficult to determine the quality and reliability of the software
3. It is difficult to make changes to the code, as you can’t be sure of what will break without running extensive manual tests.
4. Extra difficulty in finding the root cause of problems, which may affect the team’s ability to fix issues in a timely manner.

I consider low test coverage a trap in the codebase because similar to my personal issue of knocking glasses out of the table, it’s not a matter of IF this will be a problem. It’s a matter of WHEN.

In conclusion, a low test coverage decreases the quality and reliability of the software and makes maintenance and improvement harder over time.

Missing documentation

A huge part of my day-to-day as a software engineer is conveying information from one place to another. Sometimes is moving information into my brain, or vice versa.

When we are working actively on a project, we have a lot of information fresh and easily accessible in our minds. As time passes, we will certainly forget a good portion of that information.

If we do not make a conscious effort to document information in the correct channels, we are causing problems for your company. Quoting Bob Martin, author of the Clean Coder, one of the first things professionals need to have in mind is “to not cause problems”.

Documenting information properly is part of our job and part of our responsibility as professional software engineers.

Aside from that, here are other problems that missing documentation can cause:

• It can be difficult for new team members to understand the code and become productive
• Difficulty to maintain the code: similar to the lack of unit tests mentioned above, no documentation means that whoever is going to make changes in the code will have to figure it out on their own — and this will take time.
• It can be difficult to use the software: Without proper documentation, how are you supposed to know what the code is supposed to do/ or even capable to do?
• Different folks will work in this code in the future: as time passes, the author of a project may not be involved anymore. This is actually the most common scenario. Documenting things in time ensure that people won’t take crucial information with them when they leave.

Over-complicated code

You might get away with missing documentation if you write code that is simple, concise, and easy to read.

Well-written code can serve as documentation, so be sure to make your code as simple and as readable as possible.

Here’s an example of an over-complicated code (with high cyclomatic complexity) and how we can fix it:

def calculate_discount(price, customer_type, item_type):
    if customer_type == 'regular':
        if item_type == 'clothing':
            return 0.1 * price
        elif item_type == 'furniture':
            return 0.2 * price
        else:
            return 0.15 * price
    elif customer_type == 'premium':
        if item_type == 'clothing':
            return 0.2 * price
        elif item_type == 'furniture':
            return 0.3 * price
        else:
            return 0.25 * price
    else:
        if item_type == 'clothing':
            return 0.15 * price
        elif item_type == 'furniture':
            return 0.25 * price
        else:
            return 0.2 * price 

This can be refactored into the following code, which is a lot simpler to read and understand:

 def calculate_discount(price, customer_type, item_type):
    discounts = {
        ('regular', 'clothing'): 0.1,
        ('regular', 'furniture'): 0.2,
        ('regular', 'other'): 0.15,
        ('premium', 'clothing'): 0.2,
        ('premium', 'furniture'): 0.3,
        ('premium', 'other'): 0.25,
        ('other', 'clothing'): 0.15,
        ('other', 'furniture'): 0.25,
        ('other', 'other'): 0.2
    }
    
    return discounts[customer_type, item_type] * price

“Traps” == Technical Debt?

Technical debt refers to the accumulation of shortcuts, hacks, and unfinished work that will eventually cause problems for the team, like missing deadlines, poor code quality, more bugs, and taking a longer time to finish projects.

Just like financial debt, technical debt accumulates interest and becomes really expensive over time.

All the “traps” mentioned above can be considered technical debt. It’s normal for teams to deal with technical debt, as sometimes we have to make tradeoffs to finish projects.

It is important though to not lose track of the technical debt and allocate resources to clean it up on a regular basis — which is important for the team’s efficiency in the long run.

Conclusion

I have used this approach for years in my career (and personal life) and “not leaving glasses on the corner of the table”, figuratively or not, has been paying off really well for me and helping me avoid all sorts of problems.

Another way to think about this is by making an intersection with the world of cooking. There is a french expression “Mise en place”, which means putting everything in order/in the correct place to be able to work smoothly. That’s a way to think about coding too: everything should be in the correct place.

Thank you for making it this far in this peculiar thought 🙌🙏 I hope it was helpful!

Handling time zones can be quite maddening at first. If you work developing software, chances are you’ll have to deal with timezones eventually, primarily if your project is used in multiple locations (states, countries…).

It’s really confusing for the human brain to compare dates and times in different time zones. If you ever took a flight to a destination at a different timezone, you have experienced how confusing it can be.

This short article aims to give you a quick start with the terminology, most used methods, and some tips and tricks.

Terminology

• Timezone: From Wikipedia, “A time zone is an area which observes a uniform standard time for legal, commercial and social purpose. All time zones are defined as offsets from Coordinated Universal Time (UTC).”
• Naive date time object: when a DateTime object does not contain timezone information, we call it “naive”, e.g. 2022–10–13 8:00. This data time has some limitations, as you won’t be able to run certain calculations without the timezone info.
• Aware date time object: if you have a DateTime object and the timezone info e.g. 2022–10–13 8:00 (GMT-3:00 BRT), then you can run calculations and easily convert this to other timezones.
• Time delta: a time period, like “4 hours and 15 minutes”.

Looking at a few examples

Flights are a perfect example to work on: you depart from a city that has a different timezone from the destination. Let’s see what that looks like:

Here’s a summary of each step:

• 1-timezones.py: Importing the modules we need in the rest of the code
• 2-timezones.py: Creating a new data class named City to save the city’s name and time zone info
• 3-timezones.py: Another data class for flight information. We’ll need the origin, destination, flight duration, and departure time. Note we’ll also need some calculation methods to display the arrival date at the correct timezone.
• 4-timezones.py: Putting everything together: initialize City objects for origin and destination, along with a Flight.

This code will output:

Note the flight took 4h15, but the local time when you left was 16:15, and 19:30 when you arrived 🤯

Databases

You’ll probably want to store date-time objects in the database at some point. When that happens make sure you save the timezone information as well, so you can adequately convert when needed.

Example in Postgres:

select created_at at time zone 'america/los_angeles'
from users;

A few gotchas to avoid

Timezones are more than a single offset between UTC and the local time. They store information about a geographical area that might have had multiple offsets over the course of history.

Take Daylight Saving Time for example. The offset changes in a geographical area twice a year.

Gladly, pytz handles this for us, we have to make sure to use the correct method:

See the offset is incorrect for 2 reasons:

• Daylight Saving Time ended in this region on 2022–11–06. The offset should be UTC-4, not UTC-5.
• There is a 4-minute difference; As we mentioned earlier, the timezone represents a geographical area that might’ve had multiple timezones over time. If we don’t localize the date correctly, pytz won’t know the correct offset to use.

Do this instead:

Note the offset is correct when we use the localize method. Plus, the 4-minute difference is gone 🎉.

Conclusion

As long as you have a reference to the correct timezone and you localize/convert from one to another, python should manage timezones marvelously for you. Also, be aware to use the correct localize method from pytz to ensure you get the correct offset 🎉

A few references:

• https://popsql.com/learn-sql/postgresql/how-to-convert-utc-to-local-time-zone-in-postgresql
• https://docs.python.org/3/library/datetime.html
• https://pytz.sourceforge.net/

This is a tiny thought that has been in the back of my mind for years now. I think it is an incredibly simple concept with a huge potential to get any person to improve their lives and careers.

Throughout my career, I’m very grateful to have had incredibly smart people helping me out and I could learn a LOT from them.

Asking for help, though, is not something that comes naturally to some people and I like to think that asking for help is a skill.

Just like any skill, any person can master the ability of asking for help and unblocking a huge potential to get valuable information from smart people.

Let’s break this down into 3 simple steps:

1 — Give enough context when asking for help

Let’s take a look at this example:

Person 1: Can someone help me with this thingy?

And another one for comparison:

Person 2: Can someone help me with this thingy?

TL;DR: I’m trying to do X but Y is not working out for me. Can someone give me a hand?

Full context:

I’m working at X, which is part of the project Y. Part of the task involves getting Z done, which is exactly the piece I am having issues with.

I have tried already:

Option A: Didn’t work because this and that…

Option B: Didn’t work because this and that and that…

Option C: Could not test it because this and that.

After testing those options and reading through the documentation, I am now blocked and not sure yet how to move forward. I would appreciate if any of you had some clues on how to proceed.

Thank you!

Now, which person do you think will get a faster reply and will work their way out of the issue faster?

Certainly Person 2 for a few reasons:

• There is already a lot of context in the message. Someone familiar with that might easily reply with valuable information.
• It shows that Person 2 is already very organized and helping this person could be very simple and fast.

The issues I see with the approach from Person 1:

• It creates friction to get help. It requires at least another reply to get the full context, so it needs one more interaction. Something like “I need help”, “Sure, what’s up?”, “Oh, I’m having this and that issue”. See? It takes longer and does not work in favor of asynchronous communication.
• It may give the impression that you are not so well organized, which may give the impression that you don’t value and respect your coworkers time.

In summary, in our busy day to day work, if you can reduce the friction you create for people to help you, you’ll get better and faster answers and therefore you have better changes at excelling at what you do.

The most valuable lesson in this step is:

• Make sure you value and respect your coworkers time.
• Asynchronous communication is key, specially in a remote work environment. Giving the full context will ensure people can respond efficiently, even if they work in different timezones.

2 —Be proactive in asking for feedback

Sometimes, specially when we create things, we may be afraid of asking for feedback, dreading that people might find problems in our so-precious sollution.

Not asking for feedback is something that can delay your career improvement for a few reasons:

• People might not proatively give you feedback. Giving feedback is hard. It requires attention, empathy, time and a lot more. If you don’t ask, people might simply not tell you something is wrong.
• If you don’t ask for feedback, you’ll miss valuable insights from people that are possibly more experienced than you, and/or have different perspectives. Can you image the amount of issues that early feedback can save you from in the future?

3 — Be polite and light-hearted

One thing to bear in mind is that other people are living their own live, managing their own problems.

The best thing I can recommend is that the best way to ask for help is to:

• Be polite. Don’t assume that other people HAVE to help you. They might be dealing with other issues or not be available at the moment for any reason.
• Be light-hearted: Life is hard enough. Why not write some upbeat messages that will lighten the mood and make the interaction a lot easier?

One last trick when asking for help

If you are asking for help to an experienced person, they might be tempted to give you a LOT of context and a lot of information.

That’s because experienced people don’t want to steer you in the wrong direction. Also, they understand they previous experience might have worked for certain problems, but they understand there is no silver bullet. No solution will solve all sorts of issues.

What to do in this case then?

Ask: If you had these parameters, what would you do in this situation?

This is simple question that can have marvelous results. That answer will push the person to think about how they would solve it themselves, using all their previous experience.

You certainly don’t need to follow the recommendation exactly, but their answer might open your mind to ask better questions and understand their reasoning.

This question might also tap in their innarticulate knowledge:

“We know more than we’re able to explain that we know. And I call this inarticulate knowledge — the knowledge that I’m not able to articulate to somebody. And I have inarticulate knowledge about a lot of things, including other people. I could have tacit knowledge of why I trust somebody that I couldn’t explain to you. If you asked me to give you specific things, I wouldn’t be able to point to that, “Oh, there’s that one time when we were hanging out together,” because it’s probably not any one particular thing. It’s probably a series of things, call it a gut feeling. I just have that. And I have the same thing for mistrust. Right? And I think that this kind of tacit knowledge and articulate knowledge is undervalued in our society. It’s undervalued because we always want to be able to explain the science and give the hard reasons for it. But a lot of life doesn’t work like that.”

Entrepreneur, author, and educator Luke Burgis joins me for a deep dive on the René Girard and mimetic desire, different forms of knowing, and living a meaningful life. (read the transcript)

Conclusion

Life is complicated. The more we can learn from other people, more mistakes we’ll avoid in our future.

There are simple ways to ask for help in a way that significantly improves your chances of getting that life changing information you are looking for.

I hope you liked this tiny thought, please reach out if you have any questions or insights in the subject.

Thank you for reading!

Using outdated software versions may bring severe consequences to a product, from security problems to increased complexity in its maintenance/evolution. This article will explain how software versioning works and how we can avoid these problems.

Understanding the life cycle

Most software we use every day has some sort of life cycle. From operating systems like Android, iOS, and Windows to smaller components and libraries that compose our applications.

The life cycle is important for evolving software and applications, that means, life cycles provide the ability to add new features and make architectural changes in applications, following the market’s new technologies and trends.

This information is usually available on the releases page of any given application/library/framework. Let’s take for example the Django Framework:

Understanding Semantic Versioning

To navigate in the software development world, we need to understand the most commonly used versioning guideline: Semantic Versioning. Quoting from the official website:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes.

Let’s take a look at some examples of what this means in practice:

• Given we have a current version of 2.8.1
• If we update it to 2.8.2, this means we fixed something and backward compatibility is maintained.
• If we update it to 2.9.0, this means there are new features available and they are compatible with the older features (meaning: it shouldn’t break anything)
• If we update it to 3.0.0, this means we have new features and bug fixes, but also breaking changes, which are changes not compatible with the previous version.

In our day-to-day, we need to keep an eye out when updating versions to avoid having problems with breaking changes (explained below).

Dealing with Breaking Changes

Over the life cycle of a given piece of software, there will be times when an update will no longer have compatibility with previous versions, which requires the end user to make adjustments in order to update to newer versions.

From the maintainer's standpoint, backward compatibility is a quite challenging and complex problem. This way, but choosing to drop compatibility with previous versions, maintainers will have more freedom and capacity to create new features and enhancements, without worrying about legacy parts of the code. An excellent example of this is React’s Versioning Policies.

Long-term support (LTS)

Long-term support is a period in the software life cycle where the maintainers will continue working actively on the product, making improvements and bug fixes.

If a critical problem is found in an LTS version, it is expected that the issue will be fixed by the maintainers with a new version.

Using Django’s life cycle as an example we can see that version 2.2 will have support until the beginning of 2022. After that, the new LTS version will be 3.2. Having this in mind is crucial for planning our own updates, especially when the new version contains breaking changes.

How different software components relate to each other

It is interesting to note that many software components will be related in some way. Let’s take python 2 as an example, which has been completely discontinued in January 2020.

This means that even if security problems are found in python 2, these problems will not be fixed. This is why it is so important to update to the LTS versions as soon as possible.

As soon as python 2 was discontinued, many python libraries like Django and Flask started dropping support for Python 2, along with many other libraries.

Note the “cascade effect”: if you are using a library in a version that is no longer in LTS, all related/depending libraries will also drop support for that.

What happens if I don’t update?

As we can see cvedetails (security vulnerability data source), new problems may be found at any time.

Given that, if we are using an outdated software version that is no longer in Long-term support, we will not have an available patch to fix the security vulnerabilities.

We might have the option to update to a newer version, but if there are breaking changes, this will make it a lot harder to update to the newer versions, as we have to adapt some parts of our own software before updating.

Case study: Log4j vulnerability in 2021

It can get a little abstract to speak about the importance of using up-to-date software versions looking only to the future. For that reason, let’s take a look at a recent case:

In December 2021, a severe security vulnerability was found in Log4j, a logging tool for Java. This vulnerability allowed access to a remote server, simply injecting a command in the forms, headers, or URLs.

The Elastic Stack was quite affected by this vulnerability and on this page https://www.elastic.co/support/eol, we can see which versions no longer offer support. Note that:

Versions 7.x are the newest versions with active support, so they will be updated accordingly. Version 6.8.x had support until 2022, so in December of 2021, it still had updates.

This means that any person using older versions like 5.x will have a lot of work to update: they’ll first have to make adjustments for the breaking changes, then update to 7.x, where the fix is available. That’s a lot of work.

Speaking of a critical security vulnerability, there is very little time to lose, so the best scenario is to always be using up-to-date versions to be able to quickly update and be secure.

Other references

OWASP is an organization that works to map the main security vulnerabilities in the web and make them available for all the software development community, which ensures we’ll be all building secure software.

The project “Owasp Top 10” maps the 10 principal security vulnerabilities and item #6 of the list speaks directly to the fact that using outdated components is a security risk. Check the full list at:

• https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/

In the context of high performance and availability systems, load tests are a type of performance test where we check how a determined part of the system will handle many simultaneous users at the same time.

When should I use load tests?

Load tests will come in handy in many ways:

• When making performance improvements, we can check if the improvements are truly effective.
• When making decisions about a particular tech stack, load tests can be used to compare multiple approaches to the same problem and determine which works best.
• Estimate how many simultaneous users are supported by the given system.
• Find bottlenecks, that is, components of the system that will take too long to respond and affect the overall response time and user experience.

Locust.io

Locust.io is an open-source tool created to design and run load tests. The user behavior is defined by pure python code, which makes it easily customizable and extensible for many use-cases.

Setting up the load test

It is possible to run this sample project on your local machine or even deploy it to a cloud provider of your choice. Running that in a cloud provider will provide more accurate results since it will be similar to a real production environment. To get started, we’ll need these two repositories:

• locust-stress-test: Implements some tests using the locust.io tool. This is where we define the user behavior, like what pages it will access and the frequency.
• django-todo-list: A simple API built in python/Django that will be our target in the load tests.

Locust code will look like this:

Here we are defining the user behavior:

• Get a list of tasks using GET /tasks/
• Create new tasks using POST /tasks/
• Each user will wait between 1 and 3 seconds between requests.
• The number of requests in the list of tasks is 5x greater than the requests to create new tasks. Since on many websites the user will probably read a lot more than write, this is a simulation very close to reality.

Setting up the environment

It’s preferable to run the load test in a cloud provider (AWS, GCP, DigitalOcean, etc) to have accurate results with the reality, since this way we avoid having our local machine interfering with the results. To do so, I chose the following resources for this example:

• Postgres Database, managed by DigitalOcean, with 1vcpu + 1GB RAM.
• Application layer using App Platform, with 1vcpu + 1GB RAM

Running the test

The instructions to install and run the tests are detailed in the repository locust-stress-test, but in summary, we need to run:

poetry run locust --host=http://localhost:8000

After that, open the web interface displayed in your terminal, set up the test parameters then click “Start Swarming”:

Results and conclusions

Find below the complete report provided by Locust.io. Here are some observations:

• Until around 160 simultaneous users, we were having around 60 requests per second and the response time was very acceptable for this context (95% of requests finished in less than 400ms)
• The definition of what is an acceptable response time will vary depending on the context. Usually, we seek to have a response time lower than 300ms for APIs in general, but keep in mind this might change depending on the context of each system.
• After passing 160 simultaneous users, note the number of requests per second remains the same (60rps), but the response time increased a lot. This way, each user started having slower responses.
• In summary, with the available computing resources, we could serve around 160 simultaneous users with 60rps and a response time lower than 400ms. To increase these numbers, we would need more computing resources or make performance adjustments in the code. We could also add cache layers such as Memcached or Redis where it makes sense.

Check out the full report:

Understanding CPU and memory usage

Application layer

In our application layer, we see the CPU usage growing until it reached 100%. In a way, it’s a good sign that CPU usage is ramping up. This means our application server is well configured and it is not leaving idle resources.

On the other hand, since our CPU usage is getting to 100%, this also means we need more computing resources.

Database layer

We can also see in the database stats that we have a high CPU usage. This shows that the database computing resources need to be increased. To do so, we have a few approaches:

• Increase the computing resources for the database (+CPU, +Memory)
• And/Or create read-only replicas, in a way we’ll have separated instances for reading and writing in the database.
• And/Or add a cache layer (Redis, Memcached, etc) where possible to decrease the database load.

One step at a time

When performing load tests and improving performance, it is important to make small changes, one at a time. This way we can verify how much a given change affected the results. In the screenshot below, we can see the exact point where I changed a configuration and the response time improved a lot:

Combining small changes with monitoring (results and computing resources), we can understand how our system behaves under stress and adjust accordingly.

Additionally, this is a great usage of the Falsifiability principle in technology, which helps us make better and more assertive decisions about our infrastructure.

References

• Repositories with sample code: locust-stress-test e django-todo-list
• Setting it up on DigitalOcean: How To Deploy a Django App on App Platform
• Performance Testing vs. Load Testing vs. Stress Testing
• Will it scale? Let’s load test geohashing on DynamoDB
• How to Determine a Performance Baseline for a Web API
• 🇧🇷 PT-BR Version: Como fazer testes de carga com Python + Locust.io