(import this)

Trail Fixes

2024-12-01T00:00:00+00:00

Trail Fixes</h1>

Cost Center or Loss Prevention Center

2024-01-08T00:00:00+00:00

Changing the Narrative Around Business Cost Centers</h1>
In the business/accounting world there's this concept of Revenue Centers</a> and Cost Centers</a>. Revenue Centers are used to track revenue and Cost Centers are used to track costs. This is great until you start applying it to the intrinsice value of those groups of people</em>.</p>
Example: multiple companies that I've worked for in the past have treated Security, DevOps, QA/QC, and Technical Support as Cost Centers. While this may be true in a strictly accounting sense, is that really the case in a practical sense?</p>
If so, then a quick way to cut costs is to cut out those business units. Very quickly you'll see the quality of what you produce drop, customer confidence in the product go into the toilet and you're left wonder "what happened?!"</p>
What happened is the same thing you see in a retail store if you get rid of your loss prevention specialists. I.e., the people you hire to reduce the amount of products stolen ("shrink" in the industry).</p>
Loss prevention is just that. It's not a "Cost Center", it's a "Loss Prevention Center". This equates to more revenue.</p>
It's not a far stretch to say that it's a revenue center. Though I know some will balk at that.</p>
What is loss prevention but the simple act of capturing revenue that would have otherwise been lost?</p>
I'm sure it's not hard to see the parallels to the software world, Security, DevOps, QA/QC, and Technical Support. Especially Security, that's a little on the nose if you ask me.</p>
These are your "loss prevention specialists". They're a loss prevention center, not a cost center. They help you capture revenue you would have otherwise lost out the door unnoticed</em>.</p>
And you know what? In a lot of cases these are the most important people in your organization. Treat them as so.</p>

What I'm Currently Doing

2023-12-31T00:00:00+00:00

What I'm currently Doing</h1>
Work</h2>

Fantastic company (Recharge</a>) that really cares about the people that work for them and their clients</li> </ul>
Learning</h2>

Offroad vehicle recovery, maintenance, driving (perpetually)</li>
Mindfulness Meditation</li>
Stoic Philosophy</li>
Welding</li>
Rust</li> </ul>
Hobbies</h2>

Volunteering with Colorado 4x4 Rescue and Recovery (CO4x4RnR</a>)</li>
Active volunteer with Burning Man</a>

Center Camp Guardian</li>
Temple Guardian</li>
Black Rock City Ranger</li> </ul> </li>
"Making" in general, there's a wonderful feeling when there's a thing you made that wasn't a thing before.</li> </ul>

Tools I Use

2023-12-31T00:00:00+00:00

Uses</h1>
A succinct overview of tools I use on a regular basis, mostly focused on my day job of software development but possibly other random stuff thrown in.</p>
Software</h2>

Editor

NeoVim (AstroNvim)</li>
VSCode: rarely used now</li>
~Emacs (Doom) https://github.com/doomemacs/doomemacs~</li> </ul> </li>
Browser

Brave</li>
~Firefox~</li> </ul> </li>
Utilities

DevUtils: One-off tools, base64 encode/decode, format and validate JSON, etc, really handy to have always running.</li>
Amethyst: Automatically size/move windows</li>
Raycast: Quick switcher and finder of files</li>
GitKraken: The best (IMO) GUI git client</li>
Syncthing: Dropbox kinda-sorta replacement</li>
Blurred: Darken windows that aren't the active one (i.e., know where your cursor focus is)</li>
Zola: Static site/blog generator</li>
~Finda: Find anything on your computer + quick switcher~</li>
~Quicksilver: Quick switcher~</li> </ul> </li>
Terminal

Alacritty w/ tmux or zellij</li>
Wezterm</li>
FishShell</li>
Starship: Enhance your command line</li>
~zsh: Better than bash, more posix compliant than fish~</li>
~iTerm2: I'd like to use something else, but this works the best for now~</li> </ul> </li> </ul>
Services</h2>

ProtonMail: Personal email</li>
YouNeedABudget: Finance tracking</li>
Deezer: Music</li>
Github: Off-computer code backup</li>
Gitlab: Off-computer code backup, blog</li>
Kagi: Search engine</li>
Dropbox: Backup & sync</li>
Bitwarden: Password manager</li>
xBrowserSync: Sync your bookmarks across multiple devices and multiple browsers. Also offers a pretty killer search.</li>
A Fine Start: pseudo-bookmarks on your new tab screen</li>
~1Password: If you're not using a password manager, you've already been compromised and just don't know it yet~</li>
~Feedly: I love my RSS feeds~</li> </ul>
Hardware</h2>

MacBook Pro (i.e., whatever work provides me)</li>
Alienware R7 (desktop/personal machine)</li>
ZSA Voyager Keyboard</li>
Streamdeck</li>
Kensington Slimblade Trackball</li>
Logitech MX Master 3</li>
Remarkable2</li>
Pixel 7 Pro</li>
~Ultimate Hacking Keyboard https://ultimatehackingkeyboard.com/~</li> </ul>

Log all (fish) commands

2023-04-08T00:00:00+00:00

Log all non-sudo commands in fish-shell</h1>
All credit (and inspiriation) to:</p>

https://www.justinjoyce.dev/save-your-shell-history-to-log-files/ (zsh version)</li>
https://spin.atomicobject.com/2016/05/28/log-bash-history/ (bash version)</li> </ul>
tl;dr:</h2>
Copy this into your ~/.config/fish/fish.config</code> file:</p>
# log every command function cmd_log --on-event fish_preexec if test (id -u) -ne 0 # if we're already sudo, don't log echo $(date "+%Y-%m-%d.%H:%M:%S"): $(pwd): $argv >> ~/.logs/cmd-history-$(date "+%Y-%m-%d").log end end </code></pre> Explanation</h2> Note: I'm no fish/bash/zsh scripting expert so take this with a grain of salt!</p> function cmd_log</code>: Create a new fish function.</p> --on-event fish_preexec</code>: Fire this function before every command.</li> </ul> </li> if test (id -u) -ne 0</code>: If we're not already</em> sudo, then log. Note, this won't prevent sudo ls</code> commands from being logged as we weren't sudo at the time the command started</em>.</p> </li> echo</code>: Don't run, instead spit the output out.</p> $(date "+%Y-%m-%d.%H:%M:%S")</code>: Current date/time in descending format (sortable).</li> $(pwd)</code>: Print the working directory.</li> $argv</code>: Grab the entire command and all args.</li> >></code>: Append stdout (the entire echo command) to the end of...</li> ~/logs/cmd-history-$(date "+%Y-%m-%d")</code>: Today's log file.</li> </ul> </li> end</code>: End the if</code> statement.</p> </li> end</code>: End the function.</p> </li> </ul>
Bolt Grades 2022-08-09T00:00:00+00:00 Bolt Grades</h1> Bolts and Hitch Pins come in both unrated and rated. For the 4x4 application we'll be attempting to deal with rated gear only. Most hitch pins are not rated, however rated pins can be found, normally called Tractor Hitch Pins or Farm Hitch Pins. In a pinch, a properly rated bolt can be used as a hitch pin.</p> Below you'll find common grades of bolts/pins, identifying characteristics, and strength. In use as a hitch pin the important rating to look for is the Double Shear</em> strength.</p> Common Grades</h2> Grade 5 (8.8) 1/4" - 1"</h2> Identification 3 hash marks 120 degrees apart</li> Grey/Silver in color</li> Breaks suddenly</li> </ul> </li> Strength Proof Load: 85,000psi</li> Tensile: 120,000psi</li> Yield: 92,000psi</li> Shear: 72,000psi (~60% of Tensile)</li> </ul> </li> </ul> Max Force (lbs)</p> Diameter</th> Single Shear</th> Double Shear</th></tr></thead> 1/4</td> 3,534</td> 7,069</td></tr> 5/16</td> 5,522</td> 11,045</td></tr> 3/8</td> 7,952</td> 15,904</td></tr> 1/2</td> 14,137</td> 28,274</td></tr> 5/8</td> 22,089</td> 44,179</td></tr> 3/4</td> 31,809</td> 63,617</td></tr> 7/8</td> 43,273</td> 86,546</td></tr> 1</td> 56,549</td> 113,097</td></tr> 1 1/4</td> 77,313</td> 154,625</td></tr> 1 1/2</td> 111,330</td> 222,660</td></tr> </tbody></table> Grade 8 (10.9)</h2> Identification 6 hash marks, one for each side of the bolt</li> Bronze/Gold in color</li> Yields before breaking</li> </ul> </li> Strength Proof Load: 120,000psi</li> Tensile: 150,000psi</li> Yield: 130,000psi</li> Shear: 90,000psi (~60% of Tensile)</li> </ul> </li> </ul> Max Force (lbs)</p> Diameter</th> Single Shear</th> Double Shear</th></tr></thead> 1/4</td> 4,418</td> 8,836</td></tr> 5/16</td> 6,903</td> 13,806</td></tr> 3/8</td> 9,940</td> 19,880</td></tr> 1/2</td> 17,671</td> 35,343</td></tr> 5/8</td> 27,612</td> 55,223</td></tr> 3/4</td> 39,761</td> 79,522</td></tr> 7/8</td> 54,095</td> 108,190</td></tr> 1</td> 70,686</td> 141,372</td></tr> 1 1/4</td> 110,447</td> 220,893</td></tr> 1 1/2</td> 159,043</td> 318,086</td></tr> </tbody></table> Grade 9 (~12.9)</h2> Identification 9 hash marks</li> </ul> </li> Strength Proof Load: 145,000psi</li> Tensile: 180,000psi</li> Yield: 155,000psi</li> Shear: 108,000psi (~60% of Tensile)</li> </ul> </li> </ul> Definitions:</h1> Tensile Strength: The resistance of a material to breaking under tension</li> Yield Strength: The stress at which a specific amount of deformation is produced</li> Proof Load: An axial tensile load which the product must stand without evidence of any permanent set.</li> Single Shear:</li> Double Shear:</li> </ul> Sources:</h1> Bolt Grade Markings & Strength Chart</a></li> The Tractor Hitch Pin A Critical Component in Keeping Control of Implements - Purdue Extension PPP-94 (special thanks to Chad A. for the recommendation)</li> </ul> Driving 2022-08-09T00:00:00+00:00 Driving</h1> Driver Position</h2> "Dead" Pedal</li> Right foot/leg braced against the transmission tunnel</li> Hips pushed back into the seat</li> Seatbelt ON Only exception is when making a water crossing (roll down all windows as well)</li> </ul> </li> </ul> Steering</h2> "Thumbs out"</li> If airbags hands at 9 o'clock and 3 o'clock</li> If not airbags, hands at 10 and 2 or 9 and 3</li> Shuffle steering Hands move from resting position to the top of the steering wheel in a "pushing" motion.</li> Hands then move back from top of steering wheel back down to resting position in a "pulling" motion.</li> Repeat</li> </ol> </li> Bump steer When the terrain or wheel pushes against the steering, turning the wheel.</li> More prominent in solid-front axles than IFS.</li> Resist the bump steer.</li> Keep thumbs outside the steering wheel.</li> </ul> </li> </ul> Technique</h2> Left Foot Braking/Brake Throttle Modulation</h3> Using your left foot to add back-pressure to the drivetrain, equalizing torque bias, and reducing throttle lag. In an automatic, place your left foot covering the brake pedal. Leave your right foot on the throttle.</li> Before</em> getting to an obstacle, apply enough brake pressure to engage the brakes, but not so much that the engine bogs down or is unable to sustain forward momentum. This may require increasing the throttle to maintain momentum.</li> </ul> </li> Feather the brake with your left foot to adjust your forward velocity and momentum while keeping tension in the drivetrain.</li> This takes a lot of practice to develop a good feel for it and will be different in each vehicle.</li> Once you have a good feel for controlling your momentum with the brake, add in the throttle foot.</li> The goal is to keep the engine RPM's stable while making forward progress.</li> </ul> </li> Can act as a "variable locker" to provide enough resistance on a wheel that is losing or has lost traction to equalize the torque bias and provide enough torque to the wheel that has grip to propel the vehicle forward. If the wheel that has lost traction is a rear wheel, adding hand brake may be the better option than foot brake due to front/rear brake bias (discussed below).</li> </ul> </li> </ul> Hand/Parking/Emergency Brake</h3> Adjusting the front/rear brake bias Brake bias is anywhere from 60-80% biased to the front. This means that when using the foot brake, 60-80% of the braking force goes to the front wheels and only 20-40% to the rear.</li> On-highway driving this serves to stop the vehicle faster as the weight transfer puts most of the vehicle weight onto the front wheels.</li> When using left foot braking/brake throttle modulation, can be used to adjust the back-pressure in the drive train.</li> Off-highway when backing down a slope, this bias can cause the vehicle to be unstable and lurch or lose traction as a large percentage of the weight of the vehicle is now on the rear wheels, reducing the effective stopping power. The most common symptom of this is the front wheels lock up when braking while backing.</li> </ul> </li> Adding a couple of clicks to the handbrake (also called emergency or e-brake) and engaging the rear brakes partway can shift the bias from the front to the rear. When backing down, aim to bias around 60% to the rear. This will provide better braking control.</li> </ul> </li> Starting from a dead stop on a slope In a manual transmission, pulling up on the hand brake can provide enough braking force that the vehicle no longer rolls backward while transitioning from the foot brake to the throttle. This can act as a "third foot". If there is a floor-activated parking brake, this technique isn't effective.</li> In an automatic transmission, this can also help allow the torque converter to build up enough pressure to move the vehicle forward without spinning tires.</li> </ul> </li> </ul> Philosophy</h2> Driving by the rear wheels Front wheels can turn, rear wheels can't</li> Rear wheels track inside the front wheels in a turn, this is known as "wheel cheat".</li> Visualizing where the rear wheels go provides a better sense of the overall position of the vehicle through an obstacle</li> </ul> </li> Reading the terrain Look 10' out, then 50', then 100', repeat</li> </ul> </li> GOAL: Get Out and Look If you can't remember where your vehicle is, lose your line, stop the vehicle for any length of time, etc</li> Your vision is much better outside the vehicle than inside</li> Make sure to look under your vehicle and do a full 360. There is a tendency to only look forward.</li> This includes after getting out of the vehicle for lunch or to take pictures. If enough time has passed for you to forget your line, what was under your vehicle, etc, do a full 360 again. This will help prevent mistakes.</li> </ul> </li> </ul> Drivetrain 2022-05-27T00:00:00+00:00 Drivetrain</h1> Engine</h2> Transmission</h2> Manual</h3> Automatic</h3> CVT</h3> Transfer Case</h2> Part-time 4WD</li> Engages the (almost always) front driveshaft</li> Front and rear driveshaft spin in step with one another</li> If rear driveshaft goes, can drive out in FWD w/ the transfer case engages</li> Various gear reductions are available at the transfer case Jeep Wrangler Rubicon: 4:1 Can roughly treat 4-low - 2nd gear as 4-low - 1st gear in other Jeeps</li> </ul> </li> Other Jeeps: 2.6:1 or 2.72:1</li> </ul> </li> </ul> Center Differential</h2> Full-time 4WD</li> Locking the center diff locks the front and rear driveshaft in step with one another</li> </ul> Driveshaft/Propshaft</h2> Rzeppa Joint Continuous Velocity (CV) joint</li> Consists of 6 large ball bearings running in grooves along with a containing "cage"</li> Allows 45-48 degrees of articulation while some can give up to 54 degrees</li> Can be a weak point in the front driveshaft of lifted Jeeps as the front driveshaft angle changes significantly more than the rear when lifting.</li> </ul> </li> Birfield Joint CV joint</li> Consists of 6 large ball berings running in eliptical tracks.</li> Improved efficiency upon the Rzeppa joint</li> </ul> </li> Continuous-Velocity (CV) Joint Need to be matched or driveshaft loping occurs</li> </ul> </li> Cardian (also called double cardian) Joint Consists of two paired CV joints and a centering mechanism that prevent loping and tend to be stronger at larger angles.</li> </ul> </li> </ul> Axle (L/R) Differential</h2> Locking the axle differential locks the left and right axles/wheels in step with one another</li> </ul> Solid Axle</h2> Full Float</h3> Axle shaft only serves to transmit rotational force from the differential to the wheel</li> "Fully floats in the axle housing"</li> </ul> Semi Float</h3> Axle shaft serves to support the weight of the vehicle and transmits rotational force</li> Axle shaft is held in the housing by a c-clip at the differential. This c-clip can be a weak point and upon failure the entire axle, wheel, and brake assembly will walk out of the housing. Trail fix for this is to use a long rigid "bar" (hi-lift standards work well for this) strapped to the vehicle to keep the wheel from walking out of the housing.</li> </ul> </li> </ul> IFS</h2> Other</h2> Portal Hubs</h3> A planetary gear set is located at the wheel and provides the final gear reduction.</li> </ul> Pinzgauer</h3> Youtube: Pinz Driveline Operation</a></li> 2 differentials "merged together"</li> 2 ring gears offset with a center set of spider gears TODO: understand how the spider gears interact with the ring gears</li> </ul> </li> Allows each side of the axle (halfshaft) to rotate independently</li> Can bust 1 pinion and a ring gear and still keep going w/ lockers engaged</li> </ul> Adult Education 2022-05-10T00:00:00+00:00 Adult Education</h1> Communication</h2> Notes from The First Minute: How to Start Conversations that Get Results</em></p> Intro The first 60s are what matter when communicating professionally</li> Have clear intent</li> Talk on one topic at a time</li> Focus on solutions</li> Steps Frame the conversation in < 15s</li> Create a structured summary of the entire message</li> </ol> </li> Causes of miscommunication Lack of context</li> Unclear purpose</li> Not getting to the point</li> Mixing up multiple topics in the same conversation</li> Giving lengthy, unclear summaries</li> </ul> </li> Framing Context</li> Intent</li> Key message</li> </ul> </li> Summarization Goal</li> Problem</li> Solution</li> </ul> </li> </ul> </li> Chapter 1 The first minute starts when the work conversation starts</li> Only 8 good conversations can turn around a "bad first impression" These chances happen continuously during the work day and doesn't take that long to add up</li> </ul> </li> </ul> </li> Chapter 2: Framing Preparing your audience to receive your message</li> First 15s of conversation</li> Start with 3 statements: Context What is the topic?</li> Never assume the other person knows what you're talking about</li> Name what the topic/tool/subject you're going to talk about</li> </ul> </li> Intent What to do with the information?</li> Categories of intent Needing help/advice/input</li> Requesting action</li> Wanting a decision</li> Letting somebody know that something is going to happen</li> Provide information/input</li> Just chatting</li> </ol> </li> </ul> </li> Key message What is the "headline"?</li> </ul> </li> </ul> </li> </ul> </li> </ul> Notes from Previous TFC</h2> want/need invoke peer pressure</li> team, family, children</li> </ul> </li> solving problems constructionist (build puzzle)</li> destructionist (removing things)</li> cause & effect</li> </ul> </li> instruction list of steps</li> recipe</li> </ul> </li> education enabling problem solving</li> get people to think</li> what gaps need to be filled</li> providing knowledge</li> </ul> </li> training repetition</li> </ul> </li> experience anchoring effect</li> make a connection</li> </ul> </li> feedback becomes a conversation</li> </ul> </li> problem students be humble</li> be a human being</li> allow connection</li> group dynamics</li> </ul> </li> </ul> Additional Notes</h2> Be mindful of the tone you end a sentence with. Ending with an upward inflection is less threatening but also can make you sound weak or less informed.</li> Ending with a neutral or downward inflection lends a sense of confidence in the information you are providing.</li> </ul> </li> </ul> Introduction to 4 Wheel Drive 2022-05-10T00:00:00+00:00 Introduction to 4 Wheel Drive</h1> Notes from Previous TFC</h2> transfer case full-time/part-time - selectable</li> u-joint: 4 points of connection</li> birfield: 6 points of connection</li> no center differential</li> </ul> </li> IFS lower unsprung weight</li> isolates bumps</li> as one side compresses, the other side does as well</li> </ul> </li> Traction Aids differential lock selectable</li> </ul> </li> center differential failures happen in actuator</li> </ul> </li> bearings vs. axel shaft semi float supports weight and rotation</li> full float only provides rotation</li> </ul> </li> tires bias ply (not used anymore)</li> radial</li> caster F/R "casters"</li> camber L/R "off camber"</li> </ul> </li> </ul> About this Blog 2022-05-06T00:00:00+00:00 Why (import this)?</h3> Have always loved easter eggs, open a python terminal and type import this</code> ;). At the same time, I love the simplicity of Clojure and feel like it has embodied, even more-so than Python, the principals in the Zen of Python. Also, it’s a lisp, so you know, parentheses everywhere! They're like ((hugs)) for your code.</p> Potential Blog Topics</h3> Python</li> Rust</li> Clojure</li> Functional Programming</li> AWS Technologies</li> Non-technology specific programming topics (otherwise known as rants)</li> RPG’s</li> Tabletop Gaming</li> 4x4 Search and Rescue</li> Some personal stuff every once in a while</li> </ul> About Me</h3> I’m a professional software developer that’s been coding since I ruined gorillas.bas when I was about 8. Currently, I work primarily in Python, SQL, and with Google Cloud technologies focusing on backend/data processing.</p> Known Biases:</p> Prefers Functional over Object Oriented</li> Prefers Clojure and Python over Java</li> Prefers Tabletop Gaming (RPG and Board Games) over Video Games</li> Socially Liberal</li> Fiscally Realist</li> Black Lives Matter</li> People are people</li> </ul> Hi-Lift Jack 2022-05-06T00:00:00+00:00 Hi-Lift Jack</h1> Parts</h2> </p> </th> </th> </th></tr></thead> 1. Top clamp-clevis</td> 8. Handle socket</td> 15. Cross pin</td></tr> 2. Top clamp-clevis bolt & nut</td> 9. Pitman pin</td> 16. Climbing pin</td></tr> 3. Standard</td> 10. Pitman</td> 17. climbing pin spring</td></tr> 4. Reversing latch</td> 11. Hex bolt & nut</td> 18. Small running gear</td></tr> 5. Handle clip spring</td> 12. Large running gear</td> 19. Shear bolt & nut</td></tr> 6. Cap screw with washer</td> 13. Reversing switch spring</td> 20. Foot</td></tr> 7. Handle (w/ cotter pin)</td> 14. Reversing switch cam bar</td> 21. Handle</td></tr> </tbody></table> </p> Accessories</h2> Lift Mate Single most useful accessory</li> Used for lifting wheels</li> Substitution: a soft shackle, endless loop, or an appropriate length strap</li> </ul> </li> Off-Road Base Prevents the foot/base pushing into the ground</li> Substitution: a piece of > 3/4" plywood</li> </ul> </li> Off-Road Kit (winching kit) Mostly worthless unless you carry chain with removable hooks of the correct size.</li> Substitution: 3 carabiners, 2 x-locks, synthetic extensions</li> </ul> </li> Bumper-Lift Mostly worthless unless you have the specific ARB bumpers it was made for.</li> </ul> </li> Handle-Keeper Worth buying, keeps the handle upright and locked to the standard</li> The newer "quick-fist" style is even better than the kind that slides over the standard and handle</li> Substitution: anything to keep the handle in the upright position</li> </ul> </li> FK-1 Fix-It-Kit Worth buying for the shear pin alone</li> Cannot swap the shear pin for any bolt from the hardware store</li> </ul> </li> First Reponder Jack Conversion Kit The base is the primary thing here, the top clamp clevis comes with the Hi-Lift Extreme as well</li> </ul> </li> Rescue 42 Jack Mate Worth it if you can find it.</li> Significantly improved top clamp clevis that is rated for more than the jack</li> </ul> </li> </ul> Ratings</h2> 7,000lb tested capacity (shear bolt)</li> 4660lb WLL (rated capacity)</li> </ul> Uses</h2> Lifting</h3> Secure the vehicle so as to prevent it from moving once lifted.</li> Verify the reversing latch is in the upright position.</li> Bring the jack to the lifting point.</li> Pull the handle straight up until the nose of the jack is close or in contact with the lifting point.</li> Holding the standard with one hand (keep thumbs out of pinch zones), cycle the handle through 2-3 clicks until the jack will stand on its own.</li> Step back from the jack and verify it is in line with gravity (using trees nearby as a gauge if necessary).</li> Continue cycling the jack putting two hands on or finding a second person to help cycle the jack until the necessary lifting is complete.</li> Use the handle keeper to keep the jack in the upright position while working with the vehicle elevated. Caution! The jack and vehicle are both now unstable.</li> When ready to lower, take off the handle keeper and keep the handle in the upright position. Verify your body is out of the way of the jack and vehicle. Smack the reversing latch with the palm of your hand.</li> Carefully lower the handle until the trigger point. Put both hands on and push down, this will feel very weird until you've done it a few times.</li> Resist the handle until it has cycled back to the "click" point.</li> Repeat until the vehicle only has a little weight on the jack.</li> Once the nose no longer has much weight on it, it will free fall. Make sure any body parts are out of the way.</li> Reset the reversing latch to the up position.</li> </ol> Casting</h4> This can be an effective way to move a high centered vehicle off of an obstacle.</p> Verify that the vehicle, once it moves, will not fall back down on another obstacle and cause additional damage.</li> Raise the vehicle.</li> Have good communication with the driver of the vehicle.</li> Verify the direction of travel and stand behind</em> where the vehicle will move.</li> Have the jack in the raise position.</li> Have the handle of the jack down with two hands on.</li> Your job is only to guide the jack away from the vehicle so that the jack does not get pinned under the vehicle.</li> Have the driver slowly drive off the jack.</li> As they do so, guide the jack away from the vehicle making sure to not put yourself in harms way.</li> Repeat as necessary.</li> </ol> The same procedure can be used to turn a vehicle sideways.</p> Set the jack at an angle leaning toward the direction of desired movement.</li> This may require more or less angle. Distance is achieved with a greater angle. Height is achieved with a shallower angle. Depending on the terrain and obstacles, either may be necessary.</li> Raise the jack and let the vehicle fall off of the jack as it reaches its unstable point.</li> Do not try to stop the vehicle from falling or the jack from moving.</li> </ol> Spreading</h3> Setting the area to be spread between the base/top clamp clevis and the nose of the jack (facing outward away from one another). Very similar to lifting.</p> Clamping</h3> Setting the area to be clamped between the top clamp clevis and the nose of the jack (facing inward toward one another).</p> Winching</h3> Write It Down Yo 2020-11-10T00:00:00+00:00 Related to your professional job/career, quickly, what's in your head that isn't in someone else's? Why haven't you written it down? No, really, go write that down now. Even if it's a single sentence. Have you done it yet?</p> Here's a fun test. Either way, go make yourself come coffee or tea or a sandwich or something that'll force you to context switch. Now, come back to whatever-it-was you had in your brain. If you wrote it down, you can easily pick up where you left off. If not, well, good luck to you.</p> Humans have a pretty terrible working memory. The old adage is 7 +/- 2. Remember, that's for very simple things. In business/software/etc we're rarely dealing with simple things. Communicating those complex ideas to others becomes much easier when we write it down. It forces us to clarify what we're trying to communicate. Bonus points if you include pictures or diagrams.</p> This leads me to my next point: if you don't write something down, from your employer's perspective it doesn't exist</em>. Wait, what? Yeah. If anything were to happen to you, that knowledge, all the time spent figuring something out is now gone, wasted. Remember the last cool idea you had for making something better? Imagine it gone from the world, permanently.</p> Feel that? Sucks doesn't it? Now you know what happens every time someone doesn't write something down. How many ideas, learnings, etc have been lost from the world because no one bothered to write it down?</p> Now that more people are working remotely it has exposed one of the greatest business risks: business tribal knowledge. Or, more explicitly, the fun conversations that happen between employees when they work in the same physical space. Talking about ideas tends to cement them into more brains than just one. But, again, if something happens, those ideas disappear. Working from home is effectively reducing the amount of business tribal knowledge. Let me be clear, this is a good thing</em>. Business tribal knowledge is business risk. Unfortunately, I see far too few people writing down</em> that knowledge in a form that someone else can access which is increasing the business risk even if it's decreasing tribal knowledge.</p> If you want to make a splash at your current (or future) company, write things down as you learn them. Once you've written them down, make sure they're accessible to others. Bonus points if you timestamp everything. Next time your manager or coworker asks you about that-process-that-only-you-know-about, link them to where you wrote down how it works and make yourself available for questions. BOOM, bonus points. You've just generated business value and become a force multiplier instead of a roadblock. It's also something you can bring up when it comes around to review/salary time.</p> Even better, when you leave that position, no matter the reason, you're going to leave a much better taste in everyone's mouth when they go to ask you about a thing. You're no longer there, but there's documentation they can reference. There's a piece of you still around that's still being helpful</em>. People tend to remember stuff like that and at worst, you're remembered more fondly. The business world is a lot smaller than we assume. People talk, change jobs, and you run into them in the future.</p> In summary, write stuff down, make sure other people can access it, and make the world just a tiny bit better.</p> CSV Primer 2020-01-10T00:00:00+00:00 Parsing certain data formats can be more challenging than others. One of the granddaddy's of challenging file formats is the humble CSV or "comma separated value" file (I've also heard "character separated value"). The lack of a strong specification as well as adherance to a specification is what makes parsing these files particularly challenging at times.</p> Given the experiences I've had over the past few months parsing over 40 different source file formats, here's a few ways to not make your own (or other) developer's pull all</em> their hair out.</p> For the record, I've seen all of these in the wild.</p> One record per row</h2> Seriously. There's a reason why I'm putting this first. I don't care if the row has 2 columns or 500, but if you're spreading records over multiple rows, everyone involved is going to have a bad time.</p> Bad:</p> id,title,image,image_position 1,dining room table,image1,1 1,,image2,3 1,,image3,2 </code></pre> Better:</p> id,title,images 1,dining room table,image1,image3,image2 </code></pre> Also Better:</p> id,title,images 1,dining room table,"image1,image3,image2" </code></pre> Also also better:</p> id,title,image1,image2,image3,image4,image5 1,dining room table,image1,image3,image2,, </code></pre> One file</h2> Trust me, it's much</em> easier to parse records when they're all in the same file and not spread out over, say, a "data" file, "price" file, and "inventory level" file. All the data in one place.</p> Have a header</h2> If there's no header, we don't know what your data is.</p> Have the header be the first line</h2> If it's not the first line, it can be worked around in most cases, but that's additional customization, which introduces fragility.</p> Each row should have the same number of fields as the header</h2> Hopefully self-explanatory</p> Bad:</p> id,title,image 1,stuffed bear </code></pre> Also Bad:</p> id,title,image 1,stuffed bear,image1,image2 </code></pre> Best:</p> id,title,image 1,stuffed bear, 2,table,image1 </code></pre> Delimiters</h2> Long story short, I don't care which one you use, but use one that's not used in your data. For instance, if your data has commas, maybe don't use them as a field separator?</p> Bad:</p> testing,1,2,3,what are we having, adam, for lunch? </code></pre> Best:</p> testing, 1, 2, 3|what are we having, adam, for lunch? </code></pre> Quoting</h2> If you must</em> use a delimiter that your data also contains, quote the fields and be consistent. Yes, I realize most csv parsers can handle some fields being quoted and others not, but it does make things a headache if something goes wrong.</p> For the love of everything that is holy, do NOT use smart quotes as delimiters!!! Especially if you use smart quotes in your data!</p> Bad:</p> testing,1,2,3,what are we having, adam, for lunch? </code></pre> So, so, so bad:</p> “testing,1,2”,3,“what are we having, adam, for lunch?” </code></pre> Better:</p> "testing,1,2",3,"what are we having, adam, for lunch?" </code></pre> Best:</p> "testing,1,2","3","what are we having, adam, for lunch?" </code></pre> Line Endings</h2> This is what determines where a new line/record starts.</p> Please please please use just \n</code> for a line ending, \r\n</code> works too. If you must, use just \r</code>. Finally, don't mix them, please!</p> Encoding</h2> It seems like the world is starting to standardize on UTF-8. Means you should probably do the same. Multiple encodings means the parser has to try the most common first, if that fails, try a fallback, etc. This has both data quality and performance implications. Neither of which you want.</p> Entire Data Set vs. Update</h2> This gets into the weeds a bit, but providing all the data all the time is the easiest way to both provide and parse data. It allows whomever you're sending the data to reprocess the entire dataset if something goes wrong.</p> That being said, if the data is truly immense (gigabytes or terabytes of data), I'd recommend an interval setup. Basically every so often send the entire data set, and in the meantime, send only the records that have changed, BUT, send the entire record, not just the data in the record that changed.</p> Deletes</h2> This is probably the hardest bit to handle. I've seen two ways to handle it and both have their advantages and drawbacks. In my experience, the "Absence Indicates Delete" tends to be less error prone as long as the consumer is handling unexpected source files appropriately.</p> For the engineers reading this, it's the difference between the transfer of an entire system of state (single file) vs. state with multiple inputs that can get out of sync (delete file).</p> Absence Indicates Delete</h3> Basically if a record that already exists on the consumer of the csv isn't included in the provided csv it's deleted (or marked for delete or hidden, I'm treating these conditions the same for this post).</p> This has the advantage of not having to parse an additional file.</p> The disadvantage is that if either the csv file provided isn't what's expected or something goes wrong on the consumer side, an entire dataset can be deleted.</p> Delete-only File</h3> Essentially this file would be a list of the records to be deleted.</p> Has the advantage of being less error prone if the source csv is bad in some way.</p> The disadvantage here is twofold. First, needing to provide and parse a second file with a different format than the standard data file. Second, timing. If the consumer sees both the data file and the delete file at the same time and a record is included in both, which one takes precedence? Data or delete? If a record has been deleted in the past and it's now seen in the data file, should it be created or ignored?</p> Summary</h2> So, what's the upshot of all this? Similar to dealing with timezones</a>, don't build your own csv generator/parser. Use one from someone that's already gone through all these headaches. Stand on the shoulders of those giants.</p> If you're a product person reading this, my only advice to you is: listen to your engineers. They know how hard dealing with csv files is and they're just trying to get the business result you want given the constraints they're operating under.</p> ETL Tracers 2020-01-02T00:00:00+00:00 Firing visible data at a target to see if you hit</p> ETL (Extract-Transform-Load) pipelines are notoriously complex and opaque. I've always wanted something to pierce the opaqueness I've experienced on many ETL projects. I'll take a wild guess I'm not the only one. What follows is an idea I had around five years ago to pierce that opaqueness along with the experience I've had implementing it.</p> If you've watched any war or action movies, you've seen tracer rounds. These are rounds designed to light up so that the person firing knows where their rounds are going downrange. Typical rounds are invisible to the eye. For more info, see wikipedia</a>. This is an idea that we can apply to ETL pipelines to give a sense of whether the invisible data is "on target."</p> We can apply the same concept to give us visibility into the inter pipeline. Using traditional monitoring solutions it's easy to see if services are up and running or the underlying box is struggling. It's much harder to see whether the data flowing through is correct.</p> Why not make all records visible?</h2> Not all rounds in a given magazine are tracer rounds for a few reasons. Tracer rounds are less lethal because they contain less mass than a standard round. They're more complex (more expensive) to manufacture. It's also not necessary. From what little reading I've done, around every 5th round is a tracer round. That's enough to give the gunner a sense of where they're shooting without the downsides of every round being a tracer.</p> A similar effect happens with data packets (record, a batch of records, row, etc) in an ETL pipeline. Logs/metrics have extra overhead, especially if you're emitting an entire data packet. That overhead comes in the forms of network, processing, storage, and cognitive load when trying to interpret the results. It's also not necessary as long as you have a representative sample of the data flowing through. All we need to do is tag every n-th packet of data with a "tracer" flag and make sure all our code emits those tracers when they're seen. Otherwise, process them as normal.</p> Zoom and Enhance!</h2> What if we could take the idea one step further? If we emit data as it's already flowing through the pipeline, we have to do extra analysis when we examine those packets to determine if there are any errors in the pipeline, etc.</p> Instead, if we hand-craft tracer packets it gives us absolute control over the content of the packet. We can cover edge and corner cases and we know what the result should be at every step. Think of this with the same mindset you craft unit tests.</p> Also, we can encode this information for every step in the pipeline. The results of each of the extract, transform, and load steps should look very different from one another. If we do this, then each step in the pipeline can emit a diff of what the output should be versus what it actually is.</p> Wait, this is just tests?!</h2> Yep. But it's testing you have the option of running in any environment (including production). It's tests you can use in development if you want to throw a new data source into the pipeline. It's regression tests that automatically tell you if you're now casting something to an int where it was a string before. If you're running it in production, it can be a monitoring system for your ETL pipeline. I.e., if you haven't seen tracers in n-minutes at the loader, either the transformer is having problems or the transport mechanism between the transformer and loader has failed. It narrows down the number of places you need to check to look for failures.</p> Benefits of Tracers</h2> In my own implementation of the idea, we found that local development of new data sources was orders of magnitude faster. In addition, we had regression tests we could run at a moment's notice to confirm that the 40+ data sources we were using hadn't broken because we fixed a bug with the 41st source.</p> We had several data sources change their format without telling us. Using the tracer concept we were able to create a new tracer based on the new format and restore the source within a few hours.</p> So... how do I create a tracer?</h2> My process is pretty simple. I take a representative record from the source data and then hand-craft what I expect it to look like at the extract, transform, and load steps. Like any good test I then take that representative record and change the input to explore the testing space. Any good set of tests should hit happy paths, edge cases, corner cases, and known failure cases. Tracers are no different.</p> What are the components of a tracer?</h2> Source Data</h3> This is as close as you can get to what the source data looks like. Remember, this record is going to be flowing through your system like a regular record would.</p> Extract/Transform/Load Expected Data</h3> This is the expected output of each of these three stages. Include only the ones you feel are necessary. In my case, the transformer is the most critical step and as such, we crafted tracers around identifying transformer problems.</p> Example Tracer</h3> tracer_happy_path: input_record: "id,name,cost\n1234,test name with single' quotes,1234.5" transform_output_record: id: 1234 title_case_name: Test Name With Single' Quotes float_price: 1234.50 </code></pre> Awesomesauce, where can I get this code?</h2> The idea isn't well-formed enough to turn into a library yet. It requires the ETL pipeline know too much about the tracer implementation for the two concepts to decouple them at the moment. I was, however, able to implement the idea in less than 200 lines of Python code for my particular case.</p> Lessons Learned in Implementation</h2> Hand-crafting these data packets can be tedious and annoying. They're hard to get right.</li> You need to drop tracer packets need to just</em> before they'd end up in permanent storage. I.e., if you're inserting into a relational database, run all the inserts/updates/etc, and then roll back the transaction.</li> Depending on the language and implementation of this idea, the code needed to handle the tracers can add a lot of visual noise to the code. Obviously, this is something that can be refactored and fixed, but it is a hazard. In my case I used Python context managers and function decorators.</li> </ul> Key Ideas</h2> Tracers are intentionally crafted data packets that the ETL pipeline knows to emit a diff</em> between expected and actual.</li> Tracers should flow through as much of the ETL pipeline machinery as possible including storage.</li> Tracers should either be ignored by downstream processes or they should be deleted/rolled back from storage.</li> Think of tracers as constant end-to-end tests. They should cover as many edge and corner cases as possible.</li> Tracers act as an early-warning system of deviated behavior, code regressions, data integrity issues.</li> Tracers act, as a side effect, as a monitoring system for the ETL pipeline (if you're not seeing tracers every n-minutes, something's wrong).</li> </ul> 2019 Year in Review 2019-12-31T00:00:00+00:00 Apparently I missed doing one of these last year. Oh well. This year has been difficult and challenging and pretty amazing all rolled into one. First, I read (and listened) to a lot more books than I realized. That's amazing. I grew up a voracious reader and somehow got out of the habit. Needless to say, I think I'm back in the groove and just need to keep up the habit!</p> Books</h2> Audio</h3> It Burns (Marc Fennell) Short and fascinating story about the hottest of the hot peppers. Sounds boring I know, but I was pretty captivated on my way home from Burning Man by it.</li> </ul> </li> Extreme Ownership (Leif Babin, Jocko Willink) Pretty much required reading/listening if you're a leader in any capacity. The intro and acknowledgements are pretty similar. Don't hesitate fast forward through those and read them later. To a non-military person it's very "hoo-rah" b.s. that detracts from the actual work itself.</li> </ul> </li> The Dichotomy of Leadership (Leif Babin, Jocko Willink) While it would still make sense without the first book, I'd seriously consider reading Extreme Ownership first because this book builds on the last and does a deeper dive into the nuances of leadership and the balance therein.</li> </ul> </li> When Breath Becomes Air (Paul Kalanithi) Wow. This one is a hard read/listen. Can't recommend it highly enough, but damn. It really puts into perspective the fragility and strength of being human.</li> </ul> </li> Crash Test Girl (Kari Byron) This was a great read. While I hesitate to compare it to Adam Savage's book (they were both MythBusters), it's really fun and I can't get enough of reading biographical-like books.</li> </ul> </li> Everything is F*cked (Mark Manson) Hold onto your seats for the (from my perspective) rapid left turn the end of the book makes. Beyond that, there's a certain cadence to Manson's writing that I really enjoy.</li> </ul> </li> Every Tool's a Hammer (Adam Savage) Can't say enough good about this book. Savage is definitely someone I look up to and this is a fun, idiosyncratic look at his process, how he thinks about things, etc. If nothing else, the chapter on lists and list making was potentially life-changing for me.</li> </ul> </li> Spy the Lie (Michael Floyd) Was a bit disappointed in this sadly. It's interesting, but I wouldn't go out of my way to re-listen to it.</li> </ul> </li> </ul> Dead-Tree</h3> Every Tool's a Hammer (Adam Savage) Yes, I listened to and read this book. It's absolutely worth doing both. I find I get better comprehension and retention by reading but listening to Adam really drove home his passion for making.</li> </ul> </li> What If? (Randall Munroe) Anything by Munroe is considered mandatory ready for me. Smart, funny, and just all around a good time.</li> </ul> </li> How To (Randall Munroe) Same with this one. Really hoping that Munroe continues to write books (and XKCD</a> comics!)</li> </ul> </li> Deep Work (Cal Newport) Newport puts into words very eloquently what I've felt for a long time about the kind of work that I do (software development) and exactly why open offices and manager schedules destroy my productivity.</li> </ul> </li> Street Freaks (Terry Brooks) The last time I read Terry Brooks was probably in middle or high school with the Shannara books. This is a complete depart from that to a cyber/bio punk future that I really enjoyed.</li> </ul> </li> The End of Night (Paul Bogard) Very sad but meaningful read. Definitely makes you wonder what else we've lost as a society as we've lost the night sky.</li> </ul> </li> A Burglar's Guide to the City (Manaugh) A book that I'd wanted to read for quite some time, but sadly it didn't stick with me. Definitely some interesting ways of looking at architecture but the book meandered a bit.</li> </ul> </li> The Scene that Became Cities (Caveat Magister) Started reading this at Burning Man this year and immediately stopped when I realized what I was doing (spectating instead of participating). For anyone that wants to learn more about the culture and philosophy that underlies a lot of Burning Man, required reading.</li> </ul> </li> Outgrowing God (Richard Dawkins) Honestly, I was hoping for more with this one. It felt surprisingly shallow and uninspiring. I've been slowly distancing myself from "spiritual" practices for some time now. Mostly because I haven't been able to get much out of it. I was hoping for more of a guide, I guess?</li> </ul> </li> Practical Lock Picking (Deviant Ollam) If you want to understand locks and how they provide only the facade of security in our world, mandatory reading. Any talks by Deviant are also incredibly eye-opening and highly recommended.</li> </ul> </li> Simple Minded (Daniel Vincennie) Not entirely sure if this is fiction, half fiction, or non fiction. It felt like a fever dream and if that was the author's intention, it worked really well.</li> </ul> </li> The Psychedelic Explorer's Guide (James Fadiman) Not just for psychadelic explorers, but helpful guide for anyone facing a different/difficult/challenging mindset or someone that wants to provide support to someone going through difficult "stuff".</li> </ul> </li> </ul> Podcasts</h2> Accuracy Third This podcast really got me through the year and was primarily responsible for giving me the confidence to go to Burning Man for the first time.</li> </ul> </li> Critical Role I finally finished Campaign 1! Looking to Campaign 2... I think I'm going to wait a bit before I dive back in. Don't get me wrong, I love this podcast, but 3-4 hours per episode means there's not a lot of time for other listening.</li> </ul> </li> Something Else Brand new podcast, really looking forward to seeing where this goes.</li> </ul> </li> Mormon and the Meth Head Got turned onto this one by my significant other. Haven't had as much time to listen to it as I'd like but it's highly recommended.</li> </ul> </li> The Important Thing Rands in Repose's podcast. Again, not as much time as I'd like to be able to listen to it. It'll probably fill in at least some of the time that I was spending on Critical Role.</li> </ul> </li> </ul> Cool Stuff Done</h2> Burning Man Really deserves its own blog post/series. Amazing and challenging in all the ways I needed.</li> </ul> </li> 3D Printing This is an entire hobby all its own. Very cool technology that's coming up to the point where it's almost ready for a consumer audience, not just a hobby audience.</li> </ul> </li> D&D 5e Continued playing awesome games with my (now) standard gaming group. For anyone that hasn't played D&D (or other tabletop role playing game) I highly recommend it.</li> </ul> </li> </ul> Drowning in a Sea of Complexity 2019-10-23T00:00:00+00:00 When's the last time you looked a piece of code and went "ugggh, I don't want to try to figure out what this does, it's so complex?!" Yesterday? Today? The reason why you're reading a blog and not reading/writing code? ;)</p> We programmers reach for complexity like it’s goddamn instinctual.</p> Wait, let me back up. What is complexity?</p> According to Rich Hickey, it’s the interweaving/interleaving/braiding of things. For instance, if you have a function with “and” in the name, you’re complecting (adding complexity to) the function. It should be separate functions.</p> I just mentioned functions… not methods. Classes, for instance, complect data and operations on data (functions). According to the object-oriented tradition, this is a good thing. It provides encapsulation and a whole slew of other things. Sometimes this is necessary and sometimes not. When was the last time you wrote a class where the class was the only</em> thing that operated on its internal state? You may have started out with good intentions for that class, but you know what they say about the road to hell.</p> But, where am I going with this? Complexity == bad, simplicity == good? Well, yeah, I doubt anyone is going to disagree with that, but let’s dive in a bit deeper.</p> How many things can you hold in your head at one time? A common accepted value is 7 +/- 2 [citation needed]. Great, but that’s for digits, integers, very simple concepts. How many variables can you keep in your head? How much state? How many classes operating on one another at the same time? I’m guessing a lot fewer than 7 unless you’re extraordinary and then you might hit 7. But the thing is, that’s not much different than hitting 2. It’s not an order of magnitude better. So what do we do?</p> “Well, then we reach for abstractions!” you, imaginary person on the other side of this conversation, say.</p> Great, abstractions. In theory they sound like the silver bullet. If I create a container that encapsulates a ton of other things, then I’ve reduced the number of things I need to keep track of. One problem though, abstractions tend to be leaky.</p> How many of them are leaky? Hah! Trick question! All of them! What do I mean by leaky though? It’s pretty simple; an abstraction leaks when you need to know something about the underlying implementation. That’s it. And that’s why abstractions can be so difficult to deal with. Needing to keep the underlying implementation details in your head on top of the local state and it’s no wonder we write buggy, broken code.</p> Two of my favorite abstractions to reach for in this discussion are SQL and ORM's. In theory, ORM's make your life soooo much easier! Instead of writing SQL you just use the framework's classes. Until you can't. Either due to performance or a complex business requirement, you have to drop down to SQL. Bam, the abstraction has leaked as is no longer relevant. And, since you know this is likely to happen in most use-cases for ORM's, why pick one up in the first place? Because it's easy and who doesn't want easy? In my opinion, a large number of "easy" abstractions get you nothing, all they do is kick the can a little further down the road. At some point, you’ve gotta pick up the can and figure out where it came from.</p> So, what do we do? My answer is look to the data that we’re schlepping around. When you boil down what developers do, we manipulate data. That’s it. Whether that data comes in the form of submitted form data, a stream of stock market prices, or a timer timing out. It’s all data. That’s it. Data.</p> So why are we building (leaky!) abstractions</del> misdirections to hide the data from us? I spent two weeks, that I’m never getting back by the way, adding an extractor/mapper/persister to an existing microservice. This microservice was already consuming JSON, was already mapping other bits of the JSON, and was already persisting the mapped bits to a database.</p> TWO WEEKS. To persist an extra bit of the exact same JSON.</p> Maybe I’m a terrible dev, it’s possible. Or maybe we, as an industry, are drowning in complexity we added ourselves in the hopes that we’d be able to keep more things in our head at once. I’m sure we had great reasons at the time to reach for complexity in the name of "easy". Business constraints, feature requests, broken code, etc.</p> “No matter how far you have gone on the wrong road, turn back.” Turkish Proverb [citation needed]</p> </blockquote> Again, it all goes back to data. A new/old concept seems to be rising up again. Data Driven Development. Think about that for a minute. What it means is going back to our roots as developers. Moving and manipulating data. That’s all we do. And there’s no shame in doing that! Businesses pay us a lot of money to move data back and forth!</p> Instead of thinking about our programs as collections of objects, we should be thinking of them as data pipelines. Data flowing with steps transforming the data along the way.</p> This doesn’t only apply to code, by the way. It applies to architecture as well. Microservices are the extension of the object oriented principles to an architecture level. And here’s the real question, is all of the additional work and complexity really getting you anything? Or are you distributing your monolith and introducing network “stuff” as a potential hazard?</p> So, how do you start, imaginary other person in this conversation?</p> With simplicity. Keep things unentangled. If you're using an ORM and you're able to stop, do so. Learn SQL, learn what's going on in the database underneath you. Gain that knowledge and you'll know more than 75% of other developers [citation needed]. Re-examine the tools of your craft. If you're using a framework because it's the only one you know, maybe it's time to branch out. But whatever you do, write simply. Take the time to understand a problem before you reach for a keyboard. Only once you've understood the problem should you start writing. And when you do, do the simplest thing you can to solve the problem. Other developers (including future-you) will thank you.</p> For future listening...</p> Rich Hickey's Greatest Hits</a></p> Onboarding Is Hard (part 2) 2019-03-27T00:00:00+00:00 tl;dr: if you're joining a company, your first n days shouldn't be spent being productive, they should be spent building knowledge and connections so you can be productive.</p> After reading my last post, I've been stopping and starting the next one for close to a month. The previous one focused pretty hard on what the hiring company</em> can do to onboard a new hire. Which is great and all, but that's only half of the story. The other half is focusing on what the new hire</em> can do to be onboarded as quickly and painlessly as possible.</p> With that being said, this is potentially more a note to me than to anyone else!</p> Caveats</h2> First, I'm focusing on a technical/engineering onboarding, mostly because that's my background and what I have experience with. Second, some of the advice may apply, some may not. It all depends on the particular situation you find yourself in. What works for one company or person may not work for the next.</p> Social</h2> Introverts unite! Separately! In your own homes!</p> </blockquote> Just a quick note, introversion/extroversion refers to how someone recharges their social energy. Introverts tend to recharge alone, extroverts in the company of others. Shy/outgoing refers to how comfortable someone is in a social situation. In my experience, being shy tends</em> to correlate with being introverted, but it's not always the case so YMMV.</p> If you're outgoing, fantastic! You'll probably have an easier time integrating yourself into new company culture. The only caution I would provide is to temper your enthusiasm just a little. As a tech worker, you're probably interacting with more shy people than you are outgoing types. More than anything though, just be your friendly communicative self and you'll be just fine.</p> If you're shy like I am, well, this is gonna be a little rough. No real way to make it any better, it just is. You know those really good friendships you (hopefully!) made at your last company, well, you can do the exact same thing here, but just like that last company, it's going to take some time. Relationships, professional or not, are built over time via communicative trust. What I mean by this is the reason why people start talking about the weather or the company is that it's a safe topic psychologically. Can't just jump in and ask someone what they think about the universe and their place in it. That's a much deeper topic that probes at the depths of the psyche and you need to build trust before you can have those sorts of conversations.</p> So, what do you do? You reach out, maybe not in large groups as those awesome outgoing people can, but in small groups, within your team, maybe just one on one when you're asking questions. Up your "outgoingness" just a tad and you'll be okay. Don't get me wrong, it'll feel uncomfortable as hell, but you gotta do it and you'll be thankful that you did. It'll turn an environment with a bunch of strangers into one where you just might hang out with the same people for 40+ hours every week. If it helps, chances are the people on your team are just as shy as you are and are struggling just as much with meeting someone new. If you make a little more effort than what's comfortable, you're easing their experience and you'll form work-friendships much faster.</p> Now, to the introverts (extroverts, you already know what to do, go party!). Whenever you start a new job, make sure you reach out to the people close to you in your life, whether that's your partner, your friends, your therapist, or your family. Let them know what's going on and that you'll probably need a lot more time to recharge than you normally would, but that it's a temporary thing. I guarantee they'll understand. Everyone knows how stressful starting a new job can be and they'll support you.</p> One final caution, be yourself. If you're pretending to be someone you're not, it'll only backfire in the end and you'll have a much harder time integrating with the culture.</p> Lunch/Happy Hour/Social Time</h3> I'll admit, it's very hard going out to lunch with a bunch of new people. Usually, the restaurant is decently loud, it's hard to hear people, etc. There are a few things you can do to make this easier.</p> First off, the choice of the restaurant will probably be made for you. If you have any dietary restrictions, make sure whoever is making the reservation/choice knows whether you can eat there!</p> Second, whenever you all go out for food, make sure to walk/ride with someone else. It gives you a brief chance to have time with them beforehand and it'll also give you someone to sit next to that already has spent some time with you.</p> This next one is uncomfortable as hell, but put yourself in the middle as much as possible. The point of this outing is for the team to meet you, ask questions, and for you to do the same. This is much easier if you're sitting in the middle of the table where you can hear and be heard easily. It also means that you're less likely to be sidelined out of conversations.</p> If you drink alcohol and people order it, feel free, but only order one. After that switch to soda or water. Why? Sharing alcohol seems to help people form bonds quicker for whatever reason, but you don't want to go overboard. Your goal here isn't to get drunk, it's to make connections. If you don't drink, for whatever reason, order a non-alcoholic "specialty" drink. Think a strawberry lemonade instead of water or soda. Same reason. Most people don't realize it doesn't have alcohol in it and pretty much everyone likes the fancy drinks, whether they want to admit it or not!</p> Finally, try to ask open-ended questions. These are questions that can't be answered with a single word answer. They lead to a conversation instead of closing a conversation off.</p> Closed question: "How often do you guys do lunch here?" -> "About every other week." (end of the conversation)</li> Open question: "This is a great place, what other restaurants are good around here?" -> "Wow, well, there's a, and b, and c." (which naturally leads to more questions and conversation).</li> </ul> Headphones/Tuning Out</h3> Believe me, I love my Bose QC35's more than most. It's sometimes the only way I can focus enough to debug code. But, remember, your job while you're getting up to speed isn't to be productive, debug the hardest problem, or write the cool thing. It's to gather enough knowledge and make personal relationships within the company so that you can</em> do that. Think of this as a sprinter stretching before a race. If you don't stretch, limber up, warm up, you'll only hurt yourself.</p> If you do find yourself needing some focus time, make sure people know that you're still available. In my case, that means keeping only one headphone on so I can listen to the office around me. It gives the perception that I'm not in do-not-disturb mode. Collaboration is easily more important than deep work in the early days at a company, and some would argue that it's always more important. I'm not sure that I 100% agree with the last bit of that statement, but I wholeheartedly believe the first.</p> You'll also want to observe the people around you. Do they spend most of their day collaborating, chatting, etc? Or, do they spend their day grumpily downing coffee while jamming to psytrance? Either way, it's very useful information as you acculturate into your new home.</p> Learning the Tech</h2> This is sometimes the easiest and sometimes the hardest part of coming up to speed at a new place. Sometimes in the same hour! Hopefully, you have a good understanding of the technology being used at your new company even if you may not understand how it's being implemented.</p> Know what's being used</h3> In theory, this should be pretty easy. The first time you got a taste of this information was in the job posting. If they were looking for an Oracle DBA, there's a good chance they're using an Oracle Database. Make a list of everything they were asking for and figure out why they were asking for that thing.</p> Once you've got that list, catalog all the primary technology choices you'll be working with on a daily basis. Are there any you are weak on? Great! Focus on learning those every chance you get a free moment, which can be surprisingly often as a company tries to figure out how to use their new investment! The advantage of doing this is you're making their investment seem more attractive every day. You're showing initiative, and you're furthering your own knowledge.</p> Know how it's being used</h3> This is the more important topic at hand. How is it being used here</em>? The key to getting up to speed on this is usually understanding the history of how it got to now. Not just the facts, but the reasons behind it. Sometimes those reasons are very logical, sometimes it's "because a guy that no longer works here did it that way". Either way, you know more than you did before. If there are logical reasons for it, what assumptions were made that underpin the logic? If it was rando-guy, can you tease out what assumptions he was making that lead him down that path? Are they still valid? Where are the pain points in the current system? Needless to say, your first n days of spending time with the tech is going to generate a lot of questions. Don't be afraid to ask the questions, write down the answers, and create documentation from that information.</em></p> Seriously, that's the biggest way you can contribute in your first few days. Writing documentation. It may be imperfect or incomplete but it's probably more documentation than there was before, otherwise, you wouldn't have needed to ask the questions in the first place! Plus, everyone loves it when someone writes documentation, as long as "someone" isn't them. This is an easy way to get a quick win and learn something at the same time.</p> Do a teach-back of the stack (or at least your portion of it)</h3> If a meeting where you teach back to someone what you've learned about the stack, the technology, etc hasn't been scheduled, put one on the calendar. Preferably with your team lead, manager, or someone who knows your area of the stack really well. This is a fantastic chance to find the holes in your knowledge and get them filled right away. It also reinforces the idea that you're a member of a team and not just a "code in a cave" stereotype.</p> Make a PR</h3> Pretty simple stuff, once you've pulled down the code, made a branch, and made your first commit, create a work-in-progress PR. This instantly makes your work visible, which can be a very uncomfortable thing, but it also lets people point out issues with what you're writing that you may not have the knowledge to avoid. This also lets you be humble about your knowledge.</p> Essentially, this is all about shortening the feedback loop. The shorter the feedback loop, the quicker you'll learn and the faster you'll be an effective contributor. No matter how or what someone comments on your code, never</em> take it personally, but especially in your first few months. You are not your code.</em></p> Joining On-call</h3> Even if your new company isn't going to have you join the on-call rotation, shadowing someone in your first few months can give you an idea of where the instabilities in the system are and where some of the pain points are. This is invaluable knowledge as it gives you insight into where you can potentially make some nice wins. While making wins shouldn't be a goal into and of itself, it's a great way to keep up your own confidence and start to show the company and your coworkers what a great person they picked!</p> Before you take your first on-call shift, reach out to your teammates and let them know that you'll try your best but you may need some help. Gather who you should contact if you can't solve a problem and why/when/how to contact that person. Sometimes you can leave an issue until the next day and pair with someone on it but that's not always clear from the incident notification. The best thing you can do is try to triage it. If it's truly a critical issue, wake people up. At worst, it won't actually be a critical issue and there's a flaw in the documentation or notification that's found and corrected. This makes everyone's lives better!</p> When You're Stuck</h2> So, you're stuck. Do you ask for help or spend time researching/learning it yourself. For me this really boils down to one question:</p> Is this lack of knowledge something specific to the company or is it a lack of knowledge of something general? I.e., can you google the answer?</p> For example, "How does your build system kick off this Jenkins job?" is a very different question than "How do I configure Jenkins to push to an EC2 image?" The first one is specific to how the company has configured its build pipeline. The second is more general.</p> I'd spend a lot more time researching the general question than I would the specific one. If I'm still not making any progress, then I'll start asking around to see if anyone's run into a similar issue. I.e., if you can google the solution, you should probably at least try that first.</p> Closing Thoughts</h2> No one said meeting a bunch of new people, especially people that can impact your ability to have a job, was easy. In fact, I'm saying it's the complete opposite. It's damn hard. But the thing is, it's worth it and the margin for error is pretty large. You can screw up most of it and still be successful.</p> So, don't be too hard on yourself. Present yourself as authentically as possible and you'll do just fine :)</p> Onboarding Is Hard 2019-02-20T00:00:00+00:00 Why both sides need to be positive, intentional, and communicative when someone new joins your company.</p> We've all experienced the first-day jitters and shininess that comes from the excitement of new possibility and challenge. Broadly speaking, that energy can be focused one of two ways. Either it's used to catapult the new employee onto the fast track of becoming an active contributor or it can precipitate a downward spiral into mediocrity, boredom, and ultimately quitting. What follows here is my guide to capturing, focusing, and using that energy productively.</p> Have a Plan</h2> Sounds very simple I know, but you'd be surprised at how many places I've run into that thought they could just "wing it" when bringing someone new on. This is can be predicated on a few potential assumptions.</p> Existing documentation and/or team knowledge can be easily transferred to the new person.</li> The new person is a "rockstar" and will magically know what they don't know when they start, know where to get the information they don't have, and know enough to get their feet wet already.</li> </ol> Obviously, both of those are false assumptions but I've seen them play out time and time again.</p> So, your plan should look to fighting at least those two assumptions plus any others you can drum up from your particular culture, like, are there any unwritten rules? Write that shit down!</p> Know where your existing documentation is, how it's organized, and where any major gaps are. This should be an honest, factual assessment. It isn't a value judgment. This is something you can present to the new hire so they know where they're starting from.</li> Assume that the new hire has knowledge of "what" but not "how". What this means is if they say they know Python, great, but they don't know how your company/team/etc uses it in practice.</li> Figure out the most likely questions they'll have and if you don't have the answers, no worries, compile a list of the most likely person to have the answer. This can be a great way for a new hire to meet new people and start building working relationships.</li> </ol> 30/60/90 Goals</h2> It's amazing to me how many places don't provide a new hire a "roadmap" for their first 3 months. These are critical months in any new hire's journey that will set their trajectory for their time at your company. This doesn't need to be a complicated map but it should include some of the following with examples given:</p> Technical goals They should get a merge/pull request accepted in the first 2 weeks, and deployed to production in the first month.</li> They should shadow an on-call rotation by their 2nd month and feel comfortable taking on-call with a backup person by the end of their third month.</li> In their first month understand the overall architecture and do a "teach-back".</li> </ul> </li> Social goals Take a person you've never met out to coffee every week.</li> Every month for your first three, pick a different C-level executive to add into the coffee rotation.</li> Conversations can be business focused or not.</li> The goal is to make a human connection with the people you're likely to spend at least 40 hours per week.</li> </ul> </li> Career growth goals In your first month, determine whether your current team fits where you want to be.</li> In your second month, determine where you want to go in the company in terms of career.</li> By your third month have a plan for how to get there and present it to your manager.</li> </ul> </li> </ol> Buddy System</h2> For fuck's sake, assign any new hire a buddy they can go to with any question they may have without any judgment. This should be the first person they have coffee with and the first person they go to with "dumb" questions. These questions can range from "where's the 2nd bathroom if the primary one is full" to "where does this piece of code live" to "who do I ask about pushing code to production" or even "how does time-off work in practice and who do I ask for it". Think of this as a built-in acculturator and work-friend.</p> Note, that if this is the new hire's default work-friend, it's best to see if you can tease out who'd be a good match for them. Or, at the very least, don't pick your grumpiest engineer to play the hand-holding role.</p> Acculturation</h2> assimilation to a different culture, typically the dominant one.</p> </blockquote> Every company has its own culture. Some are similar enough to others that it's like putting on a different shirt. Others are similar but they have weird buttons, on the wrong sides, and collars, and what's this pocket doing here?!</p> "Close" and "same" are two very different things. You can think of culture as some of the written and unwritten rules of "how we work together". The same work still needs to get done, code needs to be written, reviews need to be done, etc. How that happens is different in every company, even if they use the exact same tools. Perfect example, one company I was with just threw pull requests into the #engineering</code> slack channel with an @here</code> attached. My first week at another company I did the same thing and was privately scolded for using @here</code>.</p> Probably one of the biggest acculturation topics is communication. How the company communicates, what different tools are used for, even what different chat channels are used for can be a huge help.</p> Communication</h2> This is probably one of the biggest ones, at least for me. Helping your new hire understand how their new company communicates. This can either be a huge stumbling block or it can be their ticket to acculturating in a week. Communication is probably one of the easiest ways to inadvertently step on toes, especially in any sort of textual communication (email, slack, etc).</p> What methods of communication are acceptable?</li> What are those various methods used for day-to-day?</li> What's the expectation and acceptability of off-hours communication?</li> What's the quickest way to irritate someone from a cultural point of view? (and how to avoid it yet communicate the same thing)</li> </ol> What's the Point?</h2> So, what's the point here? Onboarding is hard, damn hard. Let's not make it harder than it has to be. Remember, the hiring of someone new is very expensive and you should put just as much effort into the post-hire as you do the pre-hire. Always look at it from the perspective of the new hire. Give them the hand up they need to get their feet under them and they'll become a productive member of your team faster with more smiles on either side.</p> The alternative is to let them flail as some sort of weird hazing ritual and see if they succeed. They might, yes, but you'll have wasted a lot of time, money, and effort needlessly. With the ultimate downside that they'll likely quit much sooner than they would have otherwise.</p> Projects 2019-01-18T00:00:00+00:00 So, for whatever reason, I'm feeling inspired this morning. Have a few projects in mind, some of which are ongoing, and others that are just a twinkle in my mind's eye.</p> The "perfect" D&D/RPG note taking system. Something along the lines of bullet journal, customized for RPG player</em> note taking. Also, would love it if the character sheet was integrated into the system as well. I picked up a Leuchtturm1917 note book last night and, with any luck, I'll be able to transfer notes from our previous sessions over to it within the next day or so and give it a real try out on Sunday when our game is.</li> Going to Burning Man. Yeah, pretty simple. Plan is to buy a ticket the first opportunity I can. I think I've already got the survival situation pretty much figured out. It definitely helps that my girlfriend and another friend went last year and I've been listening to the awesome</em> Accuracy Third Podcast</a> since the end of Burning Man last year.</li> Building a Burning Man Art Car. Apparently, I'm supposed to wait until my sophomore year before I start getting wild-ass ideas about building shit at BM. I'm in sort of a weird space though, in some ways, I kinda feel like last year (2018) was my first year, I just didn't go physically. I'm probably full of shit about this but we'll see.</li> Writing every day. I'm doing relatively well on this so far. Not necessarily writing every day, but writing on a regular basis. Publishing what I've written to my blog as long as it's not too personal. So far, so good. Don't want to jinx it though!</li> </ul> So, what projects are you working on? What projects are floating around in your head that you haven't gotten started? What projects could</em> you be working on if only you had time/energy/money/motivation/etc?</p> Including the Why 2019-01-15T00:00:00+00:00 The biggest question I see unanswered in technology, stories, news, etc, is "why?" Why do I want to experience your content? Why does it matter to me? Wrapped up in that question is the context of why it matters to you, the creator. Why you spent time producing the content. Why is this a thing that needed to exist in the world?</p> Sometimes we may not understand that question ourselves, even while creating. Something just needed to be there, period. We happened to be the one that noticed it and had the skills to create it. Great! Once it's created, we can always go back in and take a second look, figure out why something is. The best way I find to do this is to sleep on it, look at it with a fresh set of eyes, and come at it with the perspective of someone that doesn't know you, your motivations, your context, anything.</p> Take, for example, this blog post. Why does it need to exist? It originally started out as a reaction to a "vaguebook" post I saw this morning, the very epitome of the lack of "why" (and a bunch of other things). This lead me down a path of thinking through why I struggle to understand some people but not others. Or, for that matter, why I can communicate with some people effortlessly but others it's like we talk past one another endlessly. That's one "why" for me to write this post, but what do I hope a person reading it gets out of it? The other side of the proverbial "why" coin.</p> Why should someone else read it? ("someone else" also being me, once I've lost the context and "why" of this post in the first place). The most basic reason I can think of is to "change the world." Grandiose, I know, but stick with me. We normally think of "changing the world" as being some grand thing. What we, myself included, fail to recognize is that change can be so subtle, so slight, that no one even notices. That's change too, just on a different scale.</p> So, back to my grandiose ideas of changing the world. If one person, again myself included, reads this and because of it includes an answer to "why" in their next creation, then it's served its purpose. Reducing the friction in communication between two beings. Getting someone to share their perspective accurately with someone else. That someone else being able to easily step into the perspective of the creator.</p> So, next time you create something, include a bit of "why". No, you don't need to include 100 pages of backstory before you share your recipe for perfect boiled eggs, but I do want to understand at least a little of your perspective. In this case, why your boiled eggs are better!</p> Music to Work By 2019-01-14T00:00:00+00:00 An (incomplete) list of the music I listen to when I'm trying to get shit done :tm:. Obviously all the links are on Spotify for easy listening to. And part of me wishes we were still in the "personal collection of mp3's" era but I also like being exposed to a lot of new bands/music that I wouldn't have found otherwise. Pandora was great for that for quite a while, but I've moved onto paying for a subscription to Spotify as I can re-listen to albums/songs/etc as much as I want. And to keep my sanity and focus in an open office (insert rant here about how open offices are terrible for knowledge workers) the subscription fee and a good pair of noise cancelling headphones is essential.</p> Playlists</h2> Focus w/ Energy: Liquid Funk</a></li> Taking the morning and getting into flow: Morning Flow</a></li> Afternoon focus/flow, good when researching lofi hip hop music</a></li> Chilling: 3am Airport</a></li> Linkin Park, my favorites: (dead link)</li> Triphop, for when I'm feeling the 90's/00's vibe (dead link)</li> </ul> Individual Soundtracks</h2> Doesn't get much better than this: Bastion</a></li> Or pretty much anything by Darren Korb</a></li> Or this: Rebel Galaxy</a></li> Hey, what about Tron: Legacy</a></li> Or rocket launches? SpaceX</a></li> </ul> Just a taste of what I listen to on a regular basis, preferrably at high volume, blocking out any distractions so I have at least a chance of focusing!</p> Goldilocks and the Three Company Sizes 2019-01-11T00:00:00+00:00 Which company size is right for you?</p> One of the questions that has to be answered is where do you fall on the spectrum of size and associated company mentality you work best for. The spectrum goes from startup through midsize and all the way up to massive-multinational-conglomerate. There are a few general rules of thumb I’ve come to recognize.</p> As size goes up, individual freedoms go down</li> As size goes up, stability and job security usually, but not always, increases</li> As size goes up, there’s a transition point from the focus on being right to the focus being on not being wrong</li> As size goes up, ping pong and foosball sessions are replaced with meetings</li> As size goes up, “unlimited” vacation is usually replaced with a vacation formula</li> As size goes up, unwritten rules get written down</li> As size goes up, uncertainty about perceived performance goes down</li> As size goes up, actual performance usually goes down</li> As size goes up, the on-boarding process gets longer and more detailed</li> </ul> Quite a lot depends on where you want to live on this spectrum. Too much freedom and autonomy can be terrifying, especially if someone is more extrinsically motivated than intrinsically. On the other hand, too much bureaucracy can be stifling to motivation and productivity. As most things, it’s a balancing act. The real question is, where do you end up on that spectrum?</p> As I’ve gone through companies of drastically different sizes, I tend toward the high end of startup to the low end of midsize. Enough freedom to choose tools, languages, and projects, but enough guidance so I know I’m not going right off the rails.</p> Having policies and procedures written down is always helpful, at any size company, but I find that it’s the transition point from startup to midsize where most of the good documentation is generated. This seems to be where companies codify their culture. Some, of course, do it better than others but as a new-hire, there’s nothing more valuable than documentation to read and get a sense of what you just walked into.</p> I also find that as size goes up, context provided tends to go up as well. Sometimes this is fantastic and other times, it’s overwhelming. When you’re trying to coordinate 20+ scrum teams using the “scaled agile framework” there’s too much context to hold in any one person’s head at any one point and communication breaks down. At the opposite end of the spectrum, there’s so little context for anything that you’re making it up as you go and hoping you’re going in the right direction.</p> Unlimited vacation, for me, is actually more of a negative than a positive. In my experience it changes the equation from “I have this much time to take off, great!” to “how much political capital do I have built up to be able to take time out without unseen repercussions?” A much more difficult and complex question to answer.</p> As for stability, large companies generally don’t fold in a day. They do, however, lay off people, seemingly without much thought. So, while the company may not go under, your job may disappear. As many people have said, the idea that you can find a “forever company” at this point is mostly a myth. Maybe it’s possible, but it’s more likely that you’ll find a “good enough for now” company and when it no longer meets that criteria, you move on to the next one that fits that criteria.</p> Size of company is objective, your experience of the best size for you is subjective. My advice is to find the right size and stick to it, even if you’re switching companies. You’ll be happier and more productive.</p> Python to Scala 2019-01-07T00:00:00+00:00 Let me set the background. I'm not a classically trained programmer. In fact, I've been coding for about 8 years and ended up teaching myself on the job. I'm currently a senior software engineer and end up fighting with Imposter Syndrome</a> on a regular basis.</p> I've been a Python programmer for pretty much that entire time with occasional dabbles in other languages (Clojure, Java, Scala, Node, etc). In my current (new) position, I'm working in a Scala codebase. A language that I've never had to put the effort forward to learn. Three days in and I totally had a lightbulb moment:</p> Scala is Typed Python on the JVM with Braces</em></p> Take for instance the Person class in Python:</p> class Person(name, age): def description: return "{} is {} years old".format(name, age) </code></pre> and the same thing in Scala:</p> class Person(val name: String, val age: Int) { def description = name + " is " + age + " years old" } </code></pre> I mean, yeah, there's a ton of other stuff in Scala (it's a batteries-included language like Python) but the more I look at it the more I see how similar they are instead of how different they are. Scala has an advantage that functional programming concepts are much more accepted in terms of style than they are in Python.</p> Scala also has things like for-comprehensions (list comprehensions).</p> Python:</p> l = [i for i in range(100) if i % 2 == 0] </code></pre> Scala:</p> val l = for (i <- 0 to 100 if i % 2 == 0) yield i </code></pre> So far, it's not as difficult a mountain to climb as I expected and that's a very good thing!</p> Git Commit Messages 2019-01-03T00:00:00+00:00 git commit -m "gah!"</p> </blockquote> So, apparently, git commit messages are a point of contention with developers. Yeah, the ~50 characters you get to say what the commit does, your state of mind, why this is a thing, etc. Not only that, this is the message that's probably lost when you squash merge your commit. Maybe it's just me, but I find very little value in reading any git commits. There's just not enough context without reading the associated code, and if you're doing that... the commit message probably won't provide you that much extra information.</p> That being said, two things I have started using commits for is:</p> A summary of the work done in the commit. Sometimes this is nothing more than "gah!" or "try to unbork things". I know, not great messages, but they're all I can stomach at the moment when I'm in the midst of trying to get a piece of code to do the thing I want it to do.</li> An answer to the question "What happens if I merge this commit?" These are where the good commits usually are. Things along the lines of "Add glue:* permissions to Spark worker". Tells you exactly what happens if you merge the commit.</li> </ol> Here's the thing, to provide enough of a summary so that the person coming behind you (likely to be you when you've lost the context you currently have) in ~50 characters is HARD</em>, like, getting-threading-locks-right-hard. So, if you give me commit messages like "terribleness", "joy", etc, I'll probably just laugh and go read the code. If you've given me one of the commit messages that gives me enough context, I'll still go read the code since all documentation is suspect, especially mine!</p> Good git commit messages are bonus points, nothing more. So to get up in arms about it feels, silly, and possibly a sign of bikeshedding. Write good ones if you can and don't criticise those that can't.</p> Tools I Work With 2018-12-27T00:00:00+00:00 Yay for interesting writing prompts. Here’s a quick list of the tools I use on a daily basis to get my job as a software engineer done:</p> Slack: pretty much required for asynchronous communication. Email is reserved primarily for more “formal” communication over “getting shit done”.</li> iTerm2: terminal emulator, nothing much to say here but it’s far and away the best on OSX, to the point where I can ignore it. I love tools that get enough out of my way that I can ignore that they are even a thing!</li> Fish: friendly interactive shell. For now, my shell of choice over bash and zsh. It works better out of the box but unfortunately isn’t bash-compatible. I waffle between fish and zsh on a regular basis but have been sticking with fish for close to a year now. Probably means it’s time to go back to zsh and oh-my-zsh</li> Spacemacs (with vim bindings via evil-mode): definitely a powerful editor/ide/etc. Has the most fully-functional Scala integration outside of intelliJ (which I won’t use on principal). The spacemacs configuration lends itself to discoverability as well as a pretty low-friction setup (for non-emacs users like myself). The vim bindings are the best modal editing I’ve found and are in most editors so I’m able to turn them on and just “get to work” faster. I’m definitely not a vim wizard by any stretch but I do find the editing capabilities much better than any other key bindings I’ve found yet.</li> Visual Studio Code: for when spacemacs freaks out and won’t work or if I’m writing Rust (spacemacs rust stuff… kinda-sorta works well enough if you’re familiar with the language, which I’m really not). Also, if I just need a change of pace.</li> Chrome: for the longest time I used Chrome for password management so it was my default, but I’m considering moving to Firefox now that I’m using 1password as my password manager on all my devices.</li> nvAlt: notational velocity. I have it bound to cmd+` and love its ability to pop up and pop away, support for markdown, and the ability to sync (or not) with various platforms based on where you save its files. The stupid-fast-searching is well worth taking a look at.</li> Insomnia: a postman clone that, IMO, is cleaner and more intuitive. Plus, I just like being different.</li> GitKraken: hands down the best GUI Git interface. Integrates well with both Github and Gitlab, very performant. Multi-platform. For me, it removed the fear when doing a rebase because I knew exactly what I was doing when and where. I do, however, tend to use spacemacs git integration layer for simple commits.</li> </ul> That pretty much wraps it up for tools. Those are the primary ones I use in my day-to-day writing Scala and Rust. Of course, it’ll probably change over the next few months as I get bored pretty easily and when a new shiny comes along, I can’t resist giving it a try!</p> Predict the Future of Your Industry 2018-12-21T00:00:00+00:00 Honestly? I think my industry (software development) is heading for a cliff. A complexity cliff. We're already struggling to build abstractions well enough to keep our heads from exploding with the complexity we all seem to love. Without a drastic change in direction away from OO, leaky abstractions (DAO and ORM come to mind), and a rejection of incidental complexity, we're going to collapse under the weight of our own complexity.</p> I know, the prediction seems pretty dire, but I'm seeing it in both new developers and experienced developers all the time, at multiple companies, and in multiple languages. What we've built and are now building ARE TOO COMPLEX</em></em>. Not too complex for a computer to parse, but too complex for our (feeble in comparison) minds to be able to comprehend. We need a return to the fundamentals of computing: theoretical math, lambda calculus, pure logic. Maybe it's just me, but when I'm working on a problem where I'm comparing the outputs of two programs and can't satisfy the compiler, let alone get actual matches, we've got a huge problem. I'm no computer genius, but I've been doing software development for at least 10 years now.</p> I can't shake the feeling that as an industry, we've seriously fucked up, and need to go back and understand what and where the hell we went wrong and fix it, and soon.</p> YAGNI Revisited 2018-08-29T00:00:00+00:00 "You aren't gonna need it" (YAGNI) is a phrase used in software development to help combat complexity and prevent building unnecessary components. It's a great idea but one rarely implemented. What I see most often are cron schedulers with api endpoints that put data onto an AWS queue and use an RPC framework internally for no good reason. I.e., the complete opposite of following the YAGNI principle.</p> (fair warning, when I say "prove" below I'm not talking about a formal proof, instead research or build enough to convince yourself)</p> Assumption of None</h2> I had an insight the other day that led me down an interesting path.</p> Once you have a problem to work on, but before making any technology choices or writing any code, assume that the problem is already solved. Assume that you, personally, need to do nothing. </p> No, seriously, assume that you need to do literally nothing to solve that problem. You sit on your hands and the problem is magically solved in front of your eyes. Silly right? Stick with me...</p> What does this actually mean? Well, if your problem hasn't been solved in the time it takes you to open a new browser tab, it means that you need to do a quick google search to figure out if someone else has written the thing you think you need. Even more so, it means thinking about your actual need (hammock driven development for the win!).</p> Once you've done that, prove yourself wrong. Prove to yourself that no one else has written an app or bit of code that does the thing you need.</p> At this point, you've proven to yourself that no one else has something that fills the need. Great! Don't start writing code yet.</p> Is there a group of technologies that can integrate with one another to provide the functionality? Again, assume that there is and see if you can prove yourself wrong. Nothing exists? Great! Now you can start thinking about writing code.</p> But, as you do, continue to make assumptions that you don't need (insert thing here) and prove yourself wrong. Assume you don't need to persist data until it becomes bleedingly obvious that you do. Assume you don't need a database to persist that data and a flat file will do, until you can prove that assumption wrong.</p> Proving assumptions wrong all the way up and down the stack is a great way to prevent yourself from building in something you don't need or using a technology that's too complex for your current use cast. It's a way to ruthlessly force yourself to build something that's tailored to your situation.</p> Other Benefits</h2> You know the great thing about building something like that? It's extensible. You can always add more on later, after your assumptions prove false. It improves developer speed, both from a bug-squashing perspective (it should be obvious when there's a bug because your code doesn't do the specific thing you need it to) and from an onboarding perspective.</p> I don't necessarily mean a new developer to the company by "onboarding" by the way. I mean getting a developer that's unfamiliar with the codebase up to speed and productive in the codebase. This includes you if you haven't looked at the codebase in a couple days, by the way!</p> This increases developer productivity which in turn means business velocity. If you're building the thing you need and only that, you can move at lightning speed. That's the goal, isn't it? Move faster than your competition and maintain that velocity for as long as possible.</p> You're also building in a lack of code ownership. This, contrary to popular belief, is also a good thing. It means when your code no longer fits your need, because your needs diverged, you can toss the code out and use the lessons learned to move even faster on the new need. Even in this case, go back to the basic assumption that you don't need to build anything, and prove yourself wrong every step of the way.</p> 2017 Recap 2018-01-07T00:00:00+00:00 Like other blogs, I'm doing "2017 in review". It gives me something to blog about and might jump start a new habit of writing more often. Daily blogging would be fantastic but I'd like to start with something reasonable, monthly or maybe weekly and work up from there...</p> Note, after writing this it completely changed my perspective on how 2017 went for me. When I originally started I was feeling pretty shitty about 2017 and hoping that 2018 is better. Yeah, there was a lot of negativity in 2017 but personally there was a lot of good in there too. Funny how things get put into perspective sometimes.</p> Games Played</h2> Board/Tabletop</h3> Unearth Fantastic "light" board game for up to 4 players that plays in about 45 minutes or so. Make sure to read the rules closely as our first game left us feeling a bit "WTF?"</li> Great for introducing parents and family members to a board game that's not</em> one of the U.S. classics (Clue, Monopoly, etc).</li> </ul> </li> Numenera There's going to be a lot about this in the RPG section, but I can't say enough for how much this game has changed my life for the better.</li> </ul> </li> </ul> Video</h3> Divinity Original Sin My new favorite game. Really great classic role-playing game (CRPG) with what seem to be meaningful choices, a crafting system, magic, freedom of character creation and pathing, etc. Feels close to D&D which is pretty much what I've been looking for.</li> </ul> </li> Path of Exile Think Diablo II, but better, and free. Definitely worth a couple hours to figure out if you like it or not.</li> </ul> </li> Crosscode Feels like playing a realtime-combat JRPG MMO, but it's a single-player game. Fantastic for the anti-social types that want to solo a cute MMO.</li> </ul> </li> Turmoil Great little time-waster with surprising depth (no pun intended LOL!)</li> </ul> </li> Running With Rifles Great time-waster, can be a bit frustrating at points, but the initial campaign is pretty long and engaging as are several of the player-created campaigns.</li> </ul> </li> Rebel Galaxy This game has one of the best soundtracks I've ever heard in a game. Feels like a wonderful mashup of Firefly, Cowboy Bebop, and soloing Eve: Online. I only wish the storyline was a bit longer and you could spend more time with the higher level ships.</li> </ul> </li> </ul> Books Read/Listened To</h2> Fiction</h3> Promise of Blood (Powder Mage #1) Really engaging story so far, I'm about 7 chapters or so in and can't stop reading.</li> </ul> </li> Engineering Infinity First few stories were really amazing, the next ones I seem to have gotten bogged down in. Will maybe try this again once I finish the first Powder Mage book.</li> </ul> </li> Legends of the Nameless Dwarf: The Complete Saga Haven't touched this since I finished the first book toward the startof the year. The worldbuilding is interesting but seems a little disjointed for my taste. I'll likely come back to it at some point.</li> </ul> </li> The Name of the Wind (Kingkiller Chronicles #1) The prose of this book is amazing but I find that it sometimes gets in the way of a story that's not incredibly interesting to me. I'm more interested in the nested way the stories are being told (The author is telling the story of a storyteller telling a story about himself who also sometimes tells a story).</li> </ul> </li> Vurt If you can handle the (sometimes very</em>) mature themes in here, it's a fun, wild ride.</li> </ul> </li> Norse Mythology First book on Norse mythology that I've actually finished. If I remember correctly, this one was an audiobook read by the author.</li> </ul> </li> Priest (Ratcatchers #1) Matthew Colville, if you don't know that name, you probably don't play any tabletop role playing games (TTRPGs). He has a fantastic youtube channel devoted to nothing but and is engaging and fun to listen to. I originally bought this book as well as Thief to support him and it was surprisingly good. If I remember correctly there are a few very minor editing mistakes but I highly recommend it.</li> </ul> </li> Thief (Ratcatchers #2) The only bad thing about the Ratcatchers #2 is there isn't a #3 yet!!!</li> </ul> </li> The Night Clave Great Numenera novel, required reading for Numenera GM's in my opinion.</li> </ul> </li> Myth of the Maker To be honest, I never finished this one. The Strange is an interesting concept but I just can't get into it for some reason.</li> </ul> </li> </ul> Non-fiction</h3> Coders at Work I've made it through the first interview at this point and it's engaging enough to keep reading once I make the time for non-fiction.</li> </ul> </li> Extreme Ownership Really made me take a hard look at leadership, my own role in failures, and what kind of leader I want to aspire to be.</li> </ul> </li> Rework Bunch of good tidbits in here, even for people that may not be running their own business.</li> </ul> </li> The Passionate Programmer Some of this book, I had an initially negative reaction to. Mostly the "think like a business person" stuff. In my "perfect" world, I'd just be writing code. The business world doesn't follow the same logical rules I'm used to thinking in, which makes it rather difficult for me. Thus, it's a learning opportunity.</li> </ul> </li> The Shallows: What the Internet Is Doing to Our Brains Frightening book. This is the one book this year that terrified me for the future of not only my own brain but the brains of the IT industry as well as for the developed (and soon enough developing) world.</li> Inspired me to read more, both paper books as well as on Kindle and listen to more.</li> </ul> </li> Where Good Ideas Come From Great audiobook for my now ~2 hour daily commute. Engaging enough to keep your interest, but not so engaging that you forget you're driving!</li> </ul> </li> How We Got to Now Same as the above, another great audiobook for a commute.</li> </ul> </li> The Subtle Art of Not Giving a F*ck Required reading, in my opinion, for anyone that says "yes" to too many things.</li> </ul> </li> The Design of Everyday Things Haven't finished this one yet, but it's already fascinating.</li> </ul> </li> </ul> Tabletop Role-Playing Game (TTRPG)</h3> I read a lot of RPG books, not necessarily because I'm going to play</em> that particular setting/game/etc, but because it might provide a new perspective on how to better run a particular situation, give me inspiration, or offer another tool I can throw in my GM's toolbox (clocks from Blades in the Dark as one example).</p> This is what I can remember I've read this year. It's been a lot...</p> Ryuutama I've seen it described as Miyazaki-meets-Oregon-Trail. Great RPG focused on the journey</em> of a character and the stories they tell. Definitely worth a read even if you never play it as inspiration for how to make the journeys of your character/player richer.</li> </ul> </li> Cypher System Numenera Jade Colossus: Ruins of Prior Worlds I'm not sure if this counts as a setting book but it definitely expands the setting of Numenera providing an interesting large</em> structure to explore and set adventures in. More than that, it provides a "ruin" generator that's fantastic (and is screaming for someone to create an online generator). Great book, well worth purchasing.</li> </ul> </li> Shadewalker Looks to be a great one-shot adventure and one for getting new players up and running. It's small enough that it can be placed pretty much anywhere in the Ninth World and would be easy to continue on from.</li> </ul> </li> Ninth World Bestiary 2 To be honest, there wasn't a whole lot here. I love the idea</em> of bestiaries as inspiration and to give you more and varied creatures to throw at players. The thing is, Numenera isn't supposed to be heavily combat focused and a lot of the creatures seem to be targets to swing at, not encounters to be role-played.</li> </ul> </li> In Alternate Dimensions Have already used The Whispering World alternate reality for my ongoing campaign and it's worked out incredibly well. Would definitely recommend if you're interested in ramping up the Weird factor.</li> </ul> </li> Character Options 2 Fantastic. I'd consider this a must-buy along with Character Options 1. Adds new player classes and a ton of other options.</li> </ul> </li> </ul> </li> Unmasked Retro 80's setting, Superhero RPG.</li> To be honest, other than it being a cypher system setting, nothing else appeals to me in this book. It's definitely a lot different than what was represented in the Kickstarter and I'm disappointed. That being said, there are a ton of reviews I've read online about how people love the setting and gameplay so more power to 'em. It's just not for me.</li> </ul> </li> Predation Seems like a great setting and provides some very</em> interesting options for companion beasties. The roleplaying potential here is fantastic as the beasties are all played by someone who isn't their human companion. They also come with personalities and numerous other fun tidbits.</li> </ul> </li> Expanded Worlds To be honest, this one was pretty meh for me. I'm sure I'll mine it for info if I get bored with Numenera and want to world build.</li> </ul> </li> Vurt This setting book is gorgeous and jam-packed full of information, inspiration, and details about Manchester.</li> Best of all, it seems like it's written in the Gamecat's voice, so I was reading it in that voice (from the audiobook) the entire time. I highly recommend this, kittlings.</li> Having read the novel I was glad to see the sex-focused bits of the Vurt world entirely optional or turned down a bit. If your gaming group can handle it, great, but I haven't even heard of one that can.</li> </ul> </li> </ul> </li> Blades in the Dark Interesting system and world wrapped into a book that's a little disjointed. I'd recommend it for more experienced GM's and players as it's at best a morally ambiguous setting and game play with the potential to experience a lot of interesting and potentially uncomfortable situations.</li> As a GM the "clocks" mechanic is very interesting and one that I'll likely steal for any other game I end up running.</li> </ul> </li> Dungeon World Haven't played this yet, but it looks to be a great system for new players and GM's. It provides a limited list of "moves" for both the GM and the players and yet provides a ridiculous amount of freedom inside those moves.</li> </ul> </li> Paranoia Would love to play this in the future, not much to say here other than the "secret traitor" bit is definitely interesting.</li> </ul> </li> </ul> TTRPG's</h2> Critical Role!</p> Having listened to the Critical Role podcast for a good portion of this year's commutes into and home from work, Matt is a GM god</strong> and has become someone that I can look up to, honestly. He's humble, interesting, engaging, talented, and has a lot of life wisdom.</p> The rest of the cast is similarly amazing and has likely been responsible for a good portion of the uptick in people playing D&D and other RPGs.</p> Critical Role has been such a positive influence on me that I started running my own Numenera campaign and so far it's been a resounding success. We've played approximately every 2 weeks for a good portion of the year now and one of my players has been inspired to run their own game! It's awesome to see one of your players take the GM's mantle and run with it!</em> I'm currently playing in that game now and while she has a different style than myself, it's an awesome</strong> game!</p> Another interesting side effect of playing Numenera is that my woodshop/workshop area is much improved and organized. Stay with me on this one.</p> I was looking for a good way to thank my players for sticking with me for the past however long we've bee playing as I GM'd my first real campaign. After a lot of browsing on Reddit, YouTube, and others I decided to get them a set of dice boxes. But, me being me, I can't just buy</em> something. It has to have a personal touch somehow. So, I ended up going down the route of buying some cheap boxes from a craft store. Then I set to work sanding, distressing, finishing, staining, and felting the boxes.</p> Before I could do this, however, I needed a space to work in. The logical space was my "workshop", or better known as "the place where we put shit when we don't know what to do with it." Que a 4 hour cleanup, organization, and trash music-montage. Is the workspace perfect? Hell no. The better question is: "Is it functional enough?" The answer to that one is a resounding yes. I was able to finish the boxes and give them as gifts (along with dice) to my players.</p> So, not only was I able to start 2 different projects (boxes and workshop cleanup), I was actually able to finish them as well! Nothing feels better to me than a project started and</em> finished.</p> Colorado 4x4 Rescue and Recovery (CO4x4RnR)</h2> This year I joined a 4x4 non-profit. Their (our) focus is person and vehicle extraction in the Colorado high country. Specifically on Forest Service roads and Jeep trails.</p> My first recovery happened at the end of January. I went on as a "ride-along" to see if it was for me and to get my feet wet. Well, the next month I spent close to $8,000 in upgrades to my Jeep to get it ready for recoveries. Talk about jumping in with both feet! In training and gear alone this year, I've probably spent over $10,000. I can also say that the 20+ recoveries I've been on have saved</em> our clients well over that amount, possibly many times. On one recovery alone, the client was quoted $7,000 from a commercial towing company.</p> Since that time I've joined the newly-formed SAR-ES (Search and Rescue - Emergency Support) group inside CO4x4RnR, learned Wilderness First Aid (WFA), taken 2 separate recovery skills classes, gained at least one 4x4 mentor, and made some great friends. It's also gotten me out in nature more in one year than in the past 10 years combined. That alone was worth it for my mental health.</p> Another project I was able to finish was the installation of some amber warning lights. They're currently installed in a temporary-but-functional sense which for now is good enough. That seems to be a theme for the past year and especially the last couple of months. "Perfect is the enemy of the good." So, don't try to make things perfect. Instead, make them good enough and get. them. done.</em></p> New Job</h2> On top of everything else, I also started a new job. Having gotten fed up with the lack of progress in my previous job as well as rats leaving what started to feel like a sinking ship, I looked for and found a new job within about a month. Changing jobs has always been stressful for me as I'm sure it is for many people. Thankfully, the new company has a much healthier culture, one where they're not likely to lay off people or sell a good portion of the company on what feels like a whim.</p> There are a few warning signs with the new company but as a rule, I don't talk about my current employer publicly, so my strategy right now is to adopt a wait-and-see approach. What that means is that I keep working as hard as I can to do my job right and if the company fails me, or a better opportunity arises, well, I'll move on to another.</p> Sadly the days of working for a company for 10+ years are far behind us, especially in the tech industry. Don't get me wrong, if I found the right company, I'd stick with them until whatever retirement looks like in 20+ years. The problem is I don't know that company even exists.</p> Summary</h2> So, to sum up, personally I've had a fantastic year. I'm hoping and working toward 2018 being even better. Some things that are on my list:</p> Do more functional programming, preferably getting paid to do it!</li> Read more books, fiction and</em> non-fiction, especially the dead-tree variety.</li> Play more games! Specifically tabletop games (RPG or not) with friends. The human connection is hard to beat.</li> </ul> Refactoring Python if Statements 2017-12-23T00:00:00+00:00 Note: I'm not recommending the following refactoring to everyone, nor am I saying it was even a good idea. It did, however, work out quite well for myself and my team.</p> if pred_1 == 'first': output_data = output_data._replace(output_data_1=pred_3, output_data_2=pred_4) if pred_2 and self.state_management_3 in pred_2: output_data = merge_namedtuple(output_data, self.process_data_1()) elif pred_3 == state_management_2.state1: if pred_4: output_data = merge_namedtuple(output_data, self.process_data_2()) else: output_data = merge_namedtuple(output_data, self.process_data_3()) if orig_data_2 in [state_management_1.STATE1, state_management_1.STATE2]: output_data = output_data._replace(output_data_1=orig_data_1, output_data_2=orig_data_2) elif pred_3 in [state_management_2.state2, state_management_2.state3]: if pred_4: output_data = merge_namedtuple(output_data, self.process_data_2()) else: output_data = merge_namedtuple(output_data, self.process_data_3()) output_data = output_data._replace(output_data_1=state_management_2.state1, output_data_2=state_management_1.STATE1) elif pred_1 == 'second': if pred_2 and self.state_management_3 in pred_2: output_data = merge_namedtuple(output_data, self.process_data_1()) elif pred_3 == state_management_2.state2: if pred_4 in [state_management_1.STATE3, state_management_1.STATE4, state_management_1.STATE5]: if pred5: output_data = merge_namedtuple(output_data, self.process_data_4()) elif pred_4 in [state_management_1.STATE7, state_management_1.STATE8, state_management_1.STATE6, state_management_1.STATE9]: output_data = merge_namedtuple(output_data, self.process_data_2()) if pred_4 == output_data.state_2: output_data = output_data._replace(state_1=None, state_2=None) elif pred_3 == state_management_2.state1 and not pred_4 and pred5: output_data = merge_namedtuple(output_data, self.process_data_4()) output_data = output_data._replace(state_1=output_data.sub_data.state_1, state_2=output_data.sub_data.state_2) elif pred_3 == state_management_2.state1 and pred_4 and pred6: output_data = merge_namedtuple(output_data, self.process_data_2()) </code></pre> Still with me?</p> ...</p> Yeah, pretty sure I lost about 90% of you with that if-block.</p> This isn't the actual code that I ended up refactoring, but it's convoluted enough to give the same gut-wrenching feeling from it. I've also done my best to anonymize it so to protect the guilty.</p> The White Whale</h2> Story time!</p> I ran into this block of code my 3rd or 4th day on the job and recoiled in horror at it. At the same time, it fascinated me that this was the encoding of some admittedly convoluted but mission-critical business logic into Python. The "standard" refactor for an if-elif-elif-elif block in Python is to reach for a dictionary (hashmap for those not familiar with Python), encode the predicates into the keys and the functions to be called in the values.</p> Great... but... does that mean we need a nested dictionary here and, more importantly, would that actually make the code more readable?</p> # we start with the first "layer": {'first': {} 'second': {}} # cool, that was easy... now the second "layer": {'first': {pred_2: {} pred_3: {} }} #uhhhh... we're going off the rails here... </code></pre> The problem here comes down to the different layers not being symmetrical. They all have various conditions and an amalgamation of predicates, states, and even types (some are lists, others are enums, others are booleans).</p> So... un-refactorable?</p> I'll be honest, at this point I was wondering if it really was un-refactorable.</p> The One That Got Away</h2> I left the code as-is for quite some time. Months actually. It was always sitting in the back of my head though, like an itch you can't quite scratch. Refactoring this bit of code was always on my to-do list, but I could never seem to find the time to really think about it. Add on to this, it was mission-critical business logic encoding. That always carries an inherent risk when you're refactoring. There were tests around the code, but they ended up having major holes.</p> A Light on the Horizon</h2> Tests...</p> The golden rule of refactoring is that you never do it without a good set of tests to verify old and new logic.</p> Hah! Of course! Write unit tests around the entire if-statement-of-crazy. If nothing else, I figured this would give me a deeper understanding of the business logic and the all-crucial "why" to some of the crazy logic. While I was doing this, I sat down with a number of my coworkers to fill in the gaps in my knowledge. As always, ask the people that were there first!</p> Darkness</h2> While I was chatting and interviewing my coworkers about this bit of code, there was an ominous phrase that kept popping up...</p> This isn't the first time someone's tried to refactor that if statement.</p> </blockquote> ...great...</p> After some introspection and some poking and prodding at my ego, I finally decided that it'd make a fun side project to try</em>. If I didn't succeed, no worries, at least I had added a ton of tests around it so the next time it needed to change, we could be safe about changing it!</p> The Hunt</h2> After a number of false starts, thrown out code, and late nights I hit upon an interesting idea.</p> To look up a key in a Python dictionary, the get</code> method does two things. First, it hashes the key you're looking up and compares it with all the hashed keys in the dictionary. The second thing it does an equality comparison of the unhashed lookup key and unhashed dictionary key. I assume the second round is to prevent hash collisions, but I honestly don't know.</p> At the same time, I was looking into using namedtuples</code> as a way to encode multiple values into the key. They have the advantage of being immutable and have easy methods to get and set values (important for readability of the final code).</p> Shot and a Miss</h2> That was my next thought, encode all the logic into a namedtuple</code> "template" and compare the actual data against the keys in the dictionary.</p> Well, there's a problem with that. At runtime, we don't always have all the data necessary for a given branch of the codebase and, in fact, some of the data may be set, but it may not matter.</p> The upshot of this is that some branches of the if statement have an importance priority of the data looked up that's different than other branches.</p> A New Drawing Board</h2> So, again, I was stumped. If you compare two namedtuples</code> with one another, all the data has to match or they aren't considered equal. Even if I could solve that problem, there was still the problem of the hash lookup in the dictionary. If two namedtuples</code> don't have the exact same data in them, their hashes won't match and thus looking it up in a dictionary will always fail.</p> Digging into Python's hash magic methods, I hit upon a simple idea. Make all the hashes the same. That way Python is forced</em> to use the equality function on the namedtuples</code> when it compares them against the dictionary keys.</p> A New Hope</h2> Thankfully everything in Python has public visibility. The upshot of this is it means that I can create my own custom namedtuple</code> that provides all the benefits of immutability as well as the readability of the fields, along with a custom equality function.</p> What this all boils down to is this bit of code for creating the Template for the dictionary. These are meant to be filled with data and used as the keys in the lookup dictionary. In addition, this namedtuple</code> is used to fill out the data to be compared against the keys in the dictionary.</p> # Decision matrix used in determining which data process to kick off Template = namedtuple("Template", ['pred1', 'pred2', 'pred3', 'pred4', 'pred5', 'pred6', 'pred7']) # Default any non-filled out fields to None Template.__new__.__defaults__ = (None,) * len(Template._fields) # Disable the hash function Template.__hash__ = lambda self: 1 # Set our custom equality function Template.__eq__ = rd_eq </code></pre> Custom Equality</h2> "Custom Equality" is such a great term, and it really threw the more science-minded folks for a loop!</p> To ease their trepidation, I told them that I wasn't really</em> setting up a custom equality, I was making sure that it works as a template rather than an exact match. If data shows up in the template, it's important, if it doesn't, then it's not and can be anything.</p> Note that the bottom code is more complex than just a simple template. If you notice in the original code, there's a lot of if x in ['a', 'b', 'c', 'd']</code> thrown around along with at least one if ['a', 'b'] == ['a', 'b', 'c']</code> style. That makes comparing against a template messy.</p> def rd_eq(template, other): """Compare fields in template to fields in other if template.field is not None template and other are expected to be namedtuples, tuples, or lists. Order of the elements in each *does* matter. If an element is a list, make sure that all the subelements of that list appear in the template. :param template: namedtuple, non-null values are used for comparison :param other: namedtuple, all/some/none values can be filled out and will be compared with non-null values from template :return: true if the non-null values in template "match" in other, false otherwise """ # compare template type to other type if template.__class__ != other.__class__ or len(template) != len(other): return False for template_val, other_val in zip(template, other): if template_val is not None: # only "filled out" template values matter # compare element types if isinstance(template_val, list): if isinstance(other_val, list): # if all the values in the "template" don't exist in the "other", return false if len(set(template_val).intersection(set(other_val))) != len(set(template_val)): return False else: if other_val not in template_val: return False elif template_val != other_val: return False return True </code></pre> It's worth reading through a few times, but in a nutshell:</p> If the value of a field in the template is filled in, try to compare it</li> If the value of the field is a list and the value being compared against isn't, make sure the value being compared against is in the list.</li> If the value of the field is a list and the value being compared against is also a list, make sure the values in the template exist in the value being compared against.</li> </ul> The Final Frontier</h2> The last step in the crazy mess is to get our custom dictionary up and running.</p> First, we set up the list of templates in order from most-restrictive to least.</p> # Just a coupling of data function and basic log message to send FnRunner = namedtuple("FnData", ['fn', 'log_message']) decisions = [ (Template(pred2=['val1']), FnRunner(fn=self.process_data_2, log_message='Running data process 2')), (Template(pred1='first', pred3=[state_management_2.state1, state_management_2.state3, state_management_2.state4], pred4=True), FnRunner(fn=self.process_data_1, log_message='Running data process 1')) # <snip> ] </code></pre> Then we shove it in an ordered dictionary to preserve the restrictiveness (fun fact, ordered dictionaries are compared in-order)</p> self.decision_tree = OrderedDict(decisions) </code></pre> From there, we get the data to compare against and shove it into a Template namedtuple</code> and fire off the comparison:</p> # get the realtime data to compare against the templates runner_data = Template(get_decision_data()) # create a noop function if we don't find a lookup in self.decision_tree runner_noop = FnRunner(fn=lambda *args, **kwargs: RunnerResults(), log_message="Nothing to do, ignoring") # lookup the correct data runner function to run # this is where the equality is called and everything is bashed against one another data_runner_fn = self.decision_tree.get(runner_data, runner_noop) # finally, run the function we found output_data, log_message = data_runner_fn() </code></pre> Conclusion</h2> Once I was done with all of this crazyness and had a working prototype that passed at least some of the tests I bounced it off of the team. Their reactions were a pretty mixed bag, everything from disbelief that I had actually refactored the if-statement-of-crazy to curiosity at how</em> I had done it.</p> To be honest, I'm still not 100% satisfied with the result, but the feedback in the following weeks was nothing but positive. This is telling because around the same time, the business logic now encoded in the dictionary changed drastically. This change was estimated to take around 2-4 weeks in the old if statement. In the new one, it was done in 2 days.</p> I think the increase in productivity speaks for itself.</p> Doing what you Love 2016-12-31T00:00:00+00:00 Those that know me, know that I love</em> Clojure as a language. The simplicity of syntax and concept draws me like a moth to a flame. It wouldn't be too far to say it's my favorite language and I never have the option of developing anything in it.</p> I started with Clojure several years ago when I got fed up with the Python threading/multiprocessing pain. While it wasn't exactly the easiest language to learn, the community and the resources available online made the transition reasonably painless. I also probably have an advantage that I was never formally trained in object oriented principals or design and most of my training was either self driven or on the job so switching from object oriented to functional was much easier.</p> However, I've wanted to use Clojure on a daily basis in my role as a programmer almost since I started learning it. My team, management, and other developers, however, constantly push back on it because "it looks weird." Not kidding, that's a direct quote.</p> My frustration with this was building on a daily basis. It was triggered moreso because of the simplicity of the issue. 99% of the pushback against Clojure was due to the parentheses being on the left side of the function:</p> # this was deemed to be simpler/easier to read "\t".join([str(i) for i in range(100) if i % 2 == 0]) '0\t2\t4\t6\t8\t10\t12\t14\t16\t18\t20\t22\t24\t26\t28\t30\t32\t34\t36\t38\t40\t42\t44\t46\t48\t50\t52\t54\t56\t58\t60\t62\t64\t66\t68\t70\t72\t74\t76\t78\t80\t82\t84\t86\t88\t90\t92\t94\t96\t98' </code></pre> ;; than this (clojure.string/join "\tab" (filter even? (range 100))) "0\t2\t4\t6\t8\t10\t12\t14\t16\t18\t20\t22\t24\t26\t28\t30\t32\t34\t36\t38\t40\t42\t44\t46\t48\t50\t52\t54\t56\t58\t60\t62\t64\t66\t68\t70\t72\t74\t76\t78\t80\t82\t84\t86\t88\t90\t92\t94\t96\t98" </code></pre> Note than in the Python version there are 4 groupings (parens and/or brackets) whereas in the Clojure version there are three</em> groupings. Tell me again about how many more parentheses there are in Clojure?</p> In addition, if you can't move the opening paren to the left side of the function and still read it, you've got bigger problems than what I can fix:</p> str(1) "1" </code></pre> (str 1) "1" </code></pre> Yes, I realize that these are both contrived examples, but they illustrate the core point of my frustration. Clojure is not</em> harder to read, it's different</em>. And if you can't or don't want to learn something new then you're in the wrong profession.</p> So, because no one else was interested in learning it or supporting it in production, to ease the discomfort I was feeling with being stuck, I forged ahead anyway. But, I did so with caution and pragmatism. We had a very small issue that was plaguing us for some time. A Python process would every once in a while log a traceback. We had no out of the box way of getting at the full text of those tracebacks in any of our metrics, logging, or reporting tools as Python tracebacks span multiple lines. In addition, the process would retry a given number of times so not all tracebacks should be pushed to the visibility of the engineering team, necessitating some custom logic. The existing alerting pushed notifications to Slack, but without the full text of the traceback and it pushed all tracebacks, not just the critical failures and left out some important debugging details.</p> As an isolated, non-mission critial (the other alerts would continue as-is for some time) task, this seemed like a perfect location to introduce Clojure as a solution.</p> Github: Tracebackfilter</a></p> It's now been in production for close to 2 months now and has been working like a charm. In addition, no one has derided the fact that it's written in Clojure. Not only did I really enjoy writing it, it's become a gateway for showing other people what Clojure looks like that's actually in production!</p> Build what you love, even if it goes against the grain, but do it pragmatically. It's the only way to push us forward.</p> When It's Time to Move On 2016-12-31T00:00:00+00:00 I'm now in the final stages of moving from my current company to a new one. What follows is a rundown of what's been going on in my brain throughout the entire process, my motivations, and my reasoning.</p> This is not intended to disparage my current company nor hold the new company up on a pedestal. This is my (limited) perspective.</p> Coming to Conclusions</h2> Hindsight is, of course, 20:20. Every time I've left a job, I've been able to see where the thought of leaving started, why it kept brewing for so long, what I did or didn't do to perpetuate the thought, etc. With each new job, I'm unable to see that moment when it actually happens, or for that matter, I can't seem to see the lead-up to that moment.</p> Why am I feeling like leaving?</h3> I can cite many reasons for leaving at this point, but what it comes to is two points. I'll dive into these in a moment.</p> I'm feeling bored and have been for some time * Bored People Quit</a></li> I feel like management ignores my voice and perspective</li> </ul> Bored?</h4> Talk about a first-world problem, right?</p> "I'm booooreddddddd, somebody give me something interesting to dooooooooo"</p> </blockquote> It's not as trite and silly as it sounds though. If you haven't read the above link, stop reading this and go read Bored People Quit</a> now otherwise what I'm going to say going forward won't make much sense.</p> At my current position, I ended up getting hit in the crosshairs of two separate "boredom" concepts that Rands talks about:</p> Keeping an interesting problem squarely in front of them.</p> </blockquote> They can only ‘take one for the team’ for so long.</p> </blockquote> Somewhat related to one another, my position ended up being prod support for an unnecessarily complex and complected</a> piece of software. While I understood the reason behind my "taking one for the team" (I actually volunteered for it because I was the logical choice given domain knowledge, skill set, etc), it extended far longer than I expected and far longer than I was able to be intrinsically motivated. Prod support isn't terribly interesting and this exacerbated the situation.</p> I should have realized that I was getting "bored" much sooner than I did and I take full responsibility for that.</p> When I realized what was going on and started speaking up... well...</p> Is anyone truly listening?</h4> In short, I felt like no one was hearing my concerns. I was speaking out primarily in one-on-one meetings, but occasionally in larger meetings, "hey, we need to stop band-aiding this issue and actually</em> fix it."</p> As a shy introvert, I tend to not speak up a lot. This leads to my team lead or manager putting on literally</em> every review "needs to speak up more". Same thing I've heard since elementary school. Sorry people, I'm not wired that way. If I'm talking, chances are I have something important to say. Unfortunately volume, in both loudness as well as amount, is valued over content.</p> This historically has led me into a downward spiral of "no one's listening to me anyway, why should I speak up?!"</p> What am I looking for?</h3> This was a critical question for me to answer. Was I looking for "different" or was I actually looking for something "better"?</p> Those look different from one another and I decided that I was looking for "better". This led me to turn down interviews and severely limited which companies I was applying to. Where I work is</em> a good place to work so finding "better" ended up being an interesting challenge. I was done with the current company by this point and my intrinsic motivation had shifted from "working on something interesting" to "finding something interesting to work on".</p> Looking Elsewhere</h2> Resumes and interviews are a game of numbers. With that in mind, the best advice I can give is to spread your resume as far and wide as you possibly can. My offer came through a new-to-me website called Hired.com</a> which I was very happy with. It took me a couple of tries to get responses from companies but I had two solid interview experiences and almost nothing by applying directly. I estimate that I probably sent out my resume to 20-30 companies.</p> Out of that pool, I got a grand total of 4 phone screens, which led to 3 2nd phone screens, and 1 on-site.</p> Like I said, it's a game of numbers.</p> Different vs. Better</h3> The Final Decision</h2> How does it feel to leave the best company you've ever worked for?</p> </blockquote> Leave it to one of my best work buddies to ask the hard questions. What it feels like to me is I'm not leaving the best company I've ever worked for. I'm leaving a company. That's it. When I first started, it was the best company I'd ever worked for but over time, that transformed into "just another job." Once it hit that point, it was no longer the best company I'd ever worked for.</p> The Fallout</h2> Emotions Run High</h3> It's important that once you make an announcement you let any feedback roll off your back. Coworkers will feel betrayed, happy, angry, panicked. The whole gamut of emotions, sometimes in rapid succession, sometimes all at once. It's rough, both for them and you, so give them the benefit of the doubt.</p> Who is this person anyway?!</h3> You find out interesting things about people when you "betray" them by leaving. Remember, leaving a company is like going through a breakup. You're essentially telling them and the company that they aren't good enough. Try to let them down easy but don't patronise them either. And for insert-deity-here's sake, help through the transition. You're already holding a blow torch to a gas-soaked bridge by leaving. Do your best to not light the bridge!</p> Time Off</h2> Always, always, always, make sure to take at least a week off between companies, longer if possible. Take that time to reset, clear your head, and drop any baggage you were carrying from your former employer. It's not fair to the new company, your new coworkers, or yourself to carry that pile of crap with you into the new job.</p> Freshness</h2> Once you've (hopefully) taken that time off, walk into the new company with fresh eyes. Your first months at a new company are the most valuable, in my opinion. You have the perspective of looking at the code, infrastructure, policies and procedures, etc with an outsider's perspective. That perspective doesn't last long so at the very least take notes and ask the dumb questions</em>. Those questions that seem simple on the surface but question the status-quo. That's not to say you should expect anything other than "that's the way things are and we can't change it."</p> That being said, you might just spur a vastly positive change for the company. At worst, you learn a ton about the history of the company and how they got to "now" which can only make you more effective at your new job.</p> Why I love RPG's 2016-08-27T00:00:00+00:00 Introduction</h2> For the people that know me, they know I love</em> RPG's, whether they be computer based, tabletop, or just reading the new source book that came out yesterday. Maybe it seems a bit odd to the general population with questions like "isn't that dangerous/satanic?" Seriously, this still gets asked 30+ years after D&D (Dungeons & Dragons) was put in the same category as fictional satanic cults. But I digress. In this post I hope to answer the "why" of RPG's for me and maybe encourage you to take a look at them as well.</p> What is an RPG?</h2> Anyone that's played an RPG can feel free to skip over this section. I'm including it for anyone that has no clue what I'm talking about. For the most part I'm going to be focusing on tabletop/in-person RPG's, not the computer variety.</p> In a nutshell, you can think of an RPG as 3-6 friends, sitting around a table for a few hours, telling a story together. That's it, the rolling of dice, rules, character sheets, etc is all ancillary to the telling of a good story together.</p> RPG stands for Role Playing Game. What that means is you take on the persona (or role) of a character in a story. In most</em> games, there are 2 primary roles: the Player Character (PC), and the Game Master (GM). In some games the GM is called the Dungeon Master (DM) but for the most part they are interchangeable terms.</p> The GM plays the part of the world. I.e., they tell the PC's what they see, set difficulties to determine whether PC's succeed or fail at a given task, act out the part of any Non-Player Characters (NPC's), and just generally run the game. They, in most games, also spend quite a bit of time outside of the actual game session thinking up and researching the "bones" of the story and the setting.</p> The PC's act out the part of their characters in the game. They take on the persona of a character and generally explore, fight, and experience the setting and story.</p> Normally players meet in-person or in an on-line voice/video chat on a regular basis for sessions. A session can be thought of as a chapter in a book or the amount you would read in one sitting. It can last anywhere from a few minutes to upwards of an entire weekend. In my own experience, everyone generally starts getting tired and burned out after about three hours or so. In a general sense a session is the telling of a part of the story by the GM and PC's, resolving of challenges/battles, and gathering rewards to further character development.</p> Why I find RPG's interesting</h2> There are a number of reasons why I find RPG's so interesting. The first of which is you're telling a story with friends that has never been heard before. Even if you're following a published adventure, what happens during the adventure is unique to your particular experience in that moment. Moments such as the classic joke "I'm attacking the darkness!</a>" seem to come out of almost every session. On top of that, it's not just a shared story, it's a shared experience that can be touching, moving, filled with despair, sprinkled with moments of wonder, all in a single session. As humans, we have an almost primal need to tell and hear stories with our fellow companions. This is just another avenue for that. RPG's provide useful guidelines for people who aren't natural storytellers or are uncomfortable telling stories.</p> In addition, in our digital age of increasing isolation and fewer meaningful connections with other humans, there's something so incredibly satisfying about spending a couple of hours just talking with other people in-person about something you all, very quickly, become emotionally invested in.</p> The final reason why I love RPG's is they're a chance to escape. Escape from the day-to-day routine into a fantastic world where you're saving the local town from a dragon or from a killer alien. It's a chance to become epic</em>. Which, far too often in our own world means financial status. For me, having enough money so my survival needs are taken care of is a necessity, but on some level it still feels empty somehow. If I just saved an entire town from a flood caused by the local villain, it gives me an immense sense of satisfaction. Just the same as if I were the GM and setting up this scenario and seeing my players overcome the challenges I've laid out.</p> Source books</h2> Or, why a source book can sometimes be better for me than any novel.</p> It all comes down to potential. A novel, even a fantastic one, is already written. The story is already known, even if I haven't read it yet. A good novel for me focuses much more on the world-building aspect. While I'm reading the story and following the main characters, the rest of my brain is filling in details about the world. Everything from what's over the ridge that the characters never quite make it over, to the tavern owner that only has a paragraph devoted to her and then isn't mentioned for the rest of the book. What's her life like? What other interesting characters has she seen? Is her tavern successful or does she owe a debt to a sketchy underworld boss?</p> A source book provides all the world building I could ever ask for without all the pesky details of a story already written. It allows my mind to run wild, filling in any details it chooses to. Some of these have the potential to turn into adventures for my PC's. Which brings me full circle. Now it isn't just a story I've made up between the lines of someone else's story, it's now my own story. One I can share and share in the writing of with friends over many sessions.</p> Source books also spark my creativity to life. Whenever I'm in a creative rut, even if it's not planning for the next session for my PC's, the very act of looking through a source book can spark all</em> of my creativity to life. No longer am I bored with photography, or woodworking, or any of the many arts I pursue. That spark has returned and I am, once again, able to create to my heart's content.</p> Concurrency Part 2 2016-07-08T00:00:00+00:00 Wow, even trivial concurrency in Python is hard...</p> So, you have a list of tasks that you want to consume lazily (as they're generated, so you don't blow up memory). Great! That's easy to do with a generator function using the yield keyword or the (syntax). But, oh no... you can't pass that to a multiprocess function because it's not picklable. Drat!</p> Next, you go down the road of:</p> p.map(worker, itertools.islice(generator_function, slice_size)) </code></pre> Which is great, until you want to lazily push results back to the main process because that work now blows up memory.</p> for block in p.imap(worker, itertools.islice(generator_function, slice_size)): do_additional_work() </code></pre> The above won't work because again, generator functions aren't picklable so you have to return result sets from the worker function instead of being able to yield rows back.</p> So, you end up shoving as much as you can into the worker function so that you don't have to deal with passing large chunks of work back and forth. I'm sorry, but this is a terrible state of things. I'm sure there's libraries that help to ease this pain but my point is there shouldn't NEED to be libraries. This should be core python. And yes, sadly, I'm stuck on 2.7x.</p> How-to: Read from STDIN or a File in Clojure 2016-06-20T00:00:00+00:00 or... how to avoid wasting 2 days!</p> First, the completed code:</p> (ns char-check.core (:require [clojure.tools.cli :refer [parse-opts]]) (:gen-class)) (defn exit "Exits the program with a status code and message." [status msg] (println msg) (System/exit status)) (defn main "Main function. Calling without a file object results in reading from STDIN (*in*). Otherwise, opens the in-file as a stream." ([] (main (java.io.BufferedReader. *in*))) ([in-file] (with-open [r in-file] (line-seq r)))) (def cli-options [["-h" "--help"]]) (defn -main "Entrypoint, parses arguments, exits with any errors, provides args to main." [& args] (let [{:keys [options arguments errors summary]} (parse-opts args cli-options)] (cond (:help options) (exit 0 summary) errors (exit 1 (join "\n" errors)) (empty? arguments) (main) :else (main (clojure.java.io/reader (first arguments)))))) </code></pre> So, here's what we're doing... first, take a look at:</p> (cond (:help options) (exit 0 summary) ;; if we get the help option, spit out some help! errors (exit 1 (join "\n" errors)) ;; if we get errors, print them out and exit (empty? arguments) (main) ;; if we don't get a file argument, call main with no args and let it take care of things :else (main (clojure.java.io/reader (first arguments))) ;; if we got an argument, treat the first argument (yeah, it's naive...) as a filename and wrap it in a file reader ))) </code></pre> So, this is pretty basic flow control for the command line arguments and the presence or lack of a filename to run through. Arguments come in through the & args</code> and get parsed via parse-opts</code>. This results in any filenames ending up in arguments</code> and if we don't get any, pass that along to main. If, however, we get at least one, grab the first, wrap it in a file reader, and pass it along to main (arity 1).</p> The next bit is in the main function:</p> ([] ;; arity 0... if we don't get any arguments, call main again, but this time pass it a BufferedReader wrapped *in* (main (java.io.BufferedReader. *in*))) ([in-file] ;; this will either get called with the arity 0 function and be passed *in* OR it will have an actual filename that can then be opened up and operated on. (with-open [r in-file] (line-seq r)))) </code></pre> So here we're either getting 0 or 1 argument. If we get 1 argument, great, treat it as a file and run with it. Otherwise, we got 0 arguments which means we need to wrap *in*</code> in a buffered file and then pass it along to the arity 1 "version" of main.</p> The final bit is (line-seq r)</code>. That's a lazy function to return lines from the file/stdin. Use that like you would any other lazy sequence.</p> Reading Update 2016-06-16T00:00:00+00:00 So, after about 8 months of on-and-off focusing on reading more long-form items, how am I doing? Objectively, I'd give myself a C-. Barely passing, and here's why.</p> I can absolutely say that I'm doing much better at reading long-form items. Currently I'm working through Stephen Hawking's Illustrated A Brief History of Time and The Universe in a Nutshell. Fantastic read, really engaging, and it's great to be able to relax with a book before bed.</p> That being said, I haven't been doing as well at actually finishing</em> long-form books. I have at least 3-4 books going on my Kindle right now with almost no motivation to finish them. I can't quite say why, though I wish I knew. I think part of it is dealing with some pretty serious depression lately and that, of course, seems to drown any motivation to do much of anything.</p> So, plan going forward? Make time (at least 30 minutes a day) to read something on the Kindle. Mornings may actually be the best time for this as I normally screw around on my phone for at least that much time before leaving for work. Discipline, right?</p> Burnout 2016-06-13T00:00:00+00:00 Burnout ...and possibly how to defend against it.</p> A little bit of backstory is probably in order. For me, burnout has never been a problem until this past month. Working on a migration from a data center to the cloud that's run over 6 months of constant work has gotten me pretty fried. We're nearly at the end and I feel like I've gained quite a bit of perspective on this problem, at least for myself. I feel like I'm actually in a decent place to talk about how I prevented total burnout/quitting/etc and maybe what I've learned can help someone else (including myself, the next time I'm facing burnout).</p> First off, there are two things that I believe contribute to burnout. Time sinks and mental energy sinks. Context switching is a great example of a time sink. We all know that we lose at least 15 minutes of productive time when we context switch. What we don't always realize is how much mental energy we spend. Burnout happens when we either have no more time or no more mental energy. Time can be recovered by extending deadlines, having other knowledgeable people help on the problem, etc. Mental energy however is being constantly drained while working on a given problem. For me, I find very few ways to recover that energy, none of which are quick. So, what we have are two ways of preventing burnout:</p> Reduce</em> mental energy drain</li> Replenish</em> mental energy</li> </ul> Let's tackle the reduce</em> problem first.</p> Reducing Mental Energy Drain</h2> Support System</h3> Having a good, solid support system of friends, family, and coworkers is the first thing that helped me prevent mental drain. Knowing that someone has your back when you're spending all of your mental energy fighting through an obscure bug in a complex ETL system that's been mangled and munged just to get it working is shockingly helpful. Just as having an significant other that understands why you're mubling under your breath at the dinner table and get up in the middle of eating because you just had a breakthrough can save your sanity and your relationship.</p> Tooling</h3> Any tool you currently use that adds to your cognative load or adds barriers to solving problems needs to be thrown out a window, right now. You're not doing yourself any favors by using something that's not quite good enough or even "good enough". Your tools are extensions of your brain and anything that's standing in the path between your brain and the solution to your problem needs to help, not hinder. Everything from the keyboard you type on, to the headphones you use to stay focused, to the text editor you write blog posts in. Everything matters. So much so that you, right now, need to take a good hard look at the tools you use and identify any that are problematic. No, I really mean that, go do it now. I'll wait.</p> Breaking down problems</h3> The brain can only handle so much at any given time, so, to prevent mental drain, give it less to chew on. If you have a large problem, first, document what the problem is. Then, if it's still to large, start breaking it down into managable chunks, documenting each of those and then take them one by one. I guarantee it'll be easier than trying to tackle the entire thing, all at once.</p> Replenishing Mental Energy</h2> Play</h3> Hopefully you have an office as relaxed as mine as I find that shooting one another with nerf guns and having impromteau "nerf wars" is a huge</em> stress relief and a way to remember that your coworkers are just as stressed as you are and</em> that they're just as human, childish, and fun as you are. Failing that, make time to go do something fun, whether that's gardening, 4-wheeling, or just going for a walk in the park.</p> Get away from the computer</h3> No, seriously. The more time I spend with computers, the more I've come to realize that I need time away from them. If you're under a deadline, this "time away" definitely comes at a premium, but is vital to replenish some of your mental energy. Bonus points if it happens to be something physical. Several things that have worked for me have been tai-chi, woodworking, yard work (no, really! I actually find that mowing the lawn is a very meditative act), and reading a good novel (no technical books!!!).</p> Meditation</h3> For me, this consists of either mindfulness walking or of the "classic" meditation of emptying my mind. I'm not sure why this is so helpful to me, but it always seems to allow me to regain focus and just be able to think clearly again. Your mileage may vary.</p> Exercise</h3> Okay, so this is something that I'm pretty terrible at being consistent. That being said, having some sort of exercise (even if it's just going for a 30 minute walk) can be incredible helpful in recharging your mental energy. I've found, personally, that I need to have a good balance between the physical and mental aspects of my life and if I don't have at least a walk every other day, I end up being more mentally exhausted than I "should be".</p> List of Wonderous Links 2016-03-10T00:00:00+00:00 This is going to be nothing more than a link post of articles and blogs that have resonated with me in a powerful way. All of these relate to job "stuff", not tech stuff.</p> Minor Offenses</a></li> The Elves Leave Middle Earth</a></li> Six Languages to Master (archive copy)</a></li> What to Write</a></li> You Need to Start a Whizbang Project Immediately</a></li> Programming Without a Net</a></li> Care and Feeding of Software Engineers</a></li> How to Level Up as a Developer</a></li> Rands in Repose - Management</a></li> </ul> Wow... 2016-01-03T00:00:00+00:00 What a vacation... note to self, as someone that always needs to be creating something for his own wellbeing, never take a vacation without a purpose or something to do, otherwise, you'll go crazy!</p> The Most Important Skills for a Software Developer 2015-11-10T00:00:00+00:00 First off, this isn't going to be a post about languages, technologies, etc. It would be borderline pointless to write one of those as they come and go so quickly, which brings me to my first important skill:</p> Adaptability</h3> Or, if you don't change, you die. Sure there are still some COBOL programmers around, and I'm sure they get paid a lot of money to keep what's essentially a dead skill around, but I have a suspicion that field is shrinking. We've been making a pretty heavy push at work to migrate everything up to the cloud lately. In a lot of cases it's a pain in the ass to do so, but in the end, it'll probably be worth it. Now, imagine yourself as being "that guy" (I'm using the male pronoun on purpose here) that won't adapt, won't learn, won't grow with whatever direction the business wants to go in. Imagine yourself out of a job!</p> Curiosity</h3> Or, I wonder what this does? This is the one place where a lot of more experienced developers lose their way (speaking from my own personal experience, of course). If you react to something new with "ugggh, it's something new that I have to learn" instead of with wonder, it might be time to re-examine some things. In some ways, it's your job to constantly be pushing the boundaries of what can be done in tech. A large part of that job is learning about what others have done and then implementing that to make things better.</p> Exploration</h3> Or, huh, that sounds interesting, let's go exploring! In essence, this is the flip side of curiosity. Instead of learning someone else's tech, go build something new. A great reminder for this is to have a 'whizbang' project folder on every computer you control. It's a gentle nudge to always be thinking about the really hard problems. This concept came from Jeff Knupp's awesome blog: Whizbang Project Post</a></p> Fearlessness</h3> Or, break stuff! Get your hands dirty! Is it a technology you don't understand, can't wrap your brain around? Who cares! Go play with it, get it installed, get a hello world working, and then go nuts. It's one of the best ways to internalize how a given technology can work (or not!) for you. As long as you're not driving your local sysadmin nuts with breaking hardware, you should be good. All of this boils down to having an entrepreneurial mindset as it relates to pushing tech forward into the future. If you're not learning, pushing things forward, making stuff better, then the question you need to be asking is whether you're stagnating. If you're stagnating it makes it very easy to replace you unless you've built walls of code around your position that only you understand. And that, very quickly, turns you into a curmudgeon (or a BOFH).</p> Don't be a curmudgeon, no one likes 'em and I've never seen one that was actually happy.</p> Reading 2015-10-26T00:00:00+00:00 So, reading. It's something I grew up loving. I used to spend every waking moment with my head stuck in a book. Everything from software development to high fantasy to memoirs. This began when I was very young, my parents used to read to me every night before bed and my dad promised me that whenever we went to a bookstore, he'd buy me whatever I wanted to read as long as I kept reading. Of course, at that time, it seemed like he'd just given me the keys to the candy store and he pretty much did.</p> From then on, I was a "reader". It always amazed me when I talked to someone that didn't read. I always thought in my head that they must have a very boring life and I was always very close to labeling them "stupid".</p> All that changed a few years ago and, to be honest, I'm still not sure what really happened. I feel like it started around the same time I got a smartphone. Now I could read short blogs, tweets, page-long articles, wherever I wanted for free. Fast forward a couple of years and I still buy paper books but I don't read them as often. I've gone from reading books several hours every day to reading maybe once a week for an hour if I'm lucky.</p> I hate it.</p> I hate the fact that I'd rather look at a screen than feel the pages of a book in my hand, smell the paper and ink, visit old friends between those pages.</p> I hate that I've gone from being a "reader" to being a "dumb" smartphone user. To becoming one of the people that I couldn't understand when I was younger.</p> I hate it and I'm going to change it.</p> I'm not sure what that looks like. I've been seriously considering a kindle paperwhite lately. Mostly because it feels like a bridge back to reading what I used to love, books. On my phone I primarily read blogs, hacker news, facebook, twitter, very short form things and I've found over the past year or so that I'm almost unable to keep my attention focused on anything longer. At least with a kindle I can switch between stories as I'm reading and "stretch" my attention span back out.</p> It's difficult to extend my own personal experience to the general population at large, but I do feel that children and adults both have shorter attention spans. Both due to the massive amount of information we're expected to consume and retain on a daily basis and to the massive amount of information we CAN consume at a moment's notice.</p> Will my experiment to change myself work? I guess we'll see in a few months.</p> Vacation is Hard 2015-08-18T00:00:00+00:00 ...not necessarily because going on vacation is hard, but coming back from it? Oof.</p> I just spent 10 days camping without cell phone service at a spiritual retreat. Had a great time, hung out with friends that I only see once a year, and had some seriously knock-your-socks-off spiritual moments.</p> Then, the return to day-to-day "normalcy". Usually it takes me a few hours, maybe a day at most to get back into the swing of things. For whatever reason this time? It's already a week and I'm still not back. And, when I say "I'm not back" what I mean is that my brain isn't working in normal mode yet. Here, let me give you an example.</p> When camping for 10 days with 200+ of your closest friends it's "normal" to have a 10'x10' popup structure for your kitchen, a 10'x20' carport for your living room, and have an 8 person tent for 2 people. This, of course, presents challenges. Things such as "how do I keep water from dripping down between the kitchen and the living room".</p> The context switch between solving such physical, tangible, see-results-immediately problems and solving "how do I connect to this database through a ssh tunnel again?" is so massive I don't have words to describe it and I haven't been this tired in a long time. I've tried "easing" back into it and that failed pretty miserably when I couldn't remember half my passwords which immediately threw me into option 2 "jumping into the deep end" which also failed miserably.</p> What I can't get out of my head is what an amazing time I had camping and how much I wish I was right back up there. It's a calling on a deeply personal, spiritual level. Maybe the only answer is to try to rebuild that same experience here back in the "real world".</p> Wish me luck...</p> Concurrency 2015-07-08T00:00:00+00:00 Or... why Python will eventually become irrelevant.</p> Imposter Syndrome 2015-05-26T00:00:00+00:00 Wikipedia</a></p> Essentially, it's the opposite of the Dunning-Kruger effect. You feel that your skills are less than those of your peers and that you're just skating by on luck. One day, someone is going to discover you don't really know what's going on and bam, your career is over. Is this an irrational fear for most of us that have it? Of course. Does that change the fact that we still feel incompetent when rating ourselves against our peers? Nope!</p> So, how do you get over it?</p> That, my friends, is the real question. Some days I'm able to overcome it just by looking at the work I've done. Other days, I need to look at my "feathers" file. If you don't have one of these, you should start. Essentially, take any positive feedback you get from anyone you work with and put it in a folder (file, email, evernote, dropbox, or an actual physical folder). It's the "I'm having a shitty day and need to be reminded that I'm a good person" folder. Whenever you're having an "off" day, take 10 minutes and look through it randomly. This folder also helps when it comes time for your self-review or if you're looking for a raise.</p> Other days, not even that will help. On those days, you just soldier on, try not to push any code that'll break production or the build, do any yak-shaving that needs to be done. Basically, you want to try to prevent reinforcement of the imposter syndrome.</p> The final way that I deal with it is work on a side project. Usually it's work related, something that's very niche, something that just makes me happy. Obviously, this isn't always an option so sometimes I just push through the day and when I get home I work on something like that. Woodworking, chainmaille, whatever it is, it's usually something not computer related.</p> To paraphrase Tim Ewald in Programming With Hand Tools</a></p> The more I spend time with computers, the more I need to spend time with things that aren't computers!</p> And that, for me, helps me to realize that computers aren't the sum total of my existence. My code is not me</em>.</p> BOFH 2015-05-20T00:00:00+00:00 (bastard operator from hell) What a term. It used to only apply to curmudgeonly sysadmins and the neckbeard elite but I've noticed lately that it can be applied to a large number of other IT professionals. Specifically, I'm talking about developers.</p> I know you have to sit in your cube staring at page after page of incomprehensible piles of crap code written by someone else that clearly didn't know what they were doing. I know that you have to spend hours with a debugger to find a misspelling in a string variable's value. I know that it can take a day and a half to find the missing semicolon that's been causing compiler errors. I know that it makes you want to defenestrate your laptop, cubicle, mouse, keyboard, and anything else within arm's reach.</p> How do I know this? I do it all day too and it drives me up the wall probably just as much if not more than it does you.</p> Here's the thing my fellow developers. Users, sysadmins, managers, and other devs are NOT out to get you. They are not out to make your life a living hell, nor are they trying to get your job. In fact, most of them probably wouldn't want your job if you offered it to them on a silver platter. Remember, you make things happen. That's a huge power and a huge responsibility and most people don't want either. But, I digress. Users, sysadmins, managers, and other devs are people, just like you. They have just as hard of a time understanding the meatbag sitting in a cubicle staring at "gibberish" (and occasionally writing some) as you do understanding the meatbag that seems to have a job consisting of nothing but meeting people. A smile, friendly hello, or 30 seconds taken to listen to a problem can go a long way toward building common understanding and a good working relationship.</p> So, here's my personal guide to working well with others:</p> Be nice to people, you'd be amazed at how you can get along if you follow a potentially negatively misinterpretable comment with a smiley face :) (but the thing is, you actually have to mean the smiley face)</li> You are not your code. Sure, you wrote it, does it define you as a person? I sure hope not because I know I've written some really crappy code and I don't want it defining me! If someone wants to throw it out in favor of something better, let me grab the trashcan and hold it for 'em.</li> Condescension kills. Do not, under any circumstances, no matter what the situation (even if they're a drooling idiot) act in a condescending manner to anyone. Basically you wouldn't want someone else treating you like you're an idiot for not knowing that rm -rf / will blow up your linux box. Remember, at some point, you. did. not. know. what. you. know. now!</li> If you're not in person, over communicate. Most communication mediums have a way of ignoring someone if they're too communicative. But, as a dev, chances are you're on the under-communication end of the spectrum.</li> If you're absolutely right, there's a good chance you missed something. Basically, you're never right all the time, and if you are, your career is over because you've stopped learning. Never stop learning and never stop being wrong. (this also helps when debugging... "print" rarely breaks, but the code you just introduced breaks more often than you think ;) )</li> Listen to people. And when I say listen I don't mean "wait for your turn to speak." I mean really listen, understand what they're saying and try to figure out their motivation for saying it.</li> Ask questions more than make statements. It's much easier to hear "Was there a reason you left a debug print statement in?" than "Don't leave debug print statements in!" It's giving them the benefit of the doubt, but make sure you don't sound condescending when you ask.</li> </ul> In closing, don't be a BOFH. Nobody likes them and while being the outcast was cool in high school, it doesn't work as a career.</p> On Python, Clojure, and PHP 2015-05-15T00:00:00+00:00 So, I sort of fell into programming. When I was a kid, I learned QBasic because it was the only way I knew how to put games on my computer. At that point, my father wouldn't buy or install games on the 286 we had, so I had to do it myself.</p>

(import this)

Trail Fixes

Trail Fixes</h1>

Cost Center or Loss Prevention Center

What I'm Currently Doing

What I'm currently Doing</h1>

Work</h2> Fantastic company (Recharge</a>) that really cares about the people that work for them and their clients</li> </ul> Learning</h2> Offroad vehicle recovery, maintenance, driving (perpetually)</li> Mindfulness Meditation</li> Stoic Philosophy</li> Welding</li>

Learning</h2> Offroad vehicle recovery, maintenance, driving (perpetually)</li> Mindfulness Meditation</li> Stoic Philosophy</li> Welding</li>

Tools I Use

Uses</h1> A succinct overview of tools I use on a regular basis, mostly focused on my day job of software development but possibly other random stuff thrown in.</p>

Log all (fish) commands

Bolt Grades

Driving

Driving</h1>

Technique</h2>

Drivetrain

Drivetrain</h1>

Engine</h2>

Transmission</h2>

Manual</h3>

Automatic</h3>

CVT</h3>

Transfer Case</h2> Part-time 4WD</li> Engages the (almost always) front driveshaft</li> Front and rear driveshaft spin in step with one another</li> If rear driveshaft goes, can drive out in FWD w/ the transfer case engages</li>

Solid Axle</h2>

IFS</h2>

Other</h2>

Adult Education

Adult Education</h1>

Introduction to 4 Wheel Drive

Introduction to 4 Wheel Drive</h1>

About this Blog

Hi-Lift Jack

Hi-Lift Jack</h1>

Uses</h2>

Spreading</h3> Setting the area to be spread between the base/top clamp clevis and the nose of the jack (facing outward away from one another). Very similar to lifting.</p>

Clamping</h3> Setting the area to be clamped between the top clamp clevis and the nose of the jack (facing inward toward one another).</p>

Write It Down Yo

CSV Primer

One file</h2> Trust me, it's much</em> easier to parse records when they're all in the same file and not spread out over, say, a "data" file, "price" file, and "inventory level" file. All the data in one place.</p>

Have the header be the first line</h2> If it's not the first line, it can be worked around in most cases, but that's additional customization, which introduces fragility.</p>

Line Endings</h2> This is what determines where a new line/record starts.</p> Please please please use just \n</code> for a line ending, \r\n</code> works too. If you must, use just \r</code>. Finally, don't mix them, please!</p>

ETL Tracers

What are the components of a tracer?</h2>

Source Data</h3> This is as close as you can get to what the source data looks like. Remember, this record is going to be flowing through your system like a regular record would.</p>

Extract/Transform/Load Expected Data</h3> This is the expected output of each of these three stages. Include only the ones you feel are necessary. In my case, the transformer is the most critical step and as such, we crafted tracers around identifying transformer problems.</p>

2019 Year in Review

Books</h2>

Audio</h3> It Burns (Marc Fennell) Short and fascinating story about the hottest of the hot peppers. Sounds boring I know, but I was pretty captivated on my way home from Burning Man by it.</li> </ul> </li>

Drowning in a Sea of Complexity

Onboarding Is Hard (part 2)

Onboarding Is Hard

Projects

Including the Why

Music to Work By

Goldilocks and the Three Company Sizes

Python to Scala

Git Commit Messages

Tools I Work With

Predict the Future of Your Industry

YAGNI Revisited

2017 Recap

Games Played</h2>

Books Read/Listened To</h2>

Uses</h1>
A succinct overview of tools I use on a regular basis, mostly focused on my day job of software development but possibly other random stuff thrown in.</p>

Spreading</h3>
Setting the area to be spread between the base/top clamp clevis and the nose of the jack (facing outward away from one another). Very similar to lifting.</p>

Clamping</h3>
Setting the area to be clamped between the top clamp clevis and the nose of the jack (facing inward toward one another).</p>

One file</h2>
Trust me, it's much</em> easier to parse records when they're all in the same file and not spread out over, say, a "data" file, "price" file, and "inventory level" file. All the data in one place.</p>

Have the header be the first line</h2>
If it's not the first line, it can be worked around in most cases, but that's additional customization, which introduces fragility.</p>

Line Endings</h2>
This is what determines where a new line/record starts.</p>
Please please please use just `\n</code> for a line ending, \r\n</code> works too. If you must, use just \r</code>. Finally, don't mix them, please!</p>`

Source Data</h3>
This is as close as you can get to what the source data looks like. Remember, this record is going to be flowing through your system like a regular record would.</p>

Extract/Transform/Load Expected Data</h3>
This is the expected output of each of these three stages. Include only the ones you feel are necessary. In my case, the transformer is the most critical step and as such, we crafted tracers around identifying transformer problems.</p>