I've been through about 5 Agile shops now. I would say one of the 5 ran Agile well, the rest were a mess that just makes it frustrating for everyone.
What we mostly have now is watered down agile.. the worst bits of agile like never actually "designing" anything, but we don't really have any of the good bits of the older management processes left over.
I don't really want full waterfall again but I would really love to see some sort of lite versions of Functional specifications & design specifications come back.
Agile works best IMO in the Pre-1.0 phase of a product and gets progressively worse the further you get towards maintenance of a product. I also think Agile works better and better the closer you are to the UI, and worse and worse the further you get from the UI. Solid back end design and infrastructure rarely fits well into "Sprints" and solid back end infrastructure is not sexy at all in a demo, so Agile can demote back end design to the point everything gets done in a way that is too MVP. Then later on when scalability, performance, bugginess, and maintainability come into play you're into that "established product" phase where Agile doesn't do as well. So you've got problems in an area of the product Agile has trouble with happening in a phase of development Agile has trouble with.
Agile also seems to really require absolutely top notch product management folks, and they are seriously rare.
The thing is of the 5 shops:
* 3 Were acquired
* 1 Went IPO
* I work at the 5th currently
So the companies always had a successful exit even if the codebase passed onto the acquiring company or to the public investors had major issues.. so at least in my experience there's no feedback loop to correct the issues.
The separation of design and construction into phases is a hangover from civil engineering. It has the baked in assumption that the design phase is relatively cheap, short and somewhat unpredictable the construction phase is expensive, long and predictable. The root problem is the assumption that specifications can be validated for correctness, like a blueprint for a bridge can. Nothing could be further from the truth. This is a persistent myth in software development.
Wikipedia has a current events portal. I think it's a pretty decent way to stay abreast of events without falling prey to the outrage cycle. Basically, nothing shows up on there unless it is significant enough to warrant a Wikipedia entry. That may not be the perfect filtering criteria, but it's world better than the algorithm that decides what ends up on the front page of Google News.
This is going to sounds like crazy advice, but having worked on many side projects in my life the last thing that's going to let you down is your skills. What you really need is time. Let's say it takes you 400 hours to build your project -- in those 400 hours, you will build up enough skills to get you started (not nearly enough to be good at it, but good enough).
So you need to work consistently 1-2 hours a day on your side project. It really doesn't matter what you do. If you manage to get those 1-2 hours in, you will muddle through and accomplish something. If your goal is to make a side project and bring in a non-zero amount of money, this is achievable. Learn whatever you learn on that project and then do it again.
Personally, I would spend exactly $0 on your task because, like I said, the thing that will kill you in the end is likely to be time commitment. If you spend money, you will be out the money and your time. So start with time and see where it takes you.
As others have said, no need to get fancy. Just build the simplest thing that will get you started, using the simplest tools you can find.
Without this, I might have given up on Haskell a long time ago.
Also Cachix[0], as building lots of Nix packages from scratch takes an awful long time, especially on my MacBook Air.
Also git, vim, etc.
[0]: https://cachix.org/