"Any application that could be done on a blockchain could be better done on a centralized database."
The scientific community will disagree with this. The whole culture of independent peer review process assumes there is no centralized control over scientific conclusions, whose rigor stems from decentralized feedback. The time when centralized database (source of truth) became the basis of mainstream science was during the dark ages.
> Admittedly, I have no clue if the management realises that !
Well, that's the key thing in many places: it's management that decides whether to hire and how much to offer, not you :)
The first instinct would be to put 'resources' that costs little into a project, and that usually means people with less experience that requires less pay and are easier to drag around. Imagine the difficulty they will be having trying to grok your line of reasoning for respecting and going after these older devs.
Even in a team of specialists, some of the work they do can be off-loaded to a full-stack developer to free them up for tasks that require more of their expertise.
For example, a front-end specialist would be better off optimising the slow page response times of the product's news feed or implementing a new application page altogether than, say, adjusting css that break on a few view ports. In a big team, you can push the CSS fixing job to a junior; but in a lean team, it's better if this goes to a generalist in your team.
If your backend dev is busy on implementing OAuth, he can off-load fixing a bug that has a small fix but is hard to test like a minor refactor. You compound this "minor" jobs and you will need a lot of junior staff to help on the load, or you could hire a full-stack developer to help with the whole team.
Eventually this generalist gains a good understanding of the full stack, as his title implies, and can contribute good ideas that affect all parts of the system. They also make good tech leads because they can interact and empathise with all members, and can call out decisions that may seem good on one part of the stack but could have horrible implications on the other end. Some progress to Architects simply because they have the bird's eye-view of the whole system.
Lastly, if you are a fledgling web startup, it would work against your business interests to hire an expensive specialist right away.
The difference in flexibility between having 4 backend and 3 frontend engineers on a team and having 2 backend 3 flex and 2 frontend engineers is a huge gain in what that team can commit to in any given period.
Find the entry point of the program then go from there. Use grep for function calls or event listeners. Get some background of the framework used, if there's any. Skim the issue tracker to add more perspective.
"I do not have experience due to which I cannot find a job and I cannot get a Job as I lack experience. Its like a dead-lock situation"
Nowadays, whenever a programmer says this a cat dies in the other side of the world. We developers are almost immune to this, because we have what we call open source software and free cloud services doing very specialized tasks. What I mean to say is that if experience is your problem, you should be glad to know that there are ways to gain experience without a job. This is quite easy to do in our field - contribute to open source, do some personal projects for portfolio, or even help out some startup in need of manpower. All these things can be done right now, and reaching out to HN is a good start. Relax, my friend. Just head out and continue on, say, the Python web development path, and pretty soon you will find some arrangement or gig that will get the wheels rolling for you.
The scientific community will disagree with this. The whole culture of independent peer review process assumes there is no centralized control over scientific conclusions, whose rigor stems from decentralized feedback. The time when centralized database (source of truth) became the basis of mainstream science was during the dark ages.