Software Engineering

This is currently an unordered dump of thoughts that need refinement.

• Estimation

• Queueing Theory

• On Dry Code

• A Way To Work Visually With Code

• Use ASDF to manage all of your Kubernetes and Flux dependencies

• Programming Fonts

• Don't Commit Log Statements

• M1 Mac Setup Guide

• Setup iTerm

• Junk Drawer Programming

• Rust WASM

• Other Thoughts

• Create Your Own Automated Testing Framework Anywhere

• Bookmarks For Later

• Fake Agile - Cargo Culting Design Thinking workshops, and scrums, and retros without truly asking whether it works for them. I've seen this happen all the time with Scrum and everything else. Always saying it’s good without questioning. Not adhering to what Andy Hunt was saying about it

• A better form of Tracer Bullet Development - like how a blurry image gets sharper and sharper as it loads. I should come up with a buzzword name for that

• You can’t be influential if all you’re doing is cargo culting, very rule based and copying of prodcedures. You can’t be influential by copying procedures. Like Scrum

• You Can’t Say “It’s Working” if you don’t have the data. Developers are just as guilty of this and will equally say something is working even when they don’t have the data to back that up

• All of the bullshit that Software Engineers do

  • It’s your reputation in the line so you have to waste time trying to make it perfect

• How to deal with always-available classes (like Ecto and JSON) that are put throughout your code when you are trying to adhere to Ring architecture and Functional Shell / Imperative core

• Most companies with technology problems actually have people problems, online leasing being a good example.

• Emergent Behavior vs Rigidly Defined Systems

• Quantum Computing

• Machine Learning

• Deploying Apps

• Electron

• Docker

• Kubernetes

• Istio

• Comparison of lab machines

• Comparison of lab equipment

• Guide to technology in the lab

• Comparison of the software landscape in the lab

• Determining what value you’re getting from your data

• How we use Protocol Buffers and Tracer Bullet Development

• Getting started with TBD

• The difference between Protobufs and GRPC

• Getting started with protocol buffers

• How we use Kubernetes to do X

• Why we’re using Istio

  • Auth
  • Storage
  • But that just scratches the surface

• The biggest thing that strikes me working in tech leadership is how many biases there are that need to be navigated. Most times these biases are not well founded, are not appropriate for the situation in time, or they remove the human element from the equation and value the tools over the people at hand. In the worst case scenarios, they are downright detrimental to the business. I have encountered engineering directors with teams using Go, who push forth an Elixir effort simply because they do not like Go, at the detriment of the business. I have seen CTOs push forward on extreme scaling, spending hundreds of precious start up resources and thousands of dollars at the detriment of their business. I have seen IT and QA directors cause dissent and use their pull to fire engineering directors simply because they did not want to push forward with CI and Terraform. I have seen countless engineers also hide their biases by expounding the virtues and specs of said technologies. For these reasons I also tend not to trust those in engineering who attempt to hide their biases behind specifications or utopian propaganda goals. The pragmatic programmer. https://t.co/FY9jrxv6nC https://twitter.com/nateberkopec/status/1250584158620971008?s=21

• Worth reading: https://m.signalvnoise.com/four-letter-words/ https://medicalxpress.com/news/2020-04-people-decisionand.html

• Write blog posts about all this stuff: https://en.m.wikipedia.org/wiki/Theory_of_constraints

• being a CTO does NOT mean being a benevolent dictator of technology https://news.ycombinator.com/item?id=22935878

• Second and third order effects

• Blockchain compliant database like Datomic

• https://commoncog.com/blog/the-mental-model-fallacy/

• Magic tricks of testing for JavaScript adapted from Sandi Metz

Why I'm Building a Side Dish (And Maybe You Should Too!)

• https://www.thestar.com/news/insight/2016/01/16/when-us-air-force-discovered-the-flaw-of-averages.html - This is probably a good article to take notes on for competing in business. Another article that might be useful is Paul Graham’s beating averages article
• This is gonna g to have done useful anecdotes about how a start up MVP should be done. I could make a blog post. Should also consider finding the “ship it not ship shit” quote from Basecamp. This article also cites the source of “You should be embarrassed by your 1.0” https://blog.asmartbear.com/slc.html
• Probably worth writing an article on security as well
• https://krebsonsecurity.com/2020/04/when-in-doubt-hang-up-look-up-call-back/ — this site is good for security focused ideas
• Book on engineering management https://news.ycombinator.com/item?id=22033129
• Book recommendation: Designing Data Intensive Applications
• Article Recommendation: https://medium.com/@copyconstruct/testing-microservices-the-sane-way-9bb31d158c16
• Blog post about ML legalities around training data, and how to anonymize training data https://en.m.wikipedia.org/wiki/Authors_Guild,_Inc._v._Google,_Inc.
• Goodbart’s Law https://www.sketchplanations.com/image/167369765942
• Growing teams exponentially grows their communication lines https://twitter.com/swiftonsecurity/status/1255287520461492224?s=21
• Perform a mechanical turk study on the composable search pattern I've been employing with FullStory recordings
• When the brain isn’t ready to process, it isn’t ready to process , possible blog post of things I’ve observed
• https://en.m.wikipedia.org/wiki/Defence_in_depth
• https://thedesignsquiggle.com
• C4D diagrams
• https://twitter.com/rjs/status/1258887355575889920?s=21
• https://news.ycombinator.com/item?id=23285521 And the host thread are good writing on technology choices. Particularly thinking about human cost vs hardware cost.