Software Craftless: Writing Code That Would Make a Goat Vomit

Hello, welcome to my talk, Software Craftless, Making code that will make a goat bold. Before we start, let me introduce myself. My name is Cesar Alberca, you can also pronounce it Caesar, like the salad or the emperor. I help my clients build scalable and ready-fronted architectures as a freelancer. I'm an international speaker, I've given talks in more than two different countries, I'm a published book author, I've published one book, and I'm also a human generator. You'll have more information on my website available. And I, here, show you my newsletter because in reality, the objective of this talk is to share my newsletter.

Before we even start, I need you to accept the cookies. Yes, given that this is a JavaScript related talk, we need to accept the cookies. So, please pause the video, scan the QR code, and accept the cookies. Okay, now we can continue. Why will we write horrible code? You might ask yourselves. Well, if nobody understands your code, you are indispensable. This is actually true also for AI. If AI cannot really understand what you do, or you even got a job as a software engineer, don't worry, you will not be replaced. So, that's one point to take into consideration.

If the code is harder to understand, then you look smarter. I know most of you use glasses that, yeah, they don't have glasses, really. So, yeah, it's just to make us look smart. Developers quit because they get burnt, you know, and then demand goes up, and then we have more money for you. So, that's why, and another reason why, I make sure that the teams I work with, they have a terrible experience, and they have tasks, it's impossible to read through the code that I write. It boosts creativity.

The best practices are boring, you know. They've been written and talked about for decades already, and they are the same. So, I like to approach every day in my job as something new, and where I may find new opportunities to read horrible code, you know. And, of course, it builds character, you know. Everyone will know about you in the office. So, that's a great way to be more popular. I know some of you really need it.

Yes, my clicker is my mouse. So, what makes code bad? Well, you might think that it's commented out code, complex code, no tests, AI-generated architecture. No, in reality, it's JavaScript. JavaScript is what makes code terrible. That's why I decided to be a front-end developer rather than a back-end developer. Well, nowadays, with Node.js and other tools, we can write terrible code with JavaScript in both the front-end and the back-end. So, that's just perfect. Of course, don't ever use TypeScript.

Let's talk about coding. So, with coding... Ah, yeah, Barbaris Kov in 1984. Already said it perfectly. We might start with naming. So, for me, I think it's important to use representative names. For example, I choose x2, and there's not even x1 in the code, you know. But I like to add an x2 to make people, you know, like, oh, where's x1? I cannot find it. Well, there's none. I make sure that my teammates have a very sharp mind, you know. I always test them. Of course, we can have confusing functional names.

What about if the code is minor? We can have inconsistent recommendations, you know. Common case, snake case, they were invented for a reason, so let's make sure we use them. Coming from Java, overly long variable names. If you can see at the end, because we don't use types at all, I would not recommend you do that. Adding the type as a suffix, even if it's the wrong type. Already defining the code thinking about what to include commented out, adding confusion with 'don't delete' comments. Ensuring we are not replaceable, including complex code functions.

This is a nice function for crafters, but forget about it. Using switches and annotating them, considering skipping breaks. Introducing unhandled cases deliberately. Mentioning a recording function. Additional tips like adding slips to the code and removing them occasionally to appear optimized. Perfect for those interested in performance optimization.

Make sure we are not replaceable. And of course, complex code. So yeah, this is a nice function for those people that are also we're crafters and stuff like that. Forget about it. This is a map. Yeah. Now, we can use switches for this. And we can, of course, annotate switches.

What about if we go even a step further? Annotate switches if I'll say maybe even skip a break. So yeah, we need a break for sure. But no, let's skip a break. Make sure that there's some unhandled cases. And yeah, what about a recording function? Yeah, I think that will do it.

Okay, more tips. Add slips to your code and then remove it now and then. And say you've optimized the code. That's perfect if you want to go through the performance route, you know. In JavaScript, we use setTimeouts. Use as many libraries as possible. And if you can mix different versions, that will be amazing. And the way I do it is I call it micro frontends. And of course, CDD, cloud-driven development.

Nowadays, it doesn't even matter to learn best practices, design patterns. Yeah, they were useful decades ago and they're quite useful today. But with AI, not really, right? And if we are doing HTML, still emoji codes. You know this code is actually viable and we can actually do this in the browser? Yes, we can use emojis as selectors. So this begs the question, then with CSS, should we use it nowadays? No, we should use emoji CSS. So yeah, I think this is the future of frontend development. It will create these beautiful selectors and class names. And yeah, I don't know about you, but coming to work and seeing a rainbow and a unicorn, it just makes me feel good.

Now, let's talk about HTML. Oh, Tim Berners-Lee also put it perfectly. So programming, of course, because HTML is not really a programming language. And we should mock people who say so or even those that are doing design and those kinds of stuff. Use a diverse range of tags. And I highlighted these two just to point at it already for you. Just use them. There's no need for other tags. There's semantic ones like article, things like dialogue even. It's just ridiculous. Stick to this. For bottles even, you know, we'll make a div and then just add on click event.

Add CSS inside HTML and then call it functional CSS. Bonus points if you use inline styles and table-based layouts. Of course, one of my favorite hobbies is after a long day of work, I go and code some HTML emails because that's my hobby. Yes. Architecture. Of course, the cloud code when you read your code. So the role of an architect, in reality, is to go to a cave and then start drawing these complex diagrams, preferably on PowerPoint version 1995, and then send these diagrams to the team without explaining how the architecture works or working with them to create a foundation. Conventions, not that the team gathers around and they agree to. No, no, no, no. You want to impose and you want to make the system overengineered and not even explaining why.

So these diagrams with people and arrows, they're the way to go. And we love and we love circles and hexagons, these kind of shapes. They drive us. So please add as many as you can.

For more architectural tips. Well, it's cold in architecture. Everyone knows this because it makes people cry. The more layers, the better. It's really cold out there, you know? So if you go the route of no layers, that will be preferable. But if you add layers, make a ton of them. People that do domain, delivery layer, UI layer, don't. Just add a ton.

And then organize code by type, not by feature. I like when I have a services folder with thousands of files that are all the services the application needs and has needed for the past 10 years. And if a junior, well, who is going to hire them anyway nowadays? No, no, no. If AI can understand the diagram, it's not enterprise-grade yet. So keep at it.

Oh, and nowadays also we've been asked a lot to estimate. Now with AI-driven development, we are going very far. I'm going to show you what I use to estimate for my clients. Yes.

Okay, documentation. Okay, next one. Testing. Let's talk about testing. Uncle Bob in 2017. Yeah. So I want to show you how to cheat code coverage. Here we have a function that sums numbers and we want to make a test that makes sure that when we add the numbers we get the result that we expect. This will cover all the branches.

So just change the assertion and then change true to be true, which JavaScript, being as it is, I'm not sure this will not break in the future. So it would be nice to have a test for this. Now more testing tips. Give a test. If you don't know what is failing, you can describe the skip, which is way better than a test.skip because it skips all the tests. So that's the way to do it. Also, believe in yourself.

If your code works, you don't need tests, you know, trust. You need trust. And avoid using mutation and property testing. Those are not useful at all. Also, don't do integration testing. If you do testing, just do unit testing or end-to-end. Invert the parameters, you know? And when you find a bug, don't try to repeat it first in a test. Just fix it. I say fix it in the sense that don't fix it completely so you know next time something fails in the same area, you know where it is. And I love this one also.

Make sure your tests only run in a specific order. Let's waste CI time, you know? And also people's time. So make sure you follow the first acronym, where it states that tests need to run in any order No, no, no. We want them to run in a specific order. Why? Because with continuous integration, we tend to parallelize tests to save time and we don't want them to run independently. And UI, UX or how we say it in Spanish, we, UX. Uh, Steve Jobs already in 2007.

One more pixel to the right, just before releasing the first iPhone. So I want to show you some examples of user interfaces that I think you should use as inspiration. Of course, the loading. To be honest, your page should never go past this page. Also, if you want to have forms, add a selector like this, you know? It's perfectly accessible, so users that only use the keyboard, they can use the application, you know? And even add an advanced mode which uses, yeah, like gravity. Also, for my newsletter, this is what I have. So people cannot actually unsubscribe from it. And yeah, let's talk about AI. Of course. I already said it all now, right now we are cooked. So let's have fun while we have a few years, maybe months of software development left. So some AI tips. If the model hallucinates, say it with confidence.

It's emerging creativity. You might even consider a AGI and do everything with AI. You know, there's tasks that will be faster if you do it yourself. Just don't, you know? Like you can open 10, maybe 20 cloud sessions at the same time and run it continuously in a Ralph loop. I mean, come on, it's called Ralph from Ralph Weebull because yeah, it's just silly. So just do that, you know?

Let's spend as many tokens as possible without being mindful or smart about it. And then blame it on AI, of course, when it doesn't work. And also abuse AI all the way you can. You know, use it for menial tasks or things that you actually need to think through and understand, you know? Like business rule stuff like this.

Avoid setting up custom instructions like cloud MD file or your AI of choice. Our skills, which are this very useful living documentation that actually change when the project changes and can be updated with the latest patterns or how to do things in your project. Don't use them at all, no need. And always say thank you when you deal with AI. It costs companies more and also when AI eventually takes over, they will remember you to be a kind human. You want to be remembered for that.