I’m an experienced product engineer with a strong background in Python, Django and relational databases.
I focus on quality, performance, and delivering complex projects on time and in budget. I’m passionate about building projects, improving engineering processes, and sharing knowledge.
If you need a reliable and skilled engineer, let’s connect!
If you need an official CV, you can download it here!
Intro The internet is full of articles on CEOs declaring their companies “AI-first”, in the name of increasing efficiency. After all, why have 50 engineers if you can have 5 managing a swarm of AI agents? I am a heavy user of GenAI assistive tools and they truly do help me achieve results faster. But another thing that helps you achieve results faster is not having to fight an uphill battle against whichever text editor you’re using. If you have to lift your hands from the keyboard, you’re wasting time. ...
If your project is not fully containerized, but you still want to use PostgreSQL in your GitHub Actions workflow, you can use the services feature of GitHub Actions to easily spin up a PostgreSQL container. However, the services functionality restricts what you can configure declaratively in the workflow file – namely you cannot configure the PostgreSQL server parameters that you would usually set up in the postgresql.conf file. Fortunately, most of these can be configured through ALTER SYSTEM commands. ...
Having no documentation is often less harmful than having inaccurate documentation. Like code, documentation degrades over time. What was once accurate may now be obsolete. And practices we once ignored might now be part of our daily workflow. Unless maintaining documentation is an intentional process, it will rot, maybe beyond saving. In this article I’ll outline a few guidelines that worked well for me in the past for keeping the developer documentation usable. They’re certainly not universal, but they are a good starting point for a small team of experienced developers. We’ll skip the philosophical debates and focus on real-world practices that work for small, fast-moving engineering teams - the aim is to get the most value with the least effort. Documentation doesn’t pay the bills. ...
What’s CSRF? Cross site request forgery is a type of attack where a malicious website tricks a user into performing actions on another site where they’re authenticated. This is usually done by embedding a form in the malicious site, and submitting it to the target site. An example of this would be a card game website where, when you hit the “Play” button, it sends a POST request to another site with the payload to change your login email address to the attacker’s. Since you’re logged in to the target site, the request goes through and you lose access to your account. ...
Every engineer that loves Django and has a blog has at least one of these posts. Django’s ORM is excellent, but given enough time it’s easy for approaches that weren’t mistakes to grow into mistakes This is a great thing, because it usually means your company didn’t go bankrupt, you’re still here and can fix things, and the company is doing well because the scale increased (hopefully your compensation as well). ...
@property decorator is an excellent way to reduce the readability of Python code. It obfuscates a perfectly good function call and tricks readers into thinking they’re performing a regular attribute access or assignment. Unless there’s a really good and explicit reason to do this, don’t. List of Good and Explicit Reasons: Refactoring That’s pretty much it. If you need to turn something that (rightfully so) started out as a simple attribute, but with time accrued some more complex logic, @property is a good way to gracefully transition from attributes to function calls. ...
Instead of def do_something(a, b, c): return res_fn( fn(a, b), fn(b), c ) I do: def do_something(a, b, c): inter_1 = fn(a, b) inter_2 = fn(b) result = res_fn(inter_1, inter_2, c) return result The first version is much shorter, and when formatted properly, equally readable. But the reason I prefer the second approach is because all intermediate steps are saved to local variables. Exception tracking tools like Sentry, and even Django’s error page that pops up when DEBUG=True is set, capture the local context. On top of that, if you ever have to step through the function with a debugger, you can see the exact return value before stepping out from the function. This is the reason why I even save the final result in a local variable, just before returning it. ...