Forem: Michael Gee

Build Side Projects You'll Actually Be Passionate About

Michael Gee — Wed, 09 Dec 2020 16:45:55 +0000

All too often I come across the common joke of having half-finished or abandoned software development projects most likely because so many people (including myself) can relate to it.

Why? 🤔

I strongly believe that most side-projects are doomed right from the start.

People gather inspiration from these "10 Project Ideas For Your Portfolio" posts that are usually pretty vanilla and have been built a million times before. To me, they just seem to lack inspiration and creativity.

There's nothing wrong with building these projects for learning purposes and showing companies your current skill set, but these are the projects that you'll work on for a couple of weeks and then never be touched again.

A Better Initial Approach ✅

Find your own custom solution(s) to problems in an industry that you are passionate about.

The project ideas that I have been by far the most passionate about are the ones that I come up with myself and involve industries that I am interested in like software development, sports, gaming, etc.

Being more familiar with the industry gives you a much better opportunity to recognize common problems and think of possible solutions. These solutions are now the potential birth of your next project 😄

Yes, this approach will take more time to brainstorm and plan but it also unlocks a ton of motivation and prevention of burnout in the long run.

Projects become boring when they start feeling like work, building your own projects on your own time is a much more enjoyable experience and can lead to endless learning opportunities.

Do Some Research 📖

Before moving forward, take a little bit of time to look around and see if this problem has been solved before or how often the problem is being encountered.

Has this problem been solved before? If so, how can you make it better? How long do estimate it will take to build? Do you want to put that amount of time into building it?

Try to determine if your project is leading towards a dead-end before you reach it.

🚦 Slow Down... Start with Proof of Concept

Great! So now let's assume you have your perfect idea and are ready to take over the world!

But let's slow down... before you spend the next few months keeping your idea behind a curtain for a grand reveal, I'd recommend more of a deploy now & optimize later approach.

If you are someone who wants to build something more mainstream, I much would suggest deploying early & often to see if it gains the interest you expect before wasting countless hours on it.

Popularity isn't everything, if you build something just a few people would benefit from I would consider it a success.

The main goal here is deciding to solve a problem and then building the solution. You prove to yourself and others that you can solve real-world problems and use that momentum to solve the next one!

Show Your Idea To The World 🌎

Along with everyone else, I wish I had a magic marketing button (follow my Twitter 😉) that gets the word out about the next great thing I build.

Back to reality... finding ways of getting your ideas & work in front of people's eyes is just as difficult/important if not more than building the idea itself.

Learning in public and showing in public can be 2 great ways to increase traffic as you continue to build your project.

For example, writing blog posts or creating YouTube videos explaining how you solved a technical problem or introduced a major feature can generate a good amount of traffic.

Not only will you help the community that encounters the same problem that you did, but it will attract people to what you are building, and who knows maybe some people would be willing to contribute to the project!

Side Project -> Business 💼

Unfortunately, most projects never get to this point.

With a great idea and a strong initial backing, you can decide if your project would be something you would want to work on full-time or not.

This decision can be difficult especially for people who have consistently paying jobs and see it as a possible risk.

Every case is different so there is no one right answer so I won't go too much into detail on how to go about this... especially because I don't have a side project that has reached this state (yet) 🤐

Showcase Your Side Projects 🏆

Do you have a side project you are currently working on and are proud of? I would love to see some in the comments and check out some of your work.

Prevent Your Codebase From Becoming A Spaghetti Factory

Michael Gee — Tue, 29 Sep 2020 15:44:00 +0000

Remember that one time you were looking at your team’s codebase (or even your own) and thinking “who the hell wrote this code…?” just to have that awkward moment when Git Lens shows it was actually YOU who committed the code.

I’ve been there, done that. There’s nothing worse than the realization that the huge bowl of spaghetti code 🍝 you’re looking at came from your own 2 hands.

Gordon Ramsay would be ashamed.

The Problem ☠️

Deadlines exist, features are requested at an accelerated rate, and you can sometimes get caught weighing quantity over quality.

Although nothing may seem wrong on the surface to a user’s perspective, rushing these things can sometimes make the codebase slowly but surely begin to become inconsistent, hard to read, and overwhelming especially for new onboarded developers.

Focusing on pushing new features is great and all until the time comes when you find yourself refactoring more code than you're implementing.

I have experienced this in the past and wanted to provide some of the ways I try to avoid this happening before it happens to you and your team.

The (Partial) Solution 🛠️

Better Variable & Function Naming ✅

The next time you think of naming a variable...

const data = {}

or a function...

function _handleOnClick() {}

...take a little more time to better describe what the object is storing & what the function is doing.

I already know that data is coming from the server, but what data? I already know this method is attached to a button onClick, but what is happening when it is clicked?

This can sometimes be tricky, you can find yourself spending more time sitting there thinking of better ways of naming things than actually writing the code.

Trust me it is worth it.

Instead of thinking of names before implementing it sometimes I initially give it a generic name and then once everything is hooked up and working I go back and ask myself:

“How can I make this code more readable for someone who has never seen it before?”

(Or myself when I look at it again 6 months from now)

Naming things can sometimes be easier after it is implemented because you can then see all the implementation details of what it does.

Design Patterns ✅

The good news is that you don't have to reinvent the wheel, there are already design patterns to solve commonly occurring problems in software design.

The bad news is that there is a lot of them. This topic alone could be its own blog post and realistically would be more than one although you have probably already used some even without knowing and you don't have to memorize every single one of them.

That being said, I'll just list some resources I used to get started:

Consistent Project Structure & Flow ✅

It is so much easier to navigate and read a codebase if you have consistency in things like a folder, module, and code structure.

Don't you always feel more comfortable working on your own personal projects?

You know where things are & should be, keep everything consistent in the way things are done, and know how to go about making changes to the codebase.

Obviously, this takes more time to implement in a team environment but is definitely worth sitting down with team members and figuring out an agreed-upon approach for different aspects of your project.

Good Test Coverage ✅

Tests are documentation and a safety net for developers. They should describe what the specified code is responsible for and what its expected outcomes are.

It is much easier to read the descriptions of these test cases than going line by line figuring out what the code does in its implementation.

TEAM Code Review ✅

When new code is requested to be merged, it is the responsibility of ALL developers on the team to view the PR and be aware of the changes being made.

It is much easier to continuously stay updated on the changes made to the codebase than getting an assigned user story or bug fix to code that you have never seen before.

Use Comments In Your Code ✅

It is inevitable that you will have to code an algorithm or logic that is a bit more complex than normal.

In these scenarios simply adding a comment describing the logic the same way as a test case describes the test it is about to run will help the reader quickly understand what the code does.

I tend not to leave comments on everything because if you are naming your stuff correctly like mentioned above, you really won't need to.

Conclusion

Computers and code are what make your websites and applications run but you need to also remember that humans need to be able to read and easily understand the code as well.

Utilizing some of these techniques and learning from experience can help decrease the time you find yourself refactoring your codebase.

No more spaghetti! Write better code and make Gordon Ramsay proud 👍

Start Using React.js

Michael Gee — Tue, 22 Sep 2020 15:46:17 +0000

This post is a response to the post that got some traction last week Stop Using React.

I feel like this post was a bit misguiding because it lists problems but no real solutions or alternatives.

Instead of focusing on the negatives, I instead would like the focus on the other side of the argument and the benefits you get from using React.

Solve Real-World Problems ✅

Let’s be real here if you literally just want to print “Hello World” to the screen or have a single page CSS portfolio you probably don’t need the additional JavaScript.

But let’s go back to the real world, companies solve more complicated problems and require more complicated solutions.

If you want to spend months wasting time recreating what React and its ecosystem provide out of the box just for MAYBE getting a couple of seconds of performance increases, please be my guest.

The Job Market 💼

Once I finally bought into learning React, it took me about 4-6 months to find a job. Jobs with React in the requirements or recommendations are everywhere and for good reason.

I believe it is smarter for companies to use more mainstream technology so the onboarding process of hiring new developers into their companies isn’t a bigger hassle than it already is.

It’s hard to find good developers that meet your cultural and technical needs, so having a larger pool to search from is obviously going to make this process much simpler.

“That Company” 🏢

While I don’t always agree with the actions of "the company" itself, I find the React core team to be a great group of people who are passionate about keeping the library and its ecosystem great.

These "companies" continue to provide great free open source technology for others to use. Yes, this does mean sometimes you can get vendor locked but it is your choice to make.

In my opinion, the benefits HEAVILY outweigh the costs.

Ecosystem and Community 👥

It’s overwhelming trying to fathom just how huge the React ecosystem is.

I never feel stuck when developing with React. If you come across a problem, 9 times out of 10 there will be a well maintained external library that solves it.

I have a post here that goes into some of the pros and cons of this so I won't list them here.

TLDR: Choose external libraries that are well maintained and backed by the community.

Performance 📈

It's not a secret that adding React or any other major JS framework to your project will come with performance costs.

Especially if you show statistics of a bloated create-react-app that doesn’t include code splitting and other performance enhancements the performance metrics probably will suck.

There are multiple ways of not only improving these performance metrics but providing users with visuals that will occupy their time until the screen is interactive.

It’s easy to forget that React is built for and used in some of the most visited websites in the world.

Let's consider the hundreds of MAJOR use cases like Facebook, Uber, Netflix, Instagram, Salesforce, Medium, Reddit, AND WAY MORE that ship React to millions of users daily.

Don’t you think these companies have thought of these metrics? If the performance is so bad, why do they all use it? So consider the point it’s not React itself affecting your performance, it’s how the developers implement it.

#UseThePlatform… I’ve Been There, Done That 🤦‍♂️

I’ve been on the other side, I was a huge advocate of #UseThePlatform and not needing all that extra bloated JS coming from JS frameworks.

Ever head of Polymer.js? Probably not. I will admit I loved the technology and the ideas it originated from. I loved the people behind it who were passionate about it and used it internally at Google.

There was a lot of hype and initial backing but never really got off the ground. It never got anywhere close to the external features and community support that you would get by some of the other popular JS libraries.

I constantly found myself stuck in development looking for answers which is what eventually lead me to React.

I now have 2+ years of professional experience with React and I have not looked back since.

Conclusion

This is my take on the high-level benefits to using React. There are many other benefits (developer experience, usage of JavaScript, and many others) although this post was mainly focused on responding to the opposition.

That being said, some of the benefits could also be directly applied to some of the other major JavaScript libraries/frameworks and is not exclusive to React.

As always, if you like this post give me a follow here on DEV and on Twitter.

My React.js Library Bookmarks

Michael Gee — Tue, 08 Sep 2020 15:54:25 +0000

React mainly focuses on what it does best (rendering UI components to build user interfaces) and leaves the gaps to be filled by the huge community of developers and companies.

This means the number of popular libraries and ways of doing things can definitely add up which has its pros and cons:

Pros ✅

You are not locked into one way of doing something, you have an array of great options to suit your needs the best.
React has a HUGE ecosystem of people building and maintaining libraries, so odds are if you need to do something in particular there will (9 times out of 10) be an open-source npm package for it.

Cons ❌

This can be confusing for beginners. Since you have so many options, people sometimes just go for the most popular one even if it doesn’t necessarily meet their needs.
The latest and greatest is constantly changing, it is important to choose libraries that are actively maintained and will move forward with industry standards when it does.

With that being said, here is a list of the React libraries I currently have bookmarked. These emojis next to each library show my personal experience with each library:

⭐ - my all-time favorites
✅ - have used in production and would advocate for
🕒 - have never used but am planning on using in the future
🤔 - have never used but would be interested in
👋 - have used in production but have since moved on from

Component UI Libraries

Semantic UI React ✅ https://react.semantic-ui.com/
Fluent UI ✅ https://developer.microsoft.com/en-us/fluentui#/
Chakra UI 🕒 https://chakra-ui.com/
Ant Design 🤔 https://ant.design/
Material UI 👋 https://material-ui.com/
React Bootstrap/reactstrap 👋 https://react-bootstrap.github.io/

State Management

React Internal State / Context (not a library) ✅ https://reactjs.org/docs/context.html
Redux 👋 https://redux.js.org/

Client-Side Routing

react-router ✅ https://reactrouter.com/

SSG (Static Site Generation) / SSR (Server-Side Rendering)

Next.js ⭐ https://nextjs.org/
Gatsby 🤔 https://www.gatsbyjs.com/

Testing

react-testing-library ⭐ https://testing-library.com/docs/react-testing-library/intro
Enzyme 👋 https://enzymejs.github.io/enzyme/

Forms

react-hook-form ✅ https://react-hook-form.com/
formik 🤔 https://formik.org/

Animations

framer/motion 🕒 https://www.framer.com/motion/
react-spring 🤔 https://www.react-spring.io/
react-motion 🤔 https://github.com/chenglou/react-motion
react-transition-group 🤔 https://github.com/reactjs/react-transition-group

Async

react-query ✅ https://react-query.tanstack.com/

Data Tables

react-table ✅ https://react-table-omega.vercel.app/

Internationalization

react-intl ✅ https://github.com/formatjs/formatjs

Honorable Mentions ➕

These are some other libraries that I have bookmarked/starred but have not yet used in production.

Drop-downs

react-select https://react-select.com/home

Drag & Drop

react-dnd https://react-dnd.github.io/react-dnd/about
react-beautiful-dnd https://github.com/atlassian/react-beautiful-dnd

Document `<head>` Manager

react-helmet https://github.com/nfl/react-helmet

Icons

react-icons https://github.com/react-icons/react-icons

Loading Spinners

react-spinners https://github.com/davidhu2000/react-spinners

Social Media Share Buttons

react-share https://github.com/nygardk/react-share

Responsive Styling

react-responsive https://github.com/contra/react-responsive

With the vast ecosystem of libraries, I am sure that I left out some good ones. If I did, leave some of your favorite libraries in the comments and let me know what you think of the list!

Also if you like web development and meme content follow my Twitter 😄

Quick Tips & Resources To Improve Your Github ReadMe

Michael Gee — Wed, 26 Aug 2020 15:48:13 +0000

Unless you have been living under a rock for the past few months, you are probably aware that Github has a cool new feature where you can create a custom markdown README intro for your Github profile page.

I finally got around to creating my initial implementation and wanted to share some quick tips and resources I came across while doing it.

Getting Started? 🚧

For getting started or finding new ideas and inspiration, you can't go wrong with an awesome-* repository!

Repository: awesome-github-profile-readme

I highly recommend going through various examples and gathering inspiration from multiple sources.

To see the markdown implementation of a profile click into the README.md file and click the "Raw" version shown in the image below:

Once you have an idea of the direction you want to go you can get started!

Emojis 🤔

You will quickly notice that emojis are all over the place in almost all the examples you will find.

Most emojis are supported in markdown and you can find a full reference list:

Markdown Emojies Cheat Sheet

P.S. You can also use these same emojis in your Dev.to posts since it is also using markdown.😉

Displaying Your Dev.to Blog Posts 📕

Luckily there is already a great blog post that goes over this:

Show your latest dev.to posts automatically on your GitHub profile readme

Video Resources 📽️

Next Level GitHub Profile README

UPDATE: Next Level GitHub Profile README

These videos go over various features that can be added to your README including displaying blog posts, YouTube videos, Github stats, icons, badges, currently playing Spotify songs, and more!

Bonus ➕

You might notice that a lot of examples will have no space in between the emoji and the text:

To manually inject spaces in between the two you can add   spaces:

- :computer: &nbsp;&nbsp; I'm a full-stack software developer.
- :briefcase: &nbsp;&nbsp; Currently working on...

Forem: Michael Gee

Build Side Projects You'll Actually Be Passionate About

Why? 🤔

A Better Initial Approach ✅

Do Some Research 📖

🚦 Slow Down... Start with Proof of Concept

Show Your Idea To The World 🌎

Side Project -> Business 💼

Showcase Your Side Projects 🏆

Prevent Your Codebase From Becoming A Spaghetti Factory

The Problem ☠️

The (Partial) Solution 🛠️

Better Variable & Function Naming ✅

Design Patterns ✅

Consistent Project Structure & Flow ✅

Good Test Coverage ✅

TEAM Code Review ✅

Use Comments In Your Code ✅

Conclusion

Start Using React.js

Solve Real-World Problems ✅

The Job Market 💼

“That Company” 🏢

Ecosystem and Community 👥

Performance 📈

#UseThePlatform… I’ve Been There, Done That 🤦‍♂️

Conclusion

My React.js Library Bookmarks

Component UI Libraries

State Management

Client-Side Routing

SSG (Static Site Generation) / SSR (Server-Side Rendering)

Testing

Forms

Animations

Async

Data Tables

Internationalization

Honorable Mentions ➕

Drop-downs

Drag & Drop

Document <head> Manager

Icons

Loading Spinners

Social Media Share Buttons

Responsive Styling

Quick Tips & Resources To Improve Your Github ReadMe

Getting Started? 🚧

Emojis 🤔

Displaying Your Dev.to Blog Posts 📕

Video Resources 📽️

Bonus ➕

Document `<head>` Manager