tl;dr:“When your architecture grows beyond a single container, things you thought were simple can now break in a variety of ways. In this post I want to highlight different lessons I learned while developing and maintaining large distributed systems at scale."
tl;dr:"There are many pitfall that can lead to useless, wasteful and confusing logs. Therefore I follow a specific set of practices which allows me to write better logs while also being consistent across the system." Eliran discusses here.
tl;dr:Eliran discusses 3 ideas that resonate with him the most from the mentioned book: (1) Zero-tolerance towards complexity. (2) Smaller components are not necessarily better for modularity. (3) Exception handling accounts for a lot of complexity.
tl;dr:Eliran discusses 3 ideas that resonate with him the most from the mentioned book: (1) Zero-tolerance towards complexity. (2) Smaller components are not necessarily better for modularity. (3) Exception handling accounts for a lot of complexity.
tl;dr:“The core message is that you shouldn’t just go with the first design that comes to mind. Instead, come up with at least two different designs even if you have to force yourself. No matter how confident you are, you’ll make better decisions when you compare options side by side.”
tl;dr:“A big debate among developers is whether to write code for today’s problem or to build a general-purpose solution for future needs. Both approaches have their pros and cons. Specific-purpose code can quickly become messy. But overly general code can add unnecessary complexity. This post, obviously opinionated, argues for a middle ground. That’s the sweet spot, as always.”
tl;dr:"There are many pitfall that can lead to useless, wasteful and confusing logs. Therefore I follow a specific set of practices which allows me to write better logs while also being consistent across the system." Eliran discusses here.
tl;dr:"There are many pitfall that can lead to useless, wasteful and confusing logs. Therefore I follow a specific set of practices which allows me to write better logs while also being consistent across the system." Eliran discusses here.
tl;dr:“Have you ever noticed how some software engineers seem to rocket up the career ladder, while others, just as talented, barely move? It’s not always about how good you are with code; sometimes, it’s about playing the game smartly. This got me thinking when I was reading “The 48 Laws of Power.” I chose the 5 laws that I think are most relevant and impactful for software engineers.” (1) Never outshine the master. (2) Concentrate your forces. (3) Win through your actions, never through argument. (4) Make your accomplishments seem effortless. (5) Always say less than necessary.
tl;dr:“I feel like there are some key features missing that would make me switch vendors. I mainly have two problems with current solutions: (1) It can get tedious and messy to turn on/off a feature when multiple FFs were placed for it. (2) Your codebase becomes a FF graveyard if you don’t remember cleaning it, and you probably don’t…” Eli provides suggestions on how to address these.