DEV Community: Yuri Sales

Utilizando o módulo Motor Fan L9110 com Arduino

Yuri Sales — Wed, 27 Aug 2025 04:15:10 +0000

O que é?

O Motor Fan L9110 é um módulo pequeno e de baixo custo muito utilizado em projetos de robótica diy, especialmente em projetos "bombeiros" visando conter pequenos incêndios.

Ele atua como um intermediário entre um microcontrolador (no nosso caso, o arduino) e o motor do ventilador, permitindo que você controle tanto a velocidade de rotação da hélice quanto a direção. E isso se dá por causa do circuito L9110 que ele possui, constituído de duas pontes h.

Ao aplicar uma tensão em um motor de qualquer uma das duas direções,o usuário é capaz de direcionar a rotação da hélice. Tudo isso graças ao circuito eletrônico da ponte H.

Como funciona?

Podemos ver que o módulo possui 4 pinos de conexão:

VCC: conectamos este pino na tensão de alimentação do Arduino. No caso deste módulo, 5v.

GND: terra. Conectamos ao GND no Arduino.

1 NB e 1 NA: são os pinos de controle. Cada um é conectado em uma saída digital no Arduino. É neles que fazemos o controle de direção. Se definimos a saída de um deles como HIGH e o outro como LOW o motor rotacionará para um lado e vice-versa. Se ambos possuírem o mesmo valor, a hélice ficará parada.

Mão na massa

Vamos criar um circuito em que controlamos o funcionamento do nosso mini-ventilador com um
potenciômetro. Quanto mais eu girar o pino do potenciômetro em sentido horário, maior será a velocidade de rotação do motor.

Para criar este projeto, você precisará de:

1 Arduino Uno
1 Potenciômetro
1 Protoboard
1 Motor Fan L9110
Alguns Jumpers

Vamos primeiro conectar nossa fonte de tensão (5V) e o terra (GND) na nossa protoboard.

Conectemos o pino central do potenciômetro na saída analógica A0 do Arduino. E, respectivamente, o GND e o VCC na protoboard.

O pino A0 da placa é uma entrada analógica, ou seja, é uma entrada que entende sinais analógicos e produz uma tensão variável a partir do valor enviado.

O potenciômetro é um resistor variável. Conforme giramos o seu eixo, a resistência é alterada, consequentemente, alterando a tensão de saída que ele envia para a placa, variando entre 0V e 5V.

E, para finalizar o nosso circuito, vamos adicionar o nosso Motor Fan L9110.

O pino 1 NB será conectado na saída digital 9. O pino 1 NA no ground, já que queremos movimentar nossa hélice apenas em uma direção, e os outros no ground e no VCC.

Vamos agora adicionar este código na sua IDE do Arduino e executar.

Um adendo quanto à definição do targetSpeed: o potenciômetro lê valores entre 0 e 1023. Entretanto, a função analogWrite() só aceita valores entre 0 e 255. Portanto, é necessário que um mapeamento seja feito para a escala suportada pela função.

O delay é apenas um enfeite para termos uma transição mais suave durante as mudanças de velocidade.

Fim! Obrigado pela leitura!

Uncovering Generative Artificial Intelligence and LLMs: A Brief Introduction

Yuri Sales — Sat, 02 Mar 2024 23:00:20 +0000

With the popularization of tools such as ChatGPT, Google Bard (currently Gemini), and other similar applications, which generate responses based on what the user asks, the machinery behind these innovations also came to light.

We call the set of these technologies Generative Artificial Intelligence. Generative AI is, under the hood, algorithms that generate content based on patterns recognized in previously learned data.

Different from other categories of Machine Learning, Generative AIs work by synthesizing new data instead of just predicting and making decisions.

With the evolution of statistical models and analysis of linguistic patterns since the 80s, with the advancement of Machine Learning algorithms, along with the exponential growth of data and information from the internet, combined with the increase of the storage capacity with technical improvements and cheaper hardware, Generative AI has become more feasible.

The LLMs (Large Language Models) emerged from this reality of abundant data. They are Machine Learning models focused on working with Natural Language Processing, that is, processing, understanding, interpreting, and generating human language.

With a vast amount of data learned, the LLMs can detect existing patterns and relationships between the words in a given sentence.
From there, they are able to make predictions of the possible next words, generating more meaningful answers.

The applications of LLMs are diverse, from developing dialogues to generating text, code, images, audio, video, and much more. You can also use video, audio, and image as data input.

Today, it's possible to utilize LLMs to create chatbots and virtual assistants, code generators and correctors, sentiment analysis, text classification and grouping, translation, summarization, you name it.

The future of Generative AI promises even more improvements and possibilities, evolving how we interact and utilize the technology in our daily lives.

Please share this post with your friends.

References:

Large Language Models (LLM) - Databricks
Generative AI with LangChain - Ben Auffart
Desenvolvendo aplicativos com GPT-4 e ChatGPT - Olivier Caelen e Maria-Alice Blete

#14 Mentoring, Apprenticeship, and Craftsmanship - Tips from The Clean Coder

Yuri Sales — Sun, 11 Oct 2020 12:55:43 +0000

This is the last article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the last chapter.

I have been consistently disappointed by the quality of CS graduates. It's not that the graduates aren't bright or talented, it's just that they haven't been taught what programming is really all about.

Degrees of failure

Not all CS graduates are disappointing - far from it! However, I've noticed that those who aren't something in common: Nearly all of them taught themselves to program before they entered university and continued to teach themselves despite university.

Now don't get me wrong. I think it's possible to get excellent graduation at a university. It's just that I also think it's possible to wiggle yourself through the system and come out with a diploma, and not much else.

And there's another problem. Event the best CS degree programs do not typically prepare the young graduate for what the will find in the industry.

Mentoring

There are several ways to learn things. You can learn by reading manuals written by other developers (you can include here documentation, tutorials, articles, you name it). You also can learn by observing people doing their job, and so on.

I would have been far better if I'd had a mentor, someone to teach me the in's and out's. Someone I could have observed while I helped him with small tasks, and who would review and guide my early work. Someone to act as a role model and teach me appropriate values and reflexes. A sensei. A master. A mentor.

Aprenticeship

What do doctors do? DO you think hospitals hire medical graduates and throw them into operating rooms to do heart surgery on their first day on the job? Of course not.

Somehow the software development industry has gotten the idea that programmers are programmers, and that once you graduate you can code. Indeed, it's not at all uncommon for companies to hire kids right out of school, form them into "teams", and ask them to build the most critical system. It's insane.

Let's do not kid ourselves that this doesn't matter. There's a lot at stake. Our civilization runs on software. It is software that moves and manipulates the information that pervades our daily life.

Given that we entrust software developers with all aspects of our lives, from the minutia to the momentous, I suggest that a reasonable period of training and supervised practice is not inappropriate.

Software apprenticeship

So how should the software profession induct young graduates into the ranks of professionalism? What steps should they follow? What challenges should they meet? What goals should they achieve? Let's work it backwards.

Masters

These are programmers who have taken the lead on more than one significant project. Typically they'll have 10+ years of experience and will have worked on several different kinds of systems, languages, and operating systems. They maintain that technical role by reading, studying, practicing, doing, and teaching.

Journeymen

These are programmers who are trained, competent, and energetic. During this period of their career, they will learn to work well in a team and to become team leaders. They tend to learn one language, one system, one platform; but they're learning more. As they gain experience, autonomy grows.

Apprentices/Interns

Apprentices have no autonomy. They're very closely supervised by journeymen. At the first they take no tasks at all, they simply provide assistance to the journeyman. This should be a time of a very intensive pair-programming. This is when disciplines are learned and reinforced. This is when the foundation of value is created.

The reality

All of this is idealized and hypothetical. However, if you change the names and squint ate the words, you'll realize that it's not all that different from the way we expect things to work now. Graduates are supervised by young team leads, who are supervised by project-leads, and so on.

The problem is that, in most cases, this supervision is not technical! In most companies there is no technical supervision at all. Programmers get raises and eventual promotion because, well, that's just what you do with programmers.

The difference between what we do today and my idealized program of apprenticeship is the focus on technical teaching, training, supervision, and review. What's missing from our current sterile approach is the responsibility of the elders to teach the young.

Craftsmanship

To understand, let's look at the word craftsman. This word brings to mind skill and quality. It evokes experience and competence. A craftsman is someone who works quickly, but without rushing, who provides reasonable estimates and meets commitments. A craftsman knows when to say no, but tries hard to say yes. A craftsman is a professional.

Craftsmanship is the mindset held by craftsman. Craftsmanship is a meme that contains values, disciplines, techniques, attitudes, and answers.

Convincing people

How do you get people to adopt the craftsmanship meme? Remember that a meme is contagious, but only if it can be observed. So you make the meme observable. You act as a role model. You become a craftsman first, and let your craftsmanship show. Then just let the meme do the rest of the work.

Conclusion

School an teach the theory of computer programming. But school does not, and cannot teach the discipline, practice, and skill of being a craftsman. Those things are acquired through years of personal tutelage and mentoring.

Previous article: #12 Collaboration

#13 Teams and Projects - Tips from The Clean Coder

Yuri Sales — Sun, 04 Oct 2020 20:01:58 +0000

This is the thirteenth article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the thirteenth chapter.

What if you have lots of little projects to get done? How should you allocate those projects to the programmers? What if you have one really huge project to get done?

Does it blend?

It makes no sense to tell a programmer to devote half of their time to project A and the rest of their time to project B, especially when the two projects have two different managers, different business analysts, different programmers, and different testers. How in Hell's kitchen can you call a monstrosity like that a team? That's not a team, that's something that came out of a Waring blender.

The Gelled Team

It takes time for a team to form. The team members start to form relationships. They learn how to collaborate with each other. They learn each other's quirks, strengths, and weaknesses. Eventually, the team begins to gel.

There's something truly magical about a gelled team. They can work miracles. They anticipate each other, cover for each other, support each other, and demand the best from each other. They make things happen. The team should be composed of programmers, testers, and analysts. And it should have a project manager.

Fermentation

It takes time for a team like this to work out their differences, come to terms with each other, and really gel. A gelled team will plan together, solve problems together, face issues together, and get things done.

Once this happens, it is ludicrous to break it apart just because a project comes to an end. It's best to keep that team together and just keep feeding it projects.

Which came first, the team or the project?

Banks and insurance companies tried to form teams around projects. This is a foolish approach. The teams simply cannot gel. The individuals are only on the project for a short time, and only for a percentage of their time, and therefore never learn how to deal with each other.

Professional development organizations allocate projects to existing gelled teams, they don't form teams around projects. A gelled team can accept many projects simultaneously and will divvy up the work according to their own opinions, skills, and abilities. The gelled team will get the projects done.

But how to manage that?

Teams have velocities. Velocity is the amount of work it can get done in a fixed period of time. Some teams measure their velocity in points per week, where points are a unit of complexity. They break down the features of each project they are working on and estimate them in points. Then they measure how many points they get done per week.

Velocity is a statistical measure. Over time this will average out. Management can set targets for each project given to a team. Aside from having a gelled team working on your projects, the advantage of the scheme is that in an emergency the business can say, "Project B is in crisis; put 100% of your effort on that project for the next three months".

The Project Owner dilemma

One of the objections to the approach I'm advocating is that the project owners lose some security and power. If projects are given to gelled teams, and if those teams take on several projects at the same time, then the business is free to change priorities on a whim. This can make the project owner insecure about the future. The resources that project owner is depending on might be suddenly removed from him.

Conclusion

Teams are harder to build than projects. Therefore, it is better to form persistent teams that move together from one project to the next and can take on more than one project at a time. The goal in forming a team is to give that team enough time to gel and then keep it together as an engine for getting many projects done.

Next article: #14 Mentoring, Apprenticeship and Craftsmanship

Previous article: #12 Collaboration

#12 Collaboration - Tips from The Clean Coder

Yuri Sales — Sun, 27 Sep 2020 14:39:32 +0000

This is the twelfth article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the twelfth chapter.

Most software is created by teams. Teams are most effective when the team members collaborate professionally. It's unprofessional to be a loner or a recluse on a team.

Programmers versus people

In general, we, programmers, enjoy the mild sensory deprivation and cocoon-like immersion of focus. We are happiest when we are alone in a room for hours deeply focussing on some really interesting problem.

Programmers versus employers

It's good to be passionate about what we do. But it's also good to keep your eye on the goals of the people who pay you.

The first responsibility of the professional programmer is to meet the needs of his or her employer. That means collaborating with your managers, business analysts, testers, and other team members to deeply understand the business goals. This doesn't mean you have to become a business work. It does mean that you need to understand why you are writing the code you are writing, and how the business that employs you will benefit from it.

The worst thing a professional programmer can do is to blissfully bury himself in a tomb of technology while the business crashes and burns around him. Your job is to keep the business afloat!

So, professional programmers take the time to understand the business. They talk to users about the software they're using. They talk to sales and marketing people about the problems and issues they have. They talk to their managers to understand the short-and long-term goals of the team.

Programmers versus programmers

Programmers often have difficulty working closely with other programmers. This leads to some really terrible problems.

Owned code

One of the worst symptoms of a dysfunctional team is when each programmer builds a wall around his code and refuses to let other programmers touch it. This is a recipe for disaster.

Collective ownership

I prefer teams in which any team member can check out any module and make any changes they think are appropriate. I want the team to own the code, not the individuals.

Professional developers don't prevent others from working in the code. Rather, they work with each other on as much of the system as they can. They learn from each other by working with each other on other parts of the system.

Pairing

Many programmers dislike the idea of pair-programming. I find this odd since most programmers will pair in emergencies. Why? Because it is clearly the most efficient way to solve the problem.

Professionals also pair because it is the best way to share knowledge with each other. Professionals don't create knowledge silos. Rather, they learn the different parts of the system and business by pairing with each other.

Professionals pair because it is the best way to review code. No system should consist of code that hasn't been reviewed by other programmers.

Professionals work together. You can't work together while you are sitting in corners wearing headphones. So I want you sitting around tables facing each other. I want you to be able to smell each other's fear. I want you to be able to overhear someone's frustrated mutterings. I want serendipitous communication, both verbal and body language. I want you communicating as a unit.

There are times when working alone is the right thing to do. There are times when you simply need to think long and hard about a problem. There are times when the task is so trivial that it would be a waste to have another person working with you. But, in general, it is best to collaborate closely with others and to pair with them a large fraction of the time.

Conclusion

Perhaps we didn't get into programming to work with people. Tough luck for us. Programming is all about working with people. We need to work with our business, and we need to work with each other.

Next article: #13 Teams and Projects

Previous article: #11 Estimation

#11 Pressure - Tips from The Clean Coder

Yuri Sales — Sun, 20 Sep 2020 12:38:13 +0000

This is the eleventh article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the eleventh chapter.

Imagine that you're having an out-of-body experience, observing yourself on an operating table while a surgeon performs open-heart surgery on you. That surgeon is trying to save your life, but time is limited so he is operating under a deadline - a literal deadline.

How do you want that doctor to behave? Do you want him to appear calm and collected? Do you want him issuing clear and precise orders to his support staff? Do you want him following his training and adhering to his disciplines?

Or do you want him sweating and swearing? Do you want him blaming management for unrealistic expectations and continuously complaining about the time? Do you want him behaving like a professional or like a typical developer?

The professional developer is calm and decisive under pressure. As the pressure grows he adheres to his training and disciplines, knowing that they are the best way to meet the deadlines and commitments that are pressing on him.

Avoiding pressure

The best way to stay calm under pressure is to avoid the situations that cause pressure. That avoidance may not eliminate the pressure completely, but it can go a long way towards minimizing and shortening the high-pressure periods.

Commitments

We must make sure that risk is quantified and presented to the business so that they can manage it appropriately. Accepting unrealistic commitments thwarts this goal and does a disservice to both the business and to ourselves.

Professionals will always help the business find a way to achieve their goals. But professionals do not necessarily accept commitments made for them by the business.

This is easy to say. But when your business is failing, and your paycheck is delayed because of missed commitments, it's hard not to feel the pressure. But if you have behaved professionally, at least you can hold your head high as you hunt for a new job.

Staying clean

We can avoid pressure by keeping our system, our code, and our design as clean as possible. This does not mean that we spend endless hours polishing code. It simply means that we don't tolerate messes. Professionals realize that "quick and dirty" is an oxymoron. Dirty always means slow!

Crisis discipline

You know what you believe by observing yourself in a crisis.

If you follow the discipline of TDD in non-crisis time but abandon it during a crisis, then you don't really trust that TDD is helpful. If you keep your code clean during normal times but make messes in a crisis, then you don't really believe that messes slow you down.

Choose disciplines that you feel comfortable following in a crisis. Then follow them all the time. Following these disciplines is the best way to avoid getting into a crisis.

Handling pressure

Forestalling, mitigating, and eliminating pressure is all well and good, but sometimes the pressure comes despite all your best intentions and preventions.

Don't panic

Manage your stress. Sleepless nights won't help you get done any faster. Sitting and fretting won't help either. Rushing will only drive you deeper into the hole.

Instead, slow down. Plot a course to the best possible outcome, and then drive towards that outcome at a reasonable and steady pace.

Communicate

Let your team and your superiors know that you are in trouble. Ask them for their input and guidance. Avoid creating surprises. Nothing makes people angrier and less rational than surprises. Surprises multiply the pressure by ten.

Get help

Pair! When the heat is on, find an associate who is willing to pair program with you. You'll get done faster, with fewer defects. Your partner will spot things that you miss, will have helpful ideas, and will pick up the slack when you lose focus.

By the same token, when you see someone else who's under pressure, offer to pair with them.

Conclusion

The trick to handling pressure is to avoid it when you can, and weather it when you can't. You avoid it by managing commitments, following your disciplines, and keeping clean. You weather it by staying calm, communicating, following your disciplines, and getting help.

Next article: #12 Collaboration

Previous article: #10 Estimation

#10 Estimation - Tips from The Clean Coder

Yuri Sales — Sun, 13 Sep 2020 15:04:37 +0000

This is the tenth article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the tenth chapter.

Estimation is one of the simplest, yet most frightening activities that software developers face. So many business values depend on it. It's the primary wedge that has been driven between business people and developers. It's the source of nearly all the distrust that rules that relationship.

What is an estimate?

Business likes to view it as commitments. Developers like to view as guesses. The difference is profound.

A commitment

A commitment is something you must achieve. If you commit to getting something done by a certain date, then you simply have to get it done by that date.

Professionals don't make commitments unless they know they can achieve them. It's really as simple as that.

https://dev.to/yurishenrique/11-pressure-tips-from-the-clean-coder-40i1
Commitment is about certainty. Other people are going to accept your commitments and make plans based upon them. The cost of missing those commitments, to them, and your reputation, is enormous. Missing them is an act of dishonesty only slightly less onerous than an overt lie.

An estimate

An estimate is a guess. No commitment is implied. Missing an estimate is not in any way dishonorable. The reason we make estimates is because we don't know how long something will take.

Unfortunately, most software developers are terrible estimators, mainly because we don't understand the true nature of an estimate.

An estimate is not a number, but a distribution - a probability distribution.

Implied commitments

Professionals draw a clear distinction between estimates and commitments. They do not commit unless they know for certain they will succeed. They are careful no to make any implied commitments. They communicate the probability distribution of their estimates as clearly as possible so that managers can make appropriate plans.

PERT

in 1957, the Program Evaluation and Review Technique (PERT) was created to support the U.S. Navy Polaris submarine project. One of the elements of PERT is a scheme that provides a very simple and effective way to convert estimates into probability distributions suitable for managers.

When you estimate a task, you provide three numbers. This is called trivariate analysis.

O: Optimistic Estimate. This number is wildly optimistic. You could only get the task done this quickly if everything went right. In order for the math to work, this number should have much less than a 1% chance of occurrence.
N: Nominal Estimate: This is the estimate with the greatest chance of success.
P: Pessimistic Estimate. This is wildly pessimistic. You should include everything except hurricanes, nuclear war, and other catastrophes. It also has much less than a 1% chance of success.

Given these 3 numbers, we can describe the probability solution as follows:

μ is the expected duration of the task.

δ is the standard variation of the probability distribution for the task. It's a measure of how uncertain the task is. When this number is large, the uncertainty is large too.

Imagine that you have these 3 tasks to do. It looks like the "beta" task has something that could possibly go wrong that would derail you significantly. But how long should you and your manager plan to complete all the 3 tasks?

You can combine all of them and come up with a probability distribution for the entire set of tasks.

The expected duration of that sequence is the sum of all expected durations. You will likely be done in about 14 days:
4.2 + 2.5 + 6.5.

The standard deviation of the sequence is the square root of the sum of the squares of the standard deviation of the tasks.

This tells your manager that your tasks will likely take 14 days, but could very well take 17 days (1δ) and could possibly even take 20 days (2δ). It could even take longer, but that's pretty unlikely.

The simple PERT scheme just shown is one reasonable way to help prevent setting optimistic expectations. Professionals are very careful to set reasonable expectations despite the pressure to try and to go fast.

Estimating tasks

The most important estimation resource you have is the people around you. They can see things that you don't. They can help you estimate your tasks more accurately than you can on your own.

Wideband Delphi

In the '70s, Barry Boehm introduced us to this technique. There have been many variations over the year, but they all have one thing in common: consensus.

A team of people assemble, discuss a task, estimate the task, and iterate the discussion and estimation until they reach an agreement.

The original approach involved several meetings and documents. I prefer simple low-overhead approaches such as the following.

Flying Fingers

Everybody sits around a table and starts a discussion about each task and what it involves, what might confound or complicate it, and how it might be implemented. Then the participants put their hands below the table and raise 0 to 5 fingers based on how long they estimate the task.

If everyone agrees, then they go on to the next task. Otherwise, they continue the discussion to determine why they disagree and repeat the process until they agree.

The scale of the estimated is decided on at the beginning of the meeting. It might be the number of days for a task or some more interesting scale such as "fingers times 3" ou "fingers squared".

Planning Poker

For each member, deal a hand of card with different numbers on them (0 through 5 work fine, Fibonacci series can also be used).

Pick a task and discuss it. At some point, the moderator asks everyone to pick a card. The members pull out a card that matches their estimate and hold it up with the back facing outward so that no one else can see. Then the moderator tells everyone to show their cards.

The rest is just like flying fingers.

Affinity Estimation

All the tasks are written onto cards, without any estimates showing. The team spread out the cards randomly on the table. They don't talk, they simply start sorting the cards relative to one another. Smaller tasks move to the left and the ones which take longer to the right.

Any team member can move any card at any time. Any card moved more than η times is set aside for discussion. Eventually, the silent peters out, and discussion can begin. Disagreements about the wondering are explored.

The next step is to draw lines between the cards that represent bucket sizes. These buckets might be days, weeks, or points. The Fibonacci sequence is traditional.

The Law of Large Numbers

Estimates are fraught with error. That's why they are called estimates. One way of managing errors is to take advantage of the Law of Large Numbers.

An implication of this law is that if you break up a large task into many smaller ones and estimate them independently, the sum of the estimates of the small tasks will be more accurate than a single estimate of the larger task.

Conclusion

Professionals know how to provide the business with practical estimates that the business can use for planning purposes. They don't make promises and commitments they cannot accomplish. They provide probabilistic estimates that describe the expected completion time and the likely variance.

They also work together with the other team members to achieve a consensus on the estimates.

Next article: #11 Pressure

Previous article: #9 Time Management (part 2)

#9 Time Management (part 2) - Tips from The Clean Coder

Yuri Sales — Wed, 09 Sep 2020 23:39:38 +0000

This is the second part of the ninth article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the ninth chapter.

Focus-Manna

Focus is a scarce resource, rather like manna. After you have expended your focus-manna, you have to recharge by doing unfocused activities for an hour or more.

Professional developers learn to manage their time to take advantage of their focus-manna is high; and we do other, less productive things when it's not.

Focus-manna is also a decaying resource. If you don't use it when it's there, you are likely to lose it. That's one of the reasons that meetings can be so devastating. If you spend all your focus-manna in a meeting you won't have any left for coding.

Worry and distractions also consume focus-manna.

Sleep

Professional developers manage their sleep schedule to ensure that they have topped up their focus-manna by the time they get to work in the morning.

Caffeine

There's no doubt that some of us can make more efficient use of our focus-manna by consuming moderate amounts of caffeine. But take care. Caffeine also puts a strange "jitter" on your focus. Too much of it can send your focus off in very strange directions.

Recharging

Focus-manna can be partially recharged by de-focusing. A good long walk, a conversation with friends, a time of just looking out a window can all help to pump the focus-manna back up.

I have found once the manna is gone, you can't force the focus. You can still write code, but you'll almost certainly have to rewrite it the next day or live with a rotting mss for weeks or months.

Muscle focus

There's something peculiar about doing physical disciplines such as martial arts, tai-chi, or yoga. Even though these activities require significant focus, it is a different kind of focus from coding. It's not intellectual, it's muscle. And somehow muscle focus helps to recharge mental focus. It's more than a simple recharge though.

Input versus output

Another thing I find essential for focus is to balance my output with appropriate input. Writing software is a creative exercise. I find that I am most creative when I am exposed to other people's creativity. So I read lots of science fiction.

The boxing and tomatoes

One very effective way I've used to manage my time and focus is to use the well-known Pomodoro Technique, otherwise knows as tomatoes.

You set a standard kitchen timer for 25 minutes. While that timer is running, you let nothing interfere with what you are doing. If the phone rings you answer and politely ask if you can call back within 25 minutes. If someone stops in to ask you a question you politely ask if you can get back to them within 25 minutes.

When the tomato timer dings, you stop what you are doing immediately. You deal with any interruptions that occurred during the tomato. Then you take a break of 5 minutes or so. Then you set the timer for another 25 minutes and start the next tomato. Every fourth tomato you take a longer break of 30 minutes or so.

On a good day, you might get 12 or even 14 tomatoes done. On a bad day, you might only get 2 or 3 done.

Avoidance

Sometimes your heart just isn't in your work. It may be that the thing that needs doing is scary or uncomfortable or boring.

Priority inversion

Whatever the reason, you find ways to avoid doing the real work. You convince yourself that something else is more urgent, and you do that instead. This is called priority inversion.

They are a little lie we tell ourselves. We can't face what needs to be done, so we convince ourselves that another task is more important.

Actually we aren't lying to ourselves. We are building a defense to protect us from the judgment of others.

Clearly this is unprofessional behavior. Professionals evaluate the priority of each task, disregarding their personal fears and desires, and execute those tasks in priority order.

Blind alleys

Sometimes you will make a decision and wander down a technical pathway that leads to nowhere. The most vested you are in your decision, the longer you'll wander in the wilderness. If you've staked your professional reputation, you'll wander forever.

Prudence and experience will help you avoid certain blind alleys, but you'll never avoid them. So the real skill you need is to quickly realize when you are in one and have the courage to back out. This is sometimes called The Rule of Holes: When you are in one, stop digging.

Marshes, bogs, swamps, and other messes

Messes slow you down, but don't stop you. They are worse than blind alleys because you can always see the way forward, and it always looks shorter than the way back (but it isn't).

Nothing has a more profound or long-lasting negative effect on the productivity of a software team than a mess. Nothing.

Experience and prudence can help you to avoid them, but eventually, you will make a decision that leads to a mess. Going back looks expensive because you'll have to rework the existing code, but going back will never be easier than it is now.

Moving forward through a swamp, when you know it's a swamp, is the worst kind of priority inversion. By moving forward you are lying to yourself, to your team, to your company, and to your company.

Conclusion

Software professionals are diligent in the management of their time and their focus. They understand the temptations of priority inversion and fight it as a matter of honor. And they are always on the lookout for growing messes, and they clean them as soon as they are recognized.

Next article: soon...

Previous article: #9 Time Management (part 1)

#9 Time Management (part 1) - Tips from The Clean Coder

Yuri Sales — Sun, 06 Sep 2020 13:52:14 +0000

This is the first part of the ninth article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the ninth chapter.

Eight hours is a remarkably short period of time. As a professional, you expect that you will use this precious time as efficiently and effectively as possible. What strategy can you use to ensure that you don't waste the little time you have? How can you effectively manage your time?

Meetings

The next time you are in a meeting, calculate the costs per hour, considering salaries, benefits, facilities costs, and so forth. You may be amazed.

There are two truths about meeting.

Meetings are necessary.

Meetings are huge time wasters.

Professionals are aware of the high cost of meetings. They are also aware that their own time is precious, they have code to write and schedules to meet. Therefore, they actively resist attending meetings that don't have an immediate and significant benefit.

Declining

You don't have to attend every meeting to which you are invited. You need to use your time wisely. So be very careful about which meetings you attend and which you politely refuse.

The person inviting you to a meeting is not responsible for managing your time. Only you can do that. So when you receive a meeting invitation, don't accept unless it is a meeting for which your participation is immediately and significantly necessary to the job you are doing now.

Leaving

Meetings don't always go as planned. When the meeting gets boring, leave.

Clearly you should not storm out of a meeting exclaiming "This is boring!". There's no need to be rude. You can simply ask, at an opportune moment, if your presence is still necessary.

The important thing to realize is that remaining in a meeting that has become a waste of time for you, and to which you can no longer significantly contribute, is unprofessional. You have an obligation to wisely spend your employer's time and money, so it is not unprofessional to choose an appropriate moment to negotiate your exit.

Have an agenda and a goal

To use the participants' time wisely, the meeting should have a clear agenda, with time for each topic and stated goal.

Make sure you know what discussions are on the table, how much time is allowed for them, and what goal is to be achieved.

If you find that the agenda has been high-jacked or abandoned, you should request that the new topic be tabled and the agenda be followed. If this doesn't happen, you should politely leave when possible.

Stand-up meetings

These meetings are part of the Agile canon. Each participant takes a turn to answer three questions:

What did I do yesterday?

Whats am I going to do today?

What's in my way?

Each question should require no more than twenty seconds, so each participant should require no more than one minute.

Iteration planning meetings

These are the most difficult meetings in the Agile canon to do well. Done poorly, they take far too much time.

They are meant to select the backlog items that will be executed in the next iteration. Estimates should already be done for the candidate items. Assessment of business value should already be done. In really good organizations the acceptance/component tests will already be written, or at least sketched out.

The meeting should proceed quickly with each candidate backlog item being briefly discussed and then either selected or rejected. No more than five or ten minutes should be spent on any given item. If a longer discussion is needed. It should be scheduled for another time with a subset of the team.

My rule of thumb is that the meeting should take no more than 5% of the total time in the iterations. So for a one-week iteration (forty hours), the meeting should be over within two hours.

Iteration retrospective and demo

These meetings are conducted at the end of each iteration. Team members discuss what went right and what end wrong. Stakeholders see a demo of the newly working features. These meetings can be badly abused and can soak up a lot of time, so schedule them 45 minutes before quitting time on the last day of the iteration.

Allocate no more than 20 minutes for retrospective and 25 minutes for the demo. Remember, it's only been a week or two so there shouldn't be all that much to talk about.

Arguments/disagreements

Technical disagreements tend to go off into the stratosphere. Each party has all kinds of justifications for their position but seldom any data. Without data, any argument that doesn't forge agreement within a few minutes (somewhere between five and thirty) simply won't ever forge an agreement. The only thing to do is to go get some data.

How do you get the data you need to settle a disagreement? Sometimes you can run experiments, or do some simulation or modeling. But sometimes the best alternative is to simply flip a coin to choose one of the two paths in question.

Beware of meetings that are really just a venue to vent a disagreement and to gather support for one side or the other. And avoid those where only one of the argues is presenting.

If an argument must truly be settled, then ask each of the arguers to present their case to the team in five minutes or less. Then have the team vote.

Next article: #9 Time Management (part 2)

Previous article: #8 Testing Strategies

#8 Testing Strategies - Tips from The Clean Coder

Yuri Sales — Sun, 30 Aug 2020 13:45:40 +0000

This is the eighth article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the eighth chapter.

Professional developers test their code. But testing is not simply a matter of writing a few unit tests or a few acceptance tests. Writing these tests is a good thing, but it is far from sufficient. What every professional development team needs is a good testing strategy.

QA should find nothing

I've said this before, and I'll say it again. Despite the fact that your company may have a separate QA group to test the software, it should be the goal of the development group that QA finds nothing wrong.

Of course, it's not likely that this goal will be constantly achieved. Still, every time QA finds something the development team should react in horror. They should ask themselves how it happened and take steps to prevent it in the future.

QA is part of the team

The previous section might have made it seem that QA and Development are at odds with each other, that their relationship is adversarial. This is not the intent. Rather, QA and Development should be working together to ensure the quality of the system. The best role for the QA part of the team is to act as specifiers and characterizers.

QA as specifiers

It should be QA's role to work with business to create the automated acceptance tests that become the true specification and requirements document for the system.

QA as characterizers

The other role for QA is to use the discipline of exploratory testing to characterize the true behavior of the running system and report that behavior back to development and business.

The Test Automation Pyramid

As good as it is to have a suite of unit and acceptance tests, we also need higher-level tests to ensure that QA finds nothing. The figure below shows the Test Automation Pyramid, a graphical depiction of the kinds of tests that a professional development organization needs.

Unit tests

These tests are written by programmers, for programmers, in the programming language(s) of the system. The intent is to specify the system at the lowest level. They're written before the production code as a way to specify what they are about to write.

They provide as close to 100% coverage as is practical. Generally, this number should be somewhere in the 90s. And it should be true coverage as opposed to false tests that execute code without asserting its behavior.

Compoment tests

Generally, they are written against individual components of the system. These components encapsulated the business rules, so the tests for those components are the acceptance tests for those business rules.

A component test wraps a component. It passes input data into the component and gathers output data from it. It tests that the output matches the input. Any other components are decoupled from the test using appropriate mocking and test-doubling techniques.

Component tests are written by QA and Business with assistance from Development. They are directed more towards happy-path situations and very obvious corner, boundary, and alternate-path cases. The vast majority of unhappy-path cases are covered by unit tests and are meaningless at the level of component tests.

Integration tests

These tests only have meaning for larger systems that have many components. These tests assemble groups of components and test how they communicate with each other.

Integration tests are typically written by the system architects, or lead designers, of the system. The tests ensure that the architectural structure of the system is sound.

They are typically not executed as part of the CI suite, because they often have longer runtimes. Instead, these tests are run periodically (nightly, weekly, etc.) as deemed necessary by their authors.

System tests

These are automated tests that execute against the entire integrated system. They are the ultimate integration tests. They do not test business rules directly. Rather, they test that the system has been wired together correctly and its parts interoperate according to plan.

They're written by the system architects and technical leads. We'd expect to see throughput and performance tests in this suite.

Their intent is not to ensure correct system behavior, but correct system construction.

Manual exploration tests

This is where humans put their hands on the keyboard and their eyes on the screens. These tests are not automated, nor are they scripted. The intent of these tests is to explore the system for unexpected behavior while confirming the expected ones.

Toward that end we need human brains, with human creativity, working to investigate and explore the system. Creating a written test plan for this kind of testing defeats the purpose.

Some teams will have specialists do this work. Other teams will simply declare a day or two of "bug hunting" in which as many people as possible. The goal is to ensure that the system behaves well under human operation and to creatively find as many "peculiarities" as possible.

Conclusion

TDD is a powerful discipline, and Acceptance Tests are valuable ways to express and enforce requirements. But they are only part of a total testing strategy.

Development teams need to work hand in hand with QA to create a hierarchy of unit, component, integration, system, and exploratory tests. These tests should be run as frequently as possible to provide maximum feedback and to ensure that the system remains continuously clean.

Next article: #9 Time Management (part 1)

Previous article: #7 Acceptance Testing

#7 Acceptance Testing - Tips from The Clean Coder

Yuri Sales — Mon, 24 Aug 2020 00:16:29 +0000

This is the seventh article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the seventh chapter.

The role of the professional developer is a communications role as well as a development role. Remember that garbage-in/garbage-out applies to programmers too, so professional programmers are careful to make sure that their communication with other members of the team, and the business, are accurate and healthy.

Communicating requirements

One of the most common communication issues between programmers and business is the requirements. The business people state what they believe they need, and then the programmers build what they believe the business described. At least that's how it's supposed to work. In reality, the communication of requirements is extremely different, and the process is fraught with error.

Premature precision

Both business and programmers are tempted to fall into the trap of premature precision. Business people want to know exactly what they are going to get before they authorize a project. Developers want to know exactly what they are supposed to deliver before they estimate the project. Both sides want a precision that simply cannot be achieved, and are often willing to waste a fortune trying to attain it.

The uncertainty principle

The problem is that things appear different on paper than they do in a working system. When the business actually sees what they specified running in a system, they realize that it wasn't what they wanted at all. Once they see the requirement actually running, they have a better idea of what they really want - and it's usually not what they are seeing.

Estimation anxiety

First, even with the perfect information, your estimates will have a huge variance.
Second, the uncertainty principle makes hash out of early precision. The requirements will change-making that precision moot.

Professional developers understand that estimates can, and should, be made based on low precision requirements, and recognize that those estimates are estimates; To reinforce this, professional developers always include error bars with their estimates so that be business understands the uncertainty.

Late ambiguity

the solution to premature precision is to defer precision as long as possible. Professional developers don't flesh out a requirement until they are just about to develop it. However, that can lead to another malady: late ambiguity.

Often stakeholders disagree. When they do, they may find it easier to wordsmith their way around the disagreement rather than solve it. They will find some way of phrasing the requirement that they can all agree with, without actually resolving the dispute. I once heard Tom DeMarco say, "An ambiguity in a requirements document represents an argument amongst the stakeholders."

It is the responsibility of professional developers (and stakeholders) to make sure that all ambiguity is removed from the requirements.

This is hard, and there's only one way I know how to do it.

Acceptance tests

The term acceptance test is overloaded and overused. We will define it as tests written by a collaboration of the stakeholders and the programmers in order to define when a requirement is done.

The definition of "Done"

Professional developers have a single definition of done: Done means done. Done means all code written, all tests pass, QA and the stakeholders have accepted. Done.

But how can you get this level of done-ness and still make quick progress from iteration to iteration? You create a set of automated tests that, when they pass, meet all of the above criteria! When the acceptance tests for your feature pass, you are done.

Communication

The purpose of acceptance tests is communication, clarity, and precision. By agreeing to them, the developers, stakeholders, and testers all understand what the plan for the system behavior is. Achieving this kind of clarity is the responsibility of all parties. Professional developers make it their responsibility to work with stakeholders and testers to ensure that all parties know what is about to be built.

Automation

Acceptance tests should ALWAYS be automated. There is a place for manual testing elsewhere in the software lifecycle, but these kinds of tests should never be manual. The reason is simple: cost.

The cost of automating acceptance tests is so small in comparison to the cost of executing manual test plans that it makes no economic sense to write scripts for humans to execute. Professional developers take responsibility for their part in ensuring that acceptance tests are automated.

Extra work

Don't look to these tests as extra work. Look at them as massive time and money savers. These tests will prevent you from implementing the wrong system and will allow you to know when you are done.

Who writes acceptance tests, and when?

In an ideal world, the stakeholders and QA would collaborate to write these tests, and developers would review them for consistency. In the real world, stakeholders seldom have the time or inclination to dive into the required level of detail. So they often delegate the responsibility to business analysts, QA, or even developers.

Typically business analysts write the "happy path" versions of the tests because those tests describe the features that have business value. QA typically writes the "unhappy path" tests, the boundary conditions, exceptions, and corner cases. This is because QA's job is to help think about what can go wrong.

The developer's role

Implementation work on a feature begins when the acceptance tests for that feature are ready. The developers execute the acceptance tests for the new feature and see how they fail. Then they work to connect the acceptance test to the system, and then start making the test pass by implementing the desired feature.

Test negotiation and passive aggression

Test authors are human and make mistakes. Sometimes the tests as written don't make a lot of sense once you start implementing them. They might be too complicated. They might be awkward. They might contain silly assumptions. Or they might just be wrong.

As a professional developer, it's your job to negotiate with the test author for a better test. What you should never do is take the passive-aggressive option and say to yourself, "Well, that's what the test says, so that's what I'm going to do."

Remember, as a professional it's your job to help your team to create the best software they can.

Acceptance tests and Unit tests

Acceptance tests are not unit tests. Unit tests are written by programmers for programmers. They are formal design documents that describe the lowest level structure and behavior of the code.

Acceptance tests are written by the business for the business (even when you, the developer, end up writing them). They are formal requirements documents that specify how the system should behave from the business point of view. The audience is the business and the programmers.

Although it is true that unit and acceptance tests often test the same things, they are not redundant at all. They may test the same things but through different mechanisms and pathways. Unit tests dig into the guts of the system making calls to methods in particular classes. Acceptance tests invoke the system much farther out, at the API, or sometimes even UI level. So the execution pathways that these tests are very different.

But the real reason these tests aren't redundant is that their primary function is not testing. The fact that they are tests is incidental. Their primary purpose is to formally document the design, structure, and behavior of the system.

GUIs and other complications

It's hard to specify GUIs upfront. It can be done but is seldom done well. The reason is that aesthetics are subjective and therefore volatile. People want to fiddle with GUIs. They want to massage and manipulate them.

This makes it challenging to write acceptance tests for GUIs. The trick is to design the system so that you can treat the GUI as a though it were an API rather than a set of buttons, sliders, grids, and menus. This may sound strange, but it's really just good design.

Some acceptance tests specify the behavior of the GUI itself. However, these tests do no test business rules and therefore don't require the business rules to be connected to the GUI. Therefore, it's a good idea to decouple the GUI and the business rules and replace the business rules with stubs.

Keep the GUI tests to a minimum. They're fragile.

Continuous Integration

Make sure that all your unit and acceptance tests are run several times per day in a continuous integration system. This system should be triggered by your source code control system. Every time someone commits a module, the CI system should kick off a build, and then run all the tests in the system. The results of that run should be emailed to everyone on the team.

Conclusion

Communication about details is hard. It's too easy for each party to wave their hands and assume that the other party understands. All too often they agree that they understand and leave with completely different ideas.

The only way I know to effectively eliminate communication errors between the parties is to write acceptance tests. They are the perfect requirements document.

Next article: #8 Testing Strategies

Previous article: #6 Practicing

#6 Practicing - Tips from The Clean Coder

Yuri Sales — Mon, 17 Aug 2020 00:24:09 +0000

This is the sixth article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the sixth chapter.

All professionals practice their art by engaging in skill-sharpening exercises. Musicians rehearse scales. Football players run through tires. Doctors practice sutures and surgical techniques. Lawyers practice arguments. Soldiers rehearse missions. When performance matters, professionals practice.

Some background on practicing

Practicing is not a new concept in software development, but we didn't recognize it as a practice until just after the turn of the millennium. Perhaps the first formal instance of a practice program is the "hello world".

We use it as a way to prove a new environment or a new language. Writing and executing that program is proof that we can write and execute any program.

Things have changed since the early days of programming. Some things have changed a lot. Other things haven't changed much at all.

We've got better tools to write those classic statements (if statements, while loops and assignments) with. But the nature of the statements hasn't changed in all that time. Code in 2010 would be recognizable to a programmer from the 1960s. The clay that we manipulate has not changed much in those four decades.

Turnaround time

But the way we work has changed dramatically. In the '60s I could wait a day or two to see the results of a compile. In the late '70s, a 50,000-line program might take 45 minutes to compile. Even in the '90s, long build times were the norm.

Programmers today don't wait for compiles. They have such immense power under theirs fingers that they can spin around the red-green-refactor loop in seconds.

It's not always wise to go that fast. Often is better to slow down and just think. But there are other times when spinning around that loop as fast as possible is highly productive.

Doing anything quickly requires practice. Spinning around the code/test loop quickly requires you to make very quick decisions. Making decisions quickly means being able to recognize a vast number of situations and problems and simply know what to do to address them.

Consider two martial artists in combat. Each must recognize what the other is attempting and respond appropriately within milliseconds. In combat, you don't have the luxury of freezing time, studying the positions, and deliberating on the appropriate response. You simply have to react. Indeed, it's your body that reacts while your mind is working on a higher-level strategy.

When you're spinning around the code/test loop several times per minute, it is your body that knows what keys to hit. A primal part of your mind recognizes the situation and reacts within milliseconds with the appropriate solution while your mind is free to focus on the higher-level program.

In both the martial arts case and the programming case, speed depends on practice. And in both cases the practice is similar. We choose a repertoire of problem/solution pairs and execute them over and over again until we know them cold.

Kata

In martial arts, a kata is a precise set of choreographed movements that simulates one side of a combat. The goal, which is asymptotically approached, is perfection.

The purpose of learning a kata is not to perform it on stage but to train your mind and body how to react in a particular combat situation, doing the perfected movements automatic and instinctive.

A programming kata is a precise set of choreographed keystrokes and mouse movements that simulates the solving of some programming problem. You aren't actually solving the problem because you already know the solution. Rather, you're practicing the movements and decisions involved in solving the problem.

Practicing a suite of katas is a food way to learn hotkeys and navigation idioms. It is also a good way to learn disciplines such as TDD and CI. But most importantly, it is a good way to drive common problem/solution pairs into your subconscious, so that you simply know how to solve them when facing them in real programming.

Wasa

When I studied jujitsu, much of our time in the dojo was spent in pairs practicing our wasa. Wasa is very much like a two-man kata. The routines are precisely memorized and played back. One partner plays the role of the aggressor, and the other partner is the defender. The motions are repeated over and over again as the practitioners swap roles.

Programmers can practice in a similar fashion using a game known as ping-pong. Both partners choose a kata, or a simple problem. One programmer writes a unit test, and then the other must make it pass. Then they reverse roles.

Randori

Randori is a free-form of combat. In our jujitsu dojo, we would set up a variety of combat scenarios and then enact them. But simulated combat does not map well to programming. however, there is a game that is played in many coding dojo called randori. It's very much like two-man wasa, but it's played with many people and the rules have a twist.

With the screen projected on the wall, one person writes a test and then sits down. The next person makes the test pass and then writes the next test and so on.

You can gain an immense insight into the way other people solve problems. These insights can only serve to broaden your own approach and improve your skill.

Broadening your experience

Professional programmers ofter suffer from a lack of diversity in the kind of problems they solve. Employers often enforce a single language, platform, and domain. Without a broadening influence, this can lead you to a very unhealthy narrowing of your resume and your mindset.

Open-source

One way to stay ahead of the curse is to take on some pro-bono work by contributing to an open-source project. There is no probably better way to improve your repertoire of skills than work on something that someone else cares about.

Practice ethics

Professional programmers practice on their own time. Employers don't have to pay you for your practice time. Since your practice time is your own time, you don't have to use the same languages and platforms that you use at work.

Conclusion

In one way or another, all professionals practice. They do this because they care about doing the best job they possibly can. The practice in their own time because they realize it is their responsibility to keep their skill sharp. Practicing is what you do when you aren't getting paid. You do it so that you will be paid, and paid well.