shimst3r's comments

Looking at the GitHub repo, it’s written in Scala.

If you do TDD, you write your tests first. If you don’t follow TDD, you don’t have to. The author insists on this because they assume a TDD approach.

Instead of Test-Driven Design, it should’ve been called Design-By-Testing.

As someone who has worked as a data engineer on an organically grown monolith, the last thing you want to do is ceding control over your schema due to the lack of (sensible) abstraction. Everyone will change it, nobody cares about standardization. It’s utter chaos and a data engineering nightmare.

This is the same, plus the lack of proper authN/ authZ. Good luck passing your next audit.

Unpopular opinion: With quickly growing organizations and therefore more inexperienced people managers, promoting someone to staff engineer is an easy way out of responsibility.

How often have I heard "you’re at a point in your career now where a people manager will only hinder you" to justify not being capable of supporting me.

While I see the benefit of this approach, I’m often baffled why people want to go either 100 % POSIX builtins or 100 % scripting language.

The biggest benefit of the shell is its clearly defined input and output (and error) interfaces. Most programming languages can read from and write to stdin, stdout, and stderr.

Why not use it and stick to KISS, replacing one cumbersome POSIX utility at a time, suites for the task? Then you don’t need to chain methods using less idiomatic code. But then you wouldn’t need these kind of libraries either.

We used mob programming as a framework for conducting coding dojos, it was a very good experience.

We based the sessions roughly on the book https://pragprog.com/titles/mpmob/code-with-the-wisdom-of-th... - having some kind of system is highly recommended.

While I haven't got the chance to do mob programming ever since, I'm looking forward to change this in the future. It's such a great tool for mixed-experience teams (especially good for onboarding new hires or junior devs) or cross discipline teams (having a product manager in the mob really helps removing boundaries).

There’s been a recent podcast episode on this on the Go Time podcast: https://changelog.com/gotime/209

All the best to your friend, may they have the power and support to go through this change.

It always existed.

-- sent from my iMac in Bielefeld

I haven’t worked with C in quite a while, but this repository is beautiful and wants me to look into the language again. Very readable to me and also well formatted.

Do you know cookie cutter? https://cookiecutter.readthedocs.io/en/1.7.0/ There are a lot of task specific templates that can be adjusted and open sourced if needed.

I'm still loving my 2013 MacBook Air 13" with an i7 and 8 GB RAM.

I mostly do Python development with Vim (web, DevOps, ML/NLP) and Dart/Flutter stuff with VSCode. For bigger workloads I ssh into my iMac.

I’d suggest based on PyPI download numbers, see https://hugovk.github.io/top-pypi-packages/

The official Flutter course was very good, hosted by London App Brewery.

Definitely worth it if you’re looking into cross-platform frontend development.

> Parsoid/PHP also brings us one step closer to integrating Parsoid and other MediaWiki wikitext-handling code into a single system, which will be easier to maintain and extend.

I assume that Wikimedia works on a rather tight budget. Choosing (and unifying on) tech stacks with a larger supply in devs seems to be an economically reasonable choice.