Last year I had a video call with Tomas Votruba, creator of Rector, who kindly took the time to explain a lot of things about this project. We finished the call and I couldn't wait to tell my partner how nice it was. I said to her: we should have recorded it, I'm sure it would be useful for other people too. She replied: this is so typical; millennials having a nice conversation and then they want to let the world know about it.

This definitely triggered something. Looking at it like this, she's right; it's somewhat of a weird impulse. But then, is it bad? I'm in the business of sharing. Am I doing this because I think it's somehow important that people know what I think or experience? Honestly, the answer is "no". It's just that I see value in code, conversations, and written words and I don't want that value to be only available for me. So I try to put it in a shareable form and publish it on GitHub, here, or as a talk or workshop. I've spent countless hours doing this, and I stand behind this.

Recently I realized though that there are different types of sharing, and that I made some mistakes in sharing certain things as well. Things I now feel really uneasy about.

A short history: I started blogging here in 2011, writing about the then still fresh symfony 2. Back then, there wasn't a lot of documentation, and I blogged to fill some gaps. Later I published a number of documentation chapters as well. I gained some followers on Twitter, and loyal readers too. I feel silly to admit it, but I had put so much effort in this; I was very disappointed not to win the Best Blogger award back at SymfonyCon Warsaw in 2013.

In that same year I published my first book: "A Year with Symfony". It was a very honest book. It was based on my experience with Symfony in the past year (fun fact: its original title was "More than a month with Symfony"). The last chapter in that book is called "Being a Symfony developer" where I try to convince the reader to write code that is reusable, beyond the current fashion:

"[...] developing software for reusability has proven to be quite a difficult task in itself. Luckily, there are many principles you can adhere to."

Therefore, what came next was "Principles of Package Design", heavily based on Robert Martin's work on the SOLID principles and the lesser known package design principles. An important step in my own development as a programmer. I was using these principles in my then-current project, to separate utility packages from domain-oriented ones. Packagist was quite young, and people were publishing packages with a real dependency mess (they still do), so I thought it would be good to share those design principles with others. I'm still happy about it, although I'm not a "believer" in those principles anymore. But that's maybe something for another post.

Something went wrong when I started working as a CTO at Ibuildings. With less and less time spent on programming and working on actual projects, I started organizing workshops as a way to keep learning. Those were great, but I made the mistake of not rooting them in experience. I kept doing this after I left the company, and I even wrote a new book that had the same underlying issue: "Microservices for everyone". It was a research book, not based on experience in the field. Still, I was very honest about this in the foreword:

"It's crucial to note though that so far I have not had the opportunity to work on a large microservice system."

I still think it's a good book, but I didn't realize that its implicit message is: this guy knows everything about microservices and now he wants to tell us how to do it too. I think that's really problematic. And it made me realize my own big mistake here.

"God, give me the confidence of a mediocre white dude" -- Sarah Hagi

I started out so humble, ready to put "more than a month" in a book title. I wonder where I got the superfluous amounts of confidence from. Maybe because:

• I get invited to speak at conferences (wow, I must be doing something right!)
• I have thousands of followers on Twitter (wow, I must be doing something right!)
• I published several books and people are actually buying them (wow, I must be doing something right!)

In my humble opinion, none of these things are ever to be considered a sign that "you're doing something right". Well, only if your goal is to be an influencer. It doesn't have a lot to do with experience, or a dedication to learning and teaching. It's mostly marketing. Well then how do you know you're doing something right?

For me, the question is: how do I judge advice provided by others? Where do I find good advice?

• On YouTube? No.
• In a rant someone wrote on Twitter? No.
• In memes, like that funny "I don't know what I'm doing" picture? No.
• In blog posts? Sometimes.
• In books: yeah!

Of course. It takes a lot of time to write a book so the author has to want to share something really badly. It takes a lot of effort to structure it in such a way that it will make sense and that the reader will get the message. So it'll probably give you more value than a blog post. The problem is, based on all my encounters with real programmers: few of them actually read books.

Assuming you read books, which ones do you read? Which authors do you trust? How much are you willing to pay them?

Personally, I'll pick:

• A book that has been around and has turned out to be useful for more than a couple of years since it appeared.
• An author who has lots of experience, and is knees deep in the problems they're writing about.
• An author who doesn't only know one particular framework or programming language. I want to be sure that their advice is also useful for me, if I use different tools. I want the advice to be useful in a couple of years, when those tools are outdated.

I'd happily pay 50 euros for such a book.

"Microservices for everyone" is my only book that doesn't meet those requirements. It was written while learning, or soon after learning, and without testing the conclusions in a real-world project. Tech books require more experience, and the ideas need to mature by it. I'm not alone; there are many books, blog posts, videos, tweets, etc. that sell well, but are more based on hype or fashion rather than experience and some kind of proof that the ideas work well in the long run. Personally I'd like to apologize for my own mistake, and I promise I'll never do it again.