Forem: Corey Schaf

Don't think of it as "Quitting"

Corey Schaf — Thu, 22 Apr 2021 15:52:13 +0000

Lets talk about leaving one job for another,

and why this is scary, stressful at times but important to our growth.

The first thing is the idea of “Quitting your job”. This in itself has a negative connotation. That you “Quit” on your team, “Quit” on your company and let people down you worked with. Let's take a step back and reframe how we think about quitting. First let's not call it quitting, let us call it leaving, resigning your current position or just moving on to new opportunities. Let's remove that negative sentiment.

Second, let's not think of it as failing your teammates and abandoning the company. Think of it as the company failed to set you up for success. The company failed you and you have recognized that it is time to take action and invest in yourself, your happiness and your growth as a person and engineer. There are many reasons why we move on to different places in our careers and it is often a difficult decision to make especially when you are close with your team, and these moments can be bittersweet, but in the end you need to trust yourself and your intuition on what is best for you in this point in time. You do not want to look back in years time and ask yourself “what if….I took that offer… what if I had the courage to take that interview and overcome imposter syndrome…what if I trusted myself in those moments”.

I have said this before, but we are a sum of our experiences in life, both personally and professionally. If those experiences and short and shallow then we are doing ourselves an injustice in our development. This is the point in my writing where I usually ramble and let the brain to the typing, and I really want to quote a line from Transformers 1 but the other movies were so terrible I doubt anyone would remember, but fifty years from now and you are looking back at your life don’t you wanna say you had the guts to get in the car.

Cheers.

Quick Bit: Github Action to Test a Rails App

Corey Schaf — Mon, 19 Apr 2021 20:08:56 +0000

Hello there!

In this quick little post I am going to quickly show how I built a Github Action that will run my Rails application's test suite. Now there are many posts on this topic, but I legit could not get anything I found on google to work. So after "days" of banging my head against the wall I was able to piece together a working Github Action. So if there is anyone in a similar place I hope this helps. As always, you can find me on twitter, cheers.

For my Ruby on Rails application I am using the following:

Rails v6.1.3.1
Postgres v12
Standard minitest rails integration.

Goal

On my many pushes I would like to have a Github Action run that verifies my code and tests. This should also test any branch that is set to be PR'd into the main branch. Also for note, this is a personal project so I commit a lot and my commit msg's are quite sparse.

In the Rails Application.

In config/database.yml update the settings to use the env vars that we will establish later.

test:
  <<: *default
  database: <%= ENV.fetch('PG_DATABASE', 'myapp_test') %>
  host:     <%= ENV.fetch('PG_HOST',  'localhost') %>
  username: <%= ENV.fetch('PG_USER', nil) %>
  password: <%= ENV.fetch('PG_PASSWORD', nil) %>
  port:     <%= ENV.fetch('PG_PORT', 5432) %>

And the Github Action

name: Rails
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

env:
  registry: myapp_registry
  DB_HOST: localhost
  DB_USERNAME: myapp
  DB_PASSWORD: password


jobs:
  tests:
    name: Tests
    runs-on: ubuntu-latest

    services:
      postgres:
        image: postgres:12
        ports: ["5432:5432"]
        env:
          POSTGRES_PASSWORD: password
          POSTGRES_DB: myapp_test
          POSTGRES_USER: myapp
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Setup Ruby
        uses: ruby/setup-ruby@v1
        #with:
        #  ruby-version: 2.7.2 not needed with .ruby-version file

      - name: Setup Node
        uses: actions/setup-node@v1
        with:
          node-version: 10.18.0

      - name: Find yarn cache location
        id: yarn-cache
        run: echo "::set-output name=dir::$(yarn cache dir)"

      - name: JS package cache
        uses: actions/cache@v1
        with:
          path: ${{ steps.yarn-cache.outputs.dir }}
          key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            ${{ runner.os }}-yarn-

      - name: Install packages
        run: |
          yarn install --pure-lockfile
      - name: Install PostgresSQL 12 Client
        run: |
          sudo apt-get -yqq install libpq-dev
      - name: Cache Ruby Gems
        uses: actions/cache@v2
        with:
          path: vendor/bundle
          key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}
          restore-keys: |
            ${{ runner.os }}-gems-
      - name: Bundle Install
        run: |
          bundle config path vendor/bundle
          bundle install --jobs 4 --retry 3
      - name: Setup test database and run tests
        env:
          RAILS_ENV: test
          PG_HOST: localhost
          PG_DATABASE: myapp_test
          PG_USER: myapp
          PG_PASSWORD: password
          WITH_COVERAGE: true
          DISABLE_SPRING: 1
        run: |
          bin/rails db:setup
          bin/rails test

      - name: Upload Code Coverage
        uses: actions/upload-artifact@v2
        with:
          name: code-coverage
          path: coverage/

Where is this file?

With Github Actions, you can set them up directly in the Github repo.

This will create a file in your code base under .github/workflows/{filename}.yml.

With this in place you should now see the build steps execute 1 by 1 and complete successfully, if your project is indeed passing all tests.

Cover credit: https://unsplash.com/photos/sJjvg1ybXRk

A Few Things I Learned. 10 Years as a Software Engineer.

Corey Schaf — Thu, 01 Apr 2021 18:27:10 +0000

Hello there, I am Corey. This is my first post in (checks notes) a year and a half.

I am a software engineer focusing on backend technologies and distributed systems. I have worked in a variety of fields since graduating in 2010. I entered the industry working for an e-commerce marketing firm building custom e-commerce solutions in C# and .NET. After a few years of that (which was a learning experience while also being a negative depressing environment that ruined me until I left) I took another job at a local company that builds data and engagement platforms for Higher education. This was a beautiful time that allowed me to shed the negativity of my previous position and get to work with amazing people.

In the same time span I started a few small companies to various degrees of failure, published games on the iOS app store and built a few SaaS applications in my spare time. Finally I find myself where I am today, a growing Series B startup that I joined at the seed stage.

What follows this is just a few of the things I learned along my way. I am in no way perfect, and at times quite confused on what my future in this world holds, but these are things rattling around in my head. Here goes.

Run Down:

You will never get anything unless you ask for it
EQ > IQ
Workplace empathy
Interview skills
Curiosity.
Handling burnout and career confusion
Years Experience != Experience.

1. You will never get anything unless you ask for it.

Do not assume you will get that raise, that promotion, that team transfer or anything just by waiting your turn. You need to be explicit in your intentions. Many times we hesitate to ask for things to avoid sounding needy or that we are scared of hearing “no”. Being told “no” is the worst case scenario, and that is such a simple inconsequential thing that it really doesn't matter. What it shows is that the company sees you in a different light than you see yourself. This knowledge is powerful. At the end of the day you get what you want (granted you have to earn it) or you have the knowledge that you wont be getting it and you can use that to drive your future career moves.

2. EQ > IQ

If you have ever worked in a negative place at a hostile company, you will understand how IQ is not a means to an end. I would rather work with amazing people that are not the greatest engineers than I would want to work with geniuses who are ego driven ass hats. Great people have the ability to make the people around them better, they amplify positivity. EQ will take you farther than IQ ever will. Now with all things moderation is key, this doesn't mean people with high IQ are always negative or high EQ means they are sub-par engineers. You will know those alpha ego’s when you come across them.

3. Workplace Empathy.

We are all going through some shit these days. Some more so than others. Being able to understand others helps us develop closer relationships with those people. This can then in turn help build bonds between teammates and foster a culture of positivity and inclusiveness.

A great quick video: Empathy vs Sympathy

4. Interview Skills

Working in the real world makes you rusty. Im sure we all had interviews that we look back on and just are astonished at how ill prepared we were. Interview skills differ from those used in day-to-day work, and you never know when you will need those skills to be sharp and pristine. Verbal communication, technical communication, technical comprehension, system design. All critical skills we must posses when we try to impress prospective employers but skills that deteriorate over time in the real world (maybe not for all, if you are lucky).

Interview every ~10-12 months wether you need a job or not. The worst that can happen is you say no. The goal is to keep our interview skills honed and sharp. This part is important for the verbal and behavioral communications. Being able to engage with new people and to have conversations about yourself, your background and your goals is critical.

Don't Fear the technical interview. Yes these don't represent day to day work. Yes they suck. Yes it makes you have dreams of traversing binary trees and running sliding windows on arrays. For many years I would shy away from anything that involved live coding, hackerrank or leetcode. How many opportunities have I missed because I doubted myself and refused to prepare? These technical interviews are for showcasing skill but more so its about showing you took the time to prepare. Plus its always good to understand arrays, lists, strings, trees, tries, searches, big-o and how to piece together scalable systems. Prepare little by little, day by day, week by week. These are things that can take months to fully prepare to a point that we are confident in whatever is thrown at us. Also, don't overfit your memory on specific LC questions. Learn the theory, patterns and ideas behind the data structures and algorithms and how they can be applied to any problem. I recommend "Grokking the Coding Interview" for learning about the ideas and patterns behind the different types of questions and "Cracking the Coding Interview" as a good reference and refresher on those rusty skills.

5. Curiosity

As engineers we must always be curious about many things. Exploring new languages, frameworks, ideas or exploring parallel fields. It's important to not be complacent with what you know and that it's a critical skill to continue to compound your knowledge and skill day by day. There is an overwhelming amount of technology out there these days and it can become cumbersome to try and wrap your head around any of it. They goal here is not to become a 10x'er super engineer, but to just be curious and find things that interest you and keep you excited. Its easy to loose the passion in engineering, especially working in the real world. Never stop exploring, learning and pushing yourself forward.

6. Handling burnout and career confusion

When I first jotted down a list of items I wanted to talk about, this was one of the first ones I noted. Truthfully though, I don't have an answer for this one. It's something I fight through everyday hoping to better understand everything. Point 5 above does help, finding the excitement again in the engineering field keeps the hope alive. If anyone has any ideas or helpful methods, that would be fantastic.

Career confusion is something I define as: Do I want to keep doing what I am doing? Why am I not happy? Do I have any applicable skills outside of programming? Did I waste the past decade? What can I do that I would be happy doing? Every day is just going through the motions, not solving problems that push your creative brain forward, not being taken seriously and just a complete disjoint confusion around your place in this world, professionally speaking.

7. Years Experience != Experience.

We exist as the sum of our experiences. The more we experience and push ourselves outside of our comfort zone the more we grow both personally and professionally. It is easy to fall into the trap of accepting mediocrity and being complacent. I have had done this in the past. Staying at a job too long, not learning new skills, not earning much salary, just being complacent. Think to yourself if I had to define success what does it look like to me? Can you achieve that where you are? Are you getting better day by day? Or are you stuck? Fear not, we all experience this. The key is to invest in yourself, don't give up even when things seem hopeless and acknowledge failures. For failures are the building blocks of success.

p.s. I was going to use more picture, but I didnt. Are pictures good? Distracting? Pallet cleansing?

The Pit Called Burnout

Corey Schaf — Thu, 21 Nov 2019 18:43:50 +0000

Prologue

The concept of burnout has always been an interesting one to me. How do you know when it hits vs just having a bad day/week? Personally I think its about retrospective. Looking back and reflecting on the months and years you can identify the trends. You can view the timeline of your career and life and what got you to this point now. By reflecting on past choices and mistakes it can offer a small step forward. I find some semblance of understanding by turning thoughts into words on this blog.

Story

For me, burnout is more than just physical and emotional exhaustion. It is more the depression around spending half your life writing code, first for fun then for living, only to realize is this really what I want to be? The idea of wasting my 20's and early 30's at simple engineering jobs and starting failed company after failed company is what is the most draining(are they really wasted? thats a reflection point for the future). Day in and day out not learning anything. Not spending your daily allowance of creativity and problem solving brain power. The acceptance of mediocrity cuts deep. I also think the fear of change is what keeps me locked in place at times, and its not lost on me.

Finale

I realized my own struggle with burnout a few years ago. Its still a struggle to find any passion in being an engineer. Maybe its the simplicity of the problems being solved, or lack of career evolution; I am still finding that out. But I have found something that helps. I now say yes to almost everything, because I never know what I will like or what just clicks. From writing this blog, to building games, writing tutorials, streaming on twitch, writing fiction, public speaking or building stuff. I found being open to everything forces you out of your comfort zone. Comfort kills creativity.

Podcasts for Engineers and Programmers of All Levels

Corey Schaf — Tue, 05 Nov 2019 14:55:26 +0000

Lately I have been on a big podcast kick and I found a ton of great engineering related ones. I saw some recent articles like this so I decided to make my own list. These are in no particular order of importance.

1 . Software Engineering Daily

This is one of my favorite podcasts out there. There are so many episodes available that range from Flutter, to scaling engineering at Facebook, Slack Messaging Architecture and so on. These are real world examples of technologies in use at various companies. Its an excellent resource to learn about new tech and how companies handle innovation.

It can be found here: https://softwareengineeringdaily.com/

2. The RayWenderlich.com Podcast

This is also one of my go to's. I have learned so much from this site in turns of iOS and Swift development. The podcast has a broad range of topics from iOS, Android and Unity and beyond. They are quick listens that are great for a morning commute.

It can be found here: https://www.raywenderlich.com/

3. Go Time

An excellent Go focused podcast. "A diverse panel and special guests discuss cloud infrastructure, distributed systems, microservices, Kubernetes, Docker…oh and also Go!"

4. The Python Podcast. init

Their words say it best: "The podcast about Python and the people who make it great". A python focused podcast that talks all things from Machine Learning to Web API's to, well anything. And thats Python for ya. Check it out https://www.pythonpodcast.com/

5. Engineering Culture by InfoQ

Engineering goes beyond just building things. Its about the how as much as the who. This is a great listen to learn and familairize yourself with the otherside of the software world. Excellent for learning about engineering management. If you are like me and are transitioning from a full time coder to coder/leader then this is a great listen.

Get it: https://www.infoq.com/engineering-culture-podcast/

6. The Bike Shed

One of my newly favorite podcasts. They range from Ruby to React to SQL and just life in the software world as a whole. I have this at 6, but numbers are made up and ranks dont matter.

Here: https://bikeshed.fm/

ALAS, if you have any other suggestions post them! Im always looking for new listens and learning never stops.

Compounding as an Unstoppable Tool

Corey Schaf — Thu, 17 Oct 2019 15:13:41 +0000

Compounding. I am often asked what traits/actions/paths are important for personal and professional growth. The idea of compounding, I believe, is one of the more important ideas. Continually building on top of previous goals and actions. Just as dividends and investments compound and grow over time, we can continually grow results in many aspects of our lives. From learning to health to happiness, with many small incremental steps we can incubate growth in our daily lives.

The idea of compounding is simple. Every day build on the previous day's results. This can be stringing together workouts, working on side projects or just maintaining a schedule. Eventually as we build up our routines they will become habit. I found it easiest to progress by breaking everything up into smaller pieces. As I achieve even the simplest of items this gives me visual affirmation that I am moving towards my goal. On a large Unity project I am working on, I like to break out all my weekly tasks into 4-5 items each with their own subtasks. Over the course of a week I can clearly see my progress, where I am lacking and what I can prioritize.

I also use this idea when I set my workouts and cardio for the week. I found it difficult at first to set my objectives and goals, but by building little by little each day/week you begin to see progress. Progress that is used as fuel to move you even further, you just have to light the embers. Everything matters as far as keeping the mindset. There are some days where I can only lift a few weights, or just walk on the treadmill because I am completely drained from the day. Its ok to go 10/20/30% on some activities, but its important to do it anyways. Train your mind that you can do it. As a full time software engineer there are many times I come home and just cant write any code or even sit in front of a computer, but instead of throwing the day away I usually sit down and physically write down and review my objectives for the week (then I fire up some Destiny for some stress releasing crucible action).

Those are my rambles. Any progress is still progress, regardless of how small you think it is. Every stone makes the foundation stronger.

How do you define success?

Corey Schaf — Wed, 16 Oct 2019 14:08:49 +0000

It is a simple question but at times hard to understand: How does one define success? We each have our own goals, ambitions and traits that drive us towards this goal. This idea of success for many is driven by comparisons instead of the result of our own personal pillars.

My idea of success is a simple question I ask myself everyday: Am I better today than I was yesterday.

Have I accomplished some small goals? Have I learned more at work to push myself farther? Have I helped someone in need? The idea of bettering yourself everyday is something I can hope will bring me happiness. If I can quote Steve Jobs for a second:

“For the past 33 years, I have looked in the mirror every morning and asked myself: “If today were the last day of my life, would I want to do what I am about to do today?” And whenever the answer has been “No” for too many days in a row, I know I need to change something.”

Do not become stagnate. Do not accept mediocrity. Do not settle for the mundane and lifeless. Is your job too easy? Are you unchallenged? Move on. Never stop building, never stop creating, never stop learning. Find what drives you to be a better person. Do not cheat your well being for short term dividends.

What's the point? The point is... don't lose your dinosaur.

Project Serenity: Dev Blog 0; Picking an Engine

Corey Schaf — Fri, 06 Sep 2019 18:39:32 +0000

Project Serenity is a game I have been working on for the better part of a year and a half. Although a majority of that time was spent learning different engines, 3d modeling, writing and planning. I will be using this dev blog to give insight into the different things I have learned along the way, as a way to help others and to keep myself on track!

When I initially started prototyping I was using Unity2018. There are a few concepts and technologies I was going to need in an engine as I went forward such as terrain tools, a nice lighting system and a not so steep learning curve to get some ideas mapped out. I picked Unity because I have been using it for simple prototypes since the Unity3 days. So it was a no brainer to jump in and start development.

The core of Serenity is exploring different landscapes. I wanted to build unique areas, from islands to red wood forests to desolate decaying valleys. One of the first issues I ran into was I kept needing to buy assets to help in this development. Such as Gaia to help build terrain and Amplify to build shaders. I eventually ran into an issue with an update to the tooling which ended up wiping all textures from my terrain. Even with source control, this led me to explore other options.

Some Screens from the early prototyping in Unity2018

I decided to take Unreal Engine for a spin. Being 100% new to UE4 I grabbed a few courses from the GameDev.tv guys on Udemy (they make amazing courses for UE, Unity, Godot, Blender, etc!). I really fell in love with UE. I had access to amazing terrain tools, lighting, volumetric fog. A ton of excellent features that came packaged in without the need to add third party support. After a few months I was able to prototype pretty fast using their Blueprint system. I would say one of the downsides is there does not seem to be as much community help/tutorials/support as compared to Unity's massive community (thou there was still a lot!).

Some UE4 shots:

So after a few months of exploring UE I had to make a decision on which engine to use moving forward. One major sticking point of UE was that all scripting is in C++. Which I found very slow to get used to, on top of learning all UE4's c++ macros. Being a long time .NET developer I am extremely comfortable in C# which is Unity's base scripting language. Combined with the impressive updates in Unity 2019 and the fact that I much prefer C# over C++ I decided to (once again) start prototyping back in Unity. Now dont get me wrong, I love Unreal Engine and everything it offers and I will be back to it at some point. But im looking for familiarity to help speed up the dev process and Unity offers that.

I am very happy with my move back to Unity. I have started trying to flush out a style and color scheme as well as work on the early parts of the story. Below are a few of the newer design. You can see how the art is moving from a realistic to a more stylized approach. I am using the LWRP currently, which is great but also being so new that its cumbersome at times to get some older shaders to work correctly. A majority of the models are done in Blender and I used Zbrush to help give them some different looks.

Getting Started with Ruby and RVM

Corey Schaf — Wed, 21 Aug 2019 10:48:26 +0000

As of this writing we will be using ruby 2.5.1. I am going to be walking you through how to set up our basic ruby environment using RVM and how we can easily switch between different ruby installations.

Installing RVM

RVM is a ruby environment manager. This is an optional step in starting ruby development, but highly recommended. This will allow us to have clean ruby environments for each of our projects, regardless of version/dependencies etc.

Running the following cURL command will update our system with the latest stable RVM build.

$> \curl -sSL https://get.rvm.io | bash -s stable --ruby

RVM can show us all the available ruby versions that we can install on our system, from beta to stable to obsolete. Its an amazing way to handle switching different environments with ease. As of this post, the ruby install version is 2.5.1, so that is what we will be working with.

Now we want to run the rvm helper script, that will adjust our RVM installation and our path. This allows us to run rvm at the command line.

> source /Users/corey/.rvm/scripts/rvm

> ruby -v ruby 2.5.1.p57

This will tell us our current ruby version, which for this example is sitting at ruby 2.5.1p57

Now lets create a gemset, which is a unique environment that will house all our dependencies and gems.

> rvm gemset create rails-test-api ruby-2.5.1 - #gemset created /Users/coreyschaf/.rvm/gems/ruby-2.5.1@rails-test-api ruby-2.5.1 - #generating rails-test-api wrappers.......

Now lets switch to our newly created gemset

> rvm gemset use rails-test-api Using ruby-2.5.1 with gemset rails-test-api
> rvm gemset name rails-test-api

We are now using our newly created ruby environment. We will install some basic dependencies that we need going forward.

> gem install bundler fetching: bundler-1.16.5.gem (100%) Successfully installed bundler-1.16.5 Parsing documentation for bundler-1.16.5 Installing ri documentation for bundler-1.16.5

This installs bundler, which we will be using in our rails install in the next tutorial.

> gem install rails .... ...
> rails --version Rails 5.2.1

We have successfully installed our development environment and installed the newest Ruby on Rails framework.
Let's create a quick dummy Rails application just to test our install.

> rails new demo-test Installing ....
> rails s => Booting Puma .. ....

Now if we go to our browser, and navigate to localhost:3000 we should see: