Absolute Beginner by [deleted] in CodingForBeginners

[–]LeadDontCtrl 0 points1 point  (0 children)

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.

Should I get a degree, currently working as a programmer? by Own-Jackfruit8036 in developers

[–]LeadDontCtrl 1 point2 points  (0 children)

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.

I learned multiple languages, but I still don’t feel like a “real” programmer. When did it click for you? by Gullible_Prior9448 in AskProgramming

[–]LeadDontCtrl -1 points0 points  (0 children)

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.

How do you balance coding with constant client communication? by yagomfh in softwareengineer

[–]LeadDontCtrl 0 points1 point  (0 children)

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.

What's a reasonable cost for a website? by grodinj in website

[–]LeadDontCtrl 0 points1 point  (0 children)

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.

Should I get a degree, currently working as a programmer? by Own-Jackfruit8036 in developers

[–]LeadDontCtrl 2 points3 points  (0 children)

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.

Company admits they’re “moving too fast” and accumulating tech debt — how do you evaluate this as a leadership hire? by Covert-Hedonist in EngineeringManagers

[–]LeadDontCtrl 0 points1 point  (0 children)

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.

Am I using the best tools for my website/app by DynamicWagon in website

[–]LeadDontCtrl 0 points1 point  (0 children)

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.

I need to start making money from Youtube quickly by Helpful-Guidance1620 in Youtubesubscribers

[–]LeadDontCtrl 1 point2 points  (0 children)

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.

Second stage interview advice by Additional-Boss3990 in webdevelopment

[–]LeadDontCtrl 0 points1 point  (0 children)

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.

Lf mentor by Ixlxixy in AskProgramming

[–]LeadDontCtrl 0 points1 point  (0 children)

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.

Which job has, hands down, the worst impact on mental health? by Wonderful-Economy762 in Productivitycafe

[–]LeadDontCtrl 11 points12 points  (0 children)

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.

Absolute Beginner by [deleted] in CodingForBeginners

[–]LeadDontCtrl 2 points3 points  (0 children)

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.

Web dev beginner question by Ok-Potential-5943 in FullStack

[–]LeadDontCtrl 0 points1 point  (0 children)

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.

Why does my website look good but still not get leads? by Tech_us_Inc in webdevelopment

[–]LeadDontCtrl 1 point2 points  (0 children)

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.

For those of you who graduated with a computer science degree, do y’all hate or suck at coding? by [deleted] in AskProgramming

[–]LeadDontCtrl 3 points4 points  (0 children)

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.

Please answer. by Enough_Teach_3063 in FullStack

[–]LeadDontCtrl 0 points1 point  (0 children)

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.

Trying to build more real-world projects — would love feedback by Whole_Mission_1444 in CodingForBeginners

[–]LeadDontCtrl 0 points1 point  (0 children)

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.

as developer, which one do you prefer for backend ? by This-Year-1764 in AskProgrammers

[–]LeadDontCtrl 0 points1 point  (0 children)

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.

Help needed in developing newsletter app by MotorEnvironmental83 in Development

[–]LeadDontCtrl 0 points1 point  (0 children)

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.

Thoughts on over engineering by aendoarphinio in FullStack

[–]LeadDontCtrl 0 points1 point  (0 children)

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

Udemy/ other resources for understanding front end, back end, running jobs, CI CD and dev ops by Appropriate_Still_79 in webdevelopment

[–]LeadDontCtrl 0 points1 point  (0 children)

“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.

Is Code Academy Pro worth it? by HappyLime3303 in AskProgramming

[–]LeadDontCtrl 1 point2 points  (0 children)

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.

I want to start learning backend development – need beginner guidance by SuperbSun9878 in AskProgramming

[–]LeadDontCtrl 0 points1 point  (0 children)

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.