DEV Community: addison-codes

Teamwork to Make the Dream Work

addison-codes — Mon, 08 Mar 2021 15:34:55 +0000

Working on a team is a challenge. It is no doubt a necessity but it is something that is far too often ignored as a potential point of improvement. Each person on a team has their own unique set of experiences, skills, strengths, and weaknesses. The difference between an effective team and an ineffective one is based on how well the members recognize where each other excel. By getting a grasp on your own strengths and weaknesses, communicating them to the rest of the team, and working to find how to best support others (instead of finding how to be supported) a team can increase productivity and efficiency.

How we determine our own strengths and weaknesses is different for everyone. One effective way is to practice your skills solo - don't rely on anyone and see what you can get done. Try new tasks or doing old tasks a different way and look for things that you enjoy doing and are good at. We can also try working with different teams often. As long as there is good communication, finding out how to adapt ourselves to support teammates is something that we can consciously pay attention to in order to discover what works best.

It is also important to know that it's important to practice things that we WANT to practice or learn. If you want to understand more about certain processes or develop a new skill, then just by letting your team members know that you want to learn you can start being included in discussions surrounding that. Most of us naturally like teaching - and teaching is a fantastic way to further develop your own skills.

The most important part of this process is communication. Make sure you put in some effort to understand what your team members are good at and what they want to practice. As a potential action item, take some time this week to let your teammates know something that you want to get more experience with and ask how you can better support them.

Are you a solo dev and want to get a job? 3 tips and some warnings.

addison-codes — Fri, 29 Jan 2021 06:13:03 +0000

No matter how experienced you are as a developer, working on team is (as I've recently discovered) hugely different than working alone. This is an exploration into the transition - with a few tips to prepare yourself.

My Beginnings

I was an off-and-on solo web developer for about 8 years. Starting in high school, I entered the webdev space and slowly built up my skillset. Even though I was doing some freelance work that made me some decent money, I always sort of felt like a lesser developer. I'd look at things like JS Frameworks and read blog posts from well known developers and think this is way beyond me! Well, it was beyond me, but I hadn't yet realized the amazing foundation I'd built for myself.

It was one of Traversy Media's Web Developer Roadmaps that showed me just how close I was to turning web development from a hobby/occasional-income-earner into a profession.

Fast forward about a year and half and now I'm on an amazing team of developers making custom cloud applications for clients - one of the best development gigs in my area.

Your Beginning?

If you are like me - having only worked with yourself on coding projects - it can be really hard to gauge where your skills are. With imposter syndrome ever looming, it's so easy to forget that you are skilled. To gauge where you are, I definitely recommend one of the Web Developer Roadmap videos - Traversy Media's are fantastic but there are lots of good options.

Once you know where you are, you know where you can go and what you can learn to improve. Maybe you're already standing at the top; maybe you just discovered that you were nowhere near as knowledgeable as you thought. You are, at the very least, well on your way to a valuable skill. What you are lacking, however, is experience working on a team.

Solo Vs Team

Getting this experience is not easy without a job. This kind of experience is one of the great things you receive when learning web development at a bootcamp or college. That said, if you are self-taught or come from a path that never allowed you to work on a team, you can definitely prepare yourself.

First and foremost, you need to understand the fundamental differences:

Solo	Team
You work at your speed	You work at the team's speed
You (or a linter) are your only code reviewer	Someone will be reviewing your code - and it needs to make sense
Git is useful to keep a log of your progress	Git is essential to understand so the team can work on similar things effectively

Now here are a few things you can do to prepare:

1. Open Source

Taking part in open source projects is the best way to get experience working on a team. Not doing this is my biggest regret. There are a lot of good resources out there detailing how to get started contributing to open source - it mostly seems to boil down to: Start using open source software; find something to improve; improve it.

2. Find a buddy

This one is a little more difficult and requires a slightly higher emotional investment, but the payoff is potentially much higher. Involve yourself in some online communities (like dev.to!) and connect with others that may be in the same boat. Having someone to hold you accountable, read your code, or just bounce ideas off of will be a great start towards team experience.

3. Learn something unique

If you can bring something to a team that no one else has, then you are automatically valuable. Master one technology, even if it's something small, and be passionate about it. Once you're on a team that passion will be infectious and everyone can learn from you.

Supercharge your project with each commit using 3 awesome tools.

addison-codes — Thu, 21 Jan 2021 04:57:54 +0000

The Trifecta

Conventional Commits, SemVer, and Standard Version

Do you know those projects that have a cool version number like 3.23.12? And they have a nice changelog that shows the changes in each version? If you're like me, you love the idea of being that organized, but you don't love the idea of doing more busywork when you want to focus on coding. Well, you're in luck, because with a few tools we can automate the whole thing!

There are three tools that we can use to accomplish this:

Conventional Commits (A convention for how to write commit messages)
SemVer (Semantic Versioning - the nice X.X.X version number system)
Standard Version (A node module that automatically updates a changelog with version numbers and commit info)

The best part of all of this is that you can slowly transition into using these tools. You don't have to make any big changes or commit to making a permanent change to your workflow or repository.

Step One: Get Familiar with Conventional Commits

Conventional Commits is a standardized way to write your commit messages - as well as the driver of this whole operation. Basically, when writing your commit messages all you have to do is follow a standard format. It may seem complicated at first, but with a little bit of time and the Commitizen VS Code Extension, you will quickly find it feeling natural. Firstly, it would be best to familiarize yourself with the convention, you can read up on it here.

Using Commitizen in VS Code will do the heavy lifting for you. Instead of committing via command line or VS Code's built-in Source Control, you can just open the command palette (ctrl-shift-p) and type select Commitizen. It will prompt you for all of the necessary information and format your commit message according to the standard. Then you can just push your code up as you normally would!

Conventional Commits alone will make an awesome addition to your development arsenal - if a whole team transitions to Conventional Commits, you will notice all changes to the repo are far more readable.

Step Two: Understand Semantic Versioning

Semantic Versioning is far simpler to understand. You can read up on it at the site, but it's simple enough to quickly explain here.

The version number is split into three sections with .'s like so: 2.5.11 - and each number has its own distinct meaning. I'll explain from the bottom up.

1.1.Z Z = Patch version. This starts at zero and increases with every backward-compatible bugfix or patch that is implemented.
1.Y.1 Y = Minor version. This starts at zero and increases with every backward-compatible new feature or functionality that is implemented. Every time this goes up, reset the patch version to 0.
X.1.1 X = Major version. This starts at zero and increases with every major change or addition of functionality that is not backward-compatible.
Note: If you reach number 9 for any of the versions the next increase is 10. This can even get into the triple digits, ie 1.2.99 => 1.2.100.

In your projects, you can feel free to apply these versions in whatever way makes the most sense to the project. For instance, in some projects, I might increase the major version at each milestone instead of waiting until a breaking change.

Step Three: Use Standard Version to Automate

Finally, you can use the node package Standard Version to automate the process of creating and updating a changelog. It uses your conventional commits to understand the changes you've made and updates your version number accordingly. The changelog that it generates also succinctly lists the changes in each version.

To use it, you can install it to your project as a developer dependency with this command: npm i --save-dev standard-version.

To run it for the first time: npm run release -- --first-release.

To run it for your normal releases: npm run release.

If you want to release a major or minor version regardless of what your commits indicate you can run: npm run release -- --release-as CHANGE - replacing CHANGE with either major or minor. Also, you can release to any version you define with npm run release -- --release-as VERSION - replacing VERSION with any number you like such as 1.2.0.

Running the release command will generate a changelog and you can push your code to your repo.

Other notes

If you are working in a repository that utilizes multiple branches and merges. You can explore using squash merges so the versioning and changelog only apply to the branch you want them to.

All three of these tools are powerful in their own right, but once you are comfortable using them you can explore some of their more advanced features and make your project organization even better.