Advice

I do not have a computer science degree. I am trying to get hired in this field anyway, so I had to find another way to prove I can do the work.

The thing that worked was building a stack deep enough that it answers the question for me. Not a course certificate, not a tutorial project. Real tools other people use, and infrastructure that stays up.

A few things I would tell someone starting the same way:

Pick problems that already annoy you. Every tool I have written came from something being broken in front of me. That gives you the one thing a tutorial cannot: you know when it is actually fixed.

Publish before it is good. Nobody is watching closely enough for the early version to hurt you. See leave your work up.

Depth beats a checklist. One project you can talk about for an hour is worth more than nine you can describe in a sentence. Interviewers can tell the difference immediately.

Write down what you figured out. Half of what is on this site exists because I solved something twice and got tired of it.

I will not pretend this has worked yet. I am still looking for a role. The argument is that the work should answer the question, and putting it all in public is how I am testing that.

I use AI heavily and I am not defensive about it. But the framing matters, because the same tool can make you faster or make you useless depending on what you point it at.

What it is good for: I do not enjoy reading ten thousand pages of documentation to find one paragraph. That is not learning, that is retrieval, and it is the exact task a machine should absorb. Handing that over gives me the time back for the part I actually want to be doing.

Three reasons I lean on it as hard as I do:

1. I want to know how far it goes. If something is possible now and I do not know it, I lose the opportunity by default.
2. I learn best from question and answer. Being able to ask follow-ups until it clicks is how my head works.
3. It clears the work I would otherwise avoid, which means the work gets done instead of postponed.

Where it goes wrong is when it writes something you then ship without reading. Then you have not saved effort, you have moved it to whoever debugs it later, and you have skipped the part where you would have learned something.

The test I use: could I explain this to someone who asked? If not, I do not ship it yet.

A related note on honesty. The VS Code workflow guide says plainly that AI helped write it. That disclosure costs nothing and it is the difference between a tool and a pretense.

When I got into self-hosting I wanted one thing: a login page in front of a service I was already running. That is the whole request.

It took eighty pages of documentation and a detour through role-based access control. I kept assuming I had missed a simpler path, because surely nobody designed it this way on purpose.

Nobody did. That is the point. It ended up that way because each piece was built for a different scale of problem than mine, and the simple case never got its own door.

If you are stuck in that spot right now, the useful reframe is this: the friction you are feeling is a property of the tool, not a measure of you. Software that requires eighty pages to do a common thing has a documentation problem, or an interface problem, and either way it is theirs.

Two things follow from that.

Keep going anyway. Being annoyed does not mean you are wrong for wanting it simple, and the thing usually is achievable once you find which layer you actually needed.

Then write down the short version. The path you took, minus the dead ends. That is most of what is in the guides here. Every one of them is me refusing to pay the same tax twice.

A lot of what I have built lately is well outside what I am comfortable with, and I have felt it the whole way through. Not in a productive, character-building way. In a this-is-hard-and-I-am-struggling way.

I do not think that means anything is wrong. It is what the edge feels like from the inside. The projects I am proudest of were all uncomfortable while I was in them, and none of that discomfort showed up in the result.

What helps:

Shrink the unit. The panic is usually about the whole thing at once. One moving part at a time is a different task entirely.

Say it out loud. Admitting you are stuck ends the spiral faster than anything else I have tried.

Let the timeline be wrong. Something I thought would take an evening has taken two months more than once. That is information about the problem, not about me.

Count what you learned, not just what shipped. Some of it does not ship. The knowledge does not go anywhere.

A rewrite here dropped the skip-to-content link. One anchor tag, the one that lets a keyboard user jump past the navigation. It had been static HTML in a file that got replaced, and it did not come along.

Nothing caught it. Nothing could have. Tests cover behavior somebody wrote a test for, and that link had never needed one, because for its whole life it was just sitting in a file.

The lesson is smaller than the fix and more useful: when a rewrite deletes a file, read the file it deletes. Not the diff. The file.

Diffs are good at showing you what changed in code you are thinking about. They are bad at showing you the thing you forgot existed, because you have to already know to look for it.

The full story is in the note.