The Ten-Year-Old Tech Support/Developer/Project Manager



  • Today I got an email from our QA guy that he hadn't been trained in the complexities of one of the systems I maintain, and was thus unsure of how to proceed on testing a given issue. While a reasonable request, I smiled briefly, as this recalled a time in a past life where that would have been an unacceptable answer.

    Rewind to nearly a decade ago. At the time, I was about four or five months into my first job in IT, where I was being brought up to speed in the company's scheduling software package so that its primary developer (πŸ‘¨πŸ») could be freed up to work on other projects. It was a fairly complicated system that basically took user requests for given recurring event time slots and assigned users to those openings, hopefully fulfilling their first choices. For smaller clients, it was often easier for an admin user to manage the schedules by hand instead of entering hundreds of "preferences," so our system supported that mode of operation as well as bulk entry for larger customers. For purposes of simplicity and anonymization, we'll call them "micro entry" and "bulk entry" here.

    One day, the VP of the company (πŸ‘©πŸ½, who was also in sales) asked me if I could train a new customer on the system. She explained that this customer had an unusually complicated schedule for their small size and wanted to know what we had to offer. No worries, I had been given enough information by the other dev to feel comfortable walking them through the system. So, I set up a call per the VP's instructions with the scheduler, πŸ‘©πŸ» and their CFO, πŸ‘΅. I went through all the features the application had. The call went very well, and when it came time for questions, I got some interesting feedback:

    πŸ‘΅ (in a slightly frustrated voice) @Groaner, I wish someone had told us all this earlier that this is what the system is capable of. Nobody we have talked to thus far has been able to explain how to get anything done timely and easily.
    πŸ‘¨ I'm sorry to hear that*. I hope that today we were able to clear up any misunderstandings.
    πŸ‘©πŸ» Yes, thanks, @Groaner. I'll send you the details on our schedule so that it can be imported and we can use bulk entry to save ourselves quite a lot of time.
    πŸ‘¨ Thanks, I'll let you know once you've sent the data and I have a chance to look it over. Bye!

    *Now, you might be thinking that it's a massive red flag that the customer didn't have any idea of what the hell was going on prior to talking to me, one of the most junior employees at the company, and you'd be right. However, this sort of communication lapse was just another day at the office there. Due to years of technical debt with no plan to fix it, my coworkers had fallen from being intellectually curious to asking each other at the onset of each crisis, "Joe from Intertrode is calling me about XYZ. How do I get him off the phone?"

    Later that day, the CEO of our company (πŸ‘΄ , but with a different level of baldness, probably a Norwood 5V) stormed through the common area of the office (where all the tech support people sat) with an unpleasant look on his face, walked straight to the sales office, and slammed the door behind him to have a "sales meeting" with the VP.

    πŸ‘΄ WHAT THE FUCK DID YOU TELL πŸ‘΅? Why the hell is (mumbled indistinct screaming)?!
    πŸ‘©πŸ½ (mumbled indistinct protesting)
    πŸ‘΄ (mumbled indistinct screaming)
    πŸ‘©πŸ½ (more mumbled indistinct protesting)
    πŸ‘΄ (indistinct ranting about πŸ‘΅ and πŸ‘©πŸ»)

    A few minutes later, the door opens and I realize that it's now my turn!

    πŸ‘΄ @Groaner... (sputtering and screaming)... what the... why did you...
    πŸ‘¨ What are you talking about?
    πŸ‘΄ You told πŸ‘΅ to use bulk entry! You never do bulk entry on a customer that size! They need to use micro entry.
    πŸ‘¨ That was never explained to me.
    πŸ‘΄ (more sputtering)... You're smart... what did you get on your SAT?
    πŸ‘¨ (X Math, Y Verbal)
    πŸ‘΄ See? You're a genius. You should be able to figure out that you never use bulk entry on a small customer! It screws everything up!
    πŸ‘¨ I was asked to give πŸ‘΅ and πŸ‘©πŸ» training on the features our scheduling software is capable of. I walked them through the features implemented by the software.
    πŸ‘΄ Yeah, that's a bullshit excuse like my ten-year-old daughter would give for not knowing something.

    At this point, the primary developer πŸ‘¨πŸ» emerges from the developer cave to join the unwashed masses in the tech support area from which he had escaped months earlier to offer some words in my defense:

    πŸ‘¨πŸ» Uh, I should probably point out that this was @Groaner 's first time training a customer on that application, ever...
    πŸ‘΄ (sighing) Okay. From now on, for smaller customers, no bulk entry.
    πŸ‘¨ Okay.

    Over the next few weeks, I found out there were a few other important details he didn't tell me. He was trying to keep πŸ‘΅ out of the scheduling process by primarily working with πŸ‘©πŸ». Thing is, πŸ‘΅ smelled the ruse, which is why she was sitting in on the original call I had. πŸ‘΄ had to then butter up πŸ‘΅ by saying in a call, "Now, you're smart. You figured out my system for training and implementing, and you circumvented it."

    Unfortunately for us (but probably fortunate for the customer), within a few months, we lost them and in spite of a final attempt at sucking up, the CEO refunded their money. But it wasn't all a loss. It did make for a few laughs reminiscing between the VP and I several years after we left the company!



  • @Groaner said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    You should be able to figure out that you never use bulk entry on a small customer! It screws everything up!

    ...but... why? how? :wtf: ?


  • Dupa

    @sh_code said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    @Groaner said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    You should be able to figure out that you never use bulk entry on a small customer! It screws everything up!

    ...but... why? how? :wtf: ?

    Because then they want to enter in bulk, stupid! Gosh, that's a bullshit question that my 10-year old daughter would ask to cover up her screw-up!


  • β™Ώ (Parody)

    @Groaner said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    Today I got an email from our QA guy that he hadn't been trained in the complexities of one of the systems I maintain, and was thus unsure of how to proceed on testing a given issue. While a reasonable request, I smiled briefly, as this recalled a time in a past life where that would have been an unacceptable answer.

    What? What would have been an unacceptable answer? You've ruined the story for me! /blakey


  • :belt_onion:

    I'm still unclear. Which one of the people in the story is 10 years old?


  • Dupa

    @El_Heffe said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    I'm still unclear. Which one of the people in the story is 10 years old?

    No one. It's the story that's ten years old.


  • :belt_onion:

    @kt_ said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    @El_Heffe said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    I'm still unclear. Which one of the people in the story is 10 years old?

    No one. It's the story that's ten years old.

    Based on the title, I was expecting a story about a 10 year old manager.

    I am disappoint.



  • @El_Heffe said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    @kt_ said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    @El_Heffe said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    I'm still unclear. Which one of the people in the story is 10 years old?

    No one. It's the story that's ten years old.

    Based on the title, I was expecting a story about a 10 year old manager.

    I am disappoint.

    Well maybe it counts as a manager who behaves like a 10 year old?


  • :belt_onion:

    @Medinoc said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    @El_Heffe said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    @kt_ said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    @El_Heffe said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    I'm still unclear. Which one of the people in the story is 10 years old?

    No one. It's the story that's ten years old.

    Based on the title, I was expecting a story about a 10 year old manager.

    I am disappoint.

    Well maybe it counts as a manager who behaves like a 10 year old?

    That's . . . . 90% of all managers?



  • @El_Heffe said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    Which one of the people in the story is 10 years old?

    The president's CEO's daughter



  • @sh_code said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    @Groaner said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    You should be able to figure out that you never use bulk entry on a small customer! It screws everything up!

    ...but... why? how? :wtf: ?

    This particular CEO had a mantra he repeated ad nauseam: "The best programmers are business analysts first." While this might seem like an inspired sentiment on the surface, the problem is that those are two different skillsets, each of which takes years to master. Speaking of years, after one or two of them at this company, it becomes obvious that what was really meant by "business analysts" was "mind readers."

    Many of my stories to date have been about this place, and I have a couple more in the pipeline. If you pay attention, you'll probably see more of this pattern. Stay tuned!


  • Impossible Mission - B

    @Groaner said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    it becomes obvious that what was really meant by "business analysts" was "mind readers."

    Isn't that exactly what it means, in the context of software development? 🚎



  • @boomzilla said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    @Groaner said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    Today I got an email from our QA guy that he hadn't been trained in the complexities of one of the systems I maintain, and was thus unsure of how to proceed on testing a given issue. While a reasonable request, I smiled briefly, as this recalled a time in a past life where that would have been an unacceptable answer.

    What? What would have been an unacceptable answer? You've ruined the story for me! /blakey

    That's funny, I thought the antecedent (not being trained in software and thus asking for assistance) was clear enough. But not pedantic dickweed proof.



  • @El_Heffe said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    I'm still unclear. Which one of the people in the story is 10 years old?

    The title refers to the offensive insinuation that I was no better equipped to handle the situation than the CEO's 10-year-old daughter, while being expected to be tech support, a developer, and a project manager for a poorly-handled customer relationship without being told all the facts of the situation.


  • β™Ώ (Parody)

    @Groaner said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    That's funny, I thought the antecedent (not being trained in software and thus asking for assistance) was clear enough. But not pedantic dickweed proof.

    Maybe I'm having a blakey moment, but that still makes no sense to me in context. So I'm going to double down:

    Today I got an email from our QA guy that he hadn't been trained in the complexities of one of the systems I maintain, and was thus unsure of how to proceed on testing a given issue. While a reasonable request, I smiled briefly, as this recalled a time in a past life where that would have been an unacceptable answer.

    Request? What request? You never told us about any request. The guy told you he didn't know stuff. Did he ask you to teach him? Do his work for him? Was the brief smile the unacceptable answer?

    In what you wrote, you talk about a request and about an answer but you never said what either of them were.



  • @masonwheeler said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    @Groaner said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    it becomes obvious that what was really meant by "business analysts" was "mind readers."

    Isn't that exactly what it means, in the context of software development? 🚎

    It's one thing to extract requirements from tech-unsavvy users communicating in good faith. It's another to have to walk on eggshells to appease a manager that really isn't showing any leadership but expects you to clean up his mess his way, without being given any information to that effect.

    I'm rather proud of the fact that in three years at that shithole, I never really got mad at a client. It was always the company screwing over its employees and customers that pissed me off.



  • @boomzilla said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    Request? What request? You never told us about any request. The guy told you he didn't know stuff. Did he ask you to teach him? Do his work for him? Was the brief smile the unacceptable answer?

    In what you wrote, you talk about a request and about an answer but you never said what either of them were.

    Okay, that's fair. To clarify, basically, our QA guy was presented with a problem he alone could not solve, and he said that he wasn't "trained" on how to set up test cases.

    At this company, if you had said something like that as a reason or an excuse for not doing something (or knowing how to do something), you would have been told something like "look at the source code" if you were lucky, and would have been insulted in a manner like above if you weren't.

    Notwithstanding that the CEO of this company didn't believe in QA because at his last company, the devs were able to generate code faster than QA could keep up....


  • β™Ώ (Parody)

    @Groaner said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    At this company, if you had said something like that as a reason or an excuse for not doing something (or knowing how to do something), you would have been told something like "look at the source code" if you were lucky, and would have been insulted in a manner like above if you weren't.

    Ahhhh....so the request was for him to write some tests or whatever. And he was answering. That makes much more sense now.



  • @Groaner said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    This particular CEO had a mantra he repeated ad nauseam: "The best programmers are business analysts first." While this might seem like an inspired sentiment on the surface, the problem is that those are two different skillets, each of which takes years to master.

    Yet we have the same people coding embedded systems in C and doing business analysis.



  • @Groaner said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    two different skillets

    So what are you cooking on these skillets?



  • @Arantor said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    @Groaner said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    two different skillets

    So what are you cooking on these skillets?

    Some good requirements and some good code. Thing is, you have to keep them separate or else the flavor mixes the wrong way.


  • β™Ώ (Parody)

    @Groaner Obviously. You gotta save the good code for the terrible requirements.



  • @El_Heffe said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    @kt_ said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    @El_Heffe said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    I'm still unclear. Which one of the people in the story is 10 years old?

    No one. It's the story that's ten years old.

    Based on the title, I was expecting a story about a 10 year old manager.

    I am disappoint.

    So... it's the posters fault that you don't understand something my 10 year old daughter would know? I thought you had a high SAT score?



  • It occurs to me that I have a ten year old daughter (here's one I prepared earlier!). And yes, it's true that she would use "nobody told me that" as an excuse for not knowing something that she hadn't been told. Of course, so would I. I guess that means I too am no better at my job than a 10-year-old.

    Or is there perhaps more to my job than merely being able to divine the unknown through some flash of mystical inspiration? Huh, turns out there is. So I guess I'd better stop wasting time here and get back to it :)


  • :belt_onion:

    @Scarlet_Manuka said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    It occurs to me that I have a ten year old daughter (here's one I prepared earlier!). And yes, it's true that she would use "nobody told me that" as an excuse for not knowing something that she hadn't been told. Of course, so would I. I guess that means I too am no better at my job than a 10-year-old.

    Or is there perhaps more to my job than merely being able to divine the unknown through some flash of mystical inspiration? Huh, turns out there is. So I guess I'd better stop wasting time here and get back to it :)

    You know who wouldn't use that excuse?

    Someone omniscient



  • @Groaner said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    This particular CEO had a mantra he repeated ad nauseam: "The best programmers are business analysts first." While this might seem like an inspired sentiment on the surface, the problem is that those are two different skillsets, each of which takes years to master. Speaking of years, after one or two of them at this company, it becomes obvious that what was really meant by "business analysts" was "mind readers."

    The statement, as such, doesn't make very much sense, but if you consider what things a business analyst must know, specifically that magic stuff known as "problem domain expertise", it might make more sense, or at least less non-sense.

    Problem domain expertise means knowing about the things the end-users are going to do. If the system is an order management system for stock brokers, then it means knowing what it is that stock brokers do, what stocks are, how they are traded, and so on. You don't need to know it in enough detail to be a stock broker, but it helps to know what the words mean, so that you can ...

    Well, an anecdote is upon me...

    I was tasked with building (ok, finishing the building of) a specific type of trading report generator for a particular client. It was, to a certain extent, the "project from Hell", but I made life easier for myself. We arranged for the client to send some of their senior traders into our offices to talk to me about what they needed. They arrived and I told them that I would go through on this whiteboard here what I saw from the requirements and what it meant about what they did each day, and then throw it open to them to tell me what was right and what was wrong about what I had just said. They agreed that this sounded like a good plan, so off I went.

    They listened carefully, then explained a few things that they did not quite like what I had said, and a few that I had described as possibilities that in fact would never happen (and why they would never happen), and everyone was happy because:

    • I knew more about what I needed to do and to not do.
    • They knew that I had a good understanding of the task.
    • The sales guys who had helped arrange it knew that the client and I were both happy.

    I was able to do this because (and only because) I understood something of their work, of what it is that stock brokers do. So I say, as I have in the past said, that problem domain expertise and/or knowledge is the most valuable thing you, as a programmer, can acquire.



  • @Steve_The_Cynic said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    @Groaner said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    This particular CEO had a mantra he repeated ad nauseam: "The best programmers are business analysts first." While this might seem like an inspired sentiment on the surface, the problem is that those are two different skillsets, each of which takes years to master. Speaking of years, after one or two of them at this company, it becomes obvious that what was really meant by "business analysts" was "mind readers."

    The statement, as such, doesn't make very much sense, but if you consider what things a business analyst must know, specifically that magic stuff known as "problem domain expertise", it might make more sense, or at least less non-sense.

    Problem domain expertise means knowing about the things the end-users are going to do. If the system is an order management system for stock brokers, then it means knowing what it is that stock brokers do, what stocks are, how they are traded, and so on. You don't need to know it in enough detail to be a stock broker, but it helps to know what the words mean, so that you can ...

    Well, an anecdote is upon me...

    I was tasked with building (ok, finishing the building of) a specific type of trading report generator for a particular client. It was, to a certain extent, the "project from Hell", but I made life easier for myself. We arranged for the client to send some of their senior traders into our offices to talk to me about what they needed. They arrived and I told them that I would go through on this whiteboard here what I saw from the requirements and what it meant about what they did each day, and then throw it open to them to tell me what was right and what was wrong about what I had just said. They agreed that this sounded like a good plan, so off I went.

    They listened carefully, then explained a few things that they did not quite like what I had said, and a few that I had described as possibilities that in fact would never happen (and why they would never happen), and everyone was happy because:

    • I knew more about what I needed to do and to not do.
    • They knew that I had a good understanding of the task.
    • The sales guys who had helped arrange it knew that the client and I were both happy.

    I was able to do this because (and only because) I understood something of their work, of what it is that stock brokers do. So I say, as I have in the past said, that problem domain expertise and/or knowledge is the most valuable thing you, as a programmer, can acquire.

    Oh, yes, having domain knowledge is essential. There was plenty of domain knowledge among all of us at the company, particularly given the number of times the staff ended up advising customers on best practices (or outright doing the customers' jobs for them due to poor training coupled with less-than-stellar UI/UX).

    There was a lot of seagull management at this company, where people would come running over to the developers in a panic, drop problems in their laps with little supporting information and then run off in the hopes that we would magically clean things up. It got to the point that I made a sign slightly more polite than "stacktrace or gtfo" to at least get them thinking that not everything is a software problem, not everything was the developers' problem, and that we weren't magicians.

    And that is how an inspired-on-the-surface remark about business analysts turns into a worthless platitude.


  • Discourse touched me in a no-no place

    @Groaner said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    seagull management

    I like it! It's even well-known enough to be properly documented…


  • I survived the hour long Uno hand


  • Notification Spam Recipient

    @Groaner said in The Ten-Year-Old Tech Support/Developer/Project Manager:

    dickweed

    You know, Ii've always wanted to try that. On a scale of 1 to J, how do you rate the pleasure received from its usage?


Log in to reply