Category: Programming

Impressions of my first Daily Chess game

I recently played my first Daily Chess game with one of my friends on Chess.com, and I noticed that Daily Chess is a perfect format for improving one’s chess skills. It basically gives you 24 hours to make a move.

I loved the concept of conditional moves, which allow you to define a few “if-then”s depending on the opponent’s path.

All this gives you much time to do analysis without the time pressure. The most important bit is that you make a move when you feel in the mood, and each move you make can be treated like its own puzzle – this allows you to maximize your performance where for example, my accuracy was 88.1%.

1. e4 e5 2. Nf3 d6 3. b3 Nc6 4. d4 exd4 5. Nxd4 Nxd4 6. Qxd4 Qf6 
7. Qxf6 Nxf6 8.
Bd3 Be7 9. Bg5 h6 10. Be3 O-O 11. Nd2 d5 12. e5 Ng4 13. h3 Nxe3 14. fxe3 Bb4 15.
O-O-O Ba3+ 16. Kb1 f6 17. Nf3 fxe5 18. Nxe5 Re8 19. Ng6 Re6 20. Rhf1 Bd7 21. Bf5
Rf6 22. Bd3 Rxf1 23. Rxf1 a6 24. e4 dxe4 25. Bxe4 Bb5 26. Bd3 Bxd3 27. cxd3 Rd8
28. Kc2 Rd5 29. Kc3 Rg5 30. Nf4 Rf5 31. b4 a5 32. bxa5 Bd6 33. g3 g5 34. Rb1
gxf4 35. gxf4 Rxa5 36. Rxb7 Rxa2 37. Rb5 Bxf4 38. Rf5 Bd6 39. Rh5 Kg7 40. Rh4
Rg2 41. Kd4 Kg6 42. Ke4 Kg5 0-1

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 🙂

Writing your third program with Budge-TP

In a previous blog post, we showed an implementation of a subset formal system of Peano’s axioms that could represent numbers and the addition operator. In a blog post before that, we showed and implemented a formal system that could represent numbers and the addition operator at a more basic level.

This blog post will show yet another way to represent numbers and arithmetic operations such as addition, subtraction, multiplication, and division. Finally, we’ll extend this system to also support complex arithmetic operations (combining the previous basic operations).

Continue reading “Writing your third program with Budge-TP” →