DEV Community: Jafet Benítez

The Mentorship

Jafet Benítez — Wed, 20 Jul 2022 17:37:31 +0000

Software development is a really particular industry, I have never seen an area that combines technology and artisanal work like this. What is even funnier is that even developers forget this facet or maybe never notice it.

We are used to seeing software development and immediately think about cutting-edge technology, industrialization, and all that cleanness and perfection that is often described in some of our science fiction classics. A second look into the area shows us that even in the more industrialized software factory, development keeps being a very artisanal work.

Artisans are known for creating products with expertise, high attention to detail, and without fearing putting their hands in the dirt. Software developers, or at least the good type, treat every piece of software as a delicate vase that they are giving form while they refine it... But today, I don’t want to dive extremely deep into every similitude and lose myself in the analogy, I want to talk about something that artisans and developers have in common, but sometimes, we forget or take for granted: mentorship.

I remember my early days studying software development. We used to talk a lot about how easy it is to find resources for learning new technologies for free on the web and how becoming an autodidact was a must for every dev. Some years, several JavaScript frameworks and many bugs later, I can look back and see that we weren’t too far from reality but that was just half true. Yes, we must be able to learn by ourselves. Still, we usually need somebody who points us in the right direction, someone who teaches us not the solution to the problem but a general methodology to solve problems. We have to be able to learn by ourselves, but we need mentors and eventually, when the time is right, we will need to be a mentor for someone else.

Why do I need a mentor?

GIPHY

While I’m writing this, I have a little more than 6 years of experience in the industry. I have had the honor of knowing great professionals that have served me as mentors in different moments of my life. Some of them were my teachers, other coworkers, university teammates, or even people from my local community of developers. Mentors come in a wide range of packings but they always help you to walk in the right direction.

Something that I must highlight is that I’m not just talking about receiving a block of code to solve a problem or taking a peek at your code to check how you are implementing things. Those things are great, actually awesome, nevertheless, I talk about having someone to talk about career development, high-level archetypes for some kind of problem, promising technologies, and receiving advice about that.

I’m talking about having someone who helps you to see the big picture. The problem with any new software developer is that they can be too short-sighted and are often taken by trends. There’s always a new framework, a new technology, or a new language. Trends can get messy, and being guided by trends can get us in a never-ending loop of superficial knowledge about everything without foundations of nothing.

Why do I need to be a mentor?

GIPHY

After understanding why people need mentors in almost every stage of their career, it’s simple to see why the world needs more mentors, but something that can be hard to realize is the reason why I should be the mentor that people around me need; in particular, if I haven't had a mentor. My answer to that thinking is that you have to be a mentor because you need to be a mentor. As dumb and simplistic as it sounds being a mentor is a need because it helps us to grow.

I’m convinced about the idea that mentoring someone makes both, mentor and apprentice, grow as a professional and maybe even as a person. When you have to mentor someone, your dominion over the topic is put on trial, so you have to walk the extra mile in order to be able to answer the questions when they arrive. When you have to mentor someone, you become some kind of leader, and not the bossy kind, but the organic one that people enjoy working with. So, why do I need to be a mentor? Because I have to keep growing.

Conclusion

GIPHY

Finally, I have to present a disclaimer about me and the concept of “developers as artesian” which is not a concept of mine, I’m pretty sure someone said it before, probably the guys from Etsy who have a pretty nice blog that you should check. It's called Code as craft and talks about how they arrived at some of the solutions they have implemented.

Once more, mentoring is a relationship that produces growth in two ways. Mentors and apprentices can grow from that interaction, and that’s something that we should do (and prepare for) more intentionally. Let’s be the mentor we needed when we started.

Replicating Strava's map snapshot service

Jafet Benítez — Wed, 20 Jul 2022 17:09:20 +0000

I have a while using Strava for my casual runs and something that always called my attention was the main feed of the app, where you can find a nice picture or snapshot of the path run by you or some of your friends. I initially thought that the application loaded a set of Geojsons and made a render for each one of the posts on run time, but after working with mobile maps in my own project I understod that rendering a map was no easy task for any device. I then noticed that every post had a capture of the route over the map and the feed wasn't too different from any social media post, nevertheless, I still had a curiosity about how we could generate those captures.

I recently found myself with some available time so I could start experimenting with this project and I'm going to walk you through my journey.

First things first: How to generate a map snapshot?

via GIPHY

My first step was trying to render a map and make a capture of that map. After browsing the web for a couple of minutes, I found a great article named Making Artistic Maps with Python, where the author teaches us how we can use Python to generate a high-quality map of any city.

After following the tutorial and making some tests, I noticed that the script required too much time between fetching information from Open Street Maps and processing the information. Taking into consideration the number of concurrent requests that Strava must receive I said to myself that It had to be an alternative that consumes fewer resources, and then I found Mapbox's statice Images API.

MapBox has a set of APIs that are sold as software as a service, but they allow you to generate a developer API key and even design your own map styles. The Static Images API, let you generate a completely customizable map. You provide parameters like coordinates, sizes, geographical objects (points, lines, polygons, etc), and others. In return, you get an image with the map you asked for.

The service works pretty smoothly, and after working with it I noticed that even Strava uses it (you can see MapBox mark in the footnote of every map), that definitely was a signal of being walking in the right direction.

import requests


API_URL = "https://api.mapbox.com/styles/v1/{0}/static/{1}/auto/{2}x{3}?access_token={4}"

...
request_url = API_URL.format(
    style_id,           # Map Style Ex. 'mapbox/darkv11' 
    polyline_hash,      # Polyline is alghoritm for hashing list of coordinates.
    width, height,      # Dimenssions of the image 
    token               # Access token provided by MapBox
    )

response = requests.get(request_url)

if (response.status_code == 200):
    open('map.png', 'wb').write(response.content)

else:
    print(response.text)

...

Let's get serious: Creating the service

via GIPHY

Once I got a pretty basic script for generating the maps with MapBox, I had to start thinking about how our service was going to work. I knew I had to receive a set of coordinates and maybe a couple of styling parameters but there were still two elephants in the room: asynchrony and scalability.

Since this will be using a call to an external service I couldn't rely on a synchronic execution for every HTTP call that our service is going to receive and the horizon just gets darker when you think about the failure possibilities given the number of requests and the common problems with networks. The answer was, obviously, I had to receive the request, close it immediately and then start processing the map in a new thread or background process, always taking into consideration that we have to be scalable. With that and the strategy of divide and conquer in mind, I concluded that my solution would need the components:

A web server that receives and validates the client's requests.
A queue manager that lists the validated requests.
A set of workers that reads from the queue manager and executes the processing.

For mounting that architecture, I couldn't imagine an easier way than using a Docker Compose (or Docker + Kubernetes) approach. That's how I ended up with a folder tree like the one below.

├───service
│   ├───nginx
│   └───src
│       └───map_equests.py
│       └───main.py
│       └───Dokerfile
│       └───requirements.txt
├───worker
│   └───src
│       └───helpers
│       └───worker.py
│       └───Dokerfile
│       └───requirements.txt
│
├───docker-compose.yml
└───.env

Conclusions

This solution is far from optimal, and I'm sure is not the only answer to this problem, but trying to figure out how to solve it in a revere engineering exercise has resulted in a pretty illustrating activity that I definitely recommend to any developer.

I have published the project on my Github account. You can find the repository here so you can dive deep into the code. I'm also living you some resources below that can help you in case you are working on something like this or maybe just looking for information about one of these technologies.

My personal notes about requirement elicitation in unideal situations

Jafet Benítez — Sun, 27 Jun 2021 02:13:41 +0000

via GIPHY

A common mistake in the development industry is not paying attention to the requirements (functional and non-functional). Requirement elicitation and analysis are the very first step in software development but sometimes, in a bad implementation of agile methodologies, we can lose focus of that and end up building the wrong software.

In an ideal case, you would have someone to talk with users and customers, observe them and later write down what the business is requiring. Then, that person would sit down with the technical team to analyze requirements, business rules and make a plan for the implementation and validation. But, as I said before that is “ideally” and in countries where software engineering and requirement engineering are still growing as is mine, sometimes you have to elucidate the requirements by yourself, analyze them and implement them with a very short deadline.

I remember my first job. I was a 19 years old junior developer in a government organization working in ERP for the financial direction. We were a small team with lots of work, so our manager decided to assign us to different modules and do the elicitation of requirements by ourselves; later, we would check out our notes in one of our daily meetings. Initially, I didn’t feel in an ideal situation because of my lack of experience and maybe I wasn’t, but we had to make it work.

I realized pretty soon that elicitation wasn’t as simple as I had thought during my classes in college. We had to deal with the short time of the actors, the ambiguity of the process, the actors with a tree-view mindset, and the resistance to change. Again, it wasn’t an ideal situation but had to make it work.

With time, I realized that rarely we can make an elicitation without troubles and that is ok, because, if the company hadn't problems they wouldn't have hired you to build the software in the first place. Through some time doing this kind of work, I have learned some lessons that I will leave you below. Anyway, if you want to go deeper into this topic, I highly recommend you to look at The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide). Said that, let’s go.

Review the same process with more than one actor.

The user or actor usually knows how to do his work, but does not always know how the company works or even what his partner is doing on the desk that is by his side. Actors may ignore what happens with the process after they deliver the record and that’s why you have to listen to the process from the mouths of as many people as you can find.

You may find some power users that know the company pretty well or employees that were there when the process started working in that way. They are pretty helpful and you should pay attention to them, but to find them, you have to talk to several actors and put the ideas together.

People may not be technical, so try to speak his language and don’t try to make him learn yours.

As a noob in the field, I made the mistake of talking technically to the actors. As an analyst, you have to avoid getting too technical about the implementation instead of talking with the actors in terms of the business or even better, in terms the actor can understand easily.

Better communication will get you more clarity. More clarity will lead you to better requirements and that will avoid having extra iterations or sprints because you already are making the right software from the beginning.

Identify priorities.

via GIPHY

During elicitation, you will find more than one trouble and probably more problems than what your team can handle at once. This is why you have to identify priorities and talk them down with the owner of the process and with your superior. And that leads us to the next lessons.

Validate your notes with a mentor and/or your superior.

This is probably more for people starting in the area. But even for experienced analysts, elicitation and analysis are more about having the right conversation with the right people than about having a brainstorm with yourself walking in circles in your office.

Receiving another point of view it’s critical when you are trying to make a work with quality.

Now, notice that I’m talking about having not just a superior to check your notes with you, but also a mentor. If you are starting in the area, you may have noticed that there’s a lot of things you can learn by yourself but what most people don't say is that a mentor can save you a lot of headaches. Don’t you have one? Get one.

Identify improvement opportunities.

The user and the client may tell you how they do things from the beginning of the time. They will describe the process they want you to systematize but they may lose improvement opportunities trying to be faithful to their day-to-day.

It’s probably not your work but take into consideration that before making a system for a process, the company needs to optimize the process. You can always take notes and communicate with them. Be proactive.

Remember your objective.

via GIPHY

It’s not just building software for the company, it's solving problems of the company through software, so ask for the problems. Ask the different actors not just what they do and how things should be, but ask them about what kind of things usually go wrong and what happens then.

Respect people. Process owner, user, or client you must respect them.

As we said before, while you are talking with several people you will notice that sometimes actors don’t have a holistic view of the company and its process and because of that, they may ask you for requirements that wouldn’t be right (mostly a matter of security). You will be tempted to make fun of the user and talk about “layer 8 problems”, or maybe of the client with something like “the customers know what they want but not what they need”, which may be true but you must have respect for them. The last thing you want is to have him as an enemy.

Remember that they aren’t supposed to know what you know. If that were the idea you wouldn’t have been hired.

What if people don't want to collaborate?

via GIPHY

Initially, I didn’t want to go into this topic, but while I was reviewing this article with my friend Vanessa, she told me that it would sound too idyllic if I didn't give any advice about hard people.

There are all kinds of people in this world and there are people that will not collaborate with your elicitation, actors that can even get angry with you doing your work. These people require you to go the extra mile for them and try harder to get their collaboration but remember that you have to do it with sympathy and amiability. I remember that my boss used to buy chocolates for hateful people and most of the time that helped to make them know that you are trying to give a service for the company and the employees.

Of course, if that doesn't work you will need to scale up the case or look for another person who can help you with that, but try to do that just as the last resource.

Conclusion

Finally, if there is something that I want you to remember, is that during elicitation you shouldn't fear finding troubles. Actually, you should try to remember that you are looking for the kind of problems that you can fix with software. Situations rarely are as we expected, they are not always ideal and that’s ok.