Cowboy development and toxic management processes
I don't mind sometimes being that guy who swoops in and fixes some issue to look like today's hero - Every developer needs that opportunity. I think it's important to maintain some level of composure throughout this process, however, and workplace/QA processes should still be adhered to no matter how dire the situation is that you're trying to fix. Taking the time to do things right is imperative to organisational stability and developer behaviour - Why should others respect you if you don't respect your work?
You hear the term cowboy a lot in development (well at least I do) these days, but the meaning isn't so well understood I feel. It's not simply someone who has no boundaries, pride in their work or quality standards, but it's also about their behaviour and how they interact with the company they work for.
Cowboy developers, as I've come to learn, want to be seen as a hero having done as little work as possible. They'll do enough to get recognition in the areas they feel are easiest to achieve in (grab the low-hanging fruit, right?). This work will usually come at the cost of having poor quality code (untested, unreviewed and maybe even copy-pasted without edit from Google/StackOverflow) and will be hastily left for other developers to maintain (or rewrite, if they're smart).
Sounds bad, right? It is.. It's bad because if what it does to others that are trying to work as a team for the good of the company in the long term. Cowboy developers focus on short-term wins, which will often do some monetary good, but will cost the company in efficiency and manpower (developers leaving etc.) later. Moreover these people will usually kiss-ass their way into the laps of upper management to secure their ear.
Management shouldn't be seen as an evil entity here - They have a very important role to play in being the other side of the coin to engineering. What I'm describing is a failure in management where the system no longer works as it should, possibly due to a handful or even a single individual. When management discuss work with engineering, there is usually some back-and-forth until an agreement is made in the way of work (tasks) and some kind of a deadline. When management don't like the proposed workload or deadline set out by engineering, having someone like our dear cowboy whispering what they want to hear might be enough to completely bypass the engineering teams and processes to have the work done at a much faster pace.
So, you hire some developers - back-end and front-end teams with a few guys manning the QA station. Then you throw in some Dev-Ops people to manage the stack and there you have it: a working engineering force to be reckoned with. How many cowboys does it take to bypass this expensive but necessary mass? Just one.
So some rough work is done and put in to production by someone that gives not a single shit about their code quality - not a big deal right? Except that in 5 months their work no longer functions correctly and those front-end/back-end engineers have no idea how to maintain the project. Instead of learning from this repetitive occurrence, management decides to once again assign their loyal brute to the task.
It's this symbiosis of bullshit between the cowboy coder and management that makes for such a toxic atmosphere. Not only is no one learning from their mistakes, engineering is unable to function effectively as they don't have the correct channels of communication and persuasion that is necessary. Good developers will leave of their own accord in situations like this, leaving the company in a cycle of dependency on cowboys and their substandard work.
The remedy? Don't hire them in the first place. Get yourself into a good position where you have some say in job interviews for new recruits and ensure that you weed out the heros. If you already have one working in your company then I can definitely recommend not being aggressive or vitriolic - stick to your values and explain yourself clearly and calmly whenever necessary, and don't settle for inferior options. A drive for quality is a respectable attribute and you'll find that it benefits you in the long run. Whether or not your company decides to follow-suit is on them.