DEV Community: Jackie Cisneros

Engineers Decide, Agents Execute: Why Small Teams Are the New Default

Jackie Cisneros — Thu, 15 Oct 2026 10:10:45 +0000

At WhaleHawk, I lead an engineering team of five. We build a sales intelligence platform for healthcare executive prospecting. That's a small team by any measure, and with the right AI workflow, it's the right size.

Why do we keep our team this size? Building your people assets at the end of 2026 is not about putting bodies in seats. With the power of the coding bot, it's actually a liability to host that approach -- even a partial degree of misdirection will throw a coder seriously off course with the tools at hand.

With our team, we stopped treating AI as autocomplete and started treating it as the workforce, with one non-negotiable rule:

The engineer is the decision point. The agent does the work.

If you're a founder or eng leader planning next year's team, here's my take. A small team with an AI workflow is no longer the scrappy option. It's the new default, and how disciplined your team is will decide how far and how fast you can go together.

The rule is simple. Living it is not.

"Engineers decide, agents execute" sounds obvious. Actually putting it into practice is a different story -- especially on a small team where everyone has real autonomy and nobody is waiting around for permission.

Autonomy is why small teams move fast. It's also how a codebase quietly fills up with decisions nobody made on purpose. Hand an agent a vague ticket and it will make a dozen design choices for you. For me, as the one driving our technical and product direction, that is terrifying.

To combat this -- and I do mean combat, because it takes an active defense -- we built a process with one job: make sure every meaningful decision is made by a human, out loud, before an agent writes a line of code.

How we work: decisions first, code last

Talk it through. Every piece of work starts as a conversation, and it is based on a real need -- an engineer should never write code for a feature we cannot explain the requirements for.
Write the proposal. It covers what we're building and why, plus mockups and other assets from the rest of the team. People have to read it and approve it, and most importantly, talk about it.
Write the technical spec. The spec is essentially pseudocode, and is our internal pulse check -- are we alive and making the decisions for how this fits into our system? Are we following engineering best practices? Is this thoughtful?
Plan it in Linear. We create a project and milestones. That's the map of how we'll get it done, usually broken down into thoughtful chunks of work. This keeps the scope manageable, and can help us understand timelines and expectations for QA.
Scope the issues. Each Linear issue is a piece of work of roughly 800 lines of code or less, and directly solves the problem captured in the milestone.
Attach everything in the PR. We want the agent empowered to go back through our history, understand the decisions made and why, and debug according to spec, not to symptom. Each PR is sized so our pipeline manager can review it against the spec in one pass.

Why we cap issues at about 800 lines

Scope is the agent's guardrail. An issue capped at roughly 800 lines is small enough to review in one sitting and specific enough that the agent can't wander.

It also leaves a trail. When something goes wrong, we can regress to a specific issue and say, "Okay, this is where we go back and fix what we did." The agent can follow that same trail, because the work was scoped into issues from the start.

Big, fuzzy tickets are where AI-generated code goes to rot -- the agent fills every gap with a guess, and you don't find out which guesses were wrong until something breaks. Small, scoped ones keep the code clean, keep the engineer in charge, and leave a paper trail.

The handoff is the leverage

Here's the part that changes the math for small teams. Once the proposal and the spec are approved, and the pseudocode makes sense for the application, I can hand off the implementation completely.

Is that blind trust in the robot? Not even close. Handing off the build is not about stepping away -- it's about doing the hard thinking up front, so that by the time the coding bot picks up the work, there is nothing left for it to decide. A senior engineer's value was never in the typing. It's in the design.

The leverage depends on knowing where to hand off and how to hand off well. Hand off too early and the agent makes your decisions for you. Hand off too late and you've done the work twice.

The hard truth: review becomes the bottleneck

AI didn't remove the bottleneck. It moved it from writing code to judgment.

A process like this takes full-time people and all of your attention -- especially when you're also managing a team and have engineers writing code. Designing work for agents takes real energy to get right, and so does handling that work as it comes back through the pipeline.

Our review is specific. The reviewer reads the pseudocode spec, then measures the Linear issues and the PR against it. Did we deviate from the plan? Did anyone, human or agent, make a decision outside what the spec covered? If so, it's caught before it merges.

That's how we stay on the same page and keep the codebase clean. It's also why I won't pretend this is free. If your senior people are already at capacity, adding more agents is not going to add output -- it's going to add unreviewed code, and that's a liability you'll be paying down for months.

What this means if you're building a team

Small is the default now. A handful of strong engineers with agents can cover ground that used to take a much larger team.
Hire for judgment. When agents do the execution, the people you hire are the decision-makers, not function writers.
Invest at the front. Proposals and specs aren't bureaucracy. They're how humans stay in control of what gets built.
Scope ruthlessly. Small issues and small PRs are what make agent output reviewable.
Protect your reviewers. Whoever owns the pipeline is your real constraint. Staff and schedule around them.

The teams that win won't be the ones with the most bodies in seats. They'll be the ones where every decision has an owner -- and the agents never have to guess. Engineering in 2026 hasn't been easy; this is a new type of difficult that we all have to wrap our arms around to get right.

How is your team handling the handoff between engineers and agents? Tell me what's working, and what isn't, in the comments.

Safety in AI: Hallucination Conversation for Ethicists and Software Engineers

Jackie Cisneros — Thu, 15 Oct 2026 10:07:09 +0000

A quick note before you read: I wrote this in 2023, and life got so busy that I didn't open this blog again until today. I came back to publish something about AI and coding teams, and the first thing I saw was this unpublished draft.

I'm sharing it because of how extraordinarily relevant it still is. It's something my team at WhaleHawk is actively combating. Yes, we need to be responsible. No, most of us aren't -- and it's mind-blowing that this problem is still with us. We're leaving it up to our tools to be safe, yet we're still the ones operating the controls. It's an incredibly beautiful dance we find ourselves in, and I wanted to share it.

We are in a tech turning-point in history: from one day to the next, AI has changed the game in most every software market. OpenAI's Chat software reached 100 million users within 2 months of deployment. This same audience base took Twitter (now X) 2 years to achieve. AI is everywhere and there is a race to integrate it into every aspect of software on the planet, and I can see why. Its potential to help humanity and the planet is tremendous: consider Aza Raskin's work to use AI to understand the language of animals, or using it to develop a way to eliminate micro-plastics from the ocean (Ocean Cleanup is doing a great job with Macro-Plastics, anyone know of micro-plastic initiatives?). While we are enthusiastic, it's crucial to remember this tech is new to public access. We are in uncharted territory and it is wildly exciting. However, this also means we must proceed with caution.

Don't ask me, I just work here.

I am a software developer, and have used APIs for diffusion models and LLMs to integrate AI into my apps. The process is relatively easy. I do not have formal training in math or data analysis, yet just the other day I built out a computer vision model. It took less than 10 minutes.

I am telling you this to illustrate the ease of application for this mind-blowing technology.

This blog post is mostly opinionated, and addresses one big issue I have encountered with AI deployment: confidently wrong answers. There is an ocean of safety concerns surrounding AI, but to get the conversation rolling I chose this as an entry point.

This post is for anyone in the industry to contribute to, and I want your comments. I see industry professionals and academic researchers delving into the safety and ethics of AI. Simultaneously, developers are being asked to integrate AI without a clear roadmap. I believe there should be a stronger partnership between these groups to improve AI deployment in product development.

AI isn't new.

According to Tristan Harris and Aza Raskin of the Center for Humane Technology, our first contact with AI at massive scale was social media feed algorithms optimized for engagement. LLMs have been in the works for years, and have finally reached the point of mass deployment. Hallucinations are a known issue. Although there have been improvements to decrease their occurrence, it is in the nature of the tech to happen. An LLM doesn't look up answers; it predicts the most likely next word, one token at a time, based on patterns learned in training. Most likely isn't always correct, and because each word builds on the ones before it, one wrong turn can carry through the rest of the answer.

The AI Race

Hallucinations are a fact, but for much of the industry, the excitement and potential of the tech seem to outweigh this downside. We know of the Big Dogs who have put a ton of time, money and compute power into developing LLMs: OpenAI and Google, to name two closed-source for-profit companies. You can use their API to interact with their models. Open-source platforms like Hugging Face host models (think Falcon, from the Technology Innovation Institute), and their aim is to democratize the tech so everyone has access.

The point is, the race of the Tech Giants continues. And the race of start-ups that rely on their LLMs is on, too.

What does that mean for us as software developers?

Based on how easy it is to use this tech, I can imagine developers will be asked to start using LLMs in their development process. I just spoke with a friend who is a software engineer, who is working on a project within his fintech company using external APIs to incorporate AI into payroll. I anticipate this becoming a standard request for developers. Upon hearing such news, I find myself astounded. As software engineers, we know that our job requires learning new tech quickly and often, but this is next level. To paraphrase Giada Pistilli, Principal Ethicist at Hugging Face, we are in the Wild Wild West of deployment and are being asked to do something that has never been done before--ever.

SOOO....what IS the problem?

My concern is not with the technical abilities of software engineers and developers: we pride ourselves on quick and efficient technical mastery. My concern is with the ethics: example, say we have successfully integrated AI into our fintech company to handle all things payroll and the product is deployed: how do we account for the hallucinations that will inevitably happen? Wrong answers, wrong tax reporting, wrong employee payout. These presumably will be anomalies, but one bad hiccup is enough to put a company under and cause an individual an unnecessary amount of stress.

That example was for a very black-and-white type of situation. What about the startups looking to use AI in the form of a chatbot therapist (at Boulder Startup Week 2023 I observed a few startups interested in this)? Now we are getting into the land of unclear distinctions. As we know, people are not numbers and are very complicated. What if a chatbot has a hallucination in the face of a human with a very real need for dependable information? This could cause devastating effects.

Accounting for error: a three-tier step

Level One: Big Tech Accountability

This one is giant. We want to trust the products they make and deploy them to stay competitive, and give the customers our company serves the best and latest tech. But first and foremost -- always, always do your research. For example: how does XYZ company who holds the rights to the LLM handle accountability? Are they projecting a big change in the future which might affect your software? Read how they are handling hallucinations and user unpredictability.

Level Two: Startup Accountability

So your startup has decided to use AI? Great! What are the safeguards in place to protect your company when a hallucination goes unnoticed and is used in exactly the wrong way?

Level Three: Personal Accountability

As consumers of generative AI content, it is up to us to decide if we will trust the tech or do our own research. This is tough, because we are buying the software to make a process easier, and we do not expect to need to babysit something that is guaranteed to work. But for self-preservation's sake, perhaps we should. Checking our own records is always important, and reaching out to a human for verification when we come across a fishy piece of data is important too. Informing your customers of what to watch out for and promoting awareness is practicing good transparency.

Solutions for Developers

While I may not have definitive answers for us, I have questions that I hope can get the ball rolling in this conversation. In this spirit, let's share ideas for how to safely deploy AI tech, to keep consumers and companies alike in the safe zone.

First, it is important to recognize that developers are not the only players in the vast field of AI deployment. Aside from the coding and direct tech development, there are other critical stakeholders involved: project managers, the CTOs, the business stakeholders, the quality assurance testers, devOps team, and users providing feedback as a last line of defense. Some companies have more, and some have less. The point is, these roles together create a holistic framework in which responsibility for the success and ethical use of AI is distributed. As a developer, you have friends in the business who all have the same goal as you.

In the case where all these filters fail, and as software developer you are faced with some particularly fishy implementation of AI: is it above your pay grade to question? As developers, what is our level of responsibility to human ethics in this mad dash to AI? Creating software is a giant job, and already we juggle a lot. Practically speaking, do we have the time and energy and knowledge to be aware of the potential pitfalls of the AI software we create?

Thank you for your interest in this topic. As a developer deploying AI software or an individual in the field of AI Ethics, I would love to hear from you. How should a startup deploy AI Software in the context of hallucination accountability?

What I'd say now (2026)

Three years later, hallucination looks different. Models still invent a line of code or a detail in a summary, but the labs have grown up, the companies building frontier models have grown up, and the harnesses around them have gotten incredibly good.

The safety issue hasn't gone away -- it's moved to where this post was pointing all along: how we use the tool. That still puts the developer, and the person using the tool, in the seat.

Think of a chop saw. You don't put your hand under the blade, push it down, and expect to be okay. An LLM agent is a coding tool, a developer on your team, and a thought partner in design, and even three years in, we're still figuring out how to use it well. How do we protect our codebase? How do we protect our product? I live in the applied world, and from where I sit, guardrails and knowing how to use this tool matter more than ever. (Here's how my team handles it: Engineers Decide, Agents Execute.)

Clean Python: Try/Except

Jackie Cisneros — Mon, 12 Jun 2023 16:39:29 +0000

Exceptional Error Handling in Python

We code in Python because the language has incredible ease of use. Error handling in Python is no exception. Try/except is Python's method of handling potentially hazardous input without crashing your program, and returning to the user important information needed in order for the program to proceed. In this post, we will discuss three specific instances of when try/except is a great fit for error handling:

Cushion potentially erroneous code, such as division by 0 or file access to a file that doesn't exist or an unsupported file type.
Handle network or server issues that might occur when working with external systems, such as an API endpoint, giving the user workable information to allow the program to function correctly.
Wrap user input to handle unexpected data types which allows the program to continue to function.

This post will primarily focus on the third point, demonstrating how to handle try/except in the context of unexpected or incompatible user input.

A word of caution: while try/except blocks can effectively handle problematic input and prevent crashes, they should be used judiciously as they can potentially mask issues that a developer could otherwise address to improve performance.

Please begin the video at 6:04 to hear Dr. Charles Severance, Clinical Professor of Information at the University of Michigan, explain Python's try/except. This video is part of a larger collection complied by freeCodeCamp to help devs learn more about Python.

Cushioning your Program from the Dangers of TypeError

Instead of writing validations on the input code (which we might not have the ability to do for browser or front-end input), we can anticipate when a bad data type might come in.

In your programing, you have identified a potentially dangerous line of code. Let's say your program looks like this:

x= userInput
calculate = x+5
print(calculate)

#userInput = 5

This is a very simple program that calculates the value of adding 5 to the user input. If userInput = 5 as the comment suggests, then output naturally is 10.

Now imagine the situation that you are working with a front-end team responsible for writing the user facing functionality. For some reason, the validations for the front end don't work as anticipated/ aren't written in. So the user is able to enter input as this:

#userInput = 'five'

Python then attempts to calculate:

x = 'five'
calculate = x + 5

#TypeError -- Your Python Program Crashes

As Python programers, this is a failure on our part--we did not write in error handling code to keep our program running/ provide valuable feedback to our user in order to allow Python to continue its computing. This is where we can use try/except.

x = userInput

try:
    calculate = int(x) + 5
    return(calculate)
except:
    return("The input was not a valid number. Please try again.")

This returns some valuable information to our user. They now know that in order for the program to work, they need to enter a number.

What Is Happening Here?

Python is synchronous by default, meaning it only computes code line by line--it does not "know" what is happening next. When we write our function inside of a try: statement, it stores in memory something along the lines of : "I am told to carry out the computing of the following block of code. If it fails, I am not to halt the program and return the error; rather, I am to proceed to the block labeled 'Except:' and execute the code contained within.."

In this way, if we can anticipate potentially hazardous input (as in our current situation with user input), and we can effectively allow Python to continue running the program, even with bad input.

If you are familiar with if: else: statements, it will come to no surprise to you that Python does not even hit the return statement in the try: block upon failure; instead, it moves into the Except: block and computes ALL of the code nested there.

Now the user has been notified of Python's issue in computing data, the program has not crashed, and we have succeeded as Developers by means of effective communication across the stack.

Wrapping Up: Empowering Your Programs with Exception Handling

As we've seen, Python's try/except mechanism is an essential tool in the programmer's toolbox. It enhances the robustness and reliability of your code, cushioning against potential pitfalls and keeping your program from crashing even when faced with unpredictable inputs or unexpected events.

While this post has specifically delved into handling TypeError exceptions arising from user input, remember that the try/except construct is far more versatile. You can and should use it judiciously to handle a variety of exceptional circumstances.

That being said, it's essential to not fall into the trap of using try/except blocks to mask code inefficiencies or bugs that should be fixed directly. Overusing them can lead to code that's difficult to debug and maintain.n. Always strive to write clean, efficient code and only use exception handling where it's logical and beneficial to do so.

As Dr. Charles Severance rightly emphasizes, Python's error handling, particularly try/except, can make your code more resilient and user-friendly. In the grand scheme of things, using try/except appropriately means that you're writing code that respects the user's time and experience. It's a demonstration of good coding ethics and the mark of a responsible developer.

Continue Your Research

Curious of other ways can you use try/except? Open up a Replit environment and practice coding up some simple programs to further your understanding of the try/except environment.

Here is a code example to try with an unsuccessful api endpoint:

import requests

try:
    response = requests.get('https://nonexistent-api.com')
    data = response.json()
except:
    print("Error: Unable to connect to the API endpoint.")

Here is another quick example of attempting to access a file that doesn't exist:

try:
    with open('non_existent_file.txt', 'r') as f:
        content = f.read()
except FileNotFoundError:
    print("Error: The file does not exist.")

If you are certain of the error that Python might throw, you can specify the exact error type:

try:
    # some code here
except TypeError:
    # handle TypeError
except ValueError:
    # handle ValueError
# and so on...

Open up the Replit environment and try modifying the code to see how the program's behavior changes under different circumstances.

Let's keep the conversation moving!

Do you have any additional thoughts on Python error handling, or on maintaining clean Python code in general? Any challenges you've faced, or innovative solutions you've discovered?

Whether it's a question, a concern, or simply an interesting observation, I'm all ears. So don't hesitate—join the conversation. After all, the best way to learn is together. Let's enhance our coding journey by sharing and discussing our experiences.

Looking forward to hearing from you!

Stable Diffusion XL API: using the API for the beginner dev

Jackie Cisneros — Mon, 24 Apr 2023 22:49:17 +0000

If you're interested in the world of AI image generation, you may have heard of Stable Diffusion, a product from Stability.AI and powerful tool for generating unique images based on text or image prompts. Recently, they released their latest XL version, which is very powerful in terms of prompt engineering to generate beautiful, high quality images. Along with their newest version, they also have released a rest API for students and developers to use, allowing ease of integration into an app you might be building. The number one question on my mind looking into this was: do I need a dedicated CPU and a ton of storage on my local machine to use this API? The answer is nope! The API allows you access to Stable Diffusion's Models without having to host them on your local machine! In this blog post, I will share my journey on stumbling across the API, and how I plan to use it in my full-stack project I am building at Flatiron School.

I use a MacBook Air with an M1 chip. When I first started looking into Stable Diffusion I downloaded automatic1111 in order to run a simple drawing app to ai image generation program a friend had recommended. After getting Stable Diffusion's models onto my machine, and the source code for automatic1111 (which I had to integrate SD models into) and running in the background of my machine, I literally had NO STORAGE LEFT to download the paint program! Determined to find a better way, I came across Google Colab, a sweet service for running python code with Googles amazing CPU's. StableDiffusion had a Juypter Notebook for their source code, so I could easily open it up in Colab. It ran great, and fast (maybe took 3-5 seconds to generate an image). However, I am looking for a way to build an app that has Stable Diffusion integrated in, and using Google Colab seemed like maybe it was possible, but not necessarily practical (if I am wrong on that, please let me know!)

Feeling relatively defeated yet still optimistic, I kept digging for a solution. I found an excellent tutorial from Skolo Online and she walks you through how to fetch the models from the API using Python. She says right at the beginning that her computer is slow, so apologies if it takes a minute for the code to process. I followed her step by step guidance and generated an image from my command line using a prefabricated prompt. The generation time was a matter of seconds and the image quality is astounding.

Prompt: create a high resolution picture image of a luxary car in a studio setting showcasing its sleek lines and high-end features. perfect lighting with highlights.

Note: Yes, I spelled luxury wrong in the prompt I entered for this image. I wanted to show you exactly what I told it in order to generate the above image. It can function with typos, what a plus for a not-so-great-speller as myself.

If you know python, the simplicity of incorporating these models into your code is astonishingly simple. If you feel confident running the python script flying solo, I will give you a few steps to get you started. However, if you want a hand-hold like I did, go ahead to the tutorial above. It takes about an hour to get through but it is worth it.

Step 1: Go to DreamStudio and make an account. They start you off with some credits, which equal about 150 images to generate. Play with the software a little, this is the FUN PART! Get familiar with the left tool-bar on the page: there is a prompt section where you engineer a text prompt the ai uses to generate it's images. (Tip, if you want an easy way to make a prompt, head to chatGPT and ask it to engineer a creative prompt for text to image ai generation.)

Take a look at the advanced settings: there is something called steps; the higher the steps, the better the image quality, the higher the cost to run the program. This is the downside to this api: you need to pay for it. But in reality, it is much cheaper than others, like DALL-E, coming in at about $10 for around 1000 images. If you had the CPU and memory to download stable diffusion and use the models directly on your machine, that would be the way to go to get SD "for free". However, if you are like me with a limited machine, this is the price we pay to play around with the tech. Not bad. (Note, I am unsure if SDXL, the latest model we are talking about here, is available for download. I ended up playing with v1.5 (which produces significantly less quality images) on Google Colab. Please let me know if XL is available and you have tried it either locally or with Colab.)

There is also a dropdown called Model in the advanced setting. These are the different versions of SD that are available. You can play around and test the same prompt in different models; do the results differ?

Step 2: In your personal account info in DreamStudio, there is an API key autogenerated for you. Click on the documentation tab below that and it will take you where you need to find the code to get you started.

Step 3: Here is a link to the getting started page for Stability.Ai's REST API. It is very comprehensive. They basically provide the python code necessary for gaining access to the API. Here is my source code that I ended up with, plus I have a config.py file that contains my API key, which I will then store in a dotenv file and then to a .gitignore as I build out my project. I know I need this often, so remember guys to not share your API code with the world. Ok, source code:

import os
import requests
import config
import base64
import json


api_host = 'https://api.stability.ai'
api_key = config.api_key
engine_id='stable-diffusion-xl-beta-v2-2-2'

if api_key is None:
    raise Exception("Missing Stability API key.")

def getModelList():
    url = f"{api_host}/v1/engines/list"
    response = requests.get(url, headers={
        "Authorization": f"Bearer {api_key}"
    })
    if response.status_code != 200:
        raise Exception("Non-200 response: " + str(response.text))
    # Do something with the payload...
    payload = response.json()
    print(payload)

def generateStableDiffusionImage(prompt, height, width, steps):

    url= f"{api_host}/v1/generation/{engine_id}/text-to-image"
    headers = {
            "Content-Type": "application/json",
            "Accept": "application/json",
            "Authorization": f"Bearer {api_key}"
    }
    payload={}
    payload['text_prompts'] = [{"text": f"{prompt}"}]
    payload['cfg_scale'] = 7
    payload['clip_guidance_preset'] = 'FAST_BLUE'
    payload['height'] = height
    payload['width'] = width
    payload['samples'] = 1
    payload['steps'] = steps

    response = requests.post(url,headers=headers,json=payload)

    #processing the response
    if response.status_code != 200:
        raise Exception("Non-200 response: " + str(response.text))

    data = response.json()
    # print(data)

    for i, image in enumerate(data["artifacts"]):
        with open(f"v1_txt2img_{i}.png", "wb") as f:
            f.write(base64.b64decode(image["base64"]))

for i, image in enumerate(data["artifacts"]):
    with open(f"v1_txt2img_{i}.png", "wb") as f:
        f.write(base64.b64decode(image["base64"]))

I ran my code in the python shell from my base directory, feeding the shell my code line by line, then establishing the variables of prompt, width (512, or whatever dimensions you desire), height (512) and steps (50, remember, more steps, better images and more expensive). Note that the engine_id is the current model you would like to use (I want to use the beta model with XL) and the very few last lines of code are responsible for taking the image as a string (it is a really, really, really long string) and converting it into a PNG image. My image saved directly in the base code in my directory, and I was able to see it that way.

In conclusion, I am so excited to explore this API more and integrate it into my app. Not exactly sure what I will make with it, but the possibilities are extensive! Just know that you can implement this api and use the models from Stable Diffusion in order to have a wonderful image generator inside you app. I hope this post was a spark to a fire that I have found and you feel inspired by the accessibility of this API. Think of different ways you might be able to use this tech: a simple text to image generator would be sweet, but what if you could use python to make a simple drawing, and as you sketch the API recognizes your sketch (plus a prompt) and generates an AI image? What if you use their image to image software and create a totally new image with a fed prompt? There is also an in-painting option; what type of image could you describe with those algorithms?

So happy you were here, if there is anything you think I should know let me know and most of all, Happy Coding!

SQL fundamentals: understanding Join Tables

Jackie Cisneros — Sat, 01 Apr 2023 18:57:25 +0000

SQL (structured query language) is the language of databases. On its own, it is a very powerful tool, and as a full stack dev, it is super important we understand how this language works. In this blog post, I am going to discuss SQL join tables in depth: what they are, why they are necessary, the different types of joins you can perform, and how to use them. This article is for you if you are beginning your journey with SQL and have a working knowledge of the language, including some basic syntax. Difficulty level: intermediate beginner.

What is a Join Table? Why wouldn't I just make a new table?

SQL join tables are used to associate records from different tables; think of them as linking tables. Making a new table to represent a relationship would work, however, you would need to make a new table for each instance that is created.
If you intend to grow your db, this would become unmanageable very quickly. So a join table allows you to create a many-to-many relationship between two or more tables in an efficient way.

Wait...what is a many-to-many relationship again?

A many-to-many relationship is where multiple records in one table can be associated with multiple records in another table.

For example, imagine you have a chatbot with two db tables: a "statements" table that collects all the training data for your bot, and "tag" table, which has a collection of helper tags with an associated id. A statement can have multiple tags, and a tag can have multiple statements; this helps the bot classify statements and make searching for an appropriate response easier, creating a many-to-many relationship between the two tables.

In order to represent this relationship in SQL, you would need to use a third table, a join table, that sits between the two. Let's call it "tag_association". This table would have two columns of foreign keys that reference the primary keys of both the "statements" and "tag" tables. The join table creates our necessary many-to-many relationship and maintains the referential integrity of "statement" and "tag", simultaneously avoiding data duplication. Also, it is self-scaling, which means as your data updates, so does your relationship model.

The Importance of Relationships

SQL is a relational database language, which means data is organized into tables with rows and columns. Each row represents a specific type of data, and each column is an instance of that data. Naturally, the process of querying the databases heavily relies on relationships: different types of joins in SQL can represent different types of relationships between tables in a database. There are several types of joins in SQL, including (but not entirely limited to):

Inner Join: This type of join returns only the rows that have matching values in both tables being joined. An inner join can be used to represent a one-to-many or many-to-many relationship between two tables.

Left Outer Join: This type of join returns all the rows from the left table and matching rows from the right table. If there is no matching row in the right table, then the result will contain NULL values for the right table columns. A left outer join can be used to represent a one-to-many relationship, where the left table contains the primary key and the right table contains the foreign key.

Right Outer Join: This type of join returns all the rows from the right table and matching rows from the left table. If there is no matching row in the left table, then the result will contain NULL values for the left table columns. A right outer join can be used to represent a one-to-many relationship, where the right table contains the primary key and the left table contains the foreign key.

Full Outer Join: This type of join returns all the rows from both tables being joined, with NULL values for any unmatched columns. A full outer join can be used to represent a many-to-many relationship between two tables.

WHEW! That is a lot of information. Want to practice?

Let's go ahead a practice creating some join tables using MyComplier:. We are going to use some examples from W3School's SQL program (which is extensive and contains a lot of helpful information in learning the language).

-- create a table
CREATE TABLE orders (
  OrderID INTEGER PRIMARY KEY,
  CustomerID INTEGER,
  OrderDate TEXT NOT NULL
);
-- insert some values
INSERT INTO orders VALUES (10308, 2, '1996-09-18');
INSERT INTO orders VALUES (10309, 39, '1996-09-19');
INSERT INTO orders VALUES (10310, 77, '1996-09-20');
-- fetch some values
SELECT * FROM orders WHERE CustomerID = 2;

Go ahead copy and paste this code into the complier link above (the link will take you to the main page, just click on the "Run Your SQL Code" button, it is giant and yellow, can't miss it). You can see we are creating a table called orders which has columns of OrderID, CustomerId and OrderDate. We are then inserting values into the table as particular instance orders. Then we are retrieving, or fetching an entire instance (annotated by the *) from our table where customerID matches 2. Hit the green run play button at the top and see what happens.

Now we are going to create another table, customers and populate with some data. You can copy and paste the code below, or type it yourself to improve muscle memory:

-- create another table
CREATE TABLE customers (
  CustomerID INTEGER PRIMARY KEY,
  CustomerName TEXT NOT NULL, 
  ContactName TEXT NOT NULL, 
  Country TEXT NOT NULL
);
-- insert some values
INSERT INTO customers VALUES (1, 'Alfreds Futterkiste', 'Maria Anders', 'Germany');
INSERT INTO customers VALUES (2, 'Ana Trujillo Emparedados y helados', 'Ana Trujillo', 'Mexico');
INSERT INTO customers VALUES (3, 'Antonio Moreno Taquería', 'Antonio Moreno', 'Mexico');
-- fetch some values
SELECT * FROM customers WHERE CustomerID = 2;

Hitting run, you will see that we are retuning the instance from customers where the id is 2.

Let's write for an Inner Join Table.

Great! Now it time to test how we can join these tables together. Comment out the two SELECT commands, and write the code below:

SELECT Orders.OrderID, Customers.CustomerName, Orders.OrderDate
FROM Orders
INNER JOIN Customers ON Orders.CustomerID=Customers.CustomerID;

Before you press run, can you guess what the new table will look like? Take a minute to study the above code and take an educated guess at what type of relationship we are creating. We see we are selecting from our both of our tables: orderID from orders, customerName from customers, and orderDate from orders. So there will be three columns of organized data.

The next line of code specifies the first table we are joining, orders. The next line, INNER JOIN Customers specifies that an inner join should be performed with the Customers table. ON Orders.CustomerID=Customers.CustomerID specifies the join condition, which is that the CustomerID column in the Orders table must match the CustomerID column in the Customers table.

Can you assume which is the instance that will be created? Run the code to see if you're right!

You can see that the only instance that is created is the one where the customer ID is in both tables, the id of 2. This is a very small example, so can you imagine ways to scale the table to see more instances in our join table?

Left Join Example

SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
LEFT JOIN Orders ON Customers.CustomerID = Orders.CustomerID
ORDER BY Customers.CustomerName;

As we may recall, a left join returns all the rows of the left table (in this instance customers) and only the matching rows of the right table (the orderId where customer.customerId=orders.customerID). There is only one occurrence of this in our tables, the order 10308, so the join table contains only one orderID. The other spaces for this may return Null or empty. So we see all three customer names printed, but only Anna Trujillo's id printed.

How to use the join tables within my application?

Join tables are used when we have many-to-many or a many-through relationship. For instance, say we have db that has coffee drinks and coffee shops as tables. We also have a customer tables that allows you to make an account, say for placing an online order. A join table (orders) allows us to make a relationship of orders, connecting one order with a customer_id, a drink_id and a shop_id. This way, the system has knowledge base of who ordered what and from where.

Conclusion

SQL is a beast of a language, and if you would like to dive into it, you could very well become a SQL master. However, with the benefits of abstraction and using tools like SQLAlchemy, our databases become easier to write. Understanding depth of the SQL language to write DB's can help us in our abstraction have a better understanding of what is happening in our program under the hood. It can be dense, but once you emerge from the darkest forest, the sun shines brighter!

If there is anything that I missed or that you think I ought to have included in this blog post, please let me know. And as always, Happy Coding!

Building Graphics with Code: Zdog and JS, a quick overview

Jackie Cisneros — Sat, 11 Mar 2023 02:34:41 +0000

There are some amazing JS engines out there designed to make building graphics more accessible. As an amateur visual artist/ growing developer, I would love to learn how to build my own static and animated graphics. After a quick google search, I found Zdog, an easy to use lightweight JS engine that renders 'pseudo' 3D images. My post here is to share with you my initial thoughts on the user-friendliness of engine, a quick guide to get going with it's syntax and features where we code together a sphere and a cube rotating through space, and an overall 'general implementation' idea for when this engine would be appropriate for use.

Wait, backup. What does 'pseudo 3D image' mean?

It means 3D in motion, and 2D when static. The power behind zdog is this: you transmute circles and squares on an x,y,z axis. Meaning, you target what direction you want your shape to grow or shrink. When a screenshot is taken, like in the photo above, the image looks 2D. However, when the animation is spun, you can see the dimensionality behind the object.

So why use zdog?

I am going to go a little out of order and get this out of the way right off the bat: If you want to make a game, this isn't the JS engine for you. It doesn't come with the right elements for a game (such as collision detection). Apparently you can modify it manually, but there are probably better engines out there to do your dirty work. (Actually, you might want to bark up the Python tree for that one...more on that later.)

USE ZDOG IF YOU WANT AN ISOLATED 3D IMAGE WITH SIMPLE ANIMATION CAPACITY.

Imagine you want to spin your company's logo on the Home Page and make it have depth. Or you want your 404 Not Found Page to have a bit of artistic fancy so users aren't AS disappointed if their app fails to load. Zdog can help you do these things, and of course, much more depending on where your imagination can take you.

Here is a sweet animation TienCoffee made. It is a model of a solar system. Just imagine how helpful this would be for 1st graders trying to wrap their heads around how the earth moves around the sun. Or if a coder made a model of a molecule and instead of the flat image in a text book, students can see how it connects by simply spinning the image.

Curious to get started? So am I. Let's do a little Zdog challenge together. Dave DeSandro (the creator of Zdog), made this codepen template for new users to play with. Click on it and let's make some shapes!

We are going to make a cube and sphere rotating around an invisible point space.

Don't worry, you can do this. If you know basic JS, Zdog's API is easy enough to grasp. And the results are so fun. I have been coding in JS for less than a year, and the learning curve here is realistically around a few hours to get a hang of the syntax. (That is not speaking to how long it would take in real life to create a product to deploy, but that is beyond our scope today.) Ok, without further delay, let's get started.

Do you see a purple circle inside of a cream box? Great! Off to a good start. Let's make this circle completely solid, take out the diameter and change the stroke to 12.

new Zdog.Ellipse({
  addTo: illo,
  stroke: 12,
  fill: true,
  color: '#636',
});

Whoops! It is super tiny! No worries, just go up to where we are setting illo and change make a new key/value pair of zoom: 8.

Now, let's take a quick minute to look at what's going on here. Ellipse is a shape class in Zdog. We are adding this ellipse shape (with the defined key value pairs that create it's image) to our page with addTo: illo.

Wait, what is illo?

Back in our codpen file, if we scroll up to the top of the JS file, we will see this:

let illo = new Zdog.Illustration({
  // set canvas with selector
  element: '.zdog-canvas',
zoom: 8
});

Let's say this out loud together to practice technical communication:

We are declaring a variable illo and setting it equal to a new object (using JS's new operator) calling Zdog's Illustration class and setting canvas with our css selector, '.zdog-canvas'. Zoom will be set to 8.

Great! But what is Illustration?

Illustration is a "high level" class in Zdog api that basically attaches your creation to your HTML element. All of your subsequent shape creations in Zdog will have reference to this Illustration class. This is like our fixed point for all the rotations to circle around.

Moving on to Animation!

Go ahead and copy this code to the bottom of your JS file, right before illo.updateRenderGraph();.

function animate() {
  illo.rotate.x += 0.05;
  illo.updateRenderGraph();
  requestAnimationFrame( animate );
}
animate();

Does your codepen look like this?

Sweet! You should see it spinning too. Well, actually, because we changed its' properties, it will look more like a squishing ball. Study the code for a minute; do you see that we declare it to rotate on the x-axis? What if you changed that to y? Have some fun playing with this.

Let's add another class of Rect (short for rectangle) right below our Ellipse.

new Zdog.Rect({
  addTo: illo,
  width: 8,
  height: 8
  stroke: 12,
  color: '#E62',
  fill: true
});

Right now it should look like a breathing rectangle. Why is that? Where did the ball go? It is still there, it is simply hidden behind the rectangle. We can add translate: { z: -10 }, to the key/values of this Rect object. This will push the shape back on the page (along the z axis) by 10 (whatever 10 is distinguished by in Zdog; I would need to look at their API to really know). Go ahead and add x and y values to translate on the rectangle, and do the same with the ellipse. What happens?

new Zdog.Ellipse({
  addTo: illo,
  stroke: 12,
  color: '#636',
  translate: { x: 5, z:10, y:-5 },
  fill:true
});

new Zdog.Rect({
  addTo: illo,
  width: 8,
  height: 8,
  translate: { x: -5, z:-10, y:5 },
  stroke: 12,
  color: '#E62',
  fill: true
});

See if you can get the circle to land on the rectangle. Manipulating what part of these objects will get that job done? Is there another key we need to add in order to accomplish our task?

Drag and Rotate

Ok, now the fun part. Add this code to your illo variable declaration:
dragRotate: true,

Now, add this above it :
let isSpinning = true;

Now, add a function definition to your illo object: onDragStart: function() { isSpinning = false; },

Finally, update your animate function to look like this:

function animate() {
  if ( isSpinning ) {
    illo.rotate.y += 0.03;
  }
  illo.updateRenderGraph();
  requestAnimationFrame( animate );
}

Great! Did you break it? I sure did. Let's go through what the entire js file should look like at this point:


let isSpinning = true;

const illo = new Zdog.Illustration({
  element: '.zdog-canvas',
  zoom: 6,  
  dragRotate:true, 
  onDragStart: function() {
    isSpinning = false;
  },
});

new Zdog.Ellipse({
  addTo: illo,
  stroke: 12,
  color: '#636',
  translate: { x: 5, z:10, y:-5 },
  fill:true
});
new Zdog.Rect({
  addTo: illo,
  width: 8,
  height: 8,
  translate: { x: -5, z:-10, y:5 },
  stroke: 12,
  color: '#E62',
  fill: true
});

function animate() {
  if ( isSpinning ) {
    illo.rotate.y += 0.03;
  }
  illo.updateRenderGraph();
  requestAnimationFrame( animate );
}
animate();

illo.updateRenderGraph();

Awesome! Now you can stop the image, and spin it around using your mouse.

Accomplishment: you know the basics of creating shapes and starting animations, congrats! The next step is going to the website and using the tools we explored here to model images. Doesn't that look fun?

TakeAways

Zdog's API uses classes (Illustration, Ellipse, and Rect) to make shapes and fix them to your HTML using .
Each class renders an object based on coder's choice of color, size and other mutations.
Creating animations is a matter of making functions that call illo.rotate (our fixed point) on a particular axis at a particular speed.

If you are excited about the potentials for Zdog, you can jump right into some projects DeSandro lists on Zdog's website and reverse engineer them to learn the basics. Or, you can go back to the codepen we worked on and try adding another shape, or even making a line (what the heck would that look like?). Have fun and happy coding!

Recursion in JS for Beginners, avoiding an infinite loop

Jackie Cisneros — Sun, 19 Feb 2023 23:06:09 +0000

Recursion is tricky. First of all, as a beginner, we are just learning about functions and what they do. We feel happy with our progress until a teacher, youTuber or blog post helpfully drops recursion on us and we are floored: a function that calls itself? For lack of a better word, whaaaaa...???

In this blog post, I will address a few questions that I encountered when I first learned about recursion, mainly:

What is Recursion?
How does it work?
Why should I use it?

**Spoiler; the last question I am still answering for myself.

What is Recursion?

A recursive function is one that calls itself. It may look something like this:

function recursionFunction(num){
  if(num > 0){
    console.log(num)
    recursionFunction(num-1);
  };
};
recursionFunction(10)

//Prints 10 9 8 7 6 5 4 3 2 1

Study the code above. Really look at what each element is doing; look at the curly braces, the parenthesis, the name of the function. Try to understand what the function is doing and describe it out loud to yourself. You can even open it up it this JavaScript REPL (make sure you are in node.js) and plug in the code to the left side and hit run.

Let's go through line-by-line, performing how JS performs, to better understand this process.

Line one: the function declaration

function recursionFunction(num)

Let's say out loud what this is saying:

"We are declaring a function called recursiveFunction that has one parameter, num.

Wonderful! Great technical communication. Now, JS stores this function (which is everything inside of the curly braces) in global memory, to be accessed when we call the function later in our program. The program moves on to the next line of code:

The Call to recursionFunction

recursionFunction(10)

This is the call for recursionFunction to execute with the passed in argument of 10. Since JS has this info stored in global memory, it can pull recursionFunction up again (remember, JS is synchronous, so it will not move up lines of code to access the function again; it will look for the stored function declaration in global memory.).

The Body of the Function

  if(num > 0)

Now, JS has entered a local execution context for the call to recursionFunction, and in the local memory, we are storing the argument at 10 (so currently, num = 10). In the next line of code, JS is reading "if 10 is greater than 0". This is called our "base case" and is so very important in recursion (more on this later). What that means is that, if this is true, go ahead and do the body of the "if" statement.

Is the if statement true or false right now?

That's right! It is totally true. Let's move on to the next line of code:

{
    console.log(num)
    recursionFunction(num-1);
  };

JS will then print num, which it has stored in this local memory as 10. Then, it will call recursionFunction again, but this time, the argument is (num -1). What is num? We have it stored in the local memory for the first call of recursionFunction; it is 10. So now, JS will open another execution context, on top of the first one, storing num-1, or 10-1, as the definition of num.

What do you think will happen next? We have a second execution context open, and num = 9. I think we will go back up to the stored function declaration of recursionFunction (which is stored where? In the Global Memory, meaning we can call it over and over again no matter where in our call stack we are) and use our second argument in place of our parameter num.

First we hit our base case:

if(num>0)

Is that true? Is 9 > 0? Absolutely, so we can move into the body of our base case and execute the code:

{
    console.log(num)
    recursionFunction(num-1);
  };

Now we print 9, and call recursionFunction passing in num (which is 9) minus 1. Now we open up yet another execution context, with our new argument at 8, and do everything all over again.

Now let's pretend we did all that, and now num = 0. We currently have 10 execution contexts stacked on top of each other (this is called the call stack). JS hits our base case, if num > 0... is it? Not anymore! We have finally hit the base case for this recursion. Our if statement evaluates to false, so JS exits the current execution context (which is recursionFunction(0)), enters the next one, sees there is nothing more to do there, and keeps going down the line until we are back in the Global Execution Context. Whew!!!

Base Case

As promised, let's talk a little more about our base case and code composition. What would happen to our recursive function if we moved the call to recursionFunction outside of the if statement body?

function recursionFunction(num){
  if(num > 0){
    console.log(num)
  };
  recursionFunction(num-1);
};
recursionFunction(10)

It is a simple change, we moved the code one line down. But go ahead and open up the REPL, see what happens when you plug this variation in.

Something like this will appear:

10
9
8
7
6
5
4
3
2
1
RangeError: Maximum call stack size exceeded
    at recursionFunction (/home/runner/tf3w0jc6kne/index.js:1:27)
    at recursionFunction (/home/runner/tf3w0jc6kne/index.js:5:3)
    at recursionFunction (/home/runner/tf3w0jc6kne/index.js:5:3)
    at recursionFunction (/home/runner/tf3w0jc6kne/index.js:5:3)
    at recursionFunction (/home/runner/tf3w0jc6kne/index.js:5:3)
    at recursionFunction (/home/runner/tf3w0jc6kne/index.js:5:3)
    at recursionFunction (/home/runner/tf3w0jc6kne/index.js:5:3)
    at recursionFunction (/home/runner/tf3w0jc6kne/index.js:5:3)
    at recursionFunction (/home/runner/tf3w0jc6kne/index.js:5:3)

Ouch, that is painful! See where it says

"Maximum call stack size exceeded
at recursionFunction"?

JavaScript is throwing us this error because we are recursively calling recursionFunction outside of our base case declaration (the "if" statement right at the beginning).

WAIT, WAIT...WHAT???

Think about it like this: we are calling a function from the body of itself. Which means we are inherently setting up the stage for an infinite loop. If we don't tell JS, "Hey wait! Stop running this loop when you hit zero. You don't need to go past zero and into the forever underworld of negative numbers. We good at 0.", then it doesn't know to stop. JS is performative and does not make judgement calls; it will simply go on doing what we ask of it until our memory doesn't allow it to happen any more. And then our program crashes.

To avoid that, when we write our recursions, let's make sure that our recursive call is within the code block where our base case has power.

Space and Time Complexity

That was a simple demo for what recursion can do for you as a programmer. It can make life easier for you, but it does take up more memory. Remember the call stack we talked about? Because recursive functions need to maintain this stack when they are being called, they use more space than an iteration would. They also have a slower processing rate.

HOLD ON: if recursion is slower and takes more space to process than an iteration...

...why wouldn't we just use an iteration, like a for loop or a forEach()?

const nums = [10, 9, 8, 7, 6, 5, 4, 3, 2, 1];

function printNums(number){
  for(let i = 0; i<number.length; i++){
    console.log(number[i])
  }
}
printNums(nums)
//prints 10 9 8 7 6 5 4 3 2 1

In many imperative situations, iteration is favored way above recursion. However, there are some specific situations where the code to write an iteration is too complex, and recursion is necessary. One of these situations includes Tree Traversal. Click on the link if you are feel confident with recursion and are looking for some meaty methods for solving algorithms. If algorithms are a new idea and you feel like a firehose just blasted you with info, take a breath, and lets go back to the recursive code we started with and practice our technical communication:

Technical Communication

function recursionFunction(num){
  if(num > 0){
    console.log(num)
    recursionFunction(num-1);
  };
};
recursionFunction(10)

//Prints 10 9 8 7 6 5 4 3 2 1

We are declaring a function called recursionFunction that accepts a parameter, num. The body of the function first establishes a base case: if num is greater than zero, print num. Then call recursionFunction again, passing in the argument of num minus one. We then exit the body of our base case, and exit the body of our function, and call recursionFunction passing in the integer ten as our argument. This begins the recursion process.

Great job! You just tackled one very tricky topic in your path to understand JavaScript. Give yourself a pat on the back, and go celebrate your win.

Happy Coding!

.reduce() for the beginner

Jackie Cisneros — Thu, 16 Feb 2023 23:09:13 +0000

If you are reading this post, you are at the point in your coding journey where you want to start exploring iterator techniques outside of a for loop. You are in a great spot, because .reduce() will take a callBack function (supplied by you, the Software Engineer) and return a single value without necessarily "looping" through your entire array. Here is the code we will be working with:

let arrayOne = [7, 8, 3];

let arraySum = arrayOne.reduce(function(a, b){
return (a + b)
}, 2);

console.log(arraySum) // displays 20

Getting to Know the Code

Take a minute right now to study the code above. Look at the parenthesis, the curly braces, the commas. Try to understand what the language is actually saying, and say it out loud. At the end of this post, we will say out loud together, in human words, what the code is doing. This will greatly improve your skill in technical communication.

In the above example, reduce accepts two parameters: a callBack function (which has two parameters in this example, a and b; it can actually have up to 4, but that is beyond our scope today), and an optional "initial value".

We know that in JavaScript, we have to pass in arguments when we call our functions. So why don't we see arguments here? That is a great question! And that is why reduce is so awesome and helpful. Reduce is a built-in method, which means JavaScript knows what to do when we call it on a particular array, in this case, arrayOne. It uses the array to establish the arguments to pass into the callBack function.

Let's walk line by line through our code and try to think like the program.

Synchronous JavaScript

In the first line, JavaScript sees arrayOne:

let arrayOne = [7, 8, 3];

Because JavaScript is synchronous (meaning it processes our code much like we read books in English: top to bottom, and left to right), we must initialize our array variable before we call our reducer.

Take a quick pause for a minute and try to answer this question: what would happen to the program if we initialized arrayOne after we called our reducer function?

let arraySum = arrayOne.reduce(function(a, b){
return (a + b)
}, 2);

let arrayOne = [7, 8, 3];

The program would throw an error. It would say something like this:

index.js:14 Uncaught ReferenceError: Cannot access 'arrayOne' before initialization
    at index.js:14:20

JavaScript is good to us in this way. It can recognize that we want to access an array, but because the program is inherently synchronous, it cannot jump lines of code to go searching for our variable. So, it throws an error saying we aren't communicating with it correctly. How helpful! If you come across an error like this, go ahead and check the composition of your code. Ask yourself, "Did I try to access a variable before I created it? How can I fix that?" In this case, we can simply move the line of code in which we initialize arrayOne above the reduce function.

Storing Our Single Returned Value: Practicing with REPL

In our next line of code, we initialize a variable arraySum:

let arraySum =

This is important because reduce returns a single value from an array. The way to access that returned value is through this variable. Go ahead and open up this REPL for JavaScript. Copy and paste the entire code snippet from the beginning of this post into the left window (make sure you are in node.js in the little drop-down window).

When you hit run, you will see your console.log displayed in the right window as 20. Now in the right window, type arraySum and hit enter. You should see 20. This is because our variable arraySum is set equal to the evaluated reducer function.

Parameters of Reduce: the Anonymous Function and "Initial Value"

Let's return to our code and move to the right of the variable, after the equal sign:

arrayOne.reduce(function(a, b){/*...*/}, 2)

Here we are calling reduce on arrayOne and setting our first parameter, our callBack function. This is an anonymous function (we can tell it is anonymous because it has no name, and it can be anonymous because we do not call it outside of the arraySum variable) with two parameters, a and b. Parameter a is our "accumulator" and parameter b is our "current value". Finally, we have the lonely 2. This is an optional parameter in the reduce method.

HEY WAIT! WHAT HAPPENED TO ALL THE CODE BETWEEN THE CURLY BRACES?

This is a great question. Right now, we are looking at the code the way JavaScript reads it. It doesn't look at the code block between the curly braces; it continues looking down the line at the other parameters of our anonymous function, which is the "initial value". It needs this information before it can execute the function.

What does the "initial value" do? Hold on to your hat, because this is where the ride starts. Let's integrate this question into our discussion about the parameters of our callback function.

Accumulator and Current Value: Parameters of the Anonymous Function

Let's talk about the "accumulator" first, in this case a. This is the value resulting from the previous call to our callBack function. On the first call, it is set to the value of arrayOne[0]. Check out our array below. On the first call of our callBack, where is accumulator set?

let arrayOne = [7, 8, 3];

It is set at arrayOne[0], which is the integer 7.

Now, if we have an "initial value" declared, which we do, our "accumulator" is then set to be the initial value. Check out the code snippet below one more time. What would our accumulator value be set to?

arrayOne.reduce(function(a, b){/*...*/}, 2)

If you guessed 2, you've got it!

Now let's talk about "current value". This is the value of the current element in our array. We start at arrayOne[1]. Look at our array above. Imagine we are still in the first call. What is our "current value"?

arrayOne[1] is the integer 8. Great! Now let's throw in the "initial value" wrench. If this is declared, as in our example, "current value" becomes arrayOne[0], which is 7.

Whew! So to recap, when "initial value" is a player, on the first call of our callBack function, "initial value" takes the place of "accumulator", and the default for "current value" (which is arrayOne[1]) is replaced by the arrayOne[0]. Basically, everything bumps down by one. It is almost like we are adding an element to the beginning of our array and starting there.

Finally, we hit our last line of code:

console.log(arraySum)

JavaScript scans global memory, looking for a variable named arraySum. Aha, it is there, and it evaluates to the call of our reducer function. So now, JavaScript can enter the body of our function.

The Body of the callBack Function and Making Calculations

Before we evaluate the body of our function, let's make a quick cheat sheet for the work JavaScript has done so far and stored in local memory for the first execution context of this function:

arraySum = the evaluated result of calling reduce on arrayOne;
a = 2 (this is our accumulator and first parameter/argument, in this case our "initial value");
b = 7 (this is our current value and second parameter/argument, because we have "initial value" declared, it it arrayOne[0]);

With this information that JS has stored in memory, we can enter the body of our function:

{
return (a + b)
}

JavaScript hits this line of code and knows what a and b represent in this call, as they are stored in the local memory of this function. JavaScript adds them together and returns the math, in this case 9, back to the callBack function. Now we have the value of our "accumulator" for our next call. Remember, we are only in the first call; JavaScripts' job is to do this on ALL of the element specified in the array!

For the final piece of this blog (and the most fun part of .reduce()), we finish up the calculations. In local memory, our parameters are updated, so now:

a = 9 (the evaluated result of the first call, the "accumulator");
b = 8 (the next index in our array, or arrayOne[1]);

JavaScript then enters the body of the function and performs for us:

{
return (a + b)
}

which is 17. Can you guess what we do with the evaluated result of our callBack function?

Yes! We use it as our new accumulator value in the next call.

a = 17;
b = 3;

which is 20. JavaScript sees there are no more elements in the array to iterate over, and exits out of the function entirely, leaving our variable arraySum equal to the returned value of 20, which is stored in global memory.

Here is our entire snippet of code one more time:

let arrayOne = [7, 8, 3];

let arraySum = arrayOne.reduce(function(a, b){
return (a + b)
}, 2);

console.log(arraySum) // displays 20

Technical Communication

Now, as promised, let's look at the code again and talk technically about the code. Try it yourself first. Then read the below paragraph out loud and follow along with the code above:

We are declaring a variable arrayOne and setting it equal to an array of integers including 7, 8, and 3. We are declaring another variable, arraySum, and setting it equal to the evaluated result of calling reduce on arrayOne. Reduce accepts two parameters: the first is an anonymous function that also accepts two parameters, a and b; the second is the initial value of 2. The body of the anonymous function returns adding b to a.

Whew, you did it! Now it it time to play. Go ahead and use the REPL link to try out different parameters. What would happen if you passed in a different initial value, or none at all? What would happen if you had a much larger array and called slice on it before calling reduce on it? What if you had a collection of functions that you called reduce on? Here is a little code snippet to toy with if you're up for the challenge:

const minusThree = x => x - 3

const result = [minusThree].reduce((value, currVal) => currVal(value), 0 )

Happy Coding!