20
Gnarly Learnings from June
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.
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.
Here we get a great reminder to lean into your framework tools and conventions to reduce the complexity introduced in your application.
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.
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.
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.
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.
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.
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.
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.
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.
20