#dargacode

Day 2862

Every time I go on a programming subreddit or other public forum, I see so many distraught learners in anguish that they can't start "A Real Project", and are "stuck" on tutorials, as state which has now come to be referred to as "Tutorial Hell."

It honestly makes me extremely mad that people have made Tutorial Hell into such a meme that new programmers are now scared of it. It's unnecessary gate-keeping around what counts as A Real Project, and it's harming programming students who could otherwise be happily progressing on their way to mastery if they hadn't been poisoned by this idea.

There are zero useful aspects to the concept, and it only prevents students from learning rather than helping them learn. Every programmer in the world, from you to the creators of Google, has to get their ideas based on SOMETHING:

A problem they want to solve for themselves (or a friend, or a customer).

Some knowledge they already had, applied in a new way

A new skill they've just picked up from another project or lesson

A new feature that was just introduced into some technology they use

There's literally no way to get an idea except to have had some experience that leads you to it.

So starting from a completely empty file, and divining a new project based purely on inspiration is of course a very intimidating task, but luckily we don't ever actually have to do that.

The process of developing projects is actually very natural (even inevitable???) if you transfer your code more gradually from "100% Tutorial" to "100% Project":

Start off by doing the tutorials as written. Make sure that you're actually coding along and checking in your code to a github repo.

Every time you finish a tutorial, think of some tiny change you can make to the code to "make it your own." This can start out as small as just changing some text on the screen, or the colors it's using.

Over time you'll naturally get some more ambitious ideas for how to make the project into something even cooler, and you'll start adding larger things like a new feature with its own functions.

Eventually you'll get enough practice expanding projects and applying ideas that the project is mostly your "custom" code instead of code the tutorial told you to write.

Now maybe you have an idea to make a clone of this project but make it even better.

Now you're making A Real Project, From Scratch, but it doesn't rely on you having some eureeka moment of inspiration.

Here's what those steps could look like in a more specific example, from a common tutorial:

Complete a tutorial on how to fetch data from a weather API.

Think, "how could I do some additional fetching to practice more?"

Decide to fetch some data from a movie API instead.

Think, again, "how could I do some additional fetching to practice more?"

Realize that you could use the skills you've learned to fetch two different movies, and iterate through the casts to see which actors they have in common.

Think, again, "how could I do some additional fetching to practice more?

Realize that you could do something similar by fetching two actors, and see what movies they have in common.

Remember that the meme "6 degrees of Kevin Bacon" is related to actors being in the same movies together.

Realize that you could make an app that tracks Kevin Bacon degrees by putting together your movie overlap code and your actor overlap code.

Take the code you've written to modify the tutorial and paste it into a new project, where start turning it into its own app.

https://apps.apple.com/us/app/six-degrees-movie-trivia/id328926385 (not my app)

Coding learners, you're going to be ok - you can take it gradually! Try to just focus on programming a lot, and what kinds of things you program will evolve naturally over time. If you want to consciously lead things in the direction of building your own projects from scratch that's great!

Day 2663

Here's a great explainer for Debounce vs Throttle, which are two different ways of making sure a user can't run a piece of code too frequently by spamming.

Day 2359

This git command shows every commit in your repo which isn't pointed to by anything:

git log --graph --oneline --decorate --all $( git fsck --no-reflog | awk '/dangling commit/ {print $3}' );

Very helpful for when something has gone horribly wrong, like say if you dropped the wrong git stash with important stuff in it 😅

DAY 1567

My project at work has some config files that I need to update locally, depending on what user account id I’m trying to test with, etc. If I ever accidentally checked in these changes, it would break a lot of stuff. 

After some searching I found this command, which makes sure my local changes to the file are never picked up by git:

git update-index --skip-worktree <foo/bar/filename>

DAY 1462

It’s been 4 years since I sat down to start doing some coding tutorials in the hopes of changing careers. Despite the euphemistic text on my website, this was actually 2 months after I had quit my job, and I had filled that time by agonizing over what I should do, reading a ton of advice on Reddit, and generally procrastinating in any way I could think of. 

Then, I finally forced myself to do the Hour of Code exercises on Khan Academy, and I drew a picture of a chicken. After that I could rely on momentum to move myself to the next project, and the next course, and the next topic, even when I wasn’t sure if it was the right thing to do. 

I didn’t recognize it at the time, but that first lesson was the most valuable - STOP WORRYING AND JUST CODE SOMETHING. That’s what always turned out to be the right answer all the way through this studying process, the job application process, and fairly often through my coding jobs as well. 

DAY 1221

Managing my career has not been something that came naturally to me or that I learned growing up. In particular, negotiating is something that always heard that people should do, but I had this midwestern idea that it was something only for assholes, or that it could somehow backfire.

Here are a list of articles which sum up all the things I know about negotiating, and which taught me some of them too:

Negotiating isn’t something that hurts your chances to get a job.

In fact companies expect it, and actually respect you more for doing it.

By default, most candidates will behave in ways that give away all their negotiating power.

We workers have much more power in a negotiation than we first assume.

The entire conventional interview/offer/negotiation process is set up by employers to benefit themselves and get you to accept lower compensation.

So what may feel to you like “being entitled” or “taking advantage” is actually the bare minimum to even have a chance at an equal footing.

Setting the stage for a successful negotiation begins at the first moment you speak to a recruiter, long before receiving a job offer.

It’s a lot of hard work, but it has a higher relative return on investment than possibly any other action in your career.

A job seeker can achieve a strong negotiating position regardless of experience level.

The strongest possible negotiating position is having multiple offers, and being genuinely excited about all of them.

There are many other negotiable elements of a job offer besides salary, or even financial compensation as a whole.

(Ordered from quick lists to more in-depth reads)

Penelope Trunk - 4 tips for salary negotiation

WorkMonger - 6 steps for negotiating your next job offer

Harvard - BATNA essentials

Interviewing.io - What to say when recruiters ask you for a number

Haseeb Qureshi - 10 rules for negotiating, part 1

Haseeb Qureshi - 10 rules for negotiating - part 2

Patrick McKinzie - Make more money, be more valued

Even though these aren’t limited to webdev per se, I’ve added a new section for negotiation resources in my master list:

DAY 1283

I’m writing a lot more tests in my new job, and I generally like it a lot, but I’m still very bad at it. 

I find myself pretty frequently in situations where I’m thinking, “How in the world can I possibly test this thing?? It’s gonna be impossible to get at that [state/data/function/whatever]!”

So far every time that has happened, I talk to someone on my team and it ends up I have the wrong idea and definitely shouldn’t be trying to test that thing in that way, or even that I shouldn’t be testing it at all.