I build tools. I write scripts, plugins, compiled Go code binaries, terraform .tf files, APIs, hacks (a lot of these…). Glue that makes automation happen by connecting together open source projects like terraform, ansible packer, Jenkins, Docker, Kubernetes, Github and so on.
I do a lot of note taking and documentation. Mostly this is to let me pick back up where I left off on code or infrastructure when it has issues or needs to be upgraded or replaced a year or two down the road. Some of those notes & docs might be useful to someone other than myself. If that might be the case, they go here.
intuitive engineering describes taking physical structure and system design out of the lego or erector set
viewpoint — where you piece things together one-by-one — and into an understanding of the art of engineering.
Watch really complex systems, say a network, for awhile and you find unexpected interactions become normal as complexity increases. The same is true for CICD systems and Devops/Infrastructure Engineering tools. There are gremlins in the dark corners.
Totems:
- Avoid wherever possible, complexity, and where you find complexity, work toward a simpler design as a goal.
- The elegant, aesthetically pleasing solution is also in most cases the least effort and personnel to support in the long run.
- Expect and deal with missteps as they show up – complex designs can present opportunities as you work through them that are NOT visible at the start of the project. This is true in building construction. It is also true in network and system design, in software design.
- Make that discovery part of the process, take advantage of those simplified and elegant changes as they present themselves.
- Look for the consequences several steps ahead for each decision.
- How locked into a design does it make you?
- Can you live with that?
- Is there a less restrictive/simpler/better/more elegant decision in design that can be made that doesn’t block off avenues?
- Can you solve a problem once and reuse that solution?
- Is there a modular or plugin design that would keep a flexibility?
- Use open source tooling where that is practical.
- Use best of breed. Build the interconnections and tooling passing from one system to another.
- Customize as little as possible. Write bespoke code as little as possible.
I live in the Northeast and I am currently employed by Toast, Inc., as a Staff Devops/Infrastructure/Cloud Engineer (the titles keep changing).
—doug
