my goal is to start generating names using bigram frequency, and then in part 2 we will start building a single layer neural network to do the same thing.

So where do we begin?

Let’s take a look at the dataset we are working with

words = open('names.txt', 'r').read().splitlines()
words[:10]

[’emma’,
 ‘olivia’,
 ‘ava’,
 ‘isabella’,
 ‘sophia’,
 ‘charlotte’,
 ‘mia’,
 ‘amelia’,
 ‘harper’,
 ‘evelyn’]

pretty simple, one name per line, lets get some more info next

len(words)
32033

min(len(w) for w in words)
2

max(len(w) for w in words)
15

okay cool so there is about 32,000 names in the training data, the shortest name is 2 letters long and the longest name is 15 letters long.

to outline my initial approach to the problem of generating new names based on the training data is the following: we can deterministically figure out the probability of one letter coming after another by going through the entire dataset, keeping track of all the bigrams (two letter words combos such as ‘eg’ or ‘va’) and then determine probabilities of each bigram occurring, and then using those probabilities make a guess at what letter is likely to come next given a letter, and use that to build up full names by continuously generating the next letter based on the previous. So we will only be looking one letter ahead for now.

if that’s a bit confusing dont worry, lets get into it step by step.

so firstly lets loop through all the words in the list of words, and for each word we use a clever method called zip we allows us to iterate through every bigram in all the names in the text file. additionally for every name we iterate through we add special characters to denote the start and end of each name. this will help us later on in figuring out the probabilities of a word starting/ending with a letter.

b = {}
for w in words:
    chs = ['<S>'] + list(w) + ['<E>']
    for ch1, ch2 in zip(chs, chs[1:]):
        bigram = (ch1, ch2)
        b[bigram] = b.get(bigram, 0) + 1
        #print(ch1, ch2)
sorted(b.items(), key = lambda kv: -kv[1])

[(('n', '<E>'), 6763),
 (('a', '<E>'), 6640),
 (('a', 'n'), 5438),
 (('<S>', 'a'), 4410),
 (('e', '<E>'), 3983),
 (('a', 'r'), 3264),
 (('e', 'l'), 3248),
 (('r', 'i'), 3033),
 (('n', 'a'), 2977),
...]

if you can’t decipher the output above, this is what is happening: we maintain a dictionary of all the bigrams and their frequencies then we break each word into it’s bigrams and increment it’s corresponding count in the map. after we’ve looped through all the words we sort the map, in this case the most common bigram is (‘n’, ‘<E>’) indicating ‘n’ followed by the name ending.

to make the code very clear the flow for the name “emma” would be processed like this: “emma” → “<S>emma<E>” → [(“<S>”, “e”), (“e”, “m”),…] and so on for all the bigrams in “emma”.

so this works but it’s not very efficient or extendable. ideally what we want is a 2D array/matrix that will store the counts for each possible bigram combo where we have ‘a’ to ‘z’ down the x-axis and ‘a’ to ‘z’ along the y-axis as well as a row and column for ‘.’. we would then easily be able to find the probably of “a” coming after “n” by finding “a” on the x-axis and “n” on the y-axis and lining them up. again if this doesn’t make sense, just scroll down a bit to see the final matrix we come up with.

first to make our lives easier lets start using PyTorch instead of default Python code.

another note: instead of keeping track of <S> and <E> for the start and end we will instead replace them both with a “.” - this will make our matrix much easier to read. a future optimisation would preferably use different tokens for start vs end but lets keep our lives simple for now.

we will import Torch and create a 27x27. that is 26 letters + the “.” to indicate either start/end.

import torch
N = torch.zeros((27,27), dtype = torch.int32)

this just create a 2D array with all counts starting at 0.

given that our matrix works in numbers(or indexes) and not letters we will need a method to convert letters to indices into the matrix.

chars = sorted(list(set(''.join(words))))
stoi = {s:i+1 for i,s in enumerate(chars)}
stoi['.'] = 0
itos = {i:s for s,i in stoi.items()}

stoi
{'a': 1, 'b': 2, 'c': 3,'d': 4,'e': 5,'f': 6,'g': 7,'h': 8,'i': 9,'j': 10,'k': 11, 
'l': 12, 'm': 13,'n': 14,'o': 15,'p': 16,'q': 17,'r': 18,'s': 19,'t': 20, 'u': 21,
 'v': 22, 'w': 23, 'x': 24, 'y': 25, 'z': 26,'.': 0}

stoi{} converts the letters into numbers and the itos{} converts the numbers back into their corresponding letters. above is what stoi map looks like.

next we can loop through all the bigrams again but this time we will be adding the counts to our 2D array/matrix.

for w in words:
    chs = ['.'] + list(w) + ['.']
    for ch1, ch2 in zip(chs, chs[1:]):
        ix1 = stoi[ch1]
        ix2 = stoi[ch2]
        N[ix1, ix2] += 1

once we have done that lets visualise our progress so far.

import matplotlib.pyplot as plt
%matplotlib inline

plt.figure(figsize=(16,16))
plt.imshow(N, cmap='Blues')
for i in range(27):
    for j in range(27):
        chstr = itos[i] + itos[j]
        plt.text(j, i, chstr, ha="center", va="bottom", color='gray')
        plt.text(j, i, N[i,j].item(), ha="center", va="top", color='gray')
plt.axis('off')

now we have a table with every bigram count from our training data. for example the entry “zh” = 43 tells us that the string “zh” occurs 43 times in all the names in the training data. also “.g” = 669 implies 669 names start with ‘g’ and lastly “x.” = 164 implies that 164 names end with x.

so now lets take the second row for example, this is the row for ‘b’, so if we want to figure out the most likely next letter in the name given the current letter we are looking at is ‘b’ this is the row that will help us do that.

we can sum the row’s counts for each entry in b’s row and then divide each entries count by the row’s sum to determine the probability of that specific letter coming after ‘b’ in a name.

in other words we are normalising the row. the values in the row after dividing will now sum to 1.

lets do that for just row ‘b’ first:

N[2]
tensor([114, 321,  38,   1,  65, 655,   0,   0,  41, 217,   1,   0, 103,   0,
          4, 105,   0,   0, 842,   8,   2,  45,   0,   0,   0,  83,   0],
       dtype=torch.int32)
p = N[2].float()
p = p / p.sum()
p
tensor([0.0000, 0.1377, 0.0408, 0.0481, 0.0528, 0.0478, 0.0130, 0.0209, 0.0273,
        0.0184, 0.0756, 0.0925, 0.0491, 0.0792, 0.0358, 0.0123, 0.0161, 0.0029,
        0.0512, 0.0642, 0.0408, 0.0024, 0.0117, 0.0096, 0.0042, 0.0167, 0.0290])

firstly we just grab the ‘b’ row from the matrix, we then convert the values to floats so they can have decimal points. Once we have done that we can take each entry in the row and divide it by the sum of the row(normalise it). that gives us the p tensor. this contains the probabilities of each letter occurring next given we have a ‘b’ right now as the current letter. example: p[4] gives us the probability that ‘c’ comes after ‘b’ based on the names we have seen in the training data set. 0.0481 implies there is about a 5% chance that ‘c’ would be the next letter after ‘b’.

now given a single rows probabilities how do we choose the next letter based on those probabilities? this is where the multinomial comes in…

p = tensor([0.0000, 0.1377, 0.0408, 0.0481, 0.0528, 0.0478, 0.0130, 0.0209, 0.0273,
        0.0184, 0.0756, 0.0925, 0.0491, 0.0792, 0.0358, 0.0123, 0.0161, 0.0029,
        0.0512, 0.0642, 0.0408, 0.0024, 0.0117, 0.0096, 0.0042, 0.0167, 0.0290])
from earlier^^^

ix = torch.multinomial(p, num_samples=1, replacement=True).item()
itos[ix]
'd'

the above code uses the probabilities above to choose a number between 1 and 27, each with a probability of being chosen given above in the tensor p. the numbers it chooses correspond to the index of the letter it determines is likely to come next.

we then convert that chosen index into a string using the map we created earlier and the output is ‘d’. based on the probabilities, and relative frequency from our training data ‘d’ had a 5% chance of being after ‘b’. if we kept sampling using the multinomial we would probably get a different letter each time, it does not pick the most likely next letter, it picks a letter based on it’s probability to be picked which is what is stored in tensor p.

to sample an entire word we would run the above code again and again. so we would generate ‘b’ lets say as the first letter using the top row of our table above(since the top row corresponds to probabilities of words starting with that given letter) and then we would refer to the row corresponding to ‘b’ to generate the next letter and so on until we generate a ‘.’ which means the end of the name.

lets do this now - first lets turn the entire matrix we generated above into probabilities (in other words normalise every row) so we dont need to normalise each row every time we sample. you’ll observe now that each row in the matrix below sums to 1.

P = N.float()
P /=P.sum(1, keepdims=True)

now that we have our probability matrix we can start sampling from it. lets generate 5 names:

for i in range(5):
    ix = 0
    out = []
    while True:
        p = P[ix]
        ix = torch.multinomial(p, num_samples=1, replacement=True).item()
        out.append(itos[ix])
        if ix == 0:
            break
    print(''.join(out))

cexze.
momasurailezitynn.
konimittain.
llayn.
ka.

read through the code and convince yourself that this is using the probability matrix above to continuously generate letters based on the previous letter until we reach a ‘.’ which means the word has ended. remember given any letter there is always a chance the next character is a ‘.’ which implies the end of a name. refer to the first column of the above matrix for those probabilities.

fair enough that worked but did it really?

the names we generated still look pretty random, how can we prove that we did “train” this network on the 32,000 names in the text file.

well lets say we add 10000 to every probability in the P matrix above, in other words make every letter just as likely as the next for every letter, here is the output:

for i in range(4):
    ix = 0
    out = []
    while True:
        p = P[ix] + 10000
        ix = torch.multinomial(p, num_samples=1, replacement=True).item()
        out.append(itos[ix])
        if ix == 0:
            break
    print(''.join(out))

zoglkurkicqzktyhwmvmzimjttainrlkfukzkktda.
sfcxvpubjtbhrmgotzx.
iczixqctvujkwptedogkkjemkmmsidguenkbvgynywftbspmhwcivgbvtahlvsu.
dsdxxblnwglhpyiw.

as you can see the output is pretty garbage compared to what we had earlier. i call that progress!!!

and that as far as we are going to go today…

as a sneak peek of what we will do in part 2…we need a way of calculating how “good” the output is compared to what we would actually like it to output. we will be using something called the negative log likelihood for this.

this will help us adjust the weights and biases of our neural network. what we end up doing with the neural net is basically updating the matrix P’s probabilities to be as accurate as possible but instead of counting the frequencies of bigrams we feed in training data and adjusts parameters which adjusts the values stored in P.

for now dont worry about that, if you’re excited for part 2 the best thing you can do now is understand what we did today back to front, implement it yourself, try the exercise below. you can use your own .txt file of names or any training data. use your llm of choice to explain anything I missed or glossed over. get your code working like mine and I promise you will double your level of understanding.

next up → real neural networks!

an exercise for the readers at home, try to extend this program but instead of using bi-grams I want you to use tri-grams. In other words, find the next most likely letter based on the TWO preceding letters instead of just the previous letter.

references:

https://www.youtube.com/watch?v=PaCmpygFfXo

https://github.com/karpathy/makemore

today what i’d like to do since im assuming you are not already familiar with Rust is compare it to a language you are probably already familiar with - Python.

Python was created over 35 years ago by a dude called Guido Van Rossum, it only became popular much later on though since it launched around relatively the same time as Java which had a company called Sun marketing it with around a $500 million budget so it did not get it’s well deserved fame until much later…

Rust on the other hand was launched in 2009, which makes it relatively new compared to most popular programming languages around these days… but it’s first stable version only came out in 2015 with the help of the Mozilla Foundation funding it. the creator was a dude called Graydon Hoare. he created it as a personal project after he was frustrated with an elevator software that crashed. Rust, he said, was named after a fungi with the same name that is “over-engineered for survival”. and as you’ll see it’s quite a fitting name.

so since im sure you probably know a lot about Python let me just tell you a couple more facts about Rust since it’s pretty interesting… During the early years, the Rust compiler was written in 38,000 lines of OCaml code and was based on “mostly decades-old research”, read more about it here.

anyways so how do you actually write a rust program, and how does it differ from Python? lets begin…

so starting of with the most basic program here’s how it’s done in python:

print("hello world")

and here’s the equivalent rust program:

fn main() {
    println!("Hello, world!");
}

unlike Python, every Rust program needs a main method which is where the program’s entry point is. it has to be called main() and does not have to return anything.

printing in Rust is pretty similar to python, instead of print we just use something called println! did you notice the exclamation mark? that’s not me shouting at Rust to print something, it’s what we call a macro in Rust. the macro expands at compile time to accept the number of arguments given to it. for example we could called println! like we did earlier or we could call it like this:

fn main() {
    let name = "tom";
    println!("Hello, {}", name);
}

which would expand println into a function at compile time that now accepts two arguments instead of one.

so now we can print text to the screen, how does defining variables differ between Python & Rust? Python is pretty simple:

name = "Tom"
age = 22

it genuinely does not get easier than that, in Rust we are going to have to be a little bit more specific:

let name = String::from("Tom");
let mut age: u16 = 22;

there is much to unpack here but let’s go through it slowly.

luckily Rust is usually able to infer the type which helps but we are free to specify it like we have done for the age variable if we like, u16 being an unsigned 16-bit integer in this case. the mut keyword is what tells Rust that we want this variable to be able to change in the future, otherwise we are not allowed to change it’s value throughout it’s lifetime, it’s a constant. This is what helps rust know when to free memory.

this might surprise you but there is no such thing as null or undefined in rust, it does not exist. in python it’s as simple as:

name = None
print(name.upper())  # crashes at runtime

but in Rust we have something called a Option which works like this:

let name: Option<String> = None;

match name {
    Some(n) => println!("{}", n.to_uppercase()),
    None => println!("no name!"),
}

Optionals somewhat exist in JavaScript too but this is how they work in Rust. an Optional can either have a value of Some() or None. we are then able to use something like match which is a fancy if statement. if the value of name has a value, i.e its of type Some(n) then print it out uppercased, if its of value None then print out “no name”. Some() basically wraps the value contained within the Option if it exists.

null & undefined literally not existing in Rust prevents a whole class of null pointer exception bugs that are all too common in lower level languages where you need to manage memory yourself.

speaking of memory management how does it work in Rust vs Python? well in Python there is a garbage collector so that makes it pretty trivial. a garbage collector is the thing that runs in the background freeing up memory while your program runs, thats the same for most languages these days. Rust does something pretty unique. it does not have a garbage collector and at the same time does not expect you to free memory manually.

you might be thinking that that sounds impossible but something special about Rust which i’ll cover in a future article called the Borrow Checker allows Rust to guarantee that as soon as a variable goes out of scope it can safely drop it without your program encountering any errors.

I could go on and on about how great Rust is but I currently still default to Python when I need to get something up and running quickly. if you truly need the speed while still demanding memory safety then Rust is great if you are willing to sacrifice development speed since you really have to use your brain when writing Rust code, but it is definitely one of the most satisfying languages to code in that i’ve ever come across.

in summary, rust and python are pretty different beasts. python is easy to get started with, has a garbage collector handling memory for you, and lets you be loose with types and nulls — which is great until it isn’t. rust on the other hand gives you that same memory safety but without the garbage collector, the compiler handles it all at compile time. you also have no null, explicit types, and a main function as your entry point. it’s slower to write but faster to run and significantly harder to shoot yourself in the foot with.

I kept this short and sweet on purpose, just as a mild introduction to Rust since it’s still new, if you enjoyed it and want to hear more about Rust and my journey learning Rust then please let me know in the comments!

Subscribe now

quick credentials so you dont think im making this up… im a software engineer at AWS and since im on a frontend team i theoretically should have at least an idea of what api gateway is, so heres what i do know.

in simple terms api gateway is the front door to your backend. its the bit that sits between the public internet and your actual code. every request from the outside world hits api gateway first, and api gateway goes “okay who is this, are they allowed in, are they sending me way too many requests, and where is this request even supposed to go” and only then does it hand the request off to whatever is doing the real work behind it.

normally if you wanted to expose your code to the internet you would have to build all of that yourself. youd write the code that checks if someone is logged in, the code that stops one guy from spamming you with 10,000 requests a second and taking the whole thing down, the code that checks the incoming data isnt complete garbage, the code that sends /users to one place and /orders to another, the logging, the api keys for your customers… that is a lot of code…and none of that is the actual thing you set out to build. its all just door management. api gateway is the door management. you point it at your backend, you tell it the rules, and it handles everything that happens before a request is allowed to reach your code.

so what actually happens when a request comes in. someone out on the internet sends a GET request to your-api.com/users. api gateway catches it at the matching route. first it checks the authorizer(more on that below), are you even allowed to do this? if not you get a 401 and you never reach the backend at all. then it checks throttling, are we over the rate limit? if yes you get a 429. then it can validate the request, did you actually send me the fields im expecting? if the request survives all of that, api gateway forwards it on to the integration (the thing that does the work - more on that shortly), waits for the response, potentially reshapes it, and sends it back to the caller. all the bouncer stuff happens before your code ever runs. as you can see it handles a ton of things that you’d have to manually do yourself.

the way you set it up is you define routes, which are literally just a method plus a path. GET /users, POST /users, GET /users/{id}, DELETE /orders/{id} and so on. each route points at an integration, which is just a fancy word for “the thing that handles this route” and the integration is usually one of three things. one, a lambda function, by far the most common, this is the lambda + api gateway combo i mentioned in the last post. two, some http endpoint you already have running, a server on ec2, a container, literally any url, and api gateway just forwards the request straight through to it. three, another AWS service directly with no code in between at all, you can have api gateway drop the request straight into an SQS queue or write it into dynamodb without a single line of code.

okay so the whole point of this thing is the stuff it does for you that you would otherwise have to build by hand. auth is the big one, you attach an authorizer to a route and api gateway checks every single caller before letting them in, could be IAM, could be a cognito user pool, or could be a lambda authorizer where you write your own custom “is this token legit” logic. then theres throttling, you set a rate limit and api gateway enforces it so one client cant accidentally (or on purpose) take your backend down. theres api keys and usage plans, so if youre exposing an api to other people you can hand out keys and say this key gets 1000 requests a day and this one gets a million. and theres request validation, caching, CORS, custom domains and logging to cloudwatch, all of which you configure instead of code yourself.

now the one thing that confuses literally everyone. when you go to create an api, aws asks do you want a REST api or an HTTP api, and the names are useless because both of them are for building HTTP apis. heres the actual difference. REST apis are the older, fully loaded option with every feature (api keys, usage plans, request validation, caching, etc). HTTP apis are the newer, stripped down option, fewer features but theyre cheaper and a bit faster. my rule of thumb is just start with an HTTP api and only reach for a REST api if you specifically need a feature it has. theres also WebSocket apis for real-time two-way stuff like chat apps but i havent got the chance to use those yet.

for the ceo’s reading this that care about pricing luckily the model is pretty simple, you basically pay per request. a few dollars per million requests, and HTTP apis are even cheaper than REST apis for the same traffic. theres also a free tier that covers a million calls a month for your first year which is way more than enough to mess around and build something real.

as usual there are a couple of limits it helps to know when youre weighing trade-offs. api gateway has roughly a 29 second timeout on integrations(oddly specific i know), so if your backend takes longer than that api gateway just gives up and returns an error, meaning its not built for long running jobs. it has a max payload size (10MB on REST apis) so its not for uploading huge files, for that youd hand out an s3 upload url instead(more on that in a future article). and theres a default account level rate limit (10,000 requests a second) which you can ask aws to raise if you ever get that big.(one day…)

honestly the fastest way to actually get this is to go build the tiny version. open the aws console, make a lambda with the 3 line handler from my last post, then create an HTTP api, add one route, point it at the lambda, and hit the url it gives you in your browser. then watch your own request travel internet → api gateway → lambda → back to your browser and thats genuinely it.this is a great tutorial if you get stuck.

anyway thats api gateway.it decides who gets in, how often, and where they go, and then it hands the request off to your real code. everything else like the authorizers, the throttling, REST vs HTTP, the pricing, is just detail layered on top of that one idea. if you remember nothing else from this remember “front door” and youre 90% of the way there.

if you learnt something subscribe! xD

Subscribe now

just so you know i have some sort of credentials to speak about this… im a software engineer at AWS and have time and time again worked on lambdas so although i dont know everything here’s what i do know

in simple terms lambda says give me your source code. i’ll allocate a server and run it only when there is a request for it. i’ll take care of hardware, OS, security patches, availability, scaling, maintenance. i won't charge you when your code isn't running.

normally if you wanted to run code on the internet you would go rent a server, install linux, install node or python or whatever, write a little web server that listens on a port, set up a process manager so it restarts when it crashes, get an ssl cert, set up logging, set up monitoring, and then your code finally runs. and that server is on 24/7 whether anyone is using it or not, and youre paying for it 24/7 whether anyone is using it or not. so in my case i’d be paying for an entire server to accommodate my 3 active users :(

lambda just removes all of that. you write a function. one function. it looks like this in python:

`def handler(event, context): return {”hello”: “world”}`

that is genuinely all you have to write. you upload it, you tell aws “hey when something happens, run this code with this information”, and from that moment on aws is responsible for everything else. the server. the runtime. the scaling. the patching. the restart-when-it-crashes. all of it. you just own the function.

so the natural next question is what is the something that causes the function to run, and the answer is basically anything. someone hits an api url, run my function with the form data. a file gets uploaded to s3, run my function with the file. a message lands in a queue, run my function to process the message. its 6am every day, run my function. a database row changes, run my function to send the row to S3 for longterm storage. these are called triggers or event sources and there are like 200 of them and you can pick whichever one matches what youre trying to do.

okay so now that the triggered fired what happens before the code actually starts executing? lets see

an event comes in. the lambda looks around and goes “do i have a warm lambda environment ready for this function?” if yes, great, it shoves the event into that environment and your handler runs basically instantly, well technically in a couple of milliseconds. if no, lambda has to spin up a brand new tiny linux sandbox just for you, download your code into it, start the runtime (the python interpreter or the node process etc.), import all your dependencies, and then run your function. that whole spin-up is called a cold start and depending on your language and how much code you’ve got it can be anywhere from 100ms to a couple of seconds.

after your function finishes lambda keeps it warm for a bit (usually somewhere between a few minutes and an hour) in case another event comes in soon. if another event does come in there is an environment ready to process the request. if not, the environment will eventually disappear.

okay so that covers what it is and how it runs. lets talk about what you actually use it for.

the most common use is sticking a lambda behind something called api gateway and using the two together as a backend api. someone sends a POST request to your-api.com/users, api gateway catches it, invokes your lambda, your lambda does the work, returns a response, api gateway sends it back. pretty easy!

second big use case is file processing. user uploads an image to s3, s3 fires an event, lambda picks up the event which includes the image, resizes it into thumbnails, saves them back to s3. the upload itself is what triggered the work. this is usually configured pretty easily via the aws console or CDK. same with all the other integrations.

third is using lmabdas to connect services together. you have system A and system B and they need to talk to each other but they dont quite speak the same language. solution…write a lambda. it reads from one, transforms the data, writes to the other. from my experience at aws this is probably the most popular use case for lambdas.

fourth is scheduled jobs. cron but in the cloud. some examples off the top of my head are every night at 3am clean up old records, every monday email a report, every 5 minutes check if the api is healthy. eventbridge fires the schedule, lambda runs the function, you go back to sleep. again these sound complex but connecting them is actually really simple.

i dont have a lot of experience with pricing since as a dev at AWS we don’t think a lot about pricing but you pay for two things. number of invocations and how long they run multiplied by how much memory you gave them. there is also a free tier gives you 1 million invocations and 400,000 gb-seconds per month for free. by gb-seconds its the amount of ram allocated to your lambda multiplied by how long the lambda ran.

there are a couple of limits that lambda has though which you honestly dont have to remember but it does help to know when you are discussing trade-offs etc.

it has a hard 15 minute max runtime. it has a stateless model, meaning anything you store in memory or on disk during one invocation is gone the next time, so if you need to remember things between requests you have to put that state somewhere external like dynamodb or s3 or a database. in other words if you create a variable during one invocation the next invocation wont be able to access it. it has cold starts, so if youre building something where every single millisecond of latency matters think about using provisioned concurrency which basically keeps a set amount of lambdas always pre-warmed.

okay so how do you actually try this. honestly the fastest path is just open the aws console, search for lambda, hit “create function”, pick python or node, paste the 3 line handler i wrote earlier, hit test, watch it run, look at the logs in cloudwatch. the whole thing takes maybe 4 minutes and i think doing this once will teach you more than reading 10 more articles like this one. seriously. close this tab after you finish reading and just go click around. its free. use chatgpt if you get stuck.

anyway thats lambda. its just a function that runs when something happens and you pay only for the time it ran. everything else like the runtimes, the triggers, the scaling, the pricing, the cold starts is all just extra details which i honestly learnt a lot of when writing this blog haha. if you remember nothing else from this article remember that one sentence and youll be fine.

i want you to actually go build something with this btw, not just read about it, because lambda is one of those things that goes from “kinda confusing” to “oh thats it?” the second you deploy your first one. so go do it.

if you learnt something subscribe! xD

Subscribe now

i felt like every tutorial was going to be the last one and that once i’d completed this last 6 hour react tutorial i’d be able to build anything, obviously that was not the case.

i would grind through the tutorial, copying the code step by step, even typing along with the video to feel extra productive but alas the second i start building my own project and i ran into a bug i was stuck, straight to chatgpt for an answer (which is a whole other topic on its own btw).

dont get me wrong though, this can be a great way to get the absolute basics of language or topic, a high level overview is always a great way to begin learning something new but if you really want to deeply understand something tutorials that guide you every step of the way are not the way i’d go.

so what now? no tutorials? yes that’s right. im going to limit you to at absolute maximum 2 tutorials when you are starting to learn something new, lets take react as an example. there are hundreds of javascript basics tutorials all over the internet, watch two of those and then come back here. no more than two, okay?

now that we’ve got the basics out of the way, you have a high level overview of the language, we are still going with javascript, so you understand the basics of javascript and now you need to solidify this knowledge in your brain. in a past life i’d jump straight into another tutorial and follow it step by step and feel super productive, or so i thought…

the next step is something i learnt a while ago from another blog i read and its called question driven development, it sounds odd but give me a chance. what you’re going to do is think of a problem and then break it up into small, meaningful questions and then google (dont ask chatgpt) the answers to these questions to help you solve the overall problem. if you’re confused dont worry let’s do an example.

you google ‘beginner programming problems javascript’ and tons of lists of projects and problems come up, to start off with try to keep the number of unique lines of code written to about 100 or so. now after scrolling through websites and problems i find one called ‘palindrome checker’ for example, so now i’ll break this problem into smaller questions that will help me solve this problem.

if you’re very new your questions could be ‘how do i run javascript on my laptop’ or ‘which is the best ide for javascript’, but once you’ve done this a few times, and i recommend doing it with at least 50 different problems if you’re serious about learning, then you could start asking questions like ‘how do i read in a string in javascript’ and ‘how do i store a string in an array in javascript’, these questions are small parts of the full problem that will eventually lead you to an working solution for the ‘palindrome checker’ problem.

something very important that i strongly believe is at the start of learning anything new chatgpt is not your friend, a large amount of the learning process occurs when you’re brain has to piece bits of information together to make it make sense to you since stackoverflow answers are not directly related to your problem.

the problem with chatgpt is it does all the hard work for you of simplifying information down to easy to understand, digestible parts. this is bad. its fine when you’ve forgotten how to do something but not when you’re trying to learn it and engrain it into your mind. this deserves a whole new blog in itself.

now that you’ve solved 50 small problems, its time to move onto the big leagues… i want you to go find 3-4 already existing websites that you think are cool and clone them. yes you heard that correctly, the nice thing about cloning already existing websites is that it leaves very little room for procrastination. no need to think of a good idea or design the UI from scratch. lets do another example.

say i decide i want to clone the youtube homepage, what i’ll start doing is coming up with a plan and making use of question driven developer aka QDD again. i’m sure we are all familiar with youtube’s UI. i’ll start breaking it down into small parts.

so for starters there is the search bar, using QDD i’ll ask questions like ‘how do i create a search bar using html & css’ and then ‘how do i make a search bar functional using javascript’ etc. and then ill continue to do this for each part of the homepage until i’ve got a solid plan, then ill just get to work. googling, implementing, fixing bugs, googling more, implementing more, and googling even more. no chatgpt.

once you’ve done this a couple times and i officially release you from your tutorial hell rehab, you can start building some more original projects from scratch.

but lets face it you are always going to need tutorials so the best way is to build a healthy relationship with them instead of becoming dependent on them.

generally what i like to do is make sure i’m always learning and then building right after, lets say im watching a video on how to build a navbar with react, right afterwards ill go build 3 very average navbars just to solidify it in my mind.

learn and then build. simple. if you learnt something subscribe!

Subscribe now

firstly, just some of my credentials, im currently a software engineer at amazon web services, my team is responsible for this: https://health.aws.amazon.com/health/status and i interned at amazon last year where i worked on the algorithms behind amazon’s insane customer support experience, routing cases to the correct agent’s etc.

so since i said we are starting from scratch that is exactly where im going to start. i’m going to do this from my POV but obviously apply this to your own life.

since i’ve currently got absolutely nothing on my CV there are 2 places i’m going to start. firstly i’m going to start working on projects, and yes in 2026 i understand AI has increased the expectations of what a side project looks like but what i’ve found really impresses employers is having a project that is 1) deployed - meaning it’s live on a domain & people can access it. even if absolutely nobody ever accesses it that does not matter. what matters is that for some reason when an employer can actually go to your site and use what you built it tends to get them all excited. 2) if i can manage to get a couple of people using it then that’s just extra points.

so by now i’ve worked on a couple projects, i’ve built a custom version of chess which im going to call obstacle chess where you are allowed to place bombs, walls and trap doors throughout the match, this has been deployed and can be accessed. i’ve used my creativity to show that i’m not just re-creating what can easily be found on google but adding my own spin to it.

now what i’m going to do is start looking for tangential jobs that don’t require software engineering experience, i’ve decided to start tutoring maths & computer science to people in the year below me in university, initially i’ll offer to do it for free but then eventually i’ll start charging. this will look great on my CV.

something else i’m going to start doing is contacting every single person i know and asking them if they’d like me to re-do their website for free, i’m going to ask my uncle since he owns a construction business and his website could use some work, but i could genuinely ask anybody. great, I can now add “Junior Web Developer - Scribante Construction” to my CV, wow!

now that i’ve got a basic CV together, i’ve got 2 different work experiences listed, ive got a couple projects, i’ve got the degree im currently studying and all the technologies & languages i know this is when i’ll start personally contacting small companies in my area, make sure you stay very local for now, asking if they’re consider hiring you to help with their IT, bonus points if there’s an software company near you. try to find the email’s of the higher up’s and send them an email directly with a short message and attach your CV.

realistically nobody’s first internship is that enjoyable, i know mine wasn’t, but its a stepping stone to getting into the big leagues.

once i’ve worked at around 2-3 local business during the holidays, potentially doing pretty lame, probably useless, but very valuable for my CV work this is when you have a good enough CV for it to stop being the bottle neck.

if you can check everything off this check list i’d say you’re good to start applying to proper software engineering internship roles.

• 2-3 tangential roles related to software engineering at local/no-name companies

• 3-4 projects that are deployed (or were at a point)

now the next step would be to start applying for roles and getting interviews.

genuinely i am going to just start applying everywhere, looking through linkedin, going to the career fair and socialising with recruiters, straight up just googling or asking chatgpt to find you roles to apply for. dont feel scared to apply for roles you think you aren’t cut out for, let them reject you instead of you rejecting yourself.

patience is definitely key here but throughout this process of applying for roles i’d be preparing for the interview when i eventually get one.

what that looks like for me is first following this blog post to the tee:

https://interviewguide.dev/

not even going to lie and say i can explain how to interview better than the guide above can, go give it a read after this, it helped me so much. so much value in one blog post.

another great resource for getting cracked at leetcode is

https://neetcode.io/

i paid for the pro-subscription and i was on the fence initially but that investment has produced 100x returns since it helped me eventually secure a full-time role at amazon.

once you’ve smashed the interview and secured the role you’ve basically got your foot in the door.

building up your CV and experience is a long process but one that will pay you back 100s of times over in the future. you are front-loading the effort now in order to reap the benefits later in life.

i hope this guide was semi-helpful and a break from the generic bullshit you normally see online from people trying to explain how to get your first internship. i am not gate-keeping any information. i want you to succeed as bad as i want myself to succeed