Forem: JulesWritesCode

The Second Iteration: Your Key to Finally Writing Excellent Code

JulesWritesCode — Tue, 03 Sep 2024 09:00:00 +0000

Your first version of a piece of code is mediocre at best.

When you start developing a feature, the beginning feels great. You know where the code needs to sit and how to implement it. But halfway through, you bump into an unforeseen problem, and you find yourself copy-pasting if-statements or meddling with data structures. Towards the end, your work feels rough and unfinished, but you’ve already invested hours and just want to finish it.

If you had discovered the problems and quirks beforehand, it would’ve been easy to handle them properly and to write simple code from the outset. You couldn’t discover them, however, since you first had to write the damn thing.

But there’s a simple trick to accelerate making those discoveries and getting a complete picture.

Always throw away the first iteration.

Once I started doing this, my PRs had fewer requested changes, my code produced fewer bugs, and it became easier to integrate subsequent features.

Here’s why.

You’ll arrive at a working version rapidly.

If you throw away everything regardless, you’ll spend less time on making it work.

During the first iteration, I often don’t even implement functions. Instead, I jot down the signature, return mock data or an error, and continue with the important stuff. Since I know that and how the function will work (you must be sure of those two things), I don’t have to spend time on it.

By only spending time on parts I haven’t fully grasped, I’m significantly reducing the time it takes to finish the first iteration.

You’ll get a complete overview before you do the real work.

To understand what your feature requires, you must first make it work.

The rapidly completed first iteration gives you an overview of requirements, quirks, and issues. You can then identify the spots where you could solve problems or make features work elegantly. This will help you a lot once you start the next iteration.

Then, designing an elegant implementation becomes straightforward.

You won’t waste time on unnecessary details.

As devs, we love to worry about variable names or think about performance optimization.

But the temptation of optimizing a lower-level function or rewriting code for readability can suck you in for hours. Worse, after finishing a feature, you might realize you never needed the now-optimized function in the first place. Your time would’ve been better spent elsewhere.

If you consider your first iteration a throwaway, that compulsion to optimize will be easier to resist.

Cleaning up will now be a breeze.

Once you start with the second iteration, starting from scratch won’t feel as bad.

If you invest too much into the first iteration, if you spend too many hours fixing bugs, writing tests, rewriting functions, and optimizing or commenting code, you won’t feel motivated to start over — and understandably so. You don’t want to throw away your work. But if you are less diligent during the first iteration, you are less invested, so it won’t feel like you’re throwing away anything important.

Instead, you’ll feel motivated to start building it right.

The con argument is that this approach takes longer.

But is that the case? How much time do you spend rewriting code once you’ve stumbled upon your first hurdles? Wouldn’t starting from scratch be easier than cleaning up the mess?

Give it a try and see if you like it.

From Bass Player To Startup Engineer in <9 months. Here Are Four Things You Can Learn From My Journey

JulesWritesCode — Tue, 27 Aug 2024 17:26:44 +0000

I started to code when I was 27.

Before, I was a professional musician. I studied pop music, specializing in bass guitar, and made a living playing concerts and recording songs for German artists. In 2020, the pandemic rendered every musician I knew workless, and I had to learn something new.

So, in March 2020, I installed VSCode and got to work.

Nine months later, I got my first self-employed gig as a software engineer. Another three months later, I was hired at Parqet, a fintech company I still work for.

I got lucky for sure, but some decisions greatly impacted my journey.

I want to share those with you.

From Musician to Startup Engineer

My idea to pick up coding didn't come out of thin air.

When Covid hit, I had already thought about it for a while, primarily because I thought Mr. Robot was a fantastic series and I would have loved to hack just like Elliot, and secondarily because a drummer friend had proven it to be a good idea by first learning Splunk and then starting to work at a data-analytics company.

So, when I realized in March 2020 that I would get months, maybe even years of free time, I purchased a couple of Udemy courses and marched down the rabbit hole.

I created portfolio websites and designed pages using flexbox, wrote Express applications, completed CodeWars katas, and devised simple SQL queries. It was fun. However, Germany's job center, typically unsatisfied with anything that doesn't involve an official licensing paper, kept calling to ask about my career plans and how I intended to make money.

So, in September 2020, in an attempt to soothe the bureaucrats, I started a web development bootcamp.

At that point, I had already learned the basics, so most of the course's topics came effortlessly. The questions I did have were more advanced than those of the other students. Some instructors struggled to answer, but one, Joe, was excited to be challenged. He quickly took me under his wing and became my private mentor.

After I finished the course, Joe asked for help with his startup.

He had built a fintech application and wanted me to add a multi-language mode. I did my best, which was terrible then, but he was happy about the result. Joe didn't have any more work afterward, but he recommended me to another founder in the fintech space.

That founder's name was Sumit, and I started working with him at Parqet.

When I started, we were two engineers on the backend: junior me and senior Kevin (an incredibly talented guy and by now a friend; he currently works at Supabase).

This equaled private mentoring, so I learned a ton.

We've since evolved into a team of five developers and Parqet continues to grow steadily. Considering the pay, remote work hours, and the responsibility and freedom I have (and anything else, really), it's a dream job.

What I would do again

I love practicing. During music university, I regularly locked myself in the basement for four hours or more to work on bass lines, scales, technique, and timing. To this day, I love such a strict regimen.

So, in bootcamp, I was more of a hard-liner than my peers, trying to squeeze out the maximum learning experience.

While some things were needlessly stressful, here are four things I'd definitely repeat.

1. I'd try to master the basics

There are a gazillion frameworks and libraries in web development.

But regardless of what you'll end up using or what project you'll work on, you'll always deal with the basics. You'll write for-loops and filters to manipulate data with JavaScript. You'll choose the correct HTML tags for your cards and navigation menus. You'll write CSS to make your content readable and your UI easy to navigate.

The better you understand those basics, the more productive you'll be.

Plus, a firm grasp of the basics is a requirement for getting hired.

A team of senior developers will enjoy and benefit from teaching you advanced concepts, but if they must teach you how CSS and JS work, they're wasting precious time explaining something you could quickly learn on your own. Not knowing the basis means slowing down your team.

So don't waste time learning all the shiny new tech. Instead, master your HTML, CSS, and JS.

Here's an incomplete list of concepts you should know inside out:

JS: Closure, event-loop, Array & Object methods, prototypes, "this" keyword, async-await
CSS: Specificity rules, flex & grid, inheritance, positioning, etc.
HTML: the most common tags, inline- vs. block elements, accessibility, inputs, buttons, etc.

2. I'd purchase multiple sources of information

I didn't only buy one course or book on JavaScript – I bought many.

Any learning material, say, an online video course, will try to explain mental models of its core topics. You won't understand some of them, but the issue isn't that you are stupid (though many junior devs regrettably think that about themselves). Instead, it could be the mental model is vague, the course assumes a more knowledgeable viewer, or the teaching style doesn't resonate with you.

What helped me overcome these issues was having multiple sources of information.

For example, I struggled with async-await. My course didn't explain how the event loop worked, so I didn't understand how JavaScript could wait for a task to finish and simultaneously do other tasks. My mental model was incomplete. I had no chance of understanding it.

Thankfully, the second course and another book I had purchased brought relief. The additional info bridged knowledge gaps, and I finally could comprehend the topic.

3. I'd try to force myself out of my comfort zone

Learning to code is like learning to speak a language.

When learning Spanish, you can't expect to get better by only repeating what your audio-book instructor says. You need to speak. You need to express your own thoughts using vocabulary and grammar you're unfamiliar with.

But most coding newbies don't do that.

Instead, they go through tutorials step-by-step and mindlessly follow instructions.

Doing so won't teach you anything. To improve, force yourself to think and work like a programmer: Equip yourself with knowledge, pick a problem, devise a plan to tackle it, and debug and research and fumble your way to the solution.

In short, step outside your comfort zone.

You can achieve such a learning experience with books and courses, provided you use them right. Instead of reading a paragraph and immediately executing the instructions, read the entire chapter. Take notes on objectives and upcoming stumbling blocks, then close the book. Try to complete the tasks using only your memory and notes, and reopen the book only if you've been stuck for at least twenty minutes.

Doing this, you'll be outside your comfort zone. But there's no reason you won't finish the project; due to your initial read, you have sufficient knowledge to not be overwhelmed.

You'll internalize more lessons than by only going through the motions.

4. I'd spend time to meet people and maybe find a mentor

A single friend with contacts can save you from writing 100 applications.

I knew this from my days in the music industry, and meeting Joe, who later introduced me to Sumit, further confirmed it. But meeting people can, amidst coding tutorials and writing applications, and since the results of meetups are not directly measurable, become an afterthought.

It shouldn't.

Instead, you should treat meeting people as an obligation, a higher priority on your to-do list (without becoming a sociopath, of course).

Spend two hours researching which developers who share the same tech stack or interests live in your town, which meetups happen regularly, and whether there are any large events like web development summits within driving distance. And then, visit them! I've been, for instance, to indie-hackers and Supabase meetups and had several coffee chats.

You might even find a mentor.

Receiving feedback from an experienced developer is the best way to accelerate your learning journey. I was lucky to work with Kevin during my first years at Parqet. While I sometimes felt frustrated when I revised my code according to his critique for the umpteenth time, the result was always better. Years later, I still draw on his lessons.

If you're willing to learn, finding someone who takes you under their wing is easy.

People enjoy helping others, especially those they like.

Parting Words

You might spend extra cash or time following my advice, but I'm confident it works.

Following those tips won't guarantee that you will get a great job quickly. Still, I believe they will significantly increase your chances. They certainly increased mine.

I wish you all the best on your journey. Please share any other tips or success stories you have.

The Junior Developer's Complete Guide to SSR, SSG and SPA

JulesWritesCode — Tue, 20 Aug 2024 08:02:59 +0000

Every dev tools company and -team seems to assume that Junior Devs are familiar with these terms.

When I started to code, I saw them everywhere: Nuxt is an SSR framework, you can use Gatsby for SSG, and you can enable SPA mode if you set this or that flag in your next.config.js.

What the hell?

As a first step, here's a glossary – though it won't help you to understand the details:

CSR = Client-Side Rendering
SPA = Single Page Application
SSR = Server-Side Rendering
SSG = Static Site Generation

Next, let's shed some light into the dark.

Static Web Servers

Initially, a website was an HTML file you requested from a server.

Your browser would ask the server, "Hey, can you hand me that /about page?" and the server would respond with an about.html file. Your browser knew how to parse said file and rendered a beautiful website such as this one.

We call such a server a static web server. A developer wrote HTML and CSS (and maybe a bit of JS) by hand, saved it as a file, placed it into a folder, and the server delivered it upon request. There was no user-specific content, only general, static (unchanging) content accessible to everybody.

app.get('/about', async (_, res) => {
  const file = fs.readFileSync('./about.html').toString();
  res.set('Content-Type', 'text/html');
  res.status(200).send(file);
})

Interactive Web Apps & Request-Specific Content

Static websites are, however, boring.

It's much more fun for a user if she can interact with the website. So developers made it possible: With a touch of JS, she could click on buttons, expand navigation bars, or filter her search results. The web became interactive.

This also meant that the /search-results.html page would contain different elements depending on what the user sent as search parameters.

So, the user would type into the search bar, hit Enter, and send a request with his search parameters to the server. Next, the server would grab the search results from a database, convert them into valid HTML, and create a complete /search-results.html file. The user received the resulting file as a response.

(To simplify creating request-specific HTML, developers invented HTML templating languages, such as Handlebars.)

app.get('/search-results', async (req, res) => {
  const searchParams = req.query.q;
  const results = await search(searchParams);

  let htmlList = '<ul>';
  for (const result of results) {
    htmlList += `<li>${result.title}</li>`;
  }
  htmlList += '</ul>';

  const template = fs.readFileSync('./search-results.html').toString();
  const fullPage = embedIntoTemplate(htmlList, template);

  res.set('Content-Type', 'text/html');
  res.status(200).send(fullPage);
});

A short detour about "rendering"

For the longest time, I found the term rendering highly confusing.

In its original meaning, rendering describes the computer creating a human-processable image. In video games, for example, rendering refers to the process of creating, say, 60 images per second, which the user could consume as an engaging 3D-experience. I wondered, already having heard about Server Side Rendering, how that could work — how could the server render images for the user to see?

But it turned out, and I realized this a bit too late, that "rendering" in the context of Server- or Client-Side Rendering means a different thing.

In the context of the browser, "rendering" keeps its original meaning. The browser does render an image for the user to see (the website). To do so, it needs a blueprint of what the final result should look like. This blueprint comes in the form of HTML and CSS files. The browser will interpret those files and derive from it a model representation, the Document Object Model (DOM), which it can then render and manipulate.

Let's map this to buildings and architecture so we can understand it a bit better: There's a blueprint of a house (HTML & CSS), the architect turns it into a small-scale physical model on his desk (the DOM) so that he can manipulate it, and when everybody agrees on the result, construction workers look at the model and "render" it into an actual building (the image the user sees).

When we talk about "rendering" in the context of the Server, however, we talk about creating, as opposed to parsing, HTML and CSS files. This is done first so the browser can receive the files to interpret.

Moving on to Client-Side Rendering, when we talk about "rendering", we mean manipulating the DOM (the model that the browser creates by interpreting the HTML & CSS files). The browser then converts the DOM into a human-visible image.

Client-Side Rendering & Single Page Applications (SPAs)

With the rise of platforms like Facebook, developers needed more and faster interactivity.

Processing a button-click in an interactive web app took time — the HTML file had to be created, it had to be sent over the network, and the user's browser had to render it.

All that hassle while the browser could already manipulate the website without requesting anything from the server. It just needed the proper instructions — in the form of JavaScript.

So that's where devs placed their chips.

Large JavaScript files were written and sent to the users. If the user clicked on a button, the browser would insert an HTML component; if the user clicked a "show more" button below a post, the text would be expanded — without fetching anything.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
  </head>
  <body>
    <div id="root"></div>
    <script>
      document.addEventListener('DOMContentLoaded', () => {
        const root = document.getElementById('root');

        root.innerHTML = `
            <h1>Home</h1>
            <button>About</button>
        `;

        const btn = document.querySelector('button');
        btn.addEventListener('click', () => {
          root.innerHTML = `
            <h1>About</h1>
        `;
        });
      });
    </script>
  </body>
</html>

Though the code snippet suggests the opposite, developers didn't write vanilla JavaScript.

Ginormous web apps like Facebook had so much interactivity and duplicate components (such as the infamous Like-button) that writing plain JS became cumbersome. Developers needed tools that made it simpler to deal with all the rendering, so around 2010, frameworks like Ember.js, Backbone.js, and Angular.js were born.

Of them, Angular.js was the one that brought Single Page Applications (SPAs) into the mainstream.

An SPA is the same as Client-Side Rendering, but it is taken a step further. The conventional page navigation, where a click on a link would fetch and render another HTML document, was taken over by JavaScript. A click on a link would now fire a JS function that replaced the page's contents with other, already preloaded content.

For this to work properly, devs needed to bypass existing browser mechanisms.

For example, if you click on a <button type="submit"> that's wrapped in a <form> element, the browser normally sends a POST request to the server and renders the HTML file of the response (an agreed upon standard all browsers conform to). But, since the server had already sent all the instructions, and the browser had now taken control over rendering pages, that behavior needed to be prevented.

Devs invented all kinds of hacks to bypass this and other mechanisms, but discussing those hacks is outside the scope of this post.

Server-Side Rendering

So what were the issues with that approach?

SEO and Performance.

First, if you look closely at the above HTML file, you'll barely see any content in the <body> tags (except for the script). The content was stored in JS and only rendered once the browser executed the <script>. Hence, Google's robots had a hard time guessing what the page's content was about — in fact, they couldn't guess anything.

The site couldn't be indexed and thus wouldn't rank highly on Google.

Second, since the browser would only send a single request to the server and then continue to render the SPA on its own, all content that could ever be rendered had to be delivered with the initial request. With large web apps, this could easily surpass a couple megabytes, which slowed down the page load significantly. Amazon conducted a study that concluded businesses would lose 1% of revenue with every 100ms in added page load time, so that was a huge no-no for most companies.

In short, developers needed to create HTML files on the server again.

But they couldn't circle back to templating-languages and request-specific content — by now, everybody was writing React, and they loved the component-driven approach. Wasn't there a way to write React and render it on the server? Of course! With the advent of Node.js, developers were already writing JS on the backend, and the road to full-stack frameworks such as Next.js or Nuxt was paved.

Those frameworks render React (or Vue, Svelte...) on the server. Basically, React turned into a templating language such as Handlebars.

// List.tsx
import React from "react"

export const List = (props: {
  results: { title: string }[]
}) => (
  <ul>
    {props.results.map((r) => (
      <ListElement title={r.title} />
    ))}
  </ul>
)

export const ListElement = (props: { title: string }) => (
  <li>{props.title}</li>
)

// server.ts
app.get("/search-results", async (req, res) => {
  const searchParams = req.query.q
  const results = await search(searchParams)

  const fullPage = renderToString(
    React.createElement(List, { results })
  )

  res.set("Content-Type", "text/html")
  res.status(200).send(fullPage)
})

(Note: the only difference to the "Request-Specific Content" approach is that we're now using modern frontend frameworks to write our HTML.)

Static Site Generation

Great, so our pages were indexable and fast again.

However, some sites weren't as fast as they could be.

If the content didn't change (like the page of a blog post), why should the server newly fetch and build the HTML for every user visiting the page? That seemed wasteful. Wouldn't it be enough to build the HTML once and reuse it whenever somebody requested it?

That approach is called static site generation.

In contrast to the original static web server approach, where developers manually wrote and stored HTML files on the server, here, the HTML files were generated:

Non-technical people wrote content and uploaded images in a CMS (Content Management System, such as WordPress or Sanity). Developers wrote React components, used the CMS's API, and executed a build script that fetched the data for every page and built the HTML file according to the outlined blueprint. The finished file was then stored on the server, ready to be delivered upon a user's request.

Developers could then re-trigger the build script to create new files when new content became available.

The new kid on the block: Server Components

As of August 2024, React Server Components (RSCs) – though still marked as experimental – are all the rage.

The basic idea is this: Before RSCs, a React Component first had to be delivered to the client. There, it would render and, if it needed to fetch data, send another request to the server; it had to wait for the response and re-render. This is wasteful. RSCs make it possible to both fetch the data and render the component on the server. Only the finished, isolated HTML component is sent to the client, and there merged with the existing HTML – the rest of the page is left as is.

The result is a much better performance: less back-and-forth between the server, fewer kilobytes over the network, and less re-rendering.

Plus, you can await your data right in your React Code, making it much simpler to write.

But, as usual when new features are added to existing frameworks, RSCs make React much more complex. You must constantly consider whether you need a component on the server or the client; caching layers are involved; interactivity is impossible with RSCs – tl;dr, the waters are still muddy.

As a counter-movement, developers who are fed up with the front-end complexity have started to write and favor simple frameworks, such as HTMX.