DEV Community: Nicky Christensen

I Audited 50 Websites. Here's What Was Silently Broken

Nicky Christensen — Sat, 04 Apr 2026 09:07:51 +0000

I ran deep checks on 50 production sites. 23 had silent failures their uptime monitors missed. Here's every failure type, why it happens, and how to check yourself

1. Expired or Misconfigured SSL Certificates (8 sites)

The most common failure — and the most avoidable.

Eight sites had SSL issues. Three had certificates that had expired within the last 30 days. Two had incomplete certificate chains (missing intermediate CA), which meant the site worked in Chrome on desktop but threw security warnings in Safari and on mobile devices. The remaining three had certificates that didn't match the domain — likely from a server migration or load balancer change where someone forgot to update the cert.

Why uptime monitors miss this: Most ping-based monitors hit the IP address or follow the first redirect. They don't validate the full certificate chain, check expiry, or verify that the certificate matches the domain. The server responds with 200, so the check passes.

How common is this? According to Keyfactor's 2024 PKI report, 88% of companies experienced an unplanned outage due to an expired certificate in the past two years. Microsoft Teams went down for three hours in 2020 because someone forgot to renew an auth certificate. Epic Games had a 5.5-hour outage from an expired wildcard cert.

How to check yourself:

# Check certificate expiry date
echo | openssl s_client -servername yoursite.com -connect yoursite.com:443 2>/dev/null | openssl x509 -noout -dates

# Check certificate chain completeness
echo | openssl s_client -servername yoursite.com -connect yoursite.com:443 2>/dev/null | grep -E "verify return|depth"

# Check if cert matches the domain
echo | openssl s_client -servername yoursite.com -connect yoursite.com:443 2>/dev/null | openssl x509 -noout -subject -issuer

If notAfter is in the past, your visitors are seeing browser warnings. If the chain verification fails, mobile users are getting blocked.

2. Stale CDN Content After Deploys (5 sites)

Five sites served HTML or assets that were one or more deployments old. The page loaded. It looked fine to a quick glance. But it was yesterday's version — including a known bug that the team thought they'd already fixed.

How it happens: The origin server has the new content, but CDN edge nodes are serving cached versions. Cache invalidation either failed, wasn't triggered, or hasn't propagated to all edge locations. This is particularly common with Cloudflare, CloudFront, and Vercel's edge network when cache-control headers aren't set correctly.

How nasty is it? A 2023 Catchpoint study of 150+ major e-commerce sites found that over 70% of "mysterious" production bugs reported by users were actually stale or inconsistent cached content. The website was working — but the CDN was serving yesterday's reality. As recently as December 2025, a Shopify merchant reported their CDN was serving mismatched product images in search results for weeks.

One of the sites I checked was serving HTML from 3 deploys ago to users in Europe, while US users saw the current version. The team had no idea because they were all based in the US.

How to check yourself:

# Generate a SHA-256 fingerprint of your page content
curl -s https://yoursite.com | sha256sum

# Compare with a different region (if you have a VPN)
# Or run it again after a deploy — if the hash doesn't change,
# your CDN is serving stale content

# Check cache headers to see if CDN is even invalidating
curl -sI https://yoursite.com | grep -iE "cache-control|x-cache|age|cf-cache"

If the age header shows a high number after a fresh deploy, or x-cache says HIT when you expected new content — your users aren't seeing what you shipped.

3. JavaScript Bundles That 404'd (4 sites)

Four sites had their HTML load fine (200 OK), but the JavaScript files it referenced no longer existed on the server.

How it happens: A deployment pushes new HTML that references app.3f8a2c.js, but the CDN edge node still serves the old HTML pointing to app.9d1b4e.js — which was deleted in the new release. This is the evil cousin of stale CDN content: the HTML is stale, but the assets it points to have been purged.

The result: a blank white page. Or a page that looks half-loaded — the header renders from server-side HTML, but nothing interactive works because the client-side JavaScript never boots.

This is extremely common with SPAs. Netlify's support forums have hundreds of threads about it. AWS Amplify has a known issue where NextJS static pages stop working after deploy because JavaScript files return 404. It happens any time users have cached HTML from a previous deploy that references JS bundles that no longer exist.

How to check yourself:

# Fetch the HTML and check every script source
curl -s https://yoursite.com | grep -oP 'src="[^"]*\.js"' | while read -r src; do
  url=$(echo "$src" | grep -oP '"[^"]*"' | tr -d '"')
  if [[ "$url" != http* ]]; then
    url="https://yoursite.com$url"
  fi
  status=$(curl -o /dev/null -s -w "%{http_code}" "$url")
  echo "$status $url"
done

If any of those return 404, your users are seeing a broken page while your uptime monitor shows green.

4. Redirect Chains and Loops (3 sites)

Three sites had redirect chains — sequences of 301/302 redirects that either took too many hops or looped entirely.

The worst example: A site redirected HTTP → HTTPS → www → non-www → HTTPS again, creating a loop. Every visitor hit this loop. The browser gives up after 20 redirects and shows ERR_TOO_MANY_REDIRECTS. The uptime monitor? It only followed the first redirect, got a 301, and marked it as "up."

How it happens: Conflicting redirect rules between the web server (nginx/Apache), the CDN (Cloudflare page rules), and the application (.htaccess or middleware). Someone adds a "force HTTPS" rule in Cloudflare and in nginx, or a "redirect to www" rule in the CDN that conflicts with a "redirect to non-www" rule in the application.

How to check yourself:

# Follow all redirects and show the chain
curl -sIL https://yoursite.com 2>&1 | grep -iE "^(HTTP/|location:)"

If you see more than 2 redirects, something is misconfigured. If you see the same URL appear twice, you have a loop.

5. WordPress Plugin Conflicts / White Screen of Death (2 sites)

Two WordPress sites rendered a completely blank page — the infamous White Screen of Death (WSOD). The server returned 200 OK with an empty HTML body. Both had recently updated plugins.

How common is this? It's one of the most searched WordPress errors on the internet. It happens when a plugin update introduces a PHP fatal error, exceeds the server's memory limit, or conflicts with another plugin or the active theme. The server doesn't crash — PHP catches the fatal error and returns an empty response with a 200 status code.

The specific cases I found: One site had updated a page builder plugin (Elementor) that conflicted with a custom theme. The other had a WooCommerce extension that exceeded the PHP memory limit after an update. Both sites had been showing a blank page for over 48 hours without the site owners knowing — because their uptime monitor said the server was responding fine.

How to check yourself:

# Check if the page has any actual content
content_length=$(curl -s https://yoursite.com | wc -c)
echo "Response body: $content_length bytes"
# If this is under 500 bytes for a full page, something is very wrong

# Check for PHP errors in the response headers
curl -sI https://yoursite.com | grep -iE "x-php|x-powered|content-length"

6. Mixed Content Blocking (1 site)

One site served its main page over HTTPS but loaded images and a font file over HTTP. Modern browsers block mixed content silently — no error page, no console warning for the user. The images just don't load, and the font falls back to a system font.

How it happens: Usually after an SSL migration. The site moves to HTTPS, but some hardcoded http:// references remain in the database (common in WordPress), in a template file, or in a third-party embed. It can also happen when a CDN or image hosting service changes its URL scheme.

How to check yourself:

# Find HTTP resources on an HTTPS page
curl -s https://yoursite.com | grep -oP '(src|href)="http://[^"]*"'

If that returns anything, those resources are being blocked by the browser and your visitors aren't seeing them.

The Pattern

Here's what all 23 failures had in common:

The server was up. The HTTP status code was 200. The uptime monitor said green.

Traditional uptime monitoring checks one thing: did the server respond? That's a useful signal — but it's the minimum signal. It tells you the infrastructure is alive. It tells you nothing about whether the application works.

And the numbers back this up. 85% of website bugs are first detected by users, not by monitoring tools. Not because monitoring doesn't exist — but because it's checking the wrong thing.

The gap between "server responds" and "site works for users" is where all 23 of these failures lived. And it's exactly the gap that most teams don't monitor.

What Real Monitoring Looks Like

After running this audit, the checks that actually caught problems were:

SSL certificate validation — Is the cert valid, unexpired, chain complete, and matching the domain? Not just "does the connection work."
Asset integrity checks — Does every script and stylesheet referenced in the HTML actually load with the correct status code?
Content fingerprinting — Is the content what you expect, or is the CDN serving a stale version? A SHA-256 hash of the response body catches silent content drift.
Redirect chain resolution — Does the URL resolve cleanly in ≤2 hops, or does it loop?
Response body validation — Is the page actually rendering content, or is it a 200 OK with an empty body?
Multi-region checks — A site can be broken in Frankfurt but fine in Virginia. Single-location checks miss regional CDN failures entirely.

This is what I built Sitewatch to do — run all of these checks continuously, from multiple regions, and alert when something breaks at the application layer, not just the infrastructure layer. Free for 1 site, no credit card.

Quick Audit Checklist

You don't need a tool to start. Run these against any production site right now:

Check SSL certificate expiry and chain with openssl s_client
Verify every <script> and <link> resource returns 200
Follow the full redirect chain with curl -sIL — max 2 hops, no loops
Hash the response body with sha256sum before and after a deploy
Check response body size — under 500 bytes means something is wrong
Repeat from a different geographic location

If any check fails — you just found a bug your uptime monitor has been ignoring.

Have you found similar silent failures in production? Drop a comment — I'm collecting these for a follow-up post.

My Claude Code Setup: Skills, Agents, and the Config File That Changed Everything

Nicky Christensen — Sat, 28 Mar 2026 18:43:36 +0000

CLAUDE.md — The Non-Negotiable

A CLAUDE.md file in your project root. Claude Code reads it at the start of every session. It's onboarding docs for your AI pair programmer.

What goes in it: your stack (specific versions, not just "Vue"), file structure, naming conventions, component patterns, error handling approach, available commands.

Without it, Claude guesses. With it, Claude follows your architecture.

Keep it under 200 lines. Move detailed docs to separate files and reference them with @filename.

If you do one thing from this post, create this file. 30 minutes of work. Hours saved per session.

Skills — Load Expertise, Not Context

Skills live in .claude/skills/. They're markdown files that give Claude specialized knowledge for specific tasks — but only when relevant.

The difference from CLAUDE.md: CLAUDE.md loads every session. Skills load on demand. You don't bloat your context with PDF generation instructions when you're writing API routes.

The real power: write skills for your own domain. I wrote one for my product's detection rule format. The exact structure, fields, validation patterns, naming conventions. Now every new rule comes out perfectly structured. No re-explaining. No drift.

Community skills and plugins exist too. The ecosystem is growing fast.

Subagents — Parallel Work

Claude Code can spawn subagents — independent processes with their own context and tools.

Building a feature but also need to refactor tests? Kick off a subagent for the tests. It works in a git worktree (isolated copy of your repo), so zero conflict risk. You keep working on the feature.

I use them for:

Parallel code reviews
Running test suites while developing
Research tasks that need deep exploration
Verification passes on generated code

Subagents access skills too. So a subagent loads domain knowledge, does its work, returns results. You're orchestrating a team, not managing a chatbot.

Plan Mode — Think Before You Generate

Start in plan mode for anything non-trivial. Describe what you need. Let Claude explore the codebase, identify touch points, produce a plan. Review the plan. Then switch to implementation.

This prevents the most expensive failure mode: generating code that solves the wrong problem. Planning costs minutes. Rewriting costs hours.

I document the plan in a separate file that Claude references during implementation. Every prompt becomes a step against a plan, not an open-ended request.

The Setup in Practice

Here's what this looks like end-to-end:

CLAUDE.md tells Claude my stack, conventions, patterns
Plan mode produces a reviewed implementation plan
Skills load domain-specific knowledge for the task
Focused prompts implement one step at a time against the plan
Subagents handle parallel work without context switching

Each piece is useful alone. Together they compound. Claude Code goes from "generates code" to "follows my development process."

What I Shipped With This

I built Sitewatch with this exact workflow — a monitoring platform that detects when websites return 200 OK but are actually broken for users. Broken JS bundles after deploys, MIME type mismatches, stale CDN content, redirect loops. The failures uptime tools miss.

Claude Code wrote ~60-70% of the codebase. The detection logic — the brain of the product — came from me. The setup above is how I maintained quality while moving at that speed.

Free tier for 1 site if you want to try it: getsitewatch.com

TL;DR

Stop prompting harder. Start setting up better.

Create a CLAUDE.md — today
Write a skill for your most common task
Make a slash command for your most repeated workflow
Use plan mode for anything bigger than a single file
Use subagents when tasks can run in parallel

The developers getting the most out of Claude Code aren't the best prompters. They're the ones with the best setup.

That about wraps it up!

AI Wrote 70% of My Production Codebase. Here's Why That Actually Worked.

Nicky Christensen — Fri, 27 Mar 2026 11:44:50 +0000

I used Claude Code to build Sitewatch — a monitoring platform that catches when websites return 200 OK but are actually broken. Not a side project. A real SaaS, in production, with paying users.

AI wrote roughly 60-70% of the codebase. Here are the things I wish someone had told me before I started.

1. Planning matters more than prompting

This is the single biggest lesson and the one I almost learned too late.

Early on, I'd open Claude Code and start prompting. "Build the check scheduling system." "Add retry logic." "Create the alerting pipeline." And it would. Working code, every time. The problem showed up three weeks in — I had a codebase full of features that each worked individually but didn't fit together. Different error handling patterns. Inconsistent data models. State flowing in three different directions.

I had to stop and rewrite the architecture. That cost me more time than if I'd planned it from the start.

Now my workflow is: plan first, prompt second. I think through data models, module boundaries, API surfaces, and error conventions before Claude Code writes anything. I write it down as a spec. Then I hand it pieces of the spec, one at a time.

The difference is enormous. Same tool, completely different outcomes.

2. The first 80% takes minutes. The last 20% takes your brain.

This is the productivity pattern nobody warns you about.

I'd describe a feature — "add multi-region check support with independent retry confirmation per region" — and Claude Code would produce a working implementation in minutes. Maybe 80% done. The remaining 20% — edge cases, failure modes, integration with existing code, the weird thing that happens when two regions disagree — that still required my experience.

That 80/20 split is incredibly valuable. But you have to know it's coming. If you assume the first output is done, you'll ship bugs.

3. Establish your patterns early — then Claude Code follows them

Once I had a consistent way of structuring API handlers, formatting errors, writing composables, and handling state — Claude Code replicated those patterns reliably. It picks up conventions from your codebase and follows them.

But it has to see them first. If your first few files are inconsistent, Claude Code will be too. Build the first few things yourself with intentional patterns. Let the AI learn from your codebase. Then it scales those patterns across everything else.

This is the secret to a Claude Code codebase that feels coherent instead of stitched together.

4. Domain expertise can't be delegated

Sitewatch needs to understand HTTP at a level most developers never think about. How CDNs rewrite MIME types. Why a 200 OK can mean "your site is completely broken." When a redirect chain is looping only for specific cookie states. Why the same page can return different content from different edge locations.

Claude Code could write the plumbing around all of this. But the actual detection rules — the logic that makes the product valuable — came from my head. That's not a limitation of the tool. That's the nature of domain expertise. AI handles the how. You provide the what and why.

5. Test generation is the most underrated feature

Everyone talks about Claude Code writing features. Nobody talks about how good it is at writing tests.

I'd point it at existing code and say "write comprehensive tests for this module, including edge cases." And it would generate tests I hadn't thought of. Race conditions I'd missed. Boundary values I'd overlooked. Error paths I'd assumed were unreachable.

For a solo builder who knows they should test more but never has time — this was the single biggest quality improvement.

6. Review intensity should scale with stakes

I don't hold Claude Code back from anything. It handles more than you'd expect, including complex logic. But my review process isn't uniform.

Boilerplate scaffolding? Quick scan. Database migrations? Check the schema. API route for a new feature? Read it carefully. Core detection logic that determines whether a site is flagged as broken? Line by line, every time.

The tool is good enough for everything. Your review discipline needs to match the risk.

7. Shipping faster means you need to verify faster

This one surprised me.

When you build with Claude Code, your development speed increases dramatically. Features that would have taken a week take days. But your production failure rate doesn't change — you're still deploying to the same CDNs, the same edge networks, the same infrastructure that's always been unpredictable.

So you ship more code, more often, to the same fragile production environment. Without better production verification, you're just creating more opportunities for things to break silently.

This is actually what motivated me to build Sitewatch in the first place. The faster I shipped, the more I needed to know — immediately — when something broke. Not "the server returned 200." Whether the site actually works.

What I built with it

Since the whole article is about building Sitewatch with Claude Code — here's what it actually does.

Sitewatch detects when your website returns 200 OK but is functionally broken. The kind of failures that traditional uptime monitors completely miss:

Your deploy goes through but your CDN serves stale HTML referencing deleted JavaScript bundles — blank page, green dashboard
Your JS file gets served with Content-Type: text/html and the browser silently blocks it — app looks loaded, nothing works
A redirect loop kills the page but monitoring only sees the first 301
Your CDN returns a branded error page with 200 OK instead of your actual content

What Sitewatch does:

Verifies that assets your HTML references load with correct status and MIME type
Follows redirect chains to completion
Fingerprints content to detect silent changes
Checks from multiple regions to catch CDN edge divergence
Classifies root cause with stack-specific fix guidance

For developers: catches the deploy failures your uptime tool misses. Free tier, one site, 30 seconds to set up.

For agencies managing 25-100+ client sites: continuous verification across all sites, multiple regions, root cause classification. Stop finding out from client emails.

Pricing: Free (1 site) · $9/mo (25 sites) · $19/mo (100 sites)

Give it a try →

That about wraps it up! If you found this useful, leave a comment or connect with me on Twitter | LinkedIn or visit my website.

[Boost]

Nicky Christensen — Fri, 27 Mar 2026 09:03:07 +0000

Sitewatch

Mar 27

Your CI Is Green. Your Site Might Not Be.

#webdev #devops #monitoring #startup

Comments

6 min read

I Built a Monitoring Tool Because Uptime Checks Kept Lying to Me

Nicky Christensen — Thu, 26 Mar 2026 14:18:02 +0000

If you deploy sites to Netlify, Vercel, Cloudflare Pages or pretty much any modern platform — you've probably set up some kind of uptime monitoring. Ping every minute, get an alert if the server doesn't respond. Pretty standard stuff.

I had the same setup across all my sites. And for a long time, I thought I was covered.

I wasn't.

The Problem

A few months back I pushed an update to one of my Nuxt apps on Netlify. Build passed, deploy preview looked fine, dashboard showed green. I moved on.

Turns out the site was broken for hours. Not down — the server was responding just fine. 200 OK on every request. But the JavaScript bundle the page needed wasn't loading, so the entire app was a blank page.

Here's what happened: the new deploy generated fresh hashed bundles. main.c8d13.js replaced main.a4f2c.js. But some CDN edge nodes were still serving the old HTML, which referenced the old filename. Browser tries to fetch main.a4f2c.js, gets a 404, and nothing renders.

My uptime monitor? Green the entire time. Because the HTML document loaded. 200 OK. Job done, as far as it was concerned.

It Keeps Happening

Once I started paying attention, I found this happens a lot more than you'd expect:

MIME type mismatches — Your JS file gets served as text/html by the CDN. Browser silently refuses to execute it. No console error you'd notice unless you're specifically looking. I had this on one of my sites behind Cloudflare for days without knowing.

Redirect chains that loop — CDN redirect + origin redirect + app redirect that conflict with each other. Browser hits the hop limit and gives up. Uptime tool sees the first 301 and moves on.

DNS still pointing at old infrastructure — After a migration, a subdomain resolves to the old origin. It responds with stale content from months ago. Technically "up." Practically useless.

All return 200. All invisible to standard monitoring.

Why I Built Sitewatch

I looked around for tools that caught this stuff. Most uptime monitors check if the server responds — and that's it. Some offer headless browser checks with Puppeteer, but they're slow, expensive, and fragile at any real scale. Not great when you're watching a bunch of sites.

What I needed was something in between. Goes deeper than a status code check, doesn't require a full browser session. Catches the broken deploy, the MIME type issue, the redirect loop — automatically.

So I built Sitewatch.

What It Does

Instead of just checking if your server responds, Sitewatch verifies whether your site actually works:

Asset verification — It fetches your page, parses the HTML, finds your JS and CSS bundle references, and checks each one. Correct status code? Correct MIME type? Actually loadable? If your HTML references a script that 404s or gets served as text/html, you get alerted.

Full redirect chain resolution — Follows redirects all the way to the final destination. Catches loops, unexpected landings, and chains that time out.

Content fingerprinting — Generates hashes of your page content and tracks them over time. If your homepage suddenly returns completely different content (stale cache, CDN error page that returns 200), the fingerprint shift triggers an alert.

Multi-region checks — CDN failures are often edge-specific. Your site works from Europe but serves broken assets in Asia. Sitewatch checks from multiple locations.

Confirmation before alerting — Uses a retry model before firing alerts. No 3am wake-ups because of a transient CDN blip.

It also classifies the root cause — infrastructure, deploy artifact, DNS, CDN config — so you know where to look instead of just knowing "something broke."

Some Technical Decisions

A few choices that might be relevant if you've thought about building something similar:

No headless browser. It's tempting because it's "real" rendering, but it doesn't scale well. Sitewatch parses HTML and makes targeted follow-up requests for critical assets. Gets you the meaningful signal without the overhead.

Stack detection. Different frameworks break differently. A Nuxt app has different failure patterns than a WordPress site or a Rails app behind Nginx. Sitewatch detects the tech stack from response headers and adjusts what it checks for.

Alert deduplication. If the same issue persists across checks, you don't want repeated alerts. Content fingerprints with a cooldown window — you get notified when something breaks and again when it's resolved, not every 5 minutes in between.

Try It

If you're running sites on modern deployment platforms — especially if you're managing multiple — this is a blind spot worth covering.

There's a free tier for one site. Takes about 30 seconds to set up: getsitewatch.com

That about wraps it up! If you found this useful, I'd love to know — leave a comment or connect with me on Twitter | LinkedIn or visit my website.

7 Habits Of Highly Effective Developers

Nicky Christensen — Sun, 20 Feb 2022 13:51:11 +0000

Practical advice for becoming more effective and productive

Have you ever heard of the book called The 7 Habits of Highly Effective People? It's a book written by Stephen Covey which is about productivity and bettering yourself. You learn more about some key core set of values and ideas that you can develop to help solve personal and professional problems with an integrated and principle-centered approach.

If you haven't already read this book, I urge you to do so.

I believe all people can benefit from having positive habits, though today I will try and focus on why you as a developer can benefit from positive habits that enable you to be more effective as a developer and a human being.

I've been in the tech industry for around 15 years, and I know there's a lot of opinions on what makes a good developer.
This article isn't so much about being a good or great developer, but more about how to be an effective developer, how to get most of the day so you can become the best version of yourself and get more shit done!

Throughout my years in the industry, I've picked up a few things around what is making great developers highly effective.

Let's take a look at the habits.

1. Learn new things

To become a great and effective developer, you need to have a focus on always developing your own skillset. If you procrastinate, you will never become effective, nor great for that matter. Effective developers find solutions to problems with knowledge. Knowledge comes from experience and learning things, therefore, it's essential to keep your mind open for learning new things continuously.

2. Have a focus on being healthy

I'm a big fan of this habit. A good and healthy lifestyle will provide you with a much clearer mind and a lot more energy in you every day.

Studies show that living an unhealthy lifestyle where eating healthy and exercising is NOT a part of life, people are likely to be more prone to heart failures, vulnerable to obesity, suffer from tiredness, have a harder ability to absorb information, and are generally in the higher risk of getting sick.

Taking good care of body and mind with a healthy lifestyle will make you more effective and productive not only as a developer but as a human being in general.
Go for a run, go for a swim, take a trip down to the fitness club, think about what you eat. If you are not used to doing exercise, it might be hard in the beginning, but in the long run, you'll love it.

3. Has a focus on value, not problems

Effective developers focus on value, rather than on problems. There will always be bugs, issues, etc, but having the ability to and habit in trying to identify the things that bring the most value for the end-user will help you in being more effective. You might not be the most effective in the type of solving the most bugs, but the ones solved, are the bugs that bring the most value to the end-user, which will end the end be perceived as being most effective.

Take this for example:
A Customer wants a notification whenever the battery is drained. Why?

Solution: Notification service that can help prevent running out of battery

A good exercise for getting better at this is trying to make use of the 5 whys and incorporate this in your day-to-day. Learn more about the 5 whys here and here.

4. Don't over-engineer

Effective developers and people know when to apply which methodology to X problem. They always try to simplify things to be as understandable as possible and don't end up over-engineering a solution.

Good and effective projects are the ones with simplified implementations, easy to maintain, easy to understand.
A complex design that is over-engineered is very likely to lead to difficulties in implementing new functionalities. It makes maintenance a nightmare and turns seemingly simple code into a sh*tshow of complexity.

To overcome this, try not to write unnecessary code and always try looking for simple and elegant solutions. It will make you more effective and productive.

5. Involve yourself with smart people.

This habit is definitely not only limited to developers, but all effective people in general. If you want to be effective and great, you need to involve yourself around smart people. Look around the room you're in right now. Do you suspect you're the smartest person in it? If so, go find a different room. It will change your life.

Involving yourself around smart people will make you smarter. They make you better. They spark interest and introduce you to new concepts, ideas, culture, people, and much more. In short, they know where the good stuff is or how to help find it.
If you don't know where to start on this, I recommend you read this article from Leonard Kim: https://medium.com/the-mission/how-do-i-surround-myself-with-people-who-are-smarter-than-me-d26f9f25d12d

6. Be proactive

Effective developers always try to be proactive. A good idea is trying to be better at focusing on what is in your control, rather than what you can't control. Taking a proactive approach to things, and making other people aware. Put in an effort and use the necessary energy at becoming better at this.

An example of being proactive could be the following: Be Responsible for Great Requirements - Don't blame others for poor requirements. Instead, work with the team to fully analyze the requirements to ensure they are complete, accurate, and meet the needs of the customer. Take the responsibility it requires you to do, and help others. If you do this, you and the people around you will become more efficient.

7. Prioritizing the work

Prioritizing work & work effort is critical. You must prioritize the work that gives high business value. That is the ideal situation, right? Effective people are good at this, knowing which features give the highest business value, but can be done with low/minimal efforts (Time vs Business value)
You must apply effort to the most important things first, followed by less important things. For example, everyone will generally agree that creating reusable and easily maintainable code is important.

However, in an effort to do this, developers have a tendency to "gold plate/over-engineer". "Gold plating or over-engineering" is when a developer adds bells and whistles to the feature that were not asked for and can easily increase the complexity and estimated hours needed to deliver the work. Be very careful with this. This does not add that necessary value vs the time spent.

Was it a good investment doing the bells and whistles then? Probably not. You need to become good a prioritizing work, and also know the concept of business value vs time spent.

Having good habits in your every day can be very powerful. It will benefit not only you but everyone around you. I truly believe that incorporating good habits will make you more effective. It will help you excel as a person and a developer.
As Stephen Covey says in his book:

"I am not a product of my circumstances. I am a
product of my decisions."

Start today, Try challenging yourself as of today, start practicing these habits. It will be hard, but worth it. I am sure of it.
Check back in a year, and see for yourself how much development you have made as a person.

I would love to hear your thoughts and if you have any valuable habits that make you feel like an effective developer? Share your comment in the section below. If you like this article do pass it forward and share it with your friends and peers.

Thanks for reading and I hope you liked the article.

If you’d like to catch up with me sometime, follow me on Medium | Twitter | LinkedIn or simply visit my website (That is in Danish)

Thanks for reading and I hope you liked the article, if so, please help support me by hitting that clap button or subscribing.

Typescript Generics explained in 2 minutes

Nicky Christensen — Thu, 03 Feb 2022 20:20:12 +0000

TypeScript is powerful, it can make your code a lot more stable, readable, easier to refactor and so much more.

TypeScript has Generics which are super useful when wanting to write clean and reusable pieces of code. Generics offer a way for developers to create reusable code and it works in a way to make components work with any data type and not be restricted to a single data type.

Given that you are in this article, I’m expecting you already know the basics of TypeScript, and want to know more about Generics in TypeScript so I won't go deep into an explanation around TypeScript itself.

Consider the following code:

let courses = [];
const fetchCourseTemplates = async () => {
  isLoading = true;
  const companyId = '123';
  try {
    courses = await getAllDocuments(`course_templates/${companyId}/templates`);
    isLoading = false;
  } catch (e) {
    isLoading = false;
    throw new Error('Cant load templates: ' + e);
  }
};

The function we are calling will look like this:

// Our reuseable function to get data
export const getAllDocuments = async (collectionName: string) => {
  const documents = [];
  const querySnapshot = await getDocs(collection(db, collectionName));
  querySnapshot.forEach((doc) => {
    const data = doc.data();
    documents.push({
      id: doc.id,
      ...data
    });
  });

  return documents;
};

With the above code, you are fetching some data from an API, passing a parameter on where to fetch the data (In this case, a reference to a collection in Firebase). The data passed back from the function are stored in a variable. All good, right?

Not quite. You see, if you have a reusable function to fetch data from a collection, you never know which type of data you are actually getting back. Well, you may know now but TypeScript doesn’t.

Imagine you are using this function to retrieve all kinds of different documents from different places in Firebase, the data you get returned will most likely be different from time to time. So how do we make TypeScript happy?

Introducing Generics

Generics will help you in this case. You can extend the function to use generics, and when calling the function, you specify which type of data you are working with. This will make TypeScript understand.

Let’s take the above code and see how it would look using Generics.

let courses: Course[] = [];
const fetchCourseTemplates = async () => {
  isLoading = true;
  const companyId = '123';
  try {
    courses = await getAllDocuments<Course>(`course_templates/${companyId}/templates`);
    isLoading = false;
  } catch (e) {
    isLoading = false;
    throw new Error('Cant load templates: ' + e);
  }
};

The main difference here is in the await. You might notice the . This is basically me passing a type to the function, telling TypeScript what data the function should work with. Let's take a look at the next function

// Our reuseable function to get data
export const getAllDocuments = async <T>(collectionName: string) => {
  const documents: T[] = [];
  const querySnapshot = await getDocs(collection(db, collectionName));
  querySnapshot.forEach((doc) => {
    const data = doc.data();
    documents.push({
      ...data
    } as T);
  });

  return documents;
};

Notice after the async keyword, I do . This is me getting the type back I called the function with. Further down, you will see that the array I’m creating should be of the type I passed on (We passed Course). When we are returning, TypeScript now knows that I’m returning whatever type I provided. In our cases, it would return an array of courses, because we passed Courses as our type in the fetchCourseTemplates function.

That about wraps it up! I hope you understood the above.
Of course, there is a lot more to generics and many more use cases than what I just showed, but hopefully, it gave you a basic understanding and you can see why it is powerful.

If you’d like to catch up with me sometime, follow me on Medium | Twitter | LinkedIn or simply visit my website (That is in Danish)

TypeScript Interfaces Explained in 2 Minutes

Nicky Christensen — Sun, 30 Jan 2022 12:24:05 +0000

My first article on dev.to, Yay! In this article, I'll show you what an interface is and how to create and use interfaces in your own projects.

As you may already know, JavaScript is not a type-safe language per definition. To get that cool type safety, you need to use tools like TypeScript to help you out.
TypeScript is a superset of JavaScript that introduces new features and helpful improvements to the JavaScript language.

By using TypeScript in your codebase, you can easily spot or avoid errors early and get rid of errors in compilation time which is pretty awesome. At first glance, TypeScript can seem hard and scary, but once you’ve spent some time with it, I’ll bet you that you’ll really love it.

Interfaces

An Interface in TypeScript acts more or less like a blueprint for an object. It defines information about property names in objects and their values. This can help out the TypeScript compiler in validating your objects, so you don’t define objects in the wrong format.

You define an interface by using the interface keyword in a typescript file (.ts). Take a look at the following example:

interface Course {
  title: string;
  description: string;
  createdAt: Date;
  updatedAt: Date;
  price: number;
  currency: string;
  isActive: boolean;
}

With this, you have defined an interface which can act like a blueprint for an object:

const webCourse: Course = {
  title: 'Typescript Basics',
  description: 'A course about Typescript',
  createdAt: new Date(),
  updatedAt: new Date(),
  price: 10,
  currency: 'USD',
  isActive: true
}

In interfaces, you can also specify any property as optional by using the ? or by adding undefined as a value.

interface Course {
  title: string;
  description: string;
  createdAt: Date;
  updatedAt: Date;
  price?: number; //Optional
  currency: string | undefined; //Optional
  isActive: boolean;
}

This means you can now create an object without a price and currency in this example:

const webCourse: Course = {
  title: 'Typescript Basics',
  description: 'A course about Typescript',
  createdAt: new Date(),
  updatedAt: new Date(),
  isActive: true
};

You can also have interfaces that extend other interfaces which can be quite useful sometimes.

interface BaseCourse {
  title: string;
  description: string;
  createdAt: Date;
  updatedAt: Date;
  price?: number; //Optional
  currency: string | undefined; //Optional
  isActive: boolean;
}

interface FootballCourse extends BaseCourse {
  coach: string;
}

As you can see here, we have defined a BaseCourse and FootballCourse. FootballCourse extends from the BaseCourse allowing us to utilize the BaseCourse interface and then just extending it with whatever properties we need

Another cool thing is that you can define properties as readonly, meaning that if you create an object and later on try to overwrite the property, the typescript compiler will throw an error as you have defined it as readonly:

interface BaseCourse {
  readonly title: string; //Read only
  description: string;
  createdAt: Date;
  updatedAt: Date;
  price?: number; //Optional
  currency: string | undefined; //Optional
  isActive: boolean;
}

interface FootballCourse extends BaseCourse {
  coach: string;
}

This will throw an error:

const webCourse: FootballCourse = {
  title: 'Typescript Basics',
  description: 'A course about Typescript',
  createdAt: new Date(),
  updatedAt: new Date(),
  isActive: true,
  coach: 'Nicky Christensen'
};

webCourse.title = 'A new title'; //ERROR

If you’d like to catch up with me sometime, follow me on Twitter | LinkedIn or simply visit my website (That is in Danish)