View profile

123dev #46: Skills, stories, and software every dev should know

123dev #46: Skills, stories, and software every dev should know
By Justin Garrison • Issue #46 • View online

A golfer makes a hole in one by skipping the ball over water
A golfer makes a hole in one by skipping the ball over water
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.
Feedback loops
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.
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.
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.
Did you enjoy this issue?
Justin Garrison

1 gif, 2 comments, and 3 links to make you a better developer and person

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue
Los Angeles, CA