Galen's Adventures in Programming

My initial self-challenge seemed simple enough: draw some hexagons.  Have you ever read the book "The Little Prince" by Antoine de Saint-Exupery, where the pilot draws a boa constrictor digesting an elephant, and everyone tells him he's drawn a hat?  That's how my it felt to draw hexagons in React Native.  All I had to do was keep re-imagining what a hexagon WAS, and drawing it became simple. I decided that I didn't want to import a hexagon library to draw my hexagons - instead I wanted more opportunity to play with React Native styling, and draw them that way.  I found a couple of articles online that represent a hexagon as 3 pieces: a rectangle with 2 triangles.  Here's one example .  "Cool," I thought.  "I can do that."  So I drew a hexagon. My First Hexagon However, I wanted to be able to dynamically change the hexagon's shape, which lead me to discover this website of geometry equations to calculate side measurements

COVID-19 has changed the world around us, and lives in the back of my mind perpetually.  I have friends who are out of work, and parents who my brother and I have to plead with to stay inside.  My husband and I have started having virtual board game nights, which brought up a board game that my friend and I designed a few years back: Witch's Wood. My friend and I agreed that neither of us wanted to play the game as it was, since as a board game it requires a lot of work from the players to update the board each turn.  However, if it was a mobile game (and therefore did those steps automatically) we would both give it a chance. So that's my new challenge for myself.  Progress will be slow, but it will be a chance to learn React Native, build a mobile app, and do something to distract myself from what's happening outside of my apartment building.  Who knows?  At the end of this I might even have a playable game. I will be setting myself a goal for each week, and doing my b

I have an on-site interview tomorrow, and have decided that I am going to approach the technical component a little differently than I usually do.  It's easy, in an interview situation, to feel like I am in a position where the wrong answer could tank my career, and it's pretty obvious that that mentality is not going to be helpful.  Instead, I am going to approach my technical interview as though I were getting to spend an hour debugging/problem solving with a partner, which is something that I love to do. While I was in Launch Academy, I would take an afternoon "break" from studying and ask in Slack whether anyone in my cohort would like an extra set of eyes on a problem.  It was a lot of fun listening to someone else walk me through what they wanted their code to be doing, and help them strategize how to get there from what the code was currently doing.  If I can approach a problem in a technical interview like one of those afternoon "breaks," hopefully

As I sit here in a hotel room, spending some quality time on Code Signal  (previously CodeFights), I am reminded of a different hotel stay when I first began my official journey to becoming a developer.  I had taken computer science and JavaScript classes years prior, but that was the year I had committed to taking a programming bootcamp and making my dream job into my career. Let me take you back to a sweaty, tropical night in Florida.  It was clearly October because the rain lasted all day, instead of a single hour or two in the afternoon (plus it was my birthday, so the month was pretty clear to me.)  I had spent all day running around the Magic Kingdom at Disney World with my husband, and now we were back in the room and he was fast asleep.  I took out my new-to-me MacBook Pro, and did my very first lesson for my programming bootcamp in a new language: Ruby. I will never forget that trip, for so many reasons.  There was the ice cream sundae riverboat cruise with princess Tiana,

It's amazing how important it is to practice for technical interviews.  When I first heard it suggested I thought that it was so you could have experience with the problem your interviewer gave you, but the more I interview the more I think it's about re-wiring your brain to work with logic problems.  It's sort of like crosswords - if you jump right into a hard crossword, you might get one or two unconnected answers and walk away thinking crosswords are impossible. If you start with something simple, though, you can get in the rhythm.  You might recognize a clue or two, or subtle hints in how the clues are worded that will lead you down one thought process as opposed to another.  You might not finish the crossword, but you will at least get one chunk of it finished, and feel like maybe you can do this (with more practice.) The more you practice, the bigger that chunk will get, until you have a crossword with maybe one or two blanks.  Then if you tackle that hard one from

Today was a big milestone for me - I completed my first coding assessment as part of an interview process.  It was 25 minutes of just me and the computer, sharing my screen and trying to type comments of my thought process so the person watching my assessment later isn't just watching a static screen as I thought about the best way to go about it.  My solution wasn't very elegant, but I think it did solve the problem. The best part about the whole coding assessment--even though I was nervous about 25 minutes deciding whether or not a company would want to continue the interview process--was that it was still fun!  Regardless of whether my solution was correct or not, or whether my thought process was sufficient to allow me to continue on in the interview process, I really enjoy writing code.  That's what it all comes down to, and I am so lucky that I have the opportunity to make money doing something that I enjoy this much.

My six-month engineering internship at One Door is winding to a close, and I am amazed at how much more comfortable I have become with the everyday process of being a developer in a workplace.  Git has been described as something that is "hard to learn but once you know it, hard to live without."  The ability to be working on a feature on one branch, then be able to (on the same machine) easily look at a different version of the code to help debug something is incredible.  The fact that developers can treat this as unremarkable is even more incredible. I wish that I had kept up with this blog a little better while working, but I have been absorbed by what I am learning every day and what new tasks I have been given.  Working as part of a team has been amazing, and the best feeling is when you are taken off of one team and put on another specifically because they asked to work with you.  That's not to say I haven't made my share of "new developer mistakes,"