Below is an amalgamation of link and concepts that may help you prepare for any mix of development and operations.
The easiest way to "learn what you need to learn" is to build a product. The first step in building a product is:
Solve a problem that someone actually has
Usually, you shouldn't solve a problem you think exists. You should use someone else to validate your product. This is great if you have a user before you start building, but this may not always be the case.
In most cases, you are creating something that someone will use to store data (CRUD application). Traditionally, software application replace existing manual processes. In this sense, the applicaiton you are creating is solving a new problem. In my opinion, social media applications and video games bend this rule because there are already existing games and social media applcations. My point is: if you choose to build something, make sure you understand your purpose; purpose is everything.
This means creating the minimum amount of work until that person is satisfied with your product. building a minimal application could take a few days or a few months (maybe even years!). The Lean Startup is one book that really tries to push the boundary of the Minimum Vaible Product. Why build a web application when you can build an email signup form and validate that people are interested in your product?
The paragraphs above detail the foundation of all product development. It is imporant to understand the above before you join a company or start building a product (I usually call this "Business Perspective"). You don't join a Software Company. You join a company that solves a problem with software.
- Find a product you to build
- Find the quickest way to ship your features
- Commit to a stack and finish the product
The foundation of your product will likely include a programming language. This language can be a pretty big investment depending on how serious you are about the longevity of the product. Given that you have experience with Java, it might be a good choice for whatever project you choose. Remember: spending time evaluating options is time not spent building a product.
After you pick a language, you may end up picking a framework to work with. Frameworks will help you specialize your programming language for particular use cases. Usually, these frameworks help you organize your source code and focus more on business logic and less on boilerplate.
- Understand the big three Cloud Providers (AWS (largest, widely used), Azure (probably next best), and GCP (Tied with Azure for most services, probably better at machine learning hardware)). You'll need to understand use cases before understanding each product offering.
- Knowledge of Containers is pretty much an industry standard at this point. Make sure you understand how to deploy containers to all three Cloud Providers. There are usually several options per cloud provider so make sure you understand every option. Usually, there is a tradeoff in price vs management.
- Function as a Service (sometimes referred to as "Serverless") is gaining traction and serves a good contrast to containers. Try to deploy the same function to all three Cloud Providers. You may find that some providers have a more mature offering than others. This is because the space is new and the patterns and tooling haven't really standardized.
This word can mean a lot of things but I usually think about it like this: running software for a month may lead to odd behavior
Most development happens in isolation of the real system running it. Make sure you understand what happens when you product lives longer than 30 minutes when you are developing locally. I have had some odd issues with my MushroomBot.
If you do end up deploying a service, set up monitors to understand if your application is healthy. Usually this includes:
- Is anyone using my application?
- What do customers do when they [go to my website || open my mobile app || open my desktop app || run my command line tool]?
- How do I know core business transactions are working? (can users add things to shopping carts? etc)
Making changes to your application is how you deliver value. You want to spend as much time writing code and less time in UIs. Make sure you take time to reflect on how much time you spend writing code vs how much time you spend deploying code vs how much time you spend testing code. TDD can help with writing reliable code that should save you debugging silly issues. Use a pipeline with quality testing to make sure you can deliver your code. Typically, this can be considered its own skillset but I think developers will have to learn more and more about the pipelines they use.