Young developer training and education approach and why

[cgbosse]

Extract from an email reply by @da2ce7 regarding the topic:

• In the future define Slots of scholarship. paid slots, donation
  slots.
• Market for education is massive.

I think this is the main point: education is an incredibly large
industry of which we should consider ourselves a part. If we offer and
promote educational and professional development, we are providing a
service in the education market.

We must therefore .... keep appropriate financial records of the delivery of
vocational educational services ..... (in various forms, such as:
internships, apprenticeships and job training, scholarships, work
experience, including career progression, and so on).

• We should not have complete rookies who do not know the basics
  such as git.

Absolutely newcomers are, of course, welcome. From "Bringing Children
to Work Days" to "Work Experience", we must develop at a fundamental
level the idea that people and machines can communicate and work
together. We need to be clear so that the child can understand our
goals.

Certainly however, we don't have to do all the work! For enthusiastic
beginners, we can recommend other sources of education of excellent
quality until they reach an appropriate level of mastery.

Observing and participating in our meetings at a superficial level
(e.g. while they take a short course on Git) allows them to get a feel
for the work and man-machine culture we cultivate, beginners are likely
to start giving philosophical opinions with their childish questions
long before their technical input is accepted.

• We should have two meetings a week. Public meetings which is
  recorded such as our weekly dev meeting.One of which the students
  attend and present the difficulties that they are facing. - The idea
  here is to have them public so that it encourages new contributors
  and users. The other is a meeting in which the students sit in and
  learn from listening.

I like our current weekly meeting and I think it works very well. So I
don't want to change the format too much. I think we could call our
current meeting something like "Nautilus Weekly Meeting". The general
format could be like this: a few presentations by senior people giving
insights and examples of solutions to interesting problems, and a few
Q&As to get feedback and understanding at a higher level.

I also foresee a need for another meeting. Something like a weekly
debrief meeting where each team can give a quick overview of their week
and what they are going to do next week. At the end of this meeting
there should be a short general discussion to agree on goals and
expectations.

I suggest that one of the first and important responsibilities of a
junior staff member should be to write up minutes of meetings (perhaps
in the form of an pull-request) (including appropriate links to video
files) and to maintain a blog detailing their ideas drawn from
presentations by senior staff (which should also go through some kind
of peer review process). Such entries as journalistic content are very
useful for junior staff, who can deepen their understanding of the
material in question and help present it in a way that is relevant and
accessible to a larger audience.

• Students have to learn the process of being in a programming
  environment.
• There should the PM to lead the trainees possibly a Mid developer.
• The idea is that trainees get helped and mentorized by a junior
  developer and also managed and mentorized by a mid developer.

The main focus for everyone should be to have greater clarity about the
context and the reason why they are putting their conscious energy into
their work and learning.

Yeray cautioned me when he felt (and it was true) that much of the work
he was doing was of no real benefit. This is very demotivating and
should be avoided by providing real philosophical, social and technical
reasons for doing the work. In this way, it will allow team members to
take part in the project with good reasons and avoid such frustrations.

Our team should feel that they are contributing to a broader goal that
is in line with the way they want their identity to develop and that
makes a useful contribution to their vision of how they want the world
to be.

• We have to try to autmate the code review process
  • By seniors?
  • Could we use AI?

Reviewing is a largely human process, although the quality and style of
the code can be checked by some automated processes, aligning the core
values and goals of the project with the request for correction is an
inherently subtle and human process.

The sensitivity and expressiveness of this subtle alignment is one of
the core human aspects that we want to develop and flourish throughout
our team. Both in putting together an excellent and easily verifiable
request and in giving fair and careful consideration to the requests of
others.

• The challenge for such young developers is to write which is
  easily reviewable by other people.
• We should also focus on PM
  • It is a core element of software development.
  • We should research what other challenges junior developers
    face.

Code is cheap, good review is expensive. Spending the time and energy
to put together something that is both technically good and easy to
review is a real art.

The use of automated tools such as AI and various forms of continuous
integration should be encouraged, as the focus should always be on
producing complete and well-structured review packages.

The main role of senior staff, much of whose work involves reviewing,
is to streamline the review process, thus making much better use of
their valuable attention to providing fundamental feedback.

For senior staff, drafting review requests is increasingly becoming a
meta-process; the purpose of their review requests is to serve as an
example and template for others, setting the standard for what they
themselves would like to receive for reviewing.

• In the future AI will code so developers should focus on other
  things.
  • Code will become the interpreting language of what the AI spits
    out as code.
  • Code will become the communication language with AI.

Code already is our communication language with computers, with AI is
just a natural extension in a more interactive form.

• It needs to be learned how to conceptually and philosophically
  relay to the AI why the project is being put effort into. The
  philosophical choices need to be put into words for as to help the AI
  write code. It is learning how to write the projects guidelines for
  the AI as to what wants to be achieved and the reasons for it and why
  the code needs to be in some specific format.

In order to create excellent review packages, the coder and the AI
coder must agree on the main reasons why this review package should be
created in the first place. Together, they must explain why the main
project benefits from using this review package, and show that the
package really does everything it claims to do.

• The students need to learn how to make use of AI tools so that we
  need to find AI tools for the students.
  • University teaches them to learn all by themselves.
  • We need to teach them how to work more efficiently using AI
    keeping good habits.

Finding and using AI is akin to finding and using newcomers and
juniors: both need the bigger picture to work effectively.

However, newcomers, as they personally buy in and become stakeholders
in their projects, can also exert their influence by moving the picture
forward, as they bring their unique human experience to the table. They
will adapt and refine the project goals themselves!

Growing strong, confident and intellectually independent teams in a
good and kind atmosphere of personal expression is something I would
like to achieve, as everyone has their own and unique personal passions
and development goals. I hope that Nautilus can be a good place to
encourage this at all levels and in all parts of our operations and as
a core expression of our corporate culture.

[cgbosse]

Nautilus Objective:

To offer and promote educational and professional development to developers. AI first company.

Training Objectives:

- Provide newcomers with the bigger picture to work effectively.

• The bigger picture being the why. To explain why things are done and for what purpose.
• The bigger picture is necessary for people to buy in and emotional involvement, so that they can add their unique human experience which results in proactiveness within the projects.

- Reduce the time spent on reviewing code by seniors

• Teach how to take advantage of AI tools to write cleaner code.
• Instill a habit of writing easily reviewable code.

Approach and tools:

• Provide guidance and advice at a high level to have those who really are vocational developers flourish.
• Provide the enthusiastic young developers with a list of available tools, etc. so that they can learn themselves through self study.
• Recommend other sources of education of excellent quality until they reach an appropriate level of mastery.
• Give opportunity to listen into meetings.
• Give the opportunity to voice their doubts, problems, successes weekly.
• Focus on them understanding the need for writing easily reviewable code. communicating in a structured and clear way issues.

[cgbosse]

In line with the topic of this discussion I have created to additional discussion:

• Projects and how to build something usefull long term making use of each new batch of inexperienced developers. Projects for inexperienced developers to build the skills that Nautilus needs #49
• What are the skills that new inexperienced developers should learn to speed up their progress. What are the essentials that a new and inexperienced developer should learn, assimilate and make a habit for his future career? #50