DEV Community: Ahmed El Taweel

Python decorator to show execution time of a function

Ahmed El Taweel — Sun, 28 Nov 2021 08:14:56 +0000

When working on a high throughput, low latency system, it's important to measure the execution time of your code to identify bottleneck and fix them. To do so, let's use a decorator to measure the execution time for the function it decorates.


from datetime import timedelta
from functools import wraps
from timeit import default_timer as timer
from typing import Any, Callable, Optional


def metrics(func: Optional[Callable] = None, name: Optional[str] = None, hms: Optional[bool] = False) -> Any:
    """Decorator to show execution time.

    :param func: Decorated function
    :param name: Metrics name
    :param hms: Show as human-readable string
    """
    assert callable(func) or func is None

    def decorator(fn):
        @wraps(fn)
        def wrapper(*args, **kwargs):
            comment = f"Execution time of {name or fn.__name__}:"
            t = timer()
            result = fn(*args, **kwargs)
            te = timer() - t

            # Log metrics
            from common import log
            logger = log.withPrefix('[METRICS]')
            if hms:
                logger.info(f"{comment} {timedelta(seconds=te)}")
            else:
                logger.info(f"{comment} {te:>.6f} sec")

            return result
        return wrapper

    return decorator(func) if callable(func) else decorator

By adding this decorator to each function, we can use the analytics from the APM to identify bottleneck and gain better visibility over the system.

Happy coding :D

Be BORING when choosing your tech stack

Ahmed El Taweel — Wed, 17 Feb 2021 11:44:22 +0000

Whenever you are starting a new project either in a new startup or a new solution for your current employer, always try to be boring as much as possible when choosing the tech stack.

TL;DR

Technology

Technologies tend to get better over time. The longer the technology is in the market, the higher the probability that it will be more stable.
Let's take python, for example, it has been around for around 30 years. it has hundreds of thousands of good packages. Hundreds of frameworks and a lot of support on StackOverflow and GitHub. So whenever I am going to start a new project, it will be on top of my choices.

Product

The final goal of any software project is to provide a product providing a solution for a certain problem. So we should not deviate from that goal. Building the coolest piece of software without solving the main problem is not considered progress and it's highly likely to be replaced with one that actually solves it.
The main factor in measuring the success of a product is its functionality. No user cares about what is the tech stack or the programming languages behind it.
Always remember the main goal.

Developers

Our goal is to solve problems. Chasing trends and use them whenever we can to pad our resumes will not the end goal and it's not advised.
And there no shame in using an old and stable solution to provide the functionality needed.

Takeouts

1- New technology choices come with a great deal of baggage.
2- Always keep your solutions Stupid Simple.
3- It’s important to master the tools you choose. Make sure you do that.
4- Progress happens when delivering working solutions.

Thanks

Why having a "Work With Me" guide can be a good idea?

Ahmed El Taweel — Tue, 29 Dec 2020 19:28:55 +0000

Lately, while I was surfing Twitter, I found this tweet from Shreef talking about his Work With Me Guide. And how it can be useful especially when it gets read by a teammate.

And that gave me a flashback about a problem that happened to me when I started as a remote developer for the first time in a new startup.

In April 2020, I joined a remote international team with 6 nationalities operating in 4 different timezones. I did not have a proper onboarding process. As I previously meet all the team members many times in casual meetings.
We all thought that should be okay joining and working directly. But it was not.
We did not know each other enough to work together and we did not have team rules for communication and work organizing.
Given that we were working in a startup moving fast to survive during the COVID-19 global pandemic. We faced a lot of communication, behavioral, and organizational problems which led me to leave in less than 2 months.

Although it was a long time ago, I kept thinking about the reason behind this problem. And I found that my teammates did not know me and I did not know them. I did not tell them enough about myself and I did not ask them to tell me about their preferences. We did not set rules.
Eventually, It turned out that we all were having different ways of handling communicating, organizing, and doing work.

Personally, I used to do face to face communication in all of my life. I was bad at expressing my ideas and feeling in writing. Also, I do not like doing work without taking care of planning, process, and organizing tasks flow.
On the other hand, others were less organized but they knew how and where to move their steps with minimal planning. And they preferred writing over face-to-face communication.

With that said, I think it would have smoothed the onboarding process, reduced communication conflicts, and increased the quality of the team environment if we have shared a Work With Me Guide together.

These guides should work as bases to set some team rules and as references to tell more about each team member in the work environment. They should be small, readable, and accessible. And should be used to tell how we work, what we like/dislike, what is the preferred way of communication, ... etc.

One other solution could be a Kick-Off Meeting between team members to know each other and to set some guidelines in the work environment.

Finally, Working in an international environment is challenging. We meet different people from different backgrounds. And these backgrounds affect heavily how people communicate, react, and respond. Even in local teams we can see differences but on a smaller scale.
What may be obvious to you, may not be obvious to your teammate.

Thanks.

My guide

Why getting the job done is not enough.

Ahmed El Taweel — Fri, 08 May 2020 21:44:47 +0000

During the old era of the software industry, some companies thought that delivering working software is enough to sustain the business.
It turned out that they were right and Working software is the primary measure of progress [7th principle in agile manefisto].
But, some companies and developers thought that it’s ok to deliver creepy software as long as it’s working and here where things started to take a wrong direction.

During the last 10 years, there has been an increased use of software in day to day routines, from notes and images taking to managing an entire multi-national organization using an app running on smartphones connected to the internet.
We see smart assistants, social media, e-learning platforms, e-commerce, .., and more.
Anything that was done in the past by working hands is now done by software.

With that increase in software usage especially in mobile apps and the amount of competition between startups and tech giants to acquire customers and increase their engagement, low-quality software is not welcomed anymore.
We are talking about customers using their mobile phones nearly every minute.
They do not expect latency, crashes, losing unsaved work, or bad UI/UX. And they do not care about the technical issues you face due to a sudden increase in traffic or a developer’s mistake in handling service scalability.

With all of that, it’s obvious that delivering only working software is not enough anymore to satisfy customers. And with this in mind, we need to reconsider how we manage, design, develop, and deliver software.

Fast delivery with high quality is a must to sustain customers and business continuity.
But, how to get the job done fast with good quality?

To answer this question, some actions must be taken:
1- Hire the right ones in the right position, not just the best ones.
2- Maintain the product/software roadmap and make it clear to everyone working on it.
3- Hold good communication channels within the team and across teams.
4- Assure that we need fast delivery but quality must not be compromised.
5- Give your team a space to innovate, give it the confidence to get the best out of it.
6- Be honest with your team, keep it informed, and updated.

This list can be long but these are the most important ones in my opinion.

Getting the job done can be challenging in the software industry, if not done the right way.
Having a consistent delivery process and a high bar for quality is not optional in the modern era. And with the harsh competition between companies -thank you internet- combined with high expectations from customers, we need yo revisit how we manage software teams and how we think, plan, and deliver software.

4 things I learned in the first month as a remote developer

Ahmed El Taweel — Tue, 28 Apr 2020 01:43:11 +0000

When I started a full-time remote job, I was frustrated a bit. I do not like the feeling that I am missing something. So I was doing my best to understand every tiny bit in the project and the workflow. Suddenly I started suggesting solutions and proposing enhancements to the process and the daily work and that was a big mistake.
During my first onboarding month, I took generous feedback that helped me a lot and facilitated my onboarding and understanding of the project and the team
That is why I am writing the top 4 things I learned from that feedback so anyone starting a new role, especially remote ones can avoid mistakes I fall into.

1- Be patient.

We -developers- tend to try to understand stuff fast, we hate that feeling that you do not know what's going on and how things work.
and that inner-feeling pushes us to take actions trying to understand the process and figuring out what is done and how it is done and this is a good thing but it also can be bad if done carelessly.

So, the first thing you need to do is to slow down your steps, take more time to understand, ask questions, collect information, and prioritize what needs to be understood first.
Doing so will leave a good impression with your colleagues as well as your manager.

2- Be more mature in accepting the process.

Some people when joining a new process try hard to make it like the one they are familiar with, and this -sometimes- causes conflicts between team members and leads to a lot of frustration for the person himself and his teammates.
So, the idea here is trying to ask why, why it is done that way. Break complexities to understand them. Be comfortable unlearning things and relearning them again.
This will indicate that you are mature enough to handle ambiguity and you are taking steps to fit into the process, not adjusting it.

3- Understand that people are different, not everyone is like you.

When joining a new team especially a remote one, you will meet new people with different mindsets and different attitudes. Sometimes communication can be challenging and your role here is to handle this challenge by accepting that not everyone is like you, not everyone is thinking like you and not everyone is behaving like you.
Understanding this helps a lot in breaking the ice between team members and leads to more collaboration and homogeneity in the team.

4- Do not have a quick solution, have quick questions.

Listen, understand, and ask questions.
Sometimes being the one who has a fast solution to everything is not a good indication.
Matching problem patterns and applying the same solution you are familiar with does not work.
So, ask questions quickly, understand requirements, think before proposing a solution, and question yourself 2 things:
1- Do I fully understand the problem?
2- Will this solution solve the problem?

Conclusion

Starting a new job is a challenging task and starting a remote one is more challenging. So do your best to fit in, hold good communications channels with team members, and respect the current process.
This will facilitate the whole process from onboarding to fitting in the day to day work.
Thanks.