Live data from Hacker News

The Dark Side Of Software Development That No One Talks About

simpleprogrammer.com

21–30 of 124 posts

Re: The Dark Side Of Software Development That No One Talks About

#21
post #16

If you work in software development for a decade or more in a corporate environment, you will encounter a surprising number of stakeholders who would like for the software project you're doing to fail, and will do everything they can get away with to make it fail. I did ERP implementations of Oracle ERP and SAP for many years, and saw this often. This can happen when the system you are replacing has the developer who…

I've seen a similar thing in projects that are in trouble: the relevant manager demotes the person responsible for the failure but leaves them on the project. Only your failure can validate their failure. In your examples, if their ERP software is being replaced, I suspect it's hard not to see it being declared a failure.

Another thing I've heard about what some called the "Procrustean bed" of SAP is that it can get terrifically resisted by stakeholders because it insists on rational business processes, and plenty of companies aren't run very rationally.

My family saw that while computerizing one doctor's office in 1980: after the data entry was done, the printer would just not stop in the first accounts receivable cycle. Turned out the office workers sent out a fixed number of bills per month (something like 200?), no matter how many actually needed to be sent. They didn't totally understand what was happening, but they knew "the computer would tell all".

Re: The Dark Side Of Software Development That No One Talks About

#22
One thing I wish this article talked about: Sometimes, people are brutally honest with little tact. If you're overly sensitive, you might think that such a person is being mean or being a jerk - but they have your best interests in mind, because they are telling you either a factual truth or an unvarnished personal opinion.

The reason why they are brusque is not because 'they have been abused' but because, the tolerance for bullshit is low - because of two things 1) they have seen bullshit bring down otherwise promising projects or ideas, and they don't want that to happen; 2) they percieve that varnishing your emotions or opinions with too much tact increases the cognitive load required by the recipient to 'get to the truth'.

Whether or not being brusque or diplomatic actually is effective is debatable. Nonetheless, I think missing this very important concept is generally bad.

In some fields, like science, having to deal with people who will trash your idea with honest commentary - that makes you think twice about what you are doing - is far, far, far better than having to deal with the silent judgement of a failed experiment that lets you down dispassionately, and wondering, "why didn't anyone care enough to tell me I was stupid to try this".

Re: The Dark Side Of Software Development That No One Talks About

#23
post #10

I have found that the more loudmouth and jerk-like the person is, the more they are covering up the realization that what they have/do is not all that unique, significant, or otherwise difficult yet rather comfortable and lucrative. Thus, they feel compelled to loud mouth barking and posturing to protect their bone. It's probably the same kind of mentality of a dog that snarls at his owner that just put down a bowl o…

I see what you mean but I doubt a dog would be able to realize any of that.

Re: The Dark Side Of Software Development That No One Talks About

#24
post #3

Agree with most of the points, but this certainly not some kind of secret that "no one talks about"...

Seems like you don't see as many blog posts or thought pieces about it as opposed to other cultural issues in the industry, like gender imbalances or "startup culture" minutiae.

Re: The Dark Side Of Software Development That No One Talks About

#25
As someone who manage people in the software world, who created his business from zero coding himself alone for years, I disagree.

I had to fight a lot indifference when I started, now it is the opposite problem, when I say something to people in my team, some of them smarter than me they believe it too much, like I was God or something. The same happens with your product, people trust your reputation.

"Jerk" is such a victim mentality word, in my opinion, when you want to create something that is new, people can't see it like you do. It is as simple as that. Now when you make it and success everybody says that from the first day they believed in you(not true) and after you make some repeated successes they continue not seeing it but they trust you.

The fact is that talking is cheap, and some new developer has no reputation at all, so you will have to prove with code that you can walk your talk.

Re: The Dark Side Of Software Development That No One Talks About

#26

Replace Software Development with any job and you are really on to something. People are mean and jerks are everywhere. Perhaps somehow society has convinced us otherwise, but there are a lot of terrible people out there. A lot of people do evil things, a lot of people hurt other people. This is not new and it's not a secret, people for whatever reason are more oblivious to it than they should be or perhaps people ar…

I tend to agree with the article... while people can be mean anywhere, seems like there's a certain confluence of characteristics and circumstances that allows "jerks" to have an outsize place in the tech industry.

But I suppose to look on the bright side, I'd rather have somebody be a jerk to my face, even if it is subtle and insidious, than have them pretend to be my buddy and then stab me in the back.

I'll take being surrounded by jerks over trying to navigate some of the intricately constructed, intensely political environments that are common in the business world.

Re: The Dark Side Of Software Development That No One Talks About

#27
I feel extremely lucky that I've never had to deal with developers like that. Of course, I just assume everyone is smarter than I am [a pretty safe assumption usually!]. I try not to get to attached "my way" and I genuinely care about and consider my colleagues viewpoints. Call it "ego-less programming" if you will. I generally work in situations where my teammates have complementary skill sets so perhaps that lack of overlap helps reduce potential conflicts.

I did have a bad boss once at my first programming job - back in 1987...

Re: The Dark Side Of Software Development That No One Talks About

#28

One thing I wish this article talked about: Sometimes, people are brutally honest with little tact. If you're overly sensitive, you might think that such a person is being mean or being a jerk - but they have your best interests in mind , because they are telling you either a factual truth or an unvarnished personal opinion. The reason why they are brusque is not because 'they have been abused' but because, the toler…

Wrong. Tact, compassion, and honesty are not in any way incompatible.

And no, people who think they are being "brutally honest" while forgetting compassion or even basic fucking manners are not doing so with others' best interests at heart.

They are just being assholes. There are bonafide reasons for that behavior, and they deserve a measure of compassion themselves while receiving that message, but don't try gilding the orifice's behavior.

Re: The Dark Side Of Software Development That No One Talks About

#29
post #28

One thing I wish this article talked about: Sometimes, people are brutally honest with little tact. If you're overly sensitive, you might think that such a person is being mean or being a jerk - but they have your best interests in mind , because they are telling you either a factual truth or an unvarnished personal opinion. The reason why they are brusque is not because 'they have been abused' but because, the toler…

Wrong. Tact, compassion, and honesty are not in any way incompatible. And no, people who think they are being "brutally honest" while forgetting compassion or even basic fucking manners are not doing so with others' best interests at heart. They are just being assholes. There are bonafide reasons for that behavior, and they deserve a measure of compassion themselves while receiving that message, but don't try gilding…

This.

Being "Brutally Honest" while combining that with tact is a rare communication skill that is an essential part of interacting in polite company. Having that skill and developing it has done more for the effectiveness of my teams than any other skill I have ever developed.

Re: The Dark Side Of Software Development That No One Talks About

#30
post #21
post #16

If you work in software development for a decade or more in a corporate environment, you will encounter a surprising number of stakeholders who would like for the software project you're doing to fail, and will do everything they can get away with to make it fail. I did ERP implementations of Oracle ERP and SAP for many years, and saw this often. This can happen when the system you are replacing has the developer who…

I've seen a similar thing in projects that are in trouble: the relevant manager demotes the person responsible for the failure but leaves them on the project. Only your failure can validate their failure. In your examples, if their ERP software is being replaced, I suspect it's hard not to see it being declared a failure. Another thing I've heard about what some called the "Procrustean bed" of SAP is that it can get…

Sounds like a dozen things I've seen! The people using a system can make that system fail if they want, and it happens so often. I wrote software for printing press operators that lined up what jobs they should do based in minimizing how many times they need to change ink colors in their presses, and other optimizing factors. They made the system fail hard, because they'd been printing for generations without a computer telling them what to do. So they'd tell the computer they had completed jobs when they hadn't, and when the job queue was empty, they'd proceed to print whatever they wanted. The chaos this caused with the data they then pointed to as an indication that the system does not work.

That and a dozen other things like it taught me the importance of making sure the users at the lowest level are really on board. If they want it to fail, you're better off solving that problem, because delivering a working system won't be enough: the people are part of the system.

I recognize that it's up to the managers to straighten these issues out, but they are people too, and often have their own agenda not perfectly aligned with the success of the project.

Post reply on HN