DEV Community: Andrea Canton

Smart laziness

Andrea Canton — Thu, 09 Mar 2023 07:16:23 +0000

Have you ever sped up your pass (or even start running) when you see that someone is passing through the door that you’ll pass? Even if the person is holding the door, you started before thinking “I don’t want to re-open the door”.

I’ve done it, many times. In most cases, this is not very smart.

I’d prefer spent energy now (maybe more energy) instead of re-open the door.

My fiancé after dinner, if she has to do dishes, prefers to lay on the couch for some minutes, then after a while get up and wash the dishes.

I think is very difficult to get up, so when is my turn I wash dishes and then I lay down.

Both behavior I think are lazy. I think mine is smart laziness. (I love you anyway, Marta)

Since I started working in companies, as a developer, I always had to track in some kind of software or excel files, how much I’ve worked on which project or client, or ticket. In Italy we call it consuntivazione, context-reverso translates it into final balance. I don’t trust always the internet, but I hope that now you understand what I’m talking about.

This operation for most of my colleagues is a nightmare. It is, but I prefer to do it every day, or even two or three times a day.

Most of them prefer to do it at the end of the month to enter all of the data they may be written on a TXT on the desktop, or reading through their commits. Maybe they are on holiday and have to do it from the beach (or mountains).

I think I don’t understand this kind of laziness. But most of the time I don’t even realize how not-smart-lazy I am, even when I’m running towards a closing door.

Is lazy to do effort now than later? I think is yes.

Is smart to do an effort now than later? Mostly yes.

I want to talk about laziness because last week my boss tell me that he wants me to do a two hours speech to my colleagues about test automation.

I’ve read many articles and books on tests. I’ve done some testing in my personal projects, but I’ve NEVER written tests in a company environment. That scares me the most, but I’ll be honest with my colleagues and I hope that the speech starts a conversation or even a debate.

Doing test automation is smart laziness, but instead, I’ve always thought that doing F5 multiple times on Visual Studio was more efficient.

Is not.

Is easy to write most of the documentation of a project during or after completing it? You know the answer, but your mind hopes that postpone the pain hoping that problems never come up. But you struggle with all the support and training your client demand on a not well-documented software.

And you end up that you have to spend more energy even if you never write documentation.

I’m not smart-lazy, but I hope that this article starts a conversation or even a debate.

Always over estimate effort

Andrea Canton — Thu, 26 Jan 2023 12:32:49 +0000

Developers solve problems no one have tried to solve before.

Trying to estimate how much time require to solve this problems is a guessing-game, is like gambling.
Gambling is risky, so estimates should be superconservative.

Like gambling, you think you are good, because sometimes you get it right.
But you are not, you are only lucky.

As a developer, even as a junior developer, you are responsible for the quality of the code, but our job is full of pitfalls.
We have to check performance, maintainability, security and many other subjects.

If the persons who asked you the estimate say that is too much, remember they asked you, and if they needed a different answer they shouldn't ask you in the first place.
If they need it in less time you can discuss the timing, of course, but the responsibility of failure is not all on you, at least is shared.

Moreover, clients/PM/Product owner/etc. not always need all your work in short time,
you don't need to demonstrate always how quick you can be. Speed of delivery is not the only metric that matter.

Exaggerate estimate help you to keep calm and experiment various design pattern.
If you think that they don't give you time to do unit tests, refactor, clean tech debt, remember that are you that say the estimates.

So when you give yourself the chance to have some extra-time, you can really improve your codebase, and deliver very high quality code.

Thirty minutes can be enough to make significant improvements.

What is a better time to refactor a feature that anyway will be tested? You decide. You have the power to find time to improve the code.

Inspiration for this article, other than personal experience, is this talk by Allen Holub, where he says that doing estimates is stupid and you should not do it. I agree with him, but I'm not a CSO (Chief of Something Officer), I'm a senior developer of a company where I don't have the option to don't give estimates.

I hope this article start a discussion and help me and some of you to better manage this itchy argument.

Simple writing text animation

Andrea Canton — Thu, 24 Dec 2020 07:00:58 +0000

I just tried to create a simple writing text animation using css and vanilla javascript.

The text indicator is pure css using @keyframes in loop. The writing effect is done by using a setInterval.

An improovement that it came to my mind is to change the interval every time and increment to one second if I encounter a period.

Do you think I can do better?

AHA Programming vs Single Responsibility Principle

Andrea Canton — Fri, 12 Jun 2020 08:32:20 +0000

In the Hero35.com's newsletter, I've stumbled upon this video on AHA Programming, where Kent C. Dodds tries to explain this new principle he created. The minute he starts to code I said "AHA!", but not for the same reason Kent intended. Yes, because I think he missed some more important principles in programming.

First things first, what the heck is AHA Programming?

AHA stands for Avoid Hasty Abstractions, from Kent's blog post we can summarize this way of thinking in two points:

Prefer duplication over the wrong abstraction
Optimize for change first

So far seems some good points, maybe out of the ordinary, but I encourage you to read the article or at least watch the video before continuing. Or you can just trust me, I'm not judging you!

In the presentation, Kent is showing an example where there is a frontend application that displays the name of a user in multiple places.
In general thinking a developer builds an abstraction by creating a function, say, getDisplayName(user), so if there is a bug in the behavior you'll fix it once and it repairs everywhere.

Kent brings the case when the client or stakeholders ask you to add the honorific to the name on the profile page. It always happens, it's in the software nature to change in time. The example goes on to the point every place where the name is displayed has different behavior. Kent says at this point a developer tent to don't dismantle the abstraction, instead, prefer to add flag parameters to the function/module/component to accommodate new behaviors.

I can agree that a medium level developer has this type of mindset. I also agree that removing the abstraction is a great choice instead of making a wrong abstraction. But I think the same result can be achieved easily following other old good programming principles.

Let me explain.

I recently read the well-known book on software development Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin - I C. a pattern here! It's quite inspiring, it also helped me to improve the quality of my code significantly and my supervisor noticed! You should totally read it once in your life, maybe not too early in your career: just to see enough of what the real world is made of to better understand what Uncle Bob is pointing out.

You can imagine in this book there are a lot of rules and examples of writing code. A lot. I can say principles wrote there are hard to discredit.

One of the main rules that it came out most frequently is the Single Responsibility Principle, a.k.a. SRP, that states that every module or class should have responsibility for a single part of the functionality provided by the software and that responsibility should be entirely encapsulated by the class, module, or function. Uncle Bob summarize in this sentence: "A class should have only one reason to change."

In the Functions chapter, Martin says that a method should do only a task and avoid flag parameters. If there is an if or a switch create two or more method methods if you can.

So back to the issue presented by Kent: we could address the problem by creating another function named getUserNameWithHonorific, so if after a while the name of the user became different in every place we have different functions and is easier to disassemble the abstractions if we see they're a lot and used only in one place. It's easier because you don't have a huge single function that's hard to understand, instead, you have more functions that explain what they do in the name and made by few lines of code.

Conclusions

Dodds' AHA principle is not wrong, but I think that doesn't add anything new, plus it doesn't simplify the comprehension. You can agree with me that you can't define precisely wrong abstraction, it's open to interpretation. Instead, you can more clearly identify functions or components that have more than one purpose.

I think that the parametrization of software has to stay in the higher levels of abstraction, such as abstract classes of a library, the main component of a frontend widget. Only one main switch and different modules/components that do only one thing, so if a change will come - and it will - you edit only one module or create a new one.

Now tell me what you think. I'll be pleased to discuss it!

Cover photo: taken by me last week in a forest near Corno d'Aquilio

GIT Mantras you should know

Andrea Canton — Wed, 19 Feb 2020 12:03:42 +0000

Photo by Simon Migaj on Unsplash

DISCLAIMER: This post is not the Bible, is my personal opinion, feel free to comment if you disagree.

I wrote the first line of code in 2007 and one of the main tools I used over the years is GIT. I studied various ways of thinking and encountered many problems caused by misusing this fundamental tool. So I wrote some thoughts I learned on the field, hopefully, to help you to be more confident and professional.

Use a VCS even if you are the only coder

The first job I had was a mess from many points of view. One of those was they don't use any version control system. The excuse of the head developer was "we are only in three and work always on different projects". He didn't understand that GIT (or other VCS) works as a time machine for your code and is useful even if you are the only coder in the team. And if you're asking: yes, it happened we have to work on the same project, in a rush.

Make useful commits

You should treat your commit like you treat your code (assuming you want a clean code) because if you don't keep neat your commits and branches, your repository became useless and unreliable.
One of the most trendy GIT 'motto' is Commit Early And Often.
I think a better rule can be: Make frequent commits with a short description. Even more precisely:

The first line of commit should be less than 50 characters, in plain English and should describe an action in simple present. Should not contain words like "and" or "+", in most cases you should split into two commits.

Examples:

add about page file
implements contacts saving logic
remove commented code in invoice service
intent code in the database config file

Of course, your commit should be as descriptive as possible. I've seen a lot commits with only written "wip" or "fix": please, simply don't.

Ok thanks, but how can I do those commits???

Don't be afraid to use a graphic interface (GUI)

I'm a huge fan of GIT CLI, I mostly use it but in some cases, I use an interface to easily select which files (or even lines) to commit. Instead to use git add -p
Yes, because frequent doesn't mean to commit every five minutes. When you are in a rush, or you are focused to solve a problem, you can easily forget to commit early and often. So when you notice that, you can open your GUI and make your commits.

It doesn't matter if a test is failing or your branch is broken. Unless you are on the production branch, it's better to have more descriptive commits that can help you to debug or find a deleted feature, than working commits.

Here some GUI i've used/use:

Sourcetree
GitKraken
VSCode
Visual Studio have a simpler but useful interface ()

Why I should use English only for my commits?

Let's take an example, a realistic example.
Your job is in a firm that produces e-commerce websites for other clients in Magento. At some point tons of work arrive and you and your team can't keep up to developing a lot of code. So your boss decides to hire remote developers from India.
Now your code and your git have to be read from foreign developers. Imagine if the code and git commits are all in Italian/Spanish/German/French/Finnish/etc. You and your team will be poked every minute by your foreign co-workers to explain your repository.

Another plus is English is usually shorter and without special characters.

(en) "add about page file"
(it) "aggiunge il file della pagina chi siamo"
(es) "agrega el archivo de la página sobre nosotros"
(de) "fügt die Auslagerungsdatei über uns hinzu"

(en) "implement contacts saving logic"
(it) "implementa la logica del salvataggio dei contatti"
(es) "implementa la lógica de ahorro de contactos"
(de) "implementiert die Logik des Speicherns von Kontakten"

Use distinct branches for each feature or issue

I suggest you should use GIT flow to manage your feature/issue branches. So you can experiment on a new feature, without losing the chance to make a hotfix on the production branch (master).

Look at this article for more informations

Repeat with me: `git pull --rebase`

When you work in a team on a single branch (like a release branch) it happened quite often that you make a commit but someone pushes another commit before you, so you should pull before pushing. If you don't use the --rebase flag, git will create a merge commit, a useless and confusing merge commit.
Instead, if you use the --rebase option that's what occurs:

your commit(s) is(are) put aside
the remote commits are pulled
(one at a time) your commit(s) is(are) applied on top of the updated branch
if conflicts occur the rebase stop, you solve the conflict and stage the files, then launch git rebase --continue
if there are no more commit finish, otherwise return to point 3.

Most of the time I never solve conflicts, so the rebase goes straight forward and then I push my commit(s). Notice that the conflicts part will have occurred anyway with the standard pull/merge process.

There are some negligible downside of this practice: all the timestamp of your commit(s) will be updated when you do the rebase if you have more commits you may have to solve conflicts every time a commit will be applied. Anyhow in most cases, you push commits after you make it, so those problems are almost irrelevant.

Ok but why should I care?

If you care you sound more professional and you'll benefit in the future:

You can delete all the commented code sure of cherry-picking from the past if the client wants a feature back.
You can easily debug your code with git bisect.

If you found this article useful, please consider sharing this article with your colleagues.

Like this article, if you like it! Feel free to say how crazy I sound on twitter.
There aren't stupid questions or comments: let me know your GIT mantra or your best practices, I'll respond to all of your comments!

I made some dots for a slider, Instagram style

Andrea Canton — Thu, 09 Jan 2020 13:51:51 +0000

I'm currently working in a firm who develop software for utilities company (distributors of energy, gas and water). I'm in the web development team and I'm currently building an app (using capacitor) where final customer can check and pay bills, consumptions, send self-readings, etc.

I had to build an horizontal slide for the last bills, so this slide can have more than 10 elements in it. The problem was they want some indicators on the bottom, so I tought about instagram dots indicator.

Premises

The slider is made with an horizontal CdkVirtualScroll (see the docs) element and work fine in mobile because you can drag the slides without adding javascript, plus it optimize the memory usage. The example is very semplified but the indicator component is the same I use in my project.

The code

I've made a component for the dots that mutate according the length and the current index. Note that works also for infinite scrolling with the length changing while scrolling!

The solution was to listen to changes with ngChange functionality and change the class of indicator elements. Then set the css to make smooth transitions.

Try it out with your phone in device mode with Chrome dev tools.
https://instagram-dots.stackblitz.io

Hope I've help someone, I'll read and respond to all of your comments

Please use huge font on your editor

Andrea Canton — Fri, 02 Aug 2019 14:01:59 +0000

I've been a developer for over a decade. I've to confess: my desk isn't tidy. But the virtual enviroment is near-perfect and I want to improove it everyday.

Thats some of my routines to keep my virtual workspace clean:

remove git merged branches
remove useless commented code, because there is GIT to remember old code.
refactor long files in shorter one.
remove useless thing from my editor (like sidebar, toolbar) for encourage me to use keyboard shortcut (like CTRL + P)
editor with a dark theme and a 16px font with a 30px line height (not that big, I've seen bigger line height, eg. Jeffrey Way in laracasts)

On this last particular topic some of my colleagues use to make fun of me by saying that my editor seem for visually impared people. Some of them use font 10px or 9px or even lower!

But I think this setting have two advantages:

It's better for my eyes
It discourage me to build huge unmanintainable files

Tell me what you think about it or tell me your routine!