These days, the Software Engineer staying within one or two frameworks and languages seems gone. At work, I develop in 4-5 languages (including DSLs) […and] integrate with HashiCorp Vault and push around GitLab pipelines regularly, integrating with security scanning tools and configuring/controlling automated change records, test-reporting, and artifact deployments.

2021 has been an extraordinarily-busy year for me.

In late 2020, I earned my AWS Certified Cloud Practitioner certification and have been pretty deep into AWS and DevSecOps ever since. I now rip through Terraform as well as SAM to fulfill IaC needs at work. At home, I’m using SAM and CloudFormation, but still capturing IaC. GitLab pipelines are a nothing-burger to me now, and it’s curious to see how much I’ve grown.

By this point, I have hopefully convinced the software engineers, developers, recruiters, and other interested technical people reading this blog that documentation is important and that we owe it to ourselves, our colleagues, and our users to provide high-quality documentation for our projects.

We also owe it to our future-selves not to build out infrastructure that is silly.

To this end, let’s take a moment to talk through the orchestration of documentation. Sure, we can build out documentation, but how might we automate this process?

Swagger started life as an offering from SmartBear. SmartBear then donated the API specification to the Open Source community, where it was re-branded OpenAPI 2.0 … There now exists the OpenAPI 3.0 specification [and I go through a bit of pain to generate this automatically, as Springfox support for OpenAPI 3.0 hasn’t yet come out of experimental channels]. [I]s it really worth doing all this for the sake of documentation? [Y]es, it is worth the effort.

[Swagger], or something like it, seems a good hedge against you-of-the-future cursing your past self for shortsighted and possibly slipshod design. In effect, using such tools can help you become a more considerate engineer, if only to yourself.

I have been thinking about APIs for years, both on the “consuming” and “creating” side.

Most of the APIs I have come across in private development have been either completely or relatively undocumented, some of the better-documented examples using Javadoc-style inline comments. There has to be a better way.

Differentiating between good software and engineers, and outstanding software and engineers […] comes down to a simple word: consideration.

I have spent considerable time over the past two decades thinking deeply about a singular common attribute of high-quality software, software engineers, and engineering. (NB: I have more-recently framed this thinking within the context of web sites, so my examples will pull from this, but the concepts hold through other software engineering targets and environments.)

How does a developer address decision fatigue? Learn another tool! How does a developer pivot to demonstrate qualifications around a central cluster of skills? Write software for this, of course!

I’ve been looking into GraphQL lately, and at serving GraphQL endpoints connected to a MongoDB data-store.

Why would I do such a thing? It actually ties into my earlier blog post about decision fatigue. I also have “job-fatigue,” in that I have deep interest across many domains and within many disciplines and sub-disciplines. While I have studied software development for years and thrown products together in many languages, I am now looking to continue my focus on the JavaScript development stack, as I find it rewarding via rapid-prototyping and very quick development-feedback-testing-deployment loop times.

JavaScript suffers and imposes Decision Fatigue on developers. I am enjoying working with React and Express, but the search for better tools and techniques is exhausting!

JavaScript [under the Node.js ("Node") ecosystem] has a reasonably well-known limitation: it is prone to cause decision fatigue.

Over the past month or so of free-form investigation, I have juggled the following technologies or tools:

• Typescript
• TDD Jest (Chai/Mocha were considered, but I think Enzyme may better-suit my needs, and Enzyme seems to best-pair with Jest)
• Multiple CI build/configuration/manipulation scripts
• Different code coverage tools (e.g. CodeClimate, inferno-scripts test --env=jsdom --coverage)
• MobX (I tend to use Redux, but I’m exploring MobX with Inferno in building a ResumeBuilder)
• GatsbyJS with accompanying tools Apollo and GraphQL
• Various Functional Programming techniques–I know the theory behind these (thanks, misspent academic youth!), but something like Elm still makes me worry about how I’ll run this through Babel to polyfill and present to Webpack
• Performance optimization–how do I definitively prove, aside from either running timing-scripts in the CLI or looking at Chrome’s debugging console, that the apps I write are production-ready?

This list, while exhausting, is not exhaustive. I have worked through many technical stacks in my time, and I really like the Node-based stack It has good infrastructure, reasonable-seeming performance (text-file parsing aside–Python beats the daylights out of JavaScript for this), easy deployment out to Heroku and friends, and an active community. Unfortunately, there is something of a paradox of choice here, and this leads to decision-fatigue.