This is a challenge I've seen as well. I was hoping that docker's file system would get smart enough about this so the problem would go away, but it hasn't happened yet. In the past, I've solved the situation using a combination of the following: Have the files included in the image. If the file rarely changes, you have it on a base image (or multi-stage build) to benefit from docker and buildkit's cache. Use rsync to move the files to the container or the volume (I launch a separate container with ssh server to receive the files, and have the volume shared between containers) A file watcher to run rsync when a file changed. I like this setup because it works locally, or if my docker containers are running on a VM or on a cloud VM (ssh+rsync magic FTW). Also, rsync is way faster than sending lots of files via the docker context. If you're running your application in Kubernetes, we recently open sourced a tool we build at my company to automate all of this: https://github.com/okteto/okteto.

I don't think there's a right or wrong way to be creative. What I love about apps like ShareChat or TikTok is that they are lower the bar so much that everyone can create content and express themselves. I believe that the web is better when more people can create, rather than just consume.

If your code is in Bitbucket, Bitbucket Pipelines is great. I like that it uses the same account and it's directly integrated in the same UI.

I'd start with a 3rd party site until it starts affecting you or your users. Your website's value is about the interaction and the experience of consuming those pictures, not in where the bytes are served from. Let the file hosting experts deal with that, so you can spend all of your time building amazing experiences for your users.

Mark "shipping your work" teaches you a specific set of skills that are very useful in the workplace (e.g. having a goal and deliver it vs polishing a piece of code forever). But it's one more data point. When I interview, there isn't a single thing that a developer has or hasn't done that will immediately disqualify her. It's all about assessing the candidate to see if both my team and her would benefit from working together.

Do you agree with asking a candidate to code live in front of you as a means to screen for hiring purposes? No, I'm really glad that this trend is slowly going away. Live coding is one of the most stressful things there are, and I don't think it truly helps to distinguish a good hire vs a bad hire. Second, asking algorithm questions only proves how good someone is at memorizing. 99% of us don't need any of these algorithms in our daily work. And if you do, you're only one web search away from a canonical implementation. I'm more interested to see if a candidate is good at figuring things out vs already knows everything. These days I prefer exercises where the candidate gets to solve a real problem my team has had, or it currentlyhas. For me, the key is to make the interviewee as comfortable as possible, so you can truly evaluate how the day to day is going to be like if you hire her. It's hard, and you need to develop a lot more skills as an interviewer, but I believe it yields better results.

when should I apply for a position? If you've been dabbling for a bit, and have learned enough to be able to build a simple web service or app, I'd start applying now. There's really nothing to lose. Worst case, the recruiters will look at your portfolio, will think you're too junior, and won't call you back. Best case, you'll get an interview and a job offer! Don't be afraid to apply for a position, most companies worth working for won't put you on a "blacklist" or something like that. What sort of projects should I create to form a portfolio. When looking at a candidate's portfolio (a github account is more than enough, you don't need something fancier). I always look for finished things. Libraries, services, websites (this is very oriented to back end development). I don't care for the complexity, or how unique the solution is, but I like to see developers who finish what they start. Focus on things you're curious on, tech you want to learn, or just to solve problems you yourself have (e.g. I once wrote a web service to tell me when my next bus was due).

Go and build a game! Want to write a Kernel? Just do so! Yes! With hashnode, stackoverflow, github and millions of open source projects, this is easier than ever. It might look daunting but it's so true. Just do so!

Yes, if it makes my job easier today. I prefer to fix that later, once the feature is removed. That being said, this is risky, and should only do if you have a mature level of control of your dependencies (you're using pinned dependencies, you are not automatically increasing to the next major version). Also, I'd do this for software I have full control of (an API, and internal service, etc...) and not for something that I'd give to my customers, like a library.

I've done something similar to this on python, and I didn't have a good experience with it. You end up with a LOT of logs, but with very little useful information (typically you care of where the error happened, not every other line of code that was run). Few things that help me a lot in the past, that you might find useful: A "action-id" of some sorts. This way, you can quickly grep for all the logs that were generated during the same action or request. I'd move most of the logs for class and method to a lower level, so you can filter them out by default when you're looking for an error. A dynamic way to change the level of the logs you're emitting. That way, you can have less logs by default, but you can always increase them when you want to analyze something, but without requiring a redeploy or process restart (that way it doesn't affect your current state)