Oskar Dudycz

Pragmatic about programming

Power of ignorance, or how to write simple code

2022-05-25 oskar dudyczCoding Life

cover

I was asked to compile various statistics from our Event Store GitHub community some time ago. We wanted to analyze our public repositories in terms of, for example:

  • summary data: number of stars, pull request, forks, etc.
  • but also data over time, i.e. how did they increase over time,
  • additionally, data such as issues, number of discussions, comments, etc.

The Event Store has a lot of repositories (we’re busy bees), so trying to copy and paste data from GitHub UI into Excel would be pointless. Well, we are programmers for something; we automate. GitHub provides its API (https://docs.github.com/en/rest) to get the whole spectrum of information. I decided to go on this path. Still, having API is one thing, and scraping data efficiently, is another.

How to do it then? The top results will suggest Python if you google “data scraping”. Probably you don’t even need to google that. Python and data scraping come hand in hand.

And here comes my ignorance, which turned out to be my advantage. I don’t know much about Python. Before this task, I only wrote a small, simple thing to integrate data from two APIs overnight. It was a bit similar, and I had pleasant memories, so I said: “Why not? Let’s go deeper”. It turned out that Python is a straightforward and intuitive language. Even such an ignorant like me was able to write a program that scraped a significant amount of data from GitHub and analyzed it. Python is a dynamic programming language. Because of that, it allows rapid prototyping and reduces unnecessary code structures. Plus, it is very expressive and straightforward (as I already noted).

Additionally, it has ingeniously simple support for data processing and analysis. Pandas allows you to use code like Excel. Really!

C# and Java developers sometimes feel superior and laugh at some languages ​​or technologies. Yet, they ignore the usage context. Each programming language is a tool. If the tool is used for the wrong job, it may have a harmful effect. But if we’re using it in the proper context benefiting from the strong sides, it may turn out that the laughter is actually ignorance - the damaging ignorance.

The positive ignorance, in my case, resulted in being humble. I didn’t know Python best practices too much, so I didn’t try to overengineer it. I focused on getting the job done and using the simple solutions and tools that could help me to get it right. No layers there, just simple methods with no crazy structures or optimization. Even though I have 15 years of experience in C#, I’m sure that I wouldn’t be able to get this job done in a similar time as I was able to do as a Python noob.

I have recently been discussing a bit with my sister, who is taking her first steps in IT. It turns out that explaining to a beginner why a given code is crap and the other is great is not easy. I could just say “it depends”, but such an answer will not explain anything to a beginner. For instance, when I was thinking about describing why CQRS is better than Spaghetti Code or why it is more straightforward, I realized how many things we’re taking for granted. Having learned something, we often forget our journey and how we come to our current conclusions.

Okay, so what’s the moral of that? Let’s write simple code. How to do this? Using the right tools for the job and not trying to use all of the most sublime structures. Focusing on getting our code to do its job the best it can. Nothing more, nothing less.

There is such a thing as “elevator pitch” in startup nomenclature. If you accidentally find your dream investor in an elevator, you should be able to present your idea to him during the ride. If you cannot explain it and advertise it within this time frame, maybe your idea is not good enough or does not have noticeable direct benefits.

I propose to verify that our code and architecture will pass the “junior developer pitch”. So will you be able to describe in short, simple words how it works and why it was designed like that?

If you want to see the code I created, I open-sourced it. You can find it here: https://github.com/oskardudycz/community-stats. I take Pull Requests!

Cheers!

Oskar

p.s.2. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, putting pressure on your local government or companies. You can also support Ukraine by donating e.g. to Red Cross, Ukraine humanitarian organisation or donate Ambulances for Ukraine.

👋 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

Why I'm leaving Event Store and getting ready for the next episode

What onion has to do with Clean Code?