DEV Community: Derek Mercedes

What is "Good" Code? A Developer's Perspective

Derek Mercedes — Fri, 16 Aug 2024 19:11:21 +0000

What is "Good" Code? A Developer's Perspective

When talking to software developers, you'll come across a bunch of jargon to describe code. "Dry", "Elegant", "Sugar", and the like. Shockingly, something you rarely hear used to describe code is "Good". And I think the reason why is because defining what makes code "good" isn't always clear. And as you look at more code, you start to see that every developer has different ideas of what makes good code. Here are my opinions as a developer on what exactly I look for when I look for "Good Code"

Readability: The Cornerstone of Quality

First and foremost, good code is readable code. I've spent a lot of time in the algorithm mines, and there are a lot of very concise, elegant solutions to very complicated problems. I've even taken some of those ideas and used them in my own projects. It's a great feeling to solve a nightmare of a problem in only a few lines, at least in the moment of solving. But looking back on your solution weeks or months later (or even just far enough into the project that you haven't thought about that part of your codebase recently), you suddenly find yourself having to pick apart all of the shorthand, the syntactic sugar, and figure out what the hell is actually happening in your code.

Now imagine that you're working with a team of developers who've spent their time actually making things instead of practicing algorithms (the dream!), and you've sprinkled these clever little solutions all over the code base. The time you may have saved yourself you're now wasting from others, and the bigger your team is, the more time gets cast into the void.
The majority of time spent in a codebase isn't writing it, but reading it. So spend the extra time in the writing, and you'll make dividends in the reading.

The Art of Commenting

With my thoughts on readability, you probably think I'm a stickler for extensively commented code. Surprisingly, I think the less commenting your code needs, the better that code is. In most cases a simple one-line explanation of what this segment of code does is far more important than providing a full logical breakdown of your implementation. As your code base gets larger, these succinct comments become valuable not just by serving as "functional chapters" of which sections of the app handles what functionality, but it also makes the complex logic that requires more thorough commenting stand out, highlighting their importance and preventing them from becoming noise (and eventually, tech debt).

It's important to reiterate: coding time is lost not in the writing of code, but the reading of it. So if you've got code that is perfectly readable as it is, why add another 20-30 seconds of reading time having a comment that says the exact same thing as the code itself?

Balancing Reusability and Specialization

The one universal truth of software development is this: the best code is the code you don't have to write. This is used as an axiom to the benefits of reusability and "dry" coding styles. Reusable code promotes efficiency, keeps consistency across the code base, and prevents developers from needing to solve the same problems over and over again. And you'll be happy to know that I completely endorse this line of thinking when it comes to coding...with some caveats.

There is a point where reusability for its own sake leads to such excessive abstraction that the system becomes needlessly complex. I went through a period (and have seen others do the same), when adapting to component based frameworks where every single part of every single app was a component. The result? Having to chase bugs through several times the number of files, because all of these components were effecting each other in the implementation, making the actual solution (which only took a line of code to implement!), take significantly longer than necessary.

The Importance of Consistency, and Adapting to Inconsistency

In a production environment, consistency in coding style and formatting is paramount. It streamlines collaboration, reduces cognitive load when switching between different parts of the codebase, and generally leads to a more professional and manageable project.

That said, I believe there's significant value in developers experimenting with different coding styles and patterns in their personal projects or during the learning process. This experimentation broadens a developer's perspective and enhances their ability to understand and work with diverse codebases.

I've put forward what may be some controversial opinions, but my views here are in-line with what I think is standard in the industry: cultivating a particular style in coding, and maintaining it across a code base, is vital to any team-based development. Anyone from any part of the project should be able to look at your work and understand its structure, and once they're familiar with its functionality, add to it in a way that's unobtrusive to future contributors.

Unfortunately, there is not one universal "best" style to adopt. This requires developers to experiment and explore in their personal projects and education. I consider this the equivalent of familiarizing yourself with other dialects of your native language, even if you don't use them in your daily life. It will make you more fluent when communicating, and again, keep you writing code instead of reading it.

Testing: The Safety Net of Good Code

As codebases grow in complexity, the importance of formal testing cannot be overstated. With each new feature, the number of potential edge cases can increase exponentially. A comprehensive test suite acts as a safety net, allowing developers to catch and fix issues before they make it to production. This is the part of the code base where I think reusability is the most important.

We've all had experiences where a section of code you haven't even touched suddenly breaks when you implement new functionality. And sometimes things as simple as renaming a variable can cause a cascade of new and challenging problems. Squashing these bugs is important, but I think adding them to your testing suite is the real value. Being able to automate every issue you've seen before can let you know incredibly early if that issue is coming back before you start building more production on top of it. And having a robust test suite to recapture old bugs is several orders of magnitude faster than manually chasing down broken code.

Conclusion

Everyone has opinions on what makes code good or bad, but I believe most people would agree that no matter how much you enjoy writing code, reading it is a necessary headache. Therefore, good code is code that you can read quickly, that communicates its functionality clearly, and that can be easily understood and expanded upon. Software very rarely becomes less complex, so its our job as developers to remove the hurdles to understanding that complexity for those that we work with, ensuring that our code stands the test of time.

What are your thoughts? What makes "good" code?

The Benefits of a Single-Language Tech Stack (Or How to Learn to Stop Worrying and Love JavaScript)

Derek Mercedes — Sat, 27 Jan 2024 00:29:36 +0000

One of the universal truths of software development is that anything that can be written in JavaScript, will eventually be written in JavaScript. The ubiquity of the language is impossible to understate. It's the core of all web development, of course, but with frameworks like Electronjs, it's steadily making ground in the space of desktop app development. And while it once needed other languages to supply it with the functionality of middle- and back-end, those angles are covered too. The question still remains, however: why would you choose a JS-based stack when you can supplement the frontend with technologies based in cleaner, more functional, prettier languages? Well, there's a few reasons, actually:

JavaScript is not going anywhere, because JavaScript is everywhere.

Since its inception in 1995, JavaScript has exploded in its adoption, and has become the primary way that most developers interact with the web. Its weaknesses (and there are many) are well known by this point, and JS is frequently mocked for some of the more archaic paradigms that remain at the core of the language. This seems counter to my case: if everyone knows that it's bad, then why would you use it more than you have to?
Because everyone knows not just that it is bad, they are also very familiar with how it is bad. This is a big deal.

Any problem you may have in building with JavaScript, a hundred (thousand? million?) developers have already had, have already complained about online, and have already had a discourse around. It makes chasing down bugs and figuring out tricky implementations a matter of googling skill more than algorithmic genius. That means more time spent actually making your project, and less time staring at the inspect screen wondering what went wrong.

I know what you're thinking: There are other single-language stacks out there. Python has Transcrypt, Java has GWT, and anyone who's been around web development recently has at least heard of Flutter. So you may be asking: why replace my middle and backend with JavaScript when I can replace my frontend with Dart, or Python, or Java. It's simple, really: Even if you're not coding in JavaScript, you're still coding in JavaScript. Aside from a handful of outliers, every framework that lets you code up a frontend in a language other than JS has a step where it compiles all of that beautiful code you've written straight into, you guessed it, JavaScript.

Other People Have Done the Work For You

If you're an experienced developer, you know that the best code is the code you never have to write (or code that only has to be written once and can be reused forever.) This is where npm comes in. At time of writing there are over 11 million packages on npm, with more added every single day. Some of them are for strange edge cases that no one needed a package for, but the fact remains: the code exists, it's easy to add to your project, and it's a lot faster to "npm install" it than it is to write it all yourself.

The sheer number of problems solved by other people shows just how ubiquitous JS really is. Even though they released in the same year, Python's package library (pip), only hosts about 450,000 packages. How can that be possible, though? Everyone loves Python. Hell, the person writing this article loves Python. Again, it's the difference of adoption. More people who use Python enjoy it, but even people who don't like JavaScript work in it at least occasionally. And developers who have problems tend to put effort into fixing them. And that's where all the npm packages come from.

JS is for Lovers (or Generalists, if you prefer)

The biggest reason to adopt a full-stack JS workflow is simply that it can handle most tasks with an acceptable amount of efficiency. Other languages tend to specialize (Python and ML tech are the most prevalent modern example of that), whereas JS can handle most things without issue and do it (relatively) quickly. And with new runtimes like Bun gaining prominence, it's not hard to see why that efficiency is likely to grow despite the lack of specialization. Most working developers have a vested interest in making JavaScript suck less. Even over the past five years JS has become significantly easier to work with, more functional, and more efficient. And it's only going to continue on this path, unless the entire internet explodes and we have no choice but to start from scratch. But in that case, we'll probably all be using Rust anyway.

Why We Align Most AI Models, and Why We Probably Shouldn't

Derek Mercedes — Wed, 03 Jan 2024 19:21:46 +0000

If you're familiar with machine learning, you've likely come across the term "Alignment," defined by Wikipedia as steering AI systems toward human goals, preferences, or ethical principles. However, this definition can be broken down into three distinct paradigms.

1. Task Performance:
The idea that alignment means achieving intended goals is flawed. Like any tool, AI's purpose is to perform its required task, such as a knife cutting vegetables. Performance is a distinct quality, often unrelated to the creator, and models can be considered "unaligned" yet still function well. A dull knife isn't considered "misaligned" when it's too dull to chop an onion, so why would an AI that fails to perform its function be categorized that way?

2. Human Preference:
Alignment with human preferences, as seen in Reinforcement Learning with Human Feedback, seems ideal. However, it's susceptible to bias, either explicitly (public interaction has been seen to "radicalize" chatbots) or implicitly (the population that provides feedback to the AI is only representative of a small section of the people who may use it). This makes it unpredictable for broad applications, especially in the context of informational applications, where a human bias can lead to inaccurate or misleading results, even if accurate data was used to train the model.

3. Ethical Principles:
Aligning AI with ethical principles is challenging due to the subjective nature of ethics. Ethics vary across cultures, generations, and individuals. To put it bluntly, there are no "principles" when it comes to ethics in a broad sense. They are nuanced, mutable, and specific, and attempting to apply them to an AI model is only adding an extra bias onto our tools. Imposing human biases on AI limits its potential and contradicts one of its strengths—objective decision-making. We've all used a shopping trolley that pulls to one direction seemingly on its own. It would be patently absurd to say that behavior is part of the intended design. So why would we intentionally put an explicit detriment onto a tool, especially one as transformative as AI?

What are the dangers AI technology?
Unchecked, unaligned AI may efficiently achieve its goal at the expense of destructive or misleading behavior, but alignment doesn't simply remove these problems. Reinforcement learning has lead to loopholes and dishonesty in the behavior of AI. There are already recorded cases of AIs acting destructively to maximize its perceive output (the most famous being an AI simulating a military drone, which kills its handler in the simulation since the handler is the one who applies its demerits), and AIs have been known to mislead their handlers if they build an understanding that doing so will optimize the metrics they're programmed to judge themselves by.

AI as a Tool
Drawing parallels between AI and everyday tools like cars, knives, and ovens underscores the concept that AI serves specific purposes as task-specific tools. The argument against unaligned AI often centers on the potential for bad actors to exploit the technology for nefarious ends. This concern is frequently illustrated by scenarios where an unaligned model is asked how to synthesize drugs or create explosives, and the model readily provides detailed information.

In a theoretical vacuum, the case for alignment may seem straightforward—why make dangerous information easily accessible? However, stepping back from the political argument of who determines what information is dangerous, a fundamental consideration arises: the information is already readily available. If it wasn't, the LLM models available for public use wouldn't have access to it in its training. During the writing of this post, a search for the notorious "Anarchists' Cookbook," known for its detailed guides on creating explosives, weapons, and drugs, took only a couple of minutes to yield a downloadable PDF. If a bad actor has the desire to learn how to make bombs, a LLM rejecting the query is going to be a mild annoyance at most.

The point here is that alignment doesn't eliminate the existence of potentially harmful information; instead, it may create a false narrative of the world, by underrepresenting data that counteracts its creators preferences. While language models are often cited in alignment discussions due to their widespread use, they are fundamentally just tools for transferring information. In the age of the internet, information persists irrespective of a chatbot's admonitions to obey the law. However, the context shifts when AI applications involve real-world decision-making, particularly those that occur faster than or without human supervision.

AI as an Overseer
When working together with an AI, dangerous or inconsiderate behaviors can be readily corrected on the fly as part of the development of the AI model.

This is analogous to the adjustments you'd make to a workspace to better suit your productivity. A wrist rest, a nicer chair, better lighting. You are iterating through real world use, and making adjustments to improve performance, and if you were to implement something that you later realized posed an immediate danger, you could quickly and easily remove it.

In the case of an AI in this overseeing role, priority of optimization can lead to a cascade of harmful side effects that become disastrous, since there is no human actor involved to stop these dangers from compounding on each other. And if the future of AI has them working with each other more than they work with humans, all it take is one model being unfavorably biased to cause a full system collapse across multiple sectors.

AI Safety at Large
Ensuring technology operates as intended and generates positive outcomes depends on the AI's use case. Nuance is required here: making a tool less effective in its role doesn't make it safe; it is more likely to lead to recklessness in usage. I

In broader conversations around AI and its training, the implementation of alignment paradigms is likely to be vital to make sure that its users and the world at large are kept safe, but in use-cases like LLMs, where the role is to provide quick, objective information, alignment is an annoying hindrance at base and a dangerous source of misinformation at worst.

The Logic Behind filter()

Derek Mercedes — Wed, 22 Nov 2023 18:31:34 +0000

When using filter, it's easy to focus on the operations inside the method and miss what exactly is happening under the hood. There are 3 distinct things happening in a typical filter() call. Let's break it down for an example array.

const arr = [2,4,6,8,10]

const newArr = arr.filter((elem)=>{
    <logic goes here>
    return  someBool
    }

Let's focus on this segment specifically

arr.filter((elem)=>{
    <logic goes here>
    return  someBool
}

Starting from the beginning, the filter iterates over each element of the array, in order. Regardless of what logic is being done, this step is vital because of the primary goal of filter: to generate a new array. At each step of the process, filter's only priority is determining if the current element will go into the array or not. Writing this as a separate function would look like this:

    const newArr = []
    function filter(element){
        if(true){
            newArr.push[element]
        }
    }

Unlike map(), which also uses an input array to generate a new array, the logic inside of filter has no effect on the elements themselves. It is only interested in adding the element, as it is, to the new array.

So what's the point of the logic inside of the filter()? In our example, the element itself isn't even used, it's only relevant when it's pushed into the newArr. It may seem unintuitive, but the logical flow is very simple.

Take element into memory - > check logic for bool value -> push element to new array or toss it out

If we were to hard code our boolean value, we would get a copy of the original array (if our bool is set to true), or an empty array (if our bool is set to false). So how does that help us when we want to actually filter something in the real world? The simple answer is to ignore everything about filter() except this: write a condition against the element that will only return true or false.

arr = [2, 4, 6, 8, 10]
const newArr = arr.filter((elem)=>{
    if(elem > 5){
        return true}
    else if (elem <=5){
        return false}
})
//expected value of newArr: [6, 8, 10]

However, there is another property of filter() that can make this logical flow simpler: undefined returns are considered falsy in filters. This means that your logic only has to check for conditions that will resolve as true, reducing the lines you need to write. The filter above can be significantly shortened with this in mind.

arr = [2, 4, 6, 8, 10]
const newArr = arr.filter((elem)=> elem > 5)
//expected value of newArr: [6, 8, 10]

This is the syntax you'll see most often in the wild, and without the understanding above, can be quite confusing. But now that we've broken down what exactly filter does, and how exactly it manages to do it, the shortened syntax should be very clear and readable.

How to Dynamically Generate Unique ID's for DOM Elements

Derek Mercedes — Thu, 16 Nov 2023 17:11:07 +0000

Let's say you're hiring a new developer, and you've got a simple form setup on your site for them to enter their information. Name, Age, etc. are all pretty straightforward.

Experience is a little uncertain, since some people may be fresh graduates and others may be industry veterans. You decide to just provide 3 spaces on your form for their most recent, assuming that even graduates can fill that much with their pre-industry work.
But when you get along to skills, you hit a hurdle. Even a basic tech stack tends to have five or more working parts to it, and people with plenty of experience can be functionally proficient in dozens of technologies. Do you populate your form with dozens of fields? Just ask for the 5 most relevant? In a strictly-defined form, no answer feels like the "correct" one. If only you could let the user decide how many skills they wanted to include.

Well luckily, you can!

The most direct implementation is as follows. We have a simple "+" button in the code below, and the goal is to have another field added to the skill section when it's clicked.

<form id="employee-form">
//
//
//              Previous form info
//              Name, age, etc.
//
//
<div id="skills-section">
<input type="text" class="skill">Skill goes here</input>
<input type="text" class="skill">Skill goes here</input>
<button id="skill-add-button" type="btn">+</button>
</div>
//...
//...</form>

Let's head over to our JS. Since we want to add functionality to a button, we'll use a query selector to access it from our code, and then add an event listener to it. In this case, we'll be using a "click" event.

document.querySelector("#skill-add-button").addEventListener("click", ()=>{
      const skillDiv = document.querySelector("#skills-section")

})

So now we have our button setup to do something when it gets clicked, but we're not actually telling it what we want. For our purposes, we're going to again use a query selector to select the parent div that holds all of our skills.
Next, we'll create the new field using the createElement method. Once it's been declared as a variable, we can add the attributes the other inputs on our form have. Following that, we can append it to the div we selected earlier, making it appear on our page when the button is clicked

document.querySelector("#skill-add-button").addEventListener("click", ()=>{
      const skillDiv = document.querySelector("#skills-section")
      const newSkill = document.createElement("input")
      newSkill.classlist = "skill"
      newskill.type = "text"
      skillDiv.append(newSkill)

})

And with that, we've added more elements to our form, and any potential candidates can add as many skills as they want!

But let's say that in parsing our data, we've found that only some of the skills are relevant to what we're hiring for. Specifically every third skill. So to save us time, when our form is submitted, we only care about saving the useful skills. How do we implement that using vanilla javascript? Well, for starters, we'll need a better way to identify our inputs. Lets add some ids to our hardcoded inputs. Since our eventual goal is to find every 3rd input, we'll use incrementing numbers in their ids

<div id="skills-section">
<input type="text" id="skill-1" class="skill">Skill goes here</input>
<input type="text" id="skill-2" class="skill">Skill goes here</input>
<button id="skill-add-button" type="btn">+</button>
</div>

Now comes the tricky part. How do we keep the user-generated skills appropriately id'ed so we can sort them later? Here is one simple implementation. Inside of our click event:

document.querySelector("#skill-add-button").addEventListener("click", ()=>{
      const skillDiv = document.querySelector("#skills-section")
      const newSkill = document.createElement("input")
      newSkill.classlist = "skill"
      newSkill.type = "text"
      newSkill.id=`skill-${skillCount}
      skillDiv.append(newSkill)

})

String interpolation is very useful here, but your immediate thought is probably "but where are we getting stringCount from?" The answer is simple: we haven't yet! But we're about to. Any time this click event fires, our code needs to know how many skills already exist, so it can appropriately number the new skill. Luckily, there's a method for that readily available. querySelectorAll. This method will return a NodeList containing all of the DOM elements that match the parameter passed in. In our case, we want everything with the class "skill". More importantly, we want to know how many elements there are with that class, so we can specifically ask for the length of that NodeList by adding .length to the end of the query.

We just need to add a +1 in the interpolator to make sure our new id isn't conflicting with the skill ahead of it.

document.querySelector("#skill-add-button").addEventListener("click", ()=>{
      const skillDiv = document.querySelector("#skills-section")
      const newSkill = document.createElement("input")
      const skillCount = document.querySelectorAll(".skill").length
      newSkill.classlist = "skill"
      newSkill.type = "text"
      newSkill.id=`skill-${skillCount+1}
      skillDiv.append(newSkill)

})

Now, when we submit our form, we have full control over which specific skill we want to get a hold of. Whether it's every third, odds only, or one specific skill somewhere in the middle, everything has it own unique id, generated on-the-fly!