DEV Community: Mason Egger

How I Write Conference Talk Proposals

Mason Egger — Sun, 30 Jan 2022 00:00:00 +0000

So you want to speak at a conference? Congrats! That is a fantastic goal! The decision to speak at conferences was one of the best decisions I have made in my career. I've learned so much, made countless friends, and had some of the best times of my life at various tech conferences. Whether it's your first time speaking or your thousandth, I hope you get something useful out of this post.

In this post, I'll cover how I approach writing CFPs. Having not only spoken at many events and participated on program committees for various conferences, I'll share with you the practices that I have either used or seen in successful talk proposals.

First Things First, Determine Your Audience

A common mistake I see people make when they first decide to speak is to jump straight into brainstorming a topic that they want to talk about. This isn't a bad way to approach this, but people often struggle to think of a topic for one big reason: they can't visualize their audience. Are you giving your talk to a room full of C-Suite individuals? Students? DevOps Engineers? Determining your audience and their skill level will guide you to topics that may be of interest to them.

For Example:
I enjoy talking to the Python community and DevOps/SRE communities. Which almost immediately disqualifies talks about JavaScript frameworks¹ from my list of possible topics. This may seem simple. You may be asking yourself, "Why even write this?" But you'd be surprised how many people I've helped with CFPs who I unstuck after asking "Well, who do you want to present to? Who is your audience?"

Once I have determined my target audience(s), I then think about topics.

How To Pick Topics

So now that I have my audiences in mind, I ask myself the following questions:

What is exciting in that community right now?
What topics are people talking about in that community right now?
What topics aren't being talked about right now that I think should be discussed?
What topics do I want to talk about?
What issue am I trying to solve/address?

If I have multiple audiences in mind, I will briefly explore the overlap between them. Depending on the sprawl of your audiences, this may be easy, or it may be virtually impossible. Don't feel bad if you can't find a technical topic covering both.

For Example: Python and DevOps have a good amount of overlap. I could explore topics such as using and/or extending Ansible, a Python-based DevOps tool. I could explore topics around simplifying the deployment of Python applications. The overlap here isn’t to hard to find. These talks are likely to be good candidates for both Python and DevOps conferences. But I don’t have to do this. Maybe I want to write a talk that’s solely about Python fundamentals. Great! I just would’t submit it to the DevOps conferences.

On the flip side, finding overlap can be nearly impossible. Say I’m interested in CSS and Kubernetes ². Trying to find a talk that is applicable and interesting to both communities isn’t impossible, but you may spend more time trying to find it than you want.

While it is important to focus on topics the community might find useful, it is just as important to focus on topics that you actually want to speak about. Excitement and engagement is contagious, and if you are excited about a topic then your audience will be too. There’s few things worse than listening to someone give a talk about something they aren’t interested in.

Once I have determined the topic that I want to talk about, then I start to think about what level I want to write my talks.

Talk Levels

I typically categorize talks based on the audience level,
difficulty level, and the tool level.

In most CFP systems, you'll see options for the following audience levels:

Beginner
Intermediate
Advanced
All

Audience level is the level of expertise you expect the average audience member to have. Audience level can be more of a "minimum requirements" level than a cap. You may want to institute basic prerequisites for your talk so people know what to expect before going in. For example, if I'm giving a talk on little-known SSH features, I would expect the audience to have a basic understanding of *Nix like systems and maybe even that they have used SSH in the past. Having a set idea of your desired audience will help you know where to start your talk. If my audience were beginners, I might start by introducing SSH. If I know they're more advanced, maybe I can skip past that part or cover it quickly. This doesn't mean that intermediate and advanced developers won't benefit from a beginner talk on an unfamiliar topic, of course. You'd be surprised how often more experienced developers attend beginner-focused talks to stay sharp.

Difficulty level is the knowledge level at which you target the talk on this specific topic. This is different from audience level because you have direct control over this. When writing my talks, I always keep difficulty level in mind to ensure that I don't sway too far off course. This can help me keep from going too in-depth on a beginner talk to keeping me from spending too much time on basic concepts in an advanced talk. Some topics are complex by their very nature. Don't worry, you can give different-level talks on the same core topic.

Example: The Python GIL³ ⁴

Beginner level talk - "What is the GIL and why you should care"
Intermediate level talk - "How I Got Around The GIL by doing X"
Advanced level talk - "A Deep Dive Into Garbage Collection and the GIL"
All level talk - "How Python Core Developers are approaching removing GIL"

As you can see, you can fit any topic to any level. Sometimes I have varying slides in my deck that I hide/unhide depending on the audience level.

Also, note how there is an All Level category. While some conferences will use these interchangeably, that doesn't mean that they are. Advanced developers sitting in a beginner talk about the basics of Python Strings may not benefit from that talk. However, a talk about how to build a community around your Open Source project is likely to be enjoyed by everyone of all levels.

"Aren't Audience Level and Difficulty Level extremely similar?"

Yes. They ask a lot of the same questions, they just have a different focus. You can often use one to help craft the other. Knowing the difficulty level you want to speak at somewhat mandates the audience level and vice-versa. Even in my process, I don't explicitly write down the difficulty level of my talks, just the audience level. I have, however, thought a lot about both. So while they are incredibly similar, they are distinct enough to think of them separately.

Finally, let's talk about tool level. This is very subjective as many people will disagree with what is considered a beginner tool or not. However, there are many tools that obviously fit into a category. No one on Earth has ever said that Kubernetes is a beginner-friendly tool.⁵ So, while your opinions on this may vary, it is good to understand your topic's perceived skill level. I find it easy to just have the following levels:

Beginner
Intermediate
Advanced

This primarily helps me understand how much work and care I need to take when writing the talk. Say I want to give a Kubernetes talk at the beginner level. Kubernetes isn't typically considered a beginner tool, so bringing it to a level that a beginner can understand may prove challenging. As you saw above in my audience level section, you can talk about anything at any level. Keeping tool level in mind also stops me from writing Advanced Advanced proposals.

Your Topic Doesn't Have to Be Complex

A mistake I made very early in my speaking career was trying to write obscenely complex talks on edge case topics. The first proposal I ever wrote for a Python conference was about building python packages as RPMs so you could utilize the CentOS package manager to handle both system and Python packages. This talk never got selected, and rightfully so⁶. The proposal was overly complex and an extreme fringe niche. That isn't to say that complex or unique ideas won't get accepted, but they should represent an interesting problem or a use case that a subset of the community will experience. My talk was neither.

From an organizer's point of view, complex talks can be difficult to schedule. We have to think of our attendees as a whole. Very few conferences consist of solely advanced engineers. A lot of beginners attend conferences as well. Therefore, we have to strike an even balance of talks. This tends to have us scheduling mostly beginner/intro talks⁷, followed by intermediate talks, and then a handful of advanced talks. So, complex and advanced talks will have fewer slots allocated to them, reducing the chance of your niche talk being selected.

Your Topic Doesn't Have to Be Technical

Another common misconception I see is that talks have to be technical. This couldn't be further from the truth⁸. Talks on community, soft skills, non-technical skills such as leadership, program management, etc., are all great options.

Now that I've thought about who I’m speaking to, what I want to speak about, and the tool level I want to hit I turn to my personal process for writing my CFP.

How I Write CFPs

Over the years of applying to many different conferences that all seem to use a different CFP program and process, I've developed a template to write every single one of my talks. This template can be rather non-linear. I don't just fill it out top to bottom. I bounce around using previous sections to help write the next. You can see my template below or find it on my GitHub here. Below this, I'll explain how I use every section of my template.

My CFP Template

## Type
Talk, Workshop, Lightning Talk

## Title
Some Fun, Clever Title

## Category
Single Overarching Theme
Ex: DevOps, Python, Community

## Elevator Pitch (300 Character Limit)
300 characters or less elevator pitch. 
Include Audience Takeaways

## Audience
* Who is this for?
* Can be many different audiences

## Audience Level
Expertise required for this talk
Include prerequisites

## Audience Takeaways
What will the audience take away 
and/or learn from this talk? 

Should be 3 things

## Outline
* Timed outline (1 min)
* For the Presentation (5 min)
* More detail is good here (20 min)

## Description
Slightly longer description. 
Expands upon elevator pitch. 
Be sure to include Audience Takeaways

## Internal Notes (For Your Eyes Only)
All the nitty-gritty of the talk. 
Your scratch paper

## Additional Notes
Anything else. 
Presentation materials needed
Why you're qualified to speak on this
Etc.

Type

Talk, Workshop, Lightning Talk

What type of presentation is this? What format will work for this presentation? When you have a lot of papers, it's good to have this right at the top so you don't waste time trying to figure out what you meant when you wrote this six months ago. There can be more than one type. It's rare, but I do have a few talks that could both be Talks and Lightning Talks, depending on what I omit.

Options include:

Talk (Usually 15 - 45 minutes)
Workshop (Usually 60 - 180 minutes)
Lightning Talk (Usually 5 - 10 minutes)

Title

Some Fun, Clever Title

To me, the title of a talk is everything. It needs to be catchy while also setting expectations for the talk. I am a big fan of the "Catchy first title: explanation subtitle" format. You'll see most of my talks have this title format.

For example:

Docs Like Code: Continuous integration for documentation
SSH Can Do That?: All the things you didn't know about SSH
A Year Without Pants: Successful Strategies for Remote Work

However, I don't constrain myself to this format. It is my favorite, but sometimes it just doesn't work. But titles should be entertaining and engaging. Attendees have to choose from a wide array of talks that they are given very little information on. Having a good title will attract them to your talk. And remember, the conference organizers and talk selection committee are also your audience. Another one of my talk titles is "The Enters and Exits of Context Managers." From the outside looking in, this talk is a bit confusing. It does explain that you're going to be learning about Context Managers, but with a little joke. The joke here is that __enter__ and __exit__ are ways to create a Context Manager in Python. This is a play on the phrase "The ins and outs" by changing it up with synonyms that fit perfectly.⁹

Another tip I have for titles is to make them Iambic¹⁰. If you don't know what this is, I highly recommend you look it up. The tl;dr is that, in English, it is pleasing to hear words that follow a short syllable followed by a long syllable. It's rhythmic and oh so complex.

If you are writing a paper in a language other than English, I would recommend looking into what speech patterns are pleasing in that language.

Elevator Pitch (300 Character Limit)

300 characters or less elevator pitch. 
Include Audience Takeaways

Papercall is a popular platform that conferences use to gather papers. The first part of their format includes the "Elevator Pitch" and they have a limit of 300 characters or less. I used to dislike this format, but now I think it's become my strongest asset. This is a great way to write an abstract. There's the old quote, "If I had more time, I would have written a shorter letter." Concisely portraying your thoughts on a specific topic is not a trivial effort. When I write an elevator pitch, I tend to have a two-way process. I'll either write a longer description and prune it down to fit the elevator pitch, or write the elevator pitch and then expand upon it to fill the Description. I've found that the former tends to work better for me, as it allows me to get my thoughts out first. Whenever I write the elevator pitch first, I'll often find myself coming back to modify it as the Description forms.

Also, in this section, I always include my Audience Takeaways. This makes it even more difficult because the takeaway can easily take 100 - 150 characters. So I have to be even more concise. I believe, that it is paramount that you include the Audience Takeaways. A good abstract should explain what you will talk about and what people will gain by coming to your talk. Conference attendees usually see this in the program, and they know immediately by reading it if the talk
is right for them.

Audience

* Who is this for?
* Can be many different audiences

As I said earlier in this post, you must know who your audience is. In this short section, just write it out. Is it for Python Developers? DevOps Engineers? Marketers? Make a bulleted list and write it out. Your audience can be many different types of people. You don't need to limit it to one, but don't feel bad if it is just one.

Audence Level

Expertise required for this talk
Include prerequisites

As mentioned above, having a set level for the difficulty of the talk will help you scope the content. I covered how to think about audience level in-depth above in the section. You should also explicitly write down any prerequisite knowledge you expect the audience to have coming into your talk. Sometimes there is a place to share this in the CFP submission, but if there isn't, it is still useful for scoping the talk.

Audiece Takeaways

What will the audience take away 
and/or learn from this talk? 

Should be 3 things

Audience Takeaways are one of the most vital parts of a CFP, and you'll rarely see a CFP ask for this¹¹. It isn't enough to tell people what your talk about, but what they are getting out of your talk. Single-track conferences are rare. There are usually at least two or more talks happening simultaneously. Let the viewer know what to expect from your talk so they can choose the correct talk for them.

In this section, I write three bullet points of takeaways I want attendees to get out of my talk. And three is a hard stop for me. If you've never heard of The Rule of Three you should read up on it. The tl;dr is that trios of things are more satisfying and effective than other numbers. There's some deep psychology around it that I can't explain, but it works.

When it comes to writing them into my Elevator Pitch or Description, they can take many forms. The main thing to focus on here is the Rule of Three. Looking back at my successful talk proposals, 95% of them have utilized it in the Elevator Pitch in some way.

From a conference organizer's viewpoint, I love seeing takeaways. It tells me that the talk is well thought out. Also, it helps me see if I think the talk will resonate with the audience of my conference.

Outline

* Timed outline (1 min)
* For the Presentation (5 min)
* More detail is good here (20 min)

Outlines are an extremely helpful tool. I tend to outline my talk with the titles of my slides. I may have one or two slides that aren't represented here, but most of them are. I also put time estimations next to each section. These are immensely useful, helping me scope the talk and determine what I do and don't have time to talk about. However, these are estimates, and I treat them as such. Don't feel bound to these times. Adjust as you see fit.

From a conference organizer's viewpoint, outlines help me so much. I can see exactly what you're talking about, what you're trying to get across, and whether or not I think this will be a good talk for my conference. The subset of talks that include a detailed outline and the subset of talks that get selected for the conference overlap almost perfectly.

Description

Slightly longer description. 
Expands upon elevator pitch. 
Be sure to include Audience Takeaways

This is where you can go into great depth about your talk without a character limit. I tend to write this first to get a full idea of my talk and then condense it to fit into the Elevator Pitch. You may end up submitting this section in a CFP or you may not. It's still important to fill this out to help define what you want to accomplish in your talk.

Internal Notes (For Your Eyes Only)

All the nitty-gritty of the talk. 
Your scratch paper

These are my notes. I put links to resources to help me write the talk, thoughts I had while writing the paper. Anything and everything can go here. These shouldn't be shared with conference organizers.

Additional Notes

Anything else. 
Presentation materials needed
Why you're qualified to speak on this
Etc.

A lot of CFPs will have a section for "Anything else." This is a great section to put extra requirements you'll need for your talk. These could be anything from an extra monitor to a laser pointer. If you need special accommodations, such as a lower podium or equipment, be sure to fill this in. The conference will likely already have the items you need, but it is always good to be explicit in your requirements.

Many people will often put here why they are qualified to speak on this topic. I'm personally not a fan of this, but I understand why people do it. If you want to put this in your CFPs, go ahead. A tip I would say is to never say that you are "the most qualified person to speak on this." I never put this. There is always someone more qualified to speak on this topic than me¹². If I put my qualifications here, I explain why I'm qualified to speak on this overall. Also, don't put identifying information in here. Conference organizers are trying hard to keep the selection process fair and anonymous.

My Yearly Process

Because my job expects a certain level of speaking engagements from me every year, I have a process around writing talks. Every year in late Q4, when most of the company is wrapping up and preparing to go on winter break, I sit down and write all of my conference talks for the next year. The past few years, I have written anywhere between 5-8 talks for the upcoming year. This doesn't mean that if a great idea strikes me, I won't write a paper about it. I do this so when a conference opens up that I want to speak at, I don't have to stop what I'm doing to write a proposal. The current audiences that I'm looking to speak to are the Python and DevOps communities. So I try to write talks that I think those communities will find interesting. That doesn't mean that the talks focus on a Python topic. I am somewhat known in speaking circles for talking about documentation and technical writing. These talks are relevant to both communities, so it's a win-win for me. In the past few years, I have started writing more specific talks focused on individual technologies. I usually write 2-3 of these specific talks a year, and then the rest of my talks will be broad enough that I can give them at any conference. These broader talks focus on documentation, "soft" skills, and community building.

How Do You Feel About Giving a Talk More Than Once?

There is a big debate around if/when you should give a talk more than once. I take a rather selfish stance here and say, if I spend so much time and effort writing it, you bet I'm going to give it more than once. However, I do have some rules around it.

First, I won't give a talk more than twice virtually. The first year I started speaking, which was 2019, I gave my Building Docs Like Code: Continuous Integration for Documentation talk six times at various regional Python conferences. We must remind ourselves that very few people go and search out random conference talks on YouTube¹³. Giving the same talk at different regional conferences means getting it in front of more people who more than likely would not have seen it otherwise. With the accessibility of virtual conferences, more people can attend, and I find this as a reason to not over-saturate the virtual conference market with these talks.

Second, when I'm tired of a talk, I stop giving it. My Docs Like Code talk was fantastic. I loved writing it; I loved presenting it. After six conferences and a handful of meetups, I'm tired of giving it. I may write version 2.0 in the future, but that talk is purposefully retired for now.

Third, if I give a talk and determine I don't like it, I might not give it again. I usually try to fix a talk if I feel it doesn't work, but not every talk is a winner. The talk may have felt good on paper, but I didn't like it in practice. The only way to "get good" at something is to practice. Not everything is going to be great. Don't cling to something if you aren't feeling it. There will be more opportunities.

"Should I submit a talk to this conference?"

Yes! I encourage everyone to submit talks to conferences. If you get selected, great! If you don't, feel free to reach out to the organizers for feedback on your proposal. You'll be surprised how often they'll take time to do this. Conference organizers all want you to succeed. They'll either come back with some tips on your talk, or they could tell you that your talk was great, but it just
didn't win out against other talks.

The only way to get better at anything is to practice, fail, and try again until you succeed. If you don't get selected, keep at it! It took me three years of submitting papers to conferences to finally start getting accepted. You'll get there eventually, and I look forward to watching your talk
when you do.

But not entirely, maybe you want to introduce, say, the Python community to this amazing JavaScript Framework. Go for it! Just be sure to show your audience how they can utilize it. ↩
An odd pair, but not completely unheard of. ↩
There are three things in life that are constant: Death, Change, and there will be a talk on the GIL at PyCon this year. ↩
For those of you that don't know, the GIL is the Global Interpreter Lock, and it is the thing responsible for Python not being able to run on more than one CPU core, blocking true parallelism. It's also the thing that stops you from having to track down wacky-ass race conditions and other super fun bugs that disappear and reappear due to the nature of concurrency, so maybe don't look a gift horse in the mouth, ok? ↩
And if you have, I call bullshit. ↩
It's my talk, so I can shit on it. While it was an interesting problem, it would have appealed to, like, two people. ↩
Note here that intro talk doesn't necessarily mean beginner. It means that it is an introduction to a topic. The topic itself could be advanced. What it isn't is a rare one-off use case on a rarely used feature in an advanced library. ↩
In fact, some of my favorite conference talks have had nothing to do with programming at all. ↩
As someone who enjoys clever wordplay, I'm still proud of myself for this talk title. I consider it one of my crown achievements. ↩
AP English for the win. ↩
And kudos to the ones that do. ↩
That being said, if you are the most qualified person to speak on this, you can put it. I say this because I have a lot of friends who often speak on their own open-source projects, and they are, in fact, the most qualified person to speak on this topic. However, for the sake of anonymity, maybe still avoid this. If you say, "I wrote this library, hence I'm the most qualified to speak," I probably will be able to figure out who you are. And we're trying to maintain fairness in our CFP selection process. ↩
Don't believe me? Go look at the views. ↩

Random Musings About Resumes

Mason Egger — Mon, 15 Nov 2021 00:00:00 +0000

Drafting a resume can be a nerve wracking experience. While there are many resources available for creating a resume, I still see the same mistakes year after year on resumes. In this post I'll discuss my philosophy regarding resumes and some tips on how to make yours better.

My Resume for reference

My Resume Story

It's no surprise that drafting a resume can be a daunting task. You're essentially trying to make a first impression with a piece of paper that needs to be formatted in a specific way using specific language that can't be too long or too short. If you've ever been stressed out by your resume know that you're not alone. I feel the same way. I've read articles, visited resume building centers on university campuses, and even bought a few books on resume and technical writing. While I learned a lot of good information from these resources, I found myself pushing back on some of the recurring patterns I found. Like most university students, I found myself making my first resume in preparation for a job fair. After getting a first draft of my resume finished, I looked it over and was unhappy with it. It was bland, dull, and not a representation of who I was as a person. I took it to Career Services on campus to discuss it with them but was assured that my resume checked all of their boxes and was a successful resume. That didn't sit right with me and I thought to myself "I'm going to make this the way I want to so that it represents me." So, I decided to break away from my colleagues at the time and not go with the default resume template in Google Docs and make my own using Latex ¹. Once I figured out what I was doing the result was something I was very proud of. I took my resume to the job fair and was complimented by every single recruiter I handed my resume to. Everyone loved the format and the fact that it had color, an element I was explicitly told to avoid. Since then, every single job that I've applied to has complimented me on the layout of my resume. When I started speaking at universities to students about their resumes I've tried to let them know that it's ok to deviate from the "standard resume". Below I'm going to go over the advice that I give students and working professionals regarding resumes.

Mason's Resume Advice

I will be the first to say that I have very strong opinions about resumes. You may or may not agree with everything that I say here. All of these tips are based of my personal experience and what I've witnessed while being on hiring panels ².

Tip #1 - The Standard Template is Boring. Change It Up

Everyone uses the resume templates in Word or Google Docs. Everyone. And they're boring templates, devoid of color and any emotion. I dislike them and wish they would go away forever. Try to find a template with accent colors, maybe a two column template, maybe even a Hugo template that can be saved as a 1 page resume. Don't be afraid of color ³!

Tip #2 - Objectives Are Pointless. Use That Space For Something Else

Get rid of these. Period. Objectives are my biggest pet peeve on resumes. Unless you are legitimately trying to trade me 3 chickens for one of my goats I know you're trying to get a job! You sent me your resume! You didn't send it to me so I could frame it and walk by it every day. You sent it because you want a job! Space on a resume is valuable real estate. Anything that doesn't need to be there is only taking up space from something more important. I prefer to replace this with an About Me section. Tell me who you are. What do you like to work on? What are you passionate about? My About Me says I like backend work, specifically Python, along with teaching and open source. This section is at the top of the page. The goal is for a recruiter or hiring manager to read it and be able to immediately go "This person is/isn't a good potential candidate for this role" before they ever even get to my experience ⁴. Tell people who you are up front and save everyone some time.

Tip #3 - Don't Just List Your Responsibilities. Focus On Their Impact

I always see resumes that list the job and then have a bulleted list of tasks that they completed at that job. While this does inform on what you worked on, it in no way focuses on why you were doing it or what it accomplished.

Example: You worked for a small e-commerce startup and you were responsible for implementing the shopping cart feature. You put this on your resume:

Wrote a web application using Flask, SQLite, and React for customers to use at checkout.

This tells me nothing other than what technologies you used and the general vicinity of the purpose. Try rewriting it in this format:

<THING THAT WAS ACCOMPLISHED><HOW YOU DID IT><WHAT YOU USED TO DO IT>

So let's rewrite the example above

Provided a seamless and enjoyable checkout experience for customers by implementing a shopping-cart web application using Flask, SQLite, and React.

Immediately this tells me the impact you had, what you did and how you did it. It highlights your accomplishments and allows me to gauge the impact of your work because you told me the impact.

Tip #4 - Brag About Yourself. Resumes Are NOT The Time To Be Humble

Before we go any further, I know I have to address this. Do not put that you're a 10x engineer or the Superman of programming. When I say brag about yourself, I don't mean delve into the land of hyperbole. I mean be prideful of your accomplishments. Talk about them. I often see people downplay their contributions and that is a sure way to get passed over in a screening. If you don't believe in your work how can you convince others to? Don't be afraid to take credit for your work. When implementing the above tip where you describe the impact, talk about if as if you are a CEO selling the new feature to the board. They aren't going to say "Ya, it's alright". They're going to act like it's the swiss army knife of features that'll mow your lawn, do your taxes, and it's a hot plate ⁵.

Tip #5 - Leave Out or Condense Irrelevant Data. Focus On The Data That Shows You Off

Length is usually a hot point of contention regarding resumes. Many people think that a resume should only ever be 1 page and that's it⁶. I personally don't prescribe to this philosophy. If you have 10 years of relevant experience then you should list it. But the key point to that last statement is the relevant experience part. If you're a traditional student who is attempting to get their first job you don't need more than 1 page. In fact, I would highly discourage you from going over. If you've worked side jobs here and there that doesn't really show me your skills as a software engineer. I'm not saying you should include them, but 5 list items of the different pizza delivery jobs you had isn't necessary. Be sure to include any leadership or extra responsibilities here. Condense that down to one and say Various Pizza Delivery Jobs. This will again, save you valuable space on your resume for projects, coursework, volunteer work, etc.

However, if you have previous professional experience in another field I would say that you should definitely include it. You may not need your entire work history, but a list item dedicated to acknowledging your past professions is 100% acceptable. I personally encourage it. I know many educators who are leaving the field to be software engineers. They always ask, "Should I put this?" and I startle them when I shriek "YES! Being an educator is hard. You had a profession that taught you skills that will be relevant to any job. Include it!"⁷. I have another friend who was the creative director of Cirque de Solei for near of a decade and was one of the premier jazz trombonists in the world who recently decided he wanted to go into programming. He also asked if he should include that and I was baffled. Like, you were (and still are) a famous musician. Of course you put that! There are a lot of second career people joining tech now. Your journey is a part of you and you should embrace and include that. I personally, want to know all about it.

Tip #6 - Ordering Matters. You Probably Shouldn't Lead With Your Education/University

This one I'm mostly putting because I want to rant about it. Your About Me (if you have one) and experience should always be the most prominent thing on your resume. Next you can maybe have a section dedicated to your skills, volunteer work, outside projects, awards, etc. Notice how I don't list education there. Education is important. It should be on the page. It does not need to be anywhere near the top. I have heard some resume reviewers at "prestigious" schools say that it should be at the very top and even some recruiters from some companies. The next thing I'm going to say is very important so I'm going to emphasize it for effect

This is utter bull shit.

There are some companies that care greatly about where you got your education⁸. And they have the audacity to publicly muse "Why don't we get more diverse candidates?". Well when you only focus on a handful of schools that also have diversity problems you don't get to play the surprised card when your workforce all identify within the same demographic. Personally, I refuse to put my education high up on my resume. After your first job it is old, irrelevant data. After I got my first job I immediately removed my GPA. Who the hell cares?

Unfortunately, me being pissed about this won't change these company's practices. I personally refuse to work for companies that think the school that I attended mandates my professional destiny, but they do pay a lot of money. If you want to play their games I can't stop you and you may want to include your education as the first thing.

I won't.

Things I Didn't Cover

No doubtedly there are things that I didn't cover that may have some of you going "But You Forgot to Talk About ___". The reason I left your favorite resume pet peeve is because :

I don't think it matters as much as others think it does.
It wouldn't apply in a broad sense. There are definitely tips I can give that are more targeted towards specific fields, but I wanted this article to be generalized.
I forgot ¯\_(ツ)_/¯

At the end of the day, your resume is an opportunity to express yourself. We want to know who you are and your resume is our first glimpse into that. While experience matters, you'd be surprised how often "Would this person vibe with the team" has a large part to play in hiring decisions. You can teach someone to do almost anything, it's really hard to teach them to not be a jerk.

While some of you may be sitting here thinking "Wow, that sounds like a terrible idea." let me assure you, it is way worse than you can possibly imagine. I currently have one laptop that I managed to install all of the packages correctly on that can compile my resume. I have tried to recreate it elsewhere and have failed. That laptop is forever more my "Resume Generating" laptop. One day it'll die and I'll have to change formats. But until then I just hold out against hope. ↩
If you read this article and think to yourself "He's completely wrong, I absolutely disagree with all of this" that's fine. My feelings won't be hurt. Don't implement these tips then. ↩
This is the biggest tip I get the most pushback on and I don't understand it. People always tell me "Avoid color! All you need is headers and bulleted lists!". While I can see how using colors may be difficult for someone who is visually impaired (hint: there are color schemes that address this), more often than not people who hold this bland ass opinion are trying to jam way too much into their resume and need every spare millimeter to put another irrelevant piece of information. ↩
It's also a great conversation starter for recruiters/hiring managers. They already know something about me that's true because I told them. They didn't have to extrapolate it. ↩
"And a hot plate!" ↩
I feel this is a leftover vestige of when every resume was printed out and had to be distributed physically to be reviewed. Multiple pages probably meant staples and a stack of resumes to sift through makes length an issue. But now that we do most things digitally and we have auto screening programs⁹ that filter a lot of resumes out now. ↩
This is usually when they take my caffeinee away from me and make me sit down. ↩
Looking at you FAANG. ↩
¹⁰I have my own thoughts on these but that's a rant for another day. ↩
Oooh, a footnote in a footnote. That's nifty. Ok. I'll stop now. ↩

Tech Industry Interviews are Bullshit. Let's Make Them Better

Mason Egger — Mon, 15 Feb 2021 00:00:00 +0000

Let's Just Say What We're All Thinking

Technical interviews suck. I don't think I've ever met someone who was like "You know what my favorite part of our industry is? The interviews! I love being put on the spot and being harshly critiqued over my ability to think on the spot and recall random algorithms that no one ever actually uses in production." Yet, somehow, we continue to double down on a process that is not only extremely stressful but overwhelmingly biased.

Let's Put It in Perspective

Imagine you were interviewing for a job as a short order line cook at a restaurant chain. For this example, we'll call it French Toast House. You arrive at the restaurant for an interview and are greeted by the company's accountant. Now you'll never actually work with the accountant; you're a cook but the company wants people outside of the cooks to evaluate you. You have a nice conversation with the accountant, and you try to ask basic questions like, "Do we work with gas or electric stoves?". The accountant admits that they don't know; they have nothing to do with the preparation of food, but they do want you to solve this brain teaser about transporting a fox, chicken, and corn across a river. They get up to leave and ask if you have any questions about the job. You decide to not ask any because they are unaware of the cooking procedures within the kitchen and when you tell them you don't they frown and say "That's a shame."

You are then interviewed by one of the night shift cooks. They just finished cooking 100,000,000 pieces of French toast because last night was prom night and everyone decided to come to the restaurant at 3:00am in the morning. They look utterly exhausted and completely disinterested in being there. They ask you routine questions like what a stove is and how would you handle a grease fire, but then their pager goes off. They swear loudly because apparently more French toast is needed and it's their turn to be in the bi-monthly French toast hell. You ask if it is always like this and they laugh like a deranged person who just figured out they can put Red Bull in the coffee machine and never sleep again as they walk out of the room, leaving you alone for the next 10 minutes until it's time for the next interviewer.

Your next interviewer is the Senior Short Order Line Cook. You spend the first five minutes getting to know each other but then the interviewer says it's time for "a simple test, won't be too hard". You are then asked to recreate Gordon Ramsey's famous Beef Wellington, but as an added challenge you aren't allowed to use any utensils. You are confused since you thought you were going to be making French toast, but the interviewer explains that they like to see how you do under pressure. You ask if you could go to the kitchen to attempt this experiment but are told to just diagram it on the white board. You muddle through the exercise as best you can with your limited knowledge of Beef Wellingtons but when it's over you can tell the interviewer is disappointed. They come up and show you how they would have solved it and tell you that it's a standard question from the Cracking the Short Order Line Cook Interview book. You're shown out of the building and told they'll get back to you with their decision soon. You make a mental note of how to cook Beef Wellingtons, just on the off chance it shows up at your interview at Burger Queen.

If you were offered the job would you take it? Depends on your situation. You're pretty sure you'll be able to work with real utensils and not have to cook Beef Wellingtons but didn't see any evidence of this. Was this a fair interview process? No. Yet some version of this dynamic is currently being used to interview software engineers around the world, holding them to a much higher standard and rigging the situation against people who don't know the secret knock of admittance.

Why Is It Like This?

To be honest, I have no earthly idea. I don't know where this form of interviewing came from. My assumption is that one of the larger companies decided to develop a hiring practice to ensure that they could "attract and hire top talent" ¹. Then everyone else in the industry was like "Hey look! Hooli does it like this, so should we!". There's a very blatant issue with this approach. Your 30 person startup does not have the same hiring challenges as the wealthiest company on the planet. I don't know who needs to hear this, but you are not Hooli. You're not. "Well if we continue growing our customer base..." No. Stop. You do not move petabytes of data a day. You do not have 3 billion concurrent users. And let's be honest, these large companies don't need this kind of process either. The only reason they get away with it is because their reputation allows them to get away with it. If I were to give a conservative estimate I would say 95% of all software engineering jobs will not require the level of stringency that is tested in interviews. I think the following image explains it perfectly (big shout out to Dare Obasanjo for posting this on their twitter.

So, your small startup offering a store front for people to buy stuffed armadillos should not adopt these same interviewing methods. For one, they are extremely discouraging to participants. I personally know that I'm a competent engineer. These interviews make me feel like shit, hands down. I have to tell myself that "Interview questions are not the real job. You can do the job, you just struggle jumping through their hoops." Secondly, adopting their practices means that you are validating these practices. And that's your choice; just know that some people, myself included, refuse to participate in interviews like this and you're potentially alienating your talent pool. If you really cared about "top talent", your interview practice would show it.

If you want to attract the top talent, make your interview process match the level of expectation required for the job.

Why Do the Engineers at These Companies Participate in This Process?

I honestly don't know. I know that I don't. I refuse. If I had to guess about other people, I'd say it's primarily a combination of lack of training mixed with a little bit of ego, revenge, and gatekeeping.

Let's Talk About the Lack of Training First.

I've worked in the software industry for about 9 years now, with my first three years being in academia. It wasn't until I joined DigitalOcean in October of 2019 that I ever received any form of interview training. Most engineers are thrust into the interview room with no further instructions than "Interview this person." This actually surfaces a more pressing issue, and that is there is no formalized process around hiring. This is bad for both the candidate and the company. This means that there isn't any sort of standardized interviewing practices not only across teams within the company but also within a single team that is interviewing multiple candidates for the same role. This can lead to vastly different experiences for candidates and allow for bias to slip in. So when I think about it, it is kind of hard to be upset with engineers for reverting to the types of questions that they themselves were asked when they are given no training or guidance in interviewing. At that point, it is a failure of the company, not the individual interviewers.

Do You Really Think Some People Care About Where You Went to School or Imparting Their Struggles Onto Others?

Absolutely. I've witnessed it. I've been denied opportunities because of where I went to school and my inability to perform somersaults while saying the Greek alphabet backwards. If you ever want to be completely disheartened by this all you have to do is go read the Tech industry interview section on the Blind app². The below bullet points are exact quotes from people I've heard in my career from interviewers and sadly enough, recruiters.

"Well, I had to do XYZ when I was interviewing, so they should too!"
"I went to a Top 10 Computer Science School. Where did you go?"
"I don't want to hire students from XYZ University, their program isn't good."
"We don't hire engineers from your University. (Said to me by a recruiter at a job fair on my university campus)

This saddens me to no end. But it's a reality that we need to talk about. This came up as recently as two weeks ago when someone posted the interview criteria that ex-Googlers created while they were working at Twitter. A process, btw, that is disgustingly discriminatory. (Thanks to Leslie Miley for posting this)

I could go on but I'm literally getting upset writing this. So long story short: Yes these people exist. Yes it's completely unfair. Call it out when you see it, speak up in your company for fair interviewing practices (I'll go into this more later in the article) and don't repeat their mistakes.

Does Everyone Do This?

Not at all. People tend to remember past bad experiences and that is exactly what happened in the paragraph above. For every asshole interviewer I've experienced I've dealt with three amazing ones. But it only takes one bad person in an interview panel to sour the entire experience. Oddly enough, I've found that it's usually the younger engineers who do this³. When I've interviewed with more senior engineers who haven't thought about how to balance a tree since their last interview⁴ don't ask questions like this. They ask practical questions. I know one senior engineer who always asks the exact same interview questions regardless of level. He claims he can know everything about a candidate from three relatively simple programming questions, each of which should be solvable by a student who has finished a CS 101 course. I had another senior person set up a test where I had to debug an issue with a web server. None of this "If you throw an egg down a hallway how many platypuses would it take to sing La Traviata"⁵. Questions that are actually relevant to the job that test proficiency, not familiarity with questions.

"Well Then, If You Don't Like It What's The Better Option?"

I mentioned it above but I'll repeat Ask questions that are relevant to the job you're interviewing the candidate for. If you are interviewing someone for a job to work on the front page of your website, they probably don't need to know how to build a binary tree from scratch. And I'm sure if that odd case ever did actually come up they would do what every engineer⁶ does, They'll Google It. It's as if everyone believes their workplace is this XKCD comic.

Memorization of knowledge is an outdated measure of intelligence. We live in a world where I can ask literally any question I have ever wanted and get an answer instantly. Is having this knowledge in your mind advantageous? Absolutely. But is it an indicator of ability? Not in the slightest. In actuality it could become a hindrance. The amount of times I've learned something new about a topic I already felt very knowledgeable in because I chose to look something up to double check is non-trivial. The information in your head doesn't update unless you choose to update it.

How I Interview People

I enjoy interviewing people. It's always fun to add someone new to your team and the people you meet along the way are fascinating. I split my interviews into three parts:

Let them talk about themselves
Technical interview
Discuss the job

Part 1 - Let the Candidate Tell You About Themselves

Candidates tend to want to tell you about themselves and their work. So let them. Questions like "So tell me about yourself" can be seen as vague but some candidates really enjoy that question. If they don't, try to make a more pointed question. "Tell me about your last job." "How did you get into programming?" "What is your favorite programming language and why?" These are all really good ways to get a conversation going. My favorite question to ask is "Tell me about a project that you're proud of." Most developers have had at least one project that they are super happy to talk about. The project might have taught them something new, been really fun to work on, or solved a complex issue. Whatever it is, you want to know about it because it will showcase the candidates ambition. I always hire enthusiastic, ambitious, and curious people ready to learn. That mindset is contagious and it elevates a team.

Part 2 - Technical Interview

"Wait Mason, didn't you just go on a long winded rant about how you hate technical interviews?" To an extent. I hate technical interviews for the sake of cleverness. I do, however, acknowledge that we have to have some metric of determining ability. I have a three-pronged technical interview. The first question is for them to implement the classic "Fizzbuzz" program⁷. You may laugh, but you'd be surprised how many people are filtered out with this question. This is the bare minimum bar for me. If a candidate can't pass this then I believe they will benefit more from practice and study than a job that has demands. The second question I ask is for the candidate to implement the game of craps. I usually explain the game and have a printout for the candidate to reference. This assignment requires keeping state and iterating until an outcome is reached. Finally, I tend to ask a question about removing all duplicate characters from a string and getting a count of all the characters of the same type in a string. I love set theory so if you use a set for this question I smile on the inside. This is the question I'd like to see some form of data structures being used.

Note, none of the questions require advanced knowledge of data structures or algorithms. As someone who's worked in the DevOps space for a while, I rarely come across these concepts so I don't interview for them. I assume that the person who I hire will reach for these tools when necessary and if not that's what a code review and being a mentor is for.

Part 3 - Discuss the Job

This might be the most controversial thing I say in this entire blog post. I show every candidate who does an onsite (or virtual onsite) our Jira backlog. I show them what the team is working on. I encourage them to ask questions about the backlog. It is just as much about them interviewing me as it is me interviewing them. I had an experience where I took a job and in our first sprint planning I looked at the backlog and saw not a single thing that I wanted to work on. I spent the next year and a half hating my job. I want to ensure that doesn't happen to anyone on my team. I also take this time to discuss architecture, the technologies we use, and ask questions about these technologies. If the role is for a Senior Kubernetes Engineer then I should definitely check their knowledge. If you have a good recruiting team supporting you though, this isn't as necessary because they should have already weeded out the people with little to know experience in the technologies you need.

After the Interview

Hopefully you're not the only person interviewing a candidate and there is a team of people relevant to the project. Trust your teammates. Tell them what you're going to be interviewing the candidate on so they can adjust accordingly. Everyone should interview every candidate with the same outline. Switching it up to how you feel that day just allows for bias.

How Can This Be Made Better?

Talk with your manager. Talk with your teammates. Discuss how you can make the process better. Then take action. Here are some tips for an interview process that you can easily implement and improve your process:

Discuss who will ask what. Make sure everyone doesn't ask FizzBuzz. Does everyone need to know the candidates life story or could that time be better used for other questions?
Set your questions and ask the same questions for all candidates. This will help remove bias and ensure a fair process for the whole candidate pool.
Hold your teammates accountable for their questions. If you see a question that you think is unnecessary ask your teammate what they are trying to learn from that question. Don't come off confrontational about this. People can get defensive over this topic really quick.
Don't do group interviews. These are extremely intimidating and you will not get the results you desire from these.
Debrief within 24 hours of the candidate exiting the building. Impressions are best fresh.

A defined process will lead to a better experience for both the candidates and the interviewers.

Final Thoughts

We can do better than this. I love the tech industry. The people who I've met here are amazing and the innovation is inspiring. Take action. Make an active attempt to make your process standardized. Make the interview process match the requirements. Developers talk. When we experience a good interview process we tell our friends and the same for a bad one. I've not applied at companies before because I've heard their process is awful. The changes you're trying to achieve won't happen overnight. It'll take time. The only thing I can tell you is that if no one tries to make things better that we all better get used to cracking open your copy of Cracking the Short Order Line Cook Interview and remember exactly how to make Gordon Ramsey's Beef Wellington.

By the way, "hire and attract top talent" is just a fancy way of saying "mask our discrimination by hiring people that look and think like us". ↩
I don't recommend you do this. It'll just make you sad and upset. ↩
If you're a younger engineer who doesn't do this, congrats! You're doing it right. Those who are doing this know who they are and probably will leave nasty comments or blast me on Twitter about this article. ↩
Or ever. Some of the best engineers I've ever worked with have 0 formal education in Computer Science. ↩
The answer is 17. 12 to sing the different parts and 5 extras in case any of them run after the egg. Usually the mean platypus attention span can be calculated by taking the sum of the number of platypuses divided by the average length of an egg. This can range from 53.12mm for a medium sized egg to 59.675mm for an extra large egg. For the sake of brevity I won't go into the math of converting platypuses to millimeters. ↩
Including you, snobby person currently interviewing the candidate. ↩
Always give a detailed assumption of the program. Don't assume everyone knows what Fizzbuzz is. ↩

How To Build a 7 Days To Die Server on Ubuntu 20.04

Mason Egger — Sun, 31 Jan 2021 00:00:00 +0000

7 Days to Die has easily become one of my favorite video games. It is essentially a cross between Minecraft and Left 4 Dead and I find it absolutely thrilling. In this tutorial you'll setup a 7D2D server on Ubuntu 20.04.

The Premise

7 Days to Die is an open-world sandbox that combines a first person shooter with survival horror, tower defense and traditional RPG elements. The game takes place in a post-apocalyptic world overrun by zombies. Your goal is to gather resources, craft shelter, food, and weapons, and survive the notorious blood moons that happen every 7 days where massive hordes of zombies attack.

Prerequisites

To complete this turoial, you'll need:

An Ubuntu 20.04 server with a non-root user setup. Use this tutorial for initial server setup, except name your user days. I personally use a DigitalOcean server to host my game. However, cloud hosting for your server can be expensive. You may be better off building the server locally with an old PC. Note: This server would do well to have at least 8GB of RAM and 4 CPUs. You may need more depending on your configuration and how many players you wish to support.
A copy of 7 Days to Die. You can purchase the game on the Steam Store

Step 1 - Installing the Game

First thing you'll need to do is gain access to your server. If it's a local machine you can simply login via the UI or if it's a server, you should ssh in. Login as your non-root user 7d2d and update the server to the latest version so you have the most recent packages.

sudo apt update && sudo apt upgrade -y

Next, you'll need to install some packages for running 7d2d. You'll need to install a text editor (nano, vim, emacs, etc.) to be able to modify configuration files as well as the program screen to create virtual terminal sessions for running your game server. You'll need to install wget to install the Steam command line tool and lib32gcc1 to run the SteamCMD. Install them with the following command.

sudo apt install -y vim screen wget lib32gcc1

Once you have the packages installed, you'll need to install SteamCMD. Use wget to download the tool and tar to extract it from the archive.

wget http://media.steampowered.com/installer/steamcmd_linux.tar.gz
tar -xvf steamcmd_linux.tar.gz

Next, start a SteamCMD session. Once you're logged in you'll see the SteamCMD prompt Steam>:

./steamcmd.sh

7 Days to Die is a game that doesn't require you to login to your personal account to download the game. So you'll need to login as an anonymous user.

Steam> login anonymous

Next, you'll need to set where to install the game files. Call this folder 7days and install it in the current directory.

Steam> force_install_dir ./7days

Now you're ready to install the game. Steam uses app ids to distinguish which game to download. You can view the whole list on the Steam Dedicated Servers List. The id for 7D2D is 294420 which we'll use to install the game.

Steam> app_update 294420

The game will now download and unpack in the directory. Once this is done you can quit the SteamCMD.

Steam> quit

Finally, 7D2D runs on port 26900 by default. If you enabled UFW from the Ubuntu initial server setup then you'll need to open this port to allow traffic along with a range within 5 other ports for other communication. Running the following command will properly configure your firewall.

sudo ufw allow 26900:26905/tcp
sudo ufw allow 26900:26905/udp

Once you've done this, you're ready to configure and launch the server.

Step 2 - Configuring and Running the Game

Now that you have the game installed navigate within the 7days folder to location of the configuration file.

cd 7days

The server configuration file is named serverconfig.xml. There are many settings within this file that can be tweaked, and they are all well documented. Below is a chart of some of the more interesting settings you may wish to change. This is not a comprehensive list of all settings.

Property	Description
ServerName	The name of your server
ServerDescription	The description to be shown in the server browser
ServerPort	Which port to run your server on. If you change this you'll need to update your firewall
ServerVisibility	0 = Not Listed, 1 = Friends, 2 = Public
ServerPassword	Password to get into your server. Leave blank for no password
EACEnabled	Easy Anti Cheat support. You'll need to set this to false if you plan on using mods.
GameWorld	Which map you want to play on. There are a handful of PREGENs. Set to RWG if you want to randomly generate your own. This does take a long time and can exhaust server resources.
WorldGenSeed	A seed for randomly generating your own world
WorldGenSize	Size of the world. From 2048 - 16384
LootRespawnDays	How often loot respawns
MaxSpawnedZombies	How many zombies can spawn. Has a significant performance impact
MaxSpawnedAnimals	How many animals can spawn. Has a significant performance impact

Once you have modified the file to your liking you will need to start a screen session. This will create a virtual terminal session that will persist even after you have disconnected your terminal from the server.

To start a session type the screen command:

screen

You'll be prompted with some license information. Press Enter if you agree and now you're in a screen session.

Now you can start the server by running the following command:

./startserver.sh -configfile=serverconfig.xml

It does take a few minutes for your server to start. Once you see the following output your server is ready to be connected to.

Using config file: serverconfig.xml
Set current directory to /home/days/7days
Found path: /home/days/7days/7DaysToDieServer.x86_64
[S_API FAIL] SteamAPI_Init() failed; SteamAPI_IsSteamRunning() failed.
Setting breakpad minidump AppID = 251570

Once you're ready to disconnect from the virtual session you can use the command CTRL + A + D. Now you'll be able to continue doing things on the server. Once you're ready to reconnect to the session use the command:

screen -r

You can learn more about the various screen commands here

Now that your server is running you can now connect from your client and play.

Step 3 - Connecting to Your Server

Go to Steam and launch your 7 Days to Die Game. You'll want to click on the Join Game menu option.

Once you do this click on the Connect To IP button in the bottom right hand portion of the screen and enter your IP address. If you setup a DNS name for your server that will also work here. If you setup a password you'll be prompted for it after you click connect.

The server will start downloading the configuration and when it's done you'll load into your server.

Conclusion

In this tutorial you setup a 7 Days to Die server and loaded into it. In the next tutorial we'll install the Darkness Falls mod and discuss how to configure and even modify the mod.

If you want to run this server on DigitalOcean you can click here for a $100 free credit for 2 months with a new account.

Like this content? Follow me @masonegger on Twitter or join me on Twitch for live coding and discussions on my channel CodingWithMason.

Django or Flask: How Do I Choose Which To Use?

Mason Egger — Sun, 17 Jan 2021 00:00:00 +0000

I love both Django and Flask. Due to the recent release of DigitalOcean’s App Platform I have found myself writing more and more webservices using these two frameworks. I now find myself answering the same question very often, which is how do you choose which one to use? Well luckily I have a simple checklist of questions to ask myself that helps me determine which framework to use. The Questions Currently I ask myself three questions to determine which framework I’m going to use.

I love both Django and Flask. Due to the recent release of DigitalOcean's App Platform I have found myself writing more and more webservices using these two frameworks. I now find myself answering the same question very often, which is how do you choose which one to use? Well luckily I have a simple checklist of questions to ask myself that helps me determine which framework to use.

The Questions

Currently I ask myself three questions to determine which framework I'm going to use. I will admit that currently I'm building mostly one-off applications and things for fun. If I was designing a large application for a company or open source project I would probably use these questions as a starting point, but I wouldn't use this as a finite decision maker.

That being said, it's probable that you may not agree with my choices. This is fine. Each framework is 100% capable of solving every problem I throw at it. These are just my personal preferences after roughly 8 years of building Python microservices.

Database Access

Do you need to access a database like MySQL or Postgres?
- Yes - Django
- No - Flask

I am a huge fan of the Django ORM. It was one of the first tools I learned when I started doing Python web development and it makes my life simple. So if I find myself needing a relational database I immediately find myself reaching for Django. There are other Python ORMS such as SQLAlchemy that are also good. Flask + SQLAlchemy is a perfectly fine choice as well. But I tend to go with the Django ORM.

However, if I need a different data store, such as a Key Value store like Redis, I will find myself reaching for Flask. If I don't need the Django ORM I don't use it. It doesn't add to much value for me in this situation. It's all about the right tool for the job.

User Authentication

Do you want to have users be able to login to the system?
- Yes - Django
- No - Flask

After the ORM my next favorite feature of Django is its authentication framework. This is another feature I've been using since I got started with Django and it has been fun watching it grow and gain features throughout the years. I enjoy this feature so much I have never implemented authentication in Flask. Maybe it's fantastic. I wouldn't know. I have always found Django's auth to be easy to use and extremely flexible. So, if I need user authentication, I always pick Django.

Container Size

If deploying a microservice, does size of container matter?
- Yes - Consider Flask
- No - Consider Django

Sometimes when you're deploying microservices the size of your container makes a big difference. We would expect Flask, being a microframework, to have a smaller footprint than Django, which is exactly the case. Below is data regarding three docker containers that I've built. One is ubuntu with pip installed, one has flask installed and the other has Django installed.

ubuntu              ...     394MB
flask               ...     398MB
django              ...     428MB

As we can see, there is a 30MB difference between the containers. This is just the base framework, not including other libraries and middleware. While this may not seem like a lot, it can make a difference in deployment environments. I rarely have to ask myself this question, but it is definitely something that needs to be considered.

The Decision

Once I have run through my list I tally it up. If Django was an answer to the database or authentication questions that is usually enough for me to go with Django. However, if that isn't the case I almost always go with Flask. If I'm writing a small microservice, cron task, or even a small REST API Flask provides everything I need to write clear, concise code. It's not that Flask can't be used to build large applications. In fact, the first job I had out of college was building a huge REST API in Flask. I just enjoy writing smaller apps in Flask and larger apps in Django.

Conclusion

So there you have it. That is how I determine if I'm writing my application in Django or Flask. The process may seem simple, but I have always been happy with the implementation of my apps. If I was working in a team or the code would need to be maintained by others I would use this framework to start a discussion instead of mandating a tech stack, but for my personal projects it's good enough for me.

If you're curious about deploying Django or Flask to DigitalOcean's App Platform checkout this Django and Flask tutorial that I wrote. If you're new to DigitalOcean and want to try it out you can click here for a $100 free credit for 2 months with a new account.

Exploring New Waters: A Recap of My First Year at DigitalOcean

Mason Egger — Fri, 18 Dec 2020 00:00:00 +0000

So this blog post is a few months late. I wanted to post it on the anniversary of my first day at DigitalOcean, however between Hacktoberfest, deploy by DigitalOcean, and the launch of App Platform October and November were very busy for me. However, now that things have calmed down I can finally sit down and reflect on my first year at DigitalOcean as a Developer Advocate.

How I Arrived at DigitalOcean

On October 1, 2019 I joined DigitalOcean as a Developer Advocate. This was my first step into an advocacy role after spending roughly four years professionally as a Software Engineer/Site Reliability Engineer¹. This was going to be my third role in under five years and I was feeling slightly down that I hadn't managed to stay at one place for longer than two and half years. I left my first role for reasons that honestly, looking back, I could have probably gotten over. But I was young and dumb(er) and the sudden shift in company focus, team changes, and the inability to decide on what we wanted to be triggered my fight or flight reflex and I left. My second job, the job I left to join DigitalOcean, was....interesting to say the least. I learned so much about the Cloud, Availability, Scaling, and the list goes on. The Cloud platform I got to work on and maintain is still, to this day, one of the most impressive I've ever seen. However, the culture among my org was slightly less toxic than a nuclear waste dump. Without going into too much detail it sucked, I hated it, and became ever more depressed the longer I stayed there. So, I started looking for a new gig. While being miserable at my previous job I learned a neat little trick. If I got accepted to speak at a conference my boss would give me the time off to attend the conference. He wouldn't pay for the conference, but honestly at that point anything I could do to get away was worth it. So, I started submitting talks and getting accepted to many different conferences across the continent. It was during this time that I became more aware of the Developer Advocate role and what it was. I applied for a handful of Developer Advocate roles, as well as some SE/SRE roles. While the idea of being an advocate was enticing, I wasn't quite sure if I wanted to take that step. And of course, fate would position me where I had to make that exact decision. I received offers for both a Developer Advocate role and a Site Reliability Engineer role at two different companies, both of whom I was super excited to work at. I flip flopped at lot on which role I wanted to take but, in the end, I took the role at DigitalOcean as a Developer Advocate. It was a hard decision, but I had become so disenfranchised with engineering in general I thought it would be a good choice to try something new. And, thankfully, I was correct.

How This Year Went: October 1, 2019 - December 18, 2020

DigitalOcean prides itself on being a remote friendly company. When I started almost 70% of the company was fully remote and my role was going to be remote. That being said, most new sharks start their first week in the New York City office. I had never been to NYC so it was excited. Due to current events coming up in the DigitalOcean company calendar my manager was able to allow me to start working the Monday after I stopped working at my previous job. This was due to the fact that DigitalOcean was going to be having its global company all hands at Disney World in the middle of October and for me to go I needed to start within a window. I agreed and was able to convince my boss to let me have the week off after my first week to kind of recuperate from my previous job. I fly out to NYC and get put up in one of the company's corporate apartments. Due to a majority of the company being remote these apartments were kept so employees cannot have to worry with the hassle of a hotel when they come into town. I get to the apartment and the first person I meet is Adam Harder, the new Video Marketing Manager. Later that evening my manager Eddie Zaneski arrived at the apartment since he was also spending the week in NYC. The next day we go to the office and I go through the typical first day things. This is where things change. I am packing up my stuff when my manager Eddie comes by and says "Are you ready to work an event?". Turns out that night was the kickoff night for Hacktoberfest and I was going to help run the event. It was a lot of fun and I must say, that was the most interesting first day I've ever experienced. Fast forward a few weeks and I'm off to Disney World for our company all hands. I got to meet so many people in the company, including all of my teammates, and just had the best time ever. My team was amazing. We got to take team pictures, hang out, plan what we wanted to accomplish for the next year and just get to bond. The Developer Advocate team was finally fully staffed and ready to go. I leave Disney beyond excited for what the future holds. We continue through the year as I settle in and meet more and more people in the company. We get started in 2020 and I was excited to get to work conferences. One of the main reasons I joined was to get to travel and meet developers all over the world......and we see how that all turned out. I am happy to say I did get to work one conference this
year. I attended Sunshine PHP in Miami, Florida in the first week of February and I loved it.

Unfortunately, these happy times were short lived. Due to changes made within the company, the Marketing org, and people deciding to pursue options elsewhere I was left the only remaining member of my original team. I'm not going to lie, it was kind of a blow. My previous team was amazing and to finally find a place that felt welcoming just to have it disappear was a huge downer. I contemplated if I should remain an advocate and even at the company. I decided to stay because I had just gotten started and hadn't even been able to actually do much Developer Relations work. I also wanted to see the new direction that my team was going to take. And on top of all of this, the world was grappling to deal with a global pandemic the likes of which hadn't been seen for a century. What was Developer Relations and Community going to look like when I couldn't physically be with my Community? Luckily, I fortunate enough that my new manager was someone I trusted within the company and had been a part of my previous extended team. After that we picked up another Developer Advocate internally and then a contractor to help us with the logistical parts of the role and suddenly, I had a team again. And honestly, I'm so glad I stayed. While I miss my old team, my current team is amazing. The direction, strategy, and charter of my team is amazing. We have measurable goals to work towards and I get to work with some of the best in Developer Relations. From product releases to Tech Talks (webinars) to virtual conferences (both attending and hosting) to Hacktoberfest this year has been a new slate for Developer Relations at DigitalOcean. I feel that we were able to navigate the pandemic situation and brought new life to virtual events at a level that hadn't been seen before. I'm incredibly grateful for my team, my extended teams, the Marketing organization and DigitalOcean as a whole for making a challenging year much more enjoyable that it could have been.

2020 Stats

So what all did I do this year? Here are the stats for my accomplishments of 2020:

Code:
- Added the DOCR resource and data source for the DigitalOcean Terraform Provider.
- Wrote multiple sample example applications for DigitalOcean's App Platform:
  - Django
  - Flask
  - Fortran
  - COBOL
  - Perl
- Wrote multiple functional applications for DigitalOcean's App Platform
- Hacktoberfest Repo Label/Topic Manager
- Terraform Sample Architectures for DigitalOcean
- Education Tool for setting up a lab type environment using Droplets DigitalOcean Classroom
Content:
- Wrote 6 Tutorials for DigitalOcean's Community Site
- Produced the following videos for DigitalOcean
  - Using Visual Studio Code for Remote Development
  - Build a Django App on DigitalOcean
Community:
- Presented at the following conferences:
  - PyCon 2020 - Building Docs like Code: Continuous Integration for Documentation
  - Open Source Summit - SLIs, SLAs, SLD’OHs! Learning About Service Uptime from Homer Simpson
  - PyOhio - There's a Snake in the Birdhouse! Building a Python Culture at Vrbo
  - EuroPython - There's a Snake in the Birdhouse! Building a Python Culture at Vrbo
  - PyTexas - There's a Snake in the Birdhouse! Building a Python Culture at Vrbo
  - PyTexas - How to Build and Deploy Your First Python Slackbot on DigitalOcean's App Platform
- Presented at the following meetups:
  - Chicago Python - SLIs, SLAs, SLD’OHs! Learning About Service Uptime from Homer Simpson
  - IndyPy - Infarstructure as Code using Terraform Workshop
  - Evening of Python Coding - Mkdocs Intro
  - One Valley - Strategies for Building Cloud Infrastructure
  - Texas State University EXE Student Club - Building a Discord Bot
- Presented the following Tech Talks for DigitalOcean:
- Multiple livestreams on my Twitch channel Coding With Mason

What Does The Future Hold?

My future holds many more enjoyable days at DigitalOcean. For the first time in my career I'm not looking to what's next or thinking about my next career jump. I am incredibly happy in my role and want to just enjoy that for a time. Constantly thinking about the next step, the next jump, the next item on our career checklist often causes us to miss the fun moments and doesn't allow us to just enjoy being in the moment. I finally found a company that feels like home, shares my values, and allows me to do the kind of work that I want to do. They also support me by allowing me to further my career with courses and professional development. Next year I'm going to be participating in Stephanie Morillo's DevRel CMS next year, I'm working on a book proposal and experimenting with Zines. 2020 may have been challenging but for me, it was a good year to reset and introspect, preparing and motivating me to make 2021 a phenomenal year.

Thank you to everyone who has and continues to support me and my work. I look forward to producing amazing content for y'all in 2021. Happy Holidays!

Like this content? Follow me @masonegger on Twitter or join me on Twitch for live coding and discussions on my channel CodingWithMason.

I had worked as a student at Texas State University managing labs and writing software while I was getting my degrees but our industry doesn't count this as "real" software engineering. I may write a blog about my opinion on this in the future but the tl;dr of that dismissive mindset is: "That's bullshit." ↩

My Personal 'How Am I Feeling About My Job' Litmus Test

Mason Egger — Fri, 20 Nov 2020 00:00:00 +0000

So, I’ve discovered something curious that I’ve told others about but never really wrote down before. Over the past five years working in the tech industry, from cyber security to vacation rentals to now cloud providers, I’ve developed a sort of litmus test about how I’m currently feeling about my job. Funny enough I didn’t set out to build this but rather it sort of just happened. It’s a test I apply every morning and when the results come back negative for too many days in a row I know it’s time to change something.

My Morning Shower Playlist Litmus Test

So, like some I enjoy listening to music while I shower in the morning. I used to listen to the news on my Google Home but I've learned that starting your day off with the latest news is a great way to ruin your day and put you in a sour mood. So, I started messing around with the idea of a playlist that I listen to every morning. Some people may opt to just have random music play every morning but that's not really my style. My morning shower playlist is more of a hype playlist and I enjoy the repetition. One of the things that annoys my friends and family is that I can watch the same TV show or listen to the same music over and over and over and never get tired of it. I'm embarrassed to say how many times I've watched the entire King of the Hill series and when I was
in college I bought the Book of Mormon CD (my Toyota Corolla didn't have Bluetooth) and I left it in the CD player for about 4 years. On rare occasions I would change it to Wicked but then right back. I am happy to report now that I own a vehicle with Bluetooth I now alternate my music a little more. Anyway, the point here is that while some people would be annoyed with the same music every single day I actually love it. So, I started adding and removing songs to the playlist until I settled on what I believe is the perfect shower playlist. I've noticed that when
I spend long amounts of time in the shower it's usually because I'm avoiding going to work. I can even pinpoint how I currently feel about the day ahead based on which song is playing when I finish and turn the shower off.

The Playlist

Here is my "'How Do I Feel About Work' Shower Litmus Test".

High Hopes - Panic! At The Disco
Shooting Stars - Bag Raiders
Come On Eileen - Dexys Midnight Runners
Don't Stop Me Now - Queen
9 to 5 - Dolly Parton
The Show Must Go On - Queen

If you are unfamiliar with the songs, this playlist is essentially a hype playlist with songs like High Hopes, Shooting Stars, Come On Eileen, and Don't Stop Me Now that devolves rather quickly at the end. Dolly Parton's 9 to 5 is pretty much a working class anthem that criticizes the capitalistic system (and that's putting it lightly) which is then followed by The Show Must Go On, a lesser known Queen song that, to me, reminds me of a sad clown putting on a happy face to do his job¹. Like I said, this playlist is a rollercoaster that drops fast at the end.

How I Administer This Litmus Test

Every morning I wake up, tell my Google Home Mini to play my playlist and take a shower. I listen to the music and enjoy the warm water and depending on what song is playing when I get out helps me determine how I feel about the day ahead.

Here's what I'm feeling when each song is playing:

High Hopes - Panic! At the Disco

So, I am rarely done when this song is playing. If I am it usually means that I'm running late. It takes half the time of this song just for my water to warm up. So, on days where this song is the result it tells me I need to get up earlier.

That being said, this is a great song to start your morning to. It is a fantastic hype song and usually wakes me up quickly. Some might say it is an intense song to start the morning off with, I think it is just intense enough.

Shooting Stars - Bag Raiders

It is also rare for me to be done when this song is playing. However, it does happen. When this song is the result of the test it tends to mean I'm either running slightly less late than if I had finished listening to High Hopes, that I've figured out the answer to an issue I've been having and want to rush out to fix it, or I'm just generally excited for work. Often, it's that I'm still running late, but slightly less late.

This song is more of a meditative song than a hype song in my mind. It is a great song to just stand with your head under warm water and think. Therefore, this song is not often the result of the litmus test. It is not meant to be.

Come On Eileen - Dexys Midnight Runners

When I finish my shower on this song that usually means I got a good night sleep, am ready to go, and am excited about the day. This result should be interpreted as "You are currently happy and excited about your job." I would say that maybe 35% of the time I finish here. And I suspect the reason this number is low is due to lack of sleep not excitement.

This song is just fun to sing along with. The Too-ra-loo-ra Too-ra-loo-rye-ay is just too much fun to not sing along with and play with harmonically. So have fun.

Don't Stop Me Now - Queen

Ah. This song. The hype songs of all hype songs. If I finish with this song I may have been a little groggy waking up. I'm notorious for not getting a decent night’s sleep but this song definitely wakes me up. This result basically means everything's right in my work life. I'm happy, I'm fulfilled, I'm ready to tackle the day. This song is the result a vast majority of days.

Who doesn't love this song? Like seriously. It just gets you pumped.

9 to 5 - Dolly Parton

So, as I said earlier, this roller coaster takes a downward angle fast. 9 to 5 is not the song of happy workers. I would imagine there is a correlation between the amount of people listening to this song and unions starting to form. That being said, if this song is the result of my litmus test it is not necessarily game over. This just means I'm tired with the bull shit I've been dealing with lately and will more probably be in a bad mood that day.

Dolly Parton is a national treasure. Enough said.

The Show Must Go On - Queen

This is the bottom of the roller coaster. If we are here, it is not good.

Inside my heart is breaking
My makeup may be flaking
But my smile, still, stays on

When this song is the result of the test, I know that I need to take immediate action to make something better at work. Whether that be take a few days off, talk with my manager, or polish up the resume, this is not where I want to be.

This song is hauntingly beautiful, and I highly recommend that if you haven't heard it before that you give it a listen.

How Do I Use This Data?

So, I bet you're wondering "If he gets to the end of his playlist does he just quit?". The answer here is no. No one day is enough to make me quit. It is a great indicator about how I'm currently feeling, but that day could turn everything around. I use this data two different ways. The first is to get a gauge of my mood for the day. The second is to gauge my long-term mood. If I wind up listening to the ghostly voice of Freddie Mercury singing The show must go on for a month straight that's when I start to think that serious action needs to be taken. And I've been there. I switched teams at a past job because I found myself in this dark place for a long time (this past job was actually how I developed this playlist). And even then, when nothing changed after switching teams I decided it was time to move on.

And to be honest, that was the best decision I've ever made.

Conclusion

Your mental health matters. Being unhappy in a job can drag you down into some very dark places. I stayed at a job for a year and a half hating my life wondering why none of my side projects were getting anywhere, why I didn't want to achieve the goals I had set for myself, and why my personal life was suffering. I know times are tough and getting a new job, especially in the current state of the world, can be scary or downright impossible. But life's too short to wake up every morning hating it. I didn't realize just how much a toxic work culture could drag you down until I left one. It's like having a weight lifted off your chest. I urge you all to find some way of being able to measure your happiness and satisfaction with your life. Because it's possible you'll wind up like me, confused and depressed, trying to figure out what's wrong when the answer was right in front of my face.

That being said, it's a beautiful song and if you haven't heard it, I highly recommend it. It chronicles Freddie Mercury's struggle to continue performing while losing his battle with AIDS. ↩