Author: Boro Sitnikovski

Games People Play overview

Social generalization, besides its flaws, always has advantages over no generalization. Mental stimulation helps both the mental and the physical state of a person. People like to structure the time (e.g., someone breaking the silence in a group) – this structure is aka programming, and it can be material (parent)/social (adult)/individual (child).

Continue reading “Games People Play overview” →

Beyond Software Engineering

My team lead once asked me a very simple question – “How does Boro compare today, to Boro a few years ago”?

(One of the things that a person should practice is applying the Socratic method. By asking questions like the one above, people usually get into thinking mode (like myself in this case), and they write/do stuff based on the question 🙂 Most folks in my current team have mastered the Socratic method.)

My answer was brief; working on the full-time hiring team was the biggest contributor. However, one day while I was driving*, I thought of a bit more general question: “How does one go beyond software engineering?”, put a little bit more thought into that question, and I want to share my thoughts here.

* We can debate whether the Socratic method triggered this or it was random 🙂

Continue reading “Beyond Software Engineering” →

First talk on DevEx & DevRel

At the WordPress 31st Skopje Meetup, my friend and I presented on the topic of DevEx & DevRel.

Here is a brief summary of some of the stuff we talked about:

  • There is no single definition of DevEx/DevRel. Our take is that it’s like a tourist guide that spreads the word (company culture) across.
  • It can be seen as an engineering intersection with one or more of {HR, Marketing, Product, Community, Content}
  • The three pillars Product+Community+Content are useful fictions and a lot of stuff overlaps between these
    • Community: meetups, conferences, workshops, hiring, mentorship…
    • Content: blogging, documentation, tutorials, podcasts, talks…
    • Product: coding examples, integrations, collecting and applying feedback, tooling, processes…
  • Developers by nature are skeptical folks * – we can achieve much more by doing “indirect marketing” (things such as mentorship, bottle pickup, content writing, etc.) with the hope they follow along and improve – more specifically, they see “by example” why some things are useful doing and they eventually start doing it themselves. This approach is in contrast with e.g. “let’s actively teach you [X] so that you will be better at [Y]”, where I think this will repel more than attract.
  • DevEx exists because of the intersectional voids between engineering and [X]. Building relations/partnerships helps fill these voids.
  • Measure success in terms of lifetime value rather than OKRs – you can measure how many fishes someone fished but you can’t really measure how you taught someone to fish.
  • Why DevEx/mentorship: Third perspective argument – developers get easily stuck in a cycle when programming (focused work) and it is easy to “forget” the big picture.

* This argument is of the form “Everybody is a skeptic” – you either agree with it, or you don’t, which proves the point in any case. One can argue it’s an unfair argument 🙂