At Carbon Five we try to be agile about our technology choices and pick the simplest tool for the job at hand. That means that even in 2019, the era of React and Redux and GraphQL and all the other fancy tools for client-side web applications, sometimes the best tool for our clients is a good old Rails app, serving HTML.

Often the vision for the project pushes us towards a Single Page Application instead — maybe the app is going to be highly interactive or include realtime data, or the client is already invested in a front-end framework. In those cases, of course, we’ll reach for React or Angular or Vue. But for the traditional CRUD app that just needs to show some data and let users update it, a small team of experienced Rails developers can get an idea to market incredibly quickly.

When writing React components, we sometimes need access to lifecycle events to handle a variety of side effects: fetching data on mount, sanitizing props when the component updates, cleaning up before the component unmounts, etc.

Each team has their own tolerance for what is and is not a reason to request changes on a PR and block it from being merged. This may be rooted in process, fairness, and expediency, and may be a company or team decision. Whatever your personal philosophy may be, the team as a whole and often the company has to come to some sort of consensus as to what constitutes a reason to block a PR. Over time, I’ve gotten a little more “block happy” and I’m going to talk about some of the advantages and pitfalls of blocking, and give you a mega list of reasons you might want to block a PR.

In smaller projects, React offers snappy performance – the virtual DOM diffing means updates can happen quickly and for the most part, things just work. But, particularly when you’re dealing with large data sets, things can bog down as every render loop causes many unnecessary renders of components which have not actually changed.

React Dev Tools comes with a profiler that can help pin down the problem, and React 16.8 came with some features to make it easier to improve performance of functional components. But to use these tools effectively you need to know what the problem is and how to find the culprit.

If you’ve spent any amount of time in the open source community, you’re probably familiar with GitHub issues. Issues are a fantastic way to organize the discussion around bugs and feature development in a codebase, and it’s common for open source projects to rely on issues to communicate actionable chunks of work to contributors. This practice is ubiquitous in open source repositories on GitHub, and with the help of issue labels and milestones, issues have supported the development of tons of projects and technologies. 

Earlier this year, React added the powerful new Hooks feature. Hooks allow you to ditch class components and stick with functional components, even when you need local state and lifecycle methods. They also make it much easier to extract logic from one component and share it with others.

Super Simple Hacks While You’re Figuring Out Your Workflow

There are a lot of really great reasons to use TypeScript, but we’ve occasionally encountered some hesitancy from programmers not sure how much of an adjustment it will be. Learning Typescript is not as complicated as say learning Elm and I’d argue it’s more enjoyable to use than Flow. But the hesitancy is understandable. Many front-end developers have learned JavaScript and Ruby or Python, but have not had to dig into typed languages. Learning to program with types and think about your type system in advance can elevate your programming style and eventually be easier than not using types. However, there are many different ways to be good at programming, and I have seen a range of programming styles that might make the learning curve of TypeScript steeper. Everyone eventually adjusts to TypeScript on their own and most come to love it. From those of us who have already made the change, here are some super simple tips and hacks while you’re getting your sea legs in TypeScript.

Part of our approach to software development at Carbon Five is to ensure everyone is playing with the same dictionary. The start-of-project questions we all ask are common: What are the success metrics for our stakeholders? Will our customers dislike our product? But words like “success” and “dislike,” “good” and “bad” are all personal words. What they mean will change project-to-project, and even person-to-person.

It’s a common assumption that users and stakeholders know their needs, and can easily voice them. But if a stakeholder has gone through the daunting process of signing with a new team, they may well be looking to that team to define those needs for them. How do we do that?

While it’s not a match for every project, consider adding a demo to the end of your iterations — a scary proposition, but that’s the point. When done right, the benefits of regular demos are massive.

You, fellow software engineer, have probably felt the same as I have: while coding some big feature, you find a thing that is inefficient, unreadable, deprecated, confusing, or just buggy. Maybe it’s not bad code at all — you just realize that several packages are out of date, or your framework needs to be upgraded. You roll your eyes, you sigh, and you think, “Ugh, this has got to be fixed.” It’s technical debt.

You may also have experienced this: you go to your manager, or your project manager, and complain about the Technical Debt. “We really need to upgrade to Rails 5!”  Yet you can’t seem to get the go-ahead to fix it. “We have a hard deadline!” “We don’t have time for that!” they say.

Those in charge insist you have more important things to do. How do we convince them otherwise?

Recently we’ve noticed a number of our clients maintain a backlog of small tasks that are handled separately from their main backlog. These are tasks that should be finished at some point, but will rarely take priority over business-critical features and bugfixes. Often they are bite-sized pieces of work that can be finished in a couple of hours or less: addressing engineering chores, paying off tech debt, and addressing minor bugs. Internally, this separate backlog has earned a catchy name: the snacklog.