Skills, stories, and software every dev should know - 123dev #46
Posted on November 16, 2021 • 3 minutes • 475 words
Some developers are very skilled. They can do things seemingly impossible for others. It might be developing a feature faster than others, debugging a hard problem, or reaching new scale with systems.
Many times those skills are accompanied by a decent amount of luck. While a skilled developer can replicate something with high accuracy, it’s not always skill alone that helped the first time.
Maybe you’re in the same position. You’ve done some incredible things as a developer, but you haven’t been able to replicate it. In both cases it’s alright. You can be incredibly skilled and still only have a .03% rate of making a hole-in one.
When developing code lots of people talk about optimizing your “inner loop.” The cycle of writing code and knowing if what you wrote works as intended.
For many decisions we make—especially product decisions—there is no inner loop. The feedback cycle for knowing if we chose the right thing can be weeks, months, or years. The further away in time you move from the decision the harder it is to know the reasons for success.
One thing that is important to do with long feedback loops is to collect relative data from the moment you make a decision until the time you know the decision outcome. You can’t attribute success to a single decision, and you can never accurately compare two simultaneous decisions.
Layering data from multiple decisions can retroactively shrink feedback loops to discover patterns. Thankfully, people are very good pattern matchers and even with long feedback loops the patterns you find can help you make better decisions with less data in the future.
I learned a few new
sed tricks from this repo. You might too.
GitHub - adrianscheff/useful-sed: Useful sed scripts & patterns. Useful sed scripts & patterns. . Contribute to adrianscheff/useful-sed development by creating an account on GitHub.
Creating infrastructure with code is often a very imaginative process. We used to visualize our infrastructure because it was physical servers, switches, and cables.
Now, it’s all virtual and our tools automatically create the component dependencies with directed acyclic graphs (DAGs). It is much harder to visualize what is being built, but thankfully with tools like rover if you’re using Terraform you can still visualize and explorer your infrastructure.
GitHub - im2nguyen/rover: Interactive Terraform visualization. State and configuration explorer. Interactive Terraform visualization. State and configuration explorer. - GitHub - im2nguyen/rover: Interactive Terraform visualization. State and configuration explorer.
If you’re using the AWS CDK to build your infrastructure there’s also this tool to create diagrams of your AWS components. It’s not quite as powerful and rover but getting up-to-date diagrams can help you better understand the infrastructure.
GitHub - pistazie/cdk-dia: Automated diagrams of CDK provisioned infrastructure Automated diagrams of CDK provisioned infrastructure - GitHub - pistazie/cdk-dia: Automated diagrams of CDK provisioned infrastructure