DEV Community: Richard Sween

Host Amplify Projects without Buying a New Domain

Richard Sween — Fri, 25 Sep 2020 19:24:52 +0000

Like a lot of developers, I tend to work on side projects in my spare time. Some of them (ok, a lot of them) never really get to the point where I'm ready to pay to host them at their own domain. At the same time, it would be nice to be able to host some projects with an easy to remember URL without paying for yet another domain.

Backstory

I ran into this recently with the Red Dead Naturalist Tracker, a project I mentioned in last week's blog about localStorage. It was a project mostly for me, but I wanted to be able to get to it easily and share it in action. I used AWS Amplify for hosting since it's so easy and cheap to get up and running, and by default that does give me a publicly accessible URL (with https no less!) that looks something like https://my-branch-name.my-random-project-id.amplifyapp.com. Rolls right off the tongue and is super easy to recall, right?

But there's a better (and free!) way to manage these side project URLs. If you're somewhat familiar with Amplify, you may know that you can set a custom domain for you Amplify project, so you can host it at https://my-cool-domain.com for example. But, you don't have to set your Amplify project to run at the root of a domain.

Prerequisites

For this to work, you do need a domain that you own that you manage. On this project I'm using my main domain at richardsween.dev. I have AWS Route 53 managing my domain's DNS, so it's easy to pull that into Amplify, but you don't have to do that if your domain is managed elsewhere. Amplify will provide you with DNS records you will need to add to your domain to connect Amplify to your domain. Check out the instructions for connecting a third-party DNS to Amplify for more information.

Setting up Project Subdomains with Amplify

First, log into the Amplify console and select the project you want to set up. In the left sidebar, under "App settings" click on "Domain management". You should see your default amplifyapp.com domain listed here. Click on the "Add domain" button in the upper right of the window.

Enter the domain you wish to use in the box. If it's managed by Route 53, it will be pre-populated in the dropdown for you. Then click the "Configure domain" button.

The subdomain configuration settings should now appear under your domain name. Two things to change here. First, click the "Exclude root" button next to the first subdomain entry. This will prevent Amplify from taking over the root domain URL. Next, change the second subdomain entry to whatever you want your subdomain to be named. In this example I called it "rdr-tracker", so once the changes are deployed, my project would be available at "https://rdr-tracker.example.com". If you have multiple branches or environments set up, make sure you choose the correct one in the dropdown next to the subdomain you've given it. I only have the one "main" branch, so I'll leave that as is. If you do have multiple branches that are deployed by Amplify, you can click the "Add" button to set up a unique subdomain for each one. When you are finished setting up subdomains, click "Save".

Now, Amplify will begin the process of setting up your domain, issuing the SSL certificate, and creating the DNS records you will need to be able to access your project. During this process, there may be steps Amplify needs you to do to verify your domain or set up DNS records if your DNS isn't managed by Route 53. Any actions you need to take will be shown on this page.

Wrap-up

Once Amplify completes its configuration process your project will be live at its new, easy to remember, personalized subdomain! This process could be extended beyond simple side projects as well. Freelancers or agencies could preview client work or samples on a branded preview domain (Amplify lets you password protect projects if you wanted to restrict access). Companies could host multiple services under the same company domain with different leading subdomains. There are tons of applications for this approach.

I hope you found this technique useful. I've already used this approach in several personal and work projects with success. So the next time you want to show off some thing you've been working on, don't send someone a generic default URL, show them your personalized, branded URL that you set up!

Cover Photo by Kai Oberhäuser on Unsplash

Building a Backend-less Web App with LocalStorage

Richard Sween — Fri, 18 Sep 2020 14:14:26 +0000

I recently wrote a post about how knowing how to code is a useful skill that can be applied to problems in everyday life, not just as a career. In that post, which you can read here, I talked about how I wanted to keep track of my progress in a video game and how I created a simple web app to solve my problem. In this post, I'll walk through my process of creating the app using the Web Storage API in JavaScript to handle my data storage without needing a database or user accounts.

Designing a Backend-less Web App

I go into more detail about my problem in my last post, but the basic premise is that I had several lists of items that I wanted to track. I knew that I wanted to keep things as simple as possible, so that meant no database, no user registration/logins, and no API. I decided to use React for the frontend, which admittedly was probably overkill, but it was easy for me to build something fast. I also knew that I would plan on deploying the app to Amplify since I've had a lot of success recently deploying projects using it. Since I wanted to store all my data on the client device, but I wanted data to persist between sessions, I decided to use localStorage in the browser to act as my data storage for the app.

What is localStorage?

Per the MDN docs, localStorage allows you to store data on a client device that is saved across browser sessions. That means that even if the user closes the tab or browser window, the information you stored will still be available to your web app the next time the user visits your page (the caveat to this is private or incognito browsing modes, localStorage is cleared when the last private tab or window is closed). The localStorage object stores your data as a dictionary of key/value pairs.

There are two major limitations of localStorage. The first is that both keys and values in localStorage must be strings. There are some ways around this limitation of course. Primitives can of course easily be turned into strings and then parsed back into their primitive type. For JavaScript objects, you can call JSON.stringify(obj) to turn the object into a string for storage, which you can then use JSON.parse(string) to covert back into an object. You could even store files or images in localStorage if you store the raw image data as a string, but I wouldn't recommend it.

The second limitation on localStorage is size. The total size available depends on the browser and ranges from 2.5MB to 10MB or can be unlimited. Again, localStorage isn't a place to store a lot of files or other large data but it is perfect for storing other data that is too large to fit on a 2KB cookie. Be mindful of your users, however. They may not have a large amount of storage to dedicate to the browser, so you should limit the amount of data you intend to store as much as possible.

Using LocalStorage in a React App

Using the localStorage API is pretty straightforward. To store a value, use localStorage.setItem(key, value), where "key" is a unique key you will use to retrieve your data later, and "value" is whatever data you wish to store. In my app, I was storing each list of items as an object in the component's state, so when I was ready to save my progress, I used JSON.stringify(obj) to turn my object into a string, and then pass that string to the setItem method on localStorage.

When the page loads, I performed the process in reverse. I fetch the string out of storage using localStorage.getItem(key) and then passed it through JSON.parse(string) to get my object containing my data and set it as my component's state.

Other LocalStorage methods

Two other methods I didn't use in my app but may be useful to you are removeItem and clear. If you want to remove a single item from the browser, you can use localStorage.removeItem(key) to remove a single value from localStorage. And if you want to get rid of all the data you are storing in the browser, you can use localStorage.clear().

Pros and Cons to using LocalStorage

For this app, the big pro for me was how easy it was to create a persistent state using only two browser API calls. The Web Storage APIs (of which localStorage is a part) are very well supported across browsers going back to IE8. The one big drawback to using localStorage is that the data you store is confined to the browser, so if a user tries to access your app from another browser, they're starting from scratch again. This is an obvious limitation and one that I was fine with for this app, but you'll have to decide if that's a tradeoff you want to make for your app. There are some potential workarounds, like creating an export file of the data that you could import into another browser elsewhere, but at that point you may be better off creating a backend database to track that information.

Wrap Up

I hope this gave you a practical introduction to the localStorage API and how you can use it to store data for a web app without having to stand up a database. If you're interested in checking out the app, I have it hosted at https://rdr-naturalist-tracker.richardsween.dev/. All the code is open source, and you can check it out at https://github.com/sweenr/rdr-naturalist-tracker.

Burnout: Physical and Mental

Richard Sween — Thu, 10 Sep 2020 14:09:08 +0000

I like to think of myself as a hard worker, someone you can rely on to get a job done when it needs to be. Looking back, I think that's why it's hard for me to recognize the symptoms of burnout as they creep up on me. I've experienced different types of burnout as well that varied based on the type of stress that was causing it. Hopefully, this helps someone else out before they hit the burnout phase.

Physical Burnout

The first type of burnout is what I think of as physical burnout. This is when you know what needs to be done, you know how to do the task, but due to whatever circumstances, you get overworked to the point of burnout. In my experience, this can happen when deadlines are driven by external forces out of your control (or worse pop up unexpectedly), and/or you're not given the resources you need to complete the task by the deadline.

For example, at a previous job I was tasked with setting up a simulation lab with controllable light and sound effects. Initially, there was no firm deadline, but halfway through the setup, an artificial deadline popped up that required the room to be finished in days instead of weeks (with no additional help, of course). By putting in long hours, I was successful, and everything worked by the deadline. But by the end of it, I was exhausted and sick and had to miss a week of work after. The best part is the reason for the deadline never materialized. I had put in all that extra work and stress for nothing.

Mental Burnout

I've always been better working higher in the application stack - web and app development mostly. For one project, I had to go from a year of doing web development with React to low level C++ and an entirely new-to-me graphics framework. The project was five weeks long and it was one of the hardest, longest projects I've ever had the misfortune of working on in my career. There were multiple times during that project that I almost walked out and never came back. Fortunately, I had help on that project, so I had someone to struggle with, which helped a lot, and at the end of the day we were successful.

For lack of a better term, I call this mental burnout. Unlike physical burnout, this is where you may know what needs to get done, you don't know how to complete the task, and you're mentally drained from trying to make it all work. There's a mismatch between the skills that you have and the skills necessary to be successful. For me, this type of burnout is much worse. I don't mind putting in work if I know what I'm doing and how to be successful. When I've gone through in a situation like this though, it has been rough. There's a sense of hopelessness struggling through a task you don't feel equipped to do.

Preventing and Combatting Burnout

I wish I had some secret to share with you about how to recognize scenarios that are going to lead to burnout. To be completely honest, I'm still learning how to catch myself before I get caught in a burnout spiral myself. There are some things I've noticed that can be triggers in my experience - things like deadlines that appear or are moved up without the resources to meet the new deadlines. Being tasked with something you have no experience in (especially if combined with a tight deadline).

As for combatting burnout, one thing you'll need to learn is how you react to stresses and what your tolerances are since this is going to be different for everyone. Once you recognize you're potentially in a situation that could cause burnout, communication is key. I'm fortunate to be in a place where I have bi-weekly one-on-one meetings with my manager and can be honest with him, brutally so at times, when I see a burnout situation brewing. The bottom line is that if your manager doesn't know how you're feeling, then they won't be in a position to help - they're not mind readers. As I mentioned, everyone's threshold is going to be different. The other thing I think is important is be aware of how long you've gone on a project without a break - especially this year. I just got back from a week off because I realized I hadn't taken any time off in seven months. With everything else going on in the world, and working at home full time, I forgot to take time for myself and felt burnout creeping in. Now, instead of just going through the motions at work, I feel motivated to get stuff done.

Wrap Up

In my career, I've experienced two types of burnout - physical and mental. The difference between the two is that in the former, you're overworked, and in the latter, your skills don't line up with the task and/or you're lost or confused. As an employee, you need to be clear with your manager if you feel any of these symptoms of burnout so that they can be addressed. If you're in management, it's your duty to your direct reports to push back against unreasonable deadlines and make sure that the talents of your employees line up with the tasks at hand. At the end of the day, this keeps everyone happy, healthy, and more productive than struggling through a difficult situation.

Finally: please, please take your PTO days! Work will always be there, so enjoy the time you have!

Cover Photo by Cris Saur on Unsplash

Multiple Developer Setup in AWS Amplify

Richard Sween — Fri, 04 Sep 2020 14:43:09 +0000

My company recently started working with AWS Amplify as the backend for a web application. A lot of the documentation and tutorials online are great, and the experience so far has been awesome. But there was a gap I found in showing how to get started with multiple developers on the same project. In this post, I'll walk you through setting up your project for multiple developers.

Setup

I'm going to assume you've already gone through the process of setting up your Amplify project for a single user. If not, the Amplify docs are a great place to start. They will walk you through setting up the CLI tool, connecting to your base AWS account, and creating your Amplify project.

Adding a Second Developer Account

Have the first user that created the initial Amplify project sign into the AWS console (https://console.aws.amazon.com/).
Click "Services" at the top, and then either find "IAM" under Security, Identity, & Compliance, or search for it using the search bar at the top of the dropdown.
In the IAM console, click Users in the left menu and then click Add User at the top of the next screen.
Enter a name for the user account and check Programmatic access below. Click Next: Permissions at the bottom of the screen.
On the next screen, select "Attach existing policies directly" and check the box next to "AdministratorAccess". Click Next: Tags at the bottom of the screen.
Enter any tags you want to use with the user. This step is optional. Click Next: Review at the bottom of the screen.
Double check that everything is set up correctly and click Create user at the bottom of the screen.
Make a note of the information on this screen: User name, access key ID, and Secret access key. Share these with the other developer you are working with for them to use when setting up the Amplify CLI.

Optional: AWS Console Access

By default, this new IAM user will not have access to the AWS console to be able to access any of the resources Amplify will create. Use these steps if you want your associate to have console access as well.

Follow the steps above to login and get to the IAM console with your first user account.
In the IAM console, click Users on the left menu, and then click the name of the user you created in the previous steps. You should see the Summary page for that user.
Click the Security credentials tab. At the top under Sign-in credentials you should see "Console password Disabled | Manage". Click the Manage link.
In the modal that pops up, change the option next to Console access from Disable to Enable. The password options should appear. Either enter a temporary password and check the Require password reset box or use the Autogenerated password option. Click Apply.
If you selected the autogenerated password, the user's password will appear. Be sure you copy it down as there is no way to get it again once you close the modal.
Take note of the Console sign-in link that now appears above the Console password status. Share the console sign-in link and password with your fellow developer to allow them to access the AWS console.

Cover Photo by Annie Spratt on Unsplash

Why Everyone Should Learn (Some) Coding

Richard Sween — Fri, 28 Aug 2020 14:31:08 +0000

Something happened a few weeks back that was fairly routine for me. First, some backstory: I've been playing a lot of Red Dead Online recently, ever since it landed on Xbox Game Pass. They recently released a new "role" - a storyline of things you can do to level up. This role is called the Naturalist, and it involves you wandering the vast expanses of the map trying to catalog (or hunt) the various animals that inhabit the world. For each animal you find, you need to sedate and get a blood sample from it. Animals are organized into habitats, and for each habitat that you complete by turning in a sample from each animal in that region, you get a cash payout in-game.

Seems like a simple enough task, until you realize there are 118 different animals to keep track of in the game. Optimally, while you can carry and turn in multiple samples for an animal at the same time, you get the best reward for your effort when you turn in just one sample per animal at a time until you complete a collection and are ready to start that collection again. So now there are multiple pieces of information (number of samples per animal in my inventory, have I turned in this animal already?) in different locations in-game to keep track of while you're working on progressing in the Naturalist role. You could keep track on pencil and paper, but since I'm a developer, of course I wrote an app.

But this isn't a blog post about how to write a tracker app for the Naturalist role in Red Dead Online (although if there is interest, I could certainly write one). No, this is about something bigger than that. I ran into a problem (keeping track of data), I came up with a solution (basic web app), and was able to implement the solution to make my life easier in an afternoon, but only because I had an understanding of the tools available to me as a developer. What I built wasn't terribly complicated, but it made my life easier since I was able to put together a simple tool to fix my problem.

This is why I think that it's incredibly important for everyone to at least be exposed to software development at some point in their lives. In the US, it might make sense for this to happen in or around high school. You don't have to train everyone to be a software engineer by the time they graduate (although I personally would have loved that). Exposing everyone to the basics of software development and the potential that it unlocks -- not just in future career options, but in simple ways you can make your life easier -- should be as mandatory as taking a foreign language in school. People may be exposed to it and decide it's not for them, or even that they hated every minute of it. I get it, I had to go through a lot of things in my education that I didn't enjoy and rarely, if ever, used again. But you can't use a tool if you don't know that it exists, and that's what software development skills are -- a tool. Sometimes it's a tool that pays the bills, and sometimes it's a tool that makes it easier to play a video game more efficiently.

P.S. If you're interested in checking out the app, I have it hosted at https://rdr-naturalist-tracker.richardsween.dev/. All the code is open source, and I welcome issues and PR's at https://github.com/sweenr/rdr-naturalist-tracker.

Header image photo by NESA by Makers on Unsplash

We used to run Docker in the cloud. Here's why we don't anymore.

Richard Sween — Thu, 20 Aug 2020 17:42:26 +0000

Our Problem

Recently, we were working on building a content management system (CMS) for an industry specific set of best practices. Our company had previous experience building web applications using the Django framework. We built out our application using two Docker containers - one for Django, which served as our frontend and backend, and one for the database.

This architecture worked well during the initial development phase of the project. It was easy to deploy the stack and have an isolated database and application container running locally for testing and development. The architecture was scalable, and it was easy to change out components (which we did once to change database engines).

Deployment

As a functional application started to come together, we began to look ahead to how we would deploy this to our customers. Since we had a pair of Docker containers, we pulled in another engineer who was tasked with getting these containers running in the cloud. After a bit of research, our deployment engineer developed a plan to use Kubernetes running on Google Cloud to host and maintain our infrastructure. At the time, it sounded great! It worked fairly well for our first few deployments, but after a while we started experiencing growing pains.

"Why did we do it this way?"

The way our system was deployed, each individual instance (organization or topic) received its own copy of the system - its own Django container, database container, subdomain, etc. Again, this architecture had some pros, like strict separation of data. However, it quickly became apparent that this architecture wasn't going to scale like we thought it would. We quickly ran into issues like resource quotas and other challenges in maintaining this type of growth. Another significant issue was cost - we had no paying customers yet, but our design choices were costing us hundreds of dollars a month in hosting fees.

Our Fundamental Mistake

If you were reading closely, you might have realized our biggest mistake was in front of us the whole time. Instead of asking, "How do we get these Docker containers running in the cloud?", we should have been asking, "What does our backend architecture need to look like to support our product's goals?". We were blinded by our design choices early in the project from seeing other ways of accomplishing our goals with less frustration and complexity.

Hindsight is 20/20

Looking back and having learned more about Kubernetes in the past six months, there were big red flags we missed because we were focused on other things. Kubernetes is hard, which makes sense. It was built to solve hard problems at scale, not to run a couple Docker images in the cloud. There are certainly instances where Kubernetes would be the right answer, but unless you have a whole DevOps team devoted to building, maintaining, and scaling your infrastructure, it's probably not for you.

Key Takeaways

Unbiased, third-party design reviews are invaluable.
Just because Big Company X is doing something doesn't mean we need to be doing it too.

As engineers, designers, developers, etc., once we've spent enough time with a project, we naturally lose some objectivity just because we are so used to what we're doing and how we're doing it. That's part of the reason we're so bad at testing code we've written - but that's a post for another day. Getting a fresh set of eyes on any major decisions gives you a "sanity check" that what you're doing seems like the best course of action. Find some friend or colleague not working on the project and have them hear your pitch. Most importantly, be prepared for them to tell you they think what you're doing is crazy - far better to learn this at the design phase than halfway through development.

Secondly, there are a lot of things that Google or Amazon do that anyone could emulate in their business or projects. However, there are also a lot of problems that they must solve due to the incredibly large scale they have to work at every day. These solutions don't always work as well in a scaled-down environment. Kubernetes works for Google because they have tens of thousands of applications running worldwide that need to always be available. There's a good chance that the project you're working on doesn't, and there are simpler solutions to getting a database and hosting running on the internet. Trust me, I've tried.

Sound Off

Have you made similar design decisions when in hindsight you were focused on the wrong thing? Do you have tips for keeping the bigger picture in focus when you're making decisions? I'd love to hear about them in the comments below!

Cover Photo by Todd Cravens on Unsplash

Software Process: A Journey through History

Richard Sween — Tue, 11 Aug 2020 20:07:13 +0000

This is a writeup of a presentation I gave to the Jackson Area Web and Application Developers meetup in August 2019.

Software Process Defined

What is a "software process" and do I have/need one? Basically, it's exactly what it sounds like - the process you or your company takes to build, test, and release a piece of software. So whether you're a solo developer working on side projects at home or part of a huge team at a multi-billion dollar business, you are implementing some form of software process whether you realize it or not.

I started working at Kopis Mobile in December 2016. Since that time, we have made it a focus to improve and streamline our software process. Today, I'm going to take you on a journey though the eras of software process we've been through at Kopis Mobile, starting in the Dark Ages.

The Dark Ages

Honestly, even the Dark Age would have been an improvement for our software process - we were more like cavemen right after the discovery of fire.

We were comfortable with Git and using it in a team setting. We used a modified Git Flow branching scheme to provide some structure to our Git environments. And that was about the extent of our software process at the time. Everything else was a bit of a mess: deploy keys for Android apps were stored on one person's machine (I think they were backed up on a CD somewhere?), every artifact we shipped to a customer was built on one developer's machine, there were lots of issues of "works on my machine".

There were six of us on the engineering team at the time, and we were very siloed. For the majority of project, there was one developer responsible for all of the new work done. We followed Deadline-Driven Development, where our priorities were set by what project had the closest deadline. It was stressful, it hurt morale (even if we may not have recognized it at the time), and we had a bad bus factor.

The Renaissance

For us, the discovery that sparked our Renaissance was Agile and Scrum. But it wasn't an immediate hit. We had several on-and-off attempts at implementing Scrum before really committing to it late in 2017. Many of our "failures" stemmed from the belief that traditional Agile and Scrum didn't work for us. Things like:

We had multiple products and contracts we were working on, but only one team
Our deliverables were usually contractually obligated, not customer-driven
Because of our market, we had limited customer interaction, which made it hard to get feedback and iterate

These challenges almost kept us from realizing the power of Scrum. A lot of our early difficulties revolved around us trying to force our process onto existing tools which gave us a lot of headaches. We used JIRA for a while because others in the company were using it, but it didn't work for us in engineering. We migrated to GitLab for our repository and tried using project issues to track features but that didn't work for us either.

The common problem was a lack of visibility/support for cross-product teams -- remember, we were a small team working on multiple projects concurrently. So, we went old-school, using a white board and color-coded sticky notes per project. This gave us the cross-project scrum board we wanted so bad. And it worked great, until we had a team member leave to work remotely for three months on the other side of the country. So, using the physical board as a prototype, we build a digital solution that tied into an OpenProject instance we had started using to plan and store features for future work.

While we were figuring out our tooling issued, we were also figuring out how to make the actual Scrum methodology work for our team. We started with two and then three week sprints, with half a day for planning at the start and half a day to share what we had accomplished with the team in review and discuss how things went in retro. For a while we combined those two half days into one long review/retro/planning day which we all decided after a while was too long to spend in the conference room together (the company at least catered lunch those days).

Age of Exploration

Since the whole team finally had an idea of what everyone else was working on at any given time and where we as a team were headed. Along with this insight came a conscious desire to break down the silos and enforce cross training where we could. It was uncomfortable at times, but it was definitely the right idea. Encouraging people to work on things that they weren't used to working on forced us to learn each other's code and share some of that tribal knowledge that is inherent in a silo'd project.

Another way to help cross-training and code quality was the introduction of merge reviews. Previously, our process was to get a feature implemented, test it until you were satisfied, then merge it into our develop branch. Once we implemented merge reviews, we locked the develop branch so that all merges to develop had to go through a review and get approved by another team member before getting marked as done.

While we would never be fully interchangeable - and that was never the goal - everyone on the team benefitted from having someone else that knew from experience what problems they were going through and having someone else on the team to bounce ideas off of.
Just like the early explorers, we were learning more about our world and the challenges and possibilities it offered.

The Industrial Revolution

As we continued our growth and learning, we began looking outward at what other companies were doing and what tools and processes we could use at our company. This sparked our Industrial Revolution. Just like the first Industrial Revolution revolved around transitioning from hand-made goods to machine-made ones, our Industrial Revolution involved automating a lot of the tedious tasks involved in software development. Since we were already using GitLab for our code repository, it made sense that our first major leap came from learning and implementing GitLab's Continuous Integration and Continuous Delivery (CI/CD) pipelines.

Typically when you run git push on your machine, the files are sent up to your repository and that's it - they just sit there. But there exists a way to employ a team of magical robot workers to take the code you have committed, build your application, run tests, and deploy it to your server or mobile app store of choice. There are many different CI providers out there: CircleCI, Jenkins, Travis CI, etc. GitLab has a built-in CI/CD solution - even their free tier offers some access to their CI runners that can build and test your code. We host GitLab on premises, so over time we have built a fleet of runners to build everything from PIC firmware to Android apps and everything in between.

This was the one change that I believe had the biggest impact on improving our software process as it helped a lot of our Dark Age problems. Software builds had to be reproducible on a runner - no more "but it works on my machine" issues. If it can't be built with a clean CI image, then it's like you it can't be built at all. Deploy keys and other secrets are stored in private variables that only runners have access to when they need them. So much of the tedious, repetitive actions are automated away, allowing you to focus on more important tasks.

The Future

Our software process journey is far from over. There are still pain points that we are aware of and others I'm sure we haven't even considered yet. For now, there are two big areas of improvement we want to focus on - improving automated testing and code quality tooling and better ways to manage code maintenance and technical debt.

Key Takeaways

There are no "one size fits all" solutions to software process. What works for us may not work for you exactly, so you need to figure out where you're at, where you're headed, and how you want to get there.
Break down silos - this was one of the best things we did to help morale.
Invest in automated tooling - there's no reason you should be stressing out over manual build and deploy processes in 2020.
Take time to document, develop, and refine your software process - just like with continuing education, there are always things to learn and improve about your own software process.

Sound Off

I hope this has inspired you to take a critical look at your software process, especially if you haven't given it much thought recently, or ever (no shame!). Where are you or your team at in your process improvement journey? What are you or your company doing that you're proud of or know you need help with?

Mechanical piping photo by Martin Adams on Unsplash

Cavemen image from SpongeBob SquarePants on Nickelodeon

Silo photo by Sebastian Grochowicz on Unsplash

Scrum board photo from Silicon Valley on HBO