Specifics: Kubernetes and Docker are tools you'll use when you need them. You can find yourself a tutorial on these, go though it, and have a sense on what you

Specifics: Kubernetes and Docker are tools you'll use when you need them. You can find yourself a tutorial on these, go though it, and have a sense on what you can use them for. For example, we use Docker images to spin up Jupyter notebook servers with the most common dependencies for our users, plus other components that add features like notebook scheduling, and live collaboration. It would be hard for users to set that up thelselves. Think of it as a way to package and deliver value without the fuss. How to write better code: - Read good code: clone repositories of proven software that you use, and read from it from time to time. - Curiosity: when you use software, you may encounter functionality and wonder about it. If you have the code for that software, you can look how it was implemented and architected. Doing a git blame and finding the first commit where something was introduced is educational. You can then advance commit by commit to see how it played out. - Vocabulary: sometimes you don't know something and you can't even look it up because you don't know the word for it. For example, there are concepts like 'message passing' or 'multiple dispatch' that I have pondered on for quite some time before knowing what they were called. I was trying to formulate a search query to find what that way of coding was. The same thing happened to me when I wanted to learn how to think better and improve my cognition. I had tormented myself thinking 'is there a field from which I can learn to think about my own thinking. Cognition on my cognition'. I felt stupid when I stumbled upon it and found it was simply called 'metacognition'. Sometimes I was luckier. For instance, after observing how some software can add new functionality from pieces created by third parties, I knew I wanted to learn how to do that. When I was a child, I found it really cool that you could make a Winamp skin, and Winamp would transform to that skin even though the Winamp folks ignore everything about your existence. They didn't need to integrate your skin. I found that to be really powerful. I had the docs for win32api, and found it amazing I could use it to access system functionality, etc. When I wanted to transform a Doc to PDF, I installed an extension and Microsoft Word knew where to display it and what to do with it. Same with applications. The underlying themes are APIs, extensibility. The materializations are plugins, extensions and applications. The supporting principles are good abstractions, and open/closed principle, dynamic loading, and interfaces. It helps to structure the thought into 'themes'. Extensibility theme, for example. And then categories, like a plugin architecture. Keep those and link new things you learn to those themes. These compound and find their way in your new software. - Write the documentation or the use guide first. A description of how your yet to exist software is used. You write 'X does this, here is how you use it'. If everything were possible, what would the usage be ? How would a user interact with it. Write it, then code the simplest version that does the job. - Don't be unproductively hard on yourself. Pick any amazingly successful software and do a 'git log --reverse' to see the first commits on top. Ad augusta per angusta.