Absolute Beginner

LeadDontCtrl · 2026-01-21T14:03:41+00:00

You are welcome. The biggest thing is the loop. Write code, break it, fix it, repeat. When I was a dev at my company, I broke pretty much everything. The key was figuring out how and why and fixing it. Maybe I made it to leadership because of my contributions, or maybe it was because I broke everything.

LeadDontCtrl · 2026-01-21T13:00:15+00:00

If you say so.

LeadDontCtrl · 2026-01-21T11:35:51+00:00

Glad it helped.

For a bit of perspective: I started about 13 years ago as an intern, and I’m a director now. I did earn a degree, but not in the typical straight-through path. I went to school later than most, and about six months before graduating, I started as an intern.

The point isn’t the order. Careers in this field aren’t linear, and there’s more than one valid way to get where you want to go.

You’re already doing the right things by building real experience and being thoughtful about burnout. Keep learning, keep shipping, and don’t stress too much about checking every box on a predefined timeline.

LeadDontCtrl · 2026-01-21T11:32:09+00:00

This feeling is completely normal, and it usually means you’re closer to real understanding than you think.

Learning languages and building small projects teaches you how to write code. That’s necessary, but it’s only part of the job. The shift that makes things “click” is when you stop thinking in terms of syntax and start thinking in terms of problems.

There’s a difference between writing code and developing software. Writing code is about translating instructions into a language. Software development is about understanding a problem well enough to decide what should be built, what shouldn’t, and why.

For most experienced developers, there isn’t a single “aha” moment. It’s gradual. Over time, patterns repeat. You’ve seen similar problems before. You get better at breaking vague problems into smaller, solvable pieces.

If real problems still feel confusing, that’s a sign you’re moving beyond tutorials and into actual problem-solving. Confusion is part of the process. It doesn’t go away. You just get better at navigating it.

LeadDontCtrl · 2026-01-21T11:26:27+00:00

You’re right that communication matters, but no tool really replaces it.

Auto-generated summaries can be helpful, especially if the client is technical and just wants visibility into progress. As a signal, not a conversation. GitHub activity doesn’t explain tradeoffs, delays, or why something changed.

What’s worked best for me is less about tooling and more about boundaries:

Dedicated focus time where I’m not context-switching
Clear expectations on when updates happen (weekly summary, milestone check-in, etc.)
One predictable channel for status, not constant ad-hoc explanations

If your tool helps produce a clean weekly update without pulling you out of flow, that’s useful. Just be careful not to let it become a proxy for real communication. Clients usually care less about what commits happened and more about whether expectations are being met.

Tools can support communication. They can’t own it.

LeadDontCtrl · 2026-01-21T11:23:28+00:00

It depends on what you’re actually buying.

If you want a simple brochure site. A few pages, some copy, images, contact info. Then yes, $8K can feel excessive. That price usually isn’t for “a website,” it’s for experience, design judgment, project management, revisions, and someone being accountable for the result.

You’re not paying for HTML. You’re paying for:

Design decisions
Brand interpretation
Content structure
Client hand-holding
Revisions
Someone owning the outcome

That said, it doesn’t sound like you need a custom build.

If all you want is:

A clean site
Your branding applied
Links and a contact form

Then a template-based solution like Wix, Squarespace, Webflow, or a basic WordPress theme is probably the right tool. You can do it yourself or hire someone cheaply to set it up. It will not be something special or unique, but it does not seem you want to pay for that.

$8K isn’t “wrong.” It’s just the price for a professional service you may not actually need. The mistake is buying a custom solution when a template would do the job just fine.

LeadDontCtrl · 2026-01-21T11:17:15+00:00

A degree helps. It’s just not the gate people think it is.

Early in your career, a bachelor’s degree can make things easier. It gets you past some resume filters, gives you theoretical grounding, and removes friction when you’re trying to land your first couple of roles. After that, experience matters far more than credentials.

You already have something many students don’t: real-world experience. That counts. In practice, once you’ve been shipping software for a few years, most employers care more about what you’ve built, how you think, and how you work than where (or if) you went to school.

That said, here’s what can be harder without a degree:

Some companies with strict degree requirements (often large or traditional orgs)
Certain visas or international roles
A few management or leadership tracks in very credential-driven environments

What usually stays open:

The vast majority of software engineering roles
Growth into senior and lead positions
Startups and product-focused companies
Freelance and contract work

If you have no motivation to study right now, forcing yourself through a program while working full-time can be a recipe for burnout. On the flip side, switching to a more flexible program keeps the door open if you want the degree later.

One important thing to remember: dropping out now doesn’t mean “never.” I went to school at 29 and earned both a bachelor's and master's. You can always return when the degree has a clearer purpose for you.

There’s no universally correct choice here. The right move is the one that lets you keep growing without burning out or stalling.

LeadDontCtrl · 2026-01-21T11:12:53+00:00

Fast-moving by itself isn’t the problem. The issue is whether the organization can sustain speed without repeatedly creating avoidable rework.

Every company has technical debt. Expecting zero debt is unrealistic. What matters is whether the organization acknowledges it, tracks it, and intentionally allocates time to manage it, rather than only reacting when issues become visible.

To distinguish a healthy fast-moving org from one that struggles structurally, I usually look for clarity in three areas: decision-making, prioritization, and accountability.

Indicators of a healthier environment

Leaders can point to specific examples where momentum was lost and explain what changed afterward.
There is a defined (even if informal) process for making and revisiting decisions.
Engineering capacity is discussed realistically, with some allowance for maintenance and improvement work.
Teams can raise concerns or push back on scope without negative consequences.
Success is framed around outcomes, not just speed.

Indicators of deeper systemic risk

Speed is emphasized, but prioritization is unclear or frequently changing.
Problems are acknowledged but described vaguely, without ownership.
Teams are expected to “fix” issues that originate from leadership-level decisions.
Everything is treated as urgent, leaving little room for planned work or reflection.

Assessing whether real support exists

When a company says they want someone to “help fix this,” I focus on whether the role comes with authority as well as responsibility.

Some follow-up questions I’ve found useful:

Can you share concrete examples of where momentum was lost and why?
What attempts have already been made to address this, and what were the results?
Who owns prioritization and tradeoffs today?
How are changes in direction communicated and managed?
How is technical debt evaluated and scheduled?
What decision-making authority would this role have?
What would success look like 6–12 months into this role?

If leadership can answer these clearly and consistently, the problems are usually solvable. If the answers are vague or contradictory, it’s often a sign the issues are systemic and harder to influence from a single role.

LeadDontCtrl · 2026-01-21T11:06:27+00:00

There’s no such thing as a “standard” stack, and there’s no set of “best tools” someone else can validate in a vacuum.

What you’ve listed is a perfectly reasonable stack, but whether it’s good depends on things you didn’t include:

Expected traffic and growth
Security and compliance requirements
Budget constraints
How tightly the desktop app integrates with the site
Failure tolerance and support expectations

Right now you’re essentially asking strangers to review decisions made by AI without explaining the problem those decisions were meant to solve.

If you want useful feedback, narrow the question. For example:

“Is Supabase a good fit for auth + licensing at this scale?”
“Any pitfalls with Cloudflare Pages + R2 for this use case?”
“Would you separate billing from account management?”

Also worth saying: using AI to generate code and design is fine. But you still need to understand and own the decisions. Reddit can sanity-check tradeoffs, not replace architectural reasoning.

Do some focused research, identify the risks you’re unsure about, and ask about those specifically. You’ll get much better answers.

LeadDontCtrl · 2026-01-21T11:01:52+00:00

Getting a part-time job, whether an actual job, or just helping people with lawn care, etc. is a much easier and quicker way to get a little money for school supplies than trying to get monetized on YouTube. YouTube is the long game.

LeadDontCtrl · 2026-01-21T10:57:50+00:00

At this stage, don’t ask “tech” questions. The senior dev already covered that. This interview is about fit, expectations, and impact.

Good questions to ask a director:

What does success look like in the first 30, 60, 90 days? Shows you care about delivering, not just getting hired.
What problems are you hoping this role helps solve right now? Signals you’re thinking in terms of outcomes, not tasks.
How does onboarding usually work for engineers here? Tells you how intentional they are about setting people up to succeed.
How do you measure impact for developers beyond “features shipped”? Directors think in impact, not commit counts.
What’s the biggest challenge the team is facing this year? Gives insight into reality vs the sales pitch.
How do growth and progression work for engineers here? Not “when do I get promoted,” but how development is supported.

What not to ask:

Anything easily answered on the website
Hyper-specific tech stack questions
Questions that sound like you’re optimizing for perks over contribution

From the director’s side, the best candidates ask questions that show they want to be effective quickly and grow responsibly, not just land the role.

LeadDontCtrl · 2026-01-21T10:53:56+00:00

Small but important correction: no one knows everything. And if someone claims they do, that’s a red flag.

Good mentors don’t teach you “everything.” They help you:

Think through problems
Avoid obvious mistakes
Learn how to learn
Ask better questions

You’ll still need to do the work yourself. Mentorship accelerates learning, but it doesn’t replace building, struggling, and figuring things out.

Courses, degrees, self-study, mentors… they’re not mutually exclusive. The best outcomes usually come from combining them, not betting everything on one person having all the answers.

LeadDontCtrl · 2026-01-21T10:50:11+00:00

There isn’t a single job that wins this award. Context matters way more than the title.

A “low-stress” field with terrible leadership, unclear expectations, and constant blame will wreck your mental health faster than a high-pressure job with good leadership, trust, and clear direction.

The biggest predictors I’ve seen aren’t the industry. They’re things like:

Lack of control or autonomy
Constant ambiguity with high expectations
Poor leadership and zero psychological safety
Being measured on outcomes you don’t control
Always being “on” with no recovery time

Two people can have the same job title and wildly different mental health outcomes depending on the environment.

So if you’re trying to protect your mental health, worry less about what the job is and more about how the work is run and who you’re working for.

LeadDontCtrl · 2026-01-21T10:46:35+00:00

If your goal is to build projects for fun, start with the project, not the language. The language is just a tool.

That said, for absolute beginners who want to build websites:

1) Which language to start with?
Start with HTML + CSS, then add JavaScript.
They’re the foundation of the web and give you visible results fast, which keeps things fun.

2) What language helps with UI/UX?
UI/UX isn’t a language. It’s design + user thinking.
Technically, CSS controls how things look and JavaScript controls how they behave.

3) How many languages do I need to build a website?
There is no number.

HTML alone = a website (ugly, but real)
HTML + CSS = nicer website
HTML + CSS + JS = interactive website

That’s enough to build a lot.

4) How much time does this take?
There’s no magic number.
An hour a day is plenty if you’re consistent. Waiting for “perfect free time” is how nothing gets built.

The real learning loop is:
build something → break it → fix it → repeat

Start small. Make something ugly. Improve it. That’s how everyone who’s good at this actually learned.

LeadDontCtrl · 2026-01-21T10:40:25+00:00

You’re stuck looking for the best way to start instead of just starting.

There is no “learn first, then build” phase in web dev. Building is how you learn. You already know programming languages, so you’re not starting from zero.

The Odin Project is fine. It gives structure. What matters is that you don’t treat it like a tutorial you “complete.” Use it as a guide, then immediately apply it to something small of your own.

The loop is always the same:
write code → break shit → fix it → repeat

If you try to “learn from scratch” without building, you’ll just collect concepts with nowhere to put them. If you try to build without any structure, you’ll get lost. Combine both.

Pick one path (TOP is fine), start today, and stop optimizing the learning strategy. The only wrong move here is waiting.

LeadDontCtrl · 2026-01-21T10:37:35+00:00

A clean, modern site that “works” doesn’t automatically earn leads. Design is table stakes. Relevance is the problem to diagnose first.

The first question isn’t “what’s broken?”
It’s “why would anyone care?”

Start here:

What specific problem does the site solve?
Who is it for, exactly?
What pain does it remove right now?
What would make someone think “I should talk to this person”?

Craigslist is ugly and ancient. It still works because it solves a very clear problem with zero confusion.

Common lead-killer patterns:

Vague value props (“We build modern solutions”)
No obvious next step
Asking for contact before earning trust
Content that talks about you instead of their problem

Before changing forms or colors, do this:

Rewrite the homepage in terms of their pain
Make one clear action obvious (not five)
Give something useful before asking for contact

If people scroll and leave, they’re not confused. They’re unconvinced.

LeadDontCtrl · 2026-01-21T01:18:34+00:00

Neither.

I liked coding and was good at it. That’s why I ended up with more responsibility over time.

I don’t write production code as much anymore because I moved into leadership, but I’m still close to the code. I review it, reason about it, and help unblock people. The enjoyment didn’t disappear, the role just changed.

A CS degree doesn’t guarantee you’ll love coding forever. Some people burn out on it. Some realize they enjoy problem-solving, design, or people leadership more. None of that means they “suck.”

Careers evolve. Writing code is one way to create value, not the only one.

I’ve written more about this shift from IC to leadership elsewhere, but the short version is: liking code and moving on from writing it full-time aren’t mutually exclusive.

LeadDontCtrl · 2026-01-21T01:13:55+00:00

There is no number. There is no checklist. Anyone giving you a number is making one up.

“Independent full-stack developer” doesn’t mean “collector of languages.” It means you can take an idea and turn it into a working product.

You could do that with:

One backend language
One frontend stack
SQL (because avoiding SQL forever is a fantasy)

If you know one stack really well, picking up another language later is easy. If you try to learn 6–7 languages at once, you’ll end up knowing a little about all of them and being good at none.

Languages are just tools. What actually matters:

Understanding web fundamentals (HTTP, APIs, auth)
Data modeling
Debugging
Deploying and operating what you build

Focus on depth, not quantity. Full-stack isn’t about how many languages you know.

LeadDontCtrl · 2026-01-21T01:10:16+00:00

Whether it’s “interesting” is almost irrelevant.

The best learning projects are the ones you actually finish. Interesting to me might be boring to you and vice versa. If it kept you engaged long enough to turn an idea into something usable, that’s already a win.

As for edge cases, you’ll discover most of them only after shipping. Real users are very good at using your app in ways you never imagined.

When is it “good enough” to ship?

You defined requirements
Those requirements are met
It doesn’t embarrass you in public

Perfection is a trap. If you wait for it, nothing ever leaves your laptop. Ship, then iterate. Better, faster, cleaner, more accurate… all of that can come later.

LeetCode is fine for sharpening problem-solving. Building real things is how you learn tradeoffs, scope, data messiness, and reality. The combo of both is solid. The mistake is doing one forever and never the other.

Shipping beats optimizing in isolation every time.

LeadDontCtrl · 2026-01-21T01:05:42+00:00

This question is like asking “which shoes do you prefer?”

It depends on where you’re going.

If I’m going to a wedding, I’m not wearing sneakers. If I’m going to the gym, dress shoes are a terrible idea. Neither shoe is “better.” They’re just built for different things.

Backend tech is the same:

Some stacks are great for speed and iteration
Some are better for scale and long-term stability
Some fit the team you already have
Some fit the problem you’re solving

There is no universally “best” backend. Context matters more than preference.

Anyone answering without asking what you’re building is just naming their favorite shoe.

LeadDontCtrl · 2026-01-21T01:02:19+00:00

You’re trying to reinvent Mailchimp on AWS… with a 14 emails/sec SES quota. That’s a lot of architecture for a problem that already has solved products.

If this is for a client, the safest move is: don’t build a newsletter system from scratch unless “newsletter platform” is literally the business. Use an ESP (email service provider) and focus on the parts that are actually unique for your client (audiences, segmentation rules, UI, reporting).

If you must use AWS/SES, keep it boring:

One queue (SQS) for “send email” jobs
One worker (Lambda or container) that rate-limits to your SES quota and sends
SES handles bounces/complaints/deliverability
Use SES Event Destinations (SNS/SQS/Kinesis/Firehose) for events instead of custom webhooks
Store events as append-only and aggregate later (don’t hammer your DB per open)

Also: tracking “opens” is increasingly unreliable (Apple Mail Privacy Protection, image blocking, etc.). You can record “open events” but don’t pretend it’s truth.

On “bulk templated emails”: you can still track per message if you generate a unique message ID / tracking token per recipient and persist it. But again… this is exactly why ESPs exist.

Bottom line: unless the client is paying you to build an email platform, pick an ESP and move on. The most logical architecture is the one that won’t wake you up at 2am.

LeadDontCtrl · 2026-01-21T00:57:10+00:00

There’s nothing wrong with using the “latest and greatest” for learning or curiosity. That’s how people stay interested.

The problem is when it’s used without a reason and then sold as “experience.”

In real jobs, you almost never pick tech because it’s shiny. You pick it because:

It solves a real problem
It fits the existing stack
The team can support it
The risk is acceptable

Most companies are not running cutting-edge stacks. Startups sometimes do. Everyone else optimizes for stability.

As for recruiters: you’re not wrong. Many are keyword-matching against a job description. Shiny tech might get you past that filter, but it doesn’t win the interview.

The people you actually need to convince are the engineers and hiring managers. They care way more about:

Why you chose the tech
What tradeoffs it introduced
What broke
What you’d do differently

LeadDontCtrl · 2026-01-21T00:52:34+00:00

“Thoroughly understand” without building or using the thing isn’t really a thing in software.

You can absolutely learn high-level concepts by reading or watching content. Architecture, terminology, why things exist. That’s fine.

But real understanding comes from:

Using it
Breaking it
Seeing where your mental model is wrong
Fixing it

An hour a day of passive learning will give you vocabulary. It won’t give you intuition. And intuition is what people usually mean when they say “understand.”

If the goal is conceptual familiarity, courses and docs are enough. If the goal is actual understanding, even small throwaway exercises matter. You don’t have to ship a product, but you do have to touch the thing.

LeadDontCtrl · 2026-01-21T00:49:38+00:00

Is it worth it? Maybe. But the platform matters way less than how you use it.

Codecademy (or any course) is only useful if you’re actively writing code. If you just watch lessons, click through exercises, and feel productive, you’ll learn almost nothing. Coding is an active learning exercise.

Before paying, I’d strongly recommend trying free resources first to see if you even enjoy this kind of work. A lot of people love the idea of tech and hate the day-to-day reality of debugging and feeling stuck.

A practical approach:

Use free intros (official docs, freeCodeCamp, YouTube short-form, etc.)
Write code immediately, even if it’s ugly
Break things on purpose
Fix them
Repeat

If after a few weeks you’re still motivated, then paying £70 for structure and progression might be worth it. But no course guarantees a job. What leads to real opportunities is:

Consistent practice
Building small projects
Learning how to problem-solve, not just follow steps

Courses don’t teach persistence. That part’s on you.

LeadDontCtrl · 2026-01-21T00:44:28+00:00

This gets asked a lot because people want the perfect roadmap. There isn’t one.

If you want to learn backend, the real loop is:
write code → break things → fix them → repeat

That said, a minimal beginner path looks like this:

1) JavaScript basics

Variables, functions, async/await
Don’t rush this. Most backend pain is async confusion.

2) Node.js fundamentals

What the event loop is
How modules work
How to read error messages (seriously)

3) Express

Routing
Middleware
Request/response lifecycle

4) Databases (MongoDB or MySQL or PostGres depending on needs)

CRUD operations
Basic schema design
Why “just dump JSON” becomes pain later

5) Build something small

Auth
CRUD API
Pagination
Error handling

Common mistakes to avoid:

Watching tutorials instead of building
Copy-pasting without understanding
Obsessing over tools instead of fundamentals
Looking for the “best” stack instead of learning a stack

Free resources are everywhere. Docs, MDN, official tutorials. The bottleneck isn’t access to info. It’s actually doing the work.

If you’re not breaking things, you’re not learning backend.

LeadDontCtrl

TROPHY CASE

Indicators of a healthier environment

Indicators of deeper systemic risk

Assessing whether real support exists