We love reading, watching, and listening to constantly update our skills and learn new perspectives. Here are some of the exciting pieces we learned from this month.
On the Diverse And Fantastical Shapes of Testing
Last month, we opened with a great article about the testing pyramid and its various permutations over time.
This article adds more historical context and language we can use the help frame the discussion of what kind of test we're writing - and why it matters.
Simple Things Should Be Simple
Here we get a great reminder to lean into your framework tools and conventions to reduce the complexity introduced in your application.
Intro Guide to Dockerfile Best Practices
Docker is a very powerful, and intimidating, piece of technology. These steps, carefully applied, can help you manifest improvements to your Dockerfiles in build speeds, maintainability, and repeatability.
Code Reviews—or not—at an Early Startup
Our team benefits from regular code review, and frequently holds off on merging any work until a review has been conducted. However, that's an intentional and agreed-upon norm. Being clear and direct on the "rules of the road" and expectations across your team can be your biggest ally in ensuring that everyone is on the same page with shared values and an understanding of how to operate.
An incomplete list of skills senior engineers need, beyond coding
A Senior Engineer at one company may not be considered a Senior Engineer at a different company. However, regardless of the difficulty in this industry of consistently grading levels, these skills are qualities that I hope everyone has someone on their team that can demonstrate - and are worth investing improving in yourself.
Don’t Feed the Thought Leaders
How do you get universal buy-in, or alignment (as this article presents it) on your big project or initiative? More importantly: should you? That seems dangerous to ask, but I enjoyed how this article presented a lens through which you can evaluate feedback you receive and how that judgement can lead to improved outcomes.
About Pool Sizing
Properly sizing a connection pool is a hard problem to resolve. This summary provides a technology-agnostic approach to thinking about these concepts. For rubyists looking for tactical advise on sizing Sidekiq database connections, consider reviewing this resource.
140,000 lines of code: why we built our own licensing system
The classic build vs. buy debate is one that's never truly answered, even when it's decided. (I've taken some swings at explaining how to frame that decision.) This provides some great perspective of someone looking back on one such decision, evaluating it in retrospect, and providing some suggestions for your next build vs. buy decision.
Good and Bad Elixir
Forgiving the framing of code inherently being good or bad, I appreciate the examples and detailed explanations on the downsides of certain approaches and alternative solutions that benefit the application.
Your product is a joke
This is a great kick-off for any discussion on how to present your work to fellow co-workers or clients. Building a good narrative for your work is a hard skill to practice, and often our technical descriptions are important but dry. Hopefully, we can use some of these lessons to better communicate the importance of our work without tacking on needless technical context.
Contributors
Learn more about how The Gnar builds software.
Top comments (0)