Versed in everything startup. I'm a Problem Solver, dealing with a few different languages and a few different scenarios. I'd say mainly front-end based.
Also done many side projects in various things from sublime text plugins to apps to machine learning.
Always open to new opportunities and interesting tihngs.
First of all, welcome!! This is not stackoverflow. The hashnode community is a lot more welcoming in my opinion. You can post code, comments, questions, start discussions, talk with people about problems. The list goes on. The only thing I would suggest is just search hashnode to see if a similar question has been asked first before posting your own and ensure it's well formatted. Hashnode uses markdown and have helpful guides on it. So again, welcome. Post away. https://daringfireball.net/projects/markdown/
Don't use pusher :P. Setup a https://deepstream.io/ server and run it all yourself. You could just setup a pub / sub on both sides. Either that or use a different method of communication channel between entities. What's the use case?
This is a high level of the branching strategy the company I work at and I utilise: There are story branches which are basically features and the branch looks like this: story/{PROJECT_INITIALS}-{ISSUE_NUMBER}-{ISSUE_NAME} . So using My Awesome Project and issue or ticket number 134 (jira, gitlab, github, notepad) and the name could be Create landing page: story/MAP-134-create_landing_page . Then this story gets split into smaller sub-tasks which are as trivial as possible. So, following the same convention as above, a sub-task would look like this: sub-task/MAP-135-create_navbar_item . Defects would look like this: defect/MAP-136-fix_padding_on_nav_items . master/ is the release branch. story/ and defect/ branches come off master. sub-task/ branches only come off story/ branches.
I disagree with your assessment of Agile. I've not read the book you've stated, however I know that I spend none of my time waiting around. I'm either spending my time writing code, reviewing code, creating documentation, refining user and / or customer requirements through meetings and speaking with the client, the PM or other members of the development team. I know some people would argue that being in meetings is not developing the product but it is. Creating that shared understanding, within the team, of the expected behaviour for a certain feature drives out assumptions and ambiguity. Couple that with a proper review process then the product ends up with less defects. I would argue that the way in which Agile is being implemented seriously affects the understanding of the Agile process and the outcome of the product and most importantly the quality of the product. Working this way round also reduces uncertainty thus allowing the development team to more accurately estimate the time it would take for a given task. Specifically, using Scrum Poker on a Fibonacci scale more accurately accounts potential risks in the estimation that are inherent with larger tasks. If the project gets to the point where the development team is missing things close to the deadline then I would argue that the development process is wrong or broken somewhere. Obviously, there may be small things that could be missed - as is the way of nature. But its not a question of graphs, it's a question of why wasn't this kind of stuff raised earlier in development. All of this can be done using many issue trackers. I have personally used Jira, GitLab, Trello. They all work well when coupled with a good Agile process, utilising BDD and embedding Quality critical thinking at each point of the process and most importantly communicating with the client. I must admit though, the feature progress section Zepel have built looks quite nice. I've not seen that too often in project management tools.