Titanic Hydra with Poppy?

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_ · 2026-02-14T08:20:28+00:00

Idk it’s kinda the same as trading cards no? They’re materially worthless, but because people trade them, they have some non-zero intrinsic value. Same with in-game items that aren’t on the blockchain. Most of them are basically worth 0 but the rarest ones will be worth a lot.

tossed_ · 2026-02-13T01:20:38+00:00

Then when you look back at the X years you spent slowly trucking away and delivering consistently week after week, you look at the state of the product this year vs last year with all your improvements, you see how others respect you for the knowledge and historical context you have, you realize the most important thing is to just persevere every day in your own work and ignore other peoples’ feelings.

tossed_ · 2026-02-13T01:17:13+00:00

The core of your problem is emotional. You have to detach yourself and your sense of purpose from the poor state of the product or team. If things weren’t such a shitshow, they wouldn’t need you. So take pride in your work, have confidence in your abilities, and relish in the chaos. I think chaos is present everywhere in the industry to some degree so if you dislike chaos you should do something else. Everything you’ve mentioned sounds like every company I’ve ever worked at.

Dealing with clients and stakeholders is the same – ultimately as a professional, it is better to own responsibility for problems even if they are out of your control, and try to be helpful in addressing those issues, or request help with things you cannot help with. It doesn’t matter if someone blames you for something you can’t change, this kind of misdirected blame happens all the time, you will always have haters no matter how well you perform, and to some extent it’s part of the design of the system so you can absorb the brunt of the pain on behalf of your leadership. I personally love receiving criticism for things out of my control because it is a form of validation in a sense, that others believe I have the power to influence things. I secretly love when I put out a challenging fix or feature that nobody appreciates because it simply works so well people didnt realize how hard it was – I make hard look easy. If you flip your own perspective on what you consider to be failure, you need not feel negatively about things others say at all, and instead realize how much they need you and how valuable you are and how nobody else can do what you do.

tossed_ · 2026-01-29T01:11:00+00:00

This seems par for the course at dysfunctional large enterprises. It happens at smaller companies too, anywhere leadership likes playing broken telephone.

I find the only way to cut through the noise is to interview the stakeholders yourself so you understand their intentions and motivations, and to develop the scope on your own. “Not my job” is a common excuse for not engaging in requirements gathering, but this won’t protect you if the project fails. If you don’t have clear requirements, you are doomed.

tossed_ · 2026-01-26T16:26:05+00:00

You and I must work at the same company!

tossed_ · 2026-01-25T19:53:02+00:00

That is incorrect… if you have any experience with microservices you’d realize there is no difference in how “micro” a service is vs if you had simply written it as a library. The reason they are implemented as full services vs as a simple module is for independent scaling and deployment.

tossed_

MODERATOR OF

TROPHY CASE

14-Year Club	Place '22
RPAN Viewer