If you've ever worked in security operations you know, developing automation is critical to not just success, but survival. One of the hardest problems however, is developing software sustainably. Most operators [myself included] started out in the Perl and Python ecosystems. These languages enabled us to think like a programmer, without all the overhead of having to compile like a programmer.
As you develop more software one of two things happens, you release it to the world or it never sees the light of day. Often operators feel as if "they need it to be perfect" in order to release it, not realizing the simple rule of publishing: no one will use your code year one. You start out as a nobody, it takes time and effort to gain an audience, and even then.. your tools have to be readable and the problem space you're solving in, needs to be well understood.
No One Will Read Your Code
This fact should be liberating. No one will see your code on day one. This means you can practice in the open and improve your skills out in the open, where the subtle fear of people reading your code encourages you to put just that much more effort into it. That fear of a single comment "hey, you made a mistake", which rarely never happens, forces you to be just a little cleaner with your creation. These little changes ultimately add up into something beautiful others CAN AND WILL learn from in the future. Your code isn't for today, it's an investment in tomorrow next year.
Recently @DHH's (creator of Ruby on Rails) recorded a quick and dirty series On Writing Software Well. It was a refreshing observation by someone who cares deeply about the readability of their code. It's a living breathing thing that not only solves a problem, but also helps convey a learned lesson to those that read it. This is especially helpful for those where English may not be their native language.
I can almost always tell by the way someone writes code, whether or not they've published anything in the open by the readability of their code. If anyone has ever tried to read your code, they've asked you questions about it. Those questions force you to rethink your assumptions. As you re-read, you re-factor things a bit and because time has passed, you tend to grok the problem a little better. The better you understand a problem, the more simply you're able to solve it.
This isn't an argument for or against open-source. Simply that- those that have some experience in publishing some of their code more broadly and more important regularly, vastly outperform those that don't. They're used to solving smaller problems faster, taking the time to think through their solution and present it to a wider audience more elegantly than those that don't. They tend to only invest time in problems that actually exist, while investing less in problems that don't.
Practice with Open Source
If I send a pull request to two or three peers on my local team, I may take some liberties and be a little sloppy. It makes sense, because my global reputation is not at stake here. However, if I send a pull request to the ZeroMQ project, people all over the world will see it. I'll spend that much extra time carefully creating a simple, clean and readable patch that'll demonstrate my ability to the world. It's the sum of all my pull requests that makes me a better combat programmer, not any one in particular.
Every programming language has its special quirks. Things get interesting when you become moderately proficient in multiple languages. A sort of cross pollination of best practices from each language begins taking place and subtly increases the simplicity and elegance of your work. Frameworks like JetBrains has done an amazing job at accelerating this for programmers who don't sit in a single language all day. They build tools that help you not only jump fairly quickly between languages, but also build the "best practices" of that language directly into the IDE itself.
It's one thing to read a book and try to remember when/where to implement best practices, it's another to try implement what you've learned on the fly. For those of you who are stuck with Sublime or VIM, you're missing out. JetBrains is one of those tools where- it not only makes you a faster programmer, it makes you a better programmer in every language. Want your code to be PEP8 compliant? Want to learn the best way in Ruby to write a switch statement? Their IDE will flag your code if it "could be written more elegantly". You learn by programming on rails as you're solving problems.
It's one of those combat tools where you tell them- "Shut up and take my money!" The investment in your combat operations, not to mention your career will pay off in dividends down the road. You're code will be cleaner, easier to read, which enables more people to use it. The more people use it, the more they create feedback. The more feedback you receive, the more informed about a problem space you'll be.
The PyCharm community edition is a great first start. In a lot of cases it's "good enough" for most python users. If you really want to accelerate your operation, pour some gasoline on the fire and buy the all products pack. It'll be one of the best investments you've ever made in your operation and professional career. You can certainly do things the cheap way, or you can have some of the best programming AI in the world constantly scanning your code, as you write it- pushing you to be a better programmer.
