Why?

This week, PlanetScale decided to remove their Free tier, but there are lessons here for small startups and larger businesses alike.

Their new, lowest tier of database is $40.

$40!

But this is not just any database, this is a fully managed hyper-scaling database.

This means it has incredible infrastructure running for automation, governance, migrations, rollbacks, synchronization and sharding, incredibly detailed metrics and logging to support all this, and more.

For $40.

If my normal “developer” rate is $150 an hour, this is less than 1/3 of that, so about 20 minutes of work per month to build and maintain all this infrastructure myself.

Can I build all that, and run it, and support it at midnight if something breaks and spend less than 20 minutes on it?

Absolutely not.

SECONDLY,

Free tiers are generally a loss leader, to gain a pipeline of users that can *eventually* become a paying customer, and the idea is that these paying customers eventually can cover all of the free tier folks’ expenses for the business as well as the paying tier customers’ own.

This does work to get users, but it is very hard to make this sustainable when you:

1. Have almost all free tier users that don’t *actually* need what you offer (in this case you may need MySQL, but don’t need a fully managed, ultra-scalable, lightening fast instance shaving a few milliseconds from your queries).
2. Are not profitable yet.

If you are a hobbyist, I can see why the removal of the free tier and you having to move away stinks, because it *is* work – and not very fun work at that.

However, there are lessons here to help grow your small business and understand why large organizations buy some products over others – and why Planetscale is coming to terms with this reality.

Lesson 1: Revenue Growth vs Profitability

There are two ways for a startup to be successful – direct profitability and an “Exit”.

Profitability

Direct profitability is the easiest to understand. If the money coming in is greater than the money you spend, then you are profitable! Congratulations, you are a successful business!

Planetscale is not *yet* profitable, but that doesn’t mean that success isn’t possible. Why? Because there’s another way to be successful..

Revenue Growth

Many startups, likely Planetscale (I don’t know about their funding and structure, but they probably have taken investments), have the goal of growing revenue as high and fast as possible at nearly all costs – even if it means *losing* money.

At first glance, this seems CrAzY!!

Why would a business *be ok* with losing money?

Well, there are a few reasons, but they all revolve around the “exit”.

As long as revenue is increasing, it’s ok for expenses to increase in tandem, because at some point you have one of two “exits”.

The first Exit type is acquisition.

When a large company buys a another smaller one like this that is *not* profitable, but increasing revenue, the larger company can find “synergies”, meaning HR becomes a duplicate area, some dev teams become duplicates, executive teams can become duplicates – so, layoffs happen.

This is painful, but buying a company and reducing these overhead duplications means revenue stays the same, and costs dramatically decrease, and, in most cases – instant profitability.

The second is when you get to profitability by yourself from this method.

This, too, is painful, and many times the cuts come in the form of free tiers or layoffs, but generally fewer layoffs since you still need HR and all those other roles.

The downside of *not* being profitable is that you have, quite literally, a limited expected runway. If you are losing money, you can calculate how long you will stay in business.

If I have $35, and I buy one $5 latte every month (assuming that’s my only expense), I’ll be broke in 7 months. If I spend that in a day, I’ll have one week until I’m broke.

The only way to increase runway in a company is to:

1. Make more money (revenue)
2. Be given more money (investment, meaning strings are probably attached)
3. Borrow more money (debt)

And not being profitable means you are kicking the can down the road trying to get to an Exit someday.

If your business closes before you get to that exit, you have to take the BAD exit, and your customers lose access to your product or service.

And what if you have already built a multimillion-dollar business on a product that suddenly goes out of business

Well, that leads to the second lesson here….

Lesson 2: Derisking

If there’s one thing I’ve learned in personal finance and business, it’s that when you don’t have a lot of money, you should take a lot of risks (calculated, of course, let’s not get crazy here).

However, as you grow wealth and your business, your mindset should slowly shift.

Healthy, growing, and large organizations can have double digit (10% or so) revenue growth, generally, a far cry from some startups boasting 50% or more in some quarters.

However, at that point they consistently make – and have – a lot more money.

The bets they make now have a more balanced approach:

The decision makers at companies are looking to make an investment that has great upside when things go right, but minimized downside if something goes wrong.

They want to make calculated bets on their future and if your database provider (I dunno, in my opinion, a fairly key part of any app architecture) goes out of business, then the migration off of it will be incredibly expensive and sometimes near impossible depending on how proprietary the platform is!

Because of this, CTOs and decision makers are always looking to make a great return on investment, but while keeping a close eye on the tail risk of their decision.

If they make a decision and the worst-case scenario, is you can’t move your application, or it would take an effort larger than your own business could sustain, is that acceptable?

For most orgs, probably not.

For Planetscale, specifically, they likely have a few customers that pay the bills for everyone else – big customers! Millions of dollars per year (per month?) customers!

Those paying customers want to know they are safe, and Planetscale is making the decision to make a move to de-risk those customers’ choice to use their platform.

Remember, adding in this extra layer of trust could attract just *one* of these large customers and pay for lots of re-hires!

They even say they focus on problems that “enterprise-scale” companies have. Do you think “enterprise-scale” companies can foot a $40/mo bill to test out a database before going all in? Yes. Do they NEED a freemium tier? No.

This means I can’t host free stuff on the platform anymore, but it also means that if my business makes money and is successful, then I can be more confident that I won’t go out of business just because Planetscale can’t pay the bills because I have 5 other free projects they are hosting and trying to use as a loss leader.

Side-note: If you are a startup and can’t get a handful of customers within the first year or so to cover $40/mo, then I think you should either charge more or pick a new idea. Then again, you might not need an “enterprise-scale” database, either.

Conclusion

Planetscale is making a decision to move away from freemium, which is a better path in their eyes to profitability (hey, the numbers agree with them).

Remember that profitability increases stability, which increases trust for real businesses that are looking to balance “hey this is cool tech!” with “could we survive if they sent us an email and said they’re closing down in 30 days”?

Free stuff and being frugal is very useful in the very early days of side projects, and for businesses to get leads, but when you start making money, mindsets shift.

Swing for the fences, but don’t bet the farm.

The post Planetscale Likely Lost Over Half Their Customers This Week. Here’s Why That’s Good For The Business and The Customers That Stay appeared first on Ryan Hayes.

Here’s the full error message:

C:\Program Files\dotnet\sdk\5.0.201\NuGet.targets(131,5): error : Problem starting the plugin 'C:\Users\VssAdministrator\.nuget\plugins\netcore\CredentialProvider.Microsoft\CredentialProvider.Microsoft.dll'. Plugin 'CredentialProvider.Microsoft' failed within 5.256 seconds with exit code -1.

A credential problem?

It was only failing on one of three project publishes and on the NuGet portion of the publish command. My first thought was that the credentials might be incorrect. We recently had a developer leave and I thought that potentially something was set up with his credentials and was revoked. I double-checked the service connections in Azure DevOps and everything looked to be ok.

A .NET CLI version upgrade?

I then noticed that Azure DevOps was using Microsoft Build Engine version 16.9 as opposed to my local version of 16.8. I upgraded locally, and couldn’t reproduce the issue. Everything was great there.

A timeout issue? (yes)

This is when I took a closer look at the error message below.

C:\Program Files\dotnet\sdk\5.0.201\NuGet.targets(131,5): error : Problem starting the plugin 'C:\Users\VssAdministrator\.nuget\plugins\netcore\CredentialProvider.Microsoft\CredentialProvider.Microsoft.dll'. Plugin 'CredentialProvider.Microsoft' failed within 5.256 seconds with exit code -1.

As it turns out, NuGet defaults to a 5-second timeout, which very closely aligns with the 5.256 timeframe of the error. Doing some more investigating, I found you can increase this timeout by setting an environment variable. I decided to increase the timeout from 5 to 20 seconds in the azure-pipelines.yaml and guess what? It worked!

# in your azure-pipelines.yaml

variables:
- name: NUGET.PLUGIN.HANDSHAKE.TIMEOUT.IN.SECONDS
  value: 20
- name: NUGET.PLUGIN.REQUEST.TIMEOUT.IN.SECONDS
  value: 20

The above tells the running pipeline to inject the following environment variables during the run:

$env:NUGET_PLUGIN_HANDSHAKE_TIMEOUT_IN_SECONDS=20
$env:NUGET_PLUGIN_REQUEST_TIMEOUT_IN_SECONDS=20

Maybe it was the Azure DevOps upgrade of the build tools to 16.9 made Azure Pipelines get just slow enough to push it past the 5-second timeout for the CredentialProvider.Microsoft plugin.

We’re also connecting to 3 external feeds during this project, so it’s more than the average project that may only connect to the main NuGet feed.

Hopefully, this gives you some insight into the problem and a quick solution to save you a few hours. On to the next fire!

The post Azure Dev: Problem starting the plugin CredentialProvider.Microsoft [Solved] appeared first on Ryan Hayes.

My current team is the longest I’ve ever been with an organization (other than my own freelancing business), almost 5 years. Over the years the needs, motivators, situations, and lives of people within an organization can and will change. It’s the nature of life.

There are obvious ways to reduce turnover, like avoiding burnout of your team, compensating people well, providing adequate training and opportunities, and aligning individuals with meaningful work. Even with all of these things, and no matter how much people say it, no one is guaranteed to be around forever – or even the next year.

Twice now in my career, I have had someone say to me “I don’t plan on going anywhere” and then offer their two-weeks notice within 3 months’ time. And that’s ok.

We should celebrate when someone gets an opportunity to take a chance and chase a dream, or grow, or get a new opportunity.

What makes a difference at these points, is that the organizations and teams that expected developers to leave fare far better than those that do not.

Why should you expect developers to leave?

You have probably heard the phrase: “What if ______ gets hit by a bus?”.

This effectively means what if something unforeseen happens and the person is no longer with the organization. This phrase actually causes a huge problem in a lot of teams. Getting hit by a bus is a rare event. When we pause to ask if someone will not be with us, we phrase it and think about it as if it is a rare occurrence. In reality, in January 2020, the average tenure for a Computer Science/Math employee was only 3.9 years. This means that not only will someone leave on your team, it’s probably going to occur sooner than you think.

Why does expecting developers to leave help them not leave?

When we expect people to leave, our priorities change. We switch from “I can always just ask” to “Make sure we can be successful without you”.

When we change the culture to focusing on simplifying, documenting the “why”, and ensuring others can easily maintain code without the original author, we inherently reduce complexity. When we reduce complexity and the baseline requirement for understanding code and systems, we free up our minds to be more creative in other places.

This benefits teams not just when the developer leaves, but also helps free that person from questions when new developers join the project without the extra hand-holding.

Assuming devs will leave helps us unlock the full potential of our teams in creating real value for customers, both faster and with more brain bandwidth to build better solutions.

Thanks for reading! Enjoy this article? Join the newsletter!

Ten years ago I thought I had to choose between good opportunities as a software developer in larger cities or living where I actually wanted to live (a much smaller town).

I spent the next decade building a personal brand, a freelancing business, side projects, a local and online developer community, and more to create the career I wanted and live where I wanted.

Now, I want to teach you to do the same. Join me and hundreds of developers on my newsletter for my most popular posts here and other useful tips and tools to help make your own opportunities.

The post Expecting Developers to Leave appeared first on Ryan Hayes.

You started out just wanting to be helpful or useful, and now you’re overwhelmed and can’t keep up.

If left unchecked, Success Syndrome can actually lead to burnout and potentially depression. This can be especially bad if you pin all your hopes on productivity or accomplishments fulfilling you.

Let me just say, though, that “Success Syndrome” is an indicator you’re doing something right. It means you’ve built trust, relationships, knowledge, and the start of a personal brand within your workplace or community. I’m not saying that that Success Syndrome is all good, but I am saying that the burnout is what the real issue is here. And burnout comes particularly fast when you have to field questions from peers from the former position, as well as from the new position during promotions while also trying to complete your regular developer work.

One useful observation is that many of these questions tend to be the same. 

“Hey Ryan, how do you set up X.”

“Hey Ryan, you’re good with JavaScript, what framework should I use for this project we have coming up.”

“I got this error, what do I need to install again?”

 Requests from peers or others can usually be boiled down to a StackOverflow-style question and answer pair, which is (and here’s the secret) a content gold mine.

If you’re experiencing burnout due to a large number of questions from peers that you get over and over from different people, and particularly if they aren’t NDA-based (which project-specific questions probably are, so check with your manager first) then what you need is to write those questions down!

Often times if you’re answering questions like this and they aren’t in blog-form, posted on your personal site, then you should start one and get to writing!

If you’re experiencing Success Syndrome, it’s likely that you feel good helping others and answering questions, but if they become repetitive and you’re asked something a few times, write an article and point people to it! It’ll save you time and also allow others on the internet to find it.

Multiple people asking the same thing also validates there is an audience for the question.

Questions from peers at work that might have project-specific answers, particularly ones over email, are ideal candidates to write up in a wiki or a ReadMe.md file right inside your repository. Then, once you have things there, send a link to it in email to them. Other team members will be glad you did.

The post What is Success Syndrome? (And How To Leverage It For Your Personal Brand) appeared first on Ryan Hayes.

When I was a junior dev, I would complain about lots of existing legacy code that I encountered. I ran into a lot of it doing contract consulting work. This wasn’t just the obviously bad stuff, either, like finding some homegrown ORM using non-parameterized SQL queries being read from XML files. 

I complained about the little things. Like using a loop or if statement that wasn’t the most optimal, or copied code, or someone not using some library I thought they should be using.  Honestly, I still fight that temptation sometimes. It took a few projects to really get perspective on technical debt, where it comes from, and how to appreciate it.

Often, technical debt sold the software to allow you to have a job.

Think of the times you had to add technical debt. It was likely to hit a deadline or meet some pressing customer need. Those pressing sprints were typically when a high-paying, critical customer needed something. The key to effectively working with technical debt is don’t become over-leveraged.

Strategic technical debt can bring you key wins at times that you can pay back later, but if you become over-leveraged with technical debt, and don’t pay it down, you eventually come to a point where you’re unable to move forward at any reasonable pace.

Sometimes code isn’t optimal but increased MRR (Monthly Recurring Revenue) just enough to allow for hiring a new person – you.

The post Technical Debt Isn’t All Bad (Usually) appeared first on Ryan Hayes.

“There are no rules.”

“Just follow the rules”

Why are rules, quotes about rules, punishments for broken rules everywhere?

When my daughter asks me what the rules are, she’s probably not asking what they are so that she can follow them. She’s asking so she knows how to get around them. What are the boundaries that I can operate in and what loopholes are there?

Rules help us to define certain boundaries and the operating procedure of how we interact and behave with each other, but rules aren’t actually the main thing.

In addition to explicit rules, there are unspoken rules, which sometimes eventually become explicit, spoken rules. Some examples include:

“Don’t steal.”

”Meet your deadlines.”

“Test your code.”

“Don’t tie your brother’s leg to the dog’s leg.” (A great example of an unspoken rule that recently became an explicit rule in our house)

Some rules are soft and some are hard. But they usually have one thing in common – they support and maintain relationships between people. Rules are contracts for how we can respect and serve others.

You may think that you need to create more rules to improve the culture, but often you don’t. You’re doing a disservice to people when rules are used as a replacement for genuine relationships.

While you can always focus on more rules, more punishments, more restrictions, it can never replace the heart of what we all want when we create and enforce rules – trust, honor, and respect.

When should you use rules?

Use formal rules to improve the how as opposed to the why.

When you try and improve the culture of an organization, and you’re looking to add more rules – stop and ask if the rules are actually necessary. They might be, but often you can get a better and more lasting result by stopping, listening, and simply improving the relationship with others. In doing this, we can avoid some (many) explicit rules altogether.

The post No Rules is the Best Rule appeared first on Ryan Hayes.

This past year I quit coffee.

Not necessarily on purpose. I actually love coffee. Though, when you get up to three cups per day, it’s probably a good idea to cut back, so I needed to.

So what changed? My wife rearranged the kitchen.

She “moved the cheese”.

“Moving the cheese” has a generally negative connotation, but the moving part is given more emphasis than the most important part – the behavior that the environment change creates.

The coffee pot, the scoop, the coffee, the water, the mugs all moved to different parts of the kitchen. No longer were they right next to each other, taking seconds to complete the coffee-making task.

When each of these items became further apart, it increased the friction of making a cup of coffee during the day. They didn’t move by much. It’s only an additional few steps, but it was enough to completely stop making coffee at all.

Sometimes we think that our habits are too hard to change. Even impossible. But that’s not true.

We change every single day. In fact, our brains want to change to become more adapted to our environment.

Did I complain? Yes.

Did my behavior change? Yes.

Was it good for me? Probably Yes.

If you want yourself, your team, or your users to change their behavior, change the environment, and let them adapt naturally. Don’t focus on if the cheese moved; focus on what behavioral changes will come as a result. It might be uncomfortable, there may be complaints, but we were made to adapt, and sometimes, it’s good for us.

The post Moving the Cheese appeared first on Ryan Hayes.

I’ve been writing in various forms publicly for about 12 years now.

The majority of that has either been guest blogs or on my own site.

I do it partly to organize my thoughts and solidify my understanding of topics and observations, and partly to get better at one of the most important ways to communicate – writing.

Over the years my personal site as moved several times, but each time I’ve moved it, the only regrets that I’ve ever had were moving the content to a place where I didn’t have control of 4 things:

1. The freedom to control what I write.
2. The freedom of who has access to what I write.
3. The ability to set a custom domain.
4. Setup of 301 redirects.

That last one is probably only important when you can’t decide on your slug and change it over the years.

Medium was a great writing and publishing experience for a few years. Then they removed custom domains and added paywalls.

Substack’s brilliance is that it provides a simple publishing platform when the most important thing for you to do is write. In my review of this year I realized that what I really want to do is write.

And so, that’s what I’m doing.

Just…not here on Substack. (I didn’t just pull a clickbait, did I? )

To subscribe via email, visit my website at https://ryanhayes.net and use the sign-up form for both regular articles and other updates.

Or, click here to subscribe to my posts via RSS. Feedly is a great RSS reader, but Substack has one built-in as well.

I’ll be talking all about what I learn in building cultures of innovation in Fortune 500 enterprises, remotely working in the mountains of rural America with high-growth small-town tech startups, and the principles that I learn that help make a difference in both.

Also, I’d love to learn more about you and what you’re interested in hearing about, so say hi!

Until next time.

-Ryan

The post Substack is the new Medium appeared first on Ryan Hayes.

Hahaha, I’m sorry. Let’s start that again.

Wow, what a year.

January was filled with business trips, hotels, planes, and gatherings. I remember seeing a couple coming from Europe in the Atlanta airport getting off a plane wearing masks. It was the first time I ever really stopped and thought about catching anything serious in a long time. The Coronavirus was the only thing on the news as I sat eating my usual turkey and cheese sandwich from the Boar’s Head Cafe while waiting to catch my flight. I remember thinking about when I picked up H1N1 back in 2009 while I was living in DC and was probably the sickest I’ve ever been. That flu was a bad time.

If one thing’s clear, it’s that this year has given me more perspective and made me more grateful for my family and the little things in life.

To the cloud!

As everything shut down on March 15th. My focus switched to helping my organization transition to fully remote and my local community’s businesses transition to mobile ordering, curbside pickup, and in general just how in the world to use technology to not go out of business. The companies who had made the transition to allowing for curbside pickup before the pandemic were weathering ok, and the ones who thought everything would blow over continued to decline. It hurts my heart to see so many businesses I loved visiting shutting their doors. The virus has taken both lives and livelihoods, and I’ve felt fortunate to be in a line of work that can basically do 100% of everything from home.

Volunteer Work Pivots

Last year, I joined the executive board of FoundersForge, a local non-profit focused on helping entrepreneurs in NorthEast Tennessee build scalable, high-growth businesses. We mostly run in-person events, and that completely changed. We re-focused our efforts into directly calling and working with entrepreneurs and helping them get connected with the resources they need. We planned a huge 2021 roadmap that I’m so excited about. Plus, we recently raised enough money to execute a good chunk of those plans. Using business as a way to do good in the world is something I’m passionate about, and working with such a great team here who shares that vision is truly inspiring.

TriDev, the developer meetup that Jeff Rainey and I have run for years, went full-remote. At first, we had about the same number of in-person people, but Zoom fatigue quickly set in. Even I feel it. After 10+ years of screencasts and virtual meetings, at the end of the day, I just want to go outside. I’m fortunate to live in the mountains where we have plenty of places to go, but my outdoor time has even gone down this year. RIP my Strava premium account.

Last Year as a Microsoft MVP

I’m grateful to have been awarded a Microsoft MVP award nine times. This year was my last and was bittersweet, but the program needed some fresh blood and I’ve become less directly invested in Microsoft-specific tech in recent years as the web has spread out more and I use a wider variety of tech to build software. Nine is the number of seasons Seinfeld had, and the number of years the Beatles were together, so I guess it seems like a good time to end it anyway. I’ll miss the MVP Summits, though (the in-person ones), and seeing everyone more frequently.

#IntrapreneurshipLife

I don’t speak for the org I work at all here, in any stretch of the imagination. Opinions are my own, etc.

However.

I’m incredibly proud of a new thing we built this year.

I’m a big believer that the principles that make a great startup a great startup are the same principles that make large, enterprise-size organizations great. Not least of these principles is laser-focus on bringing value to customers with everything you do.

Our org builds software for K-12 cafeterias, among other things, and COVID-19 changed the expected behavior of almost every single one of our users. As part of the work I did internally, we went from brainstorm to idea, to prototype, to shipped product with paying customers in about 6 months.

We essentially built a Doordash for K-12 schools called Heartland Meal Orders.

While doing so, we laid the groundwork for a new design system, built with Figma and Storybook and React components, and I’ve internally joined the design community of practice. While I’ve traditionally been a backend/API developer, designing and building great user interfaces are critically important and expected by the average person.

This leads to…

Things I Intentionally Learned

Every year, I pick a couple of technologies and go deep.

CSS (architecture and systems)

I’ve always known enough CSS to get the job done. Mostly based completely on Bootstrap or Foundation with everything overriding those controls. This has always served me and my teams well starting out, until we wanted to do anything custom and then everything fell apart trying to keep up with the Bootstrap upgrades. Custom CSS has its own problems, but doing it right, particularly when you have a design spec and are using a modern, component-based framework like React or Vue, it pays significant dividends later in your ability to reuse code and execute on changes quickly.

The new project we built at work had a near completely custom design, didn’t support IE11, and I was the font-end lead on the project. It was a great opportunity to really solidify my front-end skills. Parts use CSS Grid, but the majority is Flexbox. Honestly as much as CSS Grid gets talked about, Flexbox is the real workhorse of the web, and I have a deep understanding of it and edge cases now.

CosmosDB

I’ve only ever really used relational databases for apps. While I’ve used Redis for caching, and MongoDB for side projects in the past (does Firebase count in non-production toy projects?), I’ve never used [shipped] them as the primary database for a project – until now.

CosmosDB has its warts. While it touts a MongoDB API and others, only the SQL API is truly ready for a production application. It has a steep learning curve, and many foot-guns that can cost you thousands of dollars in Azure fees. It’s dangerous. But it’s fast.

Wow, is it fast.

The speed is yours to lose and having shipped a fully production, customer-paying app on CosmosDB, it’s been fun to see the extremes of the benefits and the dangers of this technology.

Next.js and GraphQL

I tend to tell new developers that the first thing they should do is start a personal website, since you can do one very important thing: Learn a technology in context from start to finish. From git to builds, to staging, to prod, to monitoring, to performance. You can learn everything and build something in production with real users and real feedback. And it’s all yours.

This year I rebuilt my website (previously Gatsby) in Next.js. I hated GraphQL in the context of Gatsby, and Next.js gave me routing conventions and more flexibility over where the content was coming from.

I went from markdown (which ended up being GraphQL on top…again), to Contentful (also GraphQL), and finally to WordPress GraphQL, since my content has all of its history there. It was fun to see all that Next.js has to offer, and what a powerful frontend platform it is for building sites and apps.

Redwood.js

I spent a big part of mid-year’s free time building a side-project in Redwood.js. Redwood is trying to be the modern version of Rails, and adding conventions and glue on top of Prisma, Node, React, etc, to make a single platform. I love the direction, but it’s built in JS instead of TypeScript, which means that there was no intellisense and type support for a very long time. It’s still coming, and I ended up spending an inordinate amount of time writing tests just for types and in the forums. I eventually gave up and have been looking at Blitz.js for the new year.

Bullet Journaling

This is probably the biggest thing I started this year that I’m carrying into 2021. Bullet Journaling is a daily practice.

BuJo is part task management, part diary, part note-taking, part art notebook, etc. Most importantly bullet journaling is intentionally slow. So much of my life had become fast and fleeting. I was becoming forgetful. Not that I couldn’t remember things. I have a decent memory. It’s just that I wasn’t remembering, or doing, the right things.

The act of pen and paper note-taking has forced me to remember and focus on what’s important. Since my hand will cramp if I write too much, I only use my pen strokes for the most important things. It’s helped me focus on the things that truly matter. I attribute the majority of productivity, clarity, and not spiraling into a mental health disaster this year on intentionally removing the screens in the morning and key times of the day, and being mindful of the gift that time is.

A side benefit has been that it’s made articles like this, where I review what I’ve done much easier. It feels sometimes like the year just goes by and I don’t accomplish much, but writing down the things I learn, the takeaways of the seemingly tossed away side projects, the small joys of time with my kids, and having a record to pass to them someday puts more life in my years.

The Year of the Mac

Ok, I promise that it’s not where I’m not an MVP anymore, but I do feel like I have more freedom to say this, but I switched to a Macbook Pro this year. I still use Windows and Visual Studio for some things I can’t get away from (dashboards and reports that require full framework .NET and Visual Studio proper for a report builder). Everything else, though is all Mac OS for day job work.

Visual Studio Code with the right plugins is a joy to use, and as much as WSL/WSL 2 has overcome so many of the npm install type of Windows-only errors there ends up just being different, more esoteric errors to replace them. .NET 5+ and of course anything Node.js and more simply work better, faster, and more consistently on Mac OS.

I hate it, but it’s true for me.

In addition, for the same reason Mac folks used to have a Windows VM to test for the IE users, I now need access to a Mac to test for weird Safari bugs. MS Edge is my daily browser driver, but with a Mac I can get in and out without much fuss or additional VMs tying up my machine. I still own a desktop PC for personal code work and any Twitch/Video work, but everything else now is either my iPad Pro or Mac.

Mentorship

I’m a big believer in mentorship and freely giving of the wisdom we collect over the years. Life has some curveballs, and it’s important to pass on what we’ve learned, for better or worse, to the next generation.

At work, we have a program I’m a part of called “Future Leaders”. It’s a two-year executive leadership mentor program, where you’re paired with a VP or higher to learn the ins and outs of the business and help train you to be a better leader. The title is kind of a misnomer, since almost is everyone is a leader for something, whether we feel like it or not. But it’s been insightful being able to see behind the scenes of how things work during a year like 2020.

The biggest takeaway from this is that openness has been so important for me to be able to make good decisions for the business and also feel like my work matters (there should always be a way to trace back your work to a “why does this matter?”). In closed-communication organizations, it’s hard sometimes to understand where particular stories or tasks fit into the bigger picture, and understanding the business side of the technical work helps flesh out the “why”.

Onward

As 2021 rolls in, and a vaccine is on the horizon, I’m excited for the new year as we slowly move back to some form of normal that involves people. Even an introvert like me can’t wait to see people and regain the ability to just go sit in a freezing cold Starbucks and listen to the hum of life and overly loud indie music.

The post 2020: Year in Review appeared first on Ryan Hayes.

Ideas.

Code.

Caffeine.

On minimal sleep.

What is a hackathon?

A hackathon is a set time frame, usually 24 hours, where teams build something. They can either be for fun or competitive. For-fun or non-competitive hackathons often revolve around flexing creative muscles while building community. Many can even be for the benefit of non-profits or to contribute to open-source software. Organizations like GiveCamp and Startup Weekend help organize large hackathons worldwide and make it easy for developers to get involved. (Running a GiveCamp is a great way to flex your leadership skills).

At the end of the time limit, they present their creations to an audience. Depending on the types of hackathons, the winners can take home fantastic prizes, like funding for their idea, credits toward services, or cold, hard cash.

The primary goals are to get people out of their comfort zones, try new things, and build something incredible within a set of constraints. You’ll come to notice that not all hackathons are created equal, so understanding the context of the one you are entering is of paramount importance.

There is a formula

What if I told you there’s a formula for winning hackathons?

While every hackathon is different, and the strategy in how you prepare, build, and present is different. In this article, the definition of winning is taking home first place or a top prize, but there are other incredible benefits of hackathon participation that can be equally important. You can "win" by becoming better as a developer or entrepreneur. You can "win" by networking with others. Keep that in mind as we start with the first step – preparing for the hackathon.

Know the rules

The first and the most non-negotiable rule of winning a hackathon is to know the rules. You don’t have a shot if you are disqualified from the competition or fail to meet the requirements. If the rules state that you must use a specific service or technology, you must use that technology. If there is a requirement for a certain number of teammates, then meet those requirements. This leads to the next softer rule of knowing the audience.

Know the audience

Knowing the audience helps give your team and your product focus. If the hackathon is based around high innovation, then a to-do like application will likely not win. If the theme is "hack for non-profits," then a robotics project based on drones will probably not help if the non-profits present are lower-tech office workers who just need a new website. Keep in mind who is attending, the hackathon theme, and what the people attending are looking for. This is particularly important for winning the "people’s choice" awards where the audience votes.

Know the judges

The win and the loss are ultimately in the hands of the judges. When planning your idea, it’s crucial to know who the judges will be, their industries, and their background. Each judge will bring with them biases, personal interests, and philosophies of what a winning project will look like.

An angel investor is likely highly focused on ROI and innovation. What would the market look like, and how much could this potentially be worth?

A judge with a marketing or sales background will likely be excited by things that show well.

If a particular judge has a clear stance against the continued increase in mass surveillance technology will likely not vote for you if your project requires a camera in their bedroom.

The key here is to find hard-negative biases to avoid while looking for a project idea that hits the excitement button in some way for each judge.

The Team and The Idea

"If you want to go fast, go alone. If you want to go far, go together." is a quote that applies so well during hackathons. When selecting a team, the main tradeoff is that the fewer people you have, the faster you can pivot and move, while each additional person adds communication overhead. Additionally, you want to balance something that is both ambitious and doable. Understaff an idea, and you won’t complete it. Overstaff a plan, and it leaves someone sitting on their hands at best, or at worst, will slow you down.

It’s best to keep the team small, particularly before you solidify an idea. Two or three people total is best. These key individuals are your "founders." They are both idea machines AND can execute. If the work for the idea can be evenly distributed between the three, then continue with the team.

If the idea is ambitious enough to need more people, then you’re at your first crossroad to "go far." You must stop and determine if the execution you are planning can support more people and decide where the "snap points" or interfaces will be.

As developers, we’re familiar with the concept of an interface. It’s a contract between two types – a bridge that allows developers to build pieces of a program, totally isolated from each other, and have some semblance of a guarantee that the two will work together. This concept and construct is the key to building larger projects in a shorter amount of time. The most effective software leaders know how to use interfaces to effectively divide and parallelize work, and it’s a vital skill to have if you intend to ramp team size.

In one hackathon, my team won by building a universal search for an existing application. It was similar to how the Windows key works on Windows or Command + Space works on Mac OS. We started with a team of 3, where we created an interface for services to search different parts of the program. One person built a service for the navigation and menus, and another the user search service, and a third built the UI. This division of work allowed us to agree on a common language between the services and, once complete, gave us the unhindered freedom to work in parallel for the rest of the time. Once we realized this, we recruited two more people to help build other services. Since an interface was in place, we were able to parallelize that work as well.

Look for ideas that have parts that can be broken off. This gives you the power to be more efficient in building a real demo of your design or product and ultimately gives you the edge over the competition whose idea is less complete. Ideas are cheap. Execution is everything.

The Execution

The execution.

The demo.

The prototype.

This is where the fun begins. It can generally be a hectic segment. If you did your due diligence in planning and team building beforehand, your goal should be clear. Break up the work and start building. Pivots and questions are sometimes inevitable. If you see that you are running into unforeseen issues, sometimes it’s best to pivot in a new direction, or at least mock a particular service or part and note the assumption.

Some hackathons, such as Startup Weekend, have designated business and technical mentors. Keep in mind any resources available to you during the hackathon and take advantage of them if appropriate (my #1 tip would be any free snacks, of course).

For picking technologies to use, some people try new tech to learn. If your intent is to win, use safe and known languages and technologies for core parts of your prototype. Only use new or unknown tech for required pieces that relate to hackathon rules, if possible. If rules say no code should be written until the competition starts (most do), then think about the code beforehand. What might it look like? Many times you imagine what structures and integrations will generally look like before you code, so run things through in your head to ensure a clean implementation.

The Presentation

The final presentation is critical. It can make up for execution missteps, and it can lose the competition for an incredibly well-built prototype.

First, choose the best presenter on the team, who is most comfortable on stage. This isn’t always the leader.

Next, craft the story. Think of the judges and the audience. What ideas are they interested in, and what stories can you tell during the demo that they will connect with? Keep in mind the original goal of the hackathon. If it’s a startup or business-focused hackathon, then be sure to include all the essential numbers. Include data about the market, ROI, relevant competitors, etc.

Finally, be sure to nail the ending. Have a final slide or come back to the most important questions and remind the judges and audience of what they just saw. Why is this the problem to solve? Why now? Why is this the right solution and not something else, or nothing at all (many times in business we aren’t fighting against competitors, we’re fighting against customers or people doing nothing)?

In Conclusion

Hackathons are incredibly rewarding and pack incredible amounts of experience and learning into a small amount of time. I recommend everyone participating in one at some point in their career (the earlier, the better). Have you participated in a hackathon? If so, what helped you get the edge over the competition? Or, what did you do that you might do differently in the future? Leave a note in the comments and let me know.

Happy hacking!

The post How to Win a Hackathon appeared first on Ryan Hayes.