Fully agree that they are great though.
Anyway, when I was working in sales, I was handling pre-sales, closings, and post-sales support. We were manufacturing and selling security equipment. The goal never was to simply close the deal. We wanted to expand the network of distributors, and to do so, we needed to build long-lasting relationships.
I quite liked the experience, but I was always more tech guy than salesman – I guess most of my clients were coming back because I was preparing projects of CCTV installations, I was providing trainings for clients and their crew.
But as a typical salesman described in the article, I would be terrible.
Most of the entries are for specific books, but there are also some authors mentioned, e.g. "The Collected Works of Dean Koontz": http://www.rinkworks.com/bookaminute/b/koontz.shtml
[0] - http://www.rinkworks.com/bookaminute/b/dick.scanner.shtml
I've been cranking on a 2D engine for over 4 years and have put thousands of hours of work into it.
My summary:
If you want to write a game, just write a game. Don't start with your own engine since this will suck all your time and you'll end up spending 90% on engine and very little getting the game game done. Especially so in the beginning when you have no features and doing anything in the game requires engine work.
If you choose to create your own engine it's a compelling and fantastic domain where problems come in all shapes and sizes and you can and get to work with physics, maths, linear algebra, audio, rendering, graphics APIs, system level programming, most likely native programming AND scripting, game content, technical art etc.
But finally the real work is not the engine but the tooling and the editor around the engine.
If (when) you rely on free assets from (for example opengameart) you can expect no consistency. Not just the art style but just the technical part too, like your models are all inconsistent in shapes and sizes and axis, 2D content such as textures are by default without any meta data etc. So you really need to create a ton of tooling so that you can have sensible workflows and you can extract and consume the usable and interesting parts of any content package easily.
This inevitably leads to the concept of "editor" which easily comes with a ton of work by itself that has nothing to do with game or game engine per se. For example the concept of "Project", windows, resource management, basic editing functionality for creating content, undo/redo/ etc. A lot of this is not really related to the game or the engine in anyway but you really sort of "must have it" if you want to create something that is actually usable.
The feature creep is real! But once you get the over a lot of the boiler plate and you can actually use your own editor to stuff content into your own engine and have it running it's really a nice feeling even if nobody else cares!
On the technical side my advice is really to be able to do first principles type of thinking. It's of utmost importance to be able to break things apart into self contained features and pieces that the game can then combine to create bigger constructs.
If you can have your materials scroll textures vertically, when you combine that with shapes that are layered and place textures onto those shapes that scroll at various multiples of your "characters" speed then you've just created "parallax scrolling" essentially.
-----
This type of project is small enough to plan all the elements before you start (which helps to stick to the design and therefore to avoid feature creep). Yet, it is still complex enough to provide entertainment and challenge.
This approach also has the advantage – at least it is an advantage in the case of side projects – that you can see the results of your work quite quickly.
I'm working on such a project myself, and it is a great experience. Although to tell the truth, it is more of a "game creation kit" than an engine.
There might be a way to get standard ML to output lua or something but I'm not that familiar with it. I think it would be an incredible fit for a third backend for gleam, but they say they aren't adding any more beyond erlang and js.
[1] https://github.com/minoki/LunarML