Polymath Engineer Weekly #90
Polymath Engineer Weekly #90
Observability Costs, AI vs 10x Programmers, Microservices Principles, Multithreading, Event-Driven Pitfalls, Product-Market Fit, Hacking APIs
Hello again.
Comic of the week
Links of the week
Why is observability so expensive?
Observability vendors will gladly identify any number of other causes such as “It’s important and should be 30% of one’s budget!” and “Stop using metrics and just use events!”, but the fundamental reality as was said previously is that there is simply no free lunch: massive production of telemetry at the source, without regard for the usefulness of the data, will inevitably lead to high costs and unhappy end-users. Someone has to pay for all of that transport and storage.
The Real Threat To Your Job Now Is Not AI
Picture this: you're diligently working on a project, navigating through lines of code like a seasoned explorer. Suddenly, a colleague swoops in, effortlessly solves a complex problem in minutes that had you scratching your head for hours, and then proceeds to refactor the entire module with surgical precision. You've just encountered a 10x programmer in action.
Microservices Design Principles You Really Need To Learn
As you apply these principles in your own projects, don't be afraid to experiment and iterate. Each application is unique, and what works for one may not work for another. By embracing a mindset of continuous improvement and learning from both successes and failures, you'll be well on your way to mastering the art of microservices design.
Multithreading and the Memory Subsystem
In this post we investigate how the memory subsystem behaves in an environment where several threads compete for memory subsystem resources. We also investigate techniques to improve the performance of multithreaded programs – programs that split the workload onto several CPU cores so that they finish faster.
Event-Driven Architecture Fundamentals and Common Pitfalls (and How to Avoid Them)
Designing event payloads with all of the data at the time of the event is often considered a prudent thing to do. However, if the data changes between the time that the event message is published and the message is processed by the receiver, the processing will be based upon stale data. Instead, design the event message with limited data to prevent sharing stale data. Consider details such as the field that was changed, the old and new value, and any additional details that the message receiver will use to determine if further action needs to be taken or if the event should be ignored.
Product-Market Fit Isn’t a Black Box — A New Framework to Help B2B Founders Find It, Faster
“From the outside, you can romanticize a founder’s life and think, ‘The world's your oyster. You can build whatever you want. You're going to start a company, it'll be great. You get to decide everything.’ And that's all true, but in the day-to-day, it's more like, ‘What am I doing? Does anyone care? Will anyone ever care?’ There’s so much in the early days where you can't tell if you’re doing it wrong. Having a group of other people going through a similar experience to talk about that with and normalize some of the uncertainty is really, really helpful. It can help you figure out if it’s an idea that you’re pulled toward because you’re just looking for something in all of the uncertainty, or if it’s actually viable.”
I have created a survey to get feedback from you. It takes only 2 minutes.
Book of the Week
Hacking APIs: Breaking Web Application Programming Interfaces
Do you have any more links our community should read? Feel free to post them on the comments.
Have a nice week. 😉
Have you read last week's post? Check the archive.