DEV Community: Tala Amm

Host Your JSON File in 2 minutes FOR FREE

Tala Amm — Fri, 05 Jun 2026 20:18:00 +0000

Many people ask: What is the best solution to host a simple JSON file and fetch it? Recently, I needed a place to host a JSON file without setting up a server, database, or paying for storage.

Turns out, if you have a GitHub account, you can use GitHub Gists.

1. Create a new Gist

Go to GitHub and from the dropdown choose Gists.

Click on Create a Gist.

Give your file a name such as data.json, file description is optional.

2. Paste your data or upload it as a file from the button below.

3. Save and Publish Gist

Before clicking on Create Gist, you can choose whether it's a Secret Gist or a Public Gist.

For JSON data hosting, choosing Secret Gist is better

But here is a Quick Comparison:

Feature	Public Gists	Secret Gists
Searchable?	Yes, via search engines and GitHub (show up in "Discover" feed).	No, completely unlisted.
Visible on Profile?	Yes, visible to anyone visiting your profile.	No, only visible to you when logged in.
Appears in Discover Feed?	Yes, listed on the global feed.	No.
Accessible via URL?	Yes, anyone with the link can view it.	Yes, anyone with the link can view it.
Best Used for	Sharing useful code snippets, templates, or instructions with the developer community.	Keeping personal work notes, saving scratchpad code, or sharing snippets with a limited audience.

⚠️ Crucial Security Warning
Secret gists are not secure vaults. If someone guesses, intercepts, or stumbles upon the URL of your secret gist, they can read all of its contents. Never store API keys, passwords, or confidential database credentials inside a secret gist. In fact, GitHub actively applies automated secret scanning to secret gists to catch leaked credentials.

GitHub will now host that file for you and keep a version history whenever you update it.

4. Get the Raw Link

Now the most important part.

Open your file and click Raw.

GitHub will redirect you to a URL that looks something like:

https://gist.githubusercontent.com/username/gist-id/raw/8c6f8d7f2d1a4f4f7f9f/data.json

Notice that random-looking section after /raw/?

8c6f8d7f2d1a4f4f7f9f

That's tied to a specific time version of your gist.

If you use that URL and later update your JSON, your application may keep fetching the old version.

Instead, remove the revision hash and keep only:

https://gist.githubusercontent.com/username/gist-id/raw/data.json

Now every request will fetch the latest version of your file.

That's it!

Why I liked this:

Free hosting
Version history
No Backend
No Database
Easy to update
Public access through a URL

This works great for small datasets, configs, portfolios, mock APIs, and personal projects. If your JSON starts reaching tens of megabytes, you should probably consider a real storage solution rather than a Gist.

Sometimes the simplest backend is no backend at all 😄!

I Thought More Threads ALWAYS Improve Performance, My Assumption Was Wrong!

Tala Amm — Fri, 05 Jun 2026 13:14:23 +0000

I Thought More Threads Would Make Matrix Multiplication Faster. My Benchmarks Said Otherwise.

When I started implementing multithreaded matrix multiplication, I thought I already knew how the results would look.

More threads should mean better performance.

Right?

After all, if one thread performs the work in one second, then two threads should finish in roughly half a second, four threads should be even faster, and sixteen threads should be significantly better.

That intuition sounds reasonable.

My benchmarks told a different story.

In this article, I'll walk through the experiment, the implementations, the benchmark results, and the surprising lessons I learned about parallel programming, cache locality, and performance engineering.

The Goal

The objective was simple:

Implement matrix multiplication in C using POSIX threads and compare different workload distribution strategies.

I implemented four versions:

Sequential baseline
Row-wise parallel multiplication
Column-wise parallel multiplication
Block-based (tiled) parallel multiplication

Then I benchmarked them using several matrix sizes and thread counts.

The goal was not only to measure execution time, but to understand why certain approaches performed better than others.

Why Matrix Multiplication?

Matrix multiplication is one of the most common operations in:

Machine learning
Scientific computing
Computer graphics
Numerical simulation
High-performance computing

The classic algorithm performs a huge number of arithmetic operations.

For an N×N matrix:

The time complexity is: O(N³)

This makes it an excellent candidate for parallelization.

There is a lot of work to distribute among threads.

Or at least that's what I thought.

The Baseline

Before introducing threads, I implemented a traditional single-threaded matrix multiplication algorithm.

The baseline served two purposes:

Correctness reference
Performance comparison point

Every parallel implementation was verified against the baseline output.

This turned out to be more important than expected because one of my parallel implementations initially produced incorrect results despite appearing to run faster.

Performance is meaningless if the answers are wrong.

Strategy 1: Row-Wise Parallelization

The first parallel approach divided the output matrix rows among threads.

For example:

Thread 1 computes rows 0–249

Thread 2 computes rows 250–499

And so on.

This strategy has a nice property:

Each thread writes to a completely separate region of memory.

No locks. No mutexes.

No synchronization overhead.

It is conceptually simple and relatively cache-friendly.

I expected this implementation to perform well.

And it did.

Strategy 2: Column-Wise Parallelization

The second approach divided columns among threads.

At first glance, it seemed almost identical to row-wise decomposition.

The amount of mathematical work was nearly the same.

The number of threads was the same.

The matrix dimensions were the same.

So I expected similar performance.

I was wrong. Very wrong.

The column-wise implementation became one of the most interesting results in the entire project.

Strategy 3: Block-Based Parallelization

The final approach used tiled matrix multiplication.

Instead of processing entire rows or columns, matrices were divided into smaller blocks.

Each thread worked on groups of tiles.

The idea was to improve cache utilization.

Modern CPUs are incredibly fast at arithmetic.

What often slows programs down is moving data between memory and the processor.

By keeping smaller regions of matrices inside cache longer, block-based multiplication attempts to reduce expensive memory accesses.

This turned out to be the winning strategy.

Benchmark Setup

Hardware:

AMD Athlon Silver 7120U
2 CPU cores / 4 Logical Processors
WSL Ubuntu
GCC with -O2 optimization

Matrix sizes:

100×100
500×500
1000×1000

Thread counts:

Each experiment was repeated multiple times and average execution times were recorded. You can find them here

How Matrix Size Changed Everything

The thread-count experiments were only part of the story.

I also wanted to understand how each implementation behaved as the problem size increased.

To do this, I benchmarked three matrix dimensions:

100×100
500×500
1000×1000

The resulting execution-time graph for each 16 threads strategy, revealed a pattern that is common in high-performance computing but easy to overlook.

For small matrices, there was relatively little difference between implementations.

In some cases, the sequential baseline was actually faster than the multithreaded versions.

This might seem surprising at first.

After all, multiple threads should mean more computational power.

The explanation lies in overhead.

Creating threads, scheduling them, and coordinating their work introduces additional cost.

For small workloads, these costs represent a significant fraction of the total execution time.

The computational problem simply isn't large enough to benefit from parallelism.

As matrix size increased, however, the situation changed dramatically.

The amount of arithmetic work in matrix multiplication grows approximately with O(N³).

This means that increasing matrix dimensions has a much larger effect on runtime than many developers initially expect.

A 1000×1000 multiplication is not merely ten times larger than a 100×100 multiplication.

It requires roughly one thousand times more arithmetic operations.

As the workload increased, the overhead of thread management became relatively less important.

The actual computation began to dominate execution time.

This is where the advantages of parallel execution became visible.

The row-wise and block-based implementations began outperforming the sequential baseline by increasingly larger margins.

The block-based implementation showed the strongest scalability.

Its execution time increased more slowly than the other approaches as matrix size grew.

This suggests that its cache-friendly design becomes more valuable as the amount of data increases.

Interestingly, the column-wise implementation did not scale as effectively.

As matrix dimensions increased, its inefficient memory access patterns generated more cache misses and reduced overall performance.

The graph highlights an important principle of performance engineering:

Optimization strategies that appear insignificant on small datasets often become critical on large datasets.

This is why benchmarking only small inputs can be misleading.

A program that appears efficient for a 100×100 matrix may behave very differently when processing matrices that are ten or one hundred times larger.

The matrix-size experiments demonstrated that scalability is not only about adding threads.

It is also about ensuring that memory access patterns remain efficient as the workload grows.

In this project, the block-based implementation achieved the best balance between parallelism and memory efficiency, allowing it to scale more effectively than the other approaches.

The First Surprise: More Threads Didn't Always Help

One of the assumptions I made, as a beginner, about parallel programming is:

"More threads equals more speed."

The benchmark results immediately challenged that assumption.

For smaller matrices, multithreading often performed worse than the sequential implementation.

Why?

Because threads are not free.

Creating threads costs time.

Scheduling threads costs time.

Context switching costs time.

Managing threads introduces overhead.

When the workload is small, those costs can exceed the benefit of parallel execution.

The computation simply isn't large enough to justify the extra complexity.

The Second Surprise: Row-Wise and Column-Wise Were Not Equal

This was the most interesting result of the project.

Row-wise decomposition consistently outperformed column-wise decomposition.

At first this seemed strange.

Both implementations perform essentially the same arithmetic operations.

So why the difference?

The answer lies in memory layout.

Matrices were stored in row-major order.

That means:

A[0][0]
A[0][1]
A[0][2]
A[0][3]

which are adjacent in memory.

Rows are contiguous.

Columns are not.

When the row-wise implementation accessed matrix elements, it often read memory sequentially.

Processors love sequential memory access.

Caches become highly effective.

The column-wise implementation frequently jumped around memory. In physical RAM addresses, it would look like:

0x02, 0x06, 0x0A, 0x0E, ...

Because of the row-major layout, column elements are physically separated by a "stride" (the width of the row).

Those jumps cause more cache misses, and stalls.

Because the data brought into the cache is thrown away unused.

More cache misses meant more trips to slower memory RAM to fetch the next value.

The arithmetic was the same.

The memory behavior was not.

And memory behavior won.

The Third Surprise: Cache Locality Was More Important Than Thread Count

The best-performing implementation was not simply the one with the most threads.

It was the one with the best cache behavior.

The block-based algorithm consistently produced the strongest results.

The reason wasn't additional parallelism.

It was improved cache reuse.

The same arithmetic operations were being performed.

But the processor spent less time waiting for memory.

This was one of the most valuable lessons from the project.

Performance engineering is often about moving data efficiently rather than performing calculations faster.

Understanding Speedup

To evaluate parallel performance, I measured speedup.

Speedup is defined as:

Speedup = Sequential Time / Parallel Time

A speedup of:

1.0 means no improvement
2.0 means twice as fast
4.0 means four times as fast

The block-based implementation achieved the highest speedup.

However, another interesting pattern emerged.

The speedup did not scale linearly with thread count.

Doubling the number of threads did not double the performance.

This is a classic result in parallel computing.

Understanding Efficiency

After computing speedup, I calculated efficiency.

Efficiency = Speedup / Threads

This metric measures how effectively each thread contributes useful work.

One surprising observation was:

Execution time improved while efficiency decreased.

At first this seems contradictory. But it isn't.

The program was getting faster.

But each additional thread contributed less benefit than the previous one.

This phenomenon is called diminishing returns.

It appears in almost every parallel system.

Why Efficiency Drops

As more threads are added:

Scheduling overhead increases
Context switching increases
Cache contention increases
Memory bandwidth becomes shared

Eventually the overhead begins to dominate.

The program may still become faster.

Just not proportionally faster.

This explains why efficiency graphs often trend downward even when performance continues to improve.

Hardware Matters

One important limitation of my experiment was hardware.

The machine only had a small number of CPU cores.

Despite testing 8 and 16 threads, the processor could not execute all of them simultaneously.

The operating system had to continuously schedule and reschedule threads.

This limited scalability.

The results illustrate a fundamental principle:

Software parallelism cannot completely overcome hardware limitations, we still need some hardware support.

At some point, the hardware becomes the bottleneck.

Lessons Learned

This project taught me several lessons that I fully appreciate after running real benchmarks.

More threads do not guarantee better performance.
Memory access patterns matter enormously.
Cache locality can outweigh algorithmic differences.
Benchmarking often disproves intuition.
Correctness verification is essential.
Performance engineering is as much about memory as computation.
Smaller benchmarks create "Performance Illusions".
Parallelism introduces a "thread tax" (creation, context switching, and synchronization overhead).

Perhaps the biggest lesson was that performance optimization should be driven by measurements, not assumptions.

Several results contradicted my expectations.

Without benchmarks, I would have drawn the wrong conclusions.

Final Thoughts

Before this project, I viewed multithreading primarily as a way to divide work.

After this project, I see it differently.

The number of threads is only one piece of the puzzle.

Memory layout, cache behavior, workload distribution, and hardware characteristics can have a greater impact on performance than simply adding more workers.

The block-based implementation won not because it created more threads, but because it used memory more intelligently.

That was the most valuable takeaway from the entire experiment.

Sometimes the fastest code isn't the code doing the least work.

It's the code waiting the least for memory.

Small Go Detail That Changes How Your Project Looks

Tala Amm — Sat, 30 May 2026 20:39:54 +0000

Today I learned something simple, but it changes how “professional” your Go project feels.

It’s about this line:

go mod init github.com/yourname/module-name

go mod init module-name

At first, it feels like just naming.

But in Go, this is actually your project identity.

💡 What this really means

When you use:

github.com/yourname/project

you are not just naming a folder.

You are defining a real package in the Go ecosystem.

It makes imports globally unique, prepares the project for versioning, simplifies dependency management, and allows other developers to consume it as a package without restructuring later.

The code doesn't change with the module name, but the engineering mindset does.

Why this matters

1. It matches real Go projects

Most real-world Go projects look like this:

Kubernetes → github.com/kubernetes/kubernetes
Docker → github.com/docker/docker

So your project instantly feels “industry-level structured”.

2. Your code becomes importable

Someone can literally do:

import "github.com/your_name/module_name/pkg"

Which means your project is no longer “local code”.

It behaves like a reusable library.

3. It prevents messy imports later

Without a proper module path:

imports become fragile
moving folders breaks stuff
Go cannot resolve dependencies cleanly

With it:

everything is globally unique
structure stays stable
refactoring becomes safer

4. It unlocks Go modules properly

Tools like:

go mod tidy

work smoothly because Go knows exactly where your module lives.

The module path is basically the “root identity” of your dependency graph.

5. It signals seriousness in your project

This is subtle but important.

Compare:

module module_name

module github.com/your_name/module_name

One looks like a practice project.

The other looks like something that belongs in a repo people can actually use.

The mindset shift 🧠

This is the part that stood out to me:

You’re not just writing code for your machine anymore.

You’re structuring it like:

a system that someone else could clone, understand, and run

That’s a different level of thinking.

🔥 Bottom line

This small line:

go mod init github.com/yourname/project

doesn’t change how your code runs.

But it changes how your project is perceived, structured, and scaled.

If I had to summarize it:

local naming → personal experiment
GitHub module path → real software project

Something I learned is that professionalism in software isn't always about complex algorithms.

Sometimes it's about making small decisions today that prevent friction when a project grows tomorrow ;)

10 Skills That Every Junior Developer MUST Have in 2026

Tala Amm — Sun, 15 Mar 2026 20:27:20 +0000

Most developers spend years learning frameworks but never learn how real systems work.

I reviewed a lot of junior developer portfolios, and I keep seeing the same pattern.

Every year juniors are told the same advice:

“Learn frameworks.”
“Build more projects.”

But the reality in 2026 is different. With the insane AI tools we have, companies don’t just hire juniors to write features anymore. Writing code alone is no longer enough...

They hire juniors to:

Deploy apps
Debug production issues
Automate tasks
Connect systems together

So here are the skills that actually make juniors valuable today. 😊

1. Debugging & Code Fixing

This is probably the most underrated skill.

Many developers can write code.

Few can debug broken systems.

The developer who fixes production issues quickly is often more valuable than the one who wrote the feature.

Especially with AI and “vibe coding” becoming common, this skill is now more valuable than ever.

Being able to:

Read logs
Trace errors
Inspect APIs
Find performance issues

Makes you extremely valuable as a junior.

In many teams, juniors spend more time fixing bugs than writing features.

2. Backend API Development

Every modern product is API-driven.

Juniors should understand how APIs work and how to build them for things like:

Authentication
Validation
Pagination
Error handling

Good API design is a huge advantage.

3. SQL & Databases

Many developers treat databases like a black box.

But understanding databases helps you:

Design good schemas
Optimize queries
Debug backend problems

Basic skills should include:

Joins
Indexing
Query optimization

4. Cloud & DevOps Basics

You don’t need to be a DevOps engineer.

But every developer should know how to ship software.

Basic knowledge should include tools like:

Docker
CI/CD pipelines
GitHub Actions
Cloud basics (AWS / GCP)

Many companies actually hire juniors to:

Deploy applications
Fix pipelines
Configure servers

5. Real-Time Systems

Modern apps are increasingly real-time.

Examples include:

Chat systems
Notifications
Collaborative tools

Understanding technologies like:

WebSockets
Event systems
Message queues

is a huge plus.

6. Automation & Scripting

One of the most in-demand skills today. Developers who automate tasks save companies huge amounts of time.

Common tools include:

Python scripts
CLI tools
Automation pipelines

You can automate things like:

Report generation
Data processing
Internal tools

7. AI API Integration

AI is now part of many products. But you don’t need to train models.

Most real products just integrate APIs.

Examples:

Chatbots
Summarization tools
AI assistants
Automation with AI

Knowing how to integrate these APIs is a valuable skill.

8. Understanding System Architecture

Great developers understand how systems connect together.

Not just writing backend code, but understanding the full flow of an application.

For example:

Frontend
↓
API
↓
Queue
↓
Worker
↓
Database
↓
Deployment

Developers who understand this flow can debug and build systems much faster.

9. Web Scraping & Data Automation

Many companies need automated data collection.

Developers are often hired to build tools that:

Monitor competitors
Collect market data
Track product information

Common tools include:

Python
Puppeteer
Playwright

Many startups rely heavily on scraped data.

10. Building Small SaaS Tools

One of the best ways to grow as a developer is building small software as a service (SaaS) tools.

Examples:

Dashboards
Automation tools
Niche productivity apps

Some developers even turn these tools into small SaaS products that generate side income.

Summary

If you're a junior developer in 2026, focus on learning:

Debugging real systems
Backend API development
SQL & databases
Cloud & DevOps basics
Real-time systems
Automation & scripting
AI API integration
System architecture
Web scraping & data automation
Building small SaaS tools

Note: I'm still early in my career myself, but after many conversations with senior engineers, CTOs, and founders, the same themes keep appearing.

Final Advice

Don't just learn frameworks. Learn how systems actually work.

Developers who understand systems will always be more valuable than developers who only know frameworks.

For Junior developers:

What skills are you currently working on this year?

For Senior engineers:

What skills do you wish you had focused on when you were a junior?

How I Built a Résumé that Passed High-Tech Companies (Google, Amazon, and Microsoft)!

Tala Amm — Fri, 06 Feb 2026 21:42:22 +0000

I’m writing this post after a long break, and honestly, I feel like this story deserved to be written.

I’m still a student. A computer engineering student.
I took an intensive full-stack development course that exposed me to a wide range of software engineering topics, but at the end of the day… I was still just a student with no previous job experience.

So when I say that my very first job application ever was for a
Part-Time Student Software Engineering Internship @ Google. Yes, I know. Bold. Maybe delusional. Definitely scary.

Was I excited? Absolutely.
Was I motivated? …not really.

I genuinely thought: “Nah. Will **GOOGLE* really look at Tala’s CV? Probably not.”*

But I shot my shot anyway.

And guess what?

They replied.

After a whole month, I got an email.
An actual reply.
An invitation to do an Online Assessment.

I was shocked. Like, sit-up-straight-and-re-read-the-email shocked.

(I’ll talk about the OA and interview experience in detail in another post 👀)

I did the assessment… and honestly?
I walked away feeling like I messed everything up. I completely deleted the idea of moving forward from my head.

But then. GUESS WHAT AGAIN???

They moved me to the interview stage.

Two technical interviews.

In the end, I wasn’t selected.
And yes, that was disappointing.

But I truly believe the reason wasn’t my technical skills, it was that my CV, portfolio, LinkedIn, and overall profile lacked extracurricular activities.

The recruiter literally encouraged me to:

“Get out of the classroom. Join hackathons. Be more active in the CS community.”

And that’s exactly what I’m doing now.

What did I learn from this?

1️⃣ Never underestimate yourself

Six months ago, if someone told me:

“You’ll get Google interviews before you even graduate”

I would’ve laughed.

Even though it didn’t work out, I walked away with something priceless:
self-confidence.

My first ever application was to Google, and I reached the last possible stage for a student internship. That alone changed how I see myself.

2️⃣ This was NOT a failure, it was a huge level-up

I always thought I wasn’t good at data structures and algorithms.

Now?

I can discuss and solve most problems put in front of me
I can analyze time & space complexity
I can think about optimizations
And most importantly... I can explain my thought process clearly

Compared to two months ago?
This is a completely different version of me.

So no, this wasn’t a rejection.
This was growth.

3️⃣ I got free feedback (lol)

I now know:

Where my weak points are in DSA
How technical interviews actually work
That I broke my fear barrier from interviews
That I lack extracurricular activities, and I’m actively fixing that

A review of myself and my résumé, for free?
I’ll take it.

So… how did I build my résumé?

Back to the main topic.

As a student who had never written a résumé before, I was lucky enough to have a Senior Software Engineering mentor.

I asked them for help, and they shared their own résumé as a template.
I didn’t reinvent the wheel, I followed the structure, adapted it to my experience, and built my first real résumé from there.

Was it perfect? No.
Was it a starting point? Absolutely.

We reviewed it together, refined it, and moved on.

Applying to Google: what I did differently

Before applying, I carefully read Google’s official résumé tips
👉 https://www.google.com/about/careers/applications/how-we-hire/

I especially used their XYZ formula to describe my projects:

““Accomplished [X] as measured by [Y], by doing [Z].””

Then I:

Read the job description at least 10 times
Highlighted what they were looking for in a candidate's resume, like:
- Relevant practical experience with: web application development, Unix/Linux,...
- Interest and ability to learn other coding languages as needed.
- Please include your expected graduation date (month and year) on your resume.

And I tailored my résumé specifically for that role.

Important details:

No images
No icons
One page only
Plain, selectable text (ATS-friendly)

How I used AI (the right way)

Once I had a solid draft, I used AI as a tool, not a writer‼️.

This was the idea of the prompt I used (you can improve it):

I’m applying for a Part-Time Software Engineering BS/MS Intern, 2026 at Google.
Here is the job description: [paste it].
Here is my résumé: [paste text or upload PDF].
Please analyze the job posting carefully and suggest edits to better align my résumé with the role, without adding false experience.

I iterated. Refined. Tailored. Rewrote.

But every word was mine.
No lies. No exaggerations.
AI helped me polish, not fabricate.

Final thoughts

My résumé wasn’t magic.
It wasn’t perfect.
But it was:

Honest
Focused
Tailored
Clear
And written with intention

And it got me further than I ever imagined.

After the Google rejection, I didn’t stop. I applied to student internship roles at Amazon and Microsoft, using the same résumé structure, the same tailoring process, and the same mindset.

And yes!! I did get moved forward in both processes.

That’s when it clicked for me: this wasn’t luck. The résumé was doing its job. And more importantly, I was definitely presenting myself properly.

If you’re a student doubting whether you’re “ready”, trust me:

You don’t need to feel ready.
You just need to start.

If you have more tips, mention them in the comments!

Thanks for reading 📖💞

My Linux Journey: From Intensive Bootcamp to BZU’s Linux Lab 🐧

Tala Amm — Sun, 05 Oct 2025 11:06:24 +0000

This semester, I’m taking the Linux Laboratory course at Birzeit University, and I’m genuinely excited about it!

The last month, during my Full Stack Development program at Notre Dame University, we spent two intensive weeks diving deep into Linux commands, shell scripting, and Python programming; the same topics we’ll be covering throughout this 4-month course at Birzeit University.

Those two weeks were intense but valuable. I learned how to navigate the Linux environment efficiently, automate repetitive tasks with shell scripts, and integrate Python into practical workflows.

During that period, I created a personal Linux command cheat sheet to help me quickly recall the most useful and commonly used commands. Since the Linux Lab at BZU covers similar material, I thought it might be helpful to share it with others who are starting their Linux journey too!

🗒️ Here’s my Linux Command Cheat Sheet:
Scripting Piscine pdf

I hope it helps other students and Linux enthusiasts make their learning process smoother and more enjoyable!

Big O Notation: Examples

Tala Amm — Sun, 21 Sep 2025 20:44:49 +0000

Hi again!

Below are clear, beginner-friendly step-by-step examples for how to calculate common Big-O classes, using Go code snippets.

O(n) - Linear time

Example: linear search (find a value in an array).

// Linear search: O(n)
func linearSearch(nums []int, target int) int {
    for i:= 0 ; i < len(nums) ; i++ {     // runs up to n times
        if nums[i] == target {         // constant-time comparison each iteration
            return i
        }
    }
    return -1
}

Step-by-step reasoning

n is the size of input which is length of nums.
In the worst case (target not present or last element), the for loop executes n iterations.
Each iteration (inside the loop) does O(1) work (compare and maybe assign).
O notation is O(1*n) = O(n)

O(log n) - Logarithmic time

Example: binary search in a sorted slice.

// Binary search: O(log n)
func binarySearch(nums []int, target int) int {
    lo, hi := 0, len(nums)-1
    for lo <= hi {
        mid := lo + (hi-lo)/2          // cut range in half
        if nums[mid] == target {
            return mid
        } else if nums[mid] < target {
            lo = mid + 1
        } else {
            hi = mid - 1
        }
    }
    return -1
}

Step-by-step reasoning

Each loop iteration halves the search range.
After k iterations the remaining range size is about n / 2^k.
It stops when n / 2^k ≤ 1 → 2^k ≥ n → k ≥ log₂(n).
So number of iterations ~ ⌈log₂ n⌉ → O(log n).
Note: base of the logarithm doesn't matter for Big-O (log₂, log₁₀, ln are all Θ(log n)).

O(n log n) - Typical of efficient sorts

Example: merge sort (divide & conquer).

// Merge sort: O(n log n)
func mergeSort(a []int) []int {
    if len(a) <= 1 {
        return a
    }
    mid := len(a) / 2
    left := mergeSort(a[:mid])
    right := mergeSort(a[mid:])
    return merge(left, right)
}

func merge(left, right []int) []int {
    res := make([]int, 0, len(left)+len(right))
    i, j := 0, 0
    for i < len(left) && j < len(right) {
        if left[i] <= right[j] {
            res = append(res, left[i])
            i++
        } else {
            res = append(res, right[j])
            j++
        }
    }
    // append remaining
    res = append(res, left[i:]...)
    res = append(res, right[j:]...)
    return res
}

Step-by-step reasoning

Recurrence: T(n) = 2·T(n/2) + O(n) (because we sort two halves then merge in O(n)).
Using Master Theorem or level-by-level cost:
- Level 0 (root): cost O(n) to merge at that level,
- Level 1: two merges of size n/2 → total O(n),
- Level 2: four merges of size n/4 → total O(n),
- ... there are about log₂(n) levels.
Total ≈ n * (log₂(n) + 1) → O(n log n).

O(n²) - Quadratic time

Example: printing every pair (nested loops), or naive pairwise compare.

// Print every ordered pair: O(n^2)
func printPairs(nums []int) {
    n := len(nums)
    for i := 0; i < n; i++ {
        for j := 0; j < n; j++ {
            // constant-time work inside
            _ = nums[i] + nums[j]  // pretend we do O(1) work
        }
    }
}

Step-by-step reasoning

Outer loop runs n times.
For every outer iteration, inner loop runs n times.
Total iterations = n * n = n².
Drop constants and lower-order terms → O(n²).

O(2ⁿ) - Exponential time (base 2)

Example: generate all subsets (power set). Each element either included or excluded → 2 choices per element.

// Generate all subsets: O(2^n)
func subsets(nums []int) [][]int {
    res := [][]int{}
    var helper func(int, []int)
    helper = func(i int, cur []int) {
        if i == len(nums) {
            tmp := append([]int(nil), cur...)
            res = append(res, tmp)
            return
        }
        // exclude current
        helper(i+1, cur)
        // include current
        helper(i+1, append(cur, nums[i]))
    }
    helper(0, []int{})
    return res
}

Step-by-step reasoning

At each index i you branch into two calls (include / exclude).
Tree depth = n, branching factor = 2 → number of leaves = 2ⁿ.
You do at least one constant amount of work per leaf (plus cost to build each subset).
Total work ≈ c · 2ⁿ → O(2ⁿ).
Note: Some recursive exponential algorithms (like naive Fibonacci) produce growth ~φⁿ where φ ≈ 1.618; often people use O(2ⁿ) to describe general exponential growth class.

O(n!) - Factorial time

Example: generate all permutations of n distinct elements.

// Generate all permutations: O(n!)
func permutations(nums []int) [][]int {
    a := make([]int, len(nums))
    copy(a, nums)
    res := [][]int{}
    var helper func(int)
    helper = func(k int) {
        if k == len(a)-1 {
            tmp := append([]int(nil), a...)
            res = append(res, tmp)
            return
        }
        for i := k; i < len(a); i++ {
            a[k], a[i] = a[i], a[k] // swap
            helper(k + 1)
            a[k], a[i] = a[i], a[k] // swap back
        }
    }
    helper(0)
    return res
}

Step-by-step reasoning

Number of permutations of n distinct items is n! = n × (n−1) × (n−2) × ... × 1.
The recursion produces all n! permutations.
If you also consider the cost to copy/print each permutation (of length n) then total time is O(n · n!) because for each of the n! permutations we may spend O(n) to copy or output it.
But the combinatorial explosion is already n!, so algorithms with factorial behavior are impractical even for small n (n = 10 → 3,628,800 permutations).

O(1) - Constant Time

Example: Get the first element of a slice

// O(1) - accessing the first element
func getFirst(nums []int) int {
    if len(nums) == 0 {
        return -1
    }
    return nums[0] // single operation
}

Step-by-step reasoning

Let n = len(nums).
The function performs:

One check: len(nums) == 0 → O(1)
One index access: nums[0] → O(1)
One return → O(1)
1. Total operations = 3 (or some small constant c). Does NOT depend on n.
2. Therefore, runtime = O(1) — it stays constant even if nums has 1 element or 1 million elements.

Key takeaway: Constant time algorithms do a fixed number of steps regardless of input size.

Quick rules / takeaways (for beginners)

Drop constants: c·n → O(n). 5n² → O(n²).
Drop lower-order terms: (n² + n)/2 → O(n²).
Log base doesn't matter: log₂ n, log₁₀ n, ln n are all Θ(log n).
Multiplicative rule: nested loops (n × n) → O(n²).
Additive rule: if you do O(n) then O(n²), total is O(n + n²) → O(n²) (keep the dominant term).
Recursive divide & conquer often gives O(n log n) or O(log n) depending on splitting and merging (use Master Theorem or count cost per level).
Output-size matters: generating all combinations/subsets/permutations means runtime grows at least as fast as the number of outputs (2ⁿ, n!, ...).

Big O Notation pt.1: Time Complexity

Tala Amm — Sun, 21 Sep 2025 18:36:43 +0000

Hello again 🙋🏻‍♀️
If you’re starting your programming journey, you’ve probably heard the term Big O notation or Time complexity of an algorithm. You may have also wondered why a solution is better than another, though they both do the same thing! At first, it might look like some scary math formula but don’t worry! In this post, we’ll break it down into simple words and examples so you can understand exactly what it means and why it matters.

This post is part one of a two-part series:

Part 1 (this post): Time Complexity
Part 2 (next post): Space Complexity

📑 Table of Contents

What is Big O Notation?
Why is Big O Notation Important?
How to Find Big O
Properties of Big O
Common Time Complexities
Big O, Big Omega, and Big Theta
Practice Exercises
Resources

What is Big O Notation?

Big O time is the language and metric we use to describe the efficiency of algorithms. Not understanding, not only will leave you judged harshly for not understanding it, but also you will struggle to judge your algorithms and solutions for coding problems.

Why is Big O Notation Important?

Big O notation is important for several reasons:

It provides a way to compare the performance of different algorithms and data structures, and to predict how they will behave as the input size increases.
It helps analyze the efficiency of algorithms.
It provides a way to describe how the runtime or space requirements of an algorithm grow as the input size increases.
Allows programmers to compare different algorithms and choose the most efficient one for a specific problem.
Helps in understanding the scalability of algorithms and predicting how they will perform as the input size grows.
Enables developers to optimize code and improve overall performance.

How to Find Big O

Ignore the lower order terms and consider only highest order term.
Ignore the constant associated with the highest order term.

Properties of Big O

Reflexivity: For any function f(n), f(n) = O(f(n)).
Transitivity: If f(n) = O(g(n)) and g(n) = O(h(n)), then f(n) = O(h(n)).
Constant Factor: For any constant c > 0 and functions f(n) and g(n), if f(n) = O(g(n)), then cf(n) = O(g(n)).
Sum Rule: If f(n) = O(g(n)) and h(n) = O(k(n)), then f(n) + h(n) = O(max( g(n), k(n) ) When combining complexities, only the largest term dominates.
Product Rule: If f(n) = O(g(n)) and h(n) = O(k(n)), then f(n) * h(n) = O(g(n) * k(n)).
Composition Rule: If f(n) = O(g(n)), then f(h(n)) = O(g(h(n))).

Common Time Complexities

Name	Notation	Meaning	Examples
Constant	O(1)	Runtime is constant regardless of input size	Accessing an array element by index, Stack push/ pop, if statement
Logarithmic	O(log n)	After each iteration, input size shrinks	Binary Search
Linear	O(n)	Runtime grows linearly with the size of input	Linear Search
Super Linear	O(n*log n)	Input of size n is processed across log n levels (a shrinking for loop idea)	Quick Sort, Heap Sort, Merge Sort
Polynomial	O(n^k)	ex: O(n^2) Runtime is proportional to the square of the input size	Strassen’s Matrix Multiplication, Bubble Sort, Selection Sort, Insertion Sort, Bucket Sort
Exponential	O(k^n)	ex: O(2^n) Runtime doubles with each addition to the input data set	Tower of Hanoi
Factorial	O(n!)	Runtime grows factorially with the size of the input	Determinant Expansion by Minors, Brute force Search algorithm for Traveling Salesman Problem

Graphs

If we plot the most common Big O notation examples, we would have graph like this:

Mathematical Examples of Runtime Analysis

Below table illustrates the runtime analysis of different orders of algorithms as the input size (n) increases.

O notation	Runtime (ex1)	Runtime (ex2)
n	10	20
log(n)	1	2.996
n * log(n)	10	59.9
n^2	100	400
2^n	1024	1048576
n!	3628800	2.432902e+1818

Big O, Big Omega, and Big Theta

Notation	Explanation
Big O (O)	Describes the upper bound of the algorithm's running time. (It describes the worst case scenario of an input) Most commonly used when analyzing time complexity
Big Ω (Omega)	Describes the lower bound of the algorithm's running time. (*It describes the best case scenario of an input*)
Big θ (Theta)	Describes a tight bound, meaning both the upper and lower bounds are the same order. (*When the best and worst scenarios are the same*) It represents the asymptotically exact growth rate.

Note: Average case is often analyzed separately and doesn’t always equal Θ.

Diagram for Big O, Big Omega, Big Theta

Ω(n) → lower bound curve (algorithm will never be faster than this).
O(n) → upper bound curve (algorithm will never be slower than this).
Θ(n) → sits between them when both bounds match.

Practice Exercises

Check out the following Blog that explain how to calculate time complexity for most common scenarios in details: Big O Notation Examples

Also, I would really recommend checking these exercises to test your knowledge: Big O Notation Exercises - GitHub

Resources

Cracking the Coding Interview Book
Big O Notation Tutorial - A Guide to Big O Analysis - GeeksforGeeks

Thanks for reading!

Happy Coding!💻😀

Will GPT-5 & Future AI Replace Junior Developers? Is Learning to Code Still Worth It?

Tala Amm — Sat, 09 Aug 2025 11:07:18 +0000

“GPT-5 can build a functional website in seconds. Is that the end of the junior developer… or the start of a completely new role?”

1. The Reality: AI as an Augmenter, Not a Replacer (For Now)

Every major AI release sparks the same debate: “Will it take my job?”
With GPT-5 and other apps ability to generate full-stack apps in one click, it’s tempting to think the answer is yes, especially for junior developers.

But the numbers tell a more nuanced story:

GitHub Copilot users reported finishing tasks 56% faster
Google’s internal AI experiments showed a 21% boost in developer productivity
Real-world teams report 30–50% time savings on repetitive tasks like refactoring and documentation

And adoption is exploding:
Nearly half of all developers are already using AI tools, and in some companies, the number is closer to 92%.

2. Where AI Still Struggles

Yes, GPT-5 can code, but it still falls short in:

Business context - AI doesn’t intuitively “get” the purpose behind features
Architecture decisions - It can suggest solutions, but not necessarily the right one for your system
Critical thinking & creativity - It can remix ideas, but human originality still sets projects apart
Reliability - AI may still produce flawed code in complex projects, that might slow teams down instead of speeding them up

In fact, a METR study found that for some senior devs, reviewing and fixing AI code made them 19% slower. Read more here

3. What Industry Leaders Are Saying

Goldman Sachs economists warn that Gen Z tech workers ~especially juniors~ are at the highest risk from AI-driven automation
GitHub’s CEO put it bluntly: “Embrace AI or get out”
Bill Gates and OpenAI’s Bret Taylor agree: AI changes the landscape, but deep programming skills, systems thinking, and human judgment remain irreplaceable

4. The Junior Developer’s Role is Evolving

Instead of writing every line of code from scratch, juniors may soon:

Act as curators of AI-generated code, ensuring it meets quality and business goals
Work more like product thinkers, shaping what AI builds instead of just building it themselves
Learn AI prompt engineering, code review at scale, and system integration

We’re not moving toward fewer skills, just different skills.

5. So… Should You Still Learn to Code in 2025?

Absolutely!! but with a twist.

Takeaway	Why It Matters
Learn core coding skills	You’ll need to understand AI output deeply enough to trust (or reject) it
Focus on system design & architecture	AI can code modules; humans still design the blueprint
Add AI literacy to your toolbox	Prompting, reviewing, and integrating AI into workflows is the new normal
Build soft skills	Collaboration, empathy, and creativity will never be automated

Final Thoughts

Learning to code in the GPT-5 era is not like learning to drive a horse carriage after cars were invented.
It’s more like learning to drive in a world where autopilot exists. You still need to know how to take the wheel when things get tricky. Watch This

The future isn’t AI replacing developers, it’s developers who understand AI replacing those who don’t.

💬 What do you think?
Are junior dev roles truly at risk, or are we just entering a new golden age of human-AI collaboration?

GPT-5 Is Here: What It Really Means for Junior Developers (Like Me)

Tala Amm — Fri, 08 Aug 2025 19:35:42 +0000

Yesterday, on August 7th, 2025, OpenAI released GPT‑5, and I've been exploring it ever since. As a junior developer, I’ve used earlier versions to help me learn, write and debug code better. But GPT‑5 genuinely changes the game.

This post isn’t a generic AI hype piece, I want to walk you through what’s actually new in GPT‑5, what’s improved, and how I (and other early-career developers) can really benefit from it right now.

1. A Smarter Brain with “Thinking Mode”

GPT‑5 introduces a new internal design where it can switch between two reasoning engines:

One for fast, lightweight responses
Another for deep, multi-step reasoning (it uses it when needed or when prompted with something like: “Think hard about this”)

Before GPT‑5, I often had to rephrase my prompts multiple times to get the model to really "think". Now, GPT‑5 does it automatically or on request.

Why it matters: When I’m stuck on a logic bug or trying to understand a concept deeply, I don’t just want an answer; I want reasoning. GPT‑5 gives me both.🫶

2. Improved Code Generation. Especially for Front-End

GPT‑5 isn’t just better at generating code, it’s more aware of structure, layout, and intent. Especially when it comes to front-end code (HTML, CSS, JS, Vue, React), the output is cleaner, more semantically correct, and closer to production-ready.

Before: We’d often get div soup or have to rework the styling logic manually.
Now: It understands component hierarchy, responsive layout, and even accessibility hints.

Why it matters: As someone still learning the ropes of clean UI/UX code, this accelerates my understanding by showing me better examples than ever before.🫶

3. “Vibe Coding” and Canvas Preview

This one blew my mind.

GPT‑5 (paired with OpenAI’s Canvas) lets us describe what we want, like: “a minimal to-do app with dark mode and animations” and it starts building a real UI with live previews. This isn't just generating code... it’s collaborative prototyping.

Why it matters: I learn faster by seeing and tweaking. Watching GPT‑5 create UI flows in real-time is like pair programming with a senior dev who also happens to be a designer and product thinker.🫶🤯

4. Explains Code Like a Mentor Would

GPT‑5 adapts explanations to our current knowledge level. If I say “explain like I’m new to JavaScript closures”, I get a beginner-friendly breakdown. If I ask for “the performance tradeoffs between useMemo and useCallback”, I get a much deeper dive.

Before: GPT sometimes gave generic or overly simplified responses.
Now: It feels like it's actually teaching, not just answering.

Why it matters: No one wants just to copy code. I want to understand it, how and why. GPT‑5 makes that learning curve smoother and more tailored.🫶

5. More Reliable: Fewer Hallucinations, More Honesty

OpenAI claims GPT‑5 hallucinates 45% less than GPT‑4o, and in my current short experience, that's true. It’s also better at admitting when it doesn’t know or when a question needs clarification.

Before: I had to double-check almost everything it generated.
Now: I still review the code (always should), but I trust the logic more.

Why it matters: As a junior dev, I don’t always know what's right or wrong, so having a more reliable assistant reduces time wasted on debugging misleading suggestions.🫶

6. Developer-Personality Presets

GPT‑5 includes four customizable response styles:

Listener – calm, reflective responses
Robot – concise, no-fluff logic
Nerd – super-detailed and technical
Cynic – sarcastic, for fun debugging

I tried the “Nerd” mode today and actually found it helpful! It gave me ultra-detailed answers, just as I wanted, with citations and theory.

Why it matters: Sometimes I need a mentor, other times I need a debugging partner. Now I have both all the time.🫶

7. It’s Everywhere Now — Not Just in ChatGPT

If you use GitHub Copilot, Cursor ,VSCode, Microsoft 365, or even Azure AI Studio, GPT‑5 is integrated or rolling out soon.

Why it matters: I can use GPT‑5 beyond side chats. It becomes part of my IDE, my editor, my docs, and my workflows.🫶

Final Thoughts

As someone still navigating the early stages of my developer journey, GPT‑5 isn’t just a tool. It’s a tutor, pair programmer, documentation companion, and sometimes even a confidence booster.

If you’re a junior dev like me: Don’t just use GPT‑5 to get answers. Use it to understand, ask better questions, and build faster.

We finally have a model that doesn’t just “respond”, it really helps you grow. Use it wisely.

Have you tried GPT‑5 yet? I’d love to hear how you’re using it in your learning or coding workflow.

Let’s keep learning together.

What Is a .env File and Why Should You Use It?

Tala Amm — Fri, 01 Aug 2025 06:01:01 +0000

In modern development, .env files are essential for managing environment-specific configuration. Whether you're building a Node.js backend, a Python app, or a full-stack project, you’ve probably seen a .env file somewhere. But what exactly is it?

What Is a `.env` File?

A .env file (short for environment) is a plain text file where you store environment variables as key-value pairs

These values are not hardcoded into your application, which means:

Your config stays clean
You can change settings without touching your code
Sensitive data stays out of your Git repo

What Should You Store in `.env`?

API keys
Database URLs
Secret tokens (like JWT secrets)
Environment flags (e.g., NODE_ENV=production)
Any config that varies by environment

How to Use `.env` in Your Project🛠️

In Node.js

Create a .env file in the root of your project, save in it your secret variables like a key-value pair:

PORT=3000
DB_HOST=localhost
JWT_SECRET=yourSuperSecretKeyHere

Install the dotenv package, in your terminal run:

npm install dotenv

Load the .env File in Your Code At the top of your main file (like server.js or index.js), add this line:

require('dotenv').config();

Now you can access your environment variables using:

const PORT = process.env.PORT;
const SECRET = process.env.JWT_SECRET;

Wait, What’s `process.env`? 🤔

In Node.js, process.env is a built-in object that gives you access to environment variables.

When you write process.env.JWT_SECRET, you're saying:

"Give me the value of the environment variable named JWT_SECRET."

It's how your app knows which port to use, what database to connect to, or what secret to use for signing tokens, without hardcoding them into your source files.

🚫 Don’t Commit `.env` to Git!

Always add it to your .gitignore:

# .gitignore
.env

Summary

.env files store environment variables
Keep secrets out of your code
Use libraries like dotenv to access them
Never commit .env to version control

Generate a Random String for a JWT Secret

Tala Amm — Thu, 31 Jul 2025 05:55:51 +0000

How to Generate a Random String for a JWT Secret (Safely!)

When working with JWT (JSON Web Tokens) in your authentication system, one of the most important things is your JWT secret key. This is the string used to sign and verify the token, like a password for your server to trust the token.

So, how do you generate a good, secure one?

🧠 What Makes a Good JWT Secret?

Long (at least 32+ characters)
Random (not guessable, not a real word)
Includes letters, numbers, and symbols
Stored securely (like in .env files)

🔧 Generate One Using Code

Bash terminal (Most Recommended)

openssl rand -hex 64

Node.js (JavaScript)

// Generate a 64-character random string
const crypto = require('crypto');
console.log(crypto.randomBytes(64).toString('hex'));

Python

import secrets
print(secrets.token_hex(64))

🛡️ Where Do You Store It?

In a .env file:

JWT_SECRET=9f7a41a6e23... (your generated key)

And in your code (JavaScript):

const jwtSecret = process.env.JWT_SECRET;

What NOT to Do ❌

Don't hard-code your secret in the codebase
Don't commit .env files to GitHub

✅ Final Tip

Regenerate your secret if you suspect a leak. Any old tokens will become invalid; which is exactly what you want in that case.