Forem: Juan Cruz Martinez

The Quiet Surrender to AI

Juan Cruz Martinez — Tue, 24 Feb 2026 12:44:12 +0000

We imagined machines would have to overpower us. We didn't imagine we'd just let go.

For years whenever people talked about AI taking over the world, the image was always the same, Skynet, Terminator like Judgment Day. Machines rising up, overpowering humanity, forcing us into submission. The fear was physical domination, the idea that one day we would have to fight back against something stronger than us to preserve what makes us human. That story assumed resistance. It assumed conflict. It assumed that if our autonomy were threatened, we would defend it.

What is actually happening is far less dramatic and far more unsettling. There are no machines dragging our minds away from us. No system is coercing us into obedience. No apocalypse is required, no war, no conquest. Instead, we are steadily handing over our thinking because it is easier to let something else do it for us. The trade is simple: less effort, less friction, less discomfort. And most people are taking it.

I am not afraid of AI. I am far more concerned with what we are doing with it. Used deliberately, AI is extraordinary. It can accelerate research, surface alternatives you hadn't considered, generate scaffolding that lets you work at a higher level of abstraction. I use it. I let it handle boilerplate, clean up grammar, automate the mechanical parts of my work. I am not interested in pretending the tool doesn't exist.

But somewhere along the way, something shifted. We stopped using AI to extend our thinking and started using it to avoid thinking altogether. That shift is subtle, and I think it is one of the most important things happening right now.

I feel this most acutely in coding because coding is the craft I care about.

I started programming as a teenager, and what hooked me was not output or efficiency. It was the struggle. Staring at a problem until it hurt and refusing to move on until it made sense. Debugging something for hours and slowly constructing a mental model of why the system behaved the way it did. It was failing, tracing the failure back to its cause, and earning understanding instead of skipping to the answer.

That friction was not an obstacle. It was the training itself. It built intuition. It built the ability to hold complexity in my head without collapsing under it. It built what I can only call taste, the sense of when a solution is right, not just functional.

Now I watch people generate code they cannot explain and ship systems they cannot reason about. If you cannot walk someone through the logic behind what you built without reopening the chat window, you did not build it. You assembled it. And over time, that difference compounds. The muscle you never use is the muscle you lose.

But I want to be honest about something. About a month ago I hit a bug in a system I was writing. The kind of thing that, five years ago, I would have traced methodically for hours, checking assumptions, slowly cornering the defect. Instead, ninety seconds in, I pasted the stack trace into a chat window. The answer came back almost instantly. It was correct. I fixed the bug and moved on.

And I felt something I didn't expect: a small, quiet loss. Not because the tool failed. Because it worked. Because the hours I would have spent building a deeper model of that system simply didn't happen. I got the fix. I missed the understanding. And I'm not sure I would have even noticed if I hadn't been paying attention.

That is what concerns me. Not the dramatic failures. The invisible ones.

Now, I know the counterargument, and I want to take it seriously, because it is not wrong.

Every generation has this panic. Socrates argued that writing would destroy memory, that people would carry knowledge in notebooks instead of in their minds, and become shallow as a result. He was partly right, actually. We did lose something. Oral cultures had capacities for memory and narrative that most literate people cannot match. But what we gained the ability to build on each other's ideas across centuries, to accumulate knowledge beyond what any single mind could hold. It was so transformative that the trade-off was clearly worth it.

Calculators. Google. Wikipedia. GPS. Every time, the fear was that cognitive offloading would make us weaker. Every time, the reality was more nuanced than the panic suggested. So why should AI be different?

Maybe it isn't. Maybe this is just the next turn of the same wheel, and the people warning about cognitive decay are playing the same role Socrates played: correct about the loss, blind to the gain.

I hold that possibility genuinely. But I think there is something different this time, and it is worth articulating precisely.

Previous tools offloaded information. AI offloads reasoning. A calculator doesn't think about the problem for you, it executes a mechanical operation so you can focus on the higher-order question. Google doesn't construct an argument, it surfaces sources so you can evaluate and synthesize them. These tools removed mechanical friction while leaving cognitive friction intact.

Large language models are the first tools that remove cognitive friction directly. They don't just give you facts. They assemble the argument. They don't just retrieve information. They do the synthesis. The thing that previous tools left for you to do, the thinking itself, is precisely what this tool offers to handle.

That doesn't make it evil. It makes the question of how you use it genuinely different from any previous technology. The line between "tool that extends my thinking" and "tool that replaces my thinking" has never been this blurry.

And I want to admit: I don't know exactly where that line is.

This pattern extends far beyond programming. Open X and you are watching bots interact with bots while humans prompt machines to manufacture engagement. Open LinkedIn and everything sounds polished, structured, optimized, safe. Every paragraph feels assembled rather than wrestled with. The voice is technically there, but it feels synthetic. You can almost hear the prompt humming behind the sentences.

We have more expressive power than ever before, and everything is starting to sound the same. Not because people lack original thoughts, but because the tool they're filtering those thoughts through has a center of gravity, and it pulls everything toward it.

That is not intelligence expanding. That is intelligence flattening. And the loss is not just aesthetic. When everyone's output converges on the same median, the signal that used to distinguish deep understanding from shallow fluency disappears. We lose the ability to tell who has actually done the thinking. Including, sometimes, ourselves.

The hardest version of this problem is generational, and I don't think my generation is equipped to talk about it honestly.

I built my intuition through friction because I had no choice. There was no tool to skip the struggle. The hours I spent debugging, the months I spent confused, the years of slowly building mental models, that was the only path available. It is easy for me to say "do the hard work" when the hard work was the only option I ever had.

Someone learning to code today at fifteen faces a fundamentally different landscape. The tool that skips the struggle is right there, it's free, and everyone around them is using it. Telling them to artificially impose difficulty is like telling someone to hand-wash their clothes to build character. It might even be right, in some narrow sense. But it is not a serious engagement with the reality they face.

What I think we actually owe that generation is not a lecture about discipline. It is an honest framework for when to use the tool and when to refuse it. When to let AI carry the load and when to carry it yourself because the carrying is the point. I don't have that framework fully worked out. I'm not sure anyone does yet.

But I know it matters, because the people who figure it out will develop genuine understanding. And the people who don't will spend years producing output that looks competent while building nothing underneath it. And they may not realize what they've lost until they need it and it isn't there.

Here is what I keep coming back to.

Convenience is not the enemy. It never was. The enemy is convenience unexamined, the slow, comfortable slide from "this tool helps me think" to "this tool thinks for me" without ever noticing the transition.

I use AI every day. I am not fighting the technology. I am fighting the gravitational pull it exerts on my own mind, the pull toward ease, toward letting the machine carry weight I should be carrying, toward skipping the part that feels slow and stupid and uncertain.

I don't always win. That concurrency bug I mentioned? I lost. I took the easy path, and I chose not to go back and do the hard work of understanding that system more deeply. I'm aware of that. I chose convenience, told myself I'd circle back, and I haven't.

So when I say most people are choosing convenience over thinking, I am not exempting myself. I am describing a gravity I feel every day. Some days I resist it well. Some days I don't.

The difference, the only difference I can claim, is that I am paying attention to the trade. I am trying to notice when I'm drifting. I am trying to keep the thinking muscle under load even when the tool offers to carry everything.

Because the uncomfortable truth is that we imagined machines would have to conquer us to take our autonomy. We imagined a fight. We imagined resistance.

We didn't imagine we would just... let go. Quietly. Willingly. Not because we were forced, but because it was easier.

And the most unsettling part is not that it's happening.

It's that most of us won't notice until it's already done.

[Boost]

Juan Cruz Martinez — Tue, 03 Feb 2026 09:19:01 +0000

Carla Urrea Stabile for Auth0

Jan 29

Why Your Demo Code Should Be Treated as Production Code (And Other DevRel Secrets) 🎸

#devrel #softwareengineering #webdev #programming

Comments

3 min read

From Senior to Staff: What Actually Changes (and How to Get There)

Juan Cruz Martinez — Tue, 07 Oct 2025 07:33:48 +0000

Moving from Senior to Staff is one of the most misunderstood transitions in an engineering career. It isn’t just a bigger paycheck, more code, or a new fancy title on LinkedIn. It’s a shift in what success looks like.

At Senior, your value is measured by how well you deliver complex work within a team. At Staff, your value comes from changing the system so multiple teams succeed. That means stepping into fuzzier problems, shaping standards, and building the paved roads that others use to move faster and safer.

If you’re asking yourself:

What does Staff really mean compared to Senior?
How do I know if I’m operating at that level?
What practical steps should I take to make the leap?

This guide is for you. It breaks down the core differences, provides a 30-60-90 days playbook, and shares concrete signals and artifacts that show Staff-level impact. We’ll also touch briefly on Principal level for context, but the focus is squarely on how to go from Senior -> Staff.

This is all coming from my own personal journey, plus having worked with people in both levels, so if you have any additional tips, or comments, hit me up on socials!

TL;DR

Senior engineers deliver complex work reliably within a team.
Staff engineers create leverage across teams: they choose the right problems, set standards, reduce systemic risk, and multiply others.
Moving up isn’t “more coding”. It’s a shift to strategy, systems, and influence.

Why Senior vs. Staff Isn’t “More of the Same”

It’s easy to assume that Staff is just “Senior, but better.” More code, more responsibility, bigger projects. But that assumption is exactly what keeps many engineers stuck at Senior for years.

The truth is: Staff is a role change, not an upgrade. The skills that make you an excellent Senior, deep technical execution, owning complex features, mentoring teammates, are still valuable, but they’re no longer enough on their own.

At Senior, success means:

You can take a loosely defined project and deliver it end-to-end.
You’re the go-to person when your team faces a tough technical challenge.
You help raise the quality bar through reviews, mentoring, and design work.

At Staff, success means something different:

You choose which problems matter at the organizational level, not just solve the ones handed to you.
You reduce systemic risk, reliability, scalability, cost, not just project risk.
You create systems and standards so, dozens of engineers can deliver faster and safer, without your direct involvement.
You influence peers and leaders across teams, not just within your own.

In short:

Senior = “I deliver complex projects well.”
Staff = “I make the organization deliver better.”

This shift feels uncomfortable at first. It requires letting go of being the hero who personally fixes everything, and instead becoming the person who designs the system that prevents problems in the first place.

The Big Differences at a Glance

Axis	Senior	Staff
Scope	One service, project, or feature team	Multiple teams or an entire domain
Time horizon	1 sprint -> 1 quarter	2–4 quarters; sets direction
Ambiguity	Clarifies project requirements	Defines problems & guardrails
Influence	Mentors teammates	Aligns leaders, gains adoption across teams
Risk	De-risks features	De-risks themes (reliability, cost, security)
Quality	Ensures correctness in repo	Creates “paved roads” so others ship safely
Metrics	Feature delivery, bug rates	Domain health: latency, cost, adoption
Artifacts	Design docs, PRs, run books	Strategy docs, RFCs, standards, deprecation plans

What Staff Engineers Actually Produce

Staff engineers aren’t judged by how many features they ship.

They’re judged by the systems, standards, and artifacts that make everyone else more effective.

Here are the kinds of things a strong Staff engineer leaves behind:

Strategy docs not just “what we’re building” but why this direction matters, how it ties to company goals, and the principles that should guide decisions.
Cross-team RFCs proposals for shared libraries, APIs, or processes that align multiple teams and prevent divergence.
Paved roads starter templates, CI/CD checks, infra defaults, or documentation that make the right way the easy way.
Reliability and cost programs SLOs, performance budgets, or cost guardrails that reduce systemic risk across services.
Migration and deprecation plans clear timelines, tooling, and communication to move dozens of teams without chaos.
Quarterly impact memos short, visible write-ups showing before/after metrics and what’s next.

These outputs are different from a Senior’s deliverables. They aren’t about your project being successful, they’re about changing the environment so every project in the org has a better chance of success.

A good litmus test:

If you went on vacation for a month, would your work keep helping others succeed?
If the answer is yes, you’re probably operating at Staff level.

These outputs keep quality and speed high even when you’re not in the room.

Signs You’re Operating at Staff Level

Titles don’t always match reality. Some engineers hold the Staff title but still operate like Seniors, while others quietly work at Staff level without the title.

The difference shows up in the signals of your day-to-day work.

Positive signals

Leaders ask you which problems to tackle, not how to implement.
Teams beyond yours adopt your standards voluntarily.
You turn vague mandates (“improve reliability”) into measurable plans.
Colleagues ship faster/safer on your paved road.
You’re comfortable saying no to projects that aren’t leverage.

Anti-signals

Heroics: saving projects by working more hours.
Endless debate threads with no decisions.
Docs with no adoption.
Optimizing local metrics while domain outcomes stagnate.
You measure success by your personal output, not by the outcomes of the system.

The Senior -> Staff Playbook

So how do you actually make the leap?

It isn’t about working longer hours or taking on every hard project.

It’s about shifting the kind of problems you own and the way you solve them.

Here’s a playbook you can follow.

1. Pick leverage, not tasks

Staff engineers don’t wait for assignments. They choose the right problems.

Look for issues that are painful across multiple teams, like:

Repeated outages caused by the same reliability gap
Onboarding that slows every new hire
Skyrocketing infra costs without visibility
Cross-service latency or data consistency issues

Write a short problem statement that frames:

Why this problem matters now
What success would look like (metrics, not feelings)
What principles should guide solutions

2. Align early and often

Staff isn’t a solo act.

Before you design solutions, pull in stakeholders:

Talk to adjacent team leads and PMs
Test your problem framing: “If we solved this, would it change your outcomes?”
Surface objections early in 1:1s
Recruit a pilot team who’s motivated to help prove it out

3. Prove it with a thin slice

Don’t try to fix everything at once.

Instead, create a reference implementation or minimum viable paved road:

A working example, not just a slide deck
Instrumentation to measure before/after impact
Enough tooling/docs so, one team can adopt it quickly

4. Scale it into a system

Once the thin slice works, make adoption easy:

Templates and golden paths
CI/CD checks or automation that enforce best practices
Migration playbooks and office hours to support teams
Clear docs and FAQs

The goal: the system succeeds without you constantly pushing it.

5. Make impact visible

Staff work is only valuable if people see its outcomes.

Create a rhythm of visible reporting:

Dashboards for reliability, cost, performance, or adoption
Short monthly updates to stakeholders
A quarterly “impact memo” that highlights wins, misses, and next bets

Visibility not only proves value. It builds trust and opens doors for your next initiative.

Remember:

Moving to Staff isn’t about doing more.
It’s about doing work that multiplies others and proving it with artifacts and outcomes.

A 30-60-90 Day Plan for Operating at Staff Level

It’s one thing to understand what Staff engineers do.

It’s another to start practicing those behaviors deliberately.

This 30-60-90 plan isn’t a magic shortcut to promotion. You won’t “become Staff” in three months.

But if you follow it, you’ll create visible artifacts, measurable outcomes, and habits that put you on the right trajectory.

Think of it as a prototype of operating at Staff level, not a promise of a title change.

Days 0–30: Define & Align

Goal: Choose the right problem and make sure it matters to the organization.

Identify one high-leverage problem. Look for an issue that hurts multiple teams: recurring outages, high infra costs, broken onboarding, or slow release cycles.
Write a 2-pager. Frame the problem, why it matters now, success metrics, principles, non-goals, and risks.
Run stakeholder 1:1s. Validate your framing with adjacent leads, PMs, and managers. Ask: “If we solved this, would it change your outcomes?”
Align with your manager. Make sure this work is recognized as Staff-level and not just a “side project.”

Days 31–60: Pilot & Prove

Goal: Show that your idea works in practice, not just in theory.

Build a thin slice. Create a reference implementation, paved-road starter kit, or minimum viable tooling.
Run a pilot. Partner with one motivated team to adopt it.
Measure before/after. Latency dropped? Setup time cut in half? Incidents avoided? Capture the data.
Share results early. Publish a short memo or internal post showing outcomes and lessons. This creates momentum and credibility.
Incorporate feedback. Adjust the system based on real adoption pain points.

Days 61–90: Scale & Institutionalize

Goal: Turn a one-off win into a repeatable system.

Expand adoption. Add docs, templates, CI checks, and migration playbooks so, multiple teams can use it.
Make it visible. Create a simple dashboard and circulate monthly health/adoption metrics.
Enable others. Run brown-bags, host office hours, or publish internal blogs to spread knowledge.
Write a quarterly memo. Summarize impact, show metrics, highlight who adopted it, and propose next bets.
Plan succession. Identify other engineers who can maintain or evolve the system so you can move on. Staff impact scales when systems outlive the creator.

⚠️ A quick reality check

This plan won’t automatically promote you to Staff in 90 days.

Most organizations require sustained evidence, often across 2–3 quarters, before recognizing Staff-level impact.

But by following this structure, you will:

Build the muscle memory of operating beyond your team
Create tangible artifacts that prove your impact
Show leaders that you can think, act, and deliver like a Staff engineer

In other words: you’ll stop waiting for the title to change and start living the role today.

The promotion will come as a lagging indicator of that consistent behavior.

👉 By the end of 90 days, you’ll have:

Tackled an org-level problem
Created a working system, not just ideas
Demonstrated measurable outcomes
Made the impact visible to leaders
Built momentum for your Staff-level promotion packet

Metrics That Matter at Staff Level

Staff engineers aren’t measured by how many tickets they close.

They’re measured by whether they improve the systems and outcomes that matter to the organization.

The exact metrics will depend on your role and your company’s priorities, but they usually fall into a few families:

Reliability: uptime, SLO attainment, incident recurrence, MTTR
Performance: latency, throughput, customer-facing SLAs
Cost Efficiency: infra cost per request/user, budget variance, efficiency gains
Quality: defect escape rate, change failure rate, deployment success rate
Adoption: % of teams using the new standard/tool, paved-road usage vs. custom paths
User/Business Impact: feature adoption, conversion, retention, time-to-first-success

Tailor metrics to your context

In platform/infrastructure roles, reliability and cost efficiency dominate.
In product or frontend roles, adoption and customer-facing performance matter more.
In data/ML roles, freshness, correctness, and trust are key.
In developer relations roles, Staff-level impact is measured less by outputs (talks, blog posts, swag) and more by program-level outcomes, such as:
- Activation: reduction in “time to first success” for new developers using the product (e.g., from 45 min -> 15 min).
- Adoption: percentage of developers or teams actively using the SDK, API, or framework.
- Retention: repeat usage of docs, samples, or community channels over time.
- Community scale: number and quality of ambassador/advocate contributions.
- Product influence: roadmap changes that came directly from aggregated developer feedback.

The right metrics are the ones that connect your work to company outcomes.

That’s the Staff mindset: not “what did I deliver,” but “how did the org get better because of it?”

Building Your Promotion Packet

A promotion packet isn’t a form you fill out at the last minute.

It’s the story of your impact, backed by evidence, artifacts, and feedback that show you’ve been operating at Staff level consistently.

Think of it as three stages:

Collecting evidence along the way
Assembling it into a clear packet
Using it in conversations with your manager for feedback and alignment

1. Collecting Evidence Along the Way

The biggest mistake engineers make is waiting until promotion season and scrambling to remember what they did.

Staff-level packets are strongest when you systematically collect proof over time.

What to collect:

Artifacts
- Save strategy docs, RFCs, paved roads, dashboards, migration plans, and memos.
- Keep a personal archive (a folder, Notion doc, or Google Drive), don’t rely only on changing org wikis.
Metrics
- Capture “before” baselines before you start.
- Record “after” results as soon as they’re visible.
- Keep screenshots or exports; dashboards evolve, but committees need fixed evidence.
Feedback & Testimonials
- Ask partner teams or managers for short notes after rollouts.
- Save Slack threads, emails, or comments that recognize impact.
- Example: “This new CI pipeline cut our release failures in half.”
Success Stories
- Post short internal updates when something lands.
- Communicate impact and create a trail of proof.

A simple evidence log can keep this organized:

Date	Artifact	Outcome	Evidence
Jan	RFC: New CI template	Release failure rate cut 50%	Build dashboard screenshot
Mar	Migration playbook	5 teams adopted in Q1	Slack feedback from Team X lead
Apr	Error budget policy	Incidents reduced 6 -> 2/qtr	Quarterly ops report

2. Assembling the Packet

When it’s time to prepare the packet, the goal is to make the story easy to understand at a glance, with details available for anyone who wants to dig deeper.

One-page summary (story at a glance):

Problem: the org-level issue you tackled and why it mattered.
Outcomes: before/after metrics that show impact.
Artifacts: key strategy docs, RFCs, paved roads, dashboards.
Adoption: which teams or orgs used your work.
Testimonials: short quotes from peers or leaders outside your team.

Appendix (the receipts):

Links to the full artifacts: docs, repos, dashboards, memos.

The one-pager tells the narrative; the appendix provides the evidence.

3. Having the Conversations

A promotion packet isn’t just a submission. It’s a conversation tool with your manager. The goal is to use it to get feedback and alignment long before the actual review cycle.

Questions to ask your manager:

“If I aim for Staff, which org-level problems would have the most impact?”
“Which metrics would prove I’m operating at that level here?”
“Looking at my current packet draft, where do you see gaps?”
“Who else should I involve or influence to show broader impact?”

Why this matters:

It ensures you’re working on problems the organization actually values.
It helps you avoid spending months on projects that won’t be recognized.
It creates a shared definition of “Staff-level” for your role and company.

👉 Would you be interested in a follow-up post on how to have effective promotion conversations with your manager? Let me know. If enough people ask, I’ll write it up.

Remember:

The packet isn’t about proving you worked hard.

It’s about proving you changed the system so the entire org got better and that you’ve been doing it consistently.

A Note on Principal Level

This article is focused on the transition from Senior -> Staff, but it’s worth briefly touching on Principal because many engineers wonder what comes next.

Similarly to "Senior to Staff", Principal isn’t just “Staff, but bigger.” It’s another shift in scope and mindset:

Scope: Where Staff usually owns a domain (a set of systems, a technical area, or a developer journey), Principal owns multiple domains or an entire function.
Time horizon: Staff plans quarters ahead; Principal sets multi-year direction.
Influence: Staff aligns teams; Principal aligns whole organizations, often including execs and cross-functional leadership.
Artifacts: Staff creates paved roads and domain strategies; Principals create company-wide technical visions, technology charters, and roadmaps that endure beyond a single product cycle.
Impact: Staff makes the environment safer and faster for dozens of engineers; Principal raises the bar for the entire company.

Why it matters even if you’re aiming for Staff

Understanding Principal helps you see how Staff fits into the bigger ladder.
Some behaviors (like shaping principles, influencing multiple orgs, or thinking in multi-year horizons) start small at Staff and expand at Principal.
Knowing the basics helps you avoid confusing Staff deliverables with Principal expectations, or overshooting too early.

Remember:

Principal isn’t the next checkbox after Staff.

It’s a different job with broader scope, longer horizons, and heavier influence.
For now, focus on mastering Staff: solving cross-team problems, creating leverage, and proving outcomes.
But keep Principal in mind as the context for where the path can lead.

Self-Check: Are You Ready?

Can you say “yes” to at least 8/12?

I’m driving an org-level problem this quarter.
There’s a visible dashboard for it.
Another team uses my paved road without me.
I’ve led a cross-team RFC to decision.
My standard is enforced in CI/policy.
I have before/after metrics tied to my work.
Managers outside my team recognize me as DRI for the domain.
I say no to low-leverage projects.
I sponsor at least one engineer through my system.
I publish quarterly memos.
I’ve declined popular work and explained why.
I have a succession plan for my system.

Remember: this isn’t a checklist to game. It’s a mirror to reflect on whether your work is multiplying others at scale.

Final Thoughts

Moving from Senior to Staff isn’t about grinding harder or being the smartest person in the room.

It’s about changing what you optimize for:

From delivering features -> to shaping outcomes
From personal output -> to organizational leverage
From fixing problems -> to building systems that prevent them
From mentoring one person -> to multiplying many

The journey can feel uncomfortable because it asks you to let go of being the hero and start being the enabler. But that’s exactly what makes Staff engineers so valuable: they make everyone around them better.

If you remember nothing else, remember this:

Staff engineers don’t measure success by what they deliver. They measure success by what the organization can deliver because of them.

Start with one problem worth solving, create leverage, make it visible, and collect the evidence as you go. Do that consistently, and you won’t just earn the Staff title, you’ll already be living it.

Thanks for reading!

The Real Reasons Why Developers Burnout

Juan Cruz Martinez — Tue, 30 Sep 2025 21:32:43 +0000

Most people think that developer burnout comes from coding too much. But here's the truth: developers rarely burn out from writing code. They burn out from everything that prevents them from doing it well.

A post I shared on LinkedIn that captured a lot of attention said something like this:

“I’ve never seen a developer burn out from ‘too much coding.’
I’ve seen them burn out from:

– unclear priorities

– constant interruptions

– politics

Protecting focus isn’t selfish. It’s survival.”

Let’s dig into why this resonates with so many developers.

The Comfortable Myth About Developer Burnout

When people outside tech hear “developer burnout,” they imagine a programmer glued to their chair for 14 hours a day, writing code until their eyes bleed. The tired stereotype of the overworked hacker.

But that’s not what most of us experience.

Developers don’t burn out because they get to spend too much time coding. Coding is the fun part. It’s what we signed up for. Solving problems with code can be exhausting, sure, but it’s often deeply fulfilling.

The truth is uglier: developers burn out because of the system around coding, not the coding itself.

The Real Burnout Triggers

In two decades in this industry, I’ve seen the same culprits again and again. They’re not technical. They’re organizational.

1. Unclear priorities

When everything is urgent, nothing is. Priorities change weekly or daily. You ship work that gets thrown away. You spend hours building features nobody uses. You never know if you’re working on the right thing.

The impact is subtle at first: you feel busy, but not productive. Over time, this disconnect kills motivation. Developers thrive on progress on seeing their work matter. When you remove that sense of direction, the work becomes a treadmill. Burnout follows.

2. Constant interruptions

Slack pings. Calendar Tetris. A “quick sync” that turns into a 45-minute derail. Studies show it takes ~23 minutes to recover from a single interruption. Now imagine 10 or of those in a day. You hardly get to work on anything at all.

Interruptions don’t just waste time they destroy depth. Deep work is where complex problems get solved. It’s where creativity emerges. Without it, developers are stuck in the shallow end: fixing small bugs, answering questions, juggling tasks but never progressing on the hard, meaningful problems. That constant surfacenlevel thrashing leaves people exhausted and unfulfilled.

3. Politics

Few things kill developer motivation like politics. Not office politics in the sitcom sense—decision-making politics.

Features prioritized because an exec shouted loudest.
Architectures chosen to please egos, not users.
Credit claimed, blame shifted.

It’s demoralizing to realize that merit doesn’t matter, that the best ideas aren’t heard, and that decisions have little to do with solving user problems. Developers want to make things better. Politics blocks that impulse and twists it into frustration. That’s when burnout sets in, not because the work is hard, but because it feels pointless.

Focus Isn’t Luxury. It’s Survival.

Burnout doesn’t come from writing too much code. It comes from being prevented from writing it well.

Focus is the oxygen of engineering. Take it away, and even the strongest developers suffocate. With it, small teams can move mountains.

Yet in too many companies, focus is treated as a luxury. Something you fight to carve out between meetings and Slack messages. That’s backwards. Protecting focus should be as sacred as protecting uptime.

If production goes down, everyone scrambles to fix it. If developer focus goes down, nobody notices, until the team is already burned out or bleeding attrition.

Code Complexity vs. Context Chaos

When developers talk about what drains them, the comparison often comes up: Is it code complexity or context chaos that wears you down more?

Most agree, it’s context chaos.

Here’s why:

Code complexity is frustrating, but it’s fair. Complex systems have rules. The logic may be tangled, but it’s still logic. You can trace it, refactor it, add tests, improve it over time. There’s always a sense that progress is possible, that effort pays off.

Context chaos, on the other hand, is unfair. It’s interruptions breaking your flow just as you’re making progress. It’s priorities shifting without explanation. It’s politics pushing the wrong projects forward. Unlike complex code, chaos doesn’t follow rules. You can’t debug it. You can’t refactor it. You can’t run a unit test to prove it works. Chaos steals energy without creating value.

And here’s the kicker: chaos amplifies complexity. A messy codebase becomes ten times harder to deal with when you’re interrupted every 20 minutes. A tough architectural problem feels impossible when politics dictates half the decisions. Chaos doesn’t just compete with code it magnifies its pain.

That’s why so many developers report that chaos, not code, is what breaks them.

How Developers Can Protect Themselves From Burnout

What can you do if you find yourself in one of these environments? Here are some survival tactics:

Draw hard boundaries. Protect blocks of time for deep work and defend them. Even two hours of uninterrupted coding can change your week.
Make priorities visible. If leadership won’t clarify, ask questions until they do. Push for written goals, not verbal fire drills.
Limit your context surface. Turn off non-critical notifications. Decline meetings where your input isn’t essential. Shrink the number of doors chaos can enter through.
Build allies. Find teammates who also value focus. A united voice is harder to ignore than a single frustrated engineer.
Document the cost. Track interruptions, shifting priorities, wasted work. Data can turn complaints into undeniable evidence.
Know when to walk. Sometimes the healthiest choice is leaving a culture that refuses to change. Protecting your energy is more important than any job.

Because developers don’t burn out from coding. They burn out from being denied the space to code. And when the system won’t give you that space you have to learn how to carve it out yourself, or decide it’s time to move on.

Thanks for reading!

What to Do When a Client Ends a Freelancing Relationship

Juan Cruz Martinez — Wed, 12 Apr 2023 19:47:04 +0000

We’ve all been there.

You feel like freelancing is going great when, out of nowhere, you get that dreaded email, call, or text.

A client ends their working relationship with you.

Sometimes, giving little or no reason.

One of the most difficult aspects of working as a freelancer is when a client ends the relationship.

It’s personal because you’ve invested so much time and energy into working with them.

It seems like they’re not just rejecting your work, they’re rejecting you. And that hurts.

Whether it’s a long-term client whom you’ve worked with for years, or a brand new account that you looked to build a relationship and trust with, ending a client relationship can be both emotionally and professionally taxing.

Although there is no one-size-fits-all approach to handling client break-ups, there are a few key things to keep in mind so that you don’t let it derail your freelancing journey.

Here are four essential things to keep in mind when a client ends a relationship.

1. Don’t Burn Bridges

Not all client break-ups are amicable or go smoothly.

You may be tempted to react unprofessionally, especially if a client ends the relationship abruptly or rudely.

It’s only natural to get upset or be defensive.

But even if you are disappointed or hurt by the end of the relationship, keep your emotions in check and take the high road.

Don’t burn bridges.

Professionalism and respect should always be your main focus, and this is especially important when parting ways with a client.

You never know what may happen in the future.

Just because a client has rejected your work or ended their working relationship with you in the present moment, they may change their mind in the future or decide that you are perfect for a different project.

So, instead of allowing negative emotions to dictate your reaction, it’s important to take the time to acknowledge the decision and express your understanding and support.

A client’s decision to end a business relationship should be respected, and you can show respect by thanking them for working with you.

Let them know that you wish their decision was different and that you’re open to working with them in the future.

The goal of this step is to leave the relationship on good terms.

Based on the wishes of both parties, you may not have a choice but to cut off communication entirely.

Sometimes, handling difficult clients necessitates cutting off all communication.

However, if you can, take the opportunity to offer one final pleasant exchange with the client, whether it’s an email, a phone call, or even a face-to-face meeting if possible.

Remain diplomatic and courteous to them throughout the process, as you want to leave a good impression.

In addition, ensure that all the terms of your work contract are respected.

Whether it’s refunds, payment arrangements, or any other agreement in the contract, each term should be followed in order to avoid any conflict.

This also shows that you are respectful of your client’s decision and value their privacy.

By acting professionally and courteously, you can leave a final, positive impression with a client, so even if they don’t return to work with you at a later time, they may recommend you to new clients. After all, building a positive freelancing reputation is a crucial part of Freelancing 101 for Devs.

2. Learn from the Experience

It’s easy to want to brush off the loss of a client, but before you do that it’s important to acknowledge it.

Even though a relationship has ended, this doesn’t mean it was a total loss.

This is the perfect time to reflect and learn from the experience.

After all, every experience is an opportunity for personal and professional growth.

Even if the relationship was not as successful as you had hoped, there are usually valuable lessons to be taken away.

Take time to understand why the client left and what (if anything) could have been done differently on your end to keep them.

If you haven’t already talked with them personally, reach out and get in touch with them.

No one likes to hear about their shortcomings, but sometimes it takes an outsider to make us more aware of how we can improve.

Ask them for any feedback that may be helpful in order to build better client relationships.

Take the time to reflect on the process and consider any improvements you can make with other clients in the future.

Using this experience as an opportunity to assess where you could have done better can help you avoid similar issues in the future.

The end of a client relationship can be tough, but it is an inevitable part of any client-facing role.

It’s simply a part of embracing the journey as a freelancer that we all need to navigate.

By following the steps outlined above, you will be able to handle the situation with grace and professionalism – while also learning valuable lessons in the process.

3. Re-Evaluate Your Support Systems

If you’ve recently lost a client, it can be a difficult experience, especially if it leads to financial strain.

You may even have to consider necessary budget cutbacks, at least short-term.

So, it’s important to take steps to ensure that your business bounces back, as quickly as possible.

Now may be the perfect time to step up your networking efforts.

There are lots of tips for networking as a freelancer that can help you boost your career.

Join industry associations, start attending industry events, add new contacts on LinkedIn, and leverage any existing relationships to spread the word about your business.

If you’ve parted ways with a client on good terms, you may even incentivize them to spread the word or send referrals to you by offering discounts on future work.

Also, losing a client is the first time some freelancers realize the importance of creating multiple streams of income.

If you haven’t already developed multiple income streams, there’s no better time to start!

Multiple income streams are essential for long-term success and avoiding a financial catastrophe when you lose an important client.

Creating multiple income streams can mean many things, like having several clients, doing varied work, or investing in different lines of business.

Now may be the right time to explore new avenues of freelancing.

Or learn new skills that you can add to your portfolio.

Or reach out to form new client relationships.

Whether it means adding new clients to your workload or adding to what you are able to offer your existing clients, focus on generating new income streams that will keep your business afloat.

Re-evaluating what support systems you need to add or improve can make all the difference in how fast your freelancing career rebounds after losing a client.

Move On

Sometimes, jumping back into freelancing and trying to find new clients can feel a bit like jumping back into the dating scene.

You might cringe just thinking about trying to move on with new clients.

You might feel reluctant and even be tempted to give up.

Don’t give up!

Turning a disappointing or bad situation into a good one is part of pivoting as a freelancer.

The most important factor to moving on is keeping a positive attitude.

Negativity will only work against you, so focus your energy on rebuilding and working toward your freelancing dream.

Remember that dream? It’s not gone.

You’ve faced difficulties in the past and persevered.

You can do the same thing now.

What you need is to create an action plan for moving forward.

Part of that action plan is to practice habits that will help you be successful as a freelancer.

Habits may seem boring or confining, but habits can be comforting.

Having steady habits to fall back on (especially when you don’t feel very motivated) will help you move on.

Another part of that action plan is to refocus on the future and on your successful client relationships.

Don’t dwell on the past, or on what “could-have-been” with a client that is gone. Your focus and energy should be spent on improving your relationships with clients you still have. You want to give them 100% of your efforts.

By staying positive, you will be more ready to pivot from a bad situation and move on to bigger, and better, opportunities.

Conclusion

When a client ends a relationship, it can be difficult and a little disappointing, but it can actually be one of the best experiences for your freelancing business.

It can teach you to remain professional, respect terms, and reflect on the experience.

It can help you make the most of the situation and use it as an opportunity to grow.

It can remind you to re-evaluate your support systems and make sure your business is well-positioned for success.

Most importantly, it can show you that you can move on from a bad experience and still realize the freelancing dreams you once had.

With hard work and a positive attitude, you can get your business back on track in no time.

Newsletter

Subscribe to my weekly newsletter for developers and builders and get a weekly email with relevant content.

Most Common Ways to Make HTTP Requests in JavaScript

Juan Cruz Martinez — Sun, 09 Apr 2023 21:32:12 +0000

In modern web development, one of the most important aspects is the ability to communicate with servers and other resources to fetch or send data. HTTP (Hypertext Transfer Protocol) is the foundation of data communication on the World Wide Web, and it allows clients (such as web browsers) to request and receive data from servers. As a web developer, understanding how to make HTTP requests is essential for creating dynamic and interactive web applications.

JavaScript, the most widely used programming language for client-side web development, provides several ways to make HTTP requests. These methods enable web applications to interact with servers, APIs, and other resources, facilitating the exchange of data in various formats, such as JSON, XML, or plain text.

In this article, we will explore the most common ways to make HTTP requests in JavaScript, including XMLHttpRequest, Fetch API, Axios, and jQuery Ajax. We will discuss their usage, syntax, and advantages, as well as potential limitations and browser support. This knowledge will help you choose the most suitable method for your projects and expand your skillset as a web developer.

Let’s get started!

Useful tutorials, guides, and career tips for developers, delivered once a week.

Subscribe and get a FREE copy of my book ten learning strategies.

Sending...

DOWNLOAD THE FREE EBOOK

Fetch API

The Fetch API is a modern and powerful alternative to XMLHttpRequest for making HTTP requests in JavaScript. Introduced as a native feature in modern browsers, the Fetch API is designed to be more concise, readable, and easier to use than its predecessor. It is built on top of the Promises API, which simplifies the process of handling asynchronous operations and managing complex workflows.

One of the key advantages of the Fetch API is its native support for making requests outside the same-origin policy using CORS (Cross-Origin Resource Sharing). This enables web applications to interact with resources hosted on different domains more easily and securely.

Following a promise-based syntax, we can use Fetch to send HTTP requests from the client-side, as this example shows.

fetch("https://world.openfoodfacts.org/category/pastas/1.json")
  .then(response => {
    // indicates whether the response is successful (status code 200-299) or not
    if (!response.ok) {
      throw new Error(`Request failed with status ${reponse.status}`)
    }
    return response.json()
  })
  .then(data => {
    console.log(data.count)
    console.log(data.products)
  })
  .catch(error => console.log(error))

Fetch significantly reduces the complexity and verboseness of the code with the use of simpler syntax and promises. In this implementation, we have to use the response.ok field to check whether the response contains an HTTP error or not because the errors caught in the catch method belong to the network level, not the application level.

The fetch method accepts a configuration object as the second parameter to allow easy manipulation of HTTP fields like headers, content-types, the request method, etc. You can find the complete list of configuration options Fetch supports in its official documentation.

Making POST requests with Fetch also follows a similar pattern to the previous example. Here, we use the config object to specify the request method and pass data that needs to be posted.

Let’s try this implementation using async/await:

async function postData () {
  const food = {
    name: "Bread",
    weight: 450,
    quantity: 3
  }

  const response = await fetch("/food", {
    method: "POST",
    body: JSON.stringify(food),
    headers: {
      "Content-Type": "application/json"
    }
  })

  if (!response.ok) {
    throw new Error(`Request failed with status ${reponse.status}`)
  }
  console.log("Request successful!")
}

Pros of Fetch API

Modern, concise, and more readable syntax based on Promises, making it easier to use and understand compared to XMLHttpRequest.
Native support for making requests outside the same-origin policy using CORS, which simplifies interactions with resources hosted on different domains.
Built-in error handling with the catch method, allowing for improved error handling capabilities in web applications.
Provides additional features over XMLHttpRequest such as integrating Request and Response objects with the native Cache API and sending no-cors requests.
Natively supported in modern browsers, eliminating the need for additional libraries.

Cons of Fetch API

Lacks some useful features supported by XMLHttpRequest such as aborting a request and monitoring request progress. (However, it allows the use of a separate AbortController object to control request aborts and timeouts.)
Accepts a response even when an HTTP error occurs. We have to manually check for HTTP errors and handle them.
No built-in progress monitoring for requests, which can be useful for tracking the progress of large file uploads or downloads.

Axios

Axios is a popular and widely used JavaScript library for making HTTP requests. It offers a simple, clean, and easy-to-use API based on Promises, making it an attractive choice for developers who prefer a more readable and concise syntax compared to XMLHttpRequest. Unlike the Fetch API, Axios works seamlessly in both browser and Node.js environments, making it a versatile solution for various types of projects.

The library provides a range of advanced features and built-in functionality, such as error handling, request cancellation, and interceptors, which can be used to modify requests and responses globally or on a per-request basis. Additionally, Axios automatically transforms JSON data, simplifying the process of sending and receiving data in a common format.

When making GET requests with Axios, we can use the dedicated axios.get() method to compile the request. Here we’ve shown an example of the implementation:

axios.get("https://world.openfoodfacts.org/category/pastas/1.json")
  .then(response => {
    // access parsed JSON response data using response.data field
    data = response.data
    console.log(data.count)
    console.log(data.products)
  })
  .catch(error => {
    if (error.response) {
      //get HTTP error code
      console.log(error.reponse.status)
    } else {
      console.log(error.message)
    }
  })

As this example shows, Axios reduces the amount of work we have to do on our end to make HTTP requests even compared to Fetch. It automatically parses the received JSON data, which we can access through response.data field. Axios also catches HTTP errors in its catch method, removing the need to specifically check for status code before processing the response. Inside the catch method, we can distinguish HTTP errors using an error.response check, which stores the HTTP error code.

For sending POST requests with Axios, we use the dedicated axios.post() method as the following example, implemented using async/await, shows:

async function postData () {
  const food = {
    name: "Bread",
    weight: 450,
    quantity: 3
  }

  try {
    const response = await axios.post("/food", food)
    console.log("Request successful!")
  } catch (error) {
    if (error.response) {
      console.log(error.reponse.status)
    } else {
      console.log(error.message)
    }
  }
}

Again, Axios simplifies this implementation by automatically converting Javascript objects to JSON without our interception. These Axios methods also accept a final parameter specifying HTTP configurations.

Other than these basic features, Axios provides solutions for many unique use cases that we won’t discuss here. But if you want to dive deeper into working with Axios in Javascript as well as Node.js, you can follow this in-depth guide to Axios on our blog.

Pros of Axios

Easy-to-use and concise syntax based on Promises, offering a more readable and intuitive experience compared to XMLHttpRequest.
Built-in support for error handling and request cancellation, which simplifies the process of managing complex requests and improving the user experience.
Supports both browser and Node.js environments, making it a versatile solution for various types of projects and platforms.
Provides useful features like interceptors for modifying requests and responses globally or on a per-request basis, and automatic JSON data transformation.
Rejects on HTTP errors by default, making error handling more intuitive than the Fetch API.

Cons of Axios

Requires an additional library to be added to your project, which can increase the overall size of the application.

XMLHttpRequest

XMLHttpRequest is a native API in Javascriptthat has been around since the early 2000s. It was initially developed by Microsoft and later adopted by other browsers. Although the name suggests that it is specifically designed for XML data, XMLHttpRequest can be used to request and handle a variety of data formats, such as JSON, HTML, and plain text.

Over the years, XMLHttpRequest has become a fundamental building block for making asynchronous HTTP requests in web applications. However, its usage has somewhat declined with the introduction of more modern and easier-to-use alternatives, such as the Fetch API.

Here’s how we can send GET requests and asynchronously retrieve data from a remote API using XMLHttpRequest API:

//create XMLHttpRequest object
const xhr = new XMLHttpRequest()
//open a get request with the remote server URL
xhr.open("GET", "https://world.openfoodfacts.org/category/pastas/1.json")
//send the Http request
xhr.send()

//EVENT HANDLERS

//triggered when the response is completed
xhr.onload = function() {
  if (xhr.status === 200) {
    //parse JSON datax`x
    data = JSON.parse(xhr.responseText)
    console.log(data.count)
    console.log(data.products)
  } else if (xhr.status === 404) {
    console.log("No records found")
  }
}

//triggered when a network-level error occurs with the request
xhr.onerror = function() {
  console.log("Network error occurred")
}

//triggered periodically as the client receives data
//used to monitor the progress of the request
xhr.onprogress = function(e) {
  if (e.lengthComputable) {
    console.log(`${e.loaded} B of ${e.total} B loaded!`)
  } else {
    console.log(`${e.loaded} B loaded!`)
  }
}

As this example shows, the process of sending a GET request with XMLHttpRequest involves three steps:

Create XMLHttpRequest
Opening the HTTP request of the indented type
Sending the request

Once the request is sent, we can use the event handlers provided by the XMLHttpObject to handle its response. Here, we have used two event handlers: onload, onerror, and onprogress. It’s important to note here that onerror method only handles network-level errors related to the request. To identify HTTP errors, we have to check the HTTP status code inside the onload method specifically.

We can send POST requests with XMLHttpRequest following a similar pattern.

// create XMLHttpRequest object
const xhr = new XMLHttpRequest()
// open a POST request
xhr.open("POST", "/food")
// set content-type header to JSON
xhr.setRequestHeader("Content-Type", "application/json");
// send JSON data to the remote server
xhr.send(JSON.stringify(food))

// Event Handlers

// track data upload progress
xhr.upload.onprogress = function(e) {
  console.log(`${e.loaded}B of ${e.total}B uploaded!`)
}

// triggered when data upload is finished
xhr.upload.onload = function(e) {
  console.log("Upload completed")
}

// triggered when the response is fully received
xhr.onload = function() {
  console.log(xhr.status)
}

// triggered due to a network-level error
xhr.onerror = function() {
  console.log("Network error occurred")
}

One main difference between the earlier GET and the current POST request is explicitly setting the content-type headers when posting JSON data. Also, there is an additional event type a POST request can trigger compared to a GET request. They are upload events accessed through the xhr.upload field. These event handlers help us track the data upload progress when the request body has to carry a significant amount of data (e.g., images, files, etc.)

Pros of XMLHttpRequest

Excellent browser support, including older browsers like Internet Explorer 7 and above.
Removes the need for external dependencies.
Ability to monitor the progress of a request using the readystatechange event.

Cons of XMLHttpRequest

Verbose and less intuitive syntax compared to modern alternatives.
No support for async/await or promise-based syntax.
Lacks some advanced features and error handling capabilities found in newer APIs.

JQuery Ajax

jQuery is a widely used and popular JavaScript library that simplifies various aspects of web development, such as DOM manipulation, event handling, and animation. One of its powerful features is jQuery Ajax, which provides a simple and easy-to-use API for making asynchronous HTTP requests. jQuery Ajax has been a popular choice among web developers for many years due to its simplified syntax and ease of use compared to XMLHttpRequest.

The jQuery Ajax API offers several advanced features and options, such as error handling, timeout settings, caching, and support for JSONP (JSON with Padding) to work around cross-domain request limitations. These features make it an attractive option for developers who are already using jQuery in their projects or prefer a more simplified approach to making HTTP requests.

Though it is from the pre-framework (like React, angular, etc) era, it is still adopted by many websites, specially when working with platforms such as wordpress and templates.

Let’s see an example of a GET request with jQuery:

$.ajax({
  url: 'https://world.openfoodfacts.org/category/pastas/1.json',
  method: 'GET',
  dataType: 'json',
  success: function(data) {
    // Handle the received data
    console.log(data);
  },
  error: function(xhr, status, error) {
    // Handle any errors
    console.error('Error: ' + status + ' - ' + error);
  }
});

Similarly, you can have a post request:

$.ajax({
  url: 'https://world.openfoodfacts.org/category/pastas/1.json',
  method: 'POST',
  dataType: 'json',
  data: json,
  success: function(data) {
    // Handle the received data
    console.log(data);
  },
  error: function(xhr, status, error) {
    // Handle any errors
    console.error('Error: ' + status + ' - ' + error);
  }
});

Pros of jQuery Ajax

Simplified syntax and ease of use, making it more accessible for developers compared to XMLHttpRequest.
Provides advanced features and options like error handling, timeout settings, caching, and JSONP support for cross-domain requests, which can improve the overall user experience.
Widely adopted and popular due to the extensive use of the jQuery library in the web development community, ensuring a wealth of resources and support.

Cons of jQuery Ajax

Requires the inclusion of the jQuery library, which may not be needed for other parts of the project, adding extra weight and complexity to the application.
Less relevant and less frequently used in modern web development due to the rise of alternative libraries and native APIs like Fetch and Axios, which offer similar functionality without the need for jQuery.
Not as lightweight and performant as native APIs like Fetch or XMLHttpRequest, which might be a concern for performance-sensitive projects or applications targeting slow connections or limited resources.

Ky

Ky is a relatively new Javascript package that can be used for making asynchronous HTTP requests from the front end of a web application. It’s built on top of the native Fetch API with a simpler syntax and additional functionality.

Ky provides a simple syntax for making requests with its dedicated HTTP methods. Here’s an example of sending a GET request using Ky with async/await.

async function getData () {
  try {
    const data = await ky.get("https://world.openfoodfacts.org/category/pastas/1.json").json()
    console.log(data.count)
    console.log(data.products)
  } catch (error) {
    if (error.response) {
      console.log(error.response.status)
    } else {
      console.log(error.message)
    }
  }
}

We can send POST requests following a similar pattern:

async function postData () {
  try {
    const response = await ky.post("/food", { json: food })
    console.log("Request successful!")
  } catch (error) {
    if (error.response) {
      console.log(error.reponse.status)
    } else {
      console.log(error.message)
    }
  }
}

Pros of Ky

Gives a simple, lightweight, promise-based API for making HTTP requests.
Addresses some limitations in the native Fetch API with support for features like request timeout, retry, and monitoring progress.
Provides hooks for modifying requests during their lifecycle: beforeRequest, afterResponse, beforeRetry, etc.
Supports all modern browsers like Chrome, Firefox, Safari. For Internet Explorer support, Ky provides an alternative package, Ky-Universal, not sure why they still bother.

Cons of Ky

Relatively a new package compared to other mature, versatile options discussed in this post. Adds an external dependency.

Conclusion

n conclusion, there are several methods available for making HTTP requests in JavaScript, each with its own advantages and disadvantages. Choosing the right method for your project depends on various factors, such as browser support, ease of use, performance, and the specific requirements of your application.

In this article we explored, XMLHttpRequest, Axios, Fetch API, jQuery Ajax, and Ky with examples, pros and cons. By now you should be able to evaluate the specific needs of your project, and choose the most suitable approach for making HTTP requests in JavaScript, ensuring efficient and responsive web applications with improved error handling and versatile functionality.

Note: Nowadays I almost always go with Axios or FetchAPI

Thanks for reading!

Newsletter

Subscribe to my weekly newsletter for developers and builders and get a weekly email with relevant content.

Turning a Freelance Gig into a Long-Term Partnership

Juan Cruz Martinez — Wed, 05 Apr 2023 12:50:32 +0000

There are two types of freelancers.

The first type views freelancing as a side-hustle. They still hold a 9-to-5 job and most of their time and energy goes into that career.

But they also want a little more - more money, or more creative freedom, or more challenging work. So, they dabble in freelancing.

The second type deep-dives into freelancing. They’ve left their 9-to-5 job and view freelancing as their new career.

They also want more - but on a bigger scale. So, they’re all in.

Both types usually start out in the same way. They’re trying to secure a freelancing gig, so they may take advantage of online freelancing platforms, or try to find freelancing opportunities through networking.

Hopefully, they start to land some gigs. But it’s at this point that the two types go in different directions.

For the part-time freelancer, gigs come and go. They take whatever they can get, whenever they can get it. They view gigs as short-term opportunities.

But for the “all-in” freelancer, a gig isn’t just a one-time job or a short-term opportunity. They’re looking to establish connections with clients and create long-term opportunities.

They want to know how to turn a freelancing gig into a long-term partnership.

Here’s the secret. Turning a freelancing gig into a long-term partnership is beneficial for both types of freelancers, and there are a few key ways to do it.

First, let me explain why it’s beneficial for both types of freelancers.

Of course, the long-term freelancer sees the benefits because he wants to secure gigs that will keep generating income and help him grow his freelancing business.

He knows the value of creating multiple streams of income as a freelancer, especially if those streams keep flowing.

Having a long-term partnership means more jobs, and more money, are coming in.

As an added bonus, long-term clients are also more likely to recommend you among their networks, so this partnership can generate additional opportunities for you.

Maybe you’re thinking, freelancing is just a side-hustle for me, and long-term partnerships would require too much from me.

Let me explain how long-term partnerships can even benefit a part-time freelancer.

If you’ve correctly turned a freelance gig into a long-term partnership, you’ve got a constant source and a sustainable stream of income from which you can supplement your side-hustle.

You no longer have to go online looking for gigs, or filling out bids, or spending your precious time and energy networking.

Additionally, your work becomes more efficient.

One of the hardest parts about working with a new client is the process of figuring out what they want and how to communicate with them.

Defining their design aesthetic, determining the best way to meet their needs, and learning what they really want when they ask you for something, are all hard to do at first.

They take time, require extra effort, and often involve mistakes at first.

But, once you’ve worked with a client for a few months, you can begin to anticipate their needs, develop the solutions they need quicker, and know what they want without asking.

As a result, you deliver better results, move quicker, and make more money.

So, long-term partnerships with even just a few clients can greatly benefit your freelancing business, whether you’re a part-time or all-in freelancer.

The real question becomes, How do I turn a freelance gig into this type of long-term partnership that benefits my freelancing business?

We all know that the freelance industry has become increasingly saturated, and it can be difficult to stand out and secure long-term freelance gigs.

Here are a few key ways to successfully create this type of long-term partnership with a client.

1. Show Interest by Asking Questions

When you begin freelancing you are, of course, focused on your business. That’s natural.

But, to really build a long-term partnership, you’ve got to shift your focus to the client.

You have to understand the client’s business, needs, and motivation. You need to show that you are interested in really helping them achieve their long-term goals, not just delivering on a short-term gig.

Understanding the long-term value of client relationships, instead of only focusing on immediate gain, is part of embracing the journey as a freelancer.

That means, you’ve got to ask questions. People love talking about themselves. Begin by finding some common interest so that you can connect with the client.

Clients want to work with someone they like, someone they feel comfortable with, someone they feel connected to.

At the most basic level, you can talk about how their business got started and where they see it heading. This will give you valuable information about whether or not this client relationship should be turned into a long-term partnership.

Not all long-term partnerships will benefit you. By asking a few questions at the start, you can determine if this short-term gig is really something you want to develop into a long-term partnership.

If it is, continue asking questions about what is important to them in this business. What struggles are they facing? What goals do they have?

The more you understand about their business, the better chance you have of being able to offer them valuable services.

A long-term partnership should be a mutually beneficial arrangement.

When they see that you are really genuine and invested in trying to help them, they will want to continue working with you.

It’s a win-win situation.

2. Create Trust by following Through

Building a rapport with your client will create a sense of trust and show them that you value their business and are committed to the partnership.

The worst thing you can do is botch the short-term project they’ve hired you for.

Clients will only continue working with a freelancer they trust to follow through and deliver on time.

Of course, things happen. Clients change the scope of a project or demand faster delivery. Or maybe you deliver exactly what they asked for, but they’re still not happy.

That’s when effective communication skills are crucial.

Trust is created through transparency and communication, as well as by following through on what you promise.

In order to avoid an unhappy client, keep in touch regularly and communicate often. Keep them updated on the status of their project.

Be honest about any set-backs and provide them with an updated timeline.

Be sure to follow up with them if you haven’t heard from them in a while and always respond quickly to any queries or requests.

These effective communication skills are one of the essential habits to practice that will help you be successful as a freelancer.

These days, it’s harder and harder to find someone whom you can really trust.

If a client realizes that they can trust you to make things right and deliver, even through set-backs or unexpected changes, they will want to continue building a partnership with you.

3. Demonstrate Initiative by Thinking Ahead

The key to forming a long-term partnership is to go above and beyond the expectations of your client.

This is one key tip for securing high-paying freelance gigs and turning those gigs into long-term partnerships.

High-end clients are looking for a freelancer who offers more value for their business.

Once you successfully deliver on a short-term gig, try offering to work on a trial project to showcase your skills.

This allows you and your client to test the waters and assess if the partnership is a natural fit.

During the process, demonstrate your creativity and flexibility, and showcase how you can tailor your services to their needs and provide valuable insights.

For example, if a client asks you to write content for their website, and you notice the website isn’t tailored for mobile users, offer your expertise in web development to help them reach mobile users and generate more sales.

Or maybe you realize that their systems could be updated and integrated more efficiently. Let them know that you’re happy to help them with this and explain the added value for their business.

This is when truly understanding their business, because you asked the right questions in the beginning, pays off.

If you’ve neglected to really get to know your client, you won’t be able to communicate how you can help them further, and you won’t be able to take the initiative to build a long-term partnership.

Knowing your client well, thinking ahead, and offering effective solutions show that you take initiative.

This type of initiative can set you apart from the scores of other freelancers competing for a client’s business.

4. Provide Value by Offering Excellence

This plays out in several ways.

Of course this means handing over an excellent product to your client. High-end clients, especially, are paying premiums to get excellent results.

But even smaller gigs deserve your best efforts. Excellence for every client is part of Freelancing 101 for Devs.

This might mean not taking on more than you can handle. Realize when your time and energy are stretched to the limit, so that you don’t end up with too many projects that turn out to be sub-par.

Prioritize which clients and projects are going to be beneficial for you in the long-term. Then, focus on providing them with excellence.

Part of the value of working with you should be that clients receive excellent customer service. Make sure you are available and responsive to their needs.

This doesn’t mean you can’t establish boundaries and routines to support your mental health and ensure your best output.

But, understand that poor customer service is a problem everywhere. Clients have enough headaches.

They aren’t going to be open to a long-term partnership with a freelancer who offers substandard customer service.

In addition to excelling in your services and interactions, have a consistent pricing structure and ensure that you are providing value for their money.

Offer great incentives to encourage your clients to remain loyal, such as offering discounts on one-off jobs or providing extras such as free consultations or resources that can benefit their business.

You should also be open to changing or adapting your services as your client’s needs evolve.

The bottom line is this: Is your work associated with excellence?

Ask yourself, What do I need to do or change so that clients expect to get excellent value when working with me?

Whatever the answer is, do it.

Creating a culture of excellence is what will entice clients to turn a short-term gig into a long-term partnership with you.

Conclusion

Finding and transforming a successful short-term freelance gig into a long-term partnership takes hard work, dedication, and excellence.

It might take some time and practice to find the right gigs and clients who will be mutually beneficial in a long-term partnership.

You’ll need to practice these four keys consistently:

Asking questions to show interest in and learn about the client’s business,
Following through so you earn the client’s trust,
Thinking ahead so you can solve the client’s problems and show initiative,
Offering excellence in a variety of ways so you can provide value to the client.

Whether a part-time or full-time freelancer, if you do these things you will soon find that clients pursue working with you.

And these successful long-term partnerships will help grow and sustain your business so that freelancing affords you the life you’ve always wanted.

Thanks for reading!

Newsletter

Subscribe to my weekly newsletter for developers and builders and get a weekly email with relevant content.

How to Fix: Error: Src Refspec Master Does Not Match Any in Git

Juan Cruz Martinez — Tue, 28 Mar 2023 20:05:32 +0000

If you’re a developer using Git, you’ve probably encountered the error message “src refspec master does not match any” at some point. This error can be frustrating and confusing, especially for beginners who are new to version control.

In this article, we’ll explain what this error message means common causes of the error and provide you with several solutions to help you fix it.

If you have this exact error, naming the master branch in the error message and you want a quick attempt to fix it without reading any further, try: git push origin main. If that doesn’t help, keep reading as this error can be caused by different reasons.

Understanding the Error Message

The error message “src refspec master does not match any” is usually caused by Git when pushing changes and not finding the master branch in your remote repository.

The actual error can happen with any branch, and the branch will be highlithed in the error itself, “Error: src refspec {branch} does not match any”.

This could be due to several reasons, including:

The branch name may be incorrect (e.g., it is called main).
There may be no commits on the branch.
The branch may have been deleted.

Common Fixes for the Error

Working on the Wrong Default Branch

This error happened a lot when we moved from using master to main as the default branch in most systems, for example, GitHub.

Most local copies of projects were using the master branch, but the repository default branch was renamed to main.

The best way to find out if your branch exists in the remote repository is by running git branch -r

git branch -r

> result:
> origin/main
> origin/test

Knowing that the master branch is missing in the remote we have two options forward. We either create and push the master branch, or we switch to another branch, i.e.: main.

To force the use of the master branch and fix the error, run:

git checkout -b master
git push origin master

If you don’t want that, and instead use another branch, simply run:

git push origin main

If you are unaware of the name of the default branch, you can run git show-ref to find it out.

No Commints on the Branch

Another common reason why you may get: “Error: src refspec {branch} does not match any” when pushing in Git is that you haven’t made a single commit for the branch yet.

This is easy to reproduce if you start with a new Git repository:

mkdir git-test
cd git-test

git init

touch README.md
git add README.md

git remote add origin https://github.com/username/git-test.git
git push -u origin main

After creating a new git repository with git init and introducing some changes, we add the remote (notice that it doesn’t matter if the repo doesn’t exist) and we try to push, but in the process we forgot to commit the changes, so we receive the error:

error: src refspec main does not match any

And it was as expected. Commiting the changes and pushing again will work as it should.

Make sure you commit your changes before trying to push!

To check if you have pending changes from commiting, you can run:

git status

To commit, after staging the changes with git add run the following command and specify the commit message that you want:

git commit -m "my first commit"

Best Practices for Avoiding the Error

Here are some recommendations to prevent you from seeing “src refspec master does not match any” often:

Use the correct branch name: When pushing or pulling changes, make sure you’re using the correct branch name. If you’re not sure, use the git branch command to check which branch you’re on.
Commit changes frequently: It’s always a good idea to commit changes frequently, especially if you’re working on a larger project. This helps you avoid having too many uncommitted changes and reduces the risk of encountering errors when pushing changes.
Keep your local and remote repositories in sync: To avoid errors, make sure you’re pulling changes regularly from the remote repository to keep your local repository up to date. Use the git pull command to update your local repository with the latest changes.

Conclusion

In conclusion, the “src refspec master does not match any” error in Git can be a frustrating issue to encounter, especially if you’re new to version control. However, with the solutions we’ve provided in this article, you should be able to resolve the error and continue managing your code effectively and efficiently.

Remember to always use the correct branch name, commit changes frequently, keep your local and remote repositories in sync, use descriptive commit messages, and use branches for experimental changes to avoid encountering this error in the future.

By following these best practices, you can reduce the risk of encountering errors and ensure a smooth and streamlined workflow when working with Git. With proper version control, you can manage your code effectively and collaborate with others on your projects with confidence.

Thanks for reading!

Newsletter

Subscribe to my weekly newsletter for developers and builders and get a weekly email with relevant content.

Must-Know JavaScript Array Methods

Juan Cruz Martinez — Mon, 13 Feb 2023 21:00:36 +0000

Arrays are one of the most powerful data structures in JavaScript and are helpful for all sorts of tasks. This blog post will discuss 15 array methods in detail so you can start using them immediately!

If you are working with JavaScript, arrays are something you can’t avoid, so knowing these 15 JavaScript array methods is not only helpful, but it is a must, and they are often the subject of interview questions.

What Are JavaScript Arrays?

A JavaScript array is a data structure that stores multiple values in a single variable. They are similar to other data structures, like lists and dictionaries, but they have some key differences. Arrays are ordered collections of items, so each item has an index. This index can be used to access or modify the items in the array.

Create an Array

You can create an array in JavaScript using any of the following syntaxes:

Create an array by encapsulating array elements in squared brackets:

const array_name = [item1, item2, ...];

Alternatively, you can start with an empty array and fill the array:

const array_name = [];
array_name[0]= item1;
array_name[1]= item2;
array_name[2]= ...;

Or you can use the keyword new with the array constructor:

const array_name = new Array(item1, item2, ...);

And there are more clever and fun ways of doing that, but that will have to be for another article.

Why Are JavaScript Arrays So Good?

JavaScript arrays are powerful because they provide a lot of methods to manipulate data. These methods make it easy to perform everyday tasks, such as:

Adding and removing elements from an array
Searching for an element in an array
Sorting the elements in an array
Looping through an array
Filtering an array

And much more!

So, without further ado, let’s get started with the 15 must-know JavaScript array methods.

Method #1: Some()

The some() method tests whether at least one element in the array passes the test implemented by the provided function. It returns a Boolean value.

This is how you use it:

arr.some(callback(element[, index[, array]])[, thisArg])

The some() method executes the callback function once for each element present in the array until it finds one where callback returns a truthy value (a value that coerces to true). It returns’ false’ if it doesn’t find such an array element.

Example:

const a = [1, 2, 3, 5, 8].some(item => item > 5)
const b = [1, 2, 3, 4, 5].some(item => item > 5)

console.log(a)
console.log(b)

---------
Output
---------
> true
> false

Method #2: Every()

The every() method tests whether all elements in the array pass the test implemented by the provided function. It returns a Boolean value.

This is how you use it:

arr.every(callback(element[, index[, array]])[, thisArg])

The every() method executes the callback function once for each array element until it finds one where callback() returns a falsy value (a value that coerces to false). It returns true if it doesn’t find such an array element.

Example:

const a = [10, 9, 8, 7, 6].every(item => item > 5)
const b = [7, 6, 5].every(item => item > 5)

console.log(a)
console.log(b)

---------
Output
---------
> true
> false

Method #3: Reduce()

The reduce() method executes a reducer function (that you provide) on each array element, resulting in a single output value.

The reducer function takes four arguments:

accumulator
currentValue
currentIndex
array

The first time the callback is called, accumulator and currentValue can be either the initialValue if provided or the first array element if not.

Definition:

arr.reduce(callback( accumulator, currentValue[, index[, array]] )[, initialValue])

How reduce() works

Let’s see with an example how reduce() works:

[0, 1, 2, 3, 4].reduce((accumulator, currentValue, currentIndex, array) => accumulator + currentValue)

If we go step by step and put in a table all the parameters plus the resulting value of the callback, we would get the following:

#	accumulator	currentValue	currentIndex	array	return value
1	0	1	0	[0, 1, 2, 3, 4]	1
2	1	2	1	[0, 1, 2, 3, 4]	3
3	3	3	2	[0, 1, 2, 3, 4]	6
4	6	4	3	[0, 1, 2, 3, 4]	10

And the final result would be 10. In our particular case, I did not provide an initial value. Let’s try that next.

const initialValue = 10
[0, 1, 2, 3, 4].reduce((accumulator, currentValue, currentIndex, array) => accumulator + currentValue, initialValue)

With this new scenario, our table would like:

#	accumulator	currentValue	currentIndex	array	return value
1	10	0	0	[0, 1, 2, 3, 4]	10
2	10	1	1	[0, 1, 2, 3, 4]	11
3	11	2	2	[0, 1, 2, 3, 4]	13
4	13	3	3	[0, 1, 2, 3, 4]	16
5	16	4	4	[0, 1, 2, 3, 4]	20

And the final resulting value is 20.

The reduce() function is great. It has several uses, like summing all the values of an array or in an object array, counting for particular items in the array, grouping objects, merging arrays contained in an array of objects, removing duplicates, etc.

If you want to know more about reduce() check our guide on JavaScript reducer, a simple, yet powerful array method

Method #4: Map()

The map() method creates a new array with the results of calling the provided function on each array element.

The function takes three arguments:

currentValue
index (optional)
array (optional)

In order, the map() method calls the provided function once for each element in an array. It does not execute the callback on elements without values. The return value of the callback function is stored in the new array.

Definition:

arr.map(callback( currentValue[, index[, array]])[, thisArg])

Always be careful when using map(). Remember that for each element, JavaScript creates an array. If you don’t need the resulting array and want to iterate the array elements, use forEach() or for-of instead.

Example:

const numbers = [1, 2, 3, 4, 5]
const doubled = numbers.map(value => value * 2)

console.log(doubled)

---------
Output
---------
> (5) [2, 4, 6, 8, 10]

As we mentioned, map() will create a new array, so the following is a consequence of that:

const numbers = [1, 2, 3, 4, 5]
const numbers2 = numbers.map(value => value)
console.log('numbers', numbers)
console.log('numbers2', numbers2)
console.log(numbers === numbers2)

---------
Output
---------
numbers (5) [1, 2, 3, 4, 5]
numbers2 (5) [1, 2, 3, 4, 5]
false

Even though each array contains the same elements, they are not the same reference. Thus the numbers === numbers2 resolves to false.

Method #5: Flat()

The flat() method creates a new array with all sub-array elements concatenated recursively up to the specified depth. The default depth is one.

Examples:

const arr1 = [1, 2, [3, 4]]
console.log(arr1.flat())

const arr2 = [1, 2, [3, 4, [5, 6]]]
console.log(arr2.flat())

const arr3 = [1, 2, [3, 4, [5, 6]]]
console.log(arr3.flat(2))

const arr4 = [1, 2, [3, 4, [5, 6, [7, 8, [9, 10]]]]]
console.log(arr4.flat(Infinity))

---------
Output
---------
> (4) [1, 2, 3, 4]
> (5) [1, 2, 3, 4, Array(2)]
> (6) [1, 2, 3, 4, 5, 6]
> (10) [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

Note that if we want to flatten all levels recursively, we can pass Infinity as the function’s argument.

Method #6: Filter()

The filter() method creates a new array with all elements that pass the given test implemented by the provided function.

The filter() method does not mutate the original array but returns a new one.

Definition:

arr.filter(callback(element[, index, [array]])[, thisArg])

Examples:

const array = [-3, -2, -1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13]

function isPrime(num) {
 for (let i = 2; num > i; i++) {
  if (num % i == 0) {
   return false
  }
 }
 return num > 1
}

console.log(array.filter(isPrime))

---------
Output
---------
> (6) [2, 3, 5, 7, 11, 13]

From the example above, we use a filter() method with a callback function to test whether each element of an array is a prime number or not. The resulting new array only contains the elements of an array that are prime numbers.

Method #7: ForEach()

The forEach() method executes the provided function once for all the elements in the array. It differs from the map() method because it does not create a new array.

arr.forEach(callback(currentValue [, index [, array]])[, thisArg])

Definition:

arr.forEach(callback(currentValue [, index [, array]])[, thisArg])

Example:

const array = [1, 2, 3, 4, 5]
array.forEach((item) => console.log(item))

---------
Output
---------
1
2
3
4
5

There are two critical considerations when using forEach():

There is no way to stop or break a forEach() loop other than throwing an exception.
forEach() expects a synchronous callback, it won’t wait for promises to be resolved.

Let’s see an example of the latter:

let ratings = [5, 4, 5]
let sum = 0

let sumFunction = async function (a, b)
{
 return a + b
}

ratings.forEach(async function(rating) {
 sum = await sumFunction(sum, rating)
})

console.log(sum)

---------
Output
---------
0

The expected outcome for the above example would have been 14, but we got 0 instead. The forEach() array method did not await the promise, and the console.log() statement was executed before the variable sum was updated.

If you want to know more about forEach() check our guide on looping arrays with JavaScript forEach

Method #8: FindIndex()

The findIndex() method returns the index of the first element in an array that satisfies a given test function. Otherwise, it returns -1. Unlike other methods, findIndex() will execute the given function even for indexes with unassigned values.

Definition:

arr.findIndex(callback( element[, index[, array]] )[, thisArg])

Example:

function isPrime(num) {
 for (let i = 2; num > i; i++) {
  if (num % i == 0) {
   return false
  }
 }
 return num > 1
}

console.log([4, 6, 8, 9, 12].findIndex(isPrime))
console.log([4, 6, 7, 9, 12].findIndex(isPrime))

---------
Output
---------
-1
2

As we can see from the example above, findIndex() returns -1 if an array does not contain any prime numbers and the index of the first element that’s a prime number.

Method #9: Find()

The find() method returns the value of the first element in an array that satisfies a given test function. Otherwise, it returns undefined. Note the difference with findIndex(), where the element’s index is returned instead of the value.

Definition:

arr.find(callback(element[, index[, array]])[, thisArg])

Example:

const inventory = [
 {name: 'apples', quantity: 2},
 {name: 'bananas', quantity: 0},
 {name: 'cherries', quantity: 5}
]

const result = inventory.find( ({ name }) => name === 'cherries' )

console.log(result)

---------
Output
---------
> {name: "cherries", quantity: 5}

Method #10: Sort()

The sort() method returns a new sorted array with the elements sorted in ascending order. When called with no arguments, the array is sorted alphabetically by converting each element to a string and comparing these strings using Unicode code point value.

Sorting is among the most popular js array methods, yet it is sometimes misused, as it has a few particularities.

Examples:

const numbers = [4, 2, 5, 1, 3]
numbers.sort((a, b) => a - b)
console.log(numbers)

---------
Output
---------
> (5) [1, 2, 3, 4, 5]

Always remember that the sorting happens in place, so:

const numbers = [4, 2, 5, 1, 3]
const numbers2 = numbers.sort((a, b) => a - b)

console.log('numbers', numbers)
console.log('numbers2', numbers2)
console.log(numbers === numbers2)

---------
Output
---------
numbers > (5) [1, 2, 3, 4, 5]
numbers2 > (5) [1, 2, 3, 4, 5]
true

The sort function will modify the original array and return a reference to itself. Thus, the initial array and the returned array are the same.

Method #11: Concat()

The concat() method merges two or more arrays into a single javascript array. This method does not alter the original but returns a new array instance containing all the elements from both arrays.

Definition:

const new_array = old_array.concat([value1[, value2[, ...[, valueN]]]])

Examples:

const letters = ['a', 'b', 'c']
const numbers = [1, 2, 3]

console.log(letters.concat(numbers))

---------
Output
---------
> (6) ["a", "b", "c", 1, 2, 3]

Method #12: Fill()

The fill() method sets all the elements in an array, from a start index to an end index, with a static value. It returns a new array object without altering the original one.

Definition:

arr.fill(value[, start[, end]])

Examples:

const original = [1, 2, 3]
const result = original.fill(4)
console.log('original', original)
console.log('result', result)
console.log(original === result)

---------
Output
---------
original > (3) [4, 4, 4]
result > (3) [4, 4, 4]
true

Method #13: Includes()

The includes() method returns true or false depending on whether a given value is present among the array elements. It is similar to the indexOf() method, but instead of returning the index, it returns just a boolean indicating its presence in the array.

Definition:

arr.includes(valueToFind[, fromIndex])

Examples:

console.log([1, 2, 3].includes(2))
console.log([1, 2, 3].includes(4))

---------
Output
---------
true
false

Note that includes is case-sensitive when dealing with strings.

Method #14: Reverse()

The reverse() method reverses an array in place. By reversing, we mean that the function will transpose the elements of the array. The first element will become the last, and the last the first element.

This operation will mutate the original array and return a reference to the same.

Definition:

a.reverse()

Examples:

console.log([1, 2, 3].reverse())

---------
Output
---------
> (3) [3, 2, 1]

A typical use case for reverse() is, for example, if you have an array of comments and want to display them in reverse chronological order.

Method #15: FlatMap()

The flatMap() method applies a function to each array element and then flattens the result into an array. It combines flat() and map() in one function.

Definition:

arr.flatMap(callback(currentValue[, index[, array]])[, thisArg])

Example:

const array = [[1], [2], [3], [4], [5]]

const a = array.flatMap(arr => arr * 10)

// With .flat() and .map()
const b = array.flat().map(arr => arr * 10)

console.log('flatMap', a)
console.log('flat&map', b)

---------
Output
---------
flatMap (5) [10, 20, 30, 40, 50]
flatMap (5) [10, 20, 30, 40, 50]

Bonus: Add and Remove Array Elements with Push() and Pop() and Shift()

push()

The push() method adds one or more elements to the end of an array and returns the new length of the new array. It mutates the array in place. The elements are added one by one after the last array element, in the order in which they appear in the arguments list.

Example:

const fruits = ["🍌", "🍊", "🍎"];
fruits.push("🥝", "🍋");
console.log(fruits); // output: ['🍌', '🍊', '🍎', '🥝', '🍋']

pop()

The pop() method removes the last array element and returns that removed element. It mutates the array in place.

Example:

const fruits = ["🍌", "🍊", "🍎"];
const popped = fruits.pop(); // remove last element

console.log(fruits); // output: ['🍌', '🍊']
console.log(popped); // output: 🍎

shift()

The shift() method removes the first element from an array and returns that removed element. It mutates the array in place.

Example:

const fruits = ["🍌", "🍊", "🍎"];
const shifted = fruits.shift(); // remove first array element

console.log(fruits); // output: ['🍊', '🍎']
console.log(shifted); // output: 🍌

These methods are particularly useful when dealing with stacks or queues. A stack is a data structure that allows you to store and retrieve data in a last-in, first-out (LIFO) order. A queue is a data structure that allows you to store and retrieve data in a first-in, first-out (FIFO) order.

Summary

In this article, we have gone over the most important JavaScript array methods. Knowing them can save us some time and in some cases even boost the performance of our code.

I hope that today you learned some new arr y methods, or refresh old concepts which you can use for your next project.

Do you know any other interesting JavaScript array methods? Let me know in the comments below.

Happy coding!

Newsletter

Subscribe to my weekly newsletter for developers and builders and get a weekly email with relevant content.

How to Clear Your NPM Cache?

Juan Cruz Martinez — Wed, 08 Feb 2023 21:01:23 +0000

We all love NPM, right? It’s the go-to package manager for all our JavaScript projects, but sometimes a little maintenance is required. It’s possible over time, NPM can become clogged with packages and files that are no longer needed occupying space on your disk, or sometimes some of those files go rogue and corrupt the cache.

When you need to, there’s an easy way to clean the NPM cache and in this article we will explain the why and how of cleaning up the NPM cache.

if you are in a rush just run npm cache clean --force, if not keep on reading to learn more.

What Is the NPM Cache?

The NPM cache is a collection of packages stored on your computer used by the Node Package Manager when installing new packages. This cache helps speed up the installation process since it doesn’t need to download the same packages repeatedly. The cache also allows NPM to track what extensions, files, and packages your computer has installed.

Unfortunately, this cache folder can get cluttered over time because NPM regularly updates old packages or installs new ones. This clutter can cause issues with installing new packages since it may not recognize what files are already installed on your machine.

Should You Clean the NPM Cache?

Let me start by saying that it is not recommended to clean the NPM cache unless you are facing errors due to data corruption issues or simply trying to free up disk space. NPM is pretty good at handling the cache, and if something is odd, it will try to fix it automatically or let you know of any possible corruption.

Why Clear the Npm Cache?

Here are a few reasons why you may want to clean up your NPM cache:

To free up disk space.
To get rid of the “Please run npm cache clean” error.
To fix libraries that didn’t download correctly.
To reinstall libraries free of cache (not sure why you would, though).

How to Clean the NPM Cache?

Cleaning up the NPM cache is simple and only requires one command:

npm cache clean --force

This command will delete all the data stored in the NPM cache, including any outdated versions of packages. Note that it’s important to use the “–force” flag when running this command, as it ensures all data is deleted, even if there may be errors because of cache corruption or others.

What Is Npm Cache Verify?

npm cache verify is a command that verifies the integrity of all installed packages in the NPM cache. It verifies the contents of the cache folder, garbage collecting any unneeded data, and verifies the integrity of the cache index and all cached data.

How to run it?

npm cache verify

Is Deleting the NPM Cache the Same as Deleting the Node_modules Folder?

No, deleting the NPM cache is different from removing your node_modules folder from your project. The NPM cache is global for your computer, whereas the node_modules folder is stored within each project. If you just remove the node_modules folder and install all packages again, you could still be getting those packages from the NPM cache, and cleaning the NPM cache, won’t affect your project’s libraries.

Summary

NPM cache is an important part of the NPM package manager that helps speed up installation processes and keeps track of what packages are installed on your machine. Cleaning the NPM cache can help free up disk space, fix corrupted libraries, and save you from running into “Please run npm cache clean” errors.

It’s not recommended to clean the NPM cache unless you really have to, but if you ever need it, now you know how.

Thanks for reading!

Newsletter

Subscribe to my weekly newsletter for developers and builders and get a weekly email with relevant content.

The Importance of Creating Multiple Streams of Income as a Freelancer

Juan Cruz Martinez — Wed, 01 Feb 2023 09:22:21 +0000

Every new freelancer has a vision of what freelancing will be like. This vision usually includes the optimal project and the perfect client, bringing in the right amount of money.

And when you start, you will often only have one or two different income streams, usually coming from your first client. It could be a short-term web-design project. Or, it could be an ongoing support agreement with a business.

This is great, but a freelancer who only has one client or one project isn’t a freelancer. They just have a part-time job. If this is all you want, that is fine.

But, if you want to grow your business and make this freelancing life work for you, you soon realize that multiple income streams are essential for long-term success.

Multiple income streams can mean many things, like having several clients, doing varied work, or investing in different lines of business.

There’s a difference between a new freelancer specializing in web design and an experienced, diversified freelancer.

The new freelancer has two monthly contracts to manage - hosting, providing simple site updates, and troubleshooting if something goes wrong. At $200/client, this is a great start.

But this freelancer is in a precarious situation. What if one (or both) of the clients decides to go in another direction? What does the freelancer then do? How do they compensate for lost revenue? How do they gain more clients? How do they keep moving their business forward?

In this article, I want to remind you why generating multiple income streams is essential for success as a freelancer and then explain how you can generate multiple income streams.

So, why do you need multiple income streams to succeed at freelancing?

Let me give you 5 reasons to consider:

You Gain Stability.

Multiple income streams mean you have income flowing in from various avenues. So, if one avenue dries up, more money keeps flowing in. You are less vulnerable to periods of stagnation or economic instability.

You have to remember that freelancing is an ever-changing business. Technology is always changing. Clients’ expectations are changing. The economy is changing. Jobs come and go.

Pivoting as a freelancer is just the nature of the beast. And it’s easier to pivot when you have the financial backing to do so because you aren’t so vulnerable to slight industry changes or the whims of one client.

Feeling financially stable is key to having peace of mind. You’ve left a reliable 9-to-5 job with paid vacation days, sick days, and a steady paycheck for the unpredictable world of freelancing.

So you have to create the financial stability you once enjoyed by diversifying and creating multiple income streams. There is nothing quite as valuable as your peace of mind.

You Enjoy Freedom.

Along with peace of mind, the financial stability of multiple income streams allows you to enjoy more freedom.

No one is paying you for sick days. No one is giving you permission to take a paid vacation. You are in charge of your own time and time off.

If you have created many and varied ways to make money, you can afford to take time off.

When your child gets sick, you can take care of him without worrying that you’re not actively creating money because you have already set up avenues to continue making money, even when you’re not frantically working at your computer.

When you need a mental health break, you can afford to take a vacation or put work on hold to prioritize your well-being because you know that the money will keep flowing in through multiple contracts you’ve acquired.

Freelancing is awesome because it can afford you the freedom you crave if you’ve set up your freelancing effectively.

You Have Greater Control.

Because you’re not solely reliant on one client, project, or gig, you have greater control over what clients you want to work with, what projects you want to work on, and how you want to work.

The more varied your income streams are, the more control you have over your freelancing business. You can spread the revenue you generate across multiple projects, clients, and services.

You can afford to say no to the types of client who aren’t a good match for you.

You can pick and choose which projects are really worth your time and effort.

You can decide in which direction you want your freelancing business to go.

You aren’t constrained because you’re too worried about losing valuable income or losing your only client. Multiple streams of income allow you to invest your time, talent, and resources in ways that will realize the freelancing vision you have.

You Realize More Opportunities.

The reality is that the more you diversify and create varied income streams, the more opportunities come your way. It’s sort of like the “snowball effect.”

As you take on more clients, your name and reputation spreads to new clients. You gain those valuable referrals.

As you diversify your services, you attract more businesses and clients who need those services.

As you increase your visibility, you can expand your networking and forge potential partnerships with promising revenue.

Soon, new opportunities are coming your way, along with new income streams. Your freelancing business and your bottom line are growing.

Suddenly, you can free up time and resources to explore new avenues of freelancing, gain new skills and experience, and set yourself up for success.

You can even take some calculated risks you wouldn’t have dared with limited resources or income streams.

This leads me to why you should have multiple income streams.

You Experience Growth.

You need multiple income streams to effectively grow your business.Tweet this

You need to decide your end goals. You need to decide if you are actively trying to grow a business that will support the lifestyle you envision.

If you’re just supplementing your 9-to-5 income, then maybe focusing on one client or project at a time works for you. And that’s great.

But if you’re looking to leave the 9-to-5 grind behind and create a new life through freelancing, consistent and dependable growth is key to making that new life happen. And multiple income streams are the key to making growth happen.

So, now that we understand why it’s so important to create multiple streams of income, we come to this question:

How Do You Successfully Create Multiple Income Streams?

Again, let me give you four suggestions:

The simplest solution is to add more clients.

Adding additional clients usually requires no new skills, but it does require the knowledge and effort needed to generate leads and referrals.

If you’ve been with a client for some time and it seems to be going well for both of you, don’t be shy in letting them know you are growing your business and in asking them to refer you.

Word of mouth is one of the best recommendations you can have, and you can incentivize existing clients to recommend you by offering a one-time discount for every new client they bring your way.

Usually, your work will speak for itself. People are always networking. Happy clients will spread the word about the value that you bring to their business.

When new clients contact you, be ready to take them on so that you can begin to add to your income streams.

Diversify your services

As a freelancer, you have quite some flexibility in which areas you expand your services; if you are doing web development and you have design skills, you can bundle those in the package or sell them as individual services. Or perhaps you have experience and like writing content that can be an excellent addition to your portfolio.

Broadening your services can help you diversify your income streams and generate a more stable and future-proof business, but be careful to overdo it and lose focus on what your real goal as a freelancer is.

If you would like some ideas for inspiration, check out my article on side gigs to make money as a developer.

Consulting

Consulting is an excellent way to increase your income without handling the full project. You will provide advice or feedback in a certain area of expertise, and that’s it. This keeps your workload manageable while still allowing you to help others and get compensated for it.

Consulting can be very rewarding since you are paid for your knowledge and experience. It’s a great way to start building relationships with potential clients and exploring new opportunities.

Provide tech support/digital integration.

More and more of every business requires the integration of different tools and platforms, which are always changing and improving.

Inventory management connects to online ordering, connects to POS systems, connects to automated postage services, etc.

Many business owners don’t have the time or knowledge to link these pieces together and streamline their business.

Especially when working with a client doing web consultations or web-design, you could offer additional services around building and maintaining interconnected frameworks, and business processes.

Time is money, right? Explain how this service will add value to their business by automating essential components that will run without them having to think about it. They’ll be more willing to pay you if you can show them how you can save them valuable time and a lot of headaches.

Conclusion

Diversification and creating multiple revenue streams are essential for continued growth, peace of mind, and stability as a freelancer.

To create varied streams of reliable income, you may need to expand your client base, learn marketable skills, or offer new services.

But the growing pains are worth it when you begin to experience the freedom of a successful freelancing career that affords you the lifestyle you’ve always dreamed of.

Generating and maintaining multiple income streams is the key to securing this freedom.

Thanks for reading!

Newsletter

Subscribe to my weekly newsletter for developers and builders and get a weekly email with relevant content.

The Types of Clients You’ll Get

Juan Cruz Martinez — Sun, 29 Jan 2023 22:04:04 +0000

Learn about the seven types of customers you may encounter in your professional life and how to work with them.

Continue reading on Medium »