Forem: Andy Huynh

A Brief Introduction to Sales Engineering

Andy Huynh — Mon, 11 Dec 2023 19:51:45 +0000

Sales Engineering is the intersection of technology and sales. It's ideal for people like:

Extroverted engineers
Sales people who enjoy talking technology
Not your grandma that doom scrolls on Facebook

In the words of Chris White, the author of The Six Habits of Highly Effective Sales Engineers

(Sales Engineering) is simply to show them – no, CONVINCE them – that your software, solutions, and company will meet their requirements, solve their problems, and enable them to achieve their desired outcomes.

What do Sales Engineers sell?

Well that depends on the company you're working for and your level of expertise in their product. Knowledgable Sales Engineers (or SEs) can sell products ranging from AI productivity tools, endpoint security solutions to grid-scale power converters. They become subject matter experts (SME) in the product and become the go to resource as a vendor when companies are interested in integrating your product into their systems.

What if I'm an experience software engineer?

There are plenty of SaaS companies interested in your skillsets in application development, security and devops. Software engineers that like to talk can make a lucrative career in Sales Engineering. Companies like Snyk, Crowdstrike and Automattic have dedicated SEs that work with customers in pre-sales (before purchase) and post-sales (after purchase) to ensure the customer journey is successful. As an engineer, if you don't want to go through yet another 2 week product sprint... if you understand software development at the application layer.. if you want to try something new... Sales Engineering might be for you!

Software Engineer to Sales Engineer Journey

Who am I? I'll be the guinea pig for current software engineers interested in seeing how this transition is accomplished. I've dedicated 9 years to multiple SaaS startups (1 unicorn) building features still in production today and earning a title I've always wanted as Senior Ruby on Rails Developer. I'm working full time to transition to the world of tech sales and will document my journey as well as provide value like where to find the best job boards, how to structure your resume and what kind of questions will be asked in SE related interviews.

As of this date, I've landed a six-figure Sales Engineering role for a prominent E-Commerce SaaS company... and rejected it. I'll explain in future posts why you might've rejected it too.

Summary

Sales Engineering is a viable path for software engineers looking to work in more client facing roles. It'll allow you to flex the muscle of selling the value of a product to customers and leverage your existing experience as a software engineer.

I'll add to this by saying I plan to add as much value to your life as I can. I'm currently a Sales Engineering student at PreSales Academy and want to share what I can to help make this transition for you smooth and enjoyable.

Integrating Astro, Netlify and Mantine

Andy Huynh — Wed, 21 Dec 2022 22:22:23 +0000

Warning, don't bother using this stack as of Dec 21, 2022.

In the spirit of cultivating more empathy in my life, I'm recreating my sister's virtual kitchen website using Astro for blazingly fast response times, Mantine UI for out-of-the-box components and Netlify for ease of distribution.

The steps from nothing to all components viewable in production should've been simple:

Create a new Astro project using Netlify's template wizard
Pull that repo down from Github and npm install
Follow instructions to install React on Astro's website and Mantine from their documentation

What started as a terrible first experience using Astro with a component library like Mantine, turned into a wild goose chase if they're compatible.

After stumbling upon this Stackoverflow issue and this Github Issue, it's concluded that Astro does not support CSS-in-Javascript for their component styling. BOO!

LoadError: cannot load such file -- aws-sdk-core/plugins/http_checksum.rb

Andy Huynh — Fri, 12 Jun 2020 18:01:02 +0000

AWS Comprehend is in its early stages. The dev world is slowly seeing its potential. It's a struggle getting it set up with your Rails environment. The following resolved my problems. I hope it solves yours, too!

# app/models/clients/aws_comprehend.rb
class Clients::AwsComprehend
  def self.call
    Aws::Comprehend::Client.new(
      region: ENV.fetch("AWS_REGION"),
      access_key_id: ENV.fetch("AWS_ACCESS_KEY"),
      secret_access_key: ENV.fetch("AWS_SECRET_ACCESS_KEY")
    )
  end
end

> Clients::AwsComprehend.()
=> NameError (uninitialized constant Aws::Comprehend::Client)
cannot load such file -- aws-sdk-core/plugins/http_checksum.rb
LoadError: cannot load such file -- aws-sdk-core/plugins/http_checksum.rb

Solution

After digging online, this Github issue comment did the trick: https://github.com/aws/aws-sdk-ruby/issues/1872#issuecomment-461634704

> bundle update aws-sdk-s3

> Clients::AwsComprehend.()
=> KeyError (key not found: "AWS_ACCESS_KEY")

Obviously this is returns a different problem. However, updating aws-sdk-core to the latest will get you past the load error.

Vim tip - remap CAPS LOCK to control

Andy Huynh — Thu, 04 Jun 2020 16:57:05 +0000

Before

After

If carpel tunnel is a real fear, remapping control key will assuage your troubles.

Many Vim packages rely on control to unlock their Vim toolset. Tmux uses it (in conjunction with the literal letter 'b') to move to different panes (tmux). This is the primary reason for this post.

Ergonomically control is in a shitty spot on standard keyboard layouts. Reaching for control, over time, garners pain in your hands quicker than you think. I've used Vim for the past five years with no finger pain. I include instructions to remap CAPS LOCK below:

1. Open system preferences

2. Find and click the keyboard icon

3. Click modifier keys

4. Set caps lock to control

5. (Optional) Set CTRL-b to CTRL-a in .tmux.conf

# Ctrl-b sucks. lets bind ctrl-a instead
unbind C-b
set -g prefix C-a

The literal letter 'a' is closer to CAPS LOCK than 'b'.

testing Apple Pay on the web with Stripe (Rails)

Andy Huynh — Fri, 29 May 2020 23:15:52 +0000

Following this guide to render an Apply Pay button with Stripe.

Stripe provided a fantastic tutorial to integrate Apple Pay with Stripe. It took me half a day to render a button on the page. Here are the fine details of the guide I overlooked to eventually succeed in rendering Apple Pay.

1) Ensure a credit card exists in your Chrome browser wallet. I had Google Pay in my wallet. It was oddly frustrating, and understandable, Apple Pay didn't recognize Google Pay. Anyways, use a CC

2) Enable HTTPS with ngrok. I'm on ngrok version 2.2.4. Adjust your domain port accordingly

> ngrok http -host-header=rewrite localhost:3000

3) Render text from the controller, explicitly

# In `config/routes.rb` point the weirdly dotted namespaced controller endpoint to `ApplePayController` 
get ".well-known/apple-developer-merchantid-domain-association" => "apple_pay#show"

# `app/controllers/apple_pay_controller.rb` render text
class ApplePayController < ApplicationController
  def show
    respond_to do |format|
      format.html do
        render text: DomainAssociationFile.()
      end
    end
  end
end

I initially served html from the controller. I saw text rendered in the web browser.

When registering my domain with Apple, I got 500 errors.

Apple pinged my controller to retrieve the domain association file. It didn't know how to respond to the HTML I gave back. Stripe expected a text format in the return response. Format it like the above.

# I threw this in a presenter
class DomainAssociationFile
  def self.call
    <<-FILE
      # download and paste your domain association file, here
    FILE
  end
end

handy Ruby methods #4 - Hash#dig

Andy Huynh — Thu, 28 May 2020 16:05:30 +0000

Before Ruby 2.3

class AutomationController < ActionController::Base
  def automation_trigger_type
    params.fetch(:automation_rule, {}).fetch(:trigger_attributes, {}).fetch(:type).tap do |trigger_type|
      raise "unknown type" unless trigger_type.blank?
    end
  end
end

After Ruby 2.3

class AutomationController < ActionController::Base
  def automation_trigger_type
    params.dig(:automation_rule, :trigger_attributes, :type).tap do |trigger_type|
      raise "unknown type" unless trigger_type.blank?
    end
  end
end

Life after Ruby 2.3 breathes an elegant expression to drill into a hash.

In the first example, Hash#fetch is invoked multiple times. It drills two levels into a nested params hash :automation_rule. A default is included to avoid the dreaded NoMethodErrors on nil error.

This approach is verbose to say the least. It's painful to look at in the eyes of a Ruby dev.

The latter example is more terse. First, Hash#dig checks if the param key :automation_rule exists. If there's a key, it digs down a nested level and looks for the key :trigger_attributes. And so on..

Anywhere Hash#dig does not find a key, it returns nil in lieu of an error.

I notice Hash#dig used in Rails controllers. Digging into controller params is commonplace as an app builds in complexity. It's also prevalent digging through an API response where the returned payload is a deeply nested JSON object.

Hash#dig is a staple to write battle-tested code.

my personal checklist deploying to Heroku

Andy Huynh — Tue, 26 May 2020 01:20:31 +0000

This post serves as my single source of truth deploying local changes to a Heroku app.

Local(production) to Github(production)

Pull the latest changes from master git pull origin master
Switch to production branch. Update that shit git checkout production
Look over diffs for both master/production branches. It's more or less a sanity check git diff production..master. Take notes of features you're merging
Looks good? Merge changes from master to production on your production branch git merge master
Push the latest version production to Github git push origin production

Github(production) to Heroku Staging

Check Heroku for green status: heroku status
Push to production:master branch on staging, update the schema (if needed) and reboot the app git push staging production:master && heroku run rake db:migrate -r staging && heroku restart -r staging
Wait for the dyno slug to change watch -n 5 bin/deploy_slug_information (details below on this script)
Login to staging. Poke around features you just merged
Check JS console for any interesting front end errors
Check Honeybadger for server errors

Github(production) to Heroku Production

Push to production:master branch on staging, update the schema (if needed) and reboot the app git push production production:master && heroku run rake db:migrate -r production && heroku restart -r production
Ensure latest SHA release is the same as production branch heroku releases -r production | grep <production_SHA>
Check HoneyBadger for errors from release

How to run watch -n 5 bin/deploy_slug_information:

Setup an executable in your bin directory to watch `./bin/deploy_slug_information`

#!/bin/bash

URL="https://my-app-name.com"

if [ "$1" == "staging" ]; then
  URL="https://my-app-name-staging.com"
fi

URL+="/deploy_slug_information.json"

echo $URL
curl -s $URL
echo

Add middleware to your Rails app `app/middleware/deploy_slug_information.rb`

class DeploySlugInformationMiddleware
  HEADER        = "X-Slug-Commit".freeze
  JSON_ENDPOINT = "/deploy_slug_information.json".freeze

  def initialize(app)
    @app         = app
    @partial_sha = (ENV["HEROKU_SLUG_COMMIT"].to_s[0, 4].presence || "unknown").freeze
  end

  def call(env)
    if env["PATH_INFO"] == JSON_ENDPOINT
      json_endpoint_reply(env)
    else
      header_injection_reply(env)
    end
  end

  private

  def header_injection_reply(env)
    status, headers, response = @app.call(env)
    headers[HEADER] = @partial_sha
    [status, headers, response]
  end

  def json_endpoint_reply(env)
    body = { slug_commit: @partial_sha }.to_json

    headers = {
      "Content-Length" => body.length.to_s,
      "Content-Type"   => "application/json",
    }

    [200, headers, [body]]
  end
end

Tips

Unix trick - use fc to edit and execute your most recently used shell command.

mutating objects in Ruby

Andy Huynh — Thu, 21 May 2020 19:55:12 +0000

Mutation bugs are some of the most common in Rubyland.

Why?

Variables are objects and they most likely contain data. This means one or more variables may read data from that variable. If we change the makeup of the object, it could spell disaster for other objects expecting it not to change.

This is prevalent when passing objects via method calls. If a method param gets mutated and passed to another method, the receiving method might not respond properly to the mutated data. The results are less malleable and unreliable code.

One reason to mutate an object is if you're crafting data.

class ApplicationHelper
  def admin_body_classes
    classes = []

    classes << "admin" if admin?
    classes << params[:controller]
    classes << "environment" if Rails.env.test?

    classes.concat(@extra_body_classes) if @extra_body_classes
    classes.join(" ").tr("/_", "-")
  end
end

In the above example, mutation makes sense. We're returning a data object at the end of admin_body_classes.

It would not make sense to use a non-mutating operand to classes. Array#concat or a shovel operand are suitable for this case since classes is being mutated throughout the method.

Being mindful of object mutation saves headaches when dealing with objects.

create a shortcut to toggle paste mode with Vim

Andy Huynh — Tue, 19 May 2020 14:50:38 +0000

Vim has a paste mode you can toggle on or off - :set paste and :set nopaste. What if you can do this with less keystrokes?

Essentially, these commands prevent weird formatting when pasting text into your editor.

I will say - copy/pasting isn't a trivial action. Expect to perform copy/paste tenfold throughout your career. Typing out these commands gets cumbersome. If only we can shortcut this to improve your workflow.

Below is a leader command to which you can add to.vimrc (config file). Leader commands are merely a fancy shortcut native to Vim.

.vimrc

function! TogglePaste()
    if(&paste == 0)
        set paste
        echo "Paste Mode Enabled"
    else
        set nopaste
        echo "Paste Mode Disabled"
    endif
endfunction

map <leader>p :call TogglePaste()<cr>

No Vimscript knowledge necessary. Just "copy/paste" this snippet to your .vimrc.

Ensure your terminal shell of choice knows about your updates. I either restart my terminal session or source my .vimrc.

Toggle on paste mode: hit the key combination \ + p. If this doesn't work... ensure you're in Vim normal mode (not insert or visual).

Toggle off paste mode: \ + P.

handy Ruby methods #3 - Hash#fetch

Andy Huynh — Sun, 17 May 2020 15:53:06 +0000

class StripePaymentIntegration
  def self.enabled?
    ENV["ENABLE_STRIPE_PAYMENT_INTEGRATION"]
  end
end

This code isn't bulletproof. If it's not obvious - let me help you.

This is disabled by default. When we push to production, the app reboots. There exists a small window where ENABLE_STRIPE_PAYMENT_INTEGRATION isn't set. The code technically isn't doing what you're expecting.

Why does the app reboot? Because Heroku dynos automatically restart with every new code release. Here's a short description of Heroku dynos.

If only we can set a default value to avoid to ensure this is enabled when we push. It'd be even better if it was in pure Ruby.

class StripePaymentIntegration
  def self.enabled?
    ENV.fetch("ENABLE_STRIPE_PAYMENT_INTEGRATION", "true")
  end
end

Voila! Understand that ENV serves as a hash-like structure. Thus, it can "fetch" a hash's value given a key. Hash#fetch takes a lookup key in the first parameter and an optional second as a fallback value.

You can deploy and now be sure this works correctly!

I believe you get the most out of a software language by writing it as it's meant to be written. One of the pillars writing good Ruby code is being expressive.

ENV.fetch("ENABLE_STRIPE_PAYMENT_INTEGRATION", "true") comment below if that doesn't express what I'm puttin' down.

the difference between RSpec eq and be

Andy Huynh — Fri, 15 May 2020 16:03:45 +0000

RSpec has two equality matchers: eq and be. Depending on the circumstances, eq works most of the time. The difference between the two is subtle. The result of understanding the difference will yield clearer and more reliable specs.

Take this contrived example which expects a user name to be "Jon".



RSpec.describe User, "#name", type: :model do
  let(:user) { Fabricate(:user, name: "Jon") }

  scenario "User's name is Jon" do
    expect(user.name).to be("Jon")
  end
end

Running this test we get a failure.



Failures:

  1) User's name is Jon
     Failure/Error: expect(user.name).to be "Jon"

       expected #<String:70298288643660> => "Jon"
            got #<String:70298288643700> => "Jon"
...
...

It's failing and rightfully so! RSpec's be matcher expects both entities to be the same object. In other words, user.name and the string "Jon" are expected to have the same object_id.

irb



irb(main):001:0> jon = "Jon"
=> "Jon" 
irb(main):002:0> "Jon"
=> "Jon" 
irb(main):003:0> jon == "Jon"
=> true
irb(main):004:0> jon.equal?("Jon")
=> false
irb(main):005:0> jon.object_id
=> 70185646150880
irb(main):005:0> "Jon".object_id
=> 70185646097920

Notice the object ids are different. Under the hood, RSpec is calling Object#equal? which is a check at the object level.

RSpec's eq, is what you expect the string value to be matched against. Going back to our earlier example:



RSpec.describe User, "#name", type: :model do
  let(:user) { Fabricate(:user, name: "Jon") }

  scenario "User's name is Jon" do
    expect(user.name).to eq("Jon")
  end
end

After you run your spec, you're passing!



Finished in 1.12 seconds (files took 13.85 seconds to load)
1 example, 0 failures

Randomized with seed 4227
...
...

The user's name value is "jon". That's the same as the value of the string "Jon". Peaking under the hood again.. RSpec eq invokes === on the two objects which checks the return value.

TLDR

eq checks if the object values are the same

be checks if the objects are the same

wtf is a feature flag?

Andy Huynh — Thu, 14 May 2020 18:31:24 +0000

rollout.io
optimizely.com
launchdarkly

The above services are bulldozers for many applications. Large companies rely on their added features like shiny dashboards and sugar methods.

Andy's dictionary:

Feature flag: allows your system to conditionally show a feature to a customer.

Feature flags are an abstraction on top of your basic programming conditionals. They house the logic of your underlying features a customer should or should not be able to access.

Imagine a scenario where you're wrapping up a feature for your SaSS. It's ready to go, however - you'd be more confident if a few customers can test it out.

More or less... beta testing.

The above services can prove to be hefty for smaller projects. You might not have many users yet. Your codebase might not be the size of an enterprise. Did I mention those services are mostly bulldozers? Where the shovel at?

I got your shovel. Integrating feature flags to Ruby projects can be accomplished using Rollout. It's minimal in it's approach and reads well. It doesn't hurt that the project has few outstanding Github issues in it's queue.

Rollout also scales well. Kajabi has a generous user base. We're releasing features non stop! We've built features on top of Rollout for our needs and it's still in use, today.

Back to our contrived example, let's say you're adding an affiliate program. You have a founders group and want to ensure they get their hands on it, first!

After installing the gem, define/activate your group and use conditionally write your markup like so:

# config/initializers.rb
$rollout.define_group(:founders) do |user|
  user.plan_name == "founder"
end

$rollout.activate_group(:affiliate_program, :founders)

<!-- index.html.erb -->
<html>
  <body>
    <% if $rollout.active?(:affiliate_program) %>
      <%= render "affiliate_program" %>
    <% else %>
      <%= render "something_else" %>
    <% end %>
  </body>
</html>