flavious

Yes, that would be amazing, full classes of approaches to problem solving would be unlocked at once and we wouldn't have to invent new languages, DSLs, transpilers, etc, but just leverage zig.

Contracts are actually quite necessary for modularity. In OOP we have data types (interfaces, classes).

As long as other paradigms provide contracts/abstractions, modularity can be achieved there also.

Faked modularity doesn't count. Leaky abstractions neither.

I'm not your goto java guy, but the module system of java and how modules can provide implementations for interfaces is really great.

Over-abstraction also has a non-negligeable cost.

Fred should learn how to squeeze in his refactorings into other, related tickets. And to learn how to argue about why an user story is more points worth, without explicitly saying the R word.

And how does the team feel about it?

Sounds like the effects of temporal coupling, or "settism and gettism", or other principles, which are violated. People are blinded nowaways too much by SOLID, and forget about the remaining 20 principles.

My rule scales with the scope of the dependency:

"If you think that creating a wrapper around the library is too expensive, then the dependency is not worth having".

Not questioning your decision at all, but can you explain the whole thought process which led you to the conclusion that it is a better fit?

Linux user for 15+ years, Slack, now Arch in the past 10 years.

Normally, bright developers acquire a new language* within a few weeks, if they already know the paradigm from another language. Hack is OOP, and so are many others, so I would expect a bright developer to learn hack in 2-3 weeks, not months.

Heck, I just read the docs of hack for 2 hours, and I already got a good sense of what the language can do. I worked with PHP internals, and a bunch of other languages in my career.

* as language we define the language, its syntax and semantics, not any other library or the ecosystem. And yes, the standard library is still just a library. Knowing a list of functions and parameters does not mean knowing a language.

Rule 20: When somebody says Agile, push for Kanban, not Scrum

From my experience, scrum is better. The idea is that you can measure progress and you can learn from mistakes with scrum.

Kanban doesn't help in that regard.

Also, a good scrum master will tell you some things:

- a successful sprint is one in which not all stories were finished, because the goal was ambitious

- do not sweat over spill-overs; they happen all the time, it's not the end of the world as long as you work 8h/day really focused and give your best

I know that in the US you got modern slavery with insame working and commuting hours, but life is decent in places like Europe.

Very good article, intuitively I'd say some overlap with "the pragmatic programmer".

I've written many thousand lines of code in bash (along with way more in 15 years of programming in other languages) and I must tell you:

Never again!

Use xonch at least.

Define "We".

Who knows, maybe he has valuable things to share. It's like that with any book. It also depends on the readership.

borgbackup.

As a programmer, I leave a small portion of code uncommitted at the end of the day.

Next day, I just look at the git diff, and I'm mentally back right where I left.

Code monkey thinks he can help beginner become a researcher? Not so fast, tiger.

When I was a junior, I could write my queries in SQL in 30 minutes for the report which was asked from me, but I needed two more days to figure out how to do it with the ORM.

For juniors, it's best to have a less abstractions.