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 César 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 will have more information on my website available. And I'm here to 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 haven't 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 burned, you know, and then demand goes up and then we have more money for you. So, that's why 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. Best practices are boring, you know, they've been written and talked about for decades already and they're the same. So, I like to approach every day in my job as something new and where I may find new opportunities to create 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, we 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, no types allowed.

Let's talk about coding. So, with coding... Ah, yeah, Barbaris Koff 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, make people, you know, like, oh, where's x1? I cannot find it. Well, there's not. I make sure that my teammates, they have very sharp minds, you know, I always test them.

Of course, we can have confusing function names. Let's see this function, in reality, what it does? It adds numbers. What about if the code is minor? And then, you can have inconsistent recommendations, you know, we can have a common case, a snake case, yeah, why not? They were invented for a reason, so let's make sure we use them. And, of course, those were coming from Java. Overly long variable names. And, of course, if you can see at the end, because we don't use typescript, we don't use types at all, I would not recommend you to do that.

I add the type as a suffix, and in this case is the wrong typeframe. It was true. I, of course, define the code already thinking about what code should I already include commented out. This is, for example, something that I will write from scratch. I'm already adding a comment there. And to make people even more confused, I add a don't delete. AI, not even with this, will understand. So, that's also perfect, you know, make sure we are not replaceable.

And, of course, complex code. So, yeah, this is a nice function for those people that are so well crafted 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 setTimeout. 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 front-ends. 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 selector.

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 front-end 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 primary language. And we should mock people who say so, or even those that aren't doing design, or those kind of stuff. Use a diverse range of tags. And I highlighted these two. I just pointed it already for you. There's no need for other tags. There's semantic ones like article, things like dialog even. It's just ridiculous.

Stick to div. For buttons even, you know? Make a div and then just add on click even. 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. Oh, the cloud code, when you read your codes. 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, no? That the team gathers around and they agree to. No, no, no. You want to impose and you want to make the system over-engineered and not even explaining why. So these diagrams with people and arrows, they're the way to go. And we love circles and hexagons. These kind of shapes, they drive us on. So please, add as many as you can.

For more architectural tips, well, it's cold on 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 would be preferable. But if you add layers, make a ton of them. People that do domain, delivery layer, UI layer, kind of stuff, don't. Just add a ton.

And then organize code by type, okay? 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 junior, 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, you know, in AI-driven development, we are going very fast.

I'm going to show you what I used to estimate for my clients. Yes. Okay, documentation. Okay, next one. Testing. Let's talk about testing. Uncle Bob in 2017. Yeah. So I'm going to show you how to cheat code coverage, okay? 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 do describe the skip, which is way better than a test to 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 test, 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 reproduce 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 don't follow the first acronym where it states that tests need to run in any order whatsoever. 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. 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, 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 all now, right now, we are coofed. 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. We might even consider 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 because 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, those stuff like this. And avoid setting up custom instructions like CloudMD file or your AI of choice. Our skills, which are these 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 AI 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. Yeah, the objective in the end is when AI reads your code, this is more or less its reaction. So yeah, the conclusion, of course, we want Anna, with 23 years old and two years of experience as a software developer, have all this tension, all of this confusion, stress from reading our code that is impossible to decipher, to look like this. And yeah, well, this is not really relevant because it's totally the wrong audience, but there's a book that I wrote about this with this kind of satire. Well, to be honest, it's not really satire. It's reality. It's in Spanish. If you want it, grab it here in this QR code.

If not, I don't care. And now, of course, the objective of this talk was to subscribe to my newsletter. I will give you the chance to do it now. So pick up your phone, take a screenshot, whatever. Ready? Okay. Let's see. Let's see. Yes. Did you manage to do it? No. Good job. Oh, no. Oh, okay. Never mind. So if you have any suggestions for similar practices, please send them over to my LinkedIn, Twitter, whatever social media you are into these days. In most of my social networks, I'm at csalberca. And that's it. Thank you, I guess. Okay. Bye-bye.