A year is actually not that much for porting such a huge legacy system to a new platform. I imagine most of the work was making the interfaces from/to other platforms.
I think parent was answering the usage of XML in this use case, which is not appropriate. XML has many strengths (as you have outlined), but it has also been (mis/ab)used so many times that it gained bad reputation. What my GGP suggests is an example of such. There is nothing to gain from XML here that any proper DB (with schema) wouldn't offer, or in this case, protobuf.
Kafka logs however are solving a different problem. The mental model is different - they do not record state, but the whole history of transactions, which makes it trivial to change the schema if/when need arises. Saying that the schema should be thought in advance and shouldn't change is not realistic IMHO.
Ok, allow me to me rephrase GP: will this make it possible (in the long run) to train tensor flow models on AMD acceleration cards in a supported, easy-to-use and performant way, comparable to what NVidia is offering?
The key word is "eventually". CV is making huge progress lately, but it is nowhere near human level yet. My guess would be that the first generation of self-driving cars will use Lidar because it means shorter time-to-market. Later manufacturers will be able to supplement Lidar more and more with cameras + CV. And maybe microphones, thermal cameras,...?
Sure - but I am guessing a few errors here and there would have much less impact than a single programming mistake. Not that I think this is the right way, but I do understand where they come from.
Retention! Always focus on retention. If people keep using your product then you have product market fit. If they keep leaving - you have an uphill marketing battle.
I find it much easier to estimate the time it will take if I take myself out of the picture. When estimating, I always try to think "how much time would it take for my colleagues to plan, execute, test, etc... something"? It is almost impossible to judge your own speed, but with experience you learn how to estimate speed of others quite accurately.
Of course, I also let product managers know that any change will affect the deadline, and almost never in a good way. I do this every time they have another "really simple idea".
This. They are not making paper out of stone, they are mixing limestone in plastic. No doubt there are some benefits to it (less plastic is used - though not 80% less because limestone has higher density), but marketing this as "paper" is highly misleading.
This is the perfect answer! Nothing else matters in this situation. The only problem with the picture painted by OP is that he is reluctant to let go of control, which is exactly what he should have done a year ago, at least partially.
Nobody in the company should be irreplaceable, otherwise you have a single point of failure.
On a more practical side: don't work on your vacation (and I mean this in general - like ever) or it doesn't make sense to even go on one. If you must, you can try shorter breaks first so you get confident that the world is still turning once you get back. And do not answer phone calls during the breaks!
Actually, your experience sounds great! In general, it is much easier to find people with narrow interests. While it might seem to you that you are not employable, this is just an illusion - there are many developers, but few with experience "from development to product design to finance". This makes you a great fit for virtually any smaller company which doesn't have a separate person for each role - startups, new businesses,...
TL;DR: You didn't fail. You learned.
As for burnout - been there. If it's any consolation, it will go away once you find something new that will keep you motivated.
I respectfully disagree. Of course you need to really understand backpropagation for any advanced stuff, but it is easier to ignore it at the beginning. Take Keras container, copy some MNIST example from somewhere and tweak it. Then, when you have a general feel of how training NNs works, gradually learn about each concept - BP should of course be one of the first. By the time you get into math stuff it will probably make much more sense because you will understand how it applies to your case.
But I guess the approach depends on how you best learn, so there is no wrong answer. Just jump in!