The most important way is to use good naming. On top of this a lot of project management tools can assign tickets to branches, that way you can see for each ticket which branch it's related to.

It's not really encrypted, as much as it is encoded. Working from a hunch, the text looks like it's base64 encoded. The pure text chars, ending with a = is often a pretty good indicator (though it's not a given). Running it through a base 64 decoder turns it into a range of binary representations of bytes, groups of eight 0s and 1s. Running this through the first "binary to text" converter Google decided for me gave me a readable 1337 text string. So first, run it through a base 64 decoder (can be found online), then through a binary to text encoder (can be found online as well) and you have your answer. After that, read a bit up on the differences between encryption and encoding, base 64 and binary numbers; all for fun and profit :-)

Yeah, I run a blog on jesperjarlskov.dk both to share some of the ideas I have, things I learn and problems I solve, but also just as an archive for myself. There's a bunch of stuff you'll end up doing repeatedly, but not often enough that you can necessarily remember exactly how to do it; I'd put stuff like that on my blog as well, so I know exactly where to find it.

Yeah, senior developers probably have more experience writing code, that's what makes them senior to you. Take this as a possibility for learning directly from somebody who is better than you, it will speak up your learning process :-)

I guess it depends on what you're doing. It never hurts to have an understanding about what's going on behind the scenes. If you're purely doing 'look-and-feel' related frontend work likes design, css, accessibility, UX stuff like that it probably won't help you much in your daily work, but if you're also doing logic with JavaScript it'll be a great advantage for any moderately complex app, knowing at least some basics will help you make more maintainable and better performing code.

Thank you, here as well. We've just rebuilt our frontend layer in VueJS, it's works pretty well with our Laravel backend, though we still have a lot of work to do on improving the performance in the frontend. One thing I think is important to keep in mind when working with frontend performance is the difference between perceived performance and actual performance. The user doesn't care when the browser says a page is done loading, the user only cares when he or she things the page is done loading. It just have to be ready enough to be useful, then you can finish loading without the user knowing or caring.

I don't. But it's really awesome to solve actual problems that people have, and code is often a very good tool for that. Ie. automating boring or repetitive tasks can help people focus on what they're actually passionate about, and allowing people more time to focus on what they love is really awesome. Code is just a tool.

JS Frameworks at not a no-go, who told you that? Like any extra layer you should always consider whether you actually need a framework since it adds another layer of moving parts to your app, this means more code which means more to maintain, more that can potentially break, and more that needs to be sent to the client and executed (ie, worse performance). Your job as a developer (and architect?) is to weigh the benefits that framework brings to your project, against these cons and figure out whether frameworks are no-go. There is of course a cost to add a framework to your stack, but developers are pretty expensive as well and the point of the framework would usually be to save developer time.

For many reasons I believe it's bad practice to run anything these days, so that's not an issue :-) I've converted a few of my personal sites to HTTP/2 with great success, but this project has some larger requirements to availability, so I wanted to make sure I wasn't forcing anybody off the system by upgrading. But my host apparently doesn't support HTTP/2, since it's not available on CentOS 7, so that pretty much made the final decision for me, sadly :-(.

Thanks a lot. You've substantiated my understanding of how it would work, so I really appreciate that. HTTP push was mostly out of interest, we're not going to start looking into that yet, but I believe the reusable connections for fetching assets could be a nice bonus in our current setup. I've contacted our hosts to hear about our current options for upgrading :-)