It's crazy, I just call a contractor I trust and they fix it, and then charge enough rent to make sure it covers anticipated maintenance, and then have a business insurance policy to protect against big disasters.
Charging enough without leaving the property empty can be a challenge. As is finding tenants who won't trash the place so often you lose money on all the repairs and turn over.
Depending on the market that may be so easy you'll think everyone else is stupid. Or it may be so hard you wonder if you are doing something wrong.
- you previously spent time building relationships with contractors. You didn’t just type in property management in Google
- a significant overhead goes to insurance and management. Your comfortable putting money as needed into the venture. You have knowledge of legal pitfalls of being a landlord.
- you regularly spend time managing these contracts
Sure, but you're managing the property. And that's great! Many get into RE thinking it's a set it and forget it type thing. That's not the case. But the work is pretty well understood and it can be done as a side gig, making it great for someone who wants to add to their income.
I know a number of people who have done very well with RE, but they all actively manage their properties.
That’s what the article suggests: “there’s no evidence that Kiyosaki actually made significant money by real estate dealings, prior to making millions of dollars with his book sales (and presumably putting some of that into real estate.)”
He already has stated publicly that the “rich dad” is a characterization. And the book is about the 4th product in his attempt to teach finance courses. So I’m already suspect of the article.
Yes it’s a terribly written book, but that’s typically the case from non-professional writers who just have something to say.
My biggest takeaway is that “stay in school so you can get a good job” is not a great wealth creation strategy. You just compete with other highly qualified candidates for jobs that pay 20-30% more (See 20+ years at Boeing). Jobs like this also attract other risk averse people.
this sounds a lot like the psychology of having nothing to lose vs something to lose. You play more aggressively and are more successful in the former case.
> I'm now ignoring recruiters who are begging me to interview for insanely well-paying openings. I have a decently well-paying job with good work-life balance, and colleagues who respect me.
So their utility function has terms other than $. So define "successful", or define the utility function more objectively. It is very clear that yours vs theirs are quite different.
I would disagree. The purpose of big O in the STL is not to allow you to compare different algorithms, but allow you to reason about how that will scale with input size. If I test perf with a size of 1000 and then it’s declared to be linear, I have a pretty good idea if that’s the right tool for the job.
Do you have any examples of “better” algorithms that the STL is not able to use? Another idea in STL is to provide many algorithms, which is why there are 3 sorts.
> Another idea in STL is to provide many algorithms, which is why there are 3 sorts.
Where do you see three sorts with different behaviour? I see two, an unstable sort just named "sort" and a stable sort.
sort performs O(N⋅log(N)) comparisons and so does the stable sort, although to be fair it also promises to work (more slowly, O(N⋅log*2(N)) instead) if there's no scratch space.
We don't get to ask for the no scratch variant, so we can't count that separately.
And these big-O values are totally uninteresting because they're typical for every modern sort, when people announce a shiny new general purpose sort it has the same complexity numbers. Does your STL have it? Who knows, the standard doesn't specify.
And that gets back to my earlier point, Introsort, the typical sort you'd find in an C++ program today, is relatively modern, and C++ was standardised in 1998. So actually quicksort was often in a "complying" C++ stdlib because hey, that's good right? Well, no, Quicksort's worst case has O(n*2) so it's actually forbidden by the STL's documentation, but nevertheless it was shipped because for many real world uses it's fast.
The creator Alex Stepanov also included insertion_sort (used in sort) but it was rejected by standard committee.
That suggests that the idea that complexity is primarily to compare is wrong, because then why would anyone pick insertion_sort? Of course there are real world cases where it is the right choice. But if you need the complexity guarantee, then it's not.
> shiny new general purpose sort
I don't want it in the standard until it's proven useful and has some longevity, not just a micro benchmark. Shiny and new are exactly the wrong adjectives.
Why can't you include a header?
> quicksort
Introsort is simply a variant of quick sort with heap sort as a fallback to avoid the worst case, and insertion sort at the lowest level.
Anyone who tried to pass off naiive quick sort simply wasn't educated about the topic, so it's good that they were not standard compliant.
I had never seen std::sort_heap before, that is kinda cool.
I'm torn about whether this constitutes a sort though. Like, yeah, in some sense this is the meat of a heap sort, but, it's the caller's job to provide the data as a heap first and of course this is C++ so if we screw that up it's Undefined Behaviour.
> I don't want it in the standard until it's proven useful and has some longevity
I wasn't advocating for such things to be in the standard but to be in the implementation. One of the worst sins of WG21 has been standardising implementations, as they did with std::unordered_map and continued to do in newer C++ versions.
And you're wrong, these people knew exactly what they were doing. You've probably used a stdlib which did this (such as libc++), the reason was very simple: Despite the big-O complexity, in practice quicksort was fast while heap sort, though compliant, is usually slower. Benchmarks matter. Big-O not so much.
Like I said, Introsort was new, and as you've explained you want to wait until things have "some longevity" before standardising them, so the stdlibs didn't take Introsort at first. LLVM took Introsort for libc++ in 2021, Microsoft landed a compliant sort some years earlier. Neither complied with C++ 98 initially.
I mean the big joke for LLVM is that the bug ticket about their sort complexity which sat in a pile unresolved until after Joe Biden became president was by Orson Peters. It's like realising the guy who pointed out that your physics textbook has the formula for mass-energy equivalence wrong is Albert Einstein. Gee, I wonder if Orson has any idea for how to fix this libc++ bug...
The most infamous case is that std::unordered_map is essentially required to be a bucket-based hashtable, whereas it's usually better to have a probe-based hashtable instead.
The thing that's fascinating for std::unordered_map is that it wasn't standardised in C++ 98. These hash tables are a C++ 11 feature.
They feel like a 1980s feature, if there was a hash table in C's stdlib, this is the hash table you'd expect. But it's not in C and it wasn't from the 1980s, it's from the same year Osama Bin Laden was killed by US special forces.
Rust existed at the same time this data structure was standardised. Not Rust 1.0, but that's insane, it's like when you realise millions of older Spanish people were alive before their country was a democracy. Many are old enough to remember the prior regime.
Well, if you want to be pedantic, std::unordered_map first appears in the C++ working draft in 2006 (N2009), which is before Rust was first publicly announced.
I do want to be pedantic, but not in a fair way :)
The C++ 11 standard was not required to standardize broken garbage from many years ago.
WG21 pulled C++ 0x Concepts (a much more powerful feature than the "Concepts Lite" which landed in C++ 20) because they argued it might take too long to implement, ridiculous as that claim is, so there's no reason to keep something terrible just because it's in a draft paper.
It's extremely hard, so with 13 extra years they were able to make an astoundingly bad job?
It's hard to even believe this was trying to be general.
Notice that not only the hash tables themselves, but the infrastructure is garbage too. In 1998 C++ STL is one of the earliest generic programming APIs, nobody knows how you should implement the generality of something like hashing, fine.
But by 2011 people had tried several things, and this (the std::hash templated callable which returns a machine-word integer) is not even a reasonable attempt at a known good design.
To counter that, when you have a team with external accountability and teammates relying on you and a salary, that can be far more motivating than working on personal projects by yourself. I wouldn’t discount the field just because of that.
I once held opinions like that, but overcame them long ago.
I came to realise that this kind of stereotype was effectively a narrow minded form of gate-keeping that contributed to the myopic tech-bro dystopia that’s been swallowing all that is good in this world.
Additionally — the original poster has been living through some very difficult times, it would be perfectly normal, and not a sign of job fitness, if motivation hit zero during a period like that.
I just urge them and others to ignore what you’ve said, and to look for a broader worldview.
I think that success isn’t from individual “great engineers” but from excellent teams and collaborations.
We over emphasise the myth of the solo genius, for example, as it fits neatly into “stories”.
There are many cases where the heroic genius “great engineer” seems to be the solution to all of the problems… until they get sick or fired and suddenly the remaining team becomes far more productive than they were before.
It’s a bit like in “moneyball” — how the talent scouts were looking for batsmen that could hit a home run, but the real value was in the batsmen who could consistently make it to first base.
Attributes like “personal motivation and curiosity” — are also filtered through the interviewer’s perception — they become: “personal motivation and curiosity in a form which I can immediately recognise because it fits the patterns I am predisposed to expect” - and this lead to very narrow selections. By looking for this trait (and believing that you can detect it), what other traits are you missing? (Hint: all of them)
In my opinion, you have a very simplistic view of the world and our industry. I formed this from reading quotes like the following:
> If you haven't been naturally excited to work on your own projects during this downtime, this field might not be for you.
reply
Being successful in this field doesn't require programming in your spare time - especially so not while going through a difficult period in life. To think that is the case is a case of pattern matching on a simplistic pattern.
> Do you think you can become a really good engineer without being personally motivated and curious?
No one said that OP wasn't personally motivated nor curious. Again that (in my opinion) is faulty pattern matching. People can be both motivated and curious without taking your one prescribed path. Separately, nothing in this question was about OP trying right now to become a "really good engineer". If your top goal in life is only to be really good at your job, you may want to broaden your horizons w.r.t. your priorities in life. Studying a field, becoming good at it, and making a living doing that is a very wise choice - none of that requires becoming one of the top 10% at that role.
> So no such thing as a good or bad engineer?
No one made a statement even remotely like this. This is a strawman you chose to "reply to" rather than respond to what the prior commenter said.
I don't think your advice is good advice for OP nor a good outlook for anyone starting their career regardless of how ambitious they may be.
> Being successful in this field doesn't require programming in your spare time
I already addressed this point.
> No one made a statement even remotely like this. This is a strawman you chose to "reply to"
No. My argument was that it’s important for a new engineers to have drive and curiosity to get started. The other poster replied that this wasn’t true because “teams”. So I was checking for understanding about why this individual does not need to take their personal development seriously.
> I don’t think your advice is good advice
This is why I am asking questions that seem stupid to you. You don’t think someone should have strong natural interest at the beginning of their career?
> You don’t think someone should have strong natural interest at the beginning of their career?
Again I never said nor implied that. In fact I specifically commented about how incorrect this statement was. I see your line of approach consistently appears to be rather than reply to what is posted, pick a easy statement that nobody stated and argue against that instead. I think it's not a productive use of my time continuing further discussions with you as you are unable to engage with what's actually being said.
> So no such thing as a good or bad engineer? Just teams then?
Buddy I understood your original points — and once held them myself — but if this reply is how you construe what I’ve tried to share with you, you have not reciprocated with any genuine care in trying to understand the conversation I thought we were having.
Counterpoint. One of the best engineers I've ever managed, nearly a 10x engineer, never coded outside of work. The dude was a bass guitarist and cyclist, never opened a code editor or terminal outside of his 9-to-5.
For example, I'm excited to work on my own projects, toying with new languages, teaching my kids, etc, but the overwhelming priority is to find something that pays the bills, and after a long and demoralizing day following that goal, I have little energy to invest much in a shot-in-the-dark side project, even if I had a good idea for one.
I would also rather be an engineer than fix apartments.