Recently, I saw some heated arguments about the optimal ratio of senior to junior developers on teams.  There was much mashing of teeth about how companies are hurting themselves by having many seniors and few, if any, junior developers.  Long threads about proper ratios, code complexity, code quality, and management oversight followed. That's all nice in theory, but the reason is that Senior Developers are overrepresented on development teams, is that they are *relatively* cheap compared to junior developers. Let's look at some numbers from glassdoor.com:

• Junior Java Developer - $75,697/year
• Java Developer - $88,116/year
• Senior Java Developer - $106,542
• Principal Java Developer - $131,235/year

A senior developer costs about $31,000/year more than a junior developer, implying that a senior developer is 41% more productive and useful than a junior developer (or that a junior is 71% as effective as a senior developer). We are taking a very generic view of things, but if you expect a senior developer to be twice as effective and productive as a junior developer, then the value of a senior developer would be 2x a junior, or $154,000/year. Relative to junior developers, the average senior developer is 30% cheaper. My personal experience in Chicago looks even worse, with 1x junior devs getting paid around $100,000/year and 5x seniors getting paid $175,000.  This is effectively a 65% discount over junior devs. As a result of these huge discounts companies do the logical thing and only hire junior devs when they can't hire enough senior devs.  The economically optimal number of junior developers on a team is always 0. But wait you say, what about non-salary costs?  Does that have an impact? Yes, but it makes the relative value of seniors worse:

• The average employee receives about $30,000 in non-salary benefits (mostly healthcare).  Hiring 2 juniors instead of 1 senior costs an extra $30,000/year
• Managers can only manage so many people, adding more juniors means adding more managers, scrum masters, and other process people.

Why senior developers are relatively cheap is a good question, but not one I feel qualified to answer.

I've used dozens of config systems in my career, heavy XML, lightweight INI, and more "Config is easy, I'm just going to write my own" disasters than I care to count.  Recently I have been working in Node and deploying to Heroku, and I found what may be my favorite config system of all time. Node-Config is a JSON based hierarchical system that plays wonderfully with Heroku's Environment variable based config.

What does a hierarchical system mean?

Imagine you are working on a system that can be run local, dev, or production, with different database and remote services.  When running locally your config might look like this:

{

    "dbConn": "DB Running locally on my laptop",

    "webapp": {

      "port": 8080

    }

},

dev also runs on port 8080, but uses a shared database.  Instead of overwriting everything, you only have to specify the deltas:

{ "dbConn": "Shared database location", }

Node-Config used the "NODE_ENV" magic variable to know which environment you are running, but no matter which environment you are running, config.webapp.portwill be 8080.

Where does Heroku fit in?

Heroku injects config variables into the system as environment variables at run time.  When using a Heroku Postgres database, they not only manage the system, but they will also automatically rotate the connection details periodically.  That's great, but if means you can't have a static config file. Well Node-Config ALSO supports environmental variable overrides! You need to create a config file called custom-environment-variables.jsonand place it with the rest of your config.  Instead of specifying values, you specify the environment variable names!  Continuing our example:

{

    "dbConn": "HEROKU_POSTGRESQL_NAVY_URL",

    "webapp": {

      "port": "PORT"

    }

},

PORT is Heroku's default PORT, and HEROKU_POSTGRESQL_NAVY_URL is a environment. Your Heroku config dashboard will look something like this: Node-config will pull Heroku's config vars in at run time.  No need to handle multiple config injection logic.  Set it once and it will all just work like magic!

Conclusion

I really like the combination of Node-config with Heroku.  The hierarchy layering keeps things simple, even while Heroku is rotating security keys under you!

Bonus for Visual Studio Code users

I use vsCode for my development. If you follow the defaults, the environment and launch.json setup will look a lot like this:     launch.json, which is vsCode's run/debug config will look like this:

{

    "version": "0.2.0",

    "configurations": [

    {

      "type": "node",

      "request": "launch",

      "name": "RUN DEV",

      "program": "${workspaceFolder}/src/app.js",

      "env": {

        "NODE_ENV": "dev",

      },

      "outputCapture": "std"

    },

    {

      "type": "node",

      "request": "launch",

      "name": "RUN PROD",

      "program": "${workspaceFolder}/src/app.js",

      "env": {

        "NODE_ENV": "production",

      },

      "outputCapture": "std"

    }

}

The first thing I do after creating a new branch, is write the changelog. Stating what new features go in the branch helps to focus my coding and keeps the branch clean and focused. As I work I do a reread and fix the changelog to match the implementation reality. There have been countless instances where I have started coding a second feature, realized it doesn't fit, and used that signal to know that this branch is done and should be merged. If you write the changelog after you code, you probably won't write a changelog. If you do it will be incomplete, because you won't remember everything. Either way your branches will be less focused, and more difficult to merge. Write the changelog first! Your fellow developers, including future you will thank you for it!

Thanks for joining me!

Good company in a journey makes the way seem shorter. — Izaak Walton