DEV Community: Phil Tenteromano

Concurrency in Golang with a Binary Search Problem

Phil Tenteromano — Fri, 24 Jun 2022 18:04:52 +0000

Problem

Solving problems with Go can be a really fun and rewarding experience. In this post, I'll go through a "medium" Leetcode challenge "Find First and Last Position of Element in Sorted Array".

The problem is fairly straight forward - it's a sorted array, so we know we can use Binary Search. However, the array is non-decreasing, meaning that elements are allowed to repeat. We're given the task to return a size-2 array with the start and ending index of where the targeted element exists in the array.

Here is the prompt:

Solution Steps

Try to think of a mental solution for yourself before reading any further.

Ignoring the trivial linear solution, we'll focus on the Binary Search solution. Let's think of the steps:

Binary Search for the target
Split the array into "lower" and "upper"
Binary Search on both, separately
Repeat until both splits no longer find the target

Pretty straight forward, I had a lot of fun solving it with Go - most of the syntax is similar to other languages. One of Go's most important features is how simple it makes Concurrency and multi-threading. It uses a data type called Channels with its native Goroutine to synchronize data across threads. Think of it as async / await in other languages.

Code

We'll make a simple Binary Search method, with runtime of O(log n):

// BinarySearch method
func findTarget(nums []int, target int) int {
    low, high := 0, len(nums) - 1

    for low <= high {
        mid := (high + low) / 2

        if nums[mid] == target {
            return mid
        }

        if nums[mid] < target {
            low = mid + 1
        } else {
            high = mid - 1
        }
    }

    return -1
}

We'll call this method a few times, but on ever-decreasing slices of the array - we'll never call it with the same memory space twice.

Now we can easily find any initial target:

func searchRange(nums []int, target int) []int {
    // Initial Search
    high := findTarget(nums, target)

    // Didn't find it, return early
    if high == -1 {
        return []int{-1, -1}
    }
    // TODO: finish function
}

Here we have the early return, when the target does not exist at all. But now what happens when we find it? Well we need to search up and down the array. We can of course do this linearly, but think about the worst case: what if theres an array of 10 million elements, all target. If we started with the center - now we have to linearly crawl through 5 million elements up and down the array. Not great!

Because of that, we'll stick with Binary Search. Golang allows us to cut up its slice datatype (slices are pretty much arrays, with a lot more flexibility, read more here). Without using concurrency, here's the rest of the method:

func searchRange(nums []int, target int) []int {
// ...

// Found target, lets search left and right
    low := high

    // Search lower half of array
    for {
        temp := findTarget(nums[:low], target)
        if temp == -1 {
            break
        }
        low = temp
    }

    // Search upper half of array
    for {        
        temp := findTarget(nums[high + 1:], target)
        if temp == -1 {
            break
        }
        // temp is reindexed at 0 - account for that
        high += temp + 1
    }

    return []int{low, high}
}

Pretty straight forward, we're just binary searching until we no longer find the element on each slice. Great! This passes on Leetcode, and we can be done. But how can we make this a little better? A primary bottleneck with this code is the fact that the "Upper" search is completely blocked until the "Lower" search completes.

We have an opportunity here - the two for loops are acting on completely separate memory addresses. Let's see what we can do with Goroutines and a Channel, here's the entire completed function, with added concurrency:

func searchRange(nums []int, target int) []int {
    // Initial Search
    high := findTarget(nums, target)

    // Didn't find it, return early
    if high == -1 {
        return []int{-1, -1}
    }

    // Hold our data from the threads
    bounds := make(chan int, 2)

    // Search lower half of array, in its own thread (goroutine)
    go func(low int) {
        for {
            temp := findTarget(nums[:low], target)
            if temp == -1 {
                break
            }
            low = temp
        } 
        // Shovel the lower-bound into the Channel
        bounds<-low
    }(high)

    // Search upper half of array, in its own thread (goroutine)
    go func(high int) {
        for {
            temp := findTarget(nums[high + 1:], target)
            if temp == -1 {
                break
            }
            high += temp + 1
        }
        // Shovel the upper-bound into the Channel
        bounds<-high
    }(high)

    newLow := <-bounds
    newHigh := <-bounds

    // No garauntee which one finishes first, so order them
    if newLow > newHigh {
        newLow, newHigh = newHigh, newLow
    }

    return []int{newLow, newHigh}
}

Now, we create an anonymous function and call it immediately, but we use the go keyword to run a Goroutine. With the scope of the bounds Channel, we can shovel data in and out of it. When pulling data out of the Channel (<-bounds), Go will block until there is actually data there.

This means that both the "lower" and "upper" slices will be processed simultaneously! Congratulations, you just solved a Leetcode challenge using thread-safe concurrency💪🧵!

Follow up

We can also clean this code up a bit by pulling the functions for "lower" and "upper" out into their own methods. This would make the primary searchRange method a bit cleaner. But for the sake of simplicity, I left them in.

Infinite Scroll with Remix Run

Phil Tenteromano — Wed, 16 Feb 2022 15:01:44 +0000

Introduction

Remix Run has landed and has created a lot of buzz in the the javascript framework world. After digging in, it motivated me to try it out by starting a web project that I've put to the side for far too long. One of the main features of this project is viewing a list of an arbitrary amount of photos, fed from a Rails API. This means infinite scroll. A video of the final result is at the bottom.

Traditionally, with client side react, we'd just listen to some breakpoint on scroll or use a virtualization tool package like react-virtual. Then we fire off our own methods, merge the state, and repeat.

Remix Run however, handles its components both on the server (SSR) and in the browser. When I was first trying out infinite scroll, I found that I was fighting against the loader and action conventions. It felt wrong, and I knew there had to be a better way. Only once I better understood that Remix's url routes are also it's api routes, I began to piece it together.

Reader note: This infinite scroll is built without any other dependencies (the scroll-breakpoint method). The styling is done with tailwindcss, which I think pairs really well with Remix. The Rails API always returns a json response. In this case the fetchPhotos method returns a response in the format:

{ photos: [ { url: "some_url", pid: "12345" }, {...} ] }

The fetchPhotos abstraction can be replaced with any API or database call for data of your choosing.

We'll solve this problem in three steps:

Create a client-side listener for scroll events
Establish a determined breakpoint for when the scroll should fire a data fetch
Merge the newly fetched data into the current data.

All while allowing this process to repeat until there is no more data to be fetched. Let's start!

Leveraging The Scroll

I created a component at app/routes/photos/_index.tsx. In Remix, this is accessible in the browser at /photos. The Rails API I'm using uses a page param to get photos in increments of 10. The initial code to load the page looks like this:

import { useLoaderData, LoaderFunction } from "remix";
import { fetchPhotos } from "~/utils/api/restful";
import type { PhotoHash } from "~/utils/api/types";

export const loader: LoaderFunction = async ({ request }) => {
  // Pass a page number to the Rails API
  const resp = await fetchPhotos(1);
  return resp.photos;
};

export default function Photos() {
  const photos = useLoaderData<PhotoHash[]>();

  return (
    <div className="container mx-auto space-y-2 md:space-y-0 md:gap-2 md:grid md:grid-cols-2 py-4">
      {photos.map((photo) => {
        return (
          <div key={photo.pid} className="w-full border-green-200 h-52">
            <img
              className="mx-auto object-center object-cover h-52 rounded hover:shadow-2xl"
              src={photo.url}
              alt={`photo-${photo.pid}`}
            />
          </div>
        );
      })}
    </div>
  );
}

But this only gets the first page of photos! fetchPhotos(1) is just a call to the Rails server with a first page argument. When the page loads, the loader will fetch the photos and render them into the jsx. The problem remains, how do we dynamically fetch more photos during scroll. Keep in mind that Remix also runs this code on the server where there is no window or document, etc. So we need to rethink our approach!

What we need now is a client side listener for scroll events and the browser height. We'll need some React for that:

import { useEffect, useState } from "react";
// ...

export default function Photos() {
  const photos = useLoaderData<PhotoHash[]>();
  const [scrollPosition, setScrollPosition] = useState(0);
  const [clientHeight, setClientHeight] = useState(0);

  // Add Listeners to scroll and client resize
  useEffect(() => {
    const scrollListener = () => {
      setClientHeight(window.innerHeight);
      setScrollPosition(window.scrollY);
    };

    // Avoid running during SSR
    if (typeof window !== "undefined") {
      window.addEventListener("scroll", scrollListener);
    }

    // Clean up
    return () => {
      if (typeof window !== "undefined") {
        window.removeEventListener("scroll", scrollListener);
      }
    };
  }, []);

return (
  //...
 )
}

Awesome, now if you add a console.log inside the scrollListener you'll see it fire very frequently whenever you scroll, which is a great start. We also check for the window, ensuring the callback only gets attached and removed when the component is rendered on the client. Now we can track where we are during scrolling.

The next step now is to figure out when we want to fire our call to fetch more photos. To do that, we also need to find the height of the parent div that contains all the photos. We'll need a useCallback listener to attach to that parent:

import { useEffect, useState, useCallback } from "react";
//...

export default function Photos() {
  //...
  // We won't care about height until a client-side render
  const [height, setHeight] = useState(null);

  // Set height of the parent container whenever photos are loaded
  const divHeight = useCallback(
    (node) => {
      if (node !== null) {
        setHeight(node.getBoundingClientRect().height);
      }
    },
    [photos.length]
  );

  //...

  return (
    <div ref={divHeight} ...>
      //...
    </div>
  )
}

Attaching this method as the ref of the parent div allows us to set the height into our components state. Furthermore, when we create a dependency on photos.length we are ensuring the container's height is set properly every time the number of photos change, which would alter the height of that container div.

Now we just need to know when we are firing our API call. We can do a little custom algebra here. Note: This all varies based upon your layout, the media size (mobile, large desktops, etc). YMMV! At the very least, the parent div should be scrollable from the initial load for this to work properly.

//...
export default Photos() {
  const [shouldFetch, setShouldFetch] = useState(true);
  //...

  // Listen on scrolls. Fire on some self-described breakpoint
  useEffect(() => {
    if (!shouldFetch || !height) return;
    if (clientHeight + scrollPosition + 100 < height) return;
    if (fetcher.state == "loading") return;
    console.log("SHOULD BE FETCHING!");

    setShouldFetch(false);
  }, [clientHeight, scrollPosition]);
  //...
}

This check clientHeight + scrollPosition + 100 < height is the scroll check, and is completely customizable in your own infinite scroll. This fires with the clientHeight and scrollPosition dependencies so once the criteria is met, we get through the Guard clauses and reach that console.log statement. Update: as of a newer version of remix, I've added the next condition fetcher.state == "loading". We need this to ensure we only refetch when the fetcher is not already fetching! Try it yourself, the log should fire once and only once - preventing further calls due to setShouldFetch(false).

Remix Conventions

So now we want to replace that console.log with a real API call and merge them into our photos; allowing this to repeat for as long as there are pages with photo data. But the question with Remix is – where should we call our API fetch from?

Remix's routes are also its API routes. This means that if you want to fetch data, well, you should hit your own routes. In this case the route is itself (/photos), just with a different page parameter (to be sent to our Rails API). Let's look at the loader for a second, and add some url query parameter for the page:

//...
// Pull page down from the loader's api request
const getPage = (searchParams: URLSearchParams) =>
  Number(searchParams.get("page") || "1");

export const loader: LoaderFunction = async ({ request }) => {
  const page = getPage(new URL(request.url).searchParams);
  const resp = await fetchPhotos(page);
  return resp.photos;
};

export default function Photos() {
  //...
}

By parsing the page URL parameter, we can now make this loader a little bit more dynamic. Hopefully you see where I'm going with this – to fetch more data, we just continuously have to load our data from this route, just with another parameter.

How does Remix do this? There's a nice little hook called useFetcher – you can see the documentation on it here. Most of the time, loader and action are all you need, but useFetcher gives us some fantastic flexibility. Specifically, we're gonna leverage our already built loader, combined with fetcher's load method. Let's call it when we hit our scrolling criteria:

import { useLoaderData, LoaderFunction, useFetcher } from "remix";
//... 

export default function Photos() {
  // Start with two because 1 was pre-loaded
  const [page, setPage] = useState(2); 
  const fetcher = useFetcher();
  //...

  // Listen on scrolls. Fire on some self-described breakpoint
  useEffect(() => {
    if (!shouldFetch || !height) return;
    if (clientHeight + scrollPosition + 100 < height) return;
    if (fetcher.state == "loading") return;
    fetcher.load(`/photos?index&page=${page}`);

    setShouldFetch(false);
  }, [clientHeight, scrollPosition, fetcher.state]);
  //...
}

Alright, we are leveraging the fetcher to load the next page (2) when we reach close to the bottom of the parent div. The fetcher calls the loader from our route, and applies a page query parameter. Keep in mind, we add the index parameter because this route is an index route; refer to the useFetcher docs for greater detail. So now we need to pull the newly fetched photos out and add them to the UI. And what about continuously grabbing more data like "Infinite Scroll" promises? Well, the fetcher is stateful, so we'll leverage this in a new, final useEffect:

//...
export default function Photos() {
  const initialPhotos = useLoaderData<PhotoHash[]>();
  const [photos, setPhotos] = useState(initialPhotos);
  //...

  // Merge photos, increment page, and allow fetching again
  useEffect(() => {
    // Discontinue API calls if the last page has been reached
    if (fetcher.data && fetcher.data.length === 0) {
      setShouldFetch(false);
      return;
    }

    // Photos contain data, merge them and allow the possiblity of another fetch
    if (fetcher.data && fetcher.data.length > 0) {
      setPhotos((prevPhotos: PhotoHash[]) => [...prevPhotos, ...fetcher.data]);
      setPage((page: number) => page + 1);
      setShouldFetch(true);
    }
  }, [fetcher.data]);
  //...
}

You can read about fetcher.data here; it's pretty much just the result of .load(), which in our case is an array of photos. In this useEffect, we depend on fetcher.data, and call this whenever that has changed - which directly corresponds to the previous useEffect where fetcher.load(...) is called.

Let's dive in to this new useEffect. When the photos array is 0 we stop fetching all together, meaning we've reached the end of all possible photos (your data source might be different). This prevents the API from being spammed, or making unnecessary calls.

But when there is photo data in the array, we merge those newly fetched photos with our current photos. Then we increment the page number by one, and finally we set our shouldFetch to true, signaling that we want to get the next page when the user has scrolled enough.

Behind the scenes, once the new photos are merged, the container div will grow. This causes a re-size of the height variable. When a user scrolls, the useEffect with fetcher.load() will continue to be triggered but the breakpoint has now changed, forcing the Guard clause to return early. Only when the user scrolls and hits that newly calculated breakpoint will the Guard clauses be bypassed, and fetcher.load() will be called again with the next page number. This will eventually update fetcher.data, causing another photo merge. This process will repeat as the user scrolls, until there is no more data being received from the API.

Below is a little preview of how it works in my browser, along with my console output. You can also view the code for the whole file at this gist.

Thank you all for reading! I hope this helps you deliver a dependency free, Remix-like infinite scroll experience. Let me know if you have any feedback or suggestions in the comments below. Good luck and have fun with Remix!

How does a baby pronounce Memorization? Memoization!

Phil Tenteromano — Sat, 21 Nov 2020 01:18:03 +0000

Memoization is a concept of computation in which common results are stored, or cached, to avoid re-calculation. This is extremely useful when an algorithm has an increasing number of similarly computed branches. Let's dive into a common example with Javascript, with the recursive Fibonacci sequence.

Here's a simple recursive Fib:

const fib = (n) => {
  if (n < 2) return n;

  return fib(n - 1) + fib(n - 2);
}

The big O of this algorithm evaluates to O(2^n). Hopefully we can all agree - this is abysmal.

Let's evaluate the line return fib(n - 1) + fib(n - 2);. At every recursive call, we are now branching down into two more Fib calls; and so on and so on. However, Fib looks backwards at itself: n-1 and n-2. Which means there will be many recursive Fib's which want to calculate the same thing. If we leave them to their devices, the call stack could easily be overwhelmed, and even for relatively small n, computation will take a long time (try fib(50)).

This is where memoization comes in. It allows us to avoid every recursive Fib call from branching into clones like something out of the Matrix movies. How? By caching the result when we've already found the answer the first time. That way, when another branch wants to calculate a fib(k) for some k > 2, we don't have to keep climbing the call stack with two more subsequent Fibs - we could return early with a concrete result.

Let's build our memoization function, we'll call it memo

const memo = (funcToMemo) => {
  const cache = {};

  // Return a new function that is memoized
  return function(...args) {
    // We've computed this already!
    if (cache[args]) return cache[args];

    // Never seen it? Compute it, but store it after
    const result = funcToMemo(...args);
    cache[args] = result;

    return result;
  }
}

Javascript treats functions as first-class citizens, so we can utilize closures that allow us to build this memoization function. I'd suggest reading up on closures and first-class functions if you're unfamiliar.

The memo function passes a cache object to an anonymous function which is now able to store, collect, and retain that information through recursive calls.

Now that we have this closure-enabled memoization function. We can wrap it around our fib function. However, due to how memory and naming is aligned, we have to sync it with the proper function names. Let's assume we want to call our memoized fib memoFib. We can do that easily with:

const memoFib = memo(fib);

However, since the fib function recursively calls the fib function itself, it will lose scope on the memoFib, and won't know about its brand new, speedy self. To really make this work, we have to update the recursive call with the anticipated memoized function name:

const fib = (n) => {
  if (n < 2) return n;

  // Recursively call the fast memoized fib
  return memoFib(n - 1) + memoFib(n - 2);
}

const memoFib = memo(fib);

And we're done! With a little proactive coding, we can call some insanely large fib numbers we would otherwise not be able to run at all. Try this with something like memoFib(500) - the number is massive, and computed fast!

Merge into Master Often? Automate!

Phil Tenteromano — Wed, 04 Mar 2020 18:11:45 +0000

Working on a Repo

My engineering department is decently sized, about 50-60 engineers all pushing to (typically) the same repository. Changes happen all the time that force us to merge an updated master into a working branch. This is due to a number of different reasons. One being our heavy reliance on tests from a number of different frameworks, across a broad codebase.

Recently, I found myself constantly running git fetch and git merge origin/master. This redundancy irked me. I, like most sane developers, love the terminal and the command line. So I thought back to my school days were we played around with bash and making our own custom commands. So I decided to make things a little easier.

Automation

Note: I work on MacOS

This'll be quick! In my ~/.bash_profile I put the following code snippet:

# Load custom bash functions
if [ -r ~/.custom_cmds.sh ]; then
  source ~/.custom_cmds.sh
fi

This simply looks for the ~/.custom_cmds.sh file, and loads it into every new bash session (by default from ~/.bash_profile).

Create the custom commands file and inside of it, simply put:

merge_master() {
  git fetch;
  git merge origin/master;
}

This creates a bash function called merge_master. Of course, you can name it anything you want, but I went with this.

Afterwards, I ran chmod u+x ~/.custom_cmds.sh to ensure execution rights of the file. Now just restart the terminal, or run source ~/.bash_profile and Boom. You have your first custom command line function! While simple, it makes me a little happier - run it from any of your repositories with a simple merge_master.

With this bash syntax, we can now create any automated function we want that will simplify our command-line-lives. Just add it into your ~/.custom_cmds.sh file!

What else do you like to automate? Bash is incredibly powerful - the options are limitless!

The Three P's of Learning How to Code

Phil Tenteromano — Wed, 09 Oct 2019 11:59:00 +0000

Recently, I made the decision to seek a TA / tutoring position at my university's CS department. As I am currently in my final semester of graduate school, I only saw the positives of being a tutor:

Help others overcome struggles
Improve peer-review skills
Reinforce my own learning
Give back to academia, especially my alma mater

So far, tutoring has been an absolute joy (while the grading part is... tedious). As the semester has gone on, more and more students have been coming to me during my tutoring hours. I also frequently tutor by appointment, whenever I have free time during my day.

Before I continue, I want to be specific about the tutoring topics and what these students are learning. I'm the TA for the CS2200 course - Data Structures. This course is the third programming course in the CS curriculum (after CS1, CS2, and not counting math-courses). The curriculum revolves around C++, a language I have the utmost respect for (mostly out of fear). TA aside, I tutor any CS student who walks in - and it's almost entirely students from those first three classes seeking help; beginners, if you will.

A language like C++ can be absolutely DAUNTING for beginners, especially once objects come into play. But this post isn't about C++, because any language can be daunting for beginners. And from everything I have seen from tutoring, this post isn't even about programming languages.

Easing Frustrations

Students that come in for tutoring sessions are typically (and predictably) coming in for help on their assignments. The assignments are written out as a page or two of specifications and requirements. Some come in asking specific questions in reference to a bug, while others just give off that 'completely lost' vibe. And since C++ is a compiled language, it can be easy to go from a working program, to throwing your laptop out the window in a few short lines of code.

The first question I always ask them is: "Does your program compile?"
Their answer is typically: "No", or the "Well it did yesterday, but then..."

This leads me to the first "P" of Learning How to Code:

Piece by Piece

Bonus points for using alliteration?
Almost always I see students trying to read through the entire assignment and tackle it as if it is one big monotonous block. They code and they code one line after the other thinking they are painting a masterpiece. As the saying goes: "to err is human", and that is never more true than when you start coding.

I challenge them to change their perspective: that they shouldn't look at their code or their program as a Picasso masterpiece. Instead, they should look at it as a jigsaw puzzle. I couldn't tell you where to start on creating a Picasso painting, but I know damn well how to put together a jigsaw puzzle.

I like this analogy because it helps them take a step back and see that all code really is, is just a series of instructions. If you modularize a large instruction set into smaller and smaller subsets you eventually get a bunch of manageable pieces, just like a jigsaw puzzle.

So I ask them to do multiple reads of an assignment's specifications. Then, when they have a good grasp of what is necessary, start breaking down the whole and implementing a little at a time. Writing a few lines of code, verifying it's validity, and repeating the process is a surefire way to increase efficiency and save you all that frustration when it comes time to fix those errors!

For new students in my tutoring, I like to go with a Bank Account example. I ask, how could you break the concept of a Bank Account down into manageable chunks? What could you implement and test, one at a time?

Pen and Paper

Alliteration again!?
Piggybacking off the first concept, 'Pen and Paper' is exactly what it sounds like. Writing down notes, drawing diagrams, visualizing instruction sets, and all manner of blueprinting are incredibly useful for clearing up the mind. Doing this not only adds to, and increases workflow, but it allows the programmer to take a step back and conceptualize their thoughts.

Personally, this one took me a while to figure out myself. Now as a tutor, it took me all of 2 days for me to start harping on students to get a pen and paper out. I noticed that when they would come in, they would only have their laptops and stare at them; they'd be banging their heads against a wall trying to code themselves out of their problems. I say, "What're you doing? Do you have a plan? No? Then why not draw one up instead of coding in circles?".

Similarly, I don't tutor by showing them my code, I get on a whiteboard and literally draw diagrams and pseudo code for them. I draw out what's needed and box out what can be separated out as a puzzle piece. I even convey to them that coding is barely even about coding - it's about problem solving. Solve the problem first, then code your solution. And... boom, transition!

Problem Solving

I'll take 2/3 on the alliteration.

Question: "What's a programmers best friend?"
Answer 1: "Google!"
Answer 2: "Stack Overflow!"

We all solve problems everyday, be it life problems or code problems. I remember when I saw my first C++ compile-time error. It was like reading hieroglyphics, I had absolutely no idea how to interpret it. This was a real challenge for me to overcome, a problem I had to solve!

Leveraging the first two P's, Problem Solving seeks to close any loopholes that may come about. With the assumption that the programmer has broken down a large task into manageable smaller ones, and they have properly conceptualize how to implement a small task, then any further problems should now be in their own independent, manageable state. This is where programmer knowledge, or of course the beautiful internet come into play; time to solve that problem.

If the first two P's are not followed, then Problem Solving can become a chaotic mess; a place where one error follows another, which follows another, and another, and then you spill coffee on your laptop, etc. Only by breaking things down and understanding can this force future obstacles to become less obscure, with exponentially less influence.

The cliche, 'nobody knows everything', couldn't be more true than in tech. The internet is the information age that we live in. It's out there, use it! Of course, if you copy and paste code you don't understand then you're only doing yourself a disservice - this will come back to haunt you!

Bonus **P**!

Practice!

Coding is hard by default, it's rewiring our brains into a new way of thinking. Lectures and videos are great, but they just won't teach you the way real practice would. We learn better and retain more information when we struggle. I am a big believer in exposure, exposure, exposure. Difficult concepts aren't meant to be mastered in a 3 month semester - it takes time, practice, and a dedication to drive on.

Whether you come from a CS degree, bootcamp, or self-taught background, this bonus P may just be the most important one!

Vets Who Code — Servicing Tech Opportunities to Those Who Served

Phil Tenteromano — Wed, 03 Jul 2019 18:01:25 +0000

When I was separating from the US Army in 2016, I thought I had my future all figured out. I was ready to take on new challenges — I had been accepted to my dream school in NYC, I was going to be surrounded by an incredible family support system, and I had my sights aimed at the tech industry.

I was lucky enough to have a pretty decent transition; 10 days after my separation date I was in the classroom, solving discrete mathematics problems. “I’m a veteran, I’m adapting to the classroom well, and I’m going into a lucrative industry — I’m set!”, I would say to myself.

I was naive enough to think that showing up to class and doing well in academia was going to be a golden ticket in the competitive private sector. Unfortunately, that’s not how it was. It hit me like a ton of bricks when I first went out applying for internships; I started off the search process thinking employers would hear me say “I know C++”, and they would be throwing offers at me.

Boy, was I wrong. I got a ton of advice from an alumni network, my mentor, and my colleagues who had gone through the tech-ringer before — do projects, do practical work, do something outside of the classroom that shows off your skills. It all started to click, and a fire burned inside of me to get after it and do more.

Learning as a Lifestyle

College was great, but it was a lot of theory. There were projects sure, but not enough — or at least, not individualized to where I can really show it off and impress employers. So I first started going out and learning on Udemy, practicing algorithms on hackerrank, and just doing more in my free time.

It was fine at first, but after a while I felt a little lost. It was unstructured, clunky, and just overall inefficient. I had a few veteran friends at school and we discussed how being a veteran could help us in the real world. One of the things we really noticed was a lack of veteran communities in our respective fields — it felt lonely. It especially felt lonely after spending years as a soldier surrounded by other soldiers near 24/7. This gave me an idea to start looking for veteran-tech groups that could satisfy that need for camaraderie — except now as soldiers and developers.

Finding Vets Who Code

I came across Vets Who Code in Summer of 2018 after some online digging and I really was intrigued. Firstly, they had a vetting process (no pun intended); they wanted some proof of basic knowledge in the field, a “prework” exercise that displayed not only skill level, but also a willingness to commit.

Now, Vets Who Code, or VWC, wasn’t just vetting people to be a part of some exclusive chat-group or something like that. They were providing free training to those veterans who went out and did the prework, thus showing their drive and their commitment. This training would last about 16–18 weeks, would meet via Slack or video calls 3–4 nights a week, and teach some of the most popular frameworks and technologies being used in the industry.

I was sold. I reached out and let them know my background and why I wanted to be there. Jerome Hardaway got back to me and asked me to provide that golden ticket (the prework). I had created a website earlier in the year, but it was a github Pull Request on their repository that really caught their eye. It was a gratifying experience just to be accepted and engage in a new chapter of learning. It was really exciting to be with other veterans, in a community focused on the tech industry.

My training cohort ran for 17 weeks during the Fall of 2018, while I also maintained a full-time school schedule. The VWC cohort really set the tone by giving us hands on practice and guidance to understand frameworks like React and Express, while exposing us to real-world industry experience. This again, all coming from fellow veterans. I just wasn’t getting that kind of utility out of school (academia can be real bubble).

So on top of the theory I was getting in the classroom, I was taking online classes with VWC and learning about all the nuanced topics of the industry. We were coding non-stop; our instructor, Brad Hankee, did an incredible job of keeping myself and the other veterans in the cohort engaged and challenged all at the same time. Even with my CS background, the cohort was able to be individualized enough to give each veteran a chance at breaking the mold and feeling confident about entering the tech space.

Hard Work → Reward

VWC’s cohort focused a lot on the Javascript language, and rightfully so, as it is pretty much the most widely used language in the industry. That right there did so much for me — I had barely even wrote a line of javascript before that (and as a CS major!?).

Before VWC, I had struggled so hard to find an internship. The Summer before I started the cohort, I had settled on an internship with a just-seeded start up with almost no money to spare, and more importantly, no mentorship. It wasn’t a great experience.

I finished the VWC cohort in December of 2018 and I knew it was about time to start applying for internships.

Let me say this: I had two offers by January from prestigious companies.

I was ecstatic to hear that good news. To put this in perspective, those offers came after I applied to maybe 5% of my total applications the year before. If that doesn’t speak volumes about what VWC does, I don’t know what does.

But wait — theres more! VWC doesn’t just offer this free training and send you on your way. It’s a community of veterans; after my cohort ended I felt empowered and only wanted more of something like this. I am 100% an active member of the community and communicate daily in the slack channel.

After my offers, Jerome asked me to contribute to teaching in the next cohort. I was given 2 weeks of teaching an expanded ‘Computer Science’ curriculum that wasn’t fleshed out as much in previous cohorts. Excited and honored, I said yes — I considered it a great way to give back to my fellow veterans, and to VWC.

Overall, Vets Who Code was an absolute catalyst to get me out of a slump and propel me to greater heights. It doesn’t matter the extent of technological background either, every single veteran is welcome. We only ask one thing — drive and commitment. Learning to code is a challenging road, but veterans are used to challenging roads. Whether you’re a veteran who has never written a line of code or you’ve been working at Google, we would love to have you on board and help you reach your potential.