Coder Legion - Recent posts tagged webdev-learning

Your Next.js redirect() Silently Does Nothing Because It's Inside a try/catch

Fri, 30 Oct 2026 10:08:42 +0000

A user fills in your form and clicks "Create post". The post is saved in the database. And the page shows "Could not create post".

They try again. Now there are two posts.

Nothing is wrong with your database. Your error handling caught something it was never supposed to catch.

The Code That Causes It

// app/actions.ts
'use server';

import { redirect } from 'next/navigation';

export async function createPost(formData: FormData) {
  try {
    const post = await db.post.create({
      data: { title: String(formData.get('title')) },
    });

    redirect(`/posts/${post.id}`);
  } catch (err) {
    return { error: 'Could not create post' };
  }
}

It reads perfectly. Save the post, go to its page, and if anything fails, return an error. A tidy, defensive pattern that you have probably written a hundred times in other frameworks.

Why It Breaks

In Next.js, redirect() does not return. It throws a special error, and the framework catches that error higher up and turns it into a redirect response.

That means your catch block receives it first. Your code swallows the redirect, returns { error: ... }, and the framework never sees it.

The same is true for notFound(), which also works by throwing. Both are written to stop execution immediately, which is why TypeScript treats them as functions that never return.

Why It Is Hard to Catch

The data is saved. The only visible symptom is a wrong error message, so it looks like a UI bug, not a logic bug.
It is inconsistent in your head. The same redirect() works fine outside a try, so you assume it is fine everywhere.
Your logs are confusing. If you log the caught error, you will see a strange error with a NEXT_REDIRECT digest and think something crashed.
It tempts you to retry. Users see an error, submit again and create duplicates.

Fix 1: Keep redirect() Outside the try Block

Only wrap the code that can genuinely fail, and redirect afterwards:

export async function createPost(formData: FormData) {
  let postId: string;

  try {
    const post = await db.post.create({
      data: { title: String(formData.get('title')) },
    });
    postId = post.id;
  } catch (err) {
    return { error: 'Could not create post' };
  }

  redirect(`/posts/${postId}`);
}

The try now covers only the database call. If it fails, you return the error. If it succeeds, execution continues to redirect(), which is outside any catch, so it can do its job.

This is the cleanest option, and it is the one I use by default.

Fix 2: Rethrow If You Must Catch Everything

Sometimes the redirect() sits deep inside a helper, and restructuring is awkward. Then let the framework's own errors pass through your catch. Newer Next.js versions provide a helper for exactly this:

import { redirect, unstable_rethrow } from 'next/navigation';

try {
  // ...work that may call redirect() or notFound() somewhere inside
} catch (err) {
  unstable_rethrow(err); // lets redirect/notFound errors continue upward
  return { error: 'Something went wrong' };
}

The name says it is not final, so check the documentation for the version you use. If it is not available in yours, structure your code as in Fix 1.

Fix 3: Do Not Use Catch-All to Control Flow

A broader habit helps here. A catch (err) with no check is a very wide net. Catch what you expect:

catch (err) {
  if (err instanceof DuplicateTitleError) {
    return { error: 'You already have a post with that title' };
  }
  throw err; // anything else is not yours to handle here
}

Rethrowing what you do not recognize means the framework's own signals, real crashes and bugs all reach the place that is meant to handle them.

Where Else This Bites

notFound() inside try. A missing record becomes your generic error instead of a 404 page.
Route handlers and Server Components. The same rule applies: any try/catch around a call that can redirect or 404 will swallow it.
.catch() on a promise. somePromise.catch(() => null) has the same effect if the promise's code calls redirect().
Wrapper functions. A helper like withErrorHandling(fn) that catches everything will break redirects in every function it wraps.

Quick Checklist

Situation	What to do
`redirect()` after a database write	Put the write in `try`, `redirect()` after it
`notFound()` when a record is missing	Call it outside the `try`, or rethrow
A shared error-handling wrapper	Make it rethrow framework errors
Unsure	Catch specific error types, rethrow the rest

The Rule

redirect() and notFound() signal by throwing, so a catch around them will eat the signal. Keep them outside try blocks, or rethrow what you do not recognize.

Quick audit: search your project for redirect( and notFound(. For each hit, look upward. If it sits inside a try, you have either a bug now or one waiting for the day the code path is used.

If you want a Next.js starting point where forms and actions are set up sensibly from day one, you can browse my templates on pixelanas.com.

Get the templates: https://pixelanas.gumroad.com

Have you ever shipped a form that showed an error after it had succeeded? Tell me in the comments how long it took you to find it.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Fix: useSearchParams() Should Be Wrapped in a Suspense Boundary (and Why It Only Breaks at Build

Sun, 18 Oct 2026 12:23:34 +0000

You add a small search box to your navbar. It reads the query string, so you reach for useSearchParams(). Everything works in next dev. You push, the deploy fails, and the build log says:

useSearchParams() should be wrapped in a suspense boundary at page "/about".
Read more: https://nextjs.org/docs/messages/missing-suspense-with-csr-bailout

Notice the page name. You did not touch /about. That detail is the whole story.

The Code That Triggers It

// components/SearchBox.tsx
'use client';

import { useSearchParams } from 'next/navigation';

export function SearchBox() {
  const searchParams = useSearchParams();
  const query = searchParams.get('q') ?? '';

  return <input defaultValue={query} placeholder="Search..." />;
}

// app/layout.tsx
import { SearchBox } from '@/components/SearchBox';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <nav>
          <SearchBox />
        </nav>
        {children}
      </body>
    </html>
  );
}

Nothing here looks wrong, and next dev agrees with you.

Why Only the Build Complains

At build time, Next.js tries to pre-render every page that does not obviously need request data into static HTML. That is the fast path, and it is the default.

But a static page is built once, before any visitor exists, so it has no query string. useSearchParams() needs one. Next.js handles this by bailing out of static rendering for that part of the tree: the component is skipped on the server and rendered in the browser instead.

The catch is how far the bail-out spreads. Without a Suspense boundary around the component, the nearest boundary is the page itself, which would turn the whole page into client-side rendering and quietly throw away the static HTML you were about to ship. Instead of letting that happen silently, the build fails and asks you to say where the boundary should be.

Dev mode renders every page on demand, so it never has to make that decision, which is why the error only shows up when you build.

Why It Hits Every Page at Once

I put the component in layout.tsx on purpose. A shared layout wraps every page, so one unguarded useSearchParams() in a navbar breaks the build for /, /about, /pricing and every other static route at the same time.

That is also why the error names a page you never edited. The problem lives in a shared component.

Fix 1: Wrap the Component in Suspense

// app/layout.tsx
import { Suspense } from 'react';
import { SearchBox } from '@/components/SearchBox';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <nav>
          <Suspense fallback={<input disabled placeholder="Search..." />}>
            <SearchBox />
          </Suspense>
        </nav>
        {children}
      </body>
    </html>
  );
}

Now only the search box is rendered in the browser. Everything else stays static HTML. The fallback is what visitors see until the client takes over, so make it the same size as the real component to avoid the layout jumping when it swaps in.

This is the fix to reach for first. It keeps your pages static and limits the client-side part to the one component that needs it.

Fix 2: Read the Params on the Server and Pass Them Down

If the value is only needed on one page, skip the hook entirely. Pages receive searchParams as a prop:

// app/search/page.tsx
export default async function SearchPage({
  searchParams,
}: {
  searchParams: Promise<{ q?: string }>;
}) {
  const { q } = await searchParams;
  return <SearchResults query={q ?? ''} />;
}

In Next.js 15, searchParams is a Promise, so it has to be awaited. Reading it marks that page as dynamic, so it renders per request instead of at build time. For a real search results page that is exactly what you want.

Fix 3: Force the Route to Be Dynamic

export const dynamic = 'force-dynamic';

This also makes the error disappear, but it does so by giving up static rendering for the route. Use it when the page genuinely depends on the request, not as a way to silence the build. On a marketing page it trades speed for nothing.

Which Fix When

Situation	Fix
Small interactive component reads the URL (navbar search, filters, tabs)	Suspense around that component
An entire page depends on the query string	Read `searchParams` in the page
The page really is per-request	`force-dynamic`

A Detail Worth Knowing About the Fallback

Whatever sits inside the Suspense boundary is client-rendered, so it will not be in the initial HTML. For a search input that does not matter. For content you want indexed, keep it outside the boundary. A fallback that does not match the final size also adds layout shift, which counts against your Core Web Vitals. I cover what those metrics measure in this plain-language guide.

The Rule

A client component that reads request-time data needs a Suspense boundary, so Next.js knows how much of the page to make dynamic. Put the boundary as close to the component as you can, and the rest of the page stays static.

I wrap every URL-driven component this way across my Next.js templates, so the production build never depends on where a navbar or filter bar ends up in the layout.

Get the templates: https://pixelanas.gumroad.com

Search your project for useSearchParams and check that every use sits inside a Suspense boundary, especially anything imported by layout.tsx. If you have hit a different build-only error, drop it in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Free upcoming accessibility education events in May

Wed, 06 May 2026 07:56:35 +0000

Funka Foundation: Accessible name – make it or break it

Friday, May 8, 13.30-14.00 CEST

Every button, link, and image on your interface must have an accessible name. Get it right and assistive technology users can find it, understand it, and activate it. Get it wrong and you have locked them out completely.

Trusted Tester Study Group 8: Sensory Characteristics and Contrast + Tables

Friday May 15, 4:00 – 5:00 PM (GMT+2)

Accessible does not equal Equitable: Real Human Experience vs Compliance

Thursday, 20 May | 10 AM AEST

In this webinar to celebrate Global Accessibility Awareness Day (GAAD), we explore the uncomfortable truth that a product can be fully compliant and still fail the people it’s meant to support. Drawing on real user experiences, we’ll expose the hidden friction that standards don’t capture, from cognitive overload to interaction fatigue and loss of confidence.

All the questions you wanted to ask during GAAD - but didn’t get the chance

Thursday 28th May 4pm UK-time

Global Accessibility Awareness Day (GAAD) on Thursday 21st May is always energising. But once the week is over, the momentum can fade. The questions people meant to ask never get asked. The practical “what do we actually do now?” conversations don’t happen.

So the week after GAAD Hassell Inclusion is hosting an open Q&A session with many seasoned accessibility experts, so you can ask the questions you need to make accessibility for 2026 not just for GAAD.

Upcoming Accessibility Events in March 2026

Wed, 25 Feb 2026 09:30:15 +0000

Trusted Tester Study Group

Together with the Google Developer Group Vienna, I am hosting a study group for the Trusted Tester certification. Watch the previous session recordings on YouTube. The dates and topics this month are:

Session 2: Auto-Playing and Auto-Updating Content + Flashing
Friday 6 March, 4:00 – 5:00 PM (GMT+1)
Session 3: Keyboard Access and Focus
Thursday 12 March, 6:00 – 7:00 PM (GMT+1)
Session 4: Forms
Friday 20 March, 4:00 – 5:00 PM (GMT+1)

Digital Accessibility Experts Live: Help! Accessibility is going in the wrong direction where I work. What can I do about it?

Thursday 26th March 4 PM UK-time

The global accessibility field grew in 2025. But many established accessibility initiatives in organisations also came under threat from the DEI backlash and economic budget cutting. 2026 is likely to be similar. So what can you do if your work comes under threat by decisions from your stakeholders?

AccessibleEU Latvia - People Living with Dementia. Accessibility, Solutions & Innovations. International Experience

Thursday 5 March 2026, 10:00 - 15:30 (EET)

This AccessibleEU event organised in collaboration with the Latvia Alzheimer’s Association and the Association of Disabled Persons and their Friends ‘Apeirons’, aims to raise awareness among society, including policymakers, service providers, and professionals, about how to better support people with dementia and other cognitive disorders.

Broadly defined accessibility plays a crucial role in enhancing the quality of life for these individuals - encompassing access to services, information, the built environment, and transportation.

Vienna Game Dev Meetup: No Diversity, No Games - How inclusion is no longer optional

Tuesday, Mar 3 · 6:30 PM to 9:30 PM CET Das Packhaus: Marxergasse 24, 1030 Wien, Österreich

The game industry has more talent, bigger budgets, and more powerful technology than ever before. Yet we’re stuck in sequels, safe bets, and recycled ideas. For decades, innovation was driven by hardware and graphics. That era is slowing down. Higher fidelity alone no longer creates novelty. Jack Gutmann argues that the next frontier of originality is perspective. Homogeneous teams create blind spots, predictable design, and cultural echo chambers, a form of creative inbreeding.

Vienna: Women Techmakers Conference “Break the Pattern”

Saturday 14 March, 9:00 - 15:00 TUtheSky (Getreidemarkt 9, 1060 Vienna)

Women Techmakers Vienna invites you to our International Women’s Day 2026 conference, themed “Break The Pattern.” Expect stories of non-traditional paths into tech and the moments women stepped up beyond their role to drive real change at work—improving processes, quality, leadership, and team culture. Come for practical takeaways, honest lessons, and new connections.

Accessibility Education Events in February 2026

Sun, 15 Feb 2026 12:05:30 +0000

Tuesday, Feb 17 · 11:30 AM to 1:00 PM CET

How does accessibility and internationalisation fit together?

Why does one need the other, how do they relate, what does this all mean in real life and what can we do in practice? The talk is about how internationalisation and accessibility belong together and how considering internationalisation can improve products in general and provide a good access point to create more accessible products.

RBI & SEBI Digital Accessibility Mandates: Why 2026 Is a Compliance Inflection Point for India’s Financial Services

Wednesday, 18 February | 12:00 - 1:00 PM (IST)

As RBI and SEBI place stronger emphasis on inclusive and accessible digital experiences, many banks, NBFCs, fintechs, and market participants are asking the same questions: Which guidelines apply to us? Where are the real risks? And how do we move forward without disrupting business priorities?

Zero Project Conference 2026

Wednesday 18th to Friday 20th

Live content from #ZeroCon26 will be streamed in an accessible manner via the conference platform and the Zero Project's YouTube channel. Session recordings will be made available after the conference.

Axe-Con 2026

Tuesday, February 24, through Wednesday, February 25, 2026

Topics of focus will include accessibility in development, accessibility in design, organizational success with accessibility, and a wildcard track. Talks at Axe-con will include case studies from enterprise companies leading in large-scale accessibility efforts, as well as best practices and updates from technology leaders around the world.

Document Accessibility in 2026

Thursday 26 February 4pm UK-time

Building on previous webinars from 2024 - Creating Accessible Documents – this webinar continues with Hassell Inclusion’s scoped model, by exploring what’s new, what’s changed, and what to prioritise in 2026 in the world of document accessibility.

Your Tutorials Are Lying to You. (Here's Why You Still Can't Build Anything Meaningful)

Tue, 18 Nov 2025 19:48:34 +0000

Alright, CODERLEGION, let's have a frank discussion. I'm an 8-year frontend engineer, primarily immersed in Angular, and I'm sharing my journey and lessons to genuinely inspire you. Today's hard truth:

You're likely stuck in Tutorial Hell, and it's sabotaging your growth.

You're grinding through courses on every hot framework – Angular, React, Vue – but your GitHub is filled with clones, not original portfolio pieces. You feel knowledgeable, but you lack the confidence to tackle a real-world problem.

Here's why: Tutorials are fundamentally not designed to forge engineers.

They are engineered to eliminate friction. But friction is the crucible in which a true engineer is formed.

Tutorials conveniently bypass the real challenges:

Unseen Bugs: Nothing truly breaks in a tutorial. The instructor's code is pristine.
Ambiguous Requirements: You're never given a vague feature request and forced to distill it into actionable steps.
Raw Setup: The ng new or create-react-app command magically configures everything for you, shielding you from build tools, configurations, and environment variables.
Reading Dense Docs: You're rarely compelled to parse through extensive API documentation to find what you need.

You're acquiring syntax, but you're fundamentally missing strategy.

The "Ugly" Project That Will Catalyze Your Transformation

My unwavering advice: Build something. I don't care if it's visually unappealing (remember our last discussion on CSS?). The point is to build it yourself.

Your Mission:
Create a simple web application that interacts with a free, public API.

Maybe fetch and display character data from the Rick and Morty API.
Perhaps a simple app that fetches cat facts from the Cat Facts API.
Or display random jokes from the JokeAPI.

The Bare Minimum: A button. Click it. Fetch data. Display the raw JSON (or a single parsed piece of it) on the page.

In this seemingly trivial project, you will be forced to conquer critical, real-world development challenges:

Making HTTP Requests: Mastering fetch() (or HttpClient in Angular) and understanding Promises and async/await.
API Documentation Literacy: Learning to read and interpret how an API works.
Error Handling: Encountering CORS issues, network errors, and gracefully managing them.
Data Parsing: Extracting meaningful information from raw JSON responses.
Browser DevTools Mastery: Debugging network requests, inspecting responses, and understanding the console.

Stop being a passive consumer. Start being an active creator. The frustration you'll inevitably face is the signal that genuine, deep learning is occurring. Push through it. The confident, capable developer you aspire to be is on the other side of that struggle.

The Folder Structure No One Teaches You (But Every Developer Needs)

Mon, 17 Nov 2025 15:02:47 +0000

Every developer has opened a messy project and immediately wanted to cry.
Maybe the routes folder had configs, the utils folder had business logic, and the components folder was full of files named test-final-new.js.

But here’s the secret: folder structure isn’t magic it’s just a series of small decisions that nobody teaches, yet every project depends on.

In this post, you’ll learn how to design a clean folder structure that grows with your project, using simple mental models and real-world examples.

Why Folder Structure Matters

A clean folder structure isn’t about being “organized.”
It directly impacts how productive you are.

Good structure helps you:

Prevent code rot — your project doesn’t slowly decay into chaos.
Onboard faster — new developers instantly know where things live.
Debug faster — find issues without hunting across five folders.
Refactor safely — changes happen in predictable places.

You don’t need a perfect structure just a consistent one.

Step 1: Start With the Core Questions

Before you create any folders, ask yourself:

What does this project do?

A simple website? A microservice? A mobile app?

What will grow over time?

APIs? Components? Modules?

What repeats?

Shared logic, hooks, helpers, constants.

What is isolated?

Auth, billing, user management, dashboards.

What should be plug-and-play?

Reusable utilities, UI components, services.

Your folder structure should reflect the shape of your project, not someone else’s.

Step 2: The Three-Layer Model

This is the simplest mental model you can apply to almost any project:

/core       → Business logic
/features   → Product modules
/shared     → Reusable utilities

Why this model works:

core = the brain
features = the different “areas” of your app
shared = the toolbox

This scales beautifully for frontend, backend, and even microservices.

Step 3: Real Examples

Let’s apply this to real projects developers actually build.

Example 1: React Project

A clean, scalable folder structure:

/src
  /components     → Reusable UI pieces
  /hooks          → Custom React hooks
  /pages          → Route-level pages
  /contexts       → Global state (Auth, Theme, User)
  /lib            → API clients, config, external services
  /assets         → Images, icons, fonts

Why this works:

Components stay reusable
Pages stay focused
Hooks remain discoverable
Global logic lives in contexts
Assets stay out of your code files

Example 2: Small Express API

A lightweight backend structure:

/src
  /routes         → Route definitions
  /controllers    → Request logic
  /services       → Business logic
  /models         → Database schemas
  /utils          → Shared helpers (validators, formatters)

Why this works:

HTTP logic stays separate from business logic
Services stay reusable across controllers
Models remain clean and consistent

Final Thought

You don’t need the perfect folder structure, you need one that reflects your project todayand doesn’t slow you down tomorrow.

Start simple.
Stay consistent.
Refactor when it hurts.

Your future self (and your teammates) will thank you.

Upcoming Accessibility Education Events in November 2025

Wed, 05 Nov 2025 07:42:02 +0000

The State of Accessibility in WordPress

Thursday, November 6, starting 04:00 PM CET

Join the WPCampus community on Thursday, November 6 at 10 a.m. Eastern (UTC -5) for a focused two-hour event exploring the current and future state of accessibility in WordPress through the lens of higher education.

They bring together accessibility leaders, developers, and governance practitioners for a series of sessions that connect insight to action: understanding where accessibility in WordPress stands today, how to build stronger governance structures, and what new tools are emerging to make accessibility testing more seamless and integrated.

Visit WPCampus.org/events for more information.

Getting tables right: Clear, accessible, and effective

Friday, November 7, from 1:30 PM to 2 PM CET

After the popular webinar on charts, Funka Foundation will now focus on tables. How do they work for people with different user needs? What are the main things to pay attention to? What are the main challenges? Join for an overview from the user perspective and some practical tips.

World Usability Day 2025: Emerging Technologies and Human Experience Livestream

Thursday, November 13, 6 PM to 8:30 PM CET

Talks and panel discussion on accessibility considerations through augmented reality, mobile app development, AI as assistive tech, and alternative interface design.

All events listed on WorldUsabilityDay.org

Your summary of upcoming accessibility education events in October 2025

Wed, 01 Oct 2025 11:52:09 +0000

WordPress Accessibility Meetup

Thursday, October 2 at 10 AM Central

It can be a struggle to convince your client to put in the effort and also conform to any regulation, like Section 508, the EU Accessibility Act, or otherwise. Drawing from her own experience with "difficult" clients and some basic psychology, Annelies Verhelst will provide you with compelling arguments and advice on how to make a business case.

Funka Foundation Friday Webinar: Cybersecurity + Accessibility = True

Friday, 3 October, 13.30-14.00 CEST

Cybersecurity and accessibility are both critical for resilient digital infrastructures. This webinar explains how accessibility requirements are integrated with modern cybersecurity measures. Together, they form robust and inclusive standards that support the Cyber Resilience Act.

Wagtail Space

Wednesday, October 8th - Friday, October 10th

Come join educators, publishing professionals, developers, open source enthusiasts, and leaders from organizations around the globe for three days of talks and networking.

WordPress Accessibility Day

Wednesday, October 15th - Thursday, October 16th

WordPress Accessibility Day is a 24-hour global event dedicated to promoting and learning website accessibility best practices for WordPress websites.

This is your event summary for upcoming opportunities in accessibility education in September 2025

Mon, 08 Sep 2025 19:46:08 +0000

WebAIM Conference

September 16-17, from 12:15 PM– 5 PM (US Eastern Time)

The Web Accessibility in Mind Conference is presented by WebAIM in partnership with Pope Tech. This virtual conference will provide conference participants with content that will help them mature their practice in digital accessibility. Our goals include:

Provide a diverse range of perspectives from a diverse group of
speakers.
Share solutions to accessibility challenges.
Give advice and guidance that helps our participants to actively
contribute to providing more accessible digital spaces.
Bring together a cross section of public and private sector
technology professionals from organizations large and small.

Google Dev Group Vienna AMA: Ask Us Anything about Accessibility

Thursday, September 18, 5:00 – 6:30 PM (GMT+2)

This session is your chance to ask all your burning questions about accessibility! Whether you're struggling with WCAG guidelines, unsure about best practices, or curious about the latest accessibility tools and techniques, we'll be here to provide answers and share insights. Panelists have backgrounds in software development, product design, UX research, QA engineering, product operations, and every single one brings deep expertise in accessibility.

Inclusive Design 24

Thursday, September 25, all day livestream on YouTube

Inclusive Design 24 (#id24) is a free 24-hour online event for the global community. It celebrates inclusive design and shares knowledge and ideas from analogue to digital, from design to development, from planners to practitioners, and everything and everyone in between.

How I Process things?

Sun, 31 Aug 2025 11:49:47 +0000

Intro.

>As this is my very first post here, this might be a good start point to begin with?

It's about of what over the years took me to of where I'm now with my coding skills and that is this.

1. Having an idea.

That is where it begins with "like a feature for my github page!", then I begin to gather the needed info of how to create that feature.

2. Figuring out of how to do it.

Figuring out of how to get my idea realised, trying to understand the concept and if needed lookup some examples or following a tut.

3. Start Coding.

Finally and the best way to get forward, I open the editor and start coding.
Sure and depending on the complexity, making mistakes and doing things completely wrong.

Then learn from that and put persistance in place until I get it right.

My credo always is this:

>While and as long as the pc doesn't smoke, it is all okay to make mistakes ???? !

4. Getting It Right.

When I get it right, I move on and up to the next challence!

In a nutshell.

Yes for me it's about being busy with it; learning, making mistakes, solving them and proceed to the next challence!

What I don't do!

As I work with many concepts, there is no way that I remember them all and I don't even try it!

There is no need for too, because there is MDN where I can find 99% of what I want too know!

What I also learned is this.

There are moments on the road that I don't make any progress. When that occurs, I learned that having a break or looking the other way can do wonders. It helps to get a fresh new look on where I was working on!

It happens that I solve things in seconds, where I previously spent
hours on!

Trying things out.

Trying things out, that is also what I do from time to time. Looking with a sharp eye to what I've created and or I can improve it, making it more KISS!

>Yes, my goal is always to Keep It Short and Simple!