This is my thinking also... it came to me over a long time, and typically has a lot to do with why I switch jobs. At a certain point i give up struggling against the 'WTF' and just start going along with the flow, then one day i look at the stuff i am doing, realize working at the place is making me a worse professional, and move along...
However I do want to note that in general these things do have real concrete negative impacts on the bottomline of the organization.
> However I do want to note that in general these things do have real concrete negative impacts on the bottomline of the organization.
Oh absolutely. But your duty to that organization is to raise these issues to the person best-equipped to see the bigger picture, and to do your best to convince him it's a real problem. Once you've done that, your work is done, you have just done more to help your organization than 100 blog posts would have accomplished, and more than 90% of the other employees would have ever done.
You can comfortably use this approach once a month and be vastly more effective than everybody else at your company at bringing about change. Simply raise an issue, have a conversation about it, then drop it if you get no support.
Exactly. It also works as a meta principle. If you raise issues without them going anywhere, that in itself is an issue worth raising. Sometimes it means going to the manager's manager, but it does work. And if it doesn't work that's an excellent exit cue.
To expand a little, I don't think the point of having a positive effect on the WTF parts of an organization has anything to do with my effect relative to other employees.
If I see a WTF security or ops practice, I don't sleep better at night by telling myself, "Welp, I noticed it and said something to someone, and that's a lot more than most people do."
Maybe I think of my job too broadly, but my job as a developer is, at least in part, to protect the business, to find the WTFs and get them sorted out.
The idea that IT is just there to solve the "business problems" and they should shut up about anything that isn't directly related to making money is absurd to begin with. But even if I'm being completely naive about that, it still implies a really shallow understanding of "business problem."
Security is a business problem. Stupid ops habits that result in downtime are a business problem. Groupthink that results in acceptance of worst practices is a business problem. All the whatthefuckery the article talks about boils down to business problems. Many of these problems are such that the people primarily concerned with running the business are not in a position to recognize as problems.
It absolutely is my job and every developer's job to find these things and take care of them.
If I ever found my self in a situation where I saw some WTFs going on and I went to my boss or a coworker and got no explanation other than 'This is how we've always done it.' I would be concerned. I would go back to my desk and finish what I was supposed to be working on. Then I would go home that evening and write out the clearest and most concise explanation of why this is a serious business problem with citations and take it back to the coworker or boss.
In my experience, the WTFs don't usually come from this is how we've always done it. They had some reason back at some point in the past where someone really needed it to be that way for some reason, and usually temporarily.
Here's an example from several jobs ago, one of my first in the industry, actually:
Why does this set of boxes still have password auth enabled? Why isn't it locked down to ssh key only? Why is port 22 accessible outside of the VPN?
Oh, it's because our CEO likes to get his hands dirty with code every once in a while, but he didn't want to mess with pub/private keys, so we just left it open because these boxes weren't that important. They were 'just' dev machines pointed at test DBs with no real data in them.
But it got written into a setup script or Wiki somewhere, and when those dev boxes got repurposed for production, people followed the scripts or rules or whatever that were specific to those machines. So now you have prod machines running with password access with SSH exposed to the public. Ones that are pointed at live DB servers with creds for them.
That's a serious WTF.
I'm not even close to a security expert of any kind. I wouldn't claim to be in a million years. I work with databases and Python, almost exclusively. Though I dabble in DevOps when I need/want to. Even I know that the above is a serious WTF.
What did it take to get that fixed after my coworkers said, "Yeah, that's how it is."?
Going straight to my boss, who also said, "Yeah, that's how it is."
Then spending maybe an hour of my time writing up how much of a business problem this is and going back to my boss, who said, "Yeah, I know it's a problem, but I don't even know why it's like that. It just is."
So then I ask him who he can think of who might know why that is. Oh, quelle suprise, his boss might know.
And indeed, his boss did know. But he had long since stopped trying to get the point across to the CEO who liked to dabble, so he just went with it. Here comes my very brief paper explaining why this is--you guessed it--a business problem. The CEO responded within a couple of hours requesting that someone come setup SSH keys on his computer and shut down the passwd auth and close port 22 on all prod machines immediately.
That's a lot more work than mentioning it to someone. But I think that it's my job to do that, even though I've never worked in DevOps or Security teams.
My work was absolutely not done when I asked a coworker about it once, and then asked my boss.
-----------------------------------------------
Edited to add:
Astute readers will note that there was a lot more WTF-ery going on than just auth and port exposure on prod. Like, for example, that the non-technical CEO who liked to dabble was doing so on a production box because he was not made aware that the boxes he was logging into to play with had been repurposed.
There was a lot of cascade in tracking down that one particular WTF, and many other WTFs were solved because of it.
At the time for that company, my job description was C# middleware for a web app. I maintain that it was absolutely part of my job to pursue that WTF to its endpoint, and that doing anything less would have been completely irresponsible.
Whether or not it's strictly within my job description, I think dealing with things like security vulnerabilities and poor operational practices definitely falls within my ethical duties as someone who claims to be a professional.
> However I do want to note that in general these things do have real concrete negative impacts on the bottomline of the organization.
Not true. Sometimes, things that have concrete negative impacts can BENEFIT organizations.
U.S. prisons are just one of many such examples of this. A concrete positive impact would be lower incarceration and re-offending rates. American prisons have the exact opposite effect. This leads to lots of "customers" in the form of prisoners and victims seeking a more abstract "sense of justice".
The American prison system is probably not the only industry with that kind of business model. There are, no doubt, many contexts where a "concrete negative impact" can be very good for the bottomline. It's also an important lesson about making money in general. It's not about creating value. It's about making others pay for your actions regardless of whether or not said actions are "positive".
> Sometimes, things that have concrete negative impacts can BENEFIT organizations.
That's a very good point too. If you wander, unaware, into a quest to change something with negative externalities on workers or the public at large but with a positive effect on the business, you'll find yourself suddenly in a minefield of opposition with a target painted on your back and no idea who you've just made enemies of. Tread very carefully.
If you are able to positively identify negative externalities that produce benefits for your company--benefits your company depends on--you shouldn't tread carefully. You should quit your job.
Classically if doing contract software work, bug-ridden software meant a secure maintenance contract for years to come.
Though when I got out of that sort of thing, I recall there being (relatively) new rules requiring a different entity to do the maintenance from the ones that created the software... but my understanding of FAR is basically non-existent, so I don't know.
There's a variety of things you can still do as a middle-tier or above engineer to try to change the situation. (Very junior engineers are advised to A: watch how the situation develops with those poor practices and learn and if ambitious B: find a mid-tier or above engineer to ally with for these matters. You lack the social capital on your own to do much.) In my experience, at least with my development style, writing unit tests is either a net time wash or for larger systems, a net time gain [1], so use them. Even if nobody else runs them, you still get a better system out of them, and you get to run them when somebody complains. You can use analysis tools on your own code. You can set up an instance of a build server even if nobody else has one, and have it monitor your unit tests and other tools and fix things as others hack on your code. Etc. etc.
There's two basic outcomes that can happen here. Either you become a leader, and gradually and often quite begrudgingly at first, people start following when they see how well it works. (Unit tests can be a real eye opener sometimes, especially when you start having reasonable cause to show how the problem is unlikely in your code, being either in the other code or the specifications.) Or you get quashed from above. Contrary to the cynical answer, the latter is not inevitable, but it is certainly a possible outcome. At that point, yeah, it's just time to say you got some valuable experience and move on.
What you MUST NOT do is simply whine... from the point of view of those above, anyhow. Even if it's perfectly sensible complaints from your point of view that are all but objectively correct, it's unlikely to be heard as anything but whining. You need to lead by example. You also very much need to do so with some idea of cost/benefits analysis; you can't go from no discipline at all to a perfectly disciplined project in one step, so consider your steps carefully. Keep them small; stay away from "big rewrites". (Probably the biggest failure case I've seen is someone who thinks that code X is in the wrong paradigm and sets out to entirely rewrite it to make it "better". YMMV but in my personal experience this is usually someone who thinks the code needs to be OO, or a different kind of OO. This is guaranteed failure. Even at surprisingly small scales! You destroy everybody else's knowledge of the code.)
And I'll say it again to underline it... the cynical answer that this is impossible is wrong. It certainly won't be easy, but I can guarantee great growth as a developer if you follow this path, both technically and in dealing with people. Even if you have to change jobs.
As for the bottom line point, arguably you have a duty as a professional developer to be doing this stuff I describe, precisely because it does mean resources are being continuously and avoidably drained on issues that shouldn't exist. If you find yourself unable to discharge it, you should find somewhere you can.
[1]: I like to say that it lets me develop with monotonic forward progress. I even use unit tests during prototype work quite often, after I got sick of the way during prototyping I couldn't count on anything to work, ever, due to changes, and I realized that itself was actually inhibiting my prototyping ability. Sure, sometimes I dump entire subsystems but even then it was usually because the unit tests showed me a fundamental flaw far earlier than the rest of my prototyping would have, and I do so with far more information about the local landscape than I would otherwise have had.
Thanks for this. I have used somewhat similar approach and ended up writing bunch of testing tools for our app over a period. I can see its effectiveness as quite a few people in our team and outside started using them, or made their own copy and modified for their needs. Now I am better off as a developer but appreciation in term monetary compensation / promotion did not come through. However unlike others I do not have option to change jobs due to visa issues etc.
Well, sounds like you're doing your part, it's just the legal system screwing you up.
I wanted to tack on that while the "change jobs for de facto promotion" technique is solid and time tested, doing the sort of stuff I mentioned can help you climb faster. If you're planning on that career path, that's great skill development. You may still advance if you just clock time in before moving on, but you'll find you don't advance as far and that you seem to be getting the same job over and over. (At least, statistically.)
Best of luck with the visa issues. If nothing else, keep an eye on the long term. Development today may still pay off later.
(I mean, don't go crazy. I'm not big into unpaid work. But not all "eight hours" are created equal.)
This is absolutely true. However I just generally dont see the point in 'fighting' superiors... its not that its impossible to fight the system and make things right, its just not a good investment of an individual contributors time and effort. much better investment to move to an organization that is either already aligned with positive processes or actively seeking to improve processes.
However I do want to note that in general these things do have real concrete negative impacts on the bottomline of the organization.