Can I Program Yet?

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 2617

This is the best short introduction I've seen to what React is and why to use it over vanilla javascript.

Day 2378

A feature like this existed at my first job, where they had written their own custom github equivalent, and I really missed it!

It's especially nice to be reading a code review comment, and then open the exact file and line in my editor. Works for a lot of different editors!

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 1307

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. 

DAY 1245

This is another question people ask me a lot.

I really wanted to get out of game design, which is a bit sad since so many people think (and my past self thought) of it as such a dream career.

Making the switch took 2.5 years with no income and a big pay cut at first, but even in the first year and month it was a no-contest great decision for me. 

Here’s what I tell my game design friends when they ask me about it:

1. I want there to be a better match between the things I feel responsible for and the things I have agency over. [I’ve always noticed that engineers and artists can still seem to feel the sense of doing good work even if the game overall is not a success.] Game designers have responsibility over the entire game, but in practice not agency to make improvements to the entire game. Engineers also have to ability to fix so many different kinds of problems compared to what a designer can do with pure tuning.

2. I can spend more time focusing on the aspects of game design that I like (implementation, process, solving technical challenges, objective decision making) and less time focusing on the parts I don’t like (creative “brainstorming”, high level theme/audience, subjective decision making).

3. More companies to choose from. I applied to 360 companies in the bay area before I got an offer, and there was no sign of me running out. In games I got to the point where I couldn’t think of a single company I wanted to work for, or if I could it would have meant relocating.

4. More potential to get a job working on issues that I care about/find meaningful. Education, health, civics, etc.

5. More flexibility on places in the US I can live and still be paid well. People on reddit all the time are talking about how ridiculous it is to live in the bay area when they can make 6 figures in much cheaper places, work remotely, etc.

6. Better career progression for someone who doesn’t want to be a manager.

7. More of an established discipline with fewer disagreements about fundamental aspects.

8. Lots of new things to learn, no sense that I can ever start to run out/hit diminishing returns.

9. I felt was fairly topped out in my game design salary as an individual contributor, but that same amount of money is on the low end of what engineers can make.

DAY 1236

This isn’t related to programming, but it’s something that people ask me about all the time, when they hear it used to be my job.

Here’s what I usually tell them:

The game economy generally includes any numerical value in the game, and the economy designer defines and tunes the formulas for all of those numbers.

For example, imagine we’re asked to design a game where the player can hit pinatas to break them open and get candy.

Some of the questions we would want to answer and then provide numbers for:

How fast can you swing the club?

How much damage does the club do to the pinata?

How much damage can the pinata take before it breaks open?

Are there different kinds of candy? If so how many?

Does the candy have rarities? How easy is it to get a really valuable piece vs the most common ones?

Can you eat the candy? If so how does it give you some kind of benefit? How much benefit from each rarity?

Can you sell the candy? If so how much is each kind worth?

Is there a store you can spend that money on things? If so what can you buy?

Can you spend money to upgrade the club we hit the pinata with? What are the new stats and prices for each item?

Can we buy pinatas with better contents? If so how expensive is each one and how likely ie each one to give you rare candy?

Can the user buy in-game currency with their real-world money? If so at what exchange rate?

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 1215

Anonymous asked:

What’s your advice for hitting the ground running in my first job, learning the new internal tools and codebase?

I definitely had a bumpy landing at my first job, and I had to develop a lot of strategies to try and get my bearings and ramp up to being useful.

Be patient with yourself and trust your team

Every person on my team told me it would take “6 months to a year” to fully ramp up, and I thought that sounded absolutely crazy. However as I hit that half-year mark, it felt like I had barely scratched the surface. 

If you trust your own feelings when it comes to how well you’re doing, you’ll always feel woefully slow and underperforming. 

Your team knows it takes time to ramp up, and they still hired you knowing that would be the case. Check in with your team and manager often to see how you’re progressing against their expectations of you. Hopefully they’ll have a clear plan which will detail what’s expected of you over time.

Take some easy, neglected work under your wing and become the go-to person

A typical way to get a junior developer comfortable with the team and the codebase is to have them do some small tasks that the team typically does. This is great for having lots of people to help you out, and clear criteria for success.

Also keep an eye out, though, for small bugs, dashboard improvements, tool features, or other things which would help the team out, but which are too low priority for your teammates.

Prioritization before you got on the team was done according to what was worth your more senior teammates’ time, but there may be a lot of things that would be good learning experiences for you.

Bringing these things up to your manager can show your proactiveness, even if they decide it’s best to not work on them. And if they do decide to put those tasks on your plate, they can be a more visible way to make an early impact on the team, since you’re doing work which will make the team’s life better and which would otherwise not have gotten done. 

Another important benefit to finding something small and focusing on it for a little while is that you’ll build up more expertise and confidence.

Resist the needing to perfectly understand everything

I'm the kind of person who always wants to know how and why and when things evolved to be how they are, what the benefits are, and all those other interesting questions that really help you dig into something while learning it.

However in the kind of giant codebases we're dealing with, it's a neverending rabbit hole that will stall you forever. There are a lot of times I have to follow some instructions or copy some example code without knowing why it works, only to go back and gradually fill in the gaps later on. For example "is this method I just called part of PHP, one of Facebook's additions on top of PHP via HACK, or part of one of our internal APIs?"

A lot of the time when studying I would take long detours to address my curiousity about something, or to relearn it from a different source which might explain it in a better way. Having to care more about productivity than learning is one of the consequences of switching from student to paid employee.

This is a really hard one for me but I'm working on it.

Worry less about getting unstuck any particular time, and more about learning how to get unstuck in general

Getting stuck and asking teammates for help is a huge (maybe the biggest?) part of being a junior developer, and it’s easy to feel like your teammates know everything all the time. 

If you pay attention, though, you’ll quickly realize that the person helping you solve your problem has to figure out the answer for themselves before they can explain to you what it is. In other words, they don’t know the answer either, but they know how to find it out.

You can pick up a lot of research and debugging tricks by watching how experienced people go about it. Do they look into he documentation first? The wiki? An internal messageboard? The codebase itself? Click a link from an error message?

There are so many ways to identify problems in code, and you might learn a method that’s new to you or find out that some techniques are better suited for certain types of tasks. Don’t be shy to ask people to let you in on their thought process of how and why they choose each method!

DAY 1200

A few times now, I’ve worked on search/autocomplete projects, and needed node scripts to process the list of items into a quickly-searchable Trie/Dict datastructure.

I’m extracting the script into its own project, with some improvements to make it more general and reusable in the future.

DAY 1173

I want to use a list of ZIP codes for my autocomplete project, but I couldn’t find anything in a good format.

After trying and failing a lot of different methods to get something that would work, I found a dataset in CSV form from AggData, and used csvjson.com to convert it to a workable JSON.