Mapping "learning code" guidelines to the Agile principles
Quotes are from agilemanifesto.org, rest is from Gregory Brown
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
As a learner, you need to start making use of what you learn as early as possible, and keep applying what you've learned, while keeping your goals focused on actually building useful things, rather than just treating coding as an intellectual exercise.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
If you realize that you're studying the wrong thing at the wrong time, don't be afraid to put it down and pick up something else. If you discover that you need to learn something else before you can accomplish your task, don't be afraid to take a detour and pick up a dependent skill.
Every time you practice, you learn more about what you don't know. Harness that change to come up with better study plans on an ongoing basis.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Break up your study and practice plans so that you can put what you've learned to use as quickly as possible. If you are struggling for weeks to learn a concept before actually putting it into practice in a project... you've bitten off more than you can chew, and should either get help, simplify your goals, or switch to some other area of study for now.
Business people and developers must work together daily throughout the project.
Don't just surround yourself with other programmers. Get in touch with, learn about, and constantly be thinking about the people who you will eventually end up helping through your newly gained software skills.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Applies more towards teachers than learners, but... make sure to design learning exercises, tutorials, projects, etc. with the assumption that your students are capable of doing active learning. Teach them the basic concepts, provide good examples, then design ways for the students to use these ideas in their own projects rather than just following along on a carefully designed, sanitized learning path.
In particular, don't produce learning materials that only show "the happy path" -- it makes things look easier than they are, and sets up students for frustration when they apply ideas outside of your carefully crafted examples.
(i.e. don't just show a finished math proof if you're a math teacher... show the messy process that produces one)
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Disagree (in part)... won't attempt to translate this one.
Working software is the primary measure of progress.
Build something (anything!) to codify and validate each and every concept you learn. A library of your own code samples and projects is worth a thousand books.
Agile processes promote sustainable development.The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Don't attempt to learn everything all at once. Reading a book in a single day is actually much worse than reading it over the course of a month, because you won't retain anything done in crunch mode sustainably.
Balance short-term gains (i.e. microskills like text editing tricks) with longer-term strategic learning (like studying a new framework, language, or development methodology)
Aim for consistency (every day or at least several days a week) and quality (i.e. full focus without distractions) over quantity (i.e. lots and lots of hours).
Continuous attention to technical excellence and good design enhances agility.
Related to the above... mastering a handful of skills is better than being mediocre at a bunch of skills.
But be careful here: only two kinds of things need to be mastered -- the stuff on your critical path (i.e. that which is essential to your work), and the mundane things that drain your energy and cognitive resources day to day (the simple stumbling blocks like not knowing the right syntax for the language you're working in)
There are many very interesting skills or areas of knowledge that are difficult to master, but unimportant in a practical sense. Make sure to master only that which appears to have a high upside benefit to learn well, or a high cost to not learn well.
If you are a beginner, you won't know how to evaluate this. Ask someone experienced for help.
Simplicity--the art of maximizing the amount of work not done--is essential.
See the above response to the previous principle. For more... read this article: https://practicingruby.com/articles/low-cost-approach-to-side-projects
The best architectures, requirements, and designs emerge from self-organizing teams.
You can't just follow a predefined curriculum, particularly if it's been handed to you by someone who doesn't have your personal goals, interests, and needs in mind.
The best study plan is one that is covers the skills and tools you need to make the kind of software you're looking to build some day, or at least prepares you for the kind of programming you want to do.
Find like-minded people who understand where you're headed, and ask them to help you find a good path to get you there.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Don't just set a bunch of goals and come up with a study plan... at least once a week take a look at what you're learning and ask "is this getting me closer to what I want to be able to do in the world?" -- if the answer is no, re-evaluate and tweak your plan. Ask for help whenever you need it.
Also... participate in meaningful communities of practice. Your local community may have plenty of meetups.
CodeNewbie is wonderful for beginners and those who want to help beginners.
(as a shameless plug), my own work at Practicing Ruby and the community available to its subscribers is specifically designed with this sort of thing in mind, and is a good place to get this sort of help for intermediate/advanced devs.