Re: Top 10 most common hard skills listed on resumes...

Michael S <already5chosen@yahoo.com> writes:

On Mon, 26 Aug 2024 17:16:06 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>

Michael S <already5chosen@yahoo.com> writes:
>
[..concerning "abstraction"..]
>

Not that I am particularly fond of abstractions when I do see
them.

>
A most unexpected comment.  IMO choosing the right abstractions
to define may be the most important skill in developing large
systems.

>
You are probably right, but me being me, I am rarely able to grasp
pure abstract things.  Most typically, first read about abstract
concept goes straight above my head.

Abstraction doesn't have to mean abstruse.  To some degree every
function written defines, or partially defines, an abstraction.
Consider printf() as an example - printf() provides a way of
sending formatted output without having to worry about the details
of how the formatting is done.  A key property of abstractions in
programming is offering a way to get something done without having
to worry about how it is done.  Sometimes what is being done is
fairly simple to explain and understand, and other times more
difficult, but both cases are abstractions.

 It can't be helped by few examples, but success is not
guaranteed.

Presumably you mean it can be helped, etc.  It's often true that
examples greatly help in explaining what an abstraction does.
However it is also often true that examples alone do not suffice.
To be useful an abstraction must be understood as to what it does.
More than that, an abstraction is not useful if the amount of effort
needed to understand and use it is greater than the amount of effort
required to do the same thing without making use of the supplied
functions, type definitions, etc.  In short, some documentation is
needed.  How much is needed varies a lot from case to case.

Even after I seemingly grasped the principle, when I start using
an instance of abstract thing, it's hard for me to stop thinking
about gears and toothed wheels rotating under the hood.

Mostly this is a matter of practice and habit.  Of course there are
cases where it can be helpful to think about what is going on inside
an abstraction.  But such cases should be rare.  The primary purpose
of defining an abstraction is so one doesn't have to think about how
something is done, only what needs to be done.  I'm confident you
have enough discipline to acquire this habit if you make an effort
to do so.  After getting into the habit then you can start to think
about when to make exceptions.  But the first reaction should always
be "It's on a need not to know basis."