This blog post is all about: why I gave up on Grammarly, what's the difference between ReSharper-aided Visual Studio and Sublime Text or Vim, did VS cripple generations of software developers and why I'm skeptical of modern IDEs (hint: they are not solving the problems they should be solving ...)I do write a lot. Mainly in English.I've got a lot of practice, so in my case, the process of writing is quite fluent, but it still takes some time - structuring thoughts, adding content, proof-reading, polishing, etc. That's why all the ideas or tools that could help me save…
This blog post is all about: why engineering leadership is both - engineering and leadership, why both strategic & tactical perspectives HAVE to be mixed (and what happens when they are not).This is one of THESE posts. No solutions, no conclusions, pure rant ...WAIT, wrong attitude. Not "rant", but "an unfavorable observation".Yeah ... That's better ;)I work in a mode I've nicknamed "continuous recruiting" - basically, if there's an person with relevant skills/experience and a correct attitude who could truly benefit a team, it's my duty (& pleasure) to build up a position/role for such a person…
This blog post is all about: "divide & conquer" rule's applicability for compensation considerations :), why getting down to individual skills is a waste of time, what's the point of rewarding loyalty, how to incentivize people so they specialize, what to do with project heroes (& their reward expectations) and why you should read the forthcoming posts in the series :)Part I of the series can be found here.Let's summarize how far did we get until now: one can't always determine directly how much (tangible) value an individual brings, so as human beings are poor in absolute evaluations, it's probably…
This blog post is all about: why salaries are so tricky in software engineering, an evolution in approaching the topic of promoting/compensating people, why market evaluation can't be relied upon, what are 2 best ways to evaluate how much you're worth, are people always comparable?Salaries in Software Engineering have always been a tricky topic. Because of several things: industry evolving so fast, companies being so different & position naming so inconsistent, experience & proficiency not possible to "deduce" directly out of tenure and at last but not least - huge disproportion between demand & supply on the job…
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…