How We Work
Some of our core beliefs
About
We build quality, user-friendly software for the energy industry in order to meaningfully accelerate electrification. We say it a few times on this website, but really, that’s precisely what we do.
We also wanted to a place to share some details around our processes and beliefs. These are part expectations and part aspirations of Bellawatt's work philosophy.
Generally, we deliver business solutions, not just product, and definitely not just code. Our technical team is not separate from our product team, business team, or clients. When we deliver something, we are thinking about its end value. If we see a potential improvement for the end-user in a design or implementation, we act on it.
To deliver quality solutions, we prioritize learning. This means continuously digging deeper into our industry and current tools, as well as regularly stepping out of our comfort zones to try new concepts or technologies. Given a choice, we lean towards generalization and away from hyper-specialization, but we aggressively push for both.
Core Values
Deep Work. Our focus on deep work has unlocked our team to deliver some of the best products in the industry. We fight distraction head on to give our team the space to dive deep on their materials and get quality work done. For some tactical examples, we don't do daily standups, ask our team to delete slack from their phone and to disable email notifications, and try to clear whole weekdays from recurring meetings for all job functions.
Quality over Quantity. Generally, we take on engagements that have an impact and seek to avoid frivolous projects that come across our desks. And within our engagements, we often and regularly cut scope. We would much rather cut our scope (and yes, short-term profitability) than deliver something that we don't believe the client needs.
Written Communication. We communicate primarily through writing for a few reasons:
- Written communication requires a specificity that verbal communication can skip.
- We want to avoid he-said/she-said misunderstandings.
- When a misunderstanding does happen, everyone can look at the same sentence or diagram and learn how to avoid such misunderstandings in the future.
- Most importantly, written back-and-forth builds a full picture of the problem, allowing the individual and/or the team to create a holistic solution.
Self Sufficiency. Each of us wants to be a manager of one. We expect one another to be disciplined and capable of delivery without explicit guidance. This does not mean we don't come to each other for help, but it does mean we expect one another to make diagnoses, even on issues that aren't part of our current skillset. As a result, our team members have wide latitude to work in a way that fits their lifestyle. The expectation is that we all deliver quality while keeping our commitments to both internal and external team members. For Example:
Not preferred: “Hey team, Webpack won't build the project. I can't continue this ticket”.
Preferred: “Hey team, Webpack won't build the project. The error message it's giving says that Object.getOwnPropertyDescriptor is undefined. I've found [some Github issue] and [some StackOverflow article] which talk about something related, but I'm really at a loss for what to try next. [Here's a link] to the Webpack config file. Can anyone point me in a direction to pursue?”
The second example is not only more explicit but also takes more responsibility for the problem. With that, our team's time together can be spent on the bigger picture rather than digging into the full background on a Webpack issue.
How We Deliver
We are a small team, so we prefer to deliver solutions in technologies that we will not have to debug ourselves such as Docker, Ruby, and React. We plan for our work to be long-lived, and we want the technology we use today to still be relevant in 5 or even 10 years. But these preferences are just that - preferences. We try our best to be non-dogmatic - we don't believe that VSCode is better than Vim or Atom, we appreciate things about both object-oriented and functional programming, and we do not automatically rule out one programming language or another “just because.”
We try to write solutions that are modular and predictable. Simplicity is a promised virtue of functional programming, but we believe the principle can be applied to any programming language, and even further to our business processes.
We deliver to production deliberately. We don't abide by the “move fast and break things” mentality, especially when we are deploying to production. We prefer a careful and deliberate approach from start to finish. This is as much cultural (it's who we are) as it is necessitated by our industry and clients.
A deliberate approach also means truly understanding the core problem, not just how to implement the solution. Of course, the occasional time constraint requires us to execute a hurried solution, but that is not our preferred approach. We try to spend ample time in “problem land” before we jump into “solution land.”
While not an exhaustive list of technologies we have used, these stand out as some of our favorites:
- Ruby. We love its expressiveness. Rails remains a compelling option for getting an application up and running quickly, and the community is still healthy and active. We have also used Laravel, and while we don't love PHP, we were pleasantly surprised with Laravel's design and ease of use.
- Python. For products that rely heavily on data, there is no comparison to the volume of mathematical libraries available in python. For web applications, we tend to lean towards Django.
- React. Its core concepts of UI as a value and modularity are now nearly ubiquitous, and the power of being able to separate UI into its own concern allows us to easily reuse and repurpose components all over the application.
- MUI and/or Tailwind: We grew up on Bootstrap, and now lean on either MUI for the numerous components or Tailwind for the quick styling. We're flexible project to project.
- Inertia. Inertia.js is a nice, small library that was originally written for Laravel, and we repurposed and open-sourced it for both Rails and Python/Django. It significantly reduces the amount of boilerplate code required to get React and Rails to communicate effectively, and increases the points of shared work. The package allows us to write front ends that leverage React's reusability while keeping our calculations in fast and easy-to-read Rails or Python. While we started this as a hackathon, we enjoyed it so much we continue to maintain the packages.
Finally, some of our favorite resources that have influenced our growth:
- Simple Made Easy - Rich Hickey
- Things I Don’t Know as of 2018 - Dan Abramov
- Boundaries (Functional Core, Imperative Shell) - Gary Bernhardt
- Controlling Complexity - Andy Matuschak
- Growing Rails Applications in Practice - Makandra
- Practical Object-Oriented Design in Ruby - Sandi Metz
- RailsConf 2018: Opening Keynote: FIXME by David Heinemeier Hansson
- The Wrong Abstraction - Sandi Metz
- Abstraction vs Duplication. Why DRY is bad advice – fluent.software
- A Philosophy of Software Design, Part 0: Introduction - DEV Community
- How To Write Better Code - Johannes Brodwall
- They Write the Right Stuff - Fast Company
Shared Vocabulary
Here are some conversational shortcuts we find ourselves frequently using:
"Genuine Question": Used as a preface before a question that might come across as snarky or accusatory. Meant to disarm a potentially contentious topic, such as “genuine question, why are we doing this in Ruby and not JavaScript?”
"Colleague": our preferred method for referring to each other. Titles may work for large siloed organizations, but we're trying to remain flat as long as we can and believe our titles should reflect that.
"Problem land" / "Solution land": Used to switch focus between requirements and implementations. Often, teams try to evaluate a specific implementation before truly grasping the issue at hand. For example, “Picking an authentication gem is jumping into solution land. What's the problem? Why does a user have to log in?”
"Are we 70% confident?": Most decisions should probably be made with somewhere around 70 percent of the information you wish you had, if you wait for 90 percent, in most cases, you're probably being slow/getting diminishing returns to your time invested finding perfection.
"Bellamorphism": Sometimes, we unintentionally project our shared values onto other teams and products. This is human nature, but we look to call it out so that it forces a conversation rather than a misalignment.
"Spike": The coding cousin of "we'll see I guess", we use "spike" when we believe that writing some code may give more clarity than continuing to talk about it. For example, "I think I know how that report should look, let me spike on it." It is understood that spikes can be discarded if results don't quite work out.
"Bump": A friendly way to remind someone to respond to a thread or email, without any passive aggression. We all have more notifications coming in than we can handle and it's ok to miss one sometimes.
"Thanks" / "Thank you": Say it often and like you mean it. Colleagues can often take each other for granted, especially when they're miles apart.