(Para a versão em Português: link)

Animes, Games, and Technology: What do they have in common? Quite a lot, but when you mix them all together, you create chaos!

And that was my biggest impression of CPBSB5.

First, I would like to thank Rocketseat for the opportunity since I won the ticket from them. In fact, even though I'm here in Brasília, I had no idea that the event would happen. The previous Friday, while checking Discord notifications, I saw that there was going to be an event and they would be giving away tickets... even though I never win anything, I tried my luck... when I received the email confirming that I had won, I was surprised and anxious, as it would be the first event of this kind that I would be attending.

But back to the chaos, don't get me wrong, because it's good chaos. On one stage, they talked about crypto, and on another, they talked about asteroid mining. At one moment, I was watching extremely technical content, turned my head, and heard loud music, people playing dance games, and others walking around in cosplay with Gandalf calmly waving in encouragement (if you know, you know).
There was so much going on and so little time, so everyone enjoyed the event the way they thought was best. I jumped from lecture to lecture, others were probably playing games and enjoying the super-fast internet that was available, I saw many in groups, people in cosplay, people programming, others doing more manual things, and of course, many people fueled by instant noodles, caffeine, and little sleep.

Top Learnings (non-exhaustive)

I focused on technology and programming lectures and in the "free" hours, those with the most interesting title (a tip for those attending an event is that the lecture titles are worth paying attention to!).

It's impossible to summarize days of events in one text, but I'll try to filter the most important things and also add a bit of my own experience and research on the topics.

One important thing to note is that the lectures were between half an hour and an hour long, and no matter how good the speakers were, it's impossible to cover a lot of content in such a short time (and some tried!).
So, I see it as less about trying to really teach a subject in depth and more about bringing up a topic so that you, the listener, can seek and pursue those topics that really caught your attention.

Security: OWASP Top 10

1. Broken Access Control
2. Cryptographic Failures
3. Injection
4. Insecure Design
5. Security Misconfiguration
6. Vulnerable and Outdated Components
7. Identification and Authentication Failures
8. Software and Data Integrity Failures
9. Security Logging and Monitoring Failures
10. Server-side Request Forgery

I attended several lectures where OWASP and security, in general, were the main topics. It's something VERY important but often overlooked. Maybe you'll see the basics in the middle of a course or video here and there, or there might be a “module” about security, but how deep is the subject usually covered?

Related to the subject is the differentiation between "authentication" and "authorization." The simplest way to differentiate the two:

• Authentication: Who are you?
• Authorization: Are you allowed to be here?

Knowing this, we can go back to the OWASP Top 1 and take as a standard to DENY any access by default and then grant access only to those who are authorized. And more than that, segmenting what is possible to do by CRUD (create, read, update, delete), that is, different accesses to read, write, update, and delete would mean that it is harder for someone to simply gain full access, and if you add to that a segmentation by route/feature, then it makes it even more difficult for someone looking to do something they shouldn't.
This is just the basic, and of course, there is more to it: it applies not only to people but also to machines. Does your server really need to have all those files there? Leaving versioning, environment files, and many others simply "lying" around, even if "normally" there is no access, if someone guesses that there is a ".env" there and that the server simply serves what exists, then it's just a matter of time until a problem occurs...
Speaking of which, how are your access logs? You do have logs, right?
No? How will you know if there are people trying to access your server then? How will you know when someone has really entered and what they did there? Or, if they've already entered and done something?
Without any limits, it's literally just a matter of time until someone gains access, and although it doesn't fix the problem, putting access limits can at least reduce the damage caused.
Whether to limit access to a server or log in to an application, one strategy is to impose a backoff time between attempts. The more you fail, the longer you have to wait between new attempts.

Moving on to the frontend world now, errors happen, but there needs to be a balance between errors that help the user and generic enough errors that don't expose information they shouldn't.

In the example, does the error help? Yes? I mean, you know why the error occurred, however, it is too much information.
The classic non-meme case is to return "incorrect email OR password" or even when trying to recover a password, only "an email has been sent to recover the password" is shown regardless of whether the email is registered or not. This is because just knowing that an email is registered is already too much information.
At the same time, a generic error like "Oops, there was an error!" is too generic and doesn't help the user... was it their mistake? Problem with the server? In this, part of the responsibility falls on those who make the backend to return the correct HTTP status codes and on the frontend to use this to show something helpful.
Hey, do you know by heart at least what each status code range does?

Another security point is the amount of information transmitted, and in this case, less is better. It is common to see a registration that should be simple, however, it extends over pages and pages asking things that they don't really need to know.
And of course, afterward, in order to show all of this, more pages or tables are necessary to show all of it.
And since we are on the internet, remember encryption, meaning the "lock" that signifies that everything is transmitted with TLS, and even if someone tries to spy on what is being transmitted, they will not have access to the transmitted data.
And if that wasn't enough... protect yourself even from those who are authenticated and authorized! Validate and sanitize all user inputs to prevent anything potentially harmful (Top 3: Injection).
Finally, remember that more than just writing code, we use a lot of other people's code. So the minimum is to keep everything updated in patch versions. Or even abandon versions that are no longer actively supported.

*Design, Data, and User Experiences*

Whether it's a frontend or some slide presentation, knowing how to display information is more than just throwing a bunch of numbers and letters on the screen. To create a good experience, it is essential to first investigate the data.

Look at the image below and try to answer: how many colors are there? Which one has more pieces?

Different experiences call for different presentations, so it is necessary to know what you're dealing with in order to use the best visualization for what you want to show. In the case of data presentation, it is important not only to throw the data on the screen, but also to explain what each one is, as well as a title for charts and sources.

Finally, contextualize what the data means since, while you may know what is being shown, others may not. Not only that but without this contextualization, there is no way to know if what is being presented is good or bad.
Now, with contextualization and even explanations of relevant facts, it is possible to summarize a lot of information in just one image that can really live up to the saying "a picture is worth a thousand words".

And the answer to the questions above?

We're not good with scattered data, it simply doesn't work for us. A small sorting already helps, but still doesn't show everything. Once the data is arranged, it's possible to see something, but to facilitate the consumption of this information, knowing how to present it visually is necessary.
The question that remains is: when did you notice that there is a gray piece?

This leads to a more design and UX (user experience) related topic: "The customer is always right," but is that really the case?
More than the customer, the programmer needs to think not about the customer, but about the USER!

My experience is that if I simply said "yes" to what my "clients" think they want, I would make a lot of Excel spreadsheets, but in the browser.
Just because it's what the customer wants doesn't mean it's what the user needs or what will generate more value for them (and sometimes for the client themselves!).

So the idea is not to think about the "client" but rather: "The user is always right." This means that it's not the user's fault for not knowing how to use something, but rather the designer's responsibility to know who their users are, and their limitations, and to create something that their users can start using right away.

Just like with code we create. If someone comes to you and says the code is confusing, it's no use explaining it to them or putting some comments, what's needed is to refactor the code so that there is no doubt. (It's a bit of an exaggeration, yes, but in general, it's always better to try to redo it in a way that minimizes any doubts than to try to explain/comment, which should be used as a "last resort.")

And then there are Nielsen's 10 heuristics (just search and read more about the subject):

1. Visibility of system status
2. Match between system and the real world
3. User control and freedom
4. Consistency and standards
5. Error prevention
6. Recognition rather than recall
7. Flexibility and efficiency of use
8. Aesthetic and minimalist design
9. Help users recognize, diagnose, and recover from errors
10. Help and documentation

Whether it's a frontend or some slide presentation, testing, refactoring, and iterations are necessary. It's totally okay to start with something simpler and as feedback is received, improve the design. Sometimes, even before "delivering", it's necessary to test various approaches to validate which one is best for a given situation.

For those who are not designers or when in the middle of things, we sometimes exaggerate too much and don't even realize it. So it's necessary to take a break, look at something else, and then come back to see the mess we've made with a clear head.

Some tips for aesthetics were:

• Colors: 60/30/10 This is about colors: 60% neutral colors, 30% main color, and 10% highlight color.
• Visual hierarchy In other words, highlight only what's most important and give more prominence to more important things.
• Whitespace In this case, not literally a blank space, but rather that things have space from their margins to "breathe" and not be all "cramped" together.

Regardless of whether there is a designer available or not, planning before getting started is essential! The famous "measure twice, cut once".
And even after it's deployed, leave a feedback field so that users can tell you what's good and what's bad. Not everyone will, in fact, only a small minority will give feedback, and normally when something is really bad..., but it's still a tool to keep improving the design.

On leadership, seniority, and skills

They asked about "soft" and "hard" skills. And one thing they said was that as programmers, much of what we do is all "soft" skills.

• Soft X Hard skill "Hard" skill is everything that is always done in the same way. In other words, the use of tools. In the case of programming, a language or framework is a hard skill that requires technique and practice. However, programming itself is a "soft" skill because everything "depends".
• "Depends" There are several levels in programming, and perhaps the level can be measured by "depends". A junior has a smaller foundation, so even though they know how to do it, they end up in a situation where "when you only have a hammer, all problems are treated as if they were nails". In this case, the "depends" is only if they can and how to hammer that problem. Someone at an intermediate level should have a better foundation, but their "depends" is still limited to the options they can put into practice to solve the problem. A senior is not limited only by what they know because learning a "hard" skill is something that should be trivial. Knowing that the possibility exists and whether it is applicable is one of the senior's "soft" skills, and more than that, the "depends" is often related to what the client wants or what the user needs. And after the senior level, the "depends" should die! Everyone knows that "depends" and therefore choosing the path to be followed to solve the problem is up to the person who transcended the "senior". And this choice doesn't even have to be the perfect solution because depending on the problem, waiting for a perfect solution is the wrong choice. In fact, another point is working with others, and in this case, several people generate several ideas, and then "disagree and commit" comes in, even if it's not the solution you wanted, once a choice is made, then everyone commits to making the chosen solution work.

But what comes after senior?
Not everyone wants to be a leader, but everyone can learn a thing or two.
Hard skills are a minimum requirement, but not absolutely necessary. A common mistake, and something that has not had a solution for a long time, is to promote someone to a leadership position simply because they are technically skilled.
By doing this, you may lose someone who is good technically and make a bet that can result in anything from a great to a terrible leader, but where even an "okay" leader is a loss.
There is always the question of whether the person wants it or not, and it is something that can be trained, but it is a mistake to think or have "becoming a manager" as the only alternative to grow.

But for those who want to learn about leadership, even without it being an official role, the pillars of leadership are mindset, results, and relationships.
Influencing people (in a good way) helps you to have more space and voice in the team. And when you pursue win-win relationships, you generate value even if others don't see it that way at first.
For this, it is necessary to know how to work in a team. And it is not enough to simply wait for each person to do their part, but to use influence to make things really happen. And for this, trust is essential (that's why you should never promise anything! Communicate and deliver without promising: it is possible!) but always treat people well, regardless of what you think of them.