DEV Community: Michael Markey

What makes for a good side project?

Michael Markey — Wed, 29 Mar 2023 12:10:18 +0000

TLDR;

Build something that you actually want to use. Since the user is you, it doesn’t matter if it’s innovative or if someone has done it before.
Pick a comfortable number of new technologies to make it technically interesting, but not too many.
Focus on the core experience first (making it usable) and worry about the rest later (or never).

Looking through twitter threads or reddit forums related to programming, you’ve probably come across this sort of post: “Any ideas for a good side project?” If you’re thinking about creating a side project, you’re essentially thinking like anyone else in a creative field. It’s like an author saying “what story should I write next?” The only response that makes sense to me is “well, what’s something that would be fun for you?”

Maybe you really just don’t know what you should make. Or maybe you’re suffering from the developer’s equivalent to writer’s block. I think I’ve found a fairly good formula for thinking about side projects (see the TLDR;) and thought it might be helpful to share for people who find themselves asking these sorts of questions.

Who this is for

People who enjoy building things, but don’t know what to make
People who start a lot of side projects, but often end up stuck in “the setup phase”
Junior/mid-level developers wanting to build a portfolio

Who this is not for (but for whom it might still be somewhat useful)

People who want to turn a side project into a side business
People who want to mainly focus on OSS development

Who, really, is going to use your thing?

I think some of the hesitation about what sorts of things to create comes from the following desire: you want to build something that other people will want to use or will think is cool.

First off, if you really do have a novel idea that you think other people will also find useful or interesting, that’s great! Go ahead and buy that domain name and start that side-business, or if it's more of an open source-minded project, then go ahead and publish the repository, share the project, and enjoy watching the number of stars climb on Github.

The problem is, however, that unless you have a specific problem or community of users in mind, it’s difficult to know what other people might want. Companies spend a lot of money trying to understand what things they should make. It’s actually a whole field in and of itself. If your main goal when developing something is external acclaim, you might be a little discouraged when the response is lukewarm, or at worst, no response at all.

What if you just focused on creating something that you, yourself, actually want to use? The great thing about creating something for yourself is that you have a clearly defined user (yourself) with clearly defined conditions (whatever it is that you want). It’s a one to one feedback loop between the creator and user. Who cares if other people think that the thing you made is innovative or unique? It is innovative and unique in and of itself because it is built for a very particular user with very particular desires.

Example 1: A shopping list

Here’s an example: I wanted an easy way to share a shopping list with my wife. She’s not that technically savvy, so the UI needed to be extremely simple. So I made a little web app that lets us share a shopping list. In other words, a todo list – the most basic and boring thing that you could ever create.

There are thousands upon thousands of apps that we could have just used. I’d even made a few todo lists before. But it doesn’t matter. There’s no outside audience here. It was just me creating something for the joy of it, that actually solved a problem that I had in my life, and that was actually useful to someone – even better in this case, two people! And it was technically interesting enough for me. I wanted to play around with Firebase and it was a perfect opportunity. And hey, I now had a public, (minimally) feature complete project that I could point to (albeit, not one that I think would be interesting or worthwhile to anyone else, but that’s besides the point.)

Don’t worry, the point of this is not to say “just build a bunch of todo apps!” The point is to try to convince you to avoid creating unnecessary expectations before you’ve even started. Going back to the comparison of creating a side project to writing a book, it’s important to avoid “preparing your acceptance speech for the Pulitzer Prize before even writing a single word.”

Again, if you have an innovative idea for something that you think will turn into an exciting open source project or lucrative side business, that’s awesome. But if you don’t, that doesn’t mean you shouldn’t be creating things. The path from side project to passion project to OSS project/side business is a natural one, and much more realistic than starting with the goal and working backwards.

Keeping it technically interesting (i.e. killing the right number of birds with the right number of stones)

Another important ingredient for a good side project is choosing what kinds of technologies to use. You want to build something that is creatively and technically interesting to you. It should be fun. My advice here is to choose enough new things that the project itself is technically stimulating, but not overwhelmingly so.

Any developer who has worked on a side project has inevitably found themselves in the following situation: you’ve got a Saturday all to yourself and you have a good idea for a new project. Your mind starts racing. "I’ll try using this thing for the first time. I’ll research all of the newest build tools, frameworks and libraries, and make sure everything is perfect."

You start reading documentation and hacking away and before you know it you’ve just spent the last hour cross referencing various issues on various repositories because the latest version of some library doesn’t work with some other thing and the day is over and you’ve accomplished nothing. You turn off your computer and never touch the project again.

The amount of new stuff to try out really depends on the person. Personally, if I don’t have at least something on a screen by the end of the day, I’ll lose motivation and probably never work on the project again. Some people are more (or less) patient, and the amount of time someone can invest in setting up a project without losing focus will vary person to person. But it’s important to get a sense of what that sweet spot is for you.

It’s also important to remember that not all technologies are created equal. Trying out a new css library is not the same as creating a native application for the first time. Trying out a new framework is not the same as trying out a new language.

Example 2: A personal finance tracker

I’m really bad with keeping track of the money I spend, and so I thought, hey, why don’t I make a little app for logging my expenses. It could have some simple labels like “Food,” “Socializing,” etc., and it could show me how much I spent in each category each month.

Much like the shopping list, personal finance tracking apps are a dime a dozen. And some of them are extremely feature rich, with the ability to link bank accounts or credit cards and even automatically read the data off of physical receipts. But I just wanted something really simple, and I had a general idea of how it would work. And I also just really wanted to make something.

I wanted to try out FaunaDB with its automatic GraphQL api generation, and I also wanted to finally try using the React version of Material UI. Furthermore, I wanted to try my hand at making a PWA. The rest would just be the normal stack of whatever I was comfortable with at the time. I got it up and running fairly quickly, and had the core of it done in a couple weeks. I did a little more development here and there, used it for about a year, and then stopped. But, it’s still there, and still something that I actually used for quite a while.

And in this case, it actually helped me to get my current job. When I first applied there was concern about my experience with React, and so I said: hey, here’s this thing I made. It’s not great, but I think it shows that general experience with React shouldn’t be an issue. And thankfully, they reconsidered.

A note on portfolios: in general, I think it’s good to think about your portfolio less as a showcase that will wow potential recruiters, and more as potential fodder for discussion. If you apply somewhere and there is concern about your experience in some area, you can use it as proof that you at least have experience in that domain.

For this reason, I’d advise against deleting old projects or making them private. No doubt, looking at code you’ve written in the past always feels a little… embarrassing? We grow so quickly and fast as developers, and looking back on a project you created even a year ago can feel like looking back decades in time. But the benefits outweigh the negatives. Your past projects are a record of your growth, and any potential recruiter or employer who wouldn’t it see it that way is, in my opinion, a place that you wouldn’t want to work.

Do it until it’s done (there’s plenty of time to do it better later)

So you’ve got an idea for something you’d like to do, you’ve picked out a couple of new technologies that you’d like to try, and you’ve started to build something. How do you know when this side project is “done?”

Since you’re creating something that you want to use, you naturally have a general idea of what the minimum functionality for that thing is, and the creation of that is what you should be initially aiming for. You can think of it as an MVP, but since this is something that you’re just having fun doing in your free time, it’s ok if it isn’t so formal.

Personally, for me, done is when the initial idea is implemented, the thing "works" and I’ve spent enough time exploring and using the new technologies that I feel technically satiated.

For this reason, I'd advise kicking the can of implementing user-facing sorts of things like authentication, payments, or traffic optimizations down the road unless they are core to the project or part of the new technical things you are exploring. If you finish creating the core experience and feel that it is something worth sharing or developing into a service, then you can handle that sort of stuff later. If you share your project and a bunch of people visit the site and bring it down... congratulations on your newfound fame!

Example 3: A scraper for a podcast

My friend and I have a podcast where we talk about Japanese convenience stores. One thing that we do each week is that we look at all of the new items coming out and then choose ones that we think look particularly awesome or weird. Usually this involves something like 250 new items across seven different convenience store chains. We usually open up seven different tabs and just manually look through each of the items that way.

I thought it would be cool if we could make this process a little bit easier, and so I decided to make a scraper that could get new item data and make it viewable in a custom web app. Someday, perhaps this scraper could scrape all of the data for each convenience store, and maybe we could share it with our listeners. But the minimum functionality that I envisioned for this first step was: try to create a scraper that could scrape the items, and display the items for one convenience store.

In terms of new tech, I wanted to try building a monorepo, and I wanted to play around with Playwright. That was it for new technology for this project. I got it up and running pretty quickly, and in this case, went on to continue developing it fairly regularly. The project has extended into being a sort of passion project, and one that we have actually shared with our audience.

I guess the thing that ties all of this together, and the point that I want to stress more than anything else, is stop inventing unnecessary obstacles for yourself and just enjoy the process of creation. It doesn't matter if your thing is boring, or uses a mediocre stack, or isn't 100% feature complete. It's important that you "actually create things," and that you learn and have fun while doing it.

Working From the Other Side of the World

Michael Markey — Thu, 16 Dec 2021 21:58:50 +0000

TL;DR

Working across timezones is tough, and requires a supportive and flexible team. Communication will become more difficult, but trying to find small things that work for you and your team - and steadily building on those things - can help to make it work.

One of the benefits of working as a developer is the ability to work from anywhere, anytime. But how about when your team is working at a set time, in the same time zone, and only one person is working from the opposite side of the planet?

That was the question that our team had when I boarded a flight in Tokyo, and headed home to the east coast of the United States to work remotely for the month of December.

A little background

A fair number of tech companies these days are fully remote with people working all over the world. Some companies have "work anytime, anywhere" implemented into the core of their company culture. Without a little bit of context, what I'm writing about probably doesn't seem all that interesting.

I'm a developer in Japan. Within Japan, I work remotely, as does the rest of our team for the most part, and so working remotely is something that we as a team are used to. Like many people living abroad, it's been quite a while since I've visited home because of Covid. With this in mind, the company that I work at, Globis, introduced a system allowing international staff to visit home and work remotely for a few months to spend time with our families.

We use scrum as our development strategy, usually working in two week sprints. We have a daily stand-up, weekly product backlog refinements, as well as various other meetings where we refine tasks, discuss on-going issues, and communicate with other teams – not to mention the more general division and company-wide meetings.

Who we are

two frontend developers (me included)
two backend developers
1 scrum master (and frontend/backend hybrid developer)
1 product owner

How we work

Communication: we have a good mix of text and voice, with lots of jumping into calls to talk things over
Working together: many days will include at least a little bit of pair/mob programming or actively working together in some way
Input from everyone: not many decisions are made just by one person, and we like to hash things out before deciding on things
Rhythm: we try not to let issues sit for too long, and value quick back-and-forth in code reviews

The issue

So we're a fairly small team, working remotely in Japan, who enjoy working together. If I was going to try to work purely according to Japan hours, I would be working from 8pm to 4am each day, which would be tough. The question was, "How could we maintain that level of communication and still maintain a healthy life style while having little overlap between time zones?"

(For reference, here's the overlap between JST and EST)

The first thing that we did, was that we made sure that the times that we did overlap would be focused on in-person activities: one-on-one meetups, pair programming, discussing important issues, etc. We figured that the best chance we would have each day would be 10am-12pm JST for the team, and 8pm-10pm EST for me.

Originally, my plan was to work from around 2pm until 10pm each day, but because of jet lag – and also the fact that I'm just a morning person in general – I ended working a morning block from around 5am to 9am, and an evening block from around 6pm to 10pm. It actually worked out great, as I would work until my wife and 2 year-old son woke up, hang out with them for the day, take a nap with my son in the afternoon, eat dinner and then jump back on to work in the evening.

Keeping in touch

As I mentioned, we're a team that values communication, and so we wanted to try to somehow maintain that level of communication while in the states.

A few things that I did which I think worked pretty well were: 1) create a daily remote log, and 2) send a video message on Slack each morning.

For the remote log, I basically kept a daily blog in Notion where I would take notes about the work I was doing, the problems I was having, some things that I thought were funny, and even a daily picture from my time in the states. The content was focused on anything that wouldn't fit cleanly into pull request comments, JIRA ticket logs, or the other channels that we have for topic based communication.

For the video message, I would record a one minute or so video each morning and share it in our Slack channel. The content wasn't really too important - more than anything it was just me trying to show my face and make sure everyone remembered my voice. I think people enjoyed it (or at least they made it seem that way 😇.)

Furthermore, we set up a 15 minute block each Monday morning (Sunday evening for me) for just a quick, fun, random chat between the team.

Record everything

One of the biggest concerns that we had as a team was how I would be able to keep up with the daily/weekly scrum events. Our scrum master thought it would be good to record all of our meetings so that I could watch them, and so that's what we did. To start, he would link the video for each meeting on Google Calendar, but we quickly felt that it was too much of a hassle. In the end, we ended up making a new channel on Slack where the videos would be posted whenever the recording was complete. It ended working out well, and I think it was a pretty cool solution.

Besides the meeting recordings, we also started to use Slack video messages for discussion about code as well. Of course, we did the main communication by text in the pull requests, but we found that sometimes it was easier to explain things simply by sharing your screen, and talking through what you were doing. Something that could take hundreds of words and a lot of thinking/editing in a pull request comment, could sometimes be more cleanly illustrated by explaining your reasoning while walking through the code, highlighting some variable and function names, and the always helpful phrases of "you know what I mean" and "something like that."

My general schedule

Here's the schedule that I came up with, that worked out for me.

Morning block (5am - 9am)

Log on
Drink some coffee
Catch up on Slack, make sure nothing's broken
Create today's remote log, and start taking notes
Chat with people if anyone is still awake
Watch the previous day's daily standup video, as well as any other meeting videos from the previous day
Do work (coding, PR reviews, documentation, other stuff etc.)

Evening block (6pm - 10pm)

Continue working
Finish today's remote log
Check-in on Slack with a video message and link to the daily remote log
When everyone gets on, have meetings, talk about work with coworkers
Figure out what I'll be doing the next day
Log off

A case study

During my time in the states, the main task that I was working on was the implementation of a logging mechanism for our web app. Without going into too much detail, the project is a bit of a tricky one, as it's centered around things that the user touches - buttons and links, and those sorts of things – and has pretty wide ranging consequences for our code base. We wanted it to be close enough to the code that we could get the necessary data that we needed from user events, but not too close that it would be baked into our logic or components.

The mobile app team had implemented a similar sort of mechanism, and so we originally planned to keep the general structure of the event names and properties as close to the mobile app as we could. However, we quickly learned that things would need to be a bit different for the web. It was the sort of project that required a bit of coming up with a plan, trying it out, and then rethinking things as we got a greater sense of how the architecture of everything would play out.

Normally, this sort of thing would happen throughout the day, with bouts of writing actual code mixed in with little meetings and some back and forth across Slack. However, because of the time difference, things happened more in blocks: I would spend the day when everyone else was asleep working on the code, then spend the evenings (or, mornings for the team) talking with the other frontend engineer about the implementation, sometimes leaving unanswered questions to him while I would go to sleep, and vice-versa.

It had its ups-and-downs, but one day in the early morning (late evening in Japan), my coworker and I were able to release the core logging mechanism onto the production server. It was an exciting moment, as it is anytime you find a solution that you feel comfortable with. But it felt extra sweet because we had managed to release it while working across the divide of 10,000 km and 14 time zones.