DEV Community: Glenn Stovall

10 ways to thrive as an egotistical developer

Glenn Stovall — Thu, 10 Feb 2022 12:16:19 +0000

You don't want to find the company where you're a good fit, you need to find the job that's a good fit for you. Here are ten tips to help you land your next gig:

1. Consider job titles

Only accept titles of 'senior' or higher. It doesn't matter if you graduated from codingbootcamp.biz six months ago. Some people get the same one year of experience ten times!

2. Pick the right technologies

Stick to cutting-edge technologies. Any framework more than thirty days old is legacy and therefore bad. For example, Ruby on Rails is dead so avoid sad sack companies such as Bloomberg, Soundcloud, Zendesk, Basecamp, Shopify, Airbnb, Kickstarter, Twitch, GitHub, or Urban Dictionary.

3. Work on the best projects

Only work on projects you want to work on. Remember that doing work that isn't your favorite is a one-way path to burnout city!😫 Staying in your comfort zone hides your weaknesses and protects your personal brand.

4. Show initiative

Apply to jobs with unsolicited feedback and redesigns of their website. What you lack in context and restraints they had when working on it, you make up for in CSS animations you copy/pasted from Codepen that add pizazz.

5. Avoid coding puzzles

Click that "leave meeting" button when they ask you to code anything. If they want to judge your quality, they can read all of your blogs, review your sample projects from coding school, or take another gander at your resume. You even rated your skills on a 10 scale to make it easy to scan! Companies that don't read every piece of content by every applicant clearly have an understaffed recruiting department, and is that the kind of place you want to work?

6. Build a personal brand

Don't practice coding puzzles. You know what you know, you shouldn't have to "prepare" for an interview. Instead, tweet threads about how all those graph riddles aren't an accurate metric for evaluating you. You build a brand by sharing, not learning. All that engagement might get you leads! Besides, you wouldn't have dropped out of college if you wanted to study for quizzes.

7. Learn in public

After leaving a company, write a think piece explaining how you left a $100 billion company after five months because "there was nothing to learn there." Use that newfound free time to establish expertise by writing think pieces on how other people should be interviewing (#branding!). The comments Hacker News will surely validate your decision to walk away from a remote job with a six-figure salary.

8. Practice self-care

Quit jobs where they expect you to receive feedback. You're too stoic to be around that kind of negativity. Be sure to quit via text so you can post screenshots on /r/antiwork.

9. Stay up to date

Stay current via extreme onlineness. Follow people who work 45 minutes per week (never on Fridays!) and make $245,000/year (plus benefits!) Keep up with people on round 13 of their interview process and can no longer even. Reflect on how everyone in the tech industry is so great (source: YouTube) and so horrible(source: Twitter) in parallel. Reflect on why you aren't doing as good as everyone else seems to be, if things will ever get better, or if you'll ever stop feeling like an impostor. Wonder if making career decisions attempting to make your reality match the filtered artifice you see online was maybe not be the correct tactic.

10. Start a Substack

Newsletters are the new self-actualization.

Name Your Next Product With This Exercise

Glenn Stovall — Mon, 08 Mar 2021 13:20:52 +0000

How do you come up with a product name? or a business name? Naming products is a hard but learnable skill. There are agencies that provide names-as-a-service. ZinZin’s existence corroborates the idea that naming can be distilled into a repeatable process.

When you’re feeling stuck, it helps to have a process. Prolific creation is the play here: When you’re stuck trying to come up with a name, it’s easier to come up with 100.

This is my current iteration on a naming process. It’s based on prior work from The ZinZin Naming Guide, the article A Good Name Points to You from Ribbonfarm, and Jane Portman’s guide to Naming your next book.

After reading this guide, you should have a process you can use next time you are coming up with a name for your next product, website, article, or creative project.

Step 1: Create an 7-column table or mindmap

You’ll need somewhere to collect your ideas. Use whatever style works for you; I prefer mindmaps on paper. Y can use a tool like Coggle or a spreadsheet. Then, create 7 sections:

Similar products – names of competitive books, apps, whatever
Mechanisms – how your product works
Implications – what your product does
Consequences – the result of your product
Pain points – pain your products solve
Jargon – related terms from your audience that could relate to your product.
Metaphors – potential metaphors that you could tie to any of the previous 6

The steps here aren’t ordinal. You can bounce back and forth; ideas from one may inspire others.

Playing Creative Offense & Defense

On The Knowledge Project, Sendhil Mullainathan talked about the idea of creative offense and defense. Creative Offense is coming up with as many unfiltered ideas as you can. Creative Defense is filtering those ideas down into the best actionable ideas from earlier.

By decoupling your creative mind from your critical eye, you empower both to work at their best.

That’s the approach I’m recommending here: coming up with several names, then filtering down.

Step 2: Decomposition

Start by breaking down your product idea. How does it work? What does it do? What results does it deliver? You can decompose your product to fill out the first three sections:

Things decompose into mechanisms, implications, and consequences. The mechanism is how it works. The implication is what it does. The consequence is what it means for the lives of the audience you’re trying to reach.

Carlos Bueno, A Good Name Points to You, Ribbonfarm

Identifying these parts of your application will inform the mechanisms_,_ implications, and consequences sections.

Examples:

Mechanisms : S3, aka Simple Storage Service.
Implications : SentinelDB. The metaphor implies that it stands in front of your data, protecting it.
Consequences: Double Your Freelancing Rate. A crispy definition of what happens to your career.

Step 3: Research

Step two is to look inward for ideas. The next step is to look outward. What are others doing in your niche? You shouldn’t plagiarize, but you can get an idea of how your audience talks and use that data to come up with ideas you could connect with. There are three data points here: similar products, pain points, and jargon.

Similar Products – Start looking at naming schemas from similar products. For example, let’s say I was making a tech podcast. I see patterns of including “cast”, “show”, “podcast”, and “talk” in the name.

Pain Points – What problem does your product solve? You’ll see this technique often in book subtitles. For example, How to Do Nothing: Resisting the Attention Economy.

Jargon – How does your audience talk? What are their terms of art? When Adam Wethan & Steve Schoger named their book teaching design in developers, they were translators between two worlds. They need to describe design techniques in geek-speak. They landed on the brilliant moniker Refactoring UI.

Metaphors – New ideas are more resonant when you can connect them to existing ideas with your audiences’ minds. For example, Steven Pressfield’s The War of Art connects Sun Tzu’s classic work to the inner struggle of creative work.

Go through each of the sections, and come up with examples for each. Hopefully, one column will inspire another and give you plenty of creative clay to work with.

Step 4: Connect & Create

Once you have your ideas, it’s time to start synthesizing new ideas from them. Mix, match, combine and write down whatever comes to you.

Add a new section of your document, or start a new document.

Remember that you are aiming for quantity, not quality here. Go wide. Big, blue ocean thinking. The beauty of creative offense is that the quantity will get you to the quality.

Step 5: Filter & Decide

Once you have your name, it’s time to filter down into something that works. Maybe in the exercise, you came up with something that really makes your heart sing.

To help you decide, you could set some constraints on the name. This will vary depending on your niche and type of product, but here are some potential rules:

Can you get a decent domain? If you need a domain for the product, are you able to get one?
Is the name simple enough? Clear > clever. Will people understand your name? Is it too wordy, complex, or hard to spell?
Will it get you in trouble? Be aware that if your name is too inspired by a competitor, you could find yourself on the receiving end of a cease & desist.
Can you say it out loud? Call it word of mouth optimization. Imagine someone recommending your product to a friend. How does it sound? For an anti-example, see mmhmm.

You may have other constraints. Consider those and eliminate names that don’t work. Eventually, you should be able to find something that works. If not, you can always repeat the previous steps and come up with more ideas.

Did you come up with a good idea using this system? Let me know what it is over Twitter @GSto , I’d love to hear it.

The post Name Your Next Product With This Exercise appeared first on Glenn Stovall.

SaaS Under The Surface

Glenn Stovall — Tue, 29 Dec 2020 14:24:32 +0000

The Unknown Unknowns of Building a SaaS Application

Some vital parts of a sustainable software business easily get overlooked.

Building a Software-as-a-service(SaaS) is much more complicated than it looks on the surface. Creating a piece of software that you charge other people money for means that you have added an order of magnitude more complex than an application used for internal purposes.

SaaS products are like an iceberg.

The Application Lives Above The Surface

You see the core functionality and value at the top. The business value. The fun stuff. What people see and think, “This is it. Easy peasy.” When the truth is, the application is only what’s visible above the surface.

Service Code Lives On The Surface

Service code is the functionality that turns “software” into “software as a service: Authentication so people can log in, and billing so they can pay you monthly for the privilege. The happy path of these lives above the surface. What people tend to forget is all other administration parts of the features when customers run into problems:

How can users reset their passwords?
How do they update their email address?
Do you need to consider Two-factor authentication? some company have security policies which require that applications they use to have two-factor authentication, so this is something to heavily consider if you sell B2B software to companies of any scale
What happens when someone upgrades or downgrades their plan?
What if someone wants to cancel?
How do you handle refunds? No matter what you do, managing customers who want their money back is inevitable.

Under The Sea

Now we get to the boring but essential parts of running a SaaS. These services don’t tend to provide a lot of visual business value. But if they didn’t exist, a problem could cause your business to collapse. If you were running the kitchen on the Titanic, these would be the cleaning supplies and fire extinguishers in the supply closet.

Transactional emails – Transaction emails are emails that your application sends throughout the user’s lifecycle and use of the application. Examples include weekly summaries and confirmation emails. These are different and typically use a separate piece of software that marketing emails, such as newsletters—an often overlooked part of an application that can bring a lot of value. Emails are part of the user experience. You should be mindful of what emails, when you send them, and their voice and tone.

Monitoring -monitoring tools keep an eye on all the different parts of the system and collects analytics useful for understanding how everything works under the hood. Monitoring is useful for debugging issues and identifying opportunities for optimization.

Error Logging – If one of your servers when down, how long would it be until you found out? You’ll need a way to know when errors happen and how frequently they occur. Error logging keeps track of errors and can notify you of severe issues immediately.

A Staging Environment. Applications live in different environments . The live version of your application is the production environment or “production” for short. Copies of the code that live on the developer’s laptops are development environments. In between, you have something called “staging.” It’s an environment that mimics production as closely as possible with a different database. Use it to test features, research issues you found due to your error logging, and to demo upcoming features to customers before they go live.

Backups – You need a way to safely store and recover data if something goes wrong or you make a corrupting change to your database that needs undoing. When it comes to paying customers, two is one, and one is none.

Hosting – You’ll have to decide where and how to host your application. There are several options, but hosting is a more irreversible decision. Think long and hard about your hosting needs now and what they could be 1-2 years from now. A common choice is Amazon Web Services (AWS).

Analytics – You’ll want to keep track of how many users are using your application, as well as how they are using it.

Reporting – Analytics answers questions about using your application in a broad sense, while reporting is for drilling down. Think of analytics as the results of a poll, while reporting as the answers a subset of people gave in a survey. You’ll want to use data generating by your application to make data-driven decisions, and you can’t do that without reporting.

God mode – god mode is something that you don’t know you need until you need it. As the owner of an application, do you want to ask a developer to make a change for you every single time you need one? Here’s an example: a user mistyped their email and wants you to fix it. You didn’t build this into your MVP, but you could do it manually. A developer could manually access the database and make the change, but what if you had a simple interface where you could? Tools like active admin for rails are one example of tooling explicitly designed for admin panels.

Fortunately, Ice isn’t that expensive.

The one good thing about these under the surface problems is that everyone has them. These problems aren’t new, so there are several off-the-shelf solutions available.

Some examples:

Authentication – auth0 and AWS Cognito
Billing – ChargeBee, Stripe Checkout
Transactional Emails – SendGrid
Monitoring – AWS Cloudwatch
Error Logging – Rollbar
Analytics – Google Analytics and Hotjar

Building Your Iceberg

These service-level problems can either be solved by custom code in your application or by integrating with 3rd party services. Doing so reduces initial development costs but adds to monthly billing, dependency on a 3rd party for core functionality, and complexity to the system’s architecture.

Part of building a SaaS is deciding when to make the build vs. buy tradeoff when creating something valuable for your customers. Factors to consider when deciding when to build vs. buy.

The post SaaS Under The Surface appeared first on Glenn Stovall.

PR18 - Content creation & strategy w/ Stephanie Morillo

Glenn Stovall — Tue, 22 Sep 2020 10:00:00 +0000

Product manager and content strategist, Stephanie Morillo. Who's also the author of the developer's guide, the content creation and the developer's guide to book publishing, teaches us about creating more engaging content and more useful documentation.

Below are the show notes and transcripts for the episode. You can listen to the episode in full here: Content creation and strategy with Stephanie Morillo.

What did you think of the episode? Have more questions about content creation? Let me know in the comments below! 👇

Show Notes

Find Stephanie Online

Stephanie Morillo

@radiomorillo

More of Stephanie's work:

The Developer's Guide to Content Creation
The Developer's Guide to Book Publishing
The Pocket Technical Writing List (Includes style guides)

Links from the show:

Transcript

Glenn Stovall: [00:00:00] hey everyone. I'm here with product manager and content strategist, Stephanie Morillo. Who's also the author of the developer's guide, the content creation and the developer's guide to book publishing. Can you do today, Stephanie?

Stephanie Morillo: [00:00:11] I'm doing well. How about you Glenn? Pretty good.

Glenn Stovall: [00:00:14] And today we were going to talk a bit about writing and content strategy for devs, but to start, could you tell me a little bit about, what you do currently in your history as a writer and content strategist?

Stephanie Morillo: [00:00:24] Yeah. so I have been a writer for the bulk of my 12 year long professional career. I started in communications and marketing and around the four year Mark decided that I want to learn how to program. So I learned Ruby with the help of a friend spent about a year at it, just dabbling. it wasn't very structured.

It was like we'd meet once a week, once or twice a week. And I learned that way and, Through that I started working in tech, so I moved into the startup space. I worked at general assembly. and then. Over the course of my time there, I realized that I wanted continue working around developers, but I didn't want to be a dev.

So when I was trying to think, okay, what could I do? I decided to go into writing, thought technical writing would be my, the path that I would go on. So I was like, I really want to be a documentarian, the kind of person who's responsible for producing, highly technical documentation, but instead find myself in copywriting.

I was writing marketing and product carpets. Copywriting at digital ocean. And then just through them, I started moving up the ladder content-wise de content management did the same thing at Github. And then most recently I was a content strategist at Microsoft cloud advocacy team before pivoting completely.

And now I am a product manager on an engineering team here at Microsoft.

Glenn Stovall: [00:01:44] Oh, cool. Awesome. And what kind of content you said your documentation, what sort of content did you do over at get hub?

Stephanie Morillo: [00:01:49] So I did do documentation AdvocateHub at GitHub. I was responsible for managing the company blog. So I was essentially the managing editor.

I was. I was copy editing blog posts. I was managing blog operations, which sounds about as interesting as it is. at that time get hubs blog was actually built on Jekyll. it was hosted on GitHub pages. There was a lot of, a lot of having to ping site engineering, whenever something went down.

And then of course, China work with good hovers who were interested in writing blog posts for the blog. So I was constantly sourcing stories, trying to find interesting angles and things that the audience would be interested in reading.

Glenn Stovall: [00:02:29] Yeah. what were some of the interesting angles or kind of stories you look for at Github?

Stephanie Morillo: [00:02:34] I was at Github only for a few months before I moved to Microsoft. So I think the better. The better example would be digital ocean. I managed their company blog for over a year. and some of the stories that I published, one of them was, about how the company managed a go mano repo.

So one of the libraries, so basically the engineering team created a goal library that was open source and the whole thing was a mono repo. And I pinged one of the developers after seeing him talk about it in Slack. And I was like, Hey, would you like to write about it? He did. I pinged an engineering manager who had given a talk at Ashcon about managing a remote teams, got him to write something for the blog.

one of the internal infrastructure teams was doing something really interesting. They had an apprenticeship program where they allowed folks from other engineering teams at digital ocean to shadow infrastructure engineering there's to learn more about the organization. And then they actually took on some work.

So it was like a two week program. And the whole point was to help build out the infrastructure team and to get people interested in wanting to make a lateral move. So that was another story, but basically we ran the gamut. I published this, we published a story on. How one of the teams designed object storage.

So pretty much I trolled all of the Slack channels, seeing what the engineers were talking about. And I was just like, yo, you should write this as a blog post. And people were more than happy to oblige most of the time.

Glenn Stovall: [00:03:56] Awesome. Cool. And then how was, what was the goal at digital ocean? Was this just trying to build brand awareness and , get engineers more interested in digital ocean?

Stephanie Morillo: [00:04:07] So digital ocean actually had a very solid content pipeline on the tutorial side of the house. So digital ocean publishes a lot of open source tutorials on how to do anything related to cloud infrastructure. Obviously, digital ocean is generally the. The hosting platform that's used in a lot of these examples, but these are all just, how to create something with the modern stack on digital ocean or on Ubuntu or whatever.

And they managed to get a lot of brand awareness through writing those kinds of tutorials. The blog was actually a channel that no one really, it was like an orphan. Nobody really owned it at digital ocean and they were using it like to publish a. A product announcement once every two or three months or something, or, Hey, we opened up a new data center.

So the blog was pretty much. Nobody. Nobody knew what to do with it. Nobody had any, concerns or anything. So I was like, you know what, I'm going to take over the block and I'm going to do whatever I want with it. while most companies have a very solid strategy, they have very clear metrics.

they're trying to, they might not even, it might not even be like just generating awareness. There might be other objectives that they're trying to meet through blog content. I really wanted to tell stories about how the, how we got things done at DOE to get engineers excited about DEO as a company, but also excited about.

Seeing themselves a deal. I wanted engineers to write the kinds of stories that they as engineers would like to read. just to give people another look into the company. People really liked the products. People really liked the UX, but they didn't know much about us. They didn't know much about our internal teams.

And we had a lot of platform teams that were building tools for internal customers. And they didn't really have the opportunity to shop, shine or highlight what they were doing. So the blog was a perfect way to do that.

Glenn Stovall: [00:05:53] Yes, that's all it cost. It's definitely a frustration I've had before where you're building a building internal tools and it's I can't put this in a portfolio or anything.

and then you also do a lot of writing on your own.

Stephanie Morillo: [00:06:04] Yeah. Yeah, I do. I do. I've been blogging pretty frequently, I would say over the last eight to nine months. prior to that, I didn't, it's funny because I spent most of my days writing and editing that at the end of the day, I was like, I don't really want to write on my blog, but since I've moved into a new team, I've.

My blog is like my creative outlet. So a lot of the blog posts that I create are around, like some of the essentials of content creation. So I have blog posts on the introduction and introduction to technical writing, but also blog posts that explains, audiences, right? what's a primary audience.

And why would you want to write for them? I have blog posts on things like. why the developers not like soft? Why don't developers like marketing or, like writing internal documentation. So any, I look for angles that, basically we book for the kinds of things that engineers asked me about.

Or things that I've done that have helped me with my own work. And those generally are the, that's the fodder for a lot of my blog posts. why

Glenn Stovall: [00:07:11] don't developers like writing internal documentation?

Stephanie Morillo: [00:07:15] Because it's hard to get feedback from internal docs, right? Like you're writing until you write something in a Wiki and then it's in the either and you don't know whether or not anybody is actually using it or not.

So in that sense for a lot of people, it might be. Feel or seem like a time suck. and also because writing documentation is generally an activity that most people undertake at the very end of a project, as opposed to writing continuously while the project is going on. So it's almost like one thing you have to check off your list before the project can officially ship, which you know, it's not always the most fun, but it is.

In my opinion, some of the most valuable form of writing, especially when it comes to things like onboarding new people, training, new people, they want to be able to, and to be able to do that in a scalable way, it's not scalable to have, a bunch of training sessions with every single person that joins the company.

Or if you're trying to. Build out a huge team, like when you're thinking about scale. and yeah, and you're thinking about, and you're thinking about access. I think internal documentation is the way to go, but I understand the frustration with having to write it, if you're not getting feedback and you don't know if people actually find it useful, It can be, it can feel like an activity that you're just doing to check off some boxes.

Glenn Stovall: [00:08:28] Yeah. And that's something I've struggled with too. Or I, again, I've blogged in for, I don't even know how many years at this point, but that is something where someone's, that does feel like a bit of screaming into a void in the internet that you don't always get.

Stephanie Morillo: [00:08:42] Yeah.

Glenn Stovall: [00:08:42] Feedback or no, if the stuff you're doing is working or not.

So I'm curious in your experience, what, or how have you gotten feedback positive or negative from some of the stuff you've published

Stephanie Morillo: [00:08:55] in terms of internal documentation, or just general

Glenn Stovall: [00:08:57] documentation, blogging, whatever.

Stephanie Morillo: [00:09:00] I ask people when I, when I publish blog posts, I like to have conversations about it on my own blog.

I don't have Oh, comments section, but I tend to syndicate a lot of my blog posts on DEV community and DEV community does it does have a chat, a comment function. So I will generally ask people to share their thoughts. let me know if they have any questions and I will actively engage with each and every single comment.

So even if somebody is this is great. Thank you. I will respond. Thank you so much for reading. If people have questions, I'll try my best to answer them with internal documentation. I've actually not had a problem with it because I'm in a lot of my capacity over the last two to three years, it's been, I've been the only person in my function, or I've been responsible for doing work that plugs into other work streams.

So my documentation does get read. and the best example of that I have is when I was transitioning out of. The developer relations team and into engineering. I was able to train up the person who was gonna take over my position just on the basis of the kind of documentation that I created alone.

I did a lot of recordings. There were decks, but there were also long Wiki articles. and their manager said that it was the best transition plan that they'd ever seen because they had all of that reference material already. So I always try to. Basically communicate out documentation of people.

Internally. I have a question that I've already answered in an article. I will send them the article. People are like, great. This is awesome. It answers my question. Great. If it doesn't I asked what it's missing and then I'll try to incorporate that in the article.

Glenn Stovall: [00:10:32] That makes sense. And I'm curious about some of your tools and process.

what did y'all use it Microsoft for internal documentation?

Stephanie Morillo: [00:10:39] we use Azure dev ops, which is, which is our productivity tool. It's similar to JIRA. So we have, we have wikis internally and we use those heavily. So that's where we host all of our documentation internally.

And then I'm on the cloud advocacy team. We relied heavily on one note. So yeah, Microsoft

Glenn Stovall: [00:10:58] makes sense. And, I'll speak to you just to hear about your, both the tooling and the process for. How you're writing, write some of your blog posts and stuff now. And I know you touched on this a bit on your book, the developer's guide to content creation, but maybe you could walk the listeners through how you go from coming up with ideas to then ending up with a finished published article to, getting eyeballs and comments on that article.

Stephanie Morillo: [00:11:23] Yeah. There's I'll tell you this. There are a lot of different, there are multiple steps to getting there. I'll try to focus on some of the most top of mind ones. first of all, my first recommendation would be for anyone who's interested in writing a blog post to, work in time boxes.

So often I hear. From folks that they don't have the time to write, or they want to know how to find the time to write. I've seen folks work in 15 minute time boxes per day. I prefer the 30 minute time box. And I'll just usually schedule that in three to four times a week. It doesn't really matter the cadence, but just know that when you have that time box, that's when you're working.

Secondly, it's not just sitting down to write that's part of. producing a blog posts, the research and the refinement or editing phase after you write are also activities that are, part and parcel of the writing process. So think about it like, you're doing your front research, then you're doing the drafting and then you're editing before you press publish.

then I would say when it comes to ideas and if you've read a book before you'll, this'll be familiar to you, but. I find that there are four sources of finding content ideas. The first one is to write about things that, things that people come to you about or things that you feel really confident in that you're like, yes, this is something I want to write about.

The second, source of content ideas is look for existing things that you have that you can repurpose. So if you've written or if you've produced, I don't know, like a conference talk like a year or two ago on a particular topic. Maybe there's aspects of that talk that you can refresh, that you can then produce.

Similarly, you gotta mind basically you're mining existing content that you have to repurpose it and refresh it. the third source of finding a content idea. Is looking out for what people need. Glen, since you've done 30 by 500, you're familiar with sales Safari. And for a lot of folks who are on the call who don't know about buy 500 or sell Safari, you can think of sales Safari as a, like a research methodology.

you're the role of a researcher. And you're going to the communities online, where your audience lives. If you're a web developer, for example, and maybe you're targeting early career web developers, you might go to places like dev community hash node. Of course, Twitter. You might even go to, I dunno, free code camp, just to see what people are talking about, what people are interested in.

that kind of stuff. So you want to find out what people need, what questions are they asking? What are their pain points? Are there specific themes that I've identified here? And then that makes it's for really good content. And then lastly, the things that you, I want to learn, if you have a list of things that you want to learn and almost.

All of us do make a list of all those things and start writing about them. It's a great way for you to crystallize your own learning, for you to process your own learning and also teach someone who is similarly, a beginner in that particular concept, helping them walk through it. . So that's the ideation phase. and then, yeah, it's really just a matter of sitting down at a sitting down like. During your time box working at chipping away a particular topic, and then figuring out what your publishing cadence is. So if you're like, you know what, it takes me a really long time to write.

It takes me 20 hours to write. Maybe all you can do is one block. It was for a month and that's totally fine. As long as you commit to that one blog post per month. So I tried to tell folks, pick a cadence. There are four ways of finding content ideas. And create a time box and those are some basic ways to get you from ideation to published.

Glenn Stovall: [00:14:48] Yeah. so why is it, that, do you think a cadence is so important? Why not just write whatever? I think I have just whatever inspiration or the mood strikes me

Stephanie Morillo: [00:14:59] because. inspiration is a finite resource. I found oftentimes in my own work that I will have moments when I'm really inspired and I will produce something.

But then after that, I have a dry spell. I've seen folks who are really excited and enthusiastic and motivated in the beginning and they produce content. Really frequently, but then after two or three months, they've run out of steam and they don't have anything around. They don't have any, anything keeping them going.

So I think if we rely on motivation and inspiration, you'll find that you're only going to be able to do things in short spurts. And if you want to write or create content consistently, you have to push through the times when you're not actually motivated to write or when you're like. Or when inspiration strikes a lot of my blog posts.

it has, they haven't been produced necessarily because I felt particularly inspired. I was like, yes, I have amuse, and this is what I'm going to write about. it's frankly been because I have told them myself, this is, this is my cadence. Like I know that I need to produce one blog post per month.

So I know that's already a task that I've decided that I would do. So it's. For me, just a matter of finding the content that I want to write about and then spending the time to write about it. And I can do that. Whether or not I'm motivated to write or inspired to write, but I can produce consistently, which is important.

Glenn Stovall: [00:16:18] Yeah, I think it's, I think it is a thing. A lot of people get backwards that they think, you'll get the inspiration and then you'll get the motivation to do the work when it's actually often the opposite is you do the work and that's, what's going to get you the. Inspiration and motivation. Like a, one of my favorite books is the war of art, which I don't know if you've ever read it.

Stephanie Morillo: [00:16:38] I haven't read it, but everybody's mentioned that to me in more than one occasion.

Glenn Stovall: [00:16:41] I think one of my favorite quotes, the author of a story says, yeah, when I write, I'm just waiting for the muse to strike, but you can tell them, use them at my typewriter every day at 7:00 AM so that she knows where to find me.

Stephanie Morillo: [00:16:54] Yeah, that's a good one. And I think it'll help a lot of folks if they realize this, like a lot of authors or novelists, or just writers that we admire, we read the finished product and we assume that they are inspired all the time and they're motivated to write all the time. And every word that they produce comes up perfectly.

When in fact it's the opposite, it's really just sheer discipline and willpower that gets them through from that first draft all the way to a publish book and. During that journey. They're often working with other people to help them refine their content, make it even better. It's not, no one sits down and produces a perfect first draft, no matter.

No matter how talented the writer. So a lot of these writers, what they did, they create systems and processes. there's no shortcut to writing, but just sitting down and actually writing. And to your point and something you mentioned earlier, the more you do it, the more motivated you become and the easier it gets in that you don't feel like you're constantly pulling your own teeth just to find the right word every time.

even if you. Produce a first draft that needs a lot of refactoring. You still feel like it's not taking you as long as it did when you first started a blog maybe a year ago or two years ago. so I think it's, the more you do it, what you're actually doing is that you're creating quick wins for yourself.

Which then motivates you to continue, which, helps you stay on track.

Glenn Stovall: [00:18:22] Yeah. I love that you call it re factoring it too, because a good thing is if we're posting online, it's not like a printed book where you printed it. It's done.

I have very frequent, like I've written an article and then I get some comments or someone's Oh, you forgot about this.

Or. You didn't consider this case. I'm like, Oh, you're right. I'll just go rewrite that section.

Stephanie Morillo: [00:18:43] Yeah. Yeah. That's true. It's and the refactoring is true. Whether or not it's a print article. a printed article or not. with a printed article, it'll likely go through multiple rounds of editing.

So if you're writing for a publication, you'll have an editor and that editor will go through everything with a fine tooth comb. Just making sure that that everything looks as polished as possible. And. Before we publish a blog post, we should just, we should do that on our own. We should do some kind of refactoring on our own just to make sure that things look polished, that it's, that it's readable.

That it's understandable that it's something that a reader can comprehend. And of course, like you said, we always miss things. Like I will publish a blog post after having edited it a bit. And I'll always find a typo, or I might even find that I can say a sentence better. I can reword it, rephrase it. And it'll sound better and I'll go in and make the change.

And then, yeah. And people will say, Hey, by the way, I saw this, you might want to update that. And that's something that you can do quickly. So it's never just a finished static product, especially if it's online content. It's something that you can and should update and maintain.

Glenn Stovall: [00:19:46] so that companies will be sent melts.

I wanted to dive in a bit, when you were talking about ideation and reusing old content, that's doing content audits because that's a word I've heard a lot, but I've ever really been clear, like what exactly a content audit is, or if I wanted to audit. My own content, because like I said, I've been writing stuff for number of years. , how would want to approach a content audit?

Stephanie Morillo: [00:20:10] So it depends on the number. On the amount of content we're talking about. So I'll give you an example. When I was a writer on bumbler, so bundlers the dependency manager for the Ruby programming language, I was responsible for, managing their concent strategy for their online documentation site.

So I decided to do a content audit to better understand what content we had. What state it was in. we just, I didn't know what we had and, what I ended up doing was that I actually ended up downloading an SEO site crawler. So the site crawlers are really cool. They will. It sounds like what it is, right?

There's a spider that crawls your site and then it'll spit all of the metadata into an Excel spreadsheet. And the metadata that it usually grabs are things like the URLs, the page titles, header, tags, any other kind of meta-tags that you have in there? if they can find information about when this was last published or updated, that kind of thing.

So you use that almost as your. As your skeleton. And then what that allows you to do is to go through each piece of content, one by one to determine whether or not it's something that is, is something you want to keep. So you might actually want to use that site crawler. And then in addition to that, look at your site analytics data, and you might decide, okay, this is a, an article that I published in 2012 and it gets no traffic.

In fact, this is something that. This is the kind of content that I wouldn't even write about anymore. So you might want to decide whether you want to update it. you want to keep it as is, or if you want to remove it. So a content audit is you first, you're basically creating an inventory of everything that you currently have.

You're trying to understand the state that it's in. And you're trying to understand if this content is something that is actually not just driving traffic to your site, but it's something that's actually relevant to readers. I don't know, five years ago, maybe your blog focused on one particular topic.

And over the course of time, your audience changed. maybe you pivoted your business or something. And as a result, the content that you've produced over the last three years, it looks vastly different than what you produced five years ago. She made that pivot. You might want to say, I got to figure out what to do with all this older stuff.

It's still on my side. It's not really, it's not really doing anything. It doesn't matter if I keep it, but I really want to track certain kinds of and all of this old stuff is not really helping me. So that's what it is. It's just, it's an inventory. You're trying to go through, determine the state and determine whether it's something that is meeting either your objectives or your readers objectives.

It's very tedious as it's as tedious as it sounds. but it's, it's a worthwhile exercise, especially if you happen to have a big blog or a big website.

Glenn Stovall: [00:22:45] Yeah. Okay. Yeah, that makes a lot of sense. So just going to inventory and figure out. Where to go from there. And that's something else I've wondered too, is about content strategy, which is another word I hear thrown around a lot at night and be particularly curious.

I know you've done a lot of work at big companies, but how you see content strategy, big companies, and also. if I'm just an independent developer and I want to start a personal blog, how much should I think about content strategy? What would that look like?

Stephanie Morillo: [00:23:14] So content strategy, a definition that I like that was coined by a content strategist named Christina Halverson is that content strategy is the planning for the creation, maintenance, and governance of useful and usable content.

It's not the same as content marketing. So content marketing is, our. Art is content that is created specifically to, to, to like address or attract, a customer need on a site. if you're trying to attract a specific type of customer, you're trying to get them into your funnel.

You might use content marketing to address that, so that customers at different stages of the funnel, you're trying to get them as close as possible to like the purchase decision. Content strategy is. All is looking at content really holistically. It looks at your product content. It looks at your marketing website.

It looks at everything that you have that is meant to be consumed or used by users and trying to determine whether or not it's actually aligning to a need. So content strategy is important because it asks why. Why am I doing this? Why am I creating this video? Why am I creating a podcast? Does this article actually fulfill a need?

And it's, in that sense, okay. For a larger company, as you might imagine, concent strategy can be quite a beast. universities have concent strategists, and they're wrangling sites that are like 20, 30,000 pages, deep trying to determine whether or not. the content is find-able, people can find it, people can use it, that it's actually relevant to them, but for somebody such as yourself.

So you're. you're an individual developer and you're a business owner, right? You're a freelancer. When you're thinking about content strategy, you might want to think about things like what kind of content channels do I want? So one thing that we, it's not unusual, it happens to all of us is that we jump on the shiny new toy.

Thinking that, Oh, maybe this is a way to attract an audience. I've seen people create podcasts because that's the du jour thing to do or create a screencast or to start Twitch in addition to blogging. Now, while that might be tempting for you, as a freelancer, you want to, you shouldn't do that. This is where constant strategy comes in. You shouldn't do that without really understanding if this meets the needs of your audience. Is it something that your audience actually wants? And thirdly, if you can actually. Maintain the thing. Is there a governance model around your Twitch stream, your, this, that, and the third, because if you find that you are overwhelmed by all of these different types of content that you're creating, then you like, what's the plan for maintaining it and keeping it going over the long haul.

So it might be things like. Okay. I need to determine what specific types. So if content I'm actually going to create, so I don't know the nature of your business, but for my business, I try to focus it on content strategy, content creation, writing, things like that. I'm not going to talk about.

I'm not going to talk about visual design. I'm not going to talk about, I don't know, I'm not going to talk about, engineering management, because that doesn't align with my goals, As a business owner, but also what my audience needs. They don't need that for me. There are other people that do that, but what they do need from me are the things that, I've carved a nation.

So that's what you have to think about is You don't want to create content for content's sake. that a lot in content marketing. it's not everyone that does that, but that a lot, right? Oh, for SEO, we're just going to write like this beginner article. That's great. But is that something that people really need from me?

Are you actually addressing what they need? So your goal is to understand your user very well to know how to find out what it is that they need. From you, even if they can articulate that yet, and for you to present that solution and you're doing that, and you're trying to be as relevant and as close to the customer or the user as possible, as opposed to just blogging about like how beautiful the dandelions were outside and have that live aside, Next to a blog post that you're writing about JavaScript, for example, huh?

Glenn Stovall: [00:27:10] Yeah, it makes a lot of sense. I think a lot of people hear blogging and they think about how some people do it or how it used to be like very early in the internet where it was just like, literally like my journal, but I'm going to publish it.

Stephanie Morillo: [00:27:24] Where now it

Glenn Stovall: [00:27:24] can just be, it could be something where, like you said, you can build up a brand, build up, help serve an audience, actually help people. And actually, could be something that if you're strategic could help you improve your business or career.

Stephanie Morillo: [00:27:39] Oh yeah, absolutely. I think, Early on in the internet, it was very much like a journal, Blogging was like a journal and it was like a trash can for all of your ideas. if you're, and it's not just if you're trying to build a business, but if you're trying to use your blog as a way of getting people to know who you are, what you're interested in, staying as close to staying.

Basically staying as close to topic to your main topics as possible is important. So one thing that I'll do, for example, with if we look at a content, got it, I'll go through my blog and I'll look at the blog posts that I've written in the past. The ones that high-performing the ones that aren't, and I will actively unpublished blog posts.

I've done it, especially because you know what I cared about, what I was interested in three years ago, doesn't necessarily all of it doesn't necessarily apply to what I'm trying to do today. So I want to make sure that the content that I do have there, all of it is useful no matter when it was published.

And that it's something that aligns with. With my brand, with my messaging, with my value proposition. if it quantity, isn't the thing with content strategy or even with blogging today is that I really believe that it's not about quantity, that it really is about quality. And for you to get to that quality, you just have, you have to know your audience very well.

And what your value prop is.

Glenn Stovall: [00:28:57] So that led to another good question. What would you say are some of the things that. Can differentiate between low quality and high quality content.

Stephanie Morillo: [00:29:06] Yeah. Low quality. as when it comes to writing or anything content, it's all really subjective, right?

Like it's hard to, there aren't any hard measurements. but I think that there are specific aspects of writing that. That can for example, like posts that, that don't have any structure, that to me is something that's indicative of low quality or something that reads like it was stream of consciousness, where there are a lot of typos where, there are missing steps.

What that indicates to me is that the writer, was that the writer did not spend enough time after the initial drafting phase, trying to make sure that. What they created was something that was, that could be readily read it readily consumed by a user readily consumed, sorry, by a user. I find that posts that have been written really quickly where people don't check for like basic spelling or grammar, where you don't find headers or where the writer doesn't indicate what kind of, prerequisite knowledge somebody needs before they look at the article that tends to signal, something that, that was just quickly put together and put out.

So I always, I really strongly advocate that a lot of writers, They have somebody, it could be a friend even review a post just to help you get the perspective of the reader. what was somebody who did not know anything about what you wrote? How would they react to this if they were looking at it for the first time?

And I think that's an important thing for the writer to keep in the back of their mind. Oftentimes writers are very much in with reason, consumed with actually getting their thoughts to paper that they, are, they don't have enough. They don't actually save any kind of mental bandwidth to think about what this looks like.

From the readers perspective and getting someone who is looking at it with a fresh set of eyes, I think lends a lot of value and can actually help you improve your quality because they might not just spot typos and stuff, but they might actually find that you're missing information. That's crucial for the reader.

There are areas that are not very clear at all, that they were very confused by or frustrated by what you're trying to do is limit the distractions in your piece so that someone can read it and comprehend it and do whatever it is that you want them to do, which is why they're reading it. So if you're creating a tutorial, And it's hard.

This is easier said than done. You basically want to make sure that the writing you're creating, you're not actually creating any obstacles or roadblocks. You're trying to remove them through the course of the piece. those are just some things formatting and stuff like that.

Glenn Stovall: [00:31:50] that makes a lot of sense or like that model of removing the distractions and removing the roadblocks.

who are some writers that you read a lot, that you find that you are really enjoyable, that really inspire you?

Stephanie Morillo: [00:32:04] Wow. Any kind of writers or folks in the tech space,

Glenn Stovall: [00:32:06] any kind of writers,

Stephanie Morillo: [00:32:08] I'm a big fan of Paul Ford's writing. Paul Ford wrote the, the Epic article. What is code five years ago and Bloomberg.

And any time I read his writing, I quite enjoy it. the folks at his agency, pulse light, I find that they write really great content. That I enjoy reading. I enjoy reading a lot of Amy Hoy's writing. It's a lot of personality in her writing. And I find that her writing is very conversational, which is excellent.

It takes you, it's like it's a narrative. A lot of her writing is very much a narrative structure and it's almost like she's talking to you. And she does that in a way. That's really excellent in terms of. Technical content. they're not specific writers, but specific companies that I like. I really like mode analytics.

I looked at mode's SQL documentation a few months ago when I was trying to learn SQL myself. And I found that there, their cul basics tutorial was just fantastically we're in. And I felt I. Understood a lot of concepts that I had trouble understanding with other tutorials with them. And I will always go back to digital oceans tutorials.

I haven't worked there for two years, so I have no skin in the game, but I will tell you that their technical writing is absolutely top notch. and I always point people to their writing.

Glenn Stovall: [00:33:22] Yeah. And I th I think it's in your book. We'll include the link here. I think they have some guides on how they ask people to write.

There are two doors lock invitations that you can use yourself, which are super helpful

Stephanie Morillo: [00:33:34] for sure.

Glenn Stovall: [00:33:35] Yup. Something else I'll throw out to the user. There's a lot of companies out there you can find they'll have some documentation on their writing or their style guides to, do they use internally?

I know, I don't know if it's still up. I know MailChimp has a, they had a style guide up. That was a really fascinating, great it's incredibly well thought out and they're known for it.

Stephanie Morillo: [00:33:57] Yeah, it was the MailChimp content style guide. And that was a, that was actually considered like a, like the golden state standard, even if for a lot of content strategists because of the, just the nature of their style guide and how they broke everything down.

the fact that they made that available to the public, which is also really awesome. It's a lot of times companies will make style guides proprietary and they'll keep it internally. So it's nice to see how other companies approach their style guides. in terms of like technical documentation, get lab also PR also publishes their style guide.

Microsoft does, and Google also makes their technical writing style guide available to the public. So there are quite a number of style guides out there already that. Are awesome for folks who are just trying to understand the, or see some examples of really good writing and apply that in their own writing.

And the great thing is that because they make it available, you can apply those same, those same concepts and those same writing styles to your own work.

Glenn Stovall: [00:34:55] Yep. Sounds good. All right. we'll, for the listener, I'll be sure to dig up as many of these as I can. We'll listen to them all be in the show notes and also that Stephanie, people want to find out more about you and what you're doing, where can they find you online?

Stephanie Morillo: [00:35:06] You can find me on Twitter @radiomorillo that's R our ADI O M O R I L O. And you can find me at stephaniemorillo.co

Glenn Stovall: [00:35:14] Alright, and then, did you have anything else you want to plug at this time?

Stephanie Morillo: [00:35:18] Nope, that's about it. I'm always welcome to. Chatting with folks online. So if you have any content questions and such, please feel free to reach out to me, I would be happy to help.

All right.

Glenn Stovall: [00:35:27] Sounds good. Thank you very much.

Stephanie Morillo: [00:35:29] Thank you.

How to decide when to build software vs. when to buy

Glenn Stovall — Wed, 19 Aug 2020 07:38:00 +0000

All software choices fall somewhere on the build-buy spectrum, & all companies fall somewhere on the ‘tech company’ spectrum. A piece of technology’s ubiquity, price, and proximity to a company’s core competency all play a factor in where it fits on this spectrum.

In this article, you’ll learn about what factors go into a build or buy decision, so you can make a more informed choice that fits your company’s needs.

The far ends: clear buys and builds

On the far end of the “buy” spectrum is software that is relatively cheap and solves problems that most businesses have, like GSuite and Microsoft Office. It would not make any sense for, say, a logistics company to build a word processor.

On the other end of the spectrum, we have software that solves unique problems and adds business value. These are clear builds. If that same logistics company had a unique process that enabled them to process deliveries more efficiently, and therefore provide better rates to their customers, it would make sense to build software for their process, since an off-the-shelf solution by definition could not exist.

In the middle: consultingware and integrationware

In the middle we have solutions built on customization and integration.

Some companies sell “ consultingware “, software that has a cheap base price, which is then used as a platform for the company to build more expensive custom software on top of for you. This is what I did at my first salaried job after college. The company would sell $5,000/year licenses for a bare-bones platform. Then the salespeople would talk them into custom-built add-ons for an additional $25,000 – $50,000.

Next, is solutions built around integrating several other off-the-shelf solutions that can work together. Then, closer to building your own software, you build and own custom integrations that interact with an off-the-shelf solution in particular ways. Look at an agency like 6kites or neurored to see an example of a company that deals with this kind of work, which I’ll term “ integrationware.”

Both are a mix of buying something that already exists, and then “buying the building” by hiring a 3rd party to do additional work on top of that.

The key difference here is ownership of the software. In consultingware, the company maintains ownership of the product, and sells licenses with an audience of 1. With integrationware, you typically own part of the platform, which integrates with an external service.

At the ends of the spectrum, the decision is easy: It makes no sense to build your own generic solutions, and you can’t buy solutions that don’t exist.

Where things get interesting is in the middle, and deciding where in the middle you fall. It’s usually not a question of “build or buy” but how much of the solution needs to be built vs bought?

Example: Should a restaurant bake or buy dessert?

Photo by American Heritage Chocolate on Unsplash

Imagine running a restaurant and deciding how you are going to serve dessert. You could buy pre-made cakes from the frozen food section. You could partner with a local bakery and sell their product. If you have in house baking expertise, you could buy eggs, flour, and sugar and bake them in-house. An extreme take on the “from scratch” cake would involve adding a farm to your restaurant, where you can raise egg-laying chickens and grow your own grain.

If you think that the last example is unrealistic, let me introduce you to the pizza farm.

Factors to consider:

Available Resources

When you have more internal IT expertise and less available cash, building solutions makes more sense. You’ll lean towards buying when the inverse is true. When you’re company doesn’t have the internal IT resources needed to build software, you either have to bring in outside agencies and contractors, or increase that competency by hiring new people.

Risk

When you buy software off the shelf, the most significant risk is the death of the vendor relationship. When you build software internally, the most significant risk is failure to launch. Once you buy an off the shelf solution, you have some vendor lock-in. That means you have taken on some risk with that vendor, and have to consider the possibility that one or more of the following possible:

The vendor goes out of business.
The vendor decides to stop supporting the software.
The vendor is acquired, and the service agreement changes drastically.

You can avoid this by building software you have total ownership and control over, but that comes with not only costs, which we’ll get to in a bit, but also its own set of risks.

The project is never finished.
The project takes longer than expected.
Requirements aren’t clear, and the project doesn’t deliver the results needed.

One puts the risk internally, the other puts the risk externally. Also consider that if you hire a 3rd party to build your internal tool, you can end up in a situation where you have the risk of both .

Total Cost of Ownership

This can be the most difficult one to determine. That’s one of the strengths of going with a pre-built solution, is that you know what you are getting and when you can get it. When building your own solution, both of these are known unknowns. While there are ways to reduce the risk and variance in a software project , you can’t fully eliminate those problems.

When you own your own software, there are some costs that may not be immediately apparent:

Hosting
Security
Maintenance
Backups
Just to name a few

Bought solutions can also have some unpredictability in pricing. First, there is negotiating with the vendors, which could land you a deal based on how long sign up to use the service.

Then you have to consider the unit of measure that determines the price. For example, Slack bills on a per-user basis. How accurately can you estimate how many people be working at your company for six or twelve months from now? You probably have some idea, and can gauge how much it will cost. However, if the pricing unit of measure is something out of your control, like website traffic, you could end up with an unexpectedly high bill.

As a general rule, the cost of ownership of maintaining software that you actually own is going to be higher. But at some points, that may not be the case. You could end up paying for 100% of a solution where you only need 20% of the features. That coupled with the extra time trying to figure out how to get a generic solution to fit your specific requirements and processes.

Time to Launch

How quickly do you need a solution?

As a general rule, buying off-the-shelf software is faster than building something yourself. As another general principle, there is a time-value of software : Solutions you have today are more valuable than solutions you have tomorrow.

However, with building software, the time to value does not have to be binary. The software can deliver partial value over time if you are doing it right.

Accomplishing this requires a developer or team that understands the difference between building half-products and half-assed ones. Software is never done and typically turns into an infinite project, living as long as the business itself.

Scale matters here as well. Sometimes a script knocked out in a day can be more efficient than integrating a 3rd party tool that takes weeks of configuration and importing to start delivering value.

Core Competencies

The closer the solution aligns with your core competency, the more sense it makes to build something yourself.

How closely does the solution line up with your core competencies? Will building custom software give you a competitive advantage, and increase the value you can deliver to your customers? How quickly and with what quality can you actually build the thing? If you can answer yes to one or more of these, then you may have a case for building a custom solution.

For example: banks and telecom companies. They have unique needs, and building custom internal solutions make sense. But most companies have technology as part of their offering, so at some point, building your own tech is inevitable.

Business Processes

Your technology is only as good as your workflow.

How unique are your business processes? You have to have alignment with your processes, and commercial off-the-shelf tools. When building software, getting alignment should be easier, as you can make all of the design decisions.

If there are several off the shelf options available, and none of them match your business practices, that could be a sign of process smell. If everyone is doing everything differently than you and you cannot identify an advantage to your unique approach, then there may be room for optimization in your own processes.

Adopting a new tool alone can’t change your business processes, but it can help.

The scale of your company matters as well. The larger your company, the more complex building a solution is. When you are smaller and more niche, You can build products faster.

Before making a buy or build decision, consider how the software would affect your day-to-day processes.

Finally, tackling the decision

If you find yourself having this conversation at your company, that’s a good sign. It means that your organization doesn’t have “not invented here syndrome“, and that it is willing to look at multiple options for solutions.

The answer depends on your stockpile of resources and your risk tolerance. Do some homework and try to figure out what solutions are available, and what the total cost of ownership would be. Regardless of what direction you decide to move, these are typically decisions with real ramifications in your business. New technology requires integration and buy-in; you want to make sure you are making the right decision before moving forward. Here are some questions to ask yourself when considering whether or not to build or buy software:

How much are we looking to invest in this solution?
Do we have the IT resources in house to build and maintain a solution? If not, could we get them?
Would the technology affect the value we deliver to customers? In what ways?
How willing are we to change our processes to better fit into commercial off-the-shelf solutions?
What is this solution going to look like in 12 months? How will it be better? Worse?
How urgent is the problem?
What features do we not need? How does an in-house half-product compare to a feature-rich generic solution?

The post How to decide when to build software vs. when to buy appeared first on Glenn Stovall.

Stop fighting holy wars

Glenn Stovall — Fri, 31 Jul 2020 11:37:55 +0000

There are many “holy wars” in tech, and you’d be best served to stop participating in them. These discussions are bikeshedding: Spending an outsized amount of time and energy on trivial details. And when talking in public, they don’t paint you in a good light.

In sport, they can be fun. However, I think getting involved in them, especially in public online spaces, can be detrimental to your career.

The developers that spend time talking about these issues are not the developers that get the opportunities to work in a higher context. As Patrick MacKenzie says, don’t call yourself a programmer.

Here’s a list of conversations you should avoid, both online and offline.

The Ban List

Is HTML/CSS/SQL “coding”?

Yes. They are all Turing complete. It doesn’t matter if they aren’t. Instead of focusing on what “real coding” is, focus on how people use tools to solve problems. Excel isn’t “coding” but there are sheets out in the wild worth millions.

Is Frontend or backend more difficult?

This isn’t a video game, and you don’t get points for playing on a higher difficulty level. Backend developers have to think more about scalability and security, while developers on the front lines have to work in the wild west that is every conceivable browser and phone.

Tabs vs. Spaces

The “oxford comma” of software development. Most text editors and IDEs can abstract this away from you. Get your team to agree on something, and stick with it. “What I prefer tabs but the rest of the team prefers spaces?” Then you use spaces.

snake_case vs. camelCase

Same as above. These are the types of syntactic decisions that don’t affect readability or maintainability. As long as everyone agrees, either one is _fine. _

when to squash and rebase commits

I’ve honestly looked at a git history maybe half a dozen times in my career. So long as the code works and is delivering value, I have no interest in the structure of that code’s origin story.

Vim vs. Emacs

Use whatever tools you are most comfortable with, and let others do the same in peace.

My Framework/Language/OS of choice is better than yours.

Do not identify with a technology choice. Frameworks come into fashion and fall out. Like code editors, use what you like and allow others to do so in peace.

That Framework/Language/OS is garbage! Why would anyone use that?

A more negative framing of the issue above. JavaScript, WordPress, and PHP are the most common targets. Why do people still use these tools if they are so poor? Because they get the job done. Let the people using these tools continue to get the job done.

“Rails is dead”

The shortage of COBOL developers in 2020 proves that no technology is ever truly dead. Tell Airbnb, Shopify, Twitch, and Github that Rails is dead. A language’s popularity does not correlate to its quality. People still use Rails (and COBOL) because it gets the job done.

What to do Instead

I would make an exception if someone, especially someone more junior asks about these in good faith. On Reddit, Twitter, with random people is not the place to debate. It’s rare that you’ll actually change anyone’s mind on one of these issues. In the worse cases, you’re tearing someone else’s work and worldview down. Treat these conversations as profane. When you see them, walk away.

Instead of trying to persuade people, invest time in teaching them.

Instead of tearing other people and tools down, build other people up. Go give a shoutout to a manager about a co-worker, or tweet an article you found interesting.

And if you have a suggestion for another argument I should add to the banned list?

The post Stop fighting holy wars appeared first on Glenn Stovall.

What have you always wanted to ask a recruiter but couldn't?

Glenn Stovall — Thu, 09 Jul 2020 11:51:25 +0000

Hey everyone! Is there anything you've ever wanted to ask a recruiter, but you didn't because of how it might affect the relationship? Or maybe its because there wasn't a good time or place to ask. Well, now's your chance.

I host Production Ready, a podcast that helps developers grow their professional skills. We're doing an "AMA" with a recruiter in an upcoming episode, so now's your chance to ask those questions!

Some questions I've been thinking about:

How much do you get paid per hire?
How often do developers go "around" you, and try to get the job themselves?
Do people actually accept jobs at companies not knowing what company they are?

I'll be sure to give you a shoutout if we use your question.

What do you want to ask the recruiter?

My best developer interview experience

Glenn Stovall — Thu, 02 Jul 2020 11:57:53 +0000

There are many less-than-ideal practices when it comes to interviewing software developers. Some people give whiteboard interviews, which treat your craft like trivia and put you spot. Others provide you with take-home projects that can seem like free labor. Developers looking for work don’t have time to spend 5-10 hours working on a project that only one company will see. In the worst cases, candidates write code, and then the interviewing company uses it in production without compensation.

I read frustration online, but I don’t see a lot of positive experiences. I wanted to share the best interview experience I’ve had, as I feel it could be a model for companies to both accurately gauge developer’s skills while treating them fairly.

Step 1: Minimum Viable Contract-to-Hire

After an initial interview, the company offered a small project. It didn’t require any development environment other than a static HTML page. The estimated time for the effort was one hour, and the elapsed time for completion was three days. Within this timeframe, I could complete the work without pressure while still showing that I could stick to deadlines.

They paid me $100 for this.

The company understood that developers are busy and should deserve compensation for work. The requirements were clear and overly specific. It was more akin to a hack you would in place for one ornery customer than production-ready code.

I was freelancing at this time and considered mass applying to jobs to land several tiny gigs.

Step 2: On to the written portion of the exam

The second part of the assignment was writing a 2-3 paragraph essay about how I would approach generalizing the feature and turning it into extendable, usable production code. In addition to testing that I could think about writing quality code and software architecture, this part also gave me a chance to display my writing and communication skills. Writing a clear summary of an idea is closer to what you’ll be doing at your job than a coding exercise written with a marker.

The result

While I didn’t get the job, I left feeling great about the people, the company, and the interviewing experience. I think one reason we struggle with interview processes is that unlike other parts of working in software, its much less open. I hope that by sharing this experience, I give some other companies some ideas on how to improve their processes.

Shorter professional dev thoughts available on Twitter: @GSto

How software can be racist (and what you can do to stop it)

Glenn Stovall — Tue, 16 Jun 2020 16:19:58 +0000

Quick top-hat: This article originally appeared on glennstovall.com; You can also listen to this essay on the Production Ready podcast.

Software is powerful and can shift the balance of power in society. Look at how social media has impacted how we talk about politics, and everything else for example. If politics is the negotiation of power in society, then software is inherently political. If software is powerful, then we, as people who make software, have power. Software can be racist, and as software developers, I believe we all have a responsibility to use our power to prevent racist software from existing.

If this topic makes you uncomfortable, I ask that you don’t stop just yet. Pause and ask yourself why you feel that way. We all have decisions we have to make, and these topics are unavoidable. Get comfortable being uncomfortable.

Part of why conversations about race are challenging is that we aren’t working from a shared vocabulary. So, I want to clarify a few terms upfront. I’m borrowing my terminology here from White Fragility: Why It’s So Hard for White People to Talk About Racism.

The difference between prejudice, discrimination, and racism

Prejudice consists of thoughts, feelings, and generalizations based on little to no experience and then projected onto a group of people. Everyone has prejudices, whether its against people of a certain race, gender, where they are from or where they went to school. If you deny that prejudices exist in others or yourself, then you are powerless to correct them. Prejudice is internal.

Discrimination is an external action based on prejudice, including ignoring, exclusion, threats, ridicule, slander, and violence.

What distinguishes Racism from discrimination is that it is backed by legal authority and institutional control. It comes from a system of power that acts independently and above the actions of any individual, company, or piece of technology.

Racism is hard to define and hard to talk about. It isn’t just people in white hoods committing acts of violence. It’s complicated, and it’s vague. You may imagine “racist” as someone who openly does and says things targeting people. But racism doesn’t have to be overt. It can be subtle. It can happen unintentionally. That’s why it’s easy for people in places of privilege to ignore. Like prejudice, if we don’t do work to acknowledge, identify, and talk about racism, we can’t do anything to stop it. “The greatest trick the Devil ever pulled was convincing the world he didn’t exist.”

Any act of discrimination that props up this system and maintains it as the status quo is de facto racist. Understand when you work on software, it could be racist, and you have a responsibility to prevent that from happening.

How can technology be racist?

When we build software, we make conscious and implicit choices about how we imagine the end-user, what data we will use, and how the algorithms work. Since everyone has unconscious biases and prejudice, there is a possibility they influence said decisions. Coding biases into software is known as “algorithmic bias.” This bias is most apparent when we look at attempts to use machine learning classification algorithms on other people, such as facial recognition.

When engineers on the Google photos team built a system to tag photos automatically, it tagged black people’s faces as ‘Gorilla’ or ‘Chimp.’ Google’s response was to remove those words as valid tags instead of fixing the root cause.

In her TEDx talk, Joy Buolamwini speaks about the discrimination she faced using facial recognition software. It couldn’t recognize her at all. Joy ran into this problem with multiple systems. She discovered they were all based on the same open-source libraries and data sets. I’ll give the developers that built these tools the benefit of the doubt and assume they didn’t mean to create software that ignores black people. But it doesn’t matter. In this situation, the outcome is more important than the intent.

Software can also enforce existing discrimination polices. If your company has a history hiring people of a particular race or gender, and then use their resumes as training data for software that judges incoming candidates, you’ll end up with a system that has the same prejudices. Amazon did exactly this when they built a system that discriminated against women in the hiring process and later faced legal action because of it.

Police departments have used a software tool called Compas before that claims it used to identify suspects and predict recidivism rates. Studies show that it’s not only more likely to be incorrect about black suspects but more likely to be used against them. Here there is discrimination not only in the software itself but how the customers of the software use it.

Racism in software can also take the form of digital redlining. You abstract away discrimination by making decisions based on zip code. Delivery services such as Uber Eats and Doordash are less likely to service predominately black neighborhoods. Those neighborhoods, on average, have fewer Pokestops in Pokemon Go. The data doesn’t have to include specific data points about race to disproportionately affect people of race. Machine learning is all about finding patterns, after all.

See how it works? When the data doesn’t explicitly involve race, everyone who built these systems is allowed to either remain ignorant or has plausible deniability about how their software might affect minorities. We have to assume that what we build could potentially have negative consequences.

Software can’t abstract away the humans behind it

We can’t hold on to a romantic view that technology is purely logical and immune to humanity’s shortcomings. We can’t assume that since computers don’t think and feel, they can’t be biased. Or that we can overcome our biases by being “data-driven.” Our biases shape the design of software, and that software repeats our mistakes. Data can never be entirely objective; our biases, which bears repeating, everyone has, will seep in via decisions influencing what data we collect, what data we ignore, and how we interpret it.

Technology is a reflection of who builds it.

According to a 2011 study by the National Institute of Standards and Technologies shows that facial recognition software built by Asian software companies was more likely to be accurate at identifying Asian faces. Who creates the software has an impact on how it works.

More diverse teams equal fewer blind spots and fewer errors like the ones above, making it to production, or worse, the news. Diversity is a competitive advantage. Creating a more diverse team isn’t about doing it to be “fair”; it is about bringing more information and insight to that table than homogeneous teams can.

As Rachel Goodman, a staff attorney for the ACLU’s racial justice program, told Fast Company: “Many of the ill effects are not intentional. It comes from people designing technology in closed rooms in close conversations and not thinking of the real world.

Do you remember Tay? Microsoft’s attempt at an AI-powered Twitter bot? In 2016, Microsoft launched a Twitter bot that would model its behavior based on the tweets of people that interacted with it.

I bet you can guess where this story is going.

“Tay is designed to engage and entertain people where they connect with each other online through casual and playful conversation,” Microsoft said. “The more you chat with Tay, the smarter she gets.”

You can’t invite a group of people to do anything on the internet, without attracting trolls. In less than a day, Tay was spouting rhetoric about how “Hitler was right” and “9/11 was an inside job.” Microsoft has to shut the project down in short order.

gerry

@geraldmellor

"Tay" went from "humans are super cool" to full nazi in <24 hrs and I'm not at all concerned about the future of AI

05:56 AM - 24 Mar 2016

This story is more of a warning of giving trolls opportunity than anything else; the main lesson still stays the same: artificial intelligence only knows what we tell it, and only acts based on our instructions.

As software developers, what can we do?

Systemic racism is complicated and insidious. It doesn’t come from one place. It comes from everywhere. It happens automatically from systems put in place before we were born and continues to spread through American society through hateful acts and maintaining an inequitable status quo.

As software developers, we can shape the tools that directly impact people’s lives, or if they get built at all. This power means that we have a choice to make: Are you going to take action, or are you going to be complicit?

There are no two ways about this decision, nor is there any avoiding it. The work you do has an impact on the world, full stop. The nature of that impact is up to you.

Outside of your job, there are actions that anyone can take, regardless of job title. Get out in the streets. Donate your time or money. Vote.

As a software developer, you can advocate for change at your job. We need to be more skeptical of our data sources and cynical about the use cases and effects of what we build. So you should ask yourself:

Are the data sets you are using accurate? How can you be sure?
In the worst-case scenario, are there ways our software could disproportionately impact a specific group of people? (This includes accessibility, by the way.)
Do we hear a diverse set of voices, both before and after building our product?
If you are a manager, are you hiring a diverse team? And if not, why not?

These are the types of questions we all need to be asking more. Technology is not amoral, and it is not apolitical. Despite all of these stories, I still believe that’s influence can be used for positive change. But that can only happen if we collectively start doing business differently than we have up to this point. So I’d like to take this opportunity to ask you:

What are you going to do differently?

Quarantine work is not remote work

Glenn Stovall — Thu, 23 Apr 2020 20:07:30 +0000

I’ve worked remotely for nearly a decade: Either self-employed or at a job, it was always completely or partially remote. I can count myself as blessed during the current situation; I have a full-time job in an industry that hasn’t taken much of a hit. My job, knock on wood, is safe. I know others haven’t been so lucky. People are moving to remote work unprepared and without a choice. That is if they still have work at all. If you’re someone who has been working remote for a while or if its new to you, your problems may not be as big as others but that doesn’t mean they aren’t real.

Working from home, even in the best conditions, comes with trade-offs. Without systems in place at a personal and organizational level, during a global pandemic, it stinks. People are stressed, burned out, and finding it difficult to get work done right now. It isn’t remote work itself and isn’t you. As someone with nearly a decade’s experience working from home, I can tell you with confidence that this is different, even though my day-to-day job hasn’t changed at all. I’ve been feeling more stressed, burned out, and struggling to be as productive as I did before. And I know I’m not alone.

// Detect dark theme var iframe = document.getElementById('tweet-1252040170783641600-176'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1252040170783641600&theme=dark" }

Why does working from home during a shelter-in-place policy hit so different than working from home normally?

We’re all dealing with external stress

Every news cycle greets us with a fresh hell: More people are dying, more industries are struggling; Everyday it’s clear we are still in act one of the horror movie, where the leaders are ignoring the scientists. The news permeates every channel, social media platform, and discussion. Its inescapable, and something thats going to weigh on your mind when you’re trying to get work done.

There’s no escape

Working remotely is not the same as working from home. Working remotely means you can work from anywhere. Its often at home, it’s not on the beach like an Instagram influencer (I’m not about getting sand in my Macbook), but it is about being able to work from a co-working space or a coffee shop once in a while. Before, when working from home I made it a point to go to a coffee shop at least once a week because I knew how important it is was to be around people. That’s no longer an option. And when work was done, there were places to go to blow off steam: the gym in the morning, the brewery at night. Also gone. The biggest difference between quarantine work from home and business, as usual, is choice.

Now workouts are limited to runs and what few weights we have; Happy hours happen exclusively on Zoom.

Everyone is home all the time.

I couldn’t imagine having children right now. I don’t know how parents are getting anything done these days. Everyone having a lack of choice means we are all trying to cram our life together in new ways. For example, my wife would play roller derby three times a week, which gave me personal time and space to work on personal projects. But if I’m being honest, usually just playing with the dogs or the Playstation. We don’t have those spaces anymore. One more way to blow off steam gone.

It adds up in ways you don’t see or expect

If you are like me, you are not making the healthiest life choices lately. Being unable to go to the gym and to the store as frequently as I would like to make exercise and eating well more difficult. The stress makes it harder to sleep. You might be having an extra drink or three during the week. You find yourself drifting at work and you aren’t sure why you never had problems concentrating before. When the entire world is facing problems, resolving bug tickets doesn’t feel so important anymore.

But it won’t stay this way forever

I’m someone who has worked remotely in some fashion for almost seven years, and I’ve been struggling these past few weeks. Don’t be too hard on yourself if you are new to working from home, and don’t be hard on the idea of remote work based on this experience. Under normal conditions, with company structures that support it, remote work can be great. It gives workers time back by not commuting, more freedom to handle the minutia of life, and the flexibility to find working conditions that work best for them. Working from home right now doesn’t give workers the same luxury, and comes with its own set of problems.

Keep going, it gets better, I promise.

How to Build an Indeterminate Checkbox in React

Glenn Stovall — Tue, 04 Feb 2020 13:03:38 +0000

Fun fact: Did you know that HTML checkboxes have three built-in states, not just two? In addition to the checked state, there is also an indeterminate state. You can’t set a checkbox to indeterminate with HTML, only with JavaScript. Here’s what they look like in the browser:

Why Would You Need An Indeterminate Checkbox?

As you can see, they can be useful for “select all” checkboxes that can be in a “some but not all selected” state. Let’s look at how we can build a react component for a three-state checkbox.

How It Will Work

You need more than props in this case. The only way to set a checkbox to indeterminate in HTML and Vanilla JavaScript is setting the prop in JavaScript like this:

document.getElementById("my-checkbox").indeterminate = true

Instead of "checked={value}", two hooks working together manage the visual state of the checkbox. First, useRef maintains a reference to the element, so that you can manage the indeterminate property directly. Then, the useEffect hook manages the changes by executing code on the reference.

First, Our Boilerplate

import React, { useRef, useEffect } from 'react'

export const CHECKED = 1
export const UNCHECKED = 2
export const INDETERMINATE = -1 

const IndeterminateCheckbox = () => <input type="checkbox" />

export default IndeterminateCheckbox

We’ll need to define a trinary state here. I like using -1 for the third “maybe” state of this boolean operation.

Modeling Our Props

We’ll only require one prop here, the value of the checkbox. To increase the flexibility of our component, we should pass other props down to the input element. This way, whoever uses our component has access to modify all other props, so they can set onClick handlers for example. Here’s a pattern you can use to handle certain props specifically while passing the rest down the component tree.

const IndeterminateCheckbox = (props) => {
  const { value, ...otherProps } = props
  return (
    <input type="checkbox" {...otherProps} />
  )
}

Managing the Three Stages.

Now we can use the value to manage the three states. Situations where we need to execute code every time props change is a perfect case for useEffect. Every time the component renders or the value changes, we need to adjust both the checked and indeterminate properties. useRef provides a reference for managing those changes inside of useEffect.

const IndeterminateCheckbox = (props) => {
  const { value, ...otherProps } = props
  const checkRef = useRef();

  useEffect(() => {
    checkRef.current.checked = value === CHECKED
    checkRef.current.indeterminate = value === INDETERMINATE
  }, [status])

  return (
    <input
      type="checkbox"
      ref={checkRef}
      {...otherProps}
    />
  )
}

And there you have it! A way to manage a three-state checkbox with React. While there isn’t a ton of use cases for this kind of structure, I like this example because I feel like it gives a clear example of three React principles:

Making your components more flexible with the other props pattern.
Using useRef to modify elements in non-standard ways.
Using useEffect to trigger events based on prop values.

Side Hustle to For Investment, Not Income

Glenn Stovall — Sat, 18 Jan 2020 14:15:25 +0000

If you have a side hustle, How much money does it bring in compared to your job? Have you considered the possibility that you could one day quit working for others and instead work for yourself? It can be hard to imagine moving from employment to making money solely off of things you create, especially when you consider some of the salaries that developers rake in.

I hope to prevent you from taking that and moving towards this thought: If I can’t replace my income, why bother trying? That’s a limiting belief that kills projects before they even begin. I don’t want you to get discouraged and deprive the world of something valuable you can build.

But First, A Note From Our Friendly Neighborhood Lawyer

This article starts to delve into finances and investment, so I would like to say:

DISCLAIMER: I am not a financial advisor of any kind. Ideas presented here may not be suitable for everyone. If you have any doubts as to the merits of any of this advice, you should seek advice from an independent financial advisor, and refrain from @‘ing me on Twitter.

Now with that out of the way…

Salaries Are Inherently Risky

People tend to play conversation when taking risks revolving around their primary source of income, and rightly so. It may be the only way you pay your mortgage, put food on the table, or take care of your children. Besides, building up income from your own products or services takes a long time. People could work for years and only build a few thousand dollars in revenue.

While everyone doesn’t recognize it, we are all trying to bridge that gap — not just side hustlers.

Burn It With F.I.R.E.

Many people call the time when they make money from assets that own instead of trading time for money “retirement.” In many cases, people plan to save, then survive using those savings plus returns from investments.

There’s one glaring flaw with this plan: The retirement doesn’t kick in until 65 if you’re lucky. A lot can go wrong between now and then, and even if you make it there in a stable financial position, you are too old to enjoy much of life.

Enter the financial independence / retire early community, or “fire” for short. Fire, as preached by its evangelist Mr. Money Mustache, focuses on using frugality to shorten the journey to retirement.

In short, you can define retirement as the moment when you have enough non-work income rolling in to cover your expenses. The safest way to generate that income is by investing in index funds, mutual funds, and bonds. You can calculate how much money you need by using the 4% rule: the amount of your savings you can withdraw annually without ever running out in your lifetime. There are some criticisms of this rule, but it works well enough for the points I’m trying to illustrate here.

To get the amount you would need to invest at that rate, take your minimum monthly spending, and multiply it by 300. Some example outcomes:

Spending |      Required Investment
-----------------------------------
    $500 |                 $150,000 
  $1,000 |                 $300,000 
  $2,500 |                 $750,000 
  $5,000 |               $1,500,000 
 $10,000 |               $3,000,000

Changing The Math

The Fire philosophy is all about shifting the numbers in this equation via frugality. Cutting spending helps on both sides. Your monthly costs go down, plus the amount you can invest goes up. You can crunch some numbers here and see how long it would take you to retire under this model.

Enter “Fat Fire”

Recently I discovered a splinter group within the fire community. They refer to themselves as “fat fire” and people following Mr. Mustache’s principles as “lean fire.” Lean fire is about bridging the work/retirement gap by spending less and saving more. Fat fire pursues the same goal, but by increasing revenue and return. I jived with some of the ideas I found in this community, and a lot of them were software developers! As a software developer, you have unique leverage you can use to generate revenue and build your portfolio.

Index Funds Are For Wimps

When investing, index funds and stocks are only one type of asset class. In short, you can keep your pile of money in a mix of four asset classes:

Stocks, bonds, and index funds, aka paper assets.
Real estate
Equity or income-generating assets, known as *business assets. *
Straight cash, homie

Each comes with unique risks and rewards. Getting into that is far beyond the scope of this post, but as a general principle: any asset has more of a return than cash, and business and real estate assets tend to have more leverage and return than paper assets.

A side hustle that generates income is a business asset. Instead of buying one, you can build one.

Two Ways You Could Make $1,000/month

Let’s consider two ways you generate an additional $1,000/month in revenue.

Option 1: You work, save, and eventually invest $300,000. Based on the 4% rule, you can peel $1,000/month off of that.
Option 2: Create and sell something that brings in $1,000/month.

Which one sounds more accessible to you? Which could you achieve more quickly? What does each of these options look like in year 2?

You can’t beat income, but you can beat the market.

It’s unlikely that a side hustle is going to replace your income in the way that you think. However, it can accelerate your path to retirement. That’s why software development is so valuable; you can create business assets out of nothing! You probably have ways you can invest your time and energy to create assets that generate income. Instead of trying to replace your salary, you could think of your side hustle as adding a new asset to your portfolio.

The post Side Hustle to For Investment, Not Income appeared first on Glenn Stovall.