• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Working With Non-Technical People

SimpleTheater

Addicted to Fun and Learning
Forum Donor
Joined
Jun 6, 2019
Messages
927
Likes
1,789
Location
Woodstock, NY
This topic has nothing to do with audio, just a rant from work yesterday. We work off approved programming stories and over the last few months have been integrating some non-programmers who are quite knowledgeable of statistical evaluation. So they helped create a story and we are working on it. So they sent a group email (completely out of our bug testing protocol) saying they have attached changes to the story.

What? You changed the story?

So I set up a Zoom meeting to berate them and they told me they were bug testing and aren’t changing the story. Of course I replied you clearly stated the changed story was attached, to which they said they merely highlighted text in the story that wasn’t appearing in the interface, like a missing colon.

So it became a short lesson in language as I told them that the word “change” to a programmer means “change”, as in the story has changed. They actually did a good job highlighting very minor text errors that are hard to see, so I applaud them, but I told them to a) go through our bug testing software, not email and b) use the term “errors found”, not “we changed”

End of rant.
 

Katji

Major Contributor
Joined
Sep 26, 2017
Messages
2,990
Likes
2,273
My general problem was them/users phoning me instead of email. Eventually I came to understand why.

Non-technical, technical is the point of mental blocking determined by the individual/subject.
 

q3cpma

Major Contributor
Joined
May 22, 2019
Messages
3,060
Likes
4,416
Location
France
This topic has nothing to do with audio, just a rant from work yesterday. We work off approved programming stories and over the last few months have been integrating some non-programmers who are quite knowledgeable of statistical evaluation. So they helped create a story and we are working on it. So they sent a group email (completely out of our bug testing protocol) saying they have attached changes to the story.

What? You changed the story?

So I set up a Zoom meeting to berate them and they told me they were bug testing and aren’t changing the story. Of course I replied you clearly stated the changed story was attached, to which they said they merely highlighted text in the story that wasn’t appearing in the interface, like a missing colon.

So it became a short lesson in language as I told them that the word “change” to a programmer means “change”, as in the story has changed. They actually did a good job highlighting very minor text errors that are hard to see, so I applaud them, but I told them to a) go through our bug testing software, not email and b) use the term “errors found”, not “we changed”

End of rant.
Sincerly sorry, but I don't understand what you mean by "story". Do you mean program?
 

Katji

Major Contributor
Joined
Sep 26, 2017
Messages
2,990
Likes
2,273
Sincerly sorry, but I don't understand what you mean by "story". Do you mean program?
:) Maybe that is where the problem starts.

"approved programming stories "
Approved. Right. Then how long before they change the story? Which they had approved. ...Even if they signed a document, they will conspire and try to get an executive to override.
 

weasels

Senior Member
Joined
Jun 15, 2020
Messages
335
Likes
546
Location
Richmond, Virginia
Sincerly sorry, but I don't understand what you mean by "story". Do you mean program?

Pretty sure he's talking about agile development, which is broken into stories and epics, vs. traditional linear development. Agile is more focused on how the software is actually going to be used, so a story might be something like "As a statistician, I can change the coefficients of my models without needing to republish."
 

Katji

Major Contributor
Joined
Sep 26, 2017
Messages
2,990
Likes
2,273
Probably everyone has seen this sketch, but just in case not ...
Ok, I stopped at 1:33. I'm the guy with the blue shirt. When they talk abut drawing red lines in blue and green, I know it's actually insanity...then it depends on my mood - am I in the mood to do some role-playing or not.

PS: Refer to audiophiles. // Play the game.
 
OP
SimpleTheater

SimpleTheater

Addicted to Fun and Learning
Forum Donor
Joined
Jun 6, 2019
Messages
927
Likes
1,789
Location
Woodstock, NY
Pretty sure he's talking about agile development, which is broken into stories and epics, vs. traditional linear development. Agile is more focused on how the software is actually going to be used, so a story might be something like "As a statistician, I can change the coefficients of my models without needing to republish."
Yes, we're an agile shop.
 

sergeauckland

Major Contributor
Forum Donor
Joined
Mar 16, 2016
Messages
3,440
Likes
9,100
Location
Suffolk UK
Pretty sure he's talking about agile development, which is broken into stories and epics, vs. traditional linear development. Agile is more focused on how the software is actually going to be used, so a story might be something like "As a statistician, I can change the coefficients of my models without needing to republish."
This is as incomprehensible as the original post. What is agile development (swinging from trees?) Epics? Coefficients of models? It's a whole language I don't understand.

S.
 

q3cpma

Major Contributor
Joined
May 22, 2019
Messages
3,060
Likes
4,416
Location
France
Pretty sure he's talking about agile development, which is broken into stories and epics, vs. traditional linear development. Agile is more focused on how the software is actually going to be used, so a story might be something like "As a statistician, I can change the coefficients of my models without needing to republish."
Didn't know that. We're supposed to be "agile" too, where I work, but without the retarded fad part; since it's a startup, we just shift priority to the client most likely to sign and don't have time for unit testing or "programer vanity" refactoring (though I do some of both, because fuck it).

Since it's programmer rant time, today's was: fuck C++ for being statically typed but without a sane type system (cf ML) and for a million other reasons, and fuck Windows for not having any equivalent to POSIX flockfile.
 

Honken

Senior Member
Joined
Mar 10, 2020
Messages
339
Likes
602
Location
Scania
I think it'd be fairer to describe your colleagues as not developers rather than non-technical.

I've come across more dysfunctional agile teams than where the culture and idea has been cargo culted into a Kafka-esque nightmare, than my brain can handle.
 

thewas

Master Contributor
Forum Donor
Joined
Jan 15, 2020
Messages
6,741
Likes
16,175
This thread actually is a good example of how specialised "technical people" can be also the source of confusion when talking to people outside their field of expertise as they fail to translate to the "language" the other party understands. In German language there is the name "Fachidioten" for that, https://de.wikipedia.org/wiki/Fachidiot (best use Google or DeepL to translate it to English)
 

Katji

Major Contributor
Joined
Sep 26, 2017
Messages
2,990
Likes
2,273
I think it's a euphemism. The reality remains, unchanged, the problems remain, because the users are like audiophiles, and the newer generation that cae with these terms are like the Darkos and so on.
 

Koeitje

Major Contributor
Joined
Oct 10, 2019
Messages
2,292
Likes
3,880
Sincerly sorry, but I don't understand what you mean by "story". Do you mean program?
A story is basically a task. If you are working on a project (epics), stories are the smallest tasks you can split the project up in (its used in agile frameworks, but that doesn't really matter to understand the concept of a story). For example it could be to implement a user login as part of a new content management system.

I'm not a developer, but sometimes have contact with the developers about certain projects they are working on. What I have noticed is that both end-users and developers cannot really talk to each other. That's why you have product owners that responsible for projects. They do the translating. And if you do let end-users talk with developers it usually works best if one of the two parties understands the other side and can accommodate. If that is not the case, bring somebody in who can. Complaining about end-users is stupid, it just means you lack the skill set to deal with them.

This thread actually is a good example of how specialised "technical people" can be also the source of confusion when talking to people outside their field of expertise as they fail to translate to the "language" the other party understands. In German language there is the name "Fachidioten" for that, https://de.wikipedia.org/wiki/Fachidiot (best use Google or DeepL to translate it to English)
Yep, this is it. I work in data analysis, mainly focused on reports and dashboarding for end-users. You have to talk in terms they understand otherwise you will get nowhere. Sometimes I also talk to technical people and have to ask them to explain it using normal words. Because I don't know all the names for the processes they run behind the scenes, but I do understand if they simply say what it does like "this does x with the data, so it can be imported in this database".
 
Last edited:

q3cpma

Major Contributor
Joined
May 22, 2019
Messages
3,060
Likes
4,416
Location
France
A story is basically a task. If you are working on a project (epics), stories are the smallest tasks you can split the project up in (its used in agile frameworks, but that doesn't really matter to understand the concept of a story). For example it could be to implement a user login as part of a new content management system.
I'm going to be very candid: why not call them tasks and projects, then?
 

Katji

Major Contributor
Joined
Sep 26, 2017
Messages
2,990
Likes
2,273
In the end / "end of the day", the programmers are responsible. Even if it is midnight or they are on leave.

users and developers cannot really talk to each other. That's why you have product owners that responsible for projects. They do the translating.
Theoretically. Usually, they are users anyway. But at least they are held responsible, it is part of the job definition.
 
OP
SimpleTheater

SimpleTheater

Addicted to Fun and Learning
Forum Donor
Joined
Jun 6, 2019
Messages
927
Likes
1,789
Location
Woodstock, NY
I'm going to be very candid: why not call them tasks and projects, then?
I didn't invent Agile development, but the concept seems to be to give them a more readable outline. A story makes it easier for outsiders to read what we plan on doing and approve it. The latter part is the most important to us, because our non-programmers couldn't approve our previous tasks because they simply didn't understand the task.
 

Koeitje

Major Contributor
Joined
Oct 10, 2019
Messages
2,292
Likes
3,880
In the end / "end of the day", the programmers are responsible. Even if it is midnight or they are on leave.


Theoretically. Usually, they are users anyway. But at least they are held responsible, it is part of the job definition.
In my case I think I'm talking more about the stakeholders for certain projects. Our development team rolls out software that our operational departments use, but those who are responsible for those departments aren't technical people. But yes, the actual end-users that press the buttons in production don't talk to development.

I'm going to be very candid: why not call them tasks and projects, then?
Doesn't sound cool. But tasks also exist in agile. The naming is a bit of a mess, and to be frank I also don't know exactly what is what. Usually the name and description tell you enough :p. Maybe I shouldn't have used to word "task" to describe a story, because a story can consist of subtasks. Usually a story can take multiple days in a sprint (which is usually two weeks), so its also common to create subtasks for a story to make it easier to manage.
 
Top Bottom