Somedays ago, while reading some random stuff about WordPress CI/CD pipelines, I came across the expression "cowboy coding" style. In the article, the author Alexa Green started talking about how she had spent her first WordPress development years in a “cowboy coding” style.
I laughed alone thinking about how I spent a lot of years in the same routine, making changes wildly on live projects, testing and firing them up with FTP, often with sitewide breaks all visible to the visitors. I am not exactly proud of it, but my journey in coding, as the many others developers journey, is not conventional. I was on physic college when started to code, and back then I wanted to become some great physicist and be the next Stephen Hawnking from my generation (which obviously did not happen). Coding was just a way to get some money to pay for lunch.
I learned as the need arose and as I got more complex projects, this became a wild routine with a cowboy coding style. In retrospect, I see that lot of mistakes I made could have been avoided if I had followed simple rules, rules by the way, I didn't even know existed back then.
Today I understand that we have to write code thinking not just about compilers, but about other programmers that may read this, especially if we are working in a remote distributed team. Specifically in the case of working with WordPress, there are standards we should follow. Agencies and companies use to have their own standards too, and either being part of a team or developing for the community, we must follow these standards, to read the guidelines, pay attention to the documentation, etc. But I also understand that in times of clean code, sometimes people get stuck, they just don't move forward trying to do things too perfectly.
That's when cowboy coding style can be interesting
"Cowboy coding is software development where programmers have autonomy over the development process. This includes control of the project's schedule, languages, algorithms, tools, frameworks and coding style. Typically, little to no coordination exists with other developers or stakeholders."
Of course this methodologie (if we even can call that a methodologie) may be indicative of a project's small size or experimental nature. But if you are starting in your coding journey I think you must try, and experiment with new things, and set up instances on AWS for example (just don't forget to pause these instances or you can get a not-great surprise on your credit card) anyway, do some coding without worriyng if it's it perfect.
The only thing I can say I know is that if we review some code we wrote like maybe a month ago, we always will want to refactor it. Being a developer, it's an endless learning journey.
I advocate that we try things, even if it means doing it in a cowboy coding style.
I'm the team
Sometimes, in a small project, we can't wait for the Q.A.'s approval, maybe doesn't even there's a Q.A. in the team. In an ideal world, all teams have a Q.A., but we do not live in an ideal world.
I worked for a long time as a full stack in a tiny e-commerce, where the QA were our users, proud of it? Not, but that was the reality I had to face.
We have always to keep in mind the famous quote:
There's no such thing as a silver bullet.
Everything depends on the needs of the project you are working on, and part of being a good developer also means being able to adjust to the reality you have.
What if?
I read some random guy complaining on Twitter (if I found it again I will edit and link here) about an idea he had ages ago that he even started to work on with some friends, but
they were so worried about beautiful and perfect code, that the product was never launched.
This is a very common history among developers, many of us already had brilliant ideas that were never launched, and that could be the subject of another huge article: "Side projects unfinished and millions of domains registered".
Now, this guy, like many others around there, wonders about what possibly could happen with his miracle idea. Would have worked? We will never know, besides being a crucial part, code is not the only thing to make a successful business, there are millions of variables to do it, but at least, he would know.
Done is better than perfect, if you wait for your code to be perfect, it will never be. It is exactly like waiting for the perfect conditions in real life. Try more, and finish things even if it means to be finished in a cowboy coding style, this article become more motivational than I thought, but I believe I showed my point.
And you? What do you think about it? Comment below!
P.S: While it is thrilling working on cowboy coding style I do not recommend doing it as your living way, it is an interesting approach for learners and in some very specific situations, but after some coding cowboy style season, it is safer to do things properly.
Top comments (1)
I can totally relate to the 'cowboy coding' style! It's amazing how we learn and grow from our unconventional coding experiences.