<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en"><generator uri="https://jekyllrb.com/" version="4.3.2">Jekyll</generator><link href="https://alshedivat.github.io/feed.xml" rel="self" type="application/atom+xml"/><link href="https://alshedivat.github.io/" rel="alternate" type="text/html" hreflang="en"/><updated>2023-02-25T19:45:14+00:00</updated><id>https://alshedivat.github.io/feed.xml</id><title type="html">blank</title><subtitle>A simple, whitespace theme for academics. Based on [*folio](https://github.com/bogoli/-folio) design. </subtitle><entry><title type="html">Rails Authentication and Small Increments</title><link href="https://alshedivat.github.io/blog/2023/rails-auth-and-increments/" rel="alternate" type="text/html" title="Rails Authentication and Small Increments"/><published>2023-02-25T15:59:00+00:00</published><updated>2023-02-25T15:59:00+00:00</updated><id>https://alshedivat.github.io/blog/2023/rails-auth-and-increments</id><content type="html" xml:base="https://alshedivat.github.io/blog/2023/rails-auth-and-increments/"><![CDATA[<p>I am starting working on a side project, a small web-app that I’ll use to track data from workouts. I have been documenting my workouts for years with pen and paper in journals, and that mostly works fine.</p> <p>I can write my plan for the current day, document what actually happens, and then see how things have gone in previous weeks, months, and years if I feel like sorting through them. There is a stack of these journals in my garage.</p> <p>I want to digitize this process so that I can use less paper, and eventually do a little data analysis and graphing. There are tons of options out there, but I have been wanting to build something and this seems fun.</p> <h2 id="first-use-case">First Use Case</h2> <p>The first thing I want to do (after getting my local environment setup with recent versions of Rails and Postgres) is create a notion of a user and figure out some way to authenticate a person.</p> <p>There are tons of options for authentication for Rails apps, and sorting through them gets overwhelming quickly. Each time I read through a new gem, I thought to myself – that is pretty cool but it’s also time consuming to set up and manage and definitely overkill.</p> <h2 id="incremental-delivery">Incremental Delivery</h2> <p>I think about the intersection of context and immediate value a lot at work. Lets say you’re building a home gym and want to mostly do barbell movements. You could get a mono-lift, a separate platform for deadlifts, a belt squat machine, and so on. I’d definitely like all of that. But I also want to start now.</p> <p>So we have to think about the real problem: Justin wants to do squats and deadlift a few times a week, and doesn’t have time to spend driving to the gym.</p> <p>What is the smallest thing we can do to help him get started?</p> <p>There are lots of modular power racks available, he probably needs a barbell and some weight, and also a platform to set that equipment on. This can be purchased and built in a couple of days.</p> <p>This setup is extensible with different attachments, and can grow over time as there is need and want.</p> <h2 id="back-to-auth">Back to Auth</h2> <p>So, what is the fastest way to get going with authentication? Token based auth. Rails supports this by default, and all it depends on is a User Model and a controller which finds a user and verifies there is a current token.</p> <p>This approach took about an hour to set up, and when it’s no longer viable (maybe friends and family want to start logging in or I want to make the data more secure), there is always Devise and OAuth.</p> <h2 id="next">Next</h2> <p>I don’t want to get too far without having CI set up, so the next thing I’ll be working on is getting something setup that will run tests. I’m think github actions or maybe a Travis CI at the moment.</p>]]></content><author><name></name></author><category term="side-project"/><summary type="html"><![CDATA[I am building a small web app that will be used for tracking data around workouts. The first thing I want to build is user authentication, but there are an overwhelming number of options available. Thinking about what can be done now, and allow for future growth was a good exercise in context and incremental delivery.]]></summary></entry><entry><title type="html">Problem Solving Post-morten</title><link href="https://alshedivat.github.io/blog/2023/problem-solving-flow/" rel="alternate" type="text/html" title="Problem Solving Post-morten"/><published>2023-02-11T15:59:00+00:00</published><updated>2023-02-11T15:59:00+00:00</updated><id>https://alshedivat.github.io/blog/2023/problem-solving-flow</id><content type="html" xml:base="https://alshedivat.github.io/blog/2023/problem-solving-flow/"><![CDATA[<p>I wrote an internal blog as a sort of autopsy on how I work through a problem starting with no context. This was a question I got in a comment.</p> <blockquote> <p>How do you feel about all of this?</p> <p>This post looks like a report about what happened. It would be interesting to read about your thoughts and opinions about this experience.</p> <p>What would you do differently? How are you going to maintain this moving forward? What do you want to tell your future self? What would you tell junior engineers who are just starting out with this kind of problem solving process?</p> <p>The joy of blogging is re-reading this in few months and saying to yourself “What was this guy thinking?” or “Whoa, this is still completely true!”</p> </blockquote> <h2 id="flow-state">Flow State</h2> <p>I wasn’t actively thinking about my process when I was working through this, and in hindsight, that is a really good sign. I was able to intuitively read through the problem, formulate some ideas and questions, ask those questions, and then I used a template for my response and everything fell into place.</p> <p>6 months ago, that would not have been the case. I would have read, and re-read the problem, then spent time doing an unorganized investigation. That unorganized investigation would have led me to poorly formed questions, that would have (unsurprisingly) not pointed me toward any useful direction.</p> <p>The fact that I was able to get into that flow state tells me the professional-development work I have been doing is useful and paying off. That work is like exercise, or flossing your teeth. Any one day in particular doesn’t matter. Consistent effort over periods of months and years makes a big difference though.</p> <p>For this particular problem, the only thing I might have done different is time-box activities more tightly. I’d pay attention to how long I was investigating before asking a question, and then give a small period of time to create and send the final report. Paying attention to time would probably have cut 10 or 15 minutes off the total time spent.</p> <h2 id="going-forward">Going Forward</h2> <p>Accomplishing one thing is great, I want to keep the momentum. My plan is to</p> <ul> <li>continue honing my problem solving template as necessary</li> <li>continue practicing solving problems that are just out of reach fo my current ability by taking P1 issues, daily programming exercises, and pairing with team mates (or anyone really) on hard problems</li> </ul> <p>To other people wanting to improve their problem solving ability and personal velocity I’d suggest</p> <ul> <li>make a personal template for how you approach problems and lean into it. Use it on every programming problem you approach no matter how small <ul> <li>my current template is restate the problem, inputs, outputs, brute force solution</li> </ul> </li> <li>time box your investigations (I use a small digital timer for amazon)</li> <li>develop the ability to ask well-formed / precise questions.</li> </ul> <p>I’d also suggest reading chapter 1 of <a href="https://www.goodreads.com/en/book/show/13590009">Thinking Like a Programmer</a>.</p>]]></content><author><name></name></author><category term="problem-solving"/><summary type="html"><![CDATA[I had a request at work to give an estimate on how how difficult some work might be. The challenge was that I had very little context in the code base that would need work, and I had about an hour to get the answer. This is a debrief on that hour of work, and a few takeaways that might be useful for people trying to improve problem solving, particularly when time is heavily constrained.]]></summary></entry><entry><title type="html">Be Ready to Run Any Meeting</title><link href="https://alshedivat.github.io/blog/2023/run-any-meeting/" rel="alternate" type="text/html" title="Be Ready to Run Any Meeting"/><published>2023-02-11T15:59:00+00:00</published><updated>2023-02-11T15:59:00+00:00</updated><id>https://alshedivat.github.io/blog/2023/run-any-meeting</id><content type="html" xml:base="https://alshedivat.github.io/blog/2023/run-any-meeting/"><![CDATA[<p>I’ve been reading through the Staff Engineering book over the past few weeks. I finished it yesterday and will probably read through the interviews again in 6 months or so. One of the take aways (there were many) is that an experienced team member should be able to lead any meeting. That doesn’t mean talk the whole time, or dominate the conversation to get their way….but know enough about what’s happening to get the conversation moving a long.</p> <h2 id="i-have-done-this-in-two-ways-recently">I have done this in two ways recently.</h2> <p>The first was last week when I was supposed to run retro. I had completely forgotten that it was my turn, and had to come up with (thats a clever way of saying “copy and paste”) a miro board, and then facilitate the team through a retro.</p> <p>The second was this morning. I am leading a team run of the educative.io OOD course. Last week the whole team was here, so it was easy to fill up the time. This week two team members didn’t make it, and one was unable to talk on the zoom.</p> <h2 id="so-how-was-i-able-to-do-this">So, how was I able to do this?</h2> <p>You don’t need to be an expert on anything in particular to run meetings, but you do need context and a sense of what conversations need to happen. Also, a willingness to provide guardrails to sometimes ensure that the meeting goal is being achieved, and other times to let go and realize that the current conversation is more important.</p> <p>This is what I did to develop this ability</p> <ul> <li>develop team context <ul> <li>know what your teammates are working on, how those things go together</li> </ul> </li> <li>develop cross team context <ul> <li>understand how a cluster of teams (core teams for example) are working, and how those goals tie together</li> </ul> </li> <li>develop company context <ul> <li>what does your organization currently value, what it the current top two goals</li> <li>what skills and behaviors does your organization value from a person in your role</li> </ul> </li> <li>pay attention to what is happening in general dev conversations</li> <li>take detailed notes</li> </ul> <p>The general ideas above can be summarized by saying, be attentive, present, and seek opportunities to get experience.</p>]]></content><author><name></name></author><category term="senior-mindset"/><summary type="html"><![CDATA[Experienced engineers are often expected to run meetings without much notice. This might be a meeting where I get a quick overview of a business need, and then am expected to give an estimate on feasability and effort. This might be a retro when the normal facilitator is out on vacation. Regardless of how much information I have on the subject, I still need to be able to make sure we can move forward as a group.]]></summary></entry></feed>