An Engineering Manager Challenge

This post came to mind while reading this post on LinkedIn, which is a share of this post by Kelvin Mai, and the follow up post Ted Neward made here. Read up on those for more insights into this topic.

Before diving into the details, it’s important to note that the criteria outlined here leave several questions unanswered, which could significantly impact the final decision. Factors like the specific nature of the projects, team dynamics, and long-term strategic goals are crucial and could sway the decision in different directions. That said, let’s break down the options.

Bringing on Two Junior Developers

Pros:

  1. Boosted Bandwidth: Two fresh faces mean more hands on deck to share the workload, increasing overall throughput.
  2. New Blood, New Ideas: Junior hires come with fresh perspectives and a ton of enthusiasm that can rejuvenate the team.
  3. Long-term Investment: Junior devs are like seedlings; with the right nurturing, they grow into valuable assets, contributing more as they develop.
  4. Flexibility: Juniors can be shaped to fit the team’s needs and culture, making them adaptable assets.

Cons:

  1. Boosted Bandwidth: Emphasis here though is on “throughput” above in the pros and not on committable, usable, and well written code you want and can use in the project. Increased throughput can be a negative, and IYKYK and can think of this as “induced demand” but for code.
  2. Training Time Sink: Juniors need a lot of guidance, which can be a major time drain for the senior members.
  3. Ramp-up Period: They won’t hit the ground running. Expect a learning curve before they start delivering at full capacity.
  4. Management Load: More people means more management. Even if they’re juniors, it adds to the admin overhead.

Hiring One Senior Developer

Pros:

  1. Expertise on Tap: A senior dev brings a treasure trove of knowledge and experience, perfect for tackling complex challenges and making strategic moves.
  2. Mentorship: They can mentor junior team members, leveling up the entire team’s skill set.
  3. Quick Impact: Seniors can dive in and start contributing much faster than juniors, thanks to their experience.

Cons:

  1. Higher Price Tag: Senior talent doesn’t come cheap. They’ll command a higher salary, impacting the budget more significantly.
  2. Cultural Fit Risks: There’s always the gamble that a senior hire might not mesh well with the existing team dynamics.
  3. Single Point of Failure: Relying on one senior dev for critical tasks can create dependencies, potentially leading to bottlenecks.

The “Do Nothing” Route

Pros:

  1. Save the Budget: Not hiring anyone saves money, which could be redirected elsewhere.
  2. Focus on Current Team: No new hires mean you can double down on developing and optimizing the current team.

Cons:

  1. Opportunity Cost: Leaving budget on the table means missing out on potential gains in capacity and productivity.
  2. Burnout Risk: Your current team might end up overworked, risking burnout and decreased morale.
  3. Stagnation: Without fresh talent, innovation can stagnate, and the team might struggle to keep up with growing demands.

The Decision

Let’s get real: not hiring anyone is likely the worst choice here. I know some would disagree in some situations, but if you’ve got budget allocated for new talent, use it! Even if the ROI isn’t immediate, it’s about positioning the team for long-term success. Hiring is an investment in the future—whether it’s two eager juniors ready to grow or a seasoned senior ready to lead and mentor. In this scenario, hiring one senior developer is the strategic move. You’ll get immediate expertise, mentorship for the juniors, and a stronger foundation for future growth. Let’s make that budget work for us and set the team up for success!

Addendum

This post attributed to leading me down the path to elaborate on staff and hiring details, including The Toxic Truth About Coding Challenges in Technical Interviews and then the elaboration on that post with The Reality of “Code Challenge” Culture Outcomes Among Large & Small Organizations.

What’s The Practice with Rider & .NET Solutions/Projects? How to resolve IDE errors?

Alright, I’ve fought with these kinds of things since the inception of .NET, the key difference now is that there are the variances in .NET versions and also IDEs. The question is, how should I setup my solution and respective projects?

First – .NET Solution

Usually what I do is create an empty solution. Name it, check the options accordingly to create a directory and make it a Git repository.

Then, as a kind of general practice I create a class library to build out logic and what not, and add a test project and then whatever the interface is going to be. That might be a web app, a GUI, or console as I’ve got selected here. Sometimes, if useful I go ahead and create a Dockerfile.

At this point, there are a few key problems I always bump into. Obviously, since I have a repo I need a .gitignore file, preferably a README.md, and maybe even a license file right? How does one add, so that the IDE is aware of them, any extra files at the solution level? What I usually do here, is use the terminal to just build out the solution level files, but then the IDE doesn’t know about them. Similar problems come up in the other .NET IDEs like Visual Studio and such.

Second – Open a Folder Solution

The second type of solution I find myself creating is started by opening a repo folder.

Empty, with nothing else that looks like this.

Creating a .gitignore and other respective files is easy at this point. As a right click will allow me to do just that. I’ve also added some projects.

At this point everything works great. As you can see below the runner is wired up, the IDE is aware of the tests, and runners are available for that.

One problem I’ve run into however with this technique, is sometimes I close this type of project – one started by merely opening the folder – and all this awareness just disappears. On the same machine, same folder, no deletion of the .idea folder or anything like that. It just loses all the awareness.

So my question is, which method do you use to start a project and how to do you, fellow .NET coders, work around these types of issues?

Software Development: Getting Started by Getting Organized

A few weeks ago I wrote up the post on the tech I’ve decided to move forward with for my new project. This post is going to cover the collection of features, domain details (i.e. what is the use case, etc), and related project collateral. Instead of just slinging code like many of us programmers often do, I’m going to layout what I’m trying to build, what features I want, and how I’m going to put those features together before delving into actual code. This way, my hope is I’ll be able to keep track over time better, and if any of this turns into something I’ll then have something to keep working from instead of throwing a code base over the fence to other devs. A crazy action that happens all the time, but is something worth avoiding!

Continue reading “Software Development: Getting Started by Getting Organized” →

Performance Monitoring and Tuning in Relational Databases: With Observability Lagniappe

This is a continuation of my posts on relational databases, started here. Previous posts on this theme, “Data Modeling“, “Let’s Talk About Database Schema“, “The Exasperating Topic of Database Indexes“, “The Keys & Relationships of Relational Databases“, “Relational Database Query Optimization“, “Normalization in Relational Databases“, “Database (DB) Caching and DB Tertiary Caching“, “Security and Authentication in Relational Databases“, A Guide to Backup and Recovery Options for Relational Databases: Focusing on SQL Server, Oracle, MariaDB/MySQL, and PostgreSQL, and Concurrency Control in Relational Databases.

In the ever-evolving landscape of software development, the performance of relational databases isn’t just a feature; it’s a critical component of system health that can dramatically influence user satisfaction and operational efficiency. We’re starting a deep dive into the world of performance monitoring and tuning for relational databases, uncovering practices essential for maintaining robustness and speed during database interactions in this post.

Continue reading “Performance Monitoring and Tuning in Relational Databases: With Observability Lagniappe” →

Starting a New Project – Let’s Choose a Tech Stack!

It’s time to start a new project. Because one can never have enough side projects! /s

This particular project I’ll be writing about in this post is derived from the multi-tenant music collector’s database I’ve already started working on. I’ve finally gotten back to it, during a slight break in collecting and music listening, to write up some of my thinking about this particular project.

Stated Objectives For This Application

  1. Personal Reasons: I always like to have side projects that I could make use of myself. Since I’ve recently started collecting music again, and in that am a new collector of vinyl albums, I wanted a better way to organize all that music and the extensive history, members, song, lyrics, and related information about the music and artists.
  2. For Everybody: Beyond the desire to have a well built application to provide the capabilities I’ve described above, I also want to provide this capability to others. In light of that capability, I’ll be designing this application as a multi-tenant application so that you too dear reader, once I get it built can use the application for your own music collection.
  3. Choose The Tech Stack: I’ll need to write this application in something, obviously, so this post is going to cover my reasoning for the tech stack I’m going to use. The application will be built in three core pieces: the database, the services and middle tier layer, and the user interface. I’ll detail each and cover the reasoning for the stack I’ll choose for each section.
Continue reading “Starting a New Project – Let’s Choose a Tech Stack!” →