A very dear friend of mine is an AD(Active Directory) engineer(he also is responsible for designing and implementing their Azure infrastructure) that more or less runs the ENTIRE AD forest for a mid-sized Federal Agency. He is a pretty sharp guy, and often runs circles around Microsoft's own AD engineers..... We talk often, and once in a while he will hit me up after interviewing potential candidates for his team....and often the conversation ends up like this..... Eduardo : "Hey MB...….had interviews today......take a wild guess how it turned out?" Me: "is that so ? How many souls where taken by FizzBuzz(https://en.wikipedia.org/wiki/Fizz_buzz#Programming) today? Eduardo: "Bro....seriously ? You list all these awesome things you have done in an NT shop that you have done with Power$hell on your resume...but when I try to get into the weeds about those projects....or when I ask you 'tell me what you think this block of code does...'....well you know the rest" The above is the future....scratch that....the above is NOW. to be accurate....scripting out automation has ALWAYS been a thing...especially in the *nix world...….but now it is is pretty much inescapable if you plan on lording over the "IT enterprise" of your grandmother's laptop. I won't bother getting into the "whys" of it all. You guys pretty much can discern that all on your own, and it's really not the point of this post. I am a software engineer......I build systems that the government uses to basically aid them in the maintenance of our society. Dev/Ops and Software Development are increasing overlapping in some ways.....and as such...I am seeing "development" practices in the Dev/Ops community that makes me cringe(It's not their fault....they aren't Devs….and we all are noobs outside of our very narrow areas of expertise) So...with all that being said.....my advice: "Knowing Python is cool....but do you know how to write code that isn't complete garbage ?" 0. Learn how to write and verify algorithms....from there...pick a programming language...and then start implementing that algorithm in that language. When you start feeling really confident....start looking for coding challenges on the web, and learn what REST is. It's 2019 and no matter what niche you have decided to call your own in the general IT industry....please know that you will at some point will be targeting a network api…….and more often than not....it will be based on REST(https://en.wikipedia.org/wiki/Representational_state_transfer. Google has REST APIs that you can play with when you are ready. 1. Take some time to learn the significance of the data types and collections that are available to you and when to use them. 2. Always(if possible) to include the type annotations of the variables/values you declare in your code...this includes the declaration of function/method arguments. If your code is going into production....and is non-trivial...you want to be able to come back(or have a team member be able to) weeks/months/years later for maintenance or feature addition/enchancement, etc....and actually understand what the code is actually doing. 3. Learn what modularization/encapsulation is. Will this always be necessary ? No....especially if your script/program isn't particularly large....but once it does start getting over 100 lines....you will start noticing that it becomes less readable...and much more diffuclt to maintain. Modularization/Encapsulation mitigates this....greatly. 4. Learn other programming languages. Python isn't always going to be an available options for you....and even when it is....it isn't always the best tool to use. The following programming languages/environments are also commonly used for Dev/Ops(though I will concede that Python is likely the most popular language used for these purposes): - Groovy - Power$hell - Ruby -Golang 5. Learn Git.....No....seriously....learn it. At this point in the game.....not having a source code/documentation versioning regime is laughable and a sure portents of guaranteed future disaster....and NO......your current routine of saving different versions of your source code on your machine is NOT an adequate substitute. Trust me on this. Also.....remember that Git was meant to be used as a distributed source control application....meaning that you should treat it as such. Do not use GitHub or your internal git server as a central repo......for what should be obvious reasons.... 6. Git isn't just for source code. It's for documentation......docker files.....whatever you think you might need to keep track of versions for. Use it. 7. Make it a habit to implement unit testing..... Unit and Integration testing catches bugs before you discover that they even existed in the first place. I know...it's boring...and eats up time....but again...if your code base is no longer trivial.....or you know that it's going to be a fairly complex code base from the start....then just man-up and start testing out the gate. 8. Always come up with a design first...verify it's logic...and then code. ALWAYS. I have yet in all my years doing this seen code that was the product of an on-the-spot-hack that wasn't to some degree complete garbage. Software Development whether you are writing the next must-have mobile app or writing an automation script....is about developing algorithms that solve a specific problem reliably....in other words...come up with a plan first. Test it's logic.....and if it pans out...then you start implementing that solution in code. Do it write the first time. Well that's all I have for now......Let me know what you think. #Peace