Oskar Dudycz

Pragmatic about programming

10 notes on the 10th blogging anniversary

2021-09-22 oskar dudyczCoding Life

Yesterday, precisely ten years passed since I released my first blog post. It’s still available in the original place (in Polish) at BlogSpot. If you know Polish and think about blogging, but you’re afraid to start, check it. It should convince you that you’ll be better than me.

I’m not great at dates. I would forget about it if my wife didn’t remind me of this fabulous cake.

10th

It’s great to have such an anniversary, but it’s even better to have a good wife.

Even though it’s been ten years, I still don’t feel like an expert in blogging, but let me share ten notes/suggestions for my ten years of blogging:

  1. Write for yourself but consider the audience. Do not try to search for topics you’re not familiar with. I initially started my blog to play with new stuff and write my findings of the daily work. I’m sometimes saying that I’m writing not to forget what I learned. It’s nice to go to your blog and find an answer from younger you. People will see when you try to explain something that you don’t know. It’s okay not to be an expert and explain your struggles, but that’s much different from showing it as a best practice. Still, it’s worth considering an audience and finding a middle ground. Nothing’s more motivating than getting feedback. People are not great at giving feedback, so if you go crazy writing about a niche inside the niche, then the chance for the input is even lower.
  2. Done is better than perfect. The hard truth about your first articles is that no one will read them. Maybe a wife, uncle or proud grandma. That might be not motivating, but it’s also a chance to make mistakes. What you write is not put in stone. You can update the post later. Of course, you should not be shitposting and take care of the quality, especially stuff like grammar. Typos and obvious mistakes that can be fixed by spell-check tool are incredibly annoying. Other than that, publish when it’s good enough. You can expand it later, rewrite or, in the worst case, throw it away. To begin, you have to begin.
  3. Build a habit. Define a schedule, e.g. once per week or per month. It’s safer to start rarely and then write more often when you find the rhythm. You won’t risk putting too much pressure on yourself. If you’re stressed and forcing yourself, then the outcome will also be hard for the readers. Still, building a cadence helps to motivate yourself. You can also consider putting a time limit for writing the blog post, e.g. two hours every other Monday. At least, that helps me to manage my perfectionism. I know that whatever will happen, I’m sitting in the evening and have to send it before I go to bed. It’s also essential for the readers (once you get them) because they know when to expect a new post.
  4. Run a newsletter. That helps in building the community around you. Also, if you’re too shy or for some reason you don’t want to share your thoughts, then writing an e-mail in the blogging form might be a good alternative for you. I managed to build a cadence when I started running my Polish newsletter. The E-mail also gives closer relation with readers, and for some can be easier to send you the feedback. It’s been over two years since I sent a blog-a-like e-mail with my thoughts. Some of them get later published as my regular blog. There are mailing platforms like Mailerlite, MailChimp or ConverKit that offer free plans.
  5. Store somewhere bits of advice that you’re giving. For sure, you’re having a lot of internal project discussions, answering questions for your colleagues. It is an excellent source for blog topics. If someone asked you for help and you helped them, others may also benefit from that. I’m not great at making notes, but once I started to put them into the same place (private git repo with markdown) and group them by topics, it helped me build the foundations for the articles.
  6. Do not expect much. I don’t see clear signs of impact on my life made by blogging. I neither got a sponsoring job offer nor earned a penny from it. However, the implicit impact is indisputable. Learning in public helps a lot (also read my advice about doing Open Source). I learned better to express my thoughts, to put the correct arguments. It helps in work and life in general. I also synthesised what I learned and had some “a-ha moments” during writing. I was finding surprising insights I didn’t consider before investigating the topic. Of course, I know a few people besides my family who read my blog, but I’m far from being an Instagram celebrity. And that’s cool.
  7. Use the right tooling. I switched the tooling a few times. I started with BlogSpot, then switched to WordPress, now I’m running it on GatsbyJS. Tooling evolved, but I started with the simplest possible option and switched when it was blocking me for some reason. Do not build your own blog engine or try to use all sophisticated tooling. Focus on blogging and selecting tooling that will enable efficiency instead of distraction during your writing. If you want to blog in English, use Grammarly. If you’re writing in your native language, find a similar tool that will help to polish your writing (e.g. LanguageTool). Speaking about Polish, I recommend Ortograf.pl, Jasnopis.pl.
  8. Read twice before posting. Please do, at least twice. You’ll be surprised how many apparent mistakes you made. Don’t be lazy leaving that to your readers.
  9. Keep your language simple. Write short sentences. Hemingway did that and was fine. You’ll also be okay with that. I’m Oskar, but not Wilde, and you’re also not. Don’t try to be sophisticated just for the sake of being such. Shorter sentences are easier to read and better to keep the pace. If you want to get more theory, I recommend you two books:
  1. Be visible and advocate for your work. It’s not like the good work will be visible by itself. You have to promote it. For the majority (including me), promoting may sound like something terrible. However, if we believe that what we wrote is good, we should help people find it. Write it on Twitter, Facebook, Linked In, or other platforms you prefer. Of course, do not do Rickrolling, do not spam communities, or immediately attack people with your link. Explain first, then you can link your article as an extension. Before posting a link on a user group, make sure that its moderators are okay with that. Also, be a community member, don’t treat it as an advertisement platform. If you help others and, from time to time, post a link, then people will appreciate it. For the inversed proportions? Yes, they won’t.

I hope that this helps you a bit. Take those as thoughts that worked for me. Your experience might be different.

The final piece of advice is: just have fun!

Cheers!

Oskar

👋 If you found this article helpful and want to get notification about the next one, subscribe to Architecture Weekly.

✉️ Join over 11500 subscribers, get the best resources to boost your skills, and stay updated with Software Architecture trends!

Loading...
Event-Driven by Oskar Dudycz

cover

Through my window, I see the result of good plans but poor execution. Opposite my flat, there is a partially completed construction place. Buildings were supposed to be eye-catching Mediterranean style apartments. Delivery date? Two years ago. Actual? More and more unknown.

Some time ago, I heard that using Event Sourcing makes creating Event-Driven Architecture easier. The arguments were correct, that if we’re already publishing events to trigger business workflows, then at some point, we may want to also store events to not lose information. Agreed. However, I also heard that keeping the state as events will simplify things. We’ll have a source of truth with a record of the system behaviour. This will allow, e.g. to confront the results of the operations with the recorded state. I’d agree with that, with one distinction. It’s easier as long as you already know Event Sourcing.

Many people in the DDD community claim that the essential is to properly break down the system into autonomous parts called bounded contexts. Once we have it, the rest is secondary and will sort itself out. For sure.

Many seasoned programmers speak similarly about new technologies. They claim that they can translate past experience into new technologies. That’s true that by analogy, they can catch the big picture quicker. But isn’t it a bold assumption to say that Win.Forms specialist will learn Angular quickly?

The end result may differ a lot from the initial ideas. I saw the plan of those buildings next to me. Now I can see the effects of the execution. Or actually, the lack.

I believe that we should carefully acknowledge not only the point of view of our authorities but also their seating point. If we want to find out how to form a wall, do we ask an architect or a foreman? An architect may know the theory, but the practice is what we’re looking for. On the other hand, if you want to know where to put the wall, you prefer the architect to do measurements. At least if you don’t want to have the roof falling to your head.

After I had torn a ligament in my knee, I went to two qualified orthopedists. One said I should have surgery and do a reconstruction. The second stated that there is no need for that; rehabilitation should be enough. Guess which one had a specialization in surgery and which in rehabilitation?

People usually give us advice from the point where they’re currently standing. They are entitled to a biased view. An architect who rarely does programming will tend to downplay the value of implementation and tactical patterns. Midlevel developers will focus on technicalities instead of the global system impact. The team manager or consultant will emphasize the importance of soft skills (or esoteric techniques known only to them).

The truth is that we need all of them. The excellent plan will fall on the bad execution. The best execution for the wrong case will be just a waste of time. We should carefully evaluate the advice considering what we need and what an expert can give us.

Therefore, when we’re reading an article, watching a talk, let’s also pay attention to the place where the person is standing. The perspective from there may be much different from where we are right now. That can be good, as it may push us in the right direction. But it may also be misleading, as we accidentally take biases of this person without understanding the tradeoffs. Personally, I prefer to follow not only people from pedestal but also those that are closer to my position. A bit further in the journey, but not too far. That helps me to calibrate my view as those people are more relative to my daily struggles.

Polish historical leader Józef Piłsudzki reportedly used to say: “Right is like an ass, everyone has its own”.

Cheers!

Oskar

How to build event-driven projections with Entity Framework

Anti-patterns in event modelling - State Obsession