I’m reviving a 2013 MacBook Pro with a clean install and fresh setup. This is mostly documentation for myself.
Install some apps
At this point I decided to take the opportunity to learn something new. A coworker had recently taught us about dotfiles at our weekly tech check-in, so I wanted to see if I could install the rest of my apps using Homebrew.
I installed Homebrew and Homebrew Bundle and created a Brewfile based on what I had installed on my work machine. I created a dotfiles folder in my Documents folder and stored the Brewfile in the dotfiles folder. Then I opened that directory in Terminal and ran
Last couple of steps to reach basic usability:
- make bash auto-complete case insensitive with
echo "set completion-ignore-case On" >> ~/.inputrc
- setup git/ssh keys
At this point it’s been about 1.5 hours since I started.
My Specific App Setup / Persnickety Shit
Add licenses for Alfred, Bartender, BetterTouchTool and HyperDock
Setup/log into Airdroid, Alfred, Bartender, BetterTouchTool, Franz, HyperSwitch, HyperDock, Kindle, ReadKit, Slack, Spillo, Stretchly, Todoist (copy settings for ReadKit and Spillo from previous settings manually)
Add Spillo, ReadKit, Chrome, Slack, Franz to dock
Install SetApp apps
Customize right-click menu
Enable dragging by swiping on trackpad:
System Preferences > Accessibility > Mouse & Trackpad > Trackpad Options > Enable dragging
Enable git colorized output:
git config --global color.ui auto
Setup VSCode with Settings Sync extension (Gist)
A co-worker recently brought to my attention that I always reach for
console.log when I’m trying to figure out why some code is not behaving as I expect. It’s rather like always reaching for a hammer and ignoring the screwdrivers and wrenches. Sometimes a hammer is the right tool. Sometimes it’s not. Ultimately, scattering
console.log around your code like fairy dust is not a particularly effective debugging method.
These are some things I’m reading to branch out and get comfortable with more debugging tools and techniques:
- /dev tips
- How to stop using console.log() and start using your browser’s debugger
- CSS Debugging and Optimization: Browser-based Developer Tools
- Art of debugging with Chrome DevTools
- Tips and Tricks for Debugging in Chrome Developer Tools
- Conditional Breakpoints in Chrome are Awesome
I hope these links are helpful to others looking to improve their debugging processes!
A new school year means another year of teaching with ScriptEd. This will be my 5th year! I’ve been reflecting on how much I’ve grown since my first year with ScriptEd:
I had the worst stage-fright and could barely get through a 5-minute lecture without becoming breathless and shaky. Once I actually stopped in the middle of a lecture and ran out of the classroom, leaving the other volunteers to pick up where I left off. While I’m still no TED speaker (though ScriptEd’s co-founder is), I can get through a class without heart palpitations. I don’t have to read directly off the slides and it doesn’t completely throw me off-track when I stumble over something or when a student interrupts with a question. I’ve even given talks at QueensJS and DjangoGirls events.
Teaching has also improved my ability to communicate at work: I use similar strategies to explain technical concepts to producers and product managers so they understand what I’m working on, struggling with, or need clarity on.
I have more empathy, patience, self-confidence, and new friends among my fellow volunteers.
Teaching is one of the hardest things I’ve ever done, and its also an amazing way to learn.