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.
The little interactive examples where they have you click and count the function executions are really great.
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 😅
“You don’t become a programmer by learning quickly.
You become a programmer by learning a little bit every day, forever.”
Code like a dumbass:
- Use simple data structures.
- Use the simplest design patterns.
- Write simple code.
- Test your code since you don’t trust your dumb ass to handle all cases.
- Automate tests since your dumb ass will break the code in the future.
- Automate linting because you can’t agree with yourself on code style.
Coding like dumbasses, I think, is the only way we can write software that is easy to understand and maintain later.
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.
Any time I go back and think about what I should have done at a particular juncture, the answer of what went well, or what I should have done, was to bias my actions toward having completed another project, or mini-project, or practice question, or even just an experiment in my browser console.
DAY 1307
An editor extension I’m using was generating some .json files with its settings, and this came in handy to ignore them everywhere.
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.
I’m going to try and get better at recognizing this type of confusion earlier on, and saving myself a lot of worries in the future.
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.
10.
I wanted to see if I could pull it off. It was really scary and awful
and satisfying and fun. I would never have thought of something like
this in the past but I was lucky enough to have some savings finally,
and was also inspired by some friends who talk about things like early
retirement and generally just finding another path that makes you happy
besides the default one.
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:
For even a simple game like this, the list of questions can just keep growing and growing, until it’s very easy to see how answering them can become someone’s full time job =D
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:
(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
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.
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.
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.
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.
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!
I believe getting unstuck is the number one most important skill to be successful in a programming job, and learning to do it better will make you more productive in every other way.
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.