Selecting A Stack For Your Side Hustle
Side hustles can be a lot of work. Not only do you have a day job, but if you are trying to do something on the side as well, every moment counts. While messing around with library compatibility problems, database configuration, and the like is part of the job, you probably don't want to do very much of it after hours when you are just trying to get something done. Remember, the goal of a working side hustle is to make extra money on the side, not to be vehicle for exploring a new framework, language, or approach.
"Ideas are everywhere, you're essentially swimming in them all the time."
When selecting a development stack for a side project, you need to maximize the amount of time that you have available for actually getting things done. This means reducing the amount of time you spend troubleshooting weird errors, digging around in configuration files, or trying to deal with massive structural changes to your workflow. On your day job, if you lose 3 hours to fighting with a configuration problem, you still have half a day left and you still get paid. On a side project, three hours of a configuration slugging match means that you don't get to start on actual work until tomorrow evening. In addition to wanting to get to where you can make money on your project, you probably also don't want to spend every waking moment of your life in front of a computer screen, so efficiency is very important.
"Bear in mind that these things are a bit different for everyone, so we can only really offer guidelines that you may emphasize or ignore based on your own experience."
Side hustles offer a challenge to developers. However, that challenge can easily turn first to drudgery and then to pain, so you've got to be careful about the platform you pick. The goal of a side hustle is to eventually get some extra money, which creates an entirely different set of constraints than doing a project with the intent of learning things (even though you will learn a ton on a side project). It's not for everyone, but anyone can give it a try.
Episode Breakdown
09:55 Cost of Tooling
This is a big one on a side hustle, especially if you are starting from nothing. Development environments have gotten a lot cheaper in recent years, but the low-end IDEs may or may not be good enough for what you need. For instance, VSCode is free and works pretty well, however, there are use cases where it is extremely soft (for instance, if you are relying on Visual Studio GUI designers of various sorts, it's not going to work well for you). "Free" versions of paid applications tend to be reduced in functionality in some way.
"You asked me to do something and I couldn't because I had the Express edition."
Also consider the cost of the equipment on which you run your development tools. If the platform is going to require you to buy a new machine to use it on (Apple has been bad about this), that's an immediate and serious cost that you need to justify. Also consider how using existing hardware is going to impact the home situation. If you and your wife/kids have multiple machines, but only one is sufficient for what you need and it happens to be the only one that can run Fortnite, that's a problem. Be sure and consider what happens on a shared computer if one of the other users messes up your stuff.
"If you think of an emulator, it's a copy of a copy."
Why you shouldn't use the software and tools of your development environment from work. It's morally dodgy at best - this almost goes without saying, as you aren't paying for a license that you are using. It could also be bad if your side hustle is widely successful, should work find out that you used their software licenses and equipment, they may have a legal case against you. If they find out before the side hustle takes off, you could also be fired, which means you now have multiple problems to deal with.
18:25 Cost of Hosting
It's not only the cost of development tools that you have to consider. Running a real application requires money. There are a lot of costs. Hosting fees for websites are pretty low, at least at the low end. However, watch for webhosts whose costs go up drastically later. Consider the costs of email hosting, domains, and the like as well. Your webhost may have some limits there that you won't see until too late, unless you look. Don't forget the costs of databases and storage. Different databases may cost different amounts to run, and the pricing scales can be surprising.
"We both got burned by Azure."
The initial price may be enough to get going, but be careful. A lot of the cheaper hosting is banking on you setting up an app there, getting bigger, and then being too busy to move off as rates go up. Be especially careful of which web and database features you use, as pricing tends to go up quickly if "enterprisey" things or large amounts of data are involved. If things are running well later, you're going to be reluctant to move hosting unless there is a huge price difference.
"Think of your webhost as more like a tattoo than a hair coloring."
This sounds like a discussion on webhosting, not the development stack, but the stack matters here. If you are using a stack that only works well on a single, paid operating system, then your hosting costs will be higher. If you pair that with a proprietary database, it will be higher still. This was (and is) definitely the case with .NET apps running against SQL Server. The tooling helps lock you in, and then it gets expensive to host. Your stack can limit the available webhosting, and your webhosting can limit what you can do with your stack.
22:50 Platform Stability
You may consider it cool when the platform you use for work is getting big updates that drastically improve things. That's because you aren't paying for the problems it causes. On a side hustle, you are. You are probably making a mistake if you try to use a framework that isn't stable for a side hustle. Remember that any time that your framework takes away is taken away from actually getting things done that make you money.
"I think of AngularJS or 1.0. A lot of people built their side businesses around it then 2.0 changed everything."
Another thing to consider is how stable code is that runs on that platform. Just because the coding interface is stable doesn't mean that (for instance) it is particularly stable in a production server environment.
This whole thing sounds ridiculous, but lots of rapidly developing systems haven't been well-tested under production workloads. A lot of times, the only way this sort of thing gets tested is for someone to put the system under load. You don't want to do that on a side project and have it fall over at night when you have to go to work in the morning. I've had this experience and it's no fun.
27:10 Ability to Get Help
If you are doing anything interesting, you are probably pushing the limits of your own skill and knowledge, if not the platform you are using. At some point you are going to need help, so you don't want to use tools that limit the help you can get. You may also want to bring another developer in on the project at some point. If you are using a weird platform or language, it's going to take longer.
You want a large, active developer community for a number of reasons. Besides the need to get help at some point, having a large development community around the platform you are using makes it easier to find libraries that you can use. A larger development community also makes it more likely that you can find people who have already solved problems that you are likely to encounter, which is very useful while you are evaluating designs.
"If you use a newer technology all the help is people if you use an older technology all the help is docs."
The point here is that just because you start a project alone, that doesn't mean that you can ignore the role of a good ecosystem to work with. Not only will a good ecosystem help you avoid being stopped cold by a roadblock, but they will also help you avoid them in advance. Building a side hustle is also a very lonely road and is tough enough without a good community around you.
30:30 Ease of Deployment and Management
It goes without saying that if you are building something on the side, that you are eventually going to have to both deploy it, and manage deployed instances of it. While it may be interesting to play with systems and learn how the pieces fit together, that goes right out the window when money is involved. Having a solid deployment configuration can help you avoid having your project derailed at a time you don't have control over it.
"It stops being fun when it starts costing you money to learn."
Deployment is easier now than it used to be, but there are some things that can be difficult. You are probably going to either want to do docker containers (preferable) or be able to just copy files out somewhere and have everything work. You either want there to be very minimal configuration, or you want the configuration to travel with the code and be versioned with it. Again, the idea is to avoid having to tinker with settings when a system is down. This also protects you against the webhost making configuration changes with a script and breaking your stuff.
You also need to be able to easily manage the software once it's out there, both manually and automatically. You would probably be better off with a GUI when you are just getting started, just so you can get going eventually and so you can quickly handle problems as they arise. You don't want to be reading wikis about command-line parameters when a system is down. However, you do also eventually need console access (and probably some sort of scheduled task runner) as well so that you can automate things once you've done them manually.
35:00 Ability to Connect With Other Platforms
No application is an island. Whether you want to allow your users to sign in with OAuth, to import their data from other applications, or even to integrate well with their own stuff, you pretty much have to live in an environment where your stuff interacts with other people's stuff. Not only are there a lot of security implications to integrating with other platforms, but there can be a lot of complexity. It's a pain, frankly.
"We have integration points for this podcast that do things like dump stuff out into slack."
This means you need pretty easy support for several common integration methods. Webhooks will need to be supported for cases where applications are calling into your application over the web. You will also need to be able to support things like OAuth if you plan to integrate with third party websites, especially on behalf of your users. You will probably want fairly decent and clean ways of dealing with JSON and XML data as well.
Your platform will also need to play nicely with other systems that you intend to use for business. You are probably going to need to integrate with a payment provider or two. Analytics, including but not limited to Google Analytics are also going to be in the mix when you try to make money off of an application. You will probably have an easier time of it using something that is widely used, at least if want a supported SDK
41:25 Ability to Handle Mixed Environments
There was a time when you could reasonably expect all or most of your users to use a single browser, operating system, or mobile platform. This means things like supporting multiple mobile environments are not only reasonable, but expected. This can also mean handling things like display resolutions that may be an ultra-high definition widescreen on a high end Mac, all the way down to a really crappy commodity phone display. It's nearly impossible to test all the configurations you might encounter in the wild.
"What is a phone/tablet and what is a laptop have blended, so you have a lot of cross over."
Your users will also make things challenging for you. Some users don't update very often. You'd be surprised at how many people expect their Windows 2000 machine to work well with modern software. Other users will expect you to support the very latest version of whatever platform they use...flawlessly. The real fun stuff happens when the constraints of a user with a cheap machine (low memory, slow CPU) can't get anything done at all because you optimized for your users with good machines to be able to do things fast.
The point is that as your user-base grows, the constraints they put on your system will eventually paint you into a corner. This typically means that your software needs to rest on a stable framework or platform that is able to adjust to your clients' platforms, rather than you doing all that work yourself. While stability is a feature, it's something that clients expect by default, and doesn't differentiate your product. You especially don't want to be in this slugging match when you have a full time job during the day.
48:00 Ability to Tolerate the Language/Syntax/Stack
While lots of languages offer cool features that are impressive, it's also possible that there are things that drive you nuts about it. This is more important than you think, as funky language features that give you heartburn will wear on you in time. You may also really dislike some things about the underlying platform as well.
"I can't stand how Python treats spaces as syntactically significant."
There is a huge difference between something that is "cool to learn" and "fun to support as a side project". This probably means that you aren't going to want to use something that you want to learn for this, because you don't know the pitfalls. It might also mean that you don't want to use the same language you use all day and associate with a job situation that you don't like. This plays more into emotion than into subjective fact, but you don't want this kind of emotional friction in your life. You probably also don't want something that is so far behind that it makes you nervous.
IoTease: Project
[
10 most in-demand internet of things skills.
Yes this is a slide show but it has some good information about the skills you'll need to get a job or side hustle in the IoT realm. If you're wanting to turn your hobby into a career or wanting to make a little extra cash working on the side in a fun area this is a great list of the skills you'll need to succeed. Many of these are obvious such as Node, GPS, Security, but some are things you might not expect like AutoCAD. Each slide talks about the skill, how it relates to IoT, and the percent increase in demand so you can determine which skills to focus on.
Tricks of the Trade
If two facts are both true, and one is empowering and the other is disempowering, pick the empowering one to focus on. There is no reason to focus yourself on something that makes things worse when an equally true option is available that doesn't.