On 6/8/2024 2:46 PM, avi.e.gross@gmail.com wrote:
> Agreed, Thomas.
>
> As someone who has spent lots of time writing code OR requirements of various levels or having to deal with the bugs afterwards, there can be a huge disconnect between the people trying to decide what to do and the people having to do it. It is not necessarily easy to come back later and ask for changes that wewre not anticipated in the design or implementation.
And typical contract vehicles aren't often flexible to allow for this
kind of thing. I've always tried to persuade my management to allow
built-in phases where re-evaluation can take place based on what's been
learned. To have a hope of that working, though, there needs to be a lot
of trust between client and development folks. Can be hard to come by.
> I recently wrote a program where the original specifications seemed reasonable. In one part, I was asked to make a graph with some random number (or all) of the data shown as a series of connected line segments showing values for the same entity at different measurement periods and then superimpose the mean for all the original data, not just the subsample shown. This needed to be done on multiple subsamples of the original/calculated data so I made it into a function.
>
> One of the datasets contained a column that was either A or B and the function was called multiple times to show what a random sample of A+B, just A and just B graphed like along with the mean of the specific data it was drawn from. But then, I got an innocuously simple request.
>
> Could we graph A+B and overlay not only the means for A+B as was now done, but also the mean for A and the mean for B. Ideally, this would mean three bolder jaged lines superimposed above the plot and seemed simple enough.
>
> But was it? To graph the means in the first place, I made a more complex data structure needed so when graphed, it aligned well with what was below it. But that was hard coded in my function, but in one implementation, I now needed it three times. Extracting it into a new function was not trivial as it depended initially on other things within the body of the function. But, it was doable and might have been done that way had I known such a need might arise. It often is like that when there seems no need to write a function for just one use. The main function now needed to be modified to allow optionally adding one or two more datasets and if available, call the new function on each and add layers to the graph with the additional means (dashed and dotted) if they are called while otherwise, the function worked as before.
I feel your pain. In the generalized X-Y graphing program I've evolved
over several generations, I have graphing methods that can plot points
and curves, optionally overlaying them. Any function that wants to plot
something has to generate a dataset object of the type that the plotter
knows how to plot. No exceptions. Nothing else ever plots to the
screen. It's simple and works very well ... but I only designed it to
have axis labels and the title of the plot. They are all three
interactive, editable by the user. That's good, but for anything else
it's hack time. Witness lines, legends, point labels, etc., etc. don't
have a natural home.
> But did I do it right? Well, if next time I am asked to have the data extended to have more measurements in more columns at more times, I might have to rewrite quite a bit of the code. My localized change allowed one or two additional means to be plotted. Adding an arbitrary number takes a different approach and, frankly, there are limits on how many kinds of 'line" segments can be used to differentiate among them.
This is the kind of situation where it needs to be implemented three
times before it gets good. One always thinks that the second time
around will work well because all the lessons were learned the first
time around. But no, it's not the second but the third implementation
that can start to be really good.
> Enough of the example except to make a point. In some projects, it is not enough to tell a programmer what you want NOW. You may get what you want fairly quickly but if you have ideas of possible extensions or future upgrades, it would be wiser to make clear some of the goals so the programmer creates an implementation that can be more easily adjusted to do more. Such code can take longer and be more complex so it may not pay off immediately.
>
> But, having said that, plenty of software may benefit from looking at what is happening and adjusting on the fly. Clearly my client cannot know what feedback they may get when showing an actual result to others who then suggest changes or enhancements. The results may not be anticipated so well in advance and especially not when the client has no idea what is doable and so on.
>
> A related example was a request for how to modify a sort of Venn Diagram chart to change the font size. Why? Because some of the labels were long and the relative sizes of the pie slices were not known till an analysis of the data produced the appropriate numbers and ratios. This was a case where the documentation of the function used by them did not suggest how to do many things as it called a function that called others to quite some depth. A few simple experiments and some guesses and exploration showed me ways to pass arguments along that were not documented but that were passed properly down the chain and I could now change the text size and quite a few other things. But I asked myself if this was really the right solution the client needed. I then made a guess on how I could get the long text wrapped into multiple lines that fit into the sections of the Venn Diagram without shrinking the text at all, or as much. The client had not considered that as an option, but it was better for their display than required. But until people see such output, unless they have lots of experience, it cannot be expected they can tell you up-front what they want.
>
> One danger of languages like Python is that often people get the code you supply and modify it themselves or reuse it on some project they consider similar. That can be a good thing but often a mess as you wrote the code to do things in a specific way for a specific purpose ...
>
>
> -----Original Message-----
> From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Thomas Passin via Python-list
> Sent: Saturday, June 8, 2024 1:10 PM
> To: python-list@python.org
> Subject: Re: From JoyceUlysses.txt -- words occurring exactly once
>
> On 6/8/2024 11:54 AM, Larry Martell via Python-list wrote:
>> On Sat, Jun 8, 2024 at 10:39 AM Mats Wichmann via Python-list <
>> python-list@python.org> wrote:
>>
>>> On 6/5/24 05:10, Thomas Passin via Python-list wrote:
>>>
>>>> Of course, we see this lack of clarity all the time in questions to the
>>>> list. I often wonder how these askers can possibly come up with
>>>> acceptable code if they don't realize they don't truly know what it's
>>>> supposed to do.
>>>
>>> Fortunately, having to explain to someone else why something is giving
>>> you trouble can help shed light on the fact the problem statement isn't
>>> clear, or isn't clearly understood. Sometimes (sadly, many times it
>>> doesn't).
>>
>>
>> The original question struck me as homework or an interview question for a
>> junior position. But having no clear requirements or specifications is good
>> training for the real world where that is often the case. When you question
>> that, you are told to just do something, and then you’re told it’s not what
>> is wanted. That frustrates people but it’s often part of the process.
>> People need to see something to help them know what they really want.
>
> At the extremes, there are two kinds of approaches you are alluding to.
> One is what I learned to call "rock management": "Bring me a rock ...
> no, that's not the right one, bring me another ... no that's not what
> I'm looking for, bring me another...". If this is your situation, so,
> so sorry!
>
> At the other end, there is a mutual evolution of the requirements
> because you and your client could not have known what they should be
> until you have spent effort and time feeling your way along. With the
> right client and management, this kind of project can be a joy to work
> on. I've been lucky enough to have worked on several projects of this kind.
>
> In truth, there always are requirements. Often (usually?) they are not
> thought out, not consistent, not articulated clearly, and not
> communicated well. They may live only in the mind of one person.
>

I agree with Larry that the OP was asking something that might be fair to use in an interview process where perhaps an exact answer is not as important as showing how the person thinks about a process. The original question can be incomplete or vague. Do they give up? Do they ask careful questions that might elicit missing parts? Do they examine alternatives and then pick a reasonable one and document exactly which possible version(s) their presented code should solve?

In this case, as mentioned, one approach is to isolate the determination of what a word means from the rest of the problem.

In effect, the code can be:

- read in all lines of text.
- words = function_name(text)
- optionally, manipulate the words such as making them all the same case, removing some characters, throwing some way.
- count the words in words remaining using some method such as a dictionary.
- output reports as requested.

You could then design any number of functions you can slide into place and the remaining code may continue working without changes.

It may not matter if you can specify the specific definition of text if you show the general solution, and maybe instantiate some fairly simple way of making words.

Note, the above logic applies not to just python but most programming environments. If someone interviewed me for a job in say, Rust, which I am just now learning out of curiosity, I might not know how to program some parts of a problem like this, let alone make use of the idioms of that language right away. But if they want someone who can rapidly learn the local ways and adapt, then the best they can do is try to see if you think like a programmer and can think abstractly and be able to do lots of work even while waiting for more info from someone on what they want for a specific part.

Or, in a case like this problem, I wonder if they would want to hear a suggestion that this may more easily be done in languages that support something like the dictionary or hash or associative array concept or that have available modules/packages/crates/etc. that provide such functionality.

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Larry Martell via Python-list
Sent: Saturday, June 8, 2024 11:54 AM
To: Mats Wichmann <mats@wichmann.us>
Cc: python-list@python.org
Subject: Re: From JoyceUlysses.txt -- words occurring exactly once

On Sat, Jun 8, 2024 at 10:39 AM Mats Wichmann via Python-list <
python-list@python.org> wrote:

> On 6/5/24 05:10, Thomas Passin via Python-list wrote:
>
> > Of course, we see this lack of clarity all the time in questions to the
> > list. I often wonder how these askers can possibly come up with
> > acceptable code if they don't realize they don't truly know what it's
> > supposed to do.
>
> Fortunately, having to explain to someone else why something is giving
> you trouble can help shed light on the fact the problem statement isn't
> clear, or isn't clearly understood. Sometimes (sadly, many times it
> doesn't).

The original question struck me as homework or an interview question for a
junior position. But having no clear requirements or specifications is good
training for the real world where that is often the case. When you question
that, you are told to just do something, and then you’re told it’s not what
is wanted. That frustrates people but it’s often part of the process.
People need to see something to help them know what they really want.

>
--
https://mail.python.org/mailman/listinfo/python-list

On 2024-06-08, Larry Martell via Python-list <python-list@python.org> wrote:

> The original question struck me as homework or an interview question for a
> junior position. But having no clear requirements or specifications is good
> training for the real world where that is often the case. When you question
> that, you are told to just do something, and then you’re told it’s not what
> is wanted. That frustrates people but it’s often part of the process.
> People need to see something to help them know what they really want.

Too true. You can spend all sorts of time getting people to pin down
and sign off on the initial requirements, but it all goes right out
the window when they get the first prototype.

"This isn't what we want, we want it to do <something else>."

"It does what you specified."

"But, this isn't what we want."

...

If you're on salary, it's all part of the job. If you're a contractor,
you either figure it in to the bid or charge for change orders.