@JD557 oh absolutely, but that's not going to be during the lessons. That's when they encounter a performance issue on the job and I help them debug it. The lessons are to get them off the ground because right now, they know so very little and aren't yet equipped to take on anything but the most basic tasks.
The kind of tasks toxic management would offload to an LLM, depriving them the chance of learning and improving their craft.
@NicolasRinaudo i thought we were on the age where nobody needs to learn anything because it's all vibecoding now
@vascorsd I’m trying to teach the joy and art of programming, not the mediocrity of vibe coding
@vascorsd huh. “The joy of programming”. That sounds like a book i’d read!
@NicolasRinaudo This sounds very good to me. Lawful composition is the key to managing complexity. Let us know how it goes!
@tpolecat oh i’ve done that a year ago already with a different cohort. 3 of them are now speaking at FP conferences, one of whom has been invited to co-write a book. I’d say i was reasonably successful :)
@NicolasRinaudo have you considered also diving into concepts which are more DDD oriented? For example, some of the things that I typically talk about to juniors and/or new joiners (depending on their experience) with non-functional background are:
* Refinement types and how they become the cornerstone of anti-corruption layers
* Structure and responsibilities of lower level services (or algebras, if you like)
[1/2]
@NicolasRinaudo all of the above + how to tie this to concrete benefits towards solving the business case.
Finding ways to talk about all of this but to people who can't/won't care but will care much about time & cost
@c_chep oh yeah no, I'm teaching this class from the perspective of doing the right thing for its own sake. My approach to negotiating with management is to throw my weight about, which has worked for me so far but I don't want to teach to young people :)
I've taken on a new cohort of young developers to train at work - and by young, I mean interns in the middle of their diplomas, not fully trained and zero practical experience.
I'm planning on taking them through my usual topics, which I feel cover a lot of what is needed to *think* about programming right, and gives them the tools to work the rest out of themselves (at least in the context of languages like Scala). Here's what I consider important:
- algebraic data types (or, I don't know, objects and subtyping if they're doing more Java-like things)
- parametric polymorphism
- recursive traversal of data structures
- programs as pipelines of transformation from one data structure to another (which implies composition)
- error handling
I feel that armed with these, most developers can break down any task into atomic problems, solve them in a clear and maintainable way, compose the solutions together, and have everybody understand them.
Optimisation, technologically-specific details, ... are all things I think can be learned on the job. But you need foundations on which to build this knowledge.
Am I missing anything you feel is critically important?