This blog post is all about: the Mother of All Rules; consciousness of assholes; why being an asshole with almost 100% certainty eliminates the possibility of building up sustainable, high-performing team; what's the problem with sarcasm (& how easily it can be solved); How not to be an asshole (it ain't that hard, really ...) Each week I'm trying to share some thoughts & frequently even make some advice to you: about architecture, leadership, technology, management & what not. And still, until this very day I didn't mention THAT. The most important advice. The most valuable rule. The mother of all…
This blog post is all about: that Ninja doesn't differ from Rockstar, why Fullstack != Versatile, is switching tech stacks a failure, what does the tech swap's success depend on, why bother re-specializing if job market is a paradise for any tech, how learning Elixir changed my C#-fu.When browsing programming job offers you're getting attacked by very different position descriptions:nouns that depict position vary: Engineer, Software Engineer, Programmer, Developer, Ninja, Rockstar, ... :)seniority adjectives vary: junior, mid, regular, aspiring, senior, lead, leader, principal, ...the only part that remains the same (& always appears) is the name of the technologyApparently…
This blog post is all about: why task trackers & basic note-taking apps are not enough anymore, where's the border between the need of handling structured & unstructured data, why we need some sort of a database (but with a flexible UI on the top) and what's the current direction of an evolution for personal knowledge management apps.Humans accumulate data. All sorts of. Notes. To-do lists. Vacation destination ideas. Important dates. Family budgets. And many, many more.Some of this data is very specific & we tend to use dedicated applications for that:music playlists in music streaming service…
This blog post covers: why boundaries constitute the structure, why E2E/Integration tests are not enough, what does it even mean "Boundary/Contract tests", who should create such tests & why and how to match expectations of more than one consumer.P.S. All the contracts covered here are supposed to be internal. No multi-tenancy, no general-purpose APIs. Nada.Having a modular split within an application/system is absolutely crucial (beyond some scale), but ... like everything in this world, this comes with certain price to pay & challenges to tackle:boundary correctness - are boundaries set reasonable (to maximize the…
This blog post is all about: the difference between focus on doing and focus on getting done, importance of owning your own metrics (KPIs), why data can be double-edged sword (but the transparency is still the key), that engineer who doesn't introspect into her/his work can be effective only by pure luck and that falling into "victimship" (instead of trying to fix the issue) has never ever fixed any problem.Part III of the series can be found here.Disclaimer: to make this as brief as possible, I've filtered out several side topics - e.g. test pyramid consideration,…
TL;DR: We're looking for a Senior System Analyst that will fit the boots of Functional Architect role for our platform. The main challenges are all about: scaling complexity, effective (& efficient) knowledge sharing, maintaining Ubiquitous Language, cultivating Domain Model that will correspond to the technical Solution Architecture. It's a chance for everyone who'd like to practice Domain-Driven Design w/o all the typical showstoppers that usually prevent it from happening.Scaling is hard. Like really, really, really hard.And I don't really mean traffic or user-base (which ain't trivial either). It's freaking hard to scale out both:domain complexity…
This blog post covers: the practical definition of what heuristic is, example of how imperfect heuristic may solve a problem we're not sure exists, what does it mean "everyday heuristic" (that is not really ad-hoc) and whether it's fair to call heuristic a "short-cut".It's not (& it never was) a surprise that software engineers are much better with terms, concepts & abstractions present directly in the code. I've seen several tech people kinda confused when discussion skewed towards more general problem-solving space - they didn't seem to have a good grasp on some basic terms & one of these…
In this article you'll find out about modern Operations (& why DevOps ain't exactly the thing), what's missing in "you build it, you run it" paradigm, why there's a need for platform-caretaking team, what does it really mean - "SRE", how did we start building an SRE team & what did we struggle with.Ol' good daysIn old good days of computing (I mean - in my case it means 90s, 00s ;>), life was so easy ;P There were development people & there were maintenance people. There were programmers & there were admins + SysOps. They've rarely talked to each…