Getting a Vercel PostgreSQL Database and Basic Authentication Operational

Quick links to all posts in the series and related at end of this post.

In the last post I’ve detailed getting started with setup of a basic React App using Next.js and deploying it to Vercel using their respective command line tooling. That post is Building “Adron’s Core Platform”: Starting a React App on Vercel.

Database Time – Getting a PostgreSQL Database

First, I setup the database in Vercel. Navigate to Storage.

Next I clicked on “Create” next to the Neon option.

The next prompt form will appear. I went with PostgreSQL (Neon) database, as shown, then the closest region (mine is Portland).

Continue reading “Getting a Vercel PostgreSQL Database and Basic Authentication Operational” →

Building “Adron’s Core Platform”: Starting a React App on Vercel

Quick links to all posts in the series and related at end of this post.

There have been a number of changes in my Collector’s Tune Tracker endeavor since I wrote up the first posts for the effort with: Building a Multi-Tenant Music Collector’s Database, Starting a New Project – Let’s Choose the Tech, and Software Development: Getting Started by Getting Organized. This is a continuation of that effort. I’ll go into the differences in a later post about those first posts and how I got to this point here today. But for this post specifically, and the next few, I’ll be focusing on getting a project started with React and Vercel.

I’ll write these following an approach that is based in the following:

  • Suffice to say, I’m a bit rusty with my React.
  • I’m completely unfamiliar with Vercel. In these posts that’s about to change however.

There are also a few prerequisites. I’m working through this on an M1 Mac, using iTerm, and largely Visual Studio Code. That and a whole lot of documentation. The following are some other prerequisites that would help if you want to follow along with what I’m going to build.

Prerequisites

Rolling Into Things

Right off, let’s get the project started with the ole npx. The steps I went through involve the following – I just added comments inline to describe what I did or what setting options I went with for prompts.

Continue reading “Building “Adron’s Core Platform”: Starting a React App on Vercel” →

The Role of a Principal Engineer: Strategic Vision and Tactical Execution

I just wrote a post about principal engineers and the purpose of the role. I wanted to elaborate a bit more about strategic influence and tactical implementation, thus I present this post. Cheers!

In any high-performing engineering team, the Principal Engineer role is uniquely positioned to influence both the day-to-day and the bigger picture. They wear the hats of both mentor and visionary, technical architect and pragmatist. This post is a deep dive into the core tenants I outlined before—because bringing each of these to life is where the real magic happens.

Technical Vision and Strategy That Scales

Strategic Influence: A Principal Engineer’s vision isn’t just about the project’s success—it’s about aligning technical goals with business outcomes, anticipating future needs, and charting a course for scalable growth. They take the long view, ensuring that each architectural decision today supports the needs of tomorrow. This means understanding where the company aims to be in five or ten years and building systems that can grow without creating excessive technical debt.

Tactical Implementation: To implement this vision tactically, a Principal Engineer uses an iterative approach. They document the architecture, outline performance benchmarks, and integrate architectural reviews into sprints. Tactical steps might include establishing microservices where modularity is beneficial, employing a well-planned API strategy, or implementing event-driven architectures that allow scalability. They routinely assess the current state, asking questions like, “If we double our users tomorrow, will the system keep up?” Each change made is documented to create a record for future engineers and ensure continuity.

Continue reading “The Role of a Principal Engineer: Strategic Vision and Tactical Execution” →

The Purpose of Principal Engineering

In the world of tech hiring, there’s always a struggle to balance experience with cost, technical chops with the ability to lead. When the stakes are high, and you need more than just code but also architectural vision, that’s where the Principal Engineer comes into play.

But what does a Principal Engineer (or “Staff Engineer”, etc) really bring to the table? And why would a CIO or CTO be willing to invest in this role?

Here’s the deal: a Principal Engineer is more than just a senior developer cranking out code. They’re strategic thinkers, problem solvers, and critical linchpins who hold the project’s technical map in their hands. Here’s a breakdown of the unique value they bring, along with what your leadership should expect when hiring for this pivotal role.

In this post I aim to break down and detail some of the deliverables that a principal engineer is on the hook for. But emphasis is on *some* of the deliverables. The role has specifics per company and org that they’re working with.

Technical Vision and Strategy That Scales

In a fast-paced engineering environment, you need a technical roadmap that not only meets today’s needs but anticipates tomorrow’s challenges. A Principal Engineer builds out this technical vision, aligning it with business goals and real-world needs. They’re not just thinking about if something works—they’re focused on how it’ll work at scale and why those architectural choices make sense for the future.

Deliverable: Expect a Principal Engineer to lay down an architecture that scales, not just through lines of code but through the decisions they make about tech stacks, data models, and more. This isn’t a job for someone who just learned Kubernetes last week; it’s for someone who can see around corners and build with flexibility.

Continue reading “The Purpose of Principal Engineering” →

A few words on getting into Computer Science in 2024 and on?

The journey into advanced software development can feel like plunging into a tumultuous ocean. At first, there’s the excitement of learning—those ‘aha’ moments when distributed systems suddenly make sense, or when the intricacies of concurrency click into place. But once you pass that initial rush, the reality sets in. It becomes clear that mastering these topics isn’t just about understanding technical nuances; it’s also about navigating a web of complexities that intertwine across systems, tools, and people.

This journey brings its fair share of frustration and existential concern. As you go deeper, you start grappling with problems that feel abstract and distant, yet profoundly impactful: distributed state consistency, data synchronization, avoiding deadlocks. You realize that these issues aren’t just technical puzzles; they represent the invisible backbone of everything you’re building. And it’s overwhelming to think how fragile these systems are, how they’re held together by code you and your team write, and how any tiny oversight can cause cascading failures.

Yet, perhaps the most exhausting part isn’t just the code; it’s the human element. Once you develop the social skills to communicate these technical complexities to people at different levels, you realize the challenge isn’t just the knowledge—it’s helping others grasp it without drowning them in details. It’s like being fluent in a language others only have a basic vocabulary for. You spend time rephrasing, simplifying, and drawing analogies, only to have people nod, agree, and repeat the same mistakes next week. They’re not at fault; these are tough concepts. But it can be isolating, being the one person who sees the problem three steps ahead while everyone else is still figuring out step one.

Continue reading “A few words on getting into Computer Science in 2024 and on?” →