I published my first ever “brag doc” last year (inspired by Julia Evans’ post “Get your work recognized: write a brag document”), and just like Julia promised, it was a super helpful tool when it came time for year-end reviews (and for self-reflection in general).
Keynote: Kent Beck
Keynote: Kerri Miller
I’ve been meaning to get around to keeping a “brag doc” ever since I read Julia Evans’ excellent post on the subject, “Get your work recognized: write a brag document”. September is a little late to start one for 2020, but hey, why put it off any longer?
One of my preferred strategies for staying up to date in tech is newsletters. Call me old school, but I love a good email newsletter. A curated list of recommended blog posts, talks, and career opportunties delivered directly to my inbox? Yes please, much appreciated. I’m subscribed to a ton of them, and I’ve found them immensely helpful for staying on top of things.
I’m reading “Accelerate” by Jez Humble, Gene Kim, and Nicole Forsgren along with some folks at work (including author Nicole Forsgren, Ph.D!)
I’m reading “Building Git” by James Coglan along with some fellow and former co-workers. Here’s my notes on each chapter.
I’m reading “Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems” by Martin Kleppmann as part of a technical book club at work. We’ll be covering a new chapter each week for the next ~12 weeks. Here’s my notes on each chapter.
At the end of 2019, I started looking for a new software engineering job, something I hadn’t done in almost five years. I’d been very involved with my previous company’s hiring process, helping design our interview process and running dozens of interviews for engineering and product team candidates at every level and role, so I thought was ready to be on the other side of the table.
I was working on a Rails project recently where we needed to 1) track the location of fine art delivery trucks and 2) give dispatchers visibility into which trucks were closest to a given location. Perfect use case for the Ruby
geocoder gem, right?
Here’s the scenario: you’re working with Elixir and Ecto, and you need to retrieve data from a table plus maybe a field or two from an unassociated table. In the past, whenever I ran into this, I’d spin up something I wasn’t totally satisfied with - maybe updating the schema(s), breaking it up into multiple queries, or building a multi-select statement if I was feeling fancy.
Modern Monitoring and Observability with Thoughtful Chaos Experiments by Datadog and Gremlin (webinar)
Notes from “Chaos engineering” webinar with Datadog and Gremlin.
Notes from Flatiron School engineering team’s training day with AWS.
Learnings from @bobjnadler’s time at Siemens & Cyrus.
Guest speakers: Noah Davis and Fred Creech from Code Climate
Challenge: introducing DDD in a legacy codebase
A code reading by @spencer1248
A code reading by @gj
Notes from Flatiron School engineering team’s code reading on future ops work.
Notes from Phil Sturgeon’s code talk at Flatiron School, 3/15/2018.
At the Flatiron School, our mission is to help people learn how to code. That means that as a member of the engineering team, my work reminds me almost every day of that important, universal truth: learning new stuff is hard.
aka The Little Submission That Could
A Story About Asynchronous Actions, Dynamic Workers and Queues, and RabbitMQ.
Low level talk about how information moves across the internet.
Notes from Flatiron School engineering team’s code reading by @joshrowley, part 1.
Notes from Flatiron School engineering team’s code reading on applying domain driven design principles to our legacy Rails codebase.
Yep, you read that right. My bash color settings broke edeliver, the tool my team uses to deploy our Elixir apps.
You’d think the answer to this question would be a simple Google search away. Unfortunately, that wasn’t the case for me this afternoon, working on a Phoenix project with a newly-added Ecto backend. In an effort to save others (and let’s be honest, future me) the same frustration, here’s the most straight-forward solutions I found.
Software developers, have you ever felt misunderstood by your non-developer teammates? It happens to most of us, which is why I wrote this post to help clear up some of the most common misunderstandings, miscommunications, and missed opportunities. Feel free to pass it along to anyone who’d love to have an easier time working with developers.
Notes from Flatiron School engineering team’s code reading on using GraphQL with our core codebase.
Notes from Flatiron School engineering team’s code reading on using Docker with our core codebase.
A fascinating glimpse into Spencer’s server config process.
Back in January 2016, our CSS was easily the messiest part of the Learn.co codebase… something that probably sounds familiar to many other web developers out there. Last spring, we budgeted time and resources to overhaul it. I led that project. Here’s what we learned.
Notes from code reading on Flatiron School eng team’s shared React from library by Seiji Naganuma.
A crash course in React and Redux from Steven Nunez, Lead Instructor/Developer at Flatiron School (part 2).
A crash course in React and Redux from Steven Nunez, Lead Instructor/Developer at Flatiron School (part 1).
Flatchat is our in-house replacement for Slack, which we’ll be moving our users off soon.
Discovered a super handy Postgres extension tonight:
fuzzystrmatch. This lil cutie is a real godsend when dealing with potentially crummy user input, such as, oh say, for a Rails project where you’re requiring your less-than-tech-savvy relatives and future inlaws to input their email address in order to access your wedding website. Note: said website is badass, built-from-scratch, and open source.
All tips courtesy @devinburnette
Notes from Flatiron School eng team’s intro to React code talk.
When I first started out learning to code, the idea of contributing to an open source project was really intimidating. I got that advice from everyone - “Contribute to open source! It’s so easy! Employers love it!” - but I was still hesistant. I’d only been writing Ruby for a couple months; how was I going to contribute anything useful to someone else’s project?
Keyboard shortcuts are a programmer’s best friend, and Sublime Text lets you write your own. I use these five below on a daily basis, and you’re going to want to, too. Here’s the setup:
I’ll keep this concise, in the spirit of less is more.
truncate_html gem is a really useful tool for clipping off a string of html at a designated point. It has some nice customizeable config options, and best of all, zero third party dependencies. Per its docs, it even does the unthinkable:
If you ever find yourself in a Rails-situation where you need one model to belong to multiple other models, consider using an ActiveRecord polymorphic association. Don’t let the multisyllabic name fool you; polymorphic associations aren’t as complex to build as they might seem. You can do it.
As I was updating some content on my personal website today, I noticed the copyright date in the footer still read “2014”. Yeah, it’s May. Go me.
I’m a firm believer in the “make it work” philosophy - solve problems first, then refactor. That said, my team may have gotten a little too creative making our last project work. Just take a look at this gnarly method we cooked up:
The first time I tried to apply “dynamic selection” within a Rails form - where selecting an option in one select field dynamically updates the menu options in a second select field, I had a surprisingly hard time with it. I’d watched the Railscast and read multiple tutorials, but just couldn’t crack the code.
This week’s Ruby Weekly had a nice post from Matt Brictson on “Setting up Sublime Text 3 for Rails Development”. It reminded me to finally install the SublimeLinter-rubocop package. This package syncs your linter up with rubocop, highlighting “bad code” as you type (according to the community Ruby Style Guide). Great addition, right?
I had a really fun time this weekend building a small side project with Sophie DeBenedetto, Jeremy Sklarsky, and Rachel Nackman. We learned a lot of very cool things that you can do with Rails + jQuery, but the coolest was easily
remote: true. This one little option is crazy powerful. Case in point: by adding
remote: true to our
Search form, our
searches.js file went from this:
Back in my former life as an art historian / art shipper, it wasn’t enough to simply know about art. You had to know about the other people who know about art - the key figures shaping the field, your peers working on the same stuff you were - that was just as critical as being able to recite off Greek column types or the core members of the Arte Povera movement (which I can still do, thanks very much, humanities degrees).
After week one of learning Rails, I was eager to test out my new skills on a new side project. I wanted to build something fairly simple, that would utilize skills I felt comfortable with - JSON parsing, ERB, simple search and routing - while also pushing me into uncharted territory, like deploying on Heroku. I spent the afternoon brainstorming, circling around some sort of app that would answer a single simple question (like Is It Raining?, one of my fave single serving sites). I had a couple good ideas, but my partner came up with the best one: is Hillary winning?
Note to self:
Last week, Avi pitched a pretty cool idea to the class: build an “auto-follow bot” for Flatiron student twitter accounts - something we could use to easily auto-follow everyone in the class.
When I was just starting out learning to code, it quickly became clear I’d be spending a lot of time in Terminal. Never one to skimp on workspace feng shui - just ask my old art world colleagues - I set about post haste to fine tune the CRUD out of my bash profile, starting with the bash prompt.
Flatiron School has a great system for sharing lecture notes: a dedicated GitHub repo. I forked the repo during week one, thinking I’d pull down the files to my local, take notes on the notes (Inception-style meta-noting), then push back up to my forked repo. No sweat.
One of the main tenants of the The Flatiron School is “Always be a beginner,”* which has been pretty easy for me to embrace so far, since I am the noobiest of coding noobs right now. Pretty much every day, I’m reminded of my beginner-dom, even in realms I thought I’d more or less mastered.