Eddie Moya

I started teaching myself JavaScript in the late 90's in my early teens, and it's been ubiquitous throughout my career. From front end to back end, to serverless, or raspberry pi - JavaScript really does seem to do it all. I specialize in finding lean, minimalist, maintainable approaches to common problems.

Stuck in Git hell? Let’s talk. Over the past ten years I’ve helped dozens of developers and teams: - Merge without fear of conflicts - Recover lost work (human errors or tooling hiccups) - Streamline CI/CD by aligning branch strategies with automation - Maintain a clean, useful history for audits, roll-backs, and code review What I offer: - One-on-one mentoring: Build an intuitive mental model of git commits, branches, refs, remotes, merges, conflicts, rebasing, etc. - Team strategy workshops: Define when and how to branch, merge, test, review and release. - Custom tooling: Once we understand what your needs are, and who your users will be (git users), we can start to build tooling that simplifies the complex steps in ways that don't disappear behind more layers of complexity. Minimal solutions = minimal maintenance = stability = minimal sadness = maximum profit! Make failure part of the plan, the definition of failing safe. There's often many reasons why a one-size-fits-all solution doesn't work. Instead of hiding your organizational or technical friction under more layers of tech or confusion, or bureaucracy, we can create nimble tools that themselves elucidate what needs doing. Make failure safe, and velocity takes off. I promise. For over a decade I've found myself enamored with the simplicity of git. I've mentored one-on-one countless times to help people obtain an intuitive grasp of how git works, and how to make choices in advance that will make things easier when things go wrong, or better yet - find ways to make the right way, the only way that works. I've also guided teams in iterating over their collaboration strategy. How and when they create and use branches, run tests, merge changes. How to merge in ways that ensure the history is most useful for their needs. How to integrate their strategy into their CI tools - where do the boundaries go? How to avoid the pitfalls that lead to developers losing hours in merge conflicts, or rebase hell, or even in the worst cases helping to recover seemingly lost changes (no promises! but we can try). When my git and DevOps mentor left for another job, I read Scott Chacon's Pro Git (1st edition). I immediately disagreed with his git-flow strategy and created my own tailored solution for our team by creating a command line tool in node.js (for a JavaScript heavy team), which integrated JIRA, git, and Jenkins to manage deployments, releases, hot-fixes, etc. All while making sure to keep breaking changes from production, without slowing down the velocity of the team by blocking working changes. I now use ArgoCD and Flux, modern sophisticated GitOps solutions, in my Kubernetes home lab to manage all of my home lab services. However such complexity is often not possible, or helpful. Want to replace Git anxiety with confidence? Want to to move fast and break less? Drop me a line, and let’s find your path forward.