Re: how to can measure my level of knowledge?
[email protected] (Rob Coops) Fri, 31 May 2024 10:57:26 +0200
| Newsgroups | perl.beginners |
|---|---|
| Message-ID | <CABPR7FEdUn_sFS6VXaZ7sf++9Aq0qSKiAsvO+Rf9SdEfdv=bVg@mail.gmail.com> |
--000000000000d5e6170619bc2c5a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi William,
Here are my two cents after nearly 30 years of writing code in many
different languages.
Writing in any functional language is exactly the same as in every other
functional language. The easiest way to learn and improve is by learning to
break down your problem into manageable steps. The simplest analogy I can
provide is the question and answer of: How do you eat an elephant? One bite
at a time.
Writing code is the thing you take a complex problem and break it down into
smaller chunks. Let's say I am asked to take an arbitrary git repository
and list all .txt and .png files in that git repository. I can just sit
down and begin writing but how would I do all that? I would first do it by
hand and record or memorize the steps I am taking. I would checkout the
repository, I would go through each directory and record all files that
have either a .txt or a .png extension, and provide the list of these files
and their path within the directory, maybe add their file size as well for
goot measure.
The next stage is writing maybe even in pseudo code or just pain text how
each step will work, lets take the crawling of the repo as an example of
what this would look like:
- Put the full path of the directory where the repo was checked out on a
list of directories to be processed
- Read contents of the directory where I checked out the repository
- For each file with a .txt and .png record the directory name a
'/' an the filename
- For each directory add them to the list of directories we need
to process
- Remove the now processed from the list of directories to be
processed
- Process the next directory on the list of directories to be
processed
- When no more directories are left to process we collected all files
with the.txt and .png extension
- Now we process the list of .txt and .png files and grab whatever
additional information we need for each file
- We now should have a structure with a full path for each .txt or .png
file (the keys) in the repository with associated as values the informat=
ion
associated with each file
- All that is left it is a simple matter of printing out the structure
from the previous line one key at a time
Based on this list of steps above you can see where the loops would be, I
have indented those to make it easy to see which bits would go in a loop.
You now have the general structure of your code figured out and where you
will need loops you have an idea of what structures you will need to store
your data etc...
The above is completely language agnostic you can implement this in any
programing language all you need to do is figure out how to do each step
one at a time. You might not know how to list the contents of a directory
in your language of choice (in this case Perl) but that is easy enough to
look up. The same for finding the attributes associated with a file, again
this is easy enough to look up. Since you have this step by step plan you
can easily figure out how to do each bit and then just string them together=
.
I often add those above steps in my code as comments, and add the actual
code below each step. So I can see exactly what my goal is with each step.
Once that is done in your very first version of the code that produces the
desired results you stop walk away and have another look at it the next day
or so and clean things up as not a single person will write perfect code
from the start there always is something missing or something that you
would like to add (comments for instance). When done you have a working bit
of code that you can explain step by step as you have set down and
understood each step of the code. Having comments in the code is very
helpful for future you... when you look back at that code a year or two
from now you will be very happy to see the comments so you can understand
what you where thinking or how you broke down the problem back then when
you were still learning how to code in this language.
Keeping this code or even just the portion of the code that does the
walking through the directory structure in some code repository for future
reference will help you not have to reinvent that wheel in the future. As
it is highly likely that at some point a project will need something
similar but this time .pdf files are what you are looking for or maybe even
a user defined extension or all directories etc...
The most important thing about being a good developer in any language is
your ability to take a complex problem and break it down into small enough
parts that any monkey with a little bit of programming knowledge and a
search engine can figure out how to code each step.
Now as you get more experienced you might find that for certain things you
just know how to do that and you do not need to write it all down as you
can just do it in your head. But having worked with people that wrote
amazingly complex code form one of the developers of the DHCP protocol to
one of the people writing the guidance code for the patriot missile system
and optimizing games for the PS3's cell processor every good developer I
have worked with has sat there writing out the steps they needed to code
before ever opening a code editor simply because even truly brilliant
people need to break problems down into smaller steps to be able to
understand what it is they are going to have to code.
I hope that helps a bit.
Kind regards,
Rob
On Thu, May 30, 2024 at 6:59=E2=80=AFPM William Torrez Corea <willitc9888@g=
mail.com>
wrote:
> I code but my logic is weak, i code 1000 lines of code but I don't
> understand the logic of the program. Can write 10 lines of code, get the
> result but I don't understand the concept.
>
> Can code the program but I can't interpret. My mentor told me: understand
> the concept because I talk nonsense.
>
> --
>
> With kindest regards, William.
>
> =E2=A2=80=E2=A3=B4=E2=A0=BE=E2=A0=BB=E2=A2=B6=E2=A3=A6=E2=A0=80
> =E2=A3=BE=E2=A0=81=E2=A2=A0=E2=A0=92=E2=A0=80=E2=A3=BF=E2=A1=81 Debian - =
The universal operating system
> =E2=A2=BF=E2=A1=84=E2=A0=98=E2=A0=B7=E2=A0=9A=E2=A0=8B=E2=A0=80 https://w=
ww.debian.org
> =E2=A0=88=E2=A0=B3=E2=A3=84=E2=A0=80=E2=A0=80=E2=A0=80=E2=A0=80
>
>
>
--000000000000d5e6170619bc2c5a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi=C2=A0William,<br><br>Here are my two cents after nearly=
30 years of writing code in many different languages.<br><br>Writing in an=
y functional language is exactly the same as in every other functional lang=
uage. The easiest way to learn and improve is by learning to break down you=
r problem into manageable=C2=A0steps. The simplest analogy I can provide is=
the question and answer of: How do you eat an elephant? One bite at a=C2=
=A0time.<br><br>Writing code is the thing you take a complex=C2=A0problem a=
nd break it down into smaller chunks. Let's say I am asked to take an a=
rbitrary git repository and list all .txt and .png files in that git reposi=
tory. I can just sit down and begin writing but how would I do all that? I =
would first do it by hand=C2=A0and record or memorize the steps I am taking=
. I would checkout the repository, I would go through each directory and re=
cord all files that have either a .txt or a .png extension, and provide the=
list of these files and their path within the directory, maybe add their f=
ile size as well for goot measure.<br>The next stage is writing maybe even =
in pseudo code or just pain text how each step will work, lets take the cra=
wling of the repo as an example of what this would look like:<br><ul><li>Pu=
t the full path of the directory where the repo was checked out on a list o=
f directories to be processed</li><ul><li>Read contents of the directory wh=
ere I checked out the repository</li><ul><li>For each file with a .txt and =
.png record the directory name a '/' an the filename</li><li>For ea=
ch directory add them to the list of directories we need to process</li></u=
l><li>Remove the now processed from the list of directories to be processed=
</li><li>Process the next directory on the list of directories to be proces=
sed</li></ul><li>When no more directories are left to process we collected =
all files with the.txt and .png extension<br></li><ul><li>Now we process th=
e list of .txt and .png files and grab whatever additional information we n=
eed for each file</li></ul><li>We now should have a structure with a full p=
ath for each .txt or .png file (the keys) in the repository with associated=
as values the information associated with each file</li><li>All that is le=
ft it is a simple matter of printing out the structure from the previous li=
ne one key at a time</li></ul><div>Based on this list of steps above you ca=
n see where the loops would be, I have indented those to make it easy to se=
e which bits would go in a loop. You now have the general structure of your=
code figured out and where you will need loops you have an idea of what st=
ructures you will need to store your data etc...<br><br>The above is comple=
tely language agnostic you can implement this in any programing language al=
l you need to do is figure out how to do each step one at a time. You might=
not know how to list the contents of a directory in your language of choic=
e (in this case Perl) but that is easy enough to look up. The same for find=
ing the attributes associated with a file, again this is easy enough to loo=
k up. Since you have this step by step plan you can easily figure out how t=
o do each bit and then just string them together.<br>I often add those abov=
e steps in my code as comments, and add the actual code below each step. So=
I can see exactly what my goal is with each step.<br><br>Once that is done=
in your very first version of the code that produces the desired results y=
ou stop walk away and have another look at it the next day or so and clean =
things up as not a single person will write perfect code from the start the=
re always is something missing or something that you would like to add (com=
ments for instance). When done you have a working bit of code that you can =
explain step by step as you have set down and understood each step of the c=
ode. Having comments in the code is very helpful for future you... when you=
look back at that code a year or two from now you will be very happy to se=
e the comments so you can understand what you where thinking or how you bro=
ke down the problem back then when you were still learning how to code in t=
his language.<br><br></div><div>Keeping this code or even just the portion =
of the code that does the walking through the directory structure in some c=
ode repository for future reference will help you not have to reinvent that=
wheel in the future. As it is highly likely that at some point a project w=
ill need something similar but this time .pdf files are what you are lookin=
g for or maybe even a user defined extension or all directories etc...<br><=
br>The most important thing about being a good developer in any language is=
your ability to take a complex problem and break it down into small enough=
parts that any monkey with a little bit of programming knowledge and a sea=
rch engine can figure out how to code each step.<br>Now as you get more exp=
erienced you might find that for certain things you just know how to do tha=
t and you do not need to write it all down as you can just do it in your he=
ad. But having worked with people that wrote amazingly complex code form on=
e of the developers of the DHCP protocol to one of the people writing the g=
uidance code for the patriot missile system and optimizing games for the PS=
3's cell processor every good developer I have worked with has sat ther=
e writing out the steps they needed to code before ever opening a code edit=
or simply because even truly brilliant people need to break problems down i=
nto smaller steps to be able to understand what it is they are going to hav=
e to code.</div><div><br></div><div>I hope that helps a bit.<br><br>Kind re=
gards,<br><br>Rob</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Thu, May 30, 2024 at 6:59=E2=80=AFPM William Torr=
ez Corea <<a href=3D"mailto:[email protected]">[email protected]=
</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div>I code but my logic is weak, i code 1000 lines of cod=
e but I don't understand the logic of the program. Can write 10 lines o=
f code, get the result but I don't understand the concept. <br></div><d=
iv><br></div><div>Can code the program but I can't interpret. My mentor=
told me: understand the concept because I talk nonsense. <br></div><div><d=
iv><div><br><span class=3D"gmail_signature_prefix">-- </span><br><div dir=
=3D"ltr" class=3D"gmail_signature"><br>With kindest regards, William.<br><b=
r>=E2=A2=80=E2=A3=B4=E2=A0=BE=E2=A0=BB=E2=A2=B6=E2=A3=A6=E2=A0=80 <br>=E2=
=A3=BE=E2=A0=81=E2=A2=A0=E2=A0=92=E2=A0=80=E2=A3=BF=E2=A1=81 Debian - The u=
niversal operating system<br>=E2=A2=BF=E2=A1=84=E2=A0=98=E2=A0=B7=E2=A0=9A=
=E2=A0=8B=E2=A0=80 <a href=3D"https://www.debian.org" target=3D"_blank">htt=
ps://www.debian.org</a><br>=E2=A0=88=E2=A0=B3=E2=A3=84=E2=A0=80=E2=A0=80=E2=
=A0=80=E2=A0=80 <br><br><br></div></div></div></div></div>
</blockquote></div>
--000000000000d5e6170619bc2c5a--