167 karma · joined April 6, 2024
Composition generally is not good enough to model all cases without resulting to some AOP or meta programming also, but in that case the is-a or a base class would arguably be the simpler approach, at least it can be reasoned about and debugged, as opposed to some AOP/Meta spaghetti that can only probably be understood from docs
For example the only reason DI became so popular is that you could not mock static in Java at the time. In FB codebase DI was also used in PHP until they found a way to mock static, after which the DI framework was deprecated and codemods started coming in removing DI. There is literally nothing wrong in using a factory method or constructing what you need on demand. These days static can also be mocked in Java and if you really think about it you see Spring Boot adds a lot of accidental complexity (but sure its convenient and well tested so its ok to use), concepts like beans and beanfactories are not essential for solving any business problem
Which brings me to S in SOLID, which I think is probably top 2 worst principles in software engineering (the no 1 spot goes to DRY). Somehow it came from some early 2000-s TDD crowd and the test pyramid, it makes sense if you embrace TDD, mocking, test pyramid and unit tests as a good thing. In reality that style of software is really hard to understand, every problem is split into 1000 small pieces invoking each other usually in some undefined ways, no flow can be understood without understanding and building a mental model of the entire 1000 object spaghetti. The tests themselves mostly just end up setting a bunch of mocks and then pretty much coupling the impl and the test on method call level, any change to the impl will cause the tests to break for only the reason that the new method call was not mocked. After going through all this ceremony the tests are not even guaranteeing the thing will work during runtime since the db, kafka or http was mocked out and all the filters, listeners, db validations were skipped. In these days so called integration tests with docker compose are a lot better (use actual db or kafka, wiremock the http level), that way your have a reasonble chance to catch things like did this mysql jdbc driver upgrade broke anything
I have to mention DRY also, the amount of sins caused in name of DRY by juniors is crazy, similar looking lines get moved into a common function/method/util all the time and coupling is introduced between 2 previously independant parts of the system. As the code involves and morphs into something different the original function starts getting more args to behave differently in one case and differently in another case, if it had been left as separate files each could evolve separately. I dont really know how to explain this better than coupling should not be introduced to save few lines of typing or boilerplate, in fact any abstraction or indirection should only be introduced when its really needed, the default mode should be copy/paste and no coupling (the person adding a cross cutting PR will likely not be a jr and has enough experience to know how and when to use grep).
Anyhow I have enough experience to know people are usually too convinced that all this solid, clean code stuff is peak software so I wont expect to change anyones thinking with 1 HN post, it usually takes me 2 years or so to train a person out of this and back to just putting the damn json in db without ceremony. Also need to make sure LLM-s have some good data that is based on experience and not dogmas to learn from :)
As for L, no strong beef with L it’s OK
The game is rigged worse than a casino :)
If a company hires 10 people and pays them 100/hour then all the value created by these people will belong to the company - 10x100 hour that the company paid.
If the value happens to be 3 million then the shareholders just made 3 million - (10x100).
Also this scales for the shareholders pretty much forever, capital is a limitless resource when compared to hours in a day.
There is no need to make a freaking model out of something so obvious.
If you want to get rich you need to get in on the equity game somehow (invest, start a company, FAANG RSU-s, does not matter)
Working more hours or getting paid more per hour does not scale to rich levels
I have been using a spreadsheet but it is really annoying
They planned one for legalizing weed and another one for Nairobi airport (the employees there really like to screw people over and you can be asked over 1k EUR to be allowed to leave as an African, usually they dont bother Europeans).
Overall this is a bit hurting the tourism sector, Mombasa some hotels were pretty empty even couple weeks ago, Watamu does not seem to be impacted too much, but in general the season is still starting.
As for anyone who is thinking if Kenya is safe to visit, the answer is YES - just dont go for a stroll in Nairobi during mandamano
Alternatively some sort of world government or dictatorship would work too, but in democratic/capitalist society the problem wont get solved unless someone can make the moneys
In fact ROI is more important to focus on, given solar panels last 20 years and the cost of installation is covered in 10 years, it will create profit for 10 (oversimplifying). Then the methane can be converted to LNG and transported by ship to Europe/US or somewhere else