Returning to first principles…

Over the past few weeks, I’ve heard more than one person, from very different places, mention “getting back to first principles.”

First principles are axioms that we pin stuff to. Another way is to look at what your values are, and what flows from that.

As a pro coder, it’s easy to get sucked into processes, tools, concepts, and philosophies written by others. I mean come on, we can’t build this stuff all by ourselves. We need help! We need IDEs, compilers, frameworks, books, strategies, ticketing, tools, and gobs of other stuff to do this. So yes, we need others to help or nothing is happening.

But it’s also good, every now and then, to double check what we’re doing and compare it against our own values. One of the things I’ve reexamined multiple times is continuous integration. If you caught the latest episode of the Pro Coder Show, I went into detail about how I kind of sort of INVENTED continuous integration as one of my first assignments in my career.

But not really.

Let me put it like this…I spotted the value of building our system on a recurring nightly cycle in order to detect when errors would creep into the system. And that was useful. VERY useful.

And that fundamental idea has become a first principle to me.

Having joined the Spring team in 2010, I later became a part of its Spring Data department in 2017 and within a year’s time, took over as the manager of all their CI pipelines. I began migrating stuff off of our UX-heavy system (Bamboo) in favor of a source control-managed approach. I had already worked with Drone, Travis, and CircleCI and had seen I’d seen the pluses and minuses of various systems in various environments. I later shepherded Spring Data into using a Docker-oriented CI tool called Concourse. It had its own pros and cons, the biggest pro being its “every step inside a container” tactic, which I LOVED.

Simply put, containers provide the perfect tool to ensure the exact environment you wish a step to be executed inside is always there.

Nevertheless, it did NOT support another key thing I needed, branch builds. So after much analysis, I eventually migrated us to good ole’ Jenkins.

Suffice it to say, every time I dug in to solve another problem with a given CI solution, I constantly checked my assumptions and my values in that context and sought out the most critical axioms. And that is how I was able to set aside my accumulated distaste for Jenkins…and actually go back to it! (A biggie being that Jenkins now supported a source control-managed solution, allowing me to avoid its horrendous UX-based configuration!)

BTW something to take note of, is that no implementation of your values is ever perfect. Instead, you must understand your own thoughts and beliefs such that you can weigh any given tool against another and decide which is better. But be ready to accept that nothing will be EXACTLY what you seek.

The same goes for IDEs. I have seen lots of them. Years ago, I spotted certain aspects of IntelliJ IDEA that best fit my need for tools. What is your favorite tool? I spoke to one person that can’t give up VS Code.

I asked “why?”

“Because, I have all the hot keys wired into my fingertips!”

You may think that I’d either laugh or scoff at such an assertion given my adoration for IntelliJ IDEA.

Nope.

Picking a tool because of deep-seated familiarity is not bad reason. You know your tool. Inside and out. The current crop of modern IDEs generally support much of the same stuff, so if you can wield it with such intensity, no need to waste time moving off of it!

The point is when assessing tools, processes, and ideas, to try and spot the handful of characteristics that are most important TO YOU. Then…use them anytime you are evaluating something else.

What are YOUR 1st principles?

If you’re a pro coder or plan to become one then stay tuned for my next article. But if you simply can’t wait then check out episode where I mention how I accidentally invented continuous integration!

?—?Greg