daniel a rios

Senior Django/Python Engineer

That's me.

About Me

I've been working professionally as a Web Developer since 2016, and am currently working at thermondo in Berlin. I've been programming in Python since 2012, and with Django since 2014.

My pre-programmer career started in the Book Production Department at Simon and Schuster in New York, winding through Catalogue Production at Christie's and Business Intelligence for Veer and Corbis in Berlin. At every job, I've been interested in Data and Programs, and have served as the de facto IT person in my department.

My main interests lie in the use of hypertext to retrieve Data and information.

My philosophy on writing software

I seem to have developed a coding philosophy. These four points are the minimum that a company needs in order to allow their developers to properly do their job of writing software: Version Control, Testing, Deploy Infrastructure, Pair Programming. If you don’t do/have these, then be assured that I will spend the first months at your company by building these things before I do anything else.

Git credit where credit is due.

My team and I were working on a long running branch to which we were all merging. The PR for this branch had one team member as the PR author, and the plan, on release day, was that I would be the one to do a squash commit. The problem with that is that my name would be listed on the Git blame. In this case, I would take the responsibility and the credit for my team’s work. We got around this by merging the branch locally with all the commits, and pushing it to the main branch when it was time to release. Therefore everyone got credit for their work, and I wouldn’t be the one with a confused look when someone checked git blame and asked me about something I never wrote.

Tests are the better half of the code.

Don’t tell me that tests are a waste of time. Tests are a part of the code. They are the better half of the code- since they are also code- in that they prove that your code actually works. Sometimes I hate writing tests. In those cases, I find them inconvenient, and repetitive. But I never regret seeing a test suite turn green after making errors and trying to discover how to test the code. I should do more Test Driven Development, since that would get the tests out of the way sooner, but I get impatient for the solution to the task at hand, so will usually start with the actual code. I worked on a project that had no tests, and not CI to run them. I wrote tests for all my code, but the more I wrote, the more older tests would fail, because they were not running with the context of the new code. So it’s not enough to have tests, you have to make sure that they are running all of them enough to know when they start to fail.

Do it once and forget about it (until you need to maintain it).

I am a big fan of CI scripts. I’ve worked with Gitlab CI, Circle CI, and Github Actions, and each of them never failed to tickle that part of my brain that likes automated processes that make things easier. I’ve worked on transforming CI scripts into Github Actions at two companies, and every time have been fascinated by how CI makes life easier for developers. At one point, I was sub-contracted out to work on a project that my company had once maintained, and they had erased the CI scripts, so each deploy was a manual nightmare that took much longer than the half-minute of developer attention needed to check that a CI script is finished. I’ve encountered this a lot, but not enough that the process necessarily needed to be changed. When adding permissions in GCP, I would have to change Terraform files. This was only a problem because I would do this so infrequently that I had forgotten the syntax of the Terraform language, and I would have to keep referring to the documentation for something I did once six months prior.

A pair of shoes is better than a single one. Pair constantly and consistently.

I’ve worked in companies that encourage pair programming. Everyone thinks it’s a good idea. But few people actually do it. The secret here is not to ask someone spontaneously if they can pair. They are working on things that they don’t want to let go just yet, so it might not be a good time. Rather, set a time where you pair, either on your issue or on their issue, but make it a habit and don't let anyone bother you during this time.

What I've worked on:

Work:

Open Source:

Community

Talks

Mentoring:

What I do

My Tech Stack Includes:

Django, Python, NeoVim, Git, GCP, Heroku, Kubernetes, Docker, Redis, Linux, Test Driven Development, Domain-Driven Development, Pytest, Django Rest Framework, Jira, Jupyter Notebook, Postgres, JavaScript, TypeScript, APIs, JSON, HTML, CSS, SQL

Favorite Python packages:

django, pytest, pytest-picked, django-extensions, pdbpp, pdir2

Favorite Text Editor:

NeoVim as adapted by LunarVim AstroNvim

Favorite Shell:

oh-my-zsh

Favorite Books:

Questions & Answers

Where are you currently working?

At the beginning of March 2023, I started working as a Senior Backend Engineer at thermondo.

Is it true that you studied English Literature at University?

Yes! Part of my life philosophy is to always be learning, and to use this knowledge for the greater good. In High School, I was on the Math and Science track, but by the end, felt that I had reached a practical limit. At Brown University, I decided to expand the boundaries of my knowledge at the time. By focusing on Culture and Literature, I was able to learn different ways to think and analyze. The English Department at Brown was heavily influenced by the theories of the Modern Culture and Media Department, so I also learned to delve deeply into a text and consider past and current cultural contexts.

Do you feel that your degree influenced your understanding of programming?

My study of programming paralleled many of the concepts of semiotics that I learned as a basis for my degree. Properties such as the sign and object in language, informed my understanding of variable assignment as well as structure and meaning in code.

Why did you switch to programming?

Well, because I discovered I have an intuitive understanding of program design, and am not afraid to explore the way hardware and software are developed.

In my career, I found I was relying more and more on the command line to complete tasks, but did not fully understand what I was doing. While trying to improve my skills, I stumbled upon Python. I simultaneously discovered that computer programs did not have to look ugly, covered with semicolons and braces, and that I loved the syntax and elegance of high-level languages.

So you're a self-taught programmer, then?

Yes. And no. I have learned so much from my local community as well as the Python and Django communities at large that I hesitate to call myself a self-taught programmer. I much prefer the term Community-Taught Programmer.

Are you active in the Python Community?

Absolutely. You'll regularly find me attending and speaking at meetups in Berlin. I attend PyBerlin and PyLadies and am planning on checking out the reboot of the Berlin Django User Group. Berlin Django User Group and the OpenTechSchool's Python and Ruby Co-Learning Meetups. I also attend various conferences and try to give back to the community however I can.

Why Python specifically?

I've explored various programming languages, but always come back to Python. It feels so natural, the mandatory whitespace, the focus on readability, the lack of braces, as well as its closeness to natural English.

On occasion, the structure and meaning of Pythonic code resemble poetry.

In my talk at PyBerlin, Python as Language and Language as Code, I go into this in even more depth.

Any other languages?

Besides German and Spanish? As part of my senior duties at Thermondo, I suggested that everyone should be able to work on any part of the systems. Thus, I ended up working on ain internal order form in Typescript. JavaScript and TypeScript have come a long way.