DEV Community: Eddy Ernesto del Valle Pino

Working remotely with a cargo cult

Eddy Ernesto del Valle Pino — Tue, 09 Mar 2021 12:02:12 +0000

If before all this (COVID-19) you worked a normal job in an office, for sure you spent a lot of time there and most of your daily social interactions where with people from the office.

Now that you have been remote for more than a year, do you have forced social interactions as part of your work schedule? to keep you being a team player and keep social cohesion at work? But nobody cares about this and people just go not to look bad, but this interaction are completely pathetic and forced?

I think companies should advice or encourage the people they employ to should find a social space somewhere else, so there is a more natural way to fill the void of social interactions with friends, neighbors or activity specific friends, not work related. Companies will have to evolve to to manage their project as opensource projects are managed. Distributed with async communication, like issues and pull requests or something like that.

I don't know for sure, these are random thoughts.

Focus and Forget Microservices!

Eddy Ernesto del Valle Pino — Fri, 01 Mar 2019 20:28:56 +0000

What are microservices for?

Scaling parts of the system independently
Scaling the engineering team so they can work "independently"
Keeping a separation of different contexts in DDD

All that comes with costs...

How do you organize an infrastructure that is auto-scalable, self healing and so on to run this microservices?
How do you organize an scalable infrastructure for your state storage? (databases, file storage)
How do you make sure and test that all this tiny pieces are talking to each other in the right and secure way?
How do you manage all the communication overhead of the team to deal with that kind of architecture?

If you are starting a business forget about microservices, your mayor concern is if there are people there outside willing to pay for your services or product and if you can create a repeatable business case.

Microservices are an optimization and if you do it early you know you are sinning. Do it when you need to, keep them in mind so you can do it later; but not when you don't know if you have to scale.

My only advice on early stage company microservice wise is: make a modular monolith.

Keep a clear separation of the bounded contexts in some kind of "modules" or whatever the technology you use supports. Always in the beginning of a company the context you are exploring changes a lot but that's fine, starting a company is a discovery journey, embrace it and be flexible.
Each module should be as full-stack as possible, containing its own piece of front-end, APIs, business logic and persistency layer.
Don't let modules interact with the internals of other modules, to communicate and pass information between them use APIs, events, smoke signals... I don't care, keep them together but not mixed.
Dependencies between modules are fine, but try to make them unidirectional, so if you start deleting the leaf modules of your system, it should continue to work just with less capabilities.

If you kind of follow this recipe you will be able (when you need to) to extract modules from your system and deploy them independently, specially the leaf modules because no one will depend on them.

If you have any other kind of experience about this, please share it!

Python beyond PEP8

Eddy Ernesto del Valle Pino — Fri, 19 Oct 2018 19:52:50 +0000

If you write Python and don't know what PEP8 is go and check it now.

PEP8 is the style guide for Python code and I think is quite good and I very much encourage people to put a linter + static analyzer as first step before running tests in CI/CD systems as a smoke test and keep things kind of tidy (at the micro level, I'm not talking about architecture here).

But this guide line lacks in some places where it promote styles that are fragile and could be improved:

Fragile indentation

This is a style that is acceptable by PEP8, but it is fragile.

# Aligned with opening delimiter.
foo = long_function_name(var_one, var_two,
                         var_three, var_four=4)

Something is fragile when it breaks easily, and is quite easy to break this indentation by changing the name of foo or long_function_name and instantaneously this the parameters in the second line would be miss-aligned.

# Aligned with opening delimiter.
foo = refactoring(var_one, var_two,
                         var_three, var_four=4)

There are some editors that will correct this for you automatically but not everybody has those. Also sometimes I find abandoned code like this from someone who had to escape a building on fire or something.

And is not very pleasant when long function calls are together looking something like:

# Aligned with opening delimiter.
foo = long_function_name(var_one, var_two,
                         var_three, var_four=4)
barf = another_long_function_name(var_one, var_two,
                                  var_three, var_four=4)

Where the amount of spaces is irregular even when semantically both lines are at the same level. Is just visually misleading.

If we just listed the parameters of the function one per line with trailing commas:

# Aligned with opening delimiter.
foo = long_function_name(
    var_one, 
    var_two,
    var_three, 
    var_four=4,
)

In this case when you change the name of the function, remove or add parameters, or change the name of the parameters the rest of the indentation is not broken. If you add a new parameter or remove one, the diff for code review will show as a single line change per parameter modified:

 # Aligned with opening delimiter.
 foo = long_function_name(
     var_one, 
     var_two,
-    var_three, 
     var_four=4,
+    another_var=5,
 )

Very nice and easy to identify changes when you do side by side comparison.

Line continuation and breaks

In Python if a line is too long you can use \ to continue in the next line. In my personal taste this looks kind of ugly and you always need to keep in mind all those breaks in imports for example:

from django.db.models.expressions import Case, Exists, Expression, \
    ExpressionList, ExpressionWrapper, F, Func, OuterRef, RowRange, Subquery, \
    Value, ValueRange, When, Window, WindowFrame

If you have to delete or rename things there, the indentation length of the lines will look funny and you may have to wrap the whole text and re-arrange all the backslashes.

So why not to use parenthesis as a grouping mechanism, like in math:

from django.db.models.expressions import (
    Case, Exists, Expression, ExpressionList, ExpressionWrapper, F, Func,
    OuterRef, RowRange, Subquery, Value, ValueRange, When, Window, WindowFrame,
)

Or also:

from django.db.models.expressions import (
    Case, 
    Exists, 
    Expression, 
    ExpressionList, 
    ExpressionWrapper,  
    F, 
    Func,
    OuterRef, 
    RowRange, 
    Subquery, 
    Value, 
    ValueRange, 
    When, 
    Window, 
    WindowFrame,
)

I don't like this last one because is too long and usually imports don't change that often, but this last style is also acceptable and has all the advantages of the example 1 I showed above, is refactoring proof.

When calling something too long

posts = (
   Posts.objects
   .exclude(author=user)
   .filter(title__startswith='hellow')
   .first()
)

When having a long if:

if (not previous_is_grouped
        and not prev.has_two_images
        and nextone
        and not nextone.has_two_images):
    do_evil_stuff()

Here I don't like the break in continuation between the first line of the if and the rest but it's fine.

Also when doing long list comprehension:

double_of_evens = [
    x * 2
    for x in range(100)
    if x % 2 == 0
]

The lines are for: mapping, iteration and filtering.

Closing

General style guidelines for a language and a whole community are amazing and I love it. But don't be blind, if you really think there is a real reason to do things a little bit better take that step.

Think about all the abandoned code of people that had to flee buildings in flames. LOL 😂.

Priority smells and professional ethics (part II)

Eddy Ernesto del Valle Pino — Sun, 19 Aug 2018 14:54:40 +0000

If you didn't read the first part go there and read so you get some context.

So to know what to do next and in which order to execute, you will have to know how much value and effort takes each of the goals you want to achieve. After you have this clear you can classify them in 4 groups and this method also helps you to prioritize tasks. Identify for your business what are the most valuable things that you can do without complicating things too much.

High value / low effort

Quick wins, but don't confuse them with "quick & dirty" solutions. Quick wins are well developed, tested, consistent with the current architecture and simple modifications that you can apply and get a lot of benefit from. They don't introduce a lot of complexity but will give you a lot of value. This are the first tasks you need to attack.

What doesn't classify here?: a hack. If your quick solution, creates a problem for later, even if it looks like low effort execution now, i twill complicate things in the future, and when this "hacks" accumulate they will come for you in the more inadequate moment and hit you where it hurts the most.

High value / high effort

As this game is not always about taking the low hanging fruit. There will be complex features that will introduce complexity and need a lot of time to complete because they need to get done A, B, C, D and E. But they are business critical, and you have to get them it doesn't matter what. How to work on this ones? How to deal with them?

My advice, is evaluate if you really need the to go that path. Be careful, do your clients will really benefit from this features? are those existing clients and you need this to keep them? or are those "imaginary clients"? Existing clients are usually more valuable than potential or imaginary clients. Don't go into this kind of tasks because the sales team is pushing you, or the CEO came with a great idea, or whatever else... Use as much factual data as you can to decide if you really need to execute this.

But if you really need this task done don't lay down a 3 month plan or something like that. Specially because complex tasks have a high level of uncertainty and you have no clue on how to estimate them and you don't have a clue on how to do whole trip to the end. So, select the simplest and more independent thing that the team can work that will lead you in the goal direction. If you have clear intermediate milestones well, good for you... but sometimes I personally had not, I knew what I wanted at the end but was not until I started working that I was able to identify what was the next step to slowly climb to the top. So, if you don't have everything clear, that's fine, just keep an open mind in case you have to abandon or change path on the way there.

Very important for me is that this tiny milestones can be deployed to production when they are completed even if they don't make too much sense by themselves alone and that they are small, sometimes just a few hours of time, a day or two. But having something in production quickly gives you immediate feedback and that's very important to change course if you have to.

In this case I don't do any kind of estimates, because long tasks will be interrupted by smaller ones that will be interleaved, because you can't stop time and work for 3 weeks in a bubble; things will happen and that's fine. So, if your boss asks, just be sincere: You have no clue, but you will work towards the goal until completion, and you have this clear milestones, and you should have at least something small to show soon. I had done this, some people don't like it, but I prefer not to lie and pretend to be a know-it-all.

Low value / low effort

This tasks usually are not part of the critical path towards success. But are nice to have. My advice is to use them for people joining the team. Is very nice to come to a new job and that same day get something out in production. Also they are good for training interns or mentoring junior developers or keep a senior engineer from being bored or tired of working in big stuff. This kind of tasks are usually refreshing to do. So this ones are not a big deal.

Low value / high effort

Just don't! No, no, no... Don't! Even if someone tells you that is very nice to have, if you know that the cost is way higher than the benefit just don't... This tasks have overall negative impact. It is preferable to have a simple system than a complex one, it will make you fast, have a happy team, reliable software.

Wrapping up

Keep in mind every time you make a commitment your boss will hold to it and will come for it later. So, try not to make many commitments... just work and deliver valuable chunks of work, always open to the needs of the organization and the business. If you are not lazy you will achieve what you want, it just takes time to build things in the right way and make the process sustainable so there is a tomorrow after you complete a goal.

Remember that working producing software is a very very long way, you will have to maintain that software probably until no one uses it. So is not a race, is not sprints (specially not the SCRUM ones), is a marathon. Your software needs to adapt and be flexible. Don't let someone that doesn't work in your code base push you to screw it up, or negotiate with you and your team time with your family and friends, your nights and your life.

Keep it cool!

Priority smells and professional ethics (part I)

Eddy Ernesto del Valle Pino — Wed, 15 Aug 2018 18:56:39 +0000

For me there are two major smells when it comes to prioritization, and you can identify them by asking someone «What are the most important tasks we should work next?», if this someone answers:

«Everything is important!», that person is lost, does not get the business, the product, the clients, will harm the team and the company.
«What are the easiest to complete?», again, this person is lost, does not get the business or doesn't care and is just there filling a hole. Going for the low hanging fruit without understanding the value of completing a task is quite bad.

To know what to do next, in what order and when; you need to know two things per task or goal:

Effort: How much costs/effort/work takes to make this change to the system.
Value: What is the value it brings to the clients, business, users. Are they going to use this feature?

Effort is complicated, it is the work required to take the system from one state to another. That implies too many things: how complex is the system, how complex is what you want to do, how well trained in the system is the person that will perform this task. Keeping a system simple and flexible helps a lot to keep the amount of effort low.

Value is dangerous, specially if you guess. If you think that "putting that text to the right is more effective for your customers" but you don't have data on this, you are guessing... and that's fine but if you are going to get into a complex task you better make sure that you are taking this decision base on data and not guts.

Take into account also that every modification you apply to a system changes it's complexity and value that it delivers. Also it takes some time to implement correctly, the more simple something is the less time it will take to execute and integrate harmoniously with the rest of the system. The ideal would be minimize complexity and maximize value in the shortest time possible, but there are few cases when this actually happens.

So basically the only thing we can do is to trade simplicity and effort for value. If something will introduce a ton of complexity in your system but not added value, it has a negative impact. Because complexity makes the system harder to change in the future, probably adding rigidity and more cognitive load on the developers. So that kind of changes is better not to do them, except you intentionally want to harm your company.

Remember always that you were hired not to get things done, but because you ultimately know, you know everything inside out. You are there to say NO and stand. Because if you don't say NO, who is going to say it? You are there to get things done but also to prevent the non-technical people from killing the company, don't be a yes-person.

Some managers would get angry at you about this, but please explain your self, explain the tread offs.

Check part II here.

On dealing with deadlines and estimates

Eddy Ernesto del Valle Pino — Tue, 14 Aug 2018 22:22:07 +0000

Don't let your self be pushed. Don't let your superior (CEO, CTO or whatever) come and negotiate with you a deadline. Deadlines are just wrong to begin with, and negotiate one is a very bad idea, picture the following scenario:

Hey when you think you will have X done?
In 2 weeks.
2 weeks? No way... it needs to be done by next week.
Well....

Bad, physics can't be violated. At the very moment you just consider yielding in a work/time negotiation you are screwed and you are not being professional. You know since a feature is being started in development that that you need testing for it, some minimum acceptance test, may be some degree of integration test, also there is infrastructure management deployment, check how it integrates with the rest of the components, check with the product owner if this is what they wanted and they put it in production and hope people use it. All that is like washing your hands when you are a doctor and you treat a patience.

You know you will need the time you said to go the whole round trip. So, why in this world are you considering to yield and make yours and your team life miserable? Not just in the short therm but also in the long one. You know well that when something is poorly designed or tested it will come for you later on. Because you will forget about this, but the code base doesn't forget.

Also that sets the ground for upper management to come again in a week and ask for another impossible. So, next time some one tells you to do something in half of the time, ask immediately for double of the money... that probably helps to stop them for asking for your free time :)

Any way, you may say: «But if there are no deadlines, what there is?» The answer is simple: «Goals», you decide what you want achieve and you just work towards that until you get there. That's it... «Ok, but what about time estimations? What management will do to plan stuff?», just don't do it... make up any crazy estimates, anyway estimates are lies we tell our self and then they get us into serious trouble. If you give a crazy time for completion and you are earlier no one will get mad at you. In the end this are estimates, but keep in mind that management love to take them as promises you made them and they will made you hold to them like if they were written on stone and not as an "estimate".

«Ok, I don't set deadlines and I give crazy estimation times, but how do I plan?» For planing and deciding what to do you need to work like a scheduler, yes, the ones that computers use, for sure you know some of them... I like to use something like a "Time Budgeting Scheduler", and it works like this:

Per each goal decide what's the maximum time it is worth to complete that goal for the business given it's value.

Examples:

Goal: We need our traffic lights not to have more than just one light on at the time.
Value: It will be confusing and cause accidents if this is not working properly.
Budget: All the time in the world, this is super important for the project to work.

Goal: There should be a way to go back to main screen after changing password.
Value: Users don't get lost after changing password
Budget: 1h, users could go back to main interface by clicking "home" in the navigation bar, if it takes more than 1h to add a "Back" button or something to go back is worthless to spend time on this.

Given that any estimates we do are usually too short for the real life execution:

If your raw estimate for any of this goals is more than the time budget on them, just don't work on them. Because is throwing resources away and wasting time and money.

If your estimates is bellow or equal to the budget you set, then it worth trying. If you deplete the time budget, re-evaluate if continuing or aborting the mission right there.

This will help you to decide if a task is feasible and you can use the time budget as the estimate you give to your boss.

Wrapping up

You are in control, don't let anyone put pressure on you, be professional. Tell me about your own experiences related to this and there will be more coming soon in how to deal with prioritization.