I'm at that point now, debating when I'll retire. We only live once and I'm not sure if I should continue working. I've reached financial freedom at a pretty young age. It's a daily debate in my mind when to call it quits, but I've never not worked and it's difficult to make the change. What I'm missing in life is time and that's what work takes from me and is the driving force behind my desire to retire -- time to do other things in life.

I have a wife and two kids. That's one reason I still work (it's probably not a good example for the kids to see a father not working)

And if you do have kids, the most profitable thing for your wife to do upon learning you won't be working any longer would be to divorce you, take 50%, impute your income for child support calculation at what you were earning before (so every 5 years you owe your full pre-tax salary). That way their quality of life won't be impacted nearly as much.

So likely at least 8x your pre-tax salary (like 11 or 12x post tax) is gone right off the bat as soon as you retire. So if you are retiring before age 40 basically all of your wealth will vaporize as soon as the mother of your children realizes they can basically take the entire wealth through a mixture of divorce, child support, and alimony and they must act fast before the imputed income calculation drops.

You could stop working and lie for 5 years claiming you are employed and doing work stuff. Then the risk of this is over. But you should definitely have a prenup or a postnup if this isn’t possible.

More broadly, I'd say if you don't have something to retire to (kids or otherwise), don't.

Yup, that’s how you end up dead very quickly.

It’s taken years off of my life dealing with the test mess people have made with it.

Absolutely the worst. 1000 line test setups that shatter into pieces the instant you try to make the simplest change to a function. Makes refactoring an absolute nightmare.

What's specifically bad about Mockito here? Poor defaults for mocks?

You've just built a calculator, and now you want to test it. Well, you have to push buttons on a calculator, so you build a robotic hand. And that hand needs a power source and some intelligence. And you need to photograph and OCR the result from the calculator screen.

This is kinda how we build software right? A little bit of "our logic" (calculation), represented as objects/actors/modules which "do things", but intermingled with million-LoC dependencies like databases and web servers.

After a while it gets frustrating setting up the robot hand and OCR equipment for each test case. Maybe it's just easier to test manually, or skip testing entirely.

At this point you can have an epiphany, and realise you only care about the numbers going in and out of the calculator, not the button pushes and pixels.

Mockito swoops in and prevents you from having that epiphany, by making it easier to keep doing things the stupid way.

Instead isolating the calculation from any IO, you can now write things like: when(finger.pushbutton(1)).then(calculator.setState(1)) when(calculator.setAnswer(3)).then(camera.setOcr(3))

(I've mostly worked in Java, but it seems like other languages typically don't let you intercept calls and responses this way)

I’ll answer: Nothing specific to Mockito, it happens in every language. Tests “solidify” code which makes refactoring hard. And yet, after refactoring, one can be happy to have tests to check whether there is any regression.

Testing is hard. I’ve tried with AI today: No, it is still not capable of handling that kind of (straightforward) task (Using Claude).

They also encourage/enable code that is less testable. If you use mockito to get your fake responses/assertions where you need them, you don't have to think about your class's dependencies to make your code testable and therefore better decomposed. I don't even do TDD, but I still find that thinking about how I'd test a class guides me toward better-factored code.

One alternative to make code with typing styles in the Java way (as opposed to the Typescript or Go way) is to have a whole lot of custom interfaces and then you end up with a whole bunch of:

  doTheThing(foo: Fooable) { ... }

when there's really only one Foo implementation in prod. It leads to (what feels like, to me) more code obfuscation in large projects, than the benefits that come out, at least for me.

So Mockito and friends are a nice alternative to that.

That is just my experience and opinion though, and there are definitely more valid or equally valid alternatives.

I don't think we have to choose. Naturally finding the "right division of labor" is as infinite as finding the "right level of abstraction", but I think the ideal situation is to strive toward code that is easy to test without having to introduce a lot of mocks or without infinite layers of abstraction.

IMO Mockito is fine, the problem I’ve encountered is people taking the easy way out and trying to test something that needs a real integration test with a convoluted series of mocks.

I've found that most of the time that if you need to mock, you probably just need to do an integration test.

I agree. I mostly only use mocks for external service dependencies (apart from primary application database), or library features that are very problematic to use in test. A lot of code simply should not be unit tested - if an integration test can cover the same paths its far better in the long run. Performance can become an issue but it is easier to deal with that than to spend so much time maintaining and debugging mock constructs.

I can’t concur with this enough.

I’ve been on projects where mocking _literally made the project less reliable_ because people ended up “testing” against mocks that didn’t accurately reflect the behavior of the real APIs.

It left us with functionality that wasn’t actually tested and resulted in real bugs and regressions that shipped.

Mocking is one of these weird programmer pop-culture memetic viruses that spread in the early 2000s and achieved complete victory in the 2010s, like Agile and OOP, and now there are entire generations of devs who it’s not that they’re making a bad or a poorly argued choice, it’s that they literally don’t even know there are other ways of thinking about these problems because these ideas have sucked all the oxygen out of the room.

> like Agile and OOP

Ha.

I think there's room to argue "Agile" is a popular bastardisation of what's meant by "agile software development", and with "OOP" we got the lame Java interpretation rather than the sophisticated Smalltalk interpretation. -- Or I might think that these ideas aren't that good if their poor imitations win out over the "proper" ideas.

With mocking.. I'm willing to be curious that there's some good/effective way of doing it. But the idea of "you're just testing that the compiler works" comes to mind.

For OOP, I'd say the issue isn't so much that it's not useful (it is very useful), but rather that it was treated as "common sense, the only way to do it".

Sometimes the right tool for the job is objects, sometimes it's functional, sometimes you do want encapsulation but it's better as structs and using composition over inheritance. When everything looks like a `class Hammer extends Tool`…

Agreed - I like your phrasing of it. There are some good ideas in OOP. I don't know that I'd go as far as to credit OOP for those ideas, but things like polymorphism and encapsulation can be very useful. What I objected to was, as you said, OOP became "the only way to do it". It became a dogma. I was very happy when functional programming started to break through and show that there were other ways that were not only viable, but often better.

Had my fill of both until I could not stand it anymore. So tired of the grifters--agile was sometimes good, but mostly a grift.

Mocking and integration tests are not mutually exclusive. I often use mocks in my integration tests. Some things can be integration tested, some things can't. Sone things you just need to mock.

People using it wrong. It definitely should not be that popular. 95% of times when I see it I consider it a tech debt.

You should be using it in rare cases when you want to verify very complex code that needs to be working with strict requirements (like calling order is specified, or some calls cannot be made during execution of the method).

Usually it is used for pointless unit tests of simple intermediary layers to test if call is delegated correctly to deeper layer. Those tests usually have negative value (they test very little but make any modification much harder).

It allows you to mock the whole universe so it becomes a hammer instead of nicely designed functions, interfaces.

Which is absurd that people use mocks considering the tests are supposed to help with refactoring but because of the mocks they can’t make a change without breaking the test.

I wish there are tests written to cover functionalities (& race conditions) instead of covering lines/branches.

I do everything I can to avoid public transportation. It's not worth the risk or the annoyances with aggressive and dangerous people. If I lived in Asia (which I did before), I'd love to use public transportation because the people are not aggressive, won't attack or kill me. That's not the case in the USA

Most of the places within public transportation range are also within biking range, so I prefer biking. The end result is the same: one less car off the road.

Now if you say "What about all the crazy drivers??" think about this: have you ever considered that you might be the crazy driver? Maybe not 100% of the time, but maybe one day you're stressed so you speed up to get through a red light, or you really need to read this text because it's important. You only need to be a crazy driver for 30 seconds to end someone's life. Something that's almost impossible to do on public transportation or on a bike.

Yeah I don’t bike for that reason. There’s no way I’ll ride a bike around cars and I can’t believe others put their life in the hands of people texting and driving.

But you are okay driving around these crazy people, even though one of them could cause an accident costing you thousands of dollars and potentially a source of transportation?

Try using American social media and offerings in China, and lately, Russia.

To be fair, in some Russian regions you cannot access even most Russian sites from mobile (we have whitelist mode). Also, not everyone, but some people started using VPN after Instagram ban, and even more after Youtube ban. Like drug addicts who cannot drop their habits.

But it's not about reciprocity if you're truly committed to free speech right?

The first amendment isn't a suicide pact, and foreign corporations were never covered by it.

It's not a 'suicide pact', it's a clear commitment that the government will not ban speech it finds inconvenient.

It's not done a great job of living up to that promise.

Americans still have free speech. There are many other platforms to use. Foreign governments never have had free speech rights and I doubt most people support them having those rights.

> There are many other platforms to use.

That will promptly proceed to bury whatever the government tells them to bury.

Exactly. I don’t even notice it.

>There's maybe like a few hundred people in the industry

My guess is that it's smaller than that. Only a few people in the world are capable of pushing into the unknown and breaking new ground and discoveries

Immutability was gaining huge traction with Java... then large parts of the industry switched to golang and we hardly make anything immutable.

Go desperately needs support for immutable structs that copy cleanly.

I want to be able to write `x := y` and be sure I don't have mutable slices and pointer types being copied unsafely.

I would kill for an immutable error type

Go is the new PHP.

Much like PHP, you can actually get stuff done unlike a lot of other programming languages.

Oh? Which “lot of” other programming languages can’t you “actually get stuff done” in? Are you sure the problem lies with the programming language?

It’s an exaggeration perhaps but I get the sentiment. FP is elegant and beautiful and everything, but it can lead you to spend all day puzzling out the right abstractions for some data transformation that takes 5 minutes with a dumb for loop in Go.

I find there are some environments where you have a positive feedback loop while working in them. PHP is one of them, Go is another at least for me.

I find many of languages I am constantly fighting with dependency managers, upgrades and all sorts of other things.

If you are on iOS seems you need to unmute your phone.

Not the Op but I’m in the same boat. I get the latest and whoever has the oldest phone among my wife and two kids will get my 16 pro.

I have two teslas and the build quality is amazing. I never do anything to them other than change the tires. Haven’t even touched the breaks. It’s the ultimate daily driver and I’ll never buy another type of car.

Build quality is attention to detail, not reliability.

Your hydraulic brake systems need to be flushed every couple years to prevent corrosion, even if you don’t use them.