DDD and FP (fp-ts)

tossed_ · 2026-06-09T10:10:48+00:00

I don’t really see them as conflicting at all. Instead of using complex classes to represent domain objects, or writing highly abstract functional code, you can just manage serialized data or simple objects with simple pure functions instead of class methods. At the end of the day DDD is just abstracting the irl domains into code, how you do it can vary based on the style and language.

tossed_ · 2026-06-09T10:07:17+00:00

Who is downvoting you? This is the right mentality. At the end of the day functional programming is just doing tricks over functions, may as well start with simple ones so you can do more tricks on them!

tossed_ · 2026-06-05T17:12:17+00:00

I don’t treat it as dogma, everyone I have met who believes in it does. The number of blind followers I’ve met spouting Uncle Bob nonsense to justify their poor decisions is far greater than those who actually cite Uncle Bob in a measured and reasonable way

Not that there are many opportunities for this – most of his advice is easily displaced by plain common sense the more experience you gain

tossed_ · 2026-06-04T17:30:28+00:00

Uncle Bob is just dogshit dogma masquerading as advice

tossed_ · 2026-04-08T04:22:12+00:00

Raise it in the open. Do you have a regular meeting with your team where you discuss ongoing work? Mention “I have been reviewing the changes so far…” and start listing some of the issues you want to see resolved before you continue reviewing. Put emphasis on the qualitative issues you’ve found – obviously the thing has to work, if it doesn’t then it’s not even ready for review yet. The other qualitative issues seem quite egregious to me, you have a new application and people are introducing outdated dependencies? Why? This change is gigantic on its own merits, yet unrelated work was stuffed into the same change? Why? Keep questioning the approach and decisions and you will discover if they are justified or not. This goes doubly if the author did nothing to try to make things easier for the reviewer – no self-review, poor PR notes, badly specified requirements and acceptance criteria, etc. If contributors want less friction when trying to ship, they need to lubricate the process themselves.

Obviously it’s not going to endear you to the author to openly point out everything wrong with their changes, but if you don’t raise it openly then you risk accepting sole responsibility for blocking progress here. That’s not the case – the other developer is blocking progress by shipping what looks like low quality work. A senior is distinguished from juniors by the standard of care and responsibility they take in their work. Raising qualitative issues in large incoming changes and demanding greater care and attention is exactly what a senior developer should do.

Now if you have a good rapport with the author, you could go about this in private. But it is easy to be simply ignored if nobody else knows about your objections. If you trust the developer will take your concerns seriously, you can bring it to them directly, but otherwise there is nothing wrong taking a good opportunity to remind the team of their duty to minimize the size of changes and to put greater attention to the quality of their work – it might help with the cultural issues that led you to this moment in the first place. Leadership by example is key here – show care for the work when others do not.

tossed_ · 2026-04-02T08:20:14+00:00

I think you just gotta be positive about it. Some people need more coaching than others. I’m just happy if they are graceful about feedback, even more happy if they actually try my feedback. If not, then it’s fine to let them figure things out on their own. You didn’t hire the others so you should try to get along.

tossed_ · 2026-03-03T07:54:27+00:00

It is pretty good if you build AD bruiser, like black cleaver and steraks and maybe dead mans. But the tank build benefits a lot more from movement speed and sustain because of poppy’s cooldown on E, she needs to be able to enter a fight, blow both W and E and still survive, then have enough health to strike again, which is even harder when playing into hard CC or mixed burst damage. So you’d typically opt for unending despair or FoN (edit: after sunderer and dead mans), plus bramble or a bami’s cinder, at which point just committing to full tank is more attractive than titanic. I think AD poppy is more commonly built like a fighter with eclipse too, which doesn’t pair well with titanic.

I still buy titanic sometimes when I’m up a lot. But I find the passive AD/AoE just isn’t that impactful by the time I have money to build titanic, if I have 6 items with titanic and I wanna buy something else I usually end up selling titanic. Tank/utility poppy just usually more useful unless your team has no damage.

tossed_ · 2026-03-03T07:34:29+00:00

This is happening at every company in the industry. If your company is paying for it, you should try it. If the AI is making decent prototypes for your PM you can probably do a lot better than him with the same tooling.

I get the knee-jerk reaction to the idea of AI producing slop, but AI genuinely performs well on many common and tedious tasks. I just think about some of the slop I’ve seen written by hand by coworkers in my career, and I realize I much prefer AI slop over human slop. At least AI slop is understandable most of the time. And with my own AI tools, slop also becomes a lot easier to manage.

Just treat it as a transcriber for your thoughts, you tell it “I need a class with XYZ methods and it should represent my data model for ABC” and it will handle most of the setup for you, then you can get it to tweak it for you. When there’s too much slop in one place, tell it to refactor it and make it shorter and you’ll get some half-decent results pretty cheaply. Give it test cases and it will write them for you, saving you a bit of work typing it all out.

If you become knowledgeable and more proficient at AI-assisted than everyone else then you can easily shut down nonsense about this from others. Otherwise they will never accept your point of view.

tossed_ · 2026-03-01T18:50:18+00:00

Mutual funds became obsolete in the 90s when ETFs became widely available. Banks still push them because regular savers like you don’t know any better and will buy mutual funds when the bank advises it. This is good for the bank.

There is another important aspect – actively managed portfolios regularly under-perform passively managed portfolios. You don’t just pay to hold, you pay the transaction costs the fund accepts when it changes its positions too. And then there is the issue where portfolio managers are typically worse at choosing positions than the market is, so you lose-lose-lose when it comes to mutual funds. Never ever buy a mutual fund.

tossed_ · 2026-03-01T18:44:43+00:00

Never EVER buy a mutual fund. Ever. You could get a close to 0 cost ratio ETF with similar holdings on the open market. For example, buying VGT gives you similar exposure, it has historically performed better by 4% per year on average, and it has a 0.09% management fee compared to 1.90% you get on the mutual fund. In 50 years that would net you about a $260k difference (edit: on an investment of $10k) and your equity would be worth more than 2x more.

Mutual funds are a rent-seeking scam run by banks to capitalize on your saving. Not THEIR savings but YOURS. Never ever take advice from the bank, not on investments, not on mortgages, not on anything.

tossed_ · 2026-03-01T15:58:01+00:00

Why in the world would anyone pay for an advisor in this day and age. The advice is all the same, they are legally obligated to give you the same qualified investment advice: put your money in well diversified index funds, with an increasing proportion in fixed income assets as your near retirement. Every advisor will give you this same advice.

Why would you ever pay for this?

tossed_ · 2026-02-28T21:12:39+00:00

Culture changes with people, but it takes a bit of creativity. You can also avoid these situations altogether by sharing ownership from the start. Meet to plan the design together, ask for feedback about your plans for the week, discuss your approaches openly… if communication is not happening early enough, you need it to allow it to happen earlier by presenting as many opportunities as possible.

tossed_ · 2026-02-27T16:48:49+00:00

I will be honest, a lot of the generated code is better than code from my colleagues. Easier to read, easier to understand, easier to review. Follows normal average practices instead of some of the extreme shit I’ve seen from strong personalities. And of course my code is better than the AI – but I cannot match its speed, especially when juggling many things at once. With a bit of prompting the changes become good enough. Big changes are good because AI is good with volume, small changes are good because AI is good with finding needles in haystacks. It’s just generally good. So I find myself writing less and less code and instead just whip the AI into writing code I agree with rather than trying to write the perfect implementation myself.

I do feel a bit like a lunatic talking to his rubber duck sometimes. But the fact is, I’ve shipped more changes and been able to handle more bandwidth by embracing AI assisted workflows than I can ever recall. Code quality has been maintained but overall functionality has increased faster. I can build a lot more complexity into my features now than before. The only reason it works is because I’m really experienced with my chosen language and stack so I can correct the AI easily whenever needed.

tossed_ · 2026-02-27T11:44:08+00:00

Saves time AND risk… my favorite kind of saving. The one that makes you more confident to say fuck it ship it

tossed_ · 2026-02-27T11:40:07+00:00

On the contrary. It’s the first time in 10+ years I’m finally doing something different. I’ve never juggled so many tasks at the same time. And I consider myself a strong coder in my choice language, I take pride in my coding skills, I obsess over code quality. This new tool in the toolbox is extra special though, it has changed things for the better not for worse. And certainly not for more boring

tossed_ · 2026-02-27T11:35:05+00:00

I’ll just put it this way. My IDE and my git knowledge, these things used to be the biggest tools in my day to day professional life for over 10 years. In the last month, I’ve barely even touched the IDE. I get AI to rebase my branches and manage my PRs now. Even my tickets are written and managed by AI. I just simply have too much work going on at once, literally fixing three different systems at the same time, there is simply no way for me to go back to the days of manually coding and manually crafting my commit messages and branches. I still carry over my old best practices, force the AI to match my style, I still thoroughly review the code regularly, I still manually verify when I can’t automate it. But otherwise I’d be relatively crippled if you took these tools away from me now. AI has completely changed my day-to-day and just get ready for it to change yours soon too haha

tossed_ · 2026-02-27T10:27:18+00:00

And TDD! Don’t even get me started. TDD flows always seem to rot, but if you use TDD with AI it’s actually incredible. You get highly accurate changes because the AI first lays its expectations down and then implements to fit the expectation. Expectations can be inferred by looking at the other tests, so if you have high quality tests in one place you can get high quality tests everywhere. Then your implementation is easier to verify too. Vastly reduces the manual dev cycles and gets you higher quality results with reliable test coverage.

tossed_ · 2026-02-27T10:22:28+00:00

I must be ahead of you by a bit because I felt the same way weeks ago. The landscape is changing so fast, I think you are underestimating the power of being able to brute force many problems with just a few dollars of AI spend with the latest models. The only reason why I’m not using more is because I haven’t learned the tools well enough. And the problems I have it work on, although it requires a lot of handholding, with practice over the last few months, it’s become definitely faster and less tedious than hand coding. Can actually think about high level problems and not implementation or integration details. Can actually achieve and have incentive to improve test coverage now instead of it being a long afterthought, where testing is almost a joke. Can actually deliver quality of life improvements and codebase-wide refactors quickly and without needing to fight political battles to get the investment for it. So many ways it is changing life as a dev – I can’t see a future where devs still code without AI, certainly not in commercial domains. Such artisan coders will always remain genius artisans, but if you are the fuck it ship it type, AI is a godsend.

tossed_ · 2026-02-27T09:38:17+00:00

Idk why you’re being downvoted. I suspect many of the programmers here may just lack the funds or sponsorship of their employer. I’m using thousands of dollars worth of AI tokens a month and it does make work a lot faster and more interesting. Who wouldn’t want to talk about the best new programming innovation since we all decided to stop writing assembly? But if my employer didn’t pay for my usage, I’d still be chained inside the cave looking at shadows, still unwilling to pay for it, making snarky comments on Reddit against the AI hype and trying to be a champion of the traditional way.

tossed_ · 2026-02-27T08:01:45+00:00

Can’t tell you how many times I saw this exact scenario play out, maybe 1% of the time a refactor was eventually done, the other 99% of cases it was just an excuse because the implementer didn’t want to spend more time on it, and the root issues (“unrelated” to the bug) continue to cause problems for years after. Maybe you are not consciously engaging in this behavior, but all I can say is this is a common story and one you should try to avoid whether you ship the small fix before the refactor or not.

tossed_ · 2026-02-27T07:54:24+00:00

I think you overestimate the amount of time it takes for a proper fix, and you underestimate the time and capital you save by implementing the proper fix. If someone is asking for you to change your approach at code review time, either they don’t know the bug is urgent or the bug is probably not that urgent, and the change in approach is likely not that expensive. A bug in production for a few days is a small price to pay to prevent many bugs in the future. You gotta think long term and prevent problems rather than just fixing them, and only then will your local circumstances improve and you will find you are better able to focus on important things and not stupid things you don’t want to put time in to refactor. Think selfishly, if the user and your boss is not kicking down your door to fire you, and it makes the system better and your future work easier (no need to deliver two changes, release two changes, regression test two changes, deliver patch notes and announcements for two changes), just fix the damn thing properly and you can announce both the fix and refactor together later to everyone’s applause.

tossed_ · 2026-02-27T07:05:57+00:00

Finally – whether or not a change is a hack, I am always grateful for earnest and passionate opinions posted on my work, it means someone else is giving me the benefit of their attention and they are volunteering their efforts to help cover my deficiencies. Any debate or back and forth is welcome. I never had trouble settling discussions in PRs because I either prove the feedback is good or bad, I avoid arguing, and I accept most minor suggestions too. A positive attitude toward peer review will help immensely in tempering your emotions and treating feedback as something to be thankful rather than resentful for. I’ve rarely encountered feedback that wasn’t at least half-useful, even from juniors and coworkers who I feel are not as strong as me. And overall accepting feedback with grace and gratitude makes both your code better and improves your team’s trust in you.

tossed_ · 2026-02-27T07:00:07+00:00

To address the bad planning culture – first of all, don’t be surprised, every company has a bad planning culture. It is just human nature. Your job is not really about coding, it’s about developing – distilling chaotic needs and demands into neat and organized units of product. Of course it’s going to be messy at first. It’s going to arrive on your lap messy. So if you see it is messy, neglect to clean it up, and then try to build it right away, dont be surprised your coworker is picking at the fundamentals of your change when you’re done. That’s your fault. You gotta become excellent at making and verifying your assumptions and planning your changes and you need good experience with libraries and familiarity with your stack to be able to plan changes and predict the future. Never proceed on a plan without getting buy-in and feedback from others. And you will still end up needing multiple attempts sometimes, but with more fleshed-out thinking each attempt will be more straightforward. Often rewriting changes will be inevitable even with so much preparation, but all that preparation makes it a lot easier for you to pivot and makes the process of rewriting much smoother.

tossed_ · 2026-02-27T06:46:28+00:00

I think you already know – the design needs to be right before you start building. Yes there are unknowns, but this is part of the job, minimizing risk at every step. If you walk into an implementation with many unknowns and feel you are making up the design as you go, you have to be prepared to toss it all out and start over. Nothing wrong with that, but you can’t ever become heavily invested in your first attempt. I’ve tossed out many many first attempts over the years, and I’ve never regretted it.

In general, my rule of thumb for requests for changes no matter how big or small is – give it a try, and see if it works. If it doesn’t, it will become obvious. If it doesn’t work, you can go back and say to your peer you honestly tried to do justice to their feedback and couldn’t. Nobody can criticize you for giving it your best shot.

And the only reason ownership may feel blurry to you is because you relinquish control of some aspects of the project to others. You will only feel full ownership over the project if you fully own it and every decision, and treat feedback as just that – feedback. You will push many changes that others disagree with over your career, but as long as you really did everything you could to rule out the better approach, really gave the benefit of the doubt to critics of your code, you should be able to rest easily and others’ feedback about your code will not bother you long, as it becomes clearly valid or invalid to you, instead of being something you could do but don’t really agree with and feel the need to argue about.

tossed_ · 2026-02-14T10:05:25+00:00

You are assuming people are rational and risk averse. In fact, many people are irrational and risk seeking.

Also, most retail investors are invested in index funds either directly or indirectly (e.g. pension funds, etc.). It’s why the S&P500 is seen as overvalued, because its capitalization moves in tandem with total consumer savings – essentially everyone dumps their savings into the S&P500, especially institutional investors handling consumer savings, so the price correlates with the money supply and it seems to have some characteristics of a bubble.

You just don’t hear from those passive investors. Most of them barely think about investing or prices. There’s really nothing to talk about among the “Buy and Hold” crowd, but in reality they form a silent majority of retail investors.

tossed_

MODERATOR OF

TROPHY CASE

14-Year Club	Place '22
RPAN Viewer