I was rather shocked after reading all that advice on writing style to get a reply that began with
Thank you for reaching out …
“Reaching out,” “going forward,” “moving forward” … these are trite and trendy and antithetical to clean writing. They’re like “stories” and “refactoring” in Agile Newspeak; the former is insulting and the latter has no clearly defined meaning.
I could see “reaching out” if the topic was a school counselor “reaching out” to a bullied student but in a pursuit that pretends to be engineering it’s nauseating. Please change that to
“story” has a well-defined meaning in agile methodologies, at least as much as “use case” does. As for “reaching out”, welcome to the world of business-speak.
I meant that “refactoring” is ill-defined; I know what “stories” means and find it to be humiliating, bringing to mind kindergarten and milk & cookies. Longer though it is I preferred “user scenarios.”
I don’t care for the methodologies, I see them as little more than rituals that add little or no value. I can understand how junior developers need more structure but for me a meeting is an interruption and, well, my introduction to this crap turned my 30-minute commute into a 90-minute commute for the privilege of listening to people sigh that they were working on the same thing as yesterday.
As for “contact” I am 66 years old, have always been passionate about precision in expression, and I don’t remember what you claim. Though I do remember when “target” was a noun.
Looks like my bit about “contact” got lost in a cut&paste accident, sorry.
As for methodologies, if you’re not using one at all, then you’re just relying on oral tradition to gather a loose consensus about what you think the customer might want and where you’re at implementing them and what may or may not be in the way, and so on … Group intuition is no way to run a project. Certainly there are those who take things too far – they’re usually the ones who put “Scrum Master” on their resume – but it’s hardly an indictment of process itself. Making you drive in to the standup meetings instead of calling in is ridiculous, but again it sounds like a culture problem at the company.
I wasn’t a fan of “story” either, but neither am I a fan of the clinical terminology where I feel like I have to be wearing a suit and tie and presenting four-color glossies to the customer. I’m currently working on a project where the customer is insisting on a detailed Requirements Specification before the product is even fully designed. It’s insane.
I’m guessing you’re not too keen on “sprint” or “epic” either
I’ve been a developer since 1988 and the great majority of that time have worked solo. Before 1992 I had shipped two Microsoft products that I wrote singlehandedly. When I do work on teams the divisions are very high, e.g. I do the entire backend and work with front-end developers and graphic designers.
As for what the customer wants, this is one area I claim some skill. Even at companies in the software business the designs are always more vague than the customer realizes and I ask a lot of questions about workflow and edge cases; I am also a technical writer and I write a specification and obtain concurrence before I write code.
One big justification for the methodologies is that we used to write a lot of unneeded code. I have zero experience with this. Yeah once I added a case-insensitive parameter to a cryptographic string compare but that’s the only one I can think of.
Anyway all this is moot; I live in Vietnam, I will never work onsite again and it’s even possible my career is drawing to a close.
And by the way I did ask that the “morning standup” be changed to a time that didn’t have me inching to work in rush hour traffic and they got frosty with me; “it’s a morning standup.” Uh, we don’t stand up. (daggers).
I remember single-occupancy offices, one brief meeting per week, email status updates. I remember when everyone from a QA hire to the CEO had done code, And I remember stock options and signing bonuses. I love the work but the industry has gone very sour.
Sounds to me like you had plenty of methodology, just not the terminology. When you’re working solo, process is just something you internalize. When you have a team, no one gets to be that lucky. But yes, it’s annoying watching best practices getting reinvented and renamed every decade or so (I’ve been programming professionally since 1995). I guess it’s a consequence of an industry with so much churn in both the technologies and practitioners.
Judging by the size and output of the industry, I’d say it’s doing just fine despite the glut of amateur developers playing at engineering. I doubt you’d have a decent web browser or the forum software to post this on if we had to rely on IBM or Accenture to deliver them for us.
My degree is in mathematics and even before university I was interested in math history; it’s almost a stereotype that coming up with new names for non-new concepts is indicative of fraud. You can call it a “story” if it makes you feel up-to-the-minute (happy to see we agree on that) but it’s still a user scenario.
The one that ended it for me was pair programming. I had three hours of it two days after my father’s funeral and I quit my Microsoft job the following morning. Eleven years later I went into counseling to overcome the PTSD it left me with. Pair programming is so diametrically opposite the Flow that enabled Microsoft’s long-vanished greatness that I decided to retire at 56 but I got bored and learned iOS to freelance.
Were I still in the USA and interviewing and the interviewer mentioned PP in any context other than “we don’t do that shit here” I would walk out without a backward glance or even the most perfunctory courtesy. Nothing speaks more clearly to how badly the SD workplace has decayed.
If you had told me back in 1988 that code was still going to be as illegible in 2020 as it was then I would have scoffed. And if you had told me about Xtreme I would have thought you were nuts.
Microsoft understood about Flow but then it went from a software business to a business business and by 1994 all that recognition was gone.
I’ve noticed pair programming has drastically fallen out of fashion these days, to the point where no one even casually mentions it anymore. I can’t say I miss it: I really do love bouncing ideas off someone in a live setting, but being forced to do it is the coding equivalent of running in a three-legged-race.
I still maintain it’s the big consulting shops that are the biggest fraud factories. The joke is that Accenture doesn’t sell solutions, they sell binders that come with software as an option.
I will not accept a gig where the customer wants me to work without a spec. I write requirements docs; that’s the beginning of the design. That’s the bare minimum. And one of the dumbest things in the methodologies is the deprecation of documents. Though when it comes to Dumbness Singularities, only pair programming beats TDD.
I guess we’ll have to agree to disagree on the formal requirements, uh, requirement. The main symptom of waterfall-methodology projects having trouble is total silence followed by project cancellation, because no one dared to pull the rope lest they have to alter The Holy Gantt Chart.
That’s good to hear. One of my former managers had his entire senior dev team come to his office as a delegation to say that if the pair programming continued they were all quitting.
The junior devs, lacking that kind of leverage, had to continue doing it and several of them ended up in therapy. Learned helplessness.
I never heard of waterfall back when people were doing it.
I like to write, it’s effortless and it is enormously helpful to me in clarifying the design. It’s time as well-spent as practicing scales on my guitars. I can write anything from requirements through functionals to user manuals and even regulatory submissions.
Few developers like to write documents; fewer still can write clearly and thoroughly. I’ve worked with medical devices and wrote submissions to the FDA that saved the company millions by being accepted on first submission.
I too extol the virtues of clear, precise communication, which is why I’d love to hear the full stories behind your clear experience with the cataclysmic outcomes of the modern software development practices. I’m certainly curious as to how pair programming leads to therapy and participants necessarily have learned helplessness. I don’t particularly like pair programming so it would be nice to be able to explain why it’s dangerous.
Full disclosure: Microsoft made me do pair programming so I would resign, and it worked. My father had just died and they figured that the additional stress of working hip-to-hip with a condescending lickspittle corp-freak whom I could not stand would push me over the edge. It did.
Weeks later I learned what was really going on; Microsoft had its very first layoffs ever and they wanted as many as possible to quit because firing is problematical and if they announced a lower layoff number it wouldn’t look as bad. Since then of course they have laid off all the SDETs (“Satya’s Vision”) and switched to that TDD horseshit.
First of all it is impossible to concentrate with someone in sexual proximity whining about every keystroke; I wanted privacy as badly as a man lost in the desert wants water. When the lickspittle walked into my office the next morning I threatened to eject him not gently, went to my manager’s office, took his scissors from his pencil cup and cut my cardkey in half.
A decade later I was still having panic attacks at the memory. I got counseling; they are over.
It definitely seems like pair programming does not work for you, and I too find it hard to focus while pair programming. I’m sorry it was that rough on you.
However, I was asking about you mentioning that pair programming put junior devs you know into therapy and gave them learned helplessness. If pair programming necessarily puts junior developers in therapy and makes them helpless, that should be more widely discussed as that’s very dangerous.
Simply, you are forced to work closer to the other person than most spouses sleep together. I found it excruciatingly uncomfortable. The Uncle Bobs will tell you that PP should have consensus, people who work comfortably together; in real life you are ordered to do it and to refuse is insubordinate. I had never heard of it but if I had known I would have refused. I had already decided from conversations about unit tests and TDD that my manager was a lunatic and was planning on quitting anyway; that project was about done, I had met my next manager and, well, no goddamn way I was working for him.
Let me put it this way: I’ve been in three very bad auto accidents, in two of them I came within a centimeter of being dead or quadriplegic, and I go for years at a time without thinking of them. Until I got counseling the memory of those three hours of PP haunted my waking and sleeping life.
I totally agree with you that pair programming is uncomfortable.
I also agree that managers that encourage or require developers to skip unit testing (or any other comprehensive test harness) are irresponsible. To put it mathematically, if it isn’t proven valid, then it’s not useful, for math or code.
But it doesn’t sound like you don’t have specific stories of other developers having to go to therapy specifically because of pair programming. Or stories explaining how learned helplessness is a necessary outcome of pair programming?
I totally understand that pair programming does not work well for you, and I agree that it does not work well for me either.
It’s just that you said:
which, based on the literal meaning of your words, says that you had stories of other developers requiring therapy as a direct result of pair programming, so I just wanted the story behind that statement.
I know exactly what learned helpless is. You just added the two words ‘learned helplessness’ after talking about other developers needing therapy because of pair programming without any explanation, so I thought that there had to be some connection that you had forgotten to explain.
I don’t believe that I have seen in any discussion about test driven design or unit tests a requirement that a development team not have QA. Having a manager insist that unit testing means that developers are solely responsible for testing their code is indeed quite psychotic.
I am rather surprised that you can write code for six straight weeks without writing a single test and you can generate completely flawless code. For most developers, that’s far beyond our human capabilities.
Personally, I am a huge fan of the mantra that untested code is broken code. I work on a geographically dispersed team with a wide range of skills and areas of expertise, so tests help us coordinate our development, help provide examples of our APIs, and help prevent regression when we reogranize our code for maintainability and performance while retaining consistent behavior (some people call this process ‘refactoring’). A corner case always falls through the cracks when we rush and skip adding tests.
This goes back to at least the 90s. There are two schools of thought: One, people hate nonsense. Two, people’s brains are a mush of associations and so doing whatever you can to make an interaction have the right feeling is a significant factor in manipulating people. Advertisers, lawyers, and politicians follow the latter. The classic statement “It’s not what you say but how you say it” also leans in one of these directions. I’m not sure of the weight of evidence in actual formal psycholinguistics, but it seems like at least a moderately difficult field to study (e.g., how to quantify people’s pre-communication disposition and biases and then correct for those while communicating).
That said, you (or anyone) may personally disagree. But that also means little scientifically because the concern is manipulating the greatest number of people, not any one individual (plural of anecdote is not data).
