[awkward_yeti]

> Pick a small number of specific skills you're simply good but not great at.

I am struggling with this one since forever, what are the skills-set a programmer should enumerate through ? like how good they can connect to a DB provider ? or how quickly they can set up a web server ? what qualifies as a skill in this context ?

[practicingdev]

Given that the goal of software development is to build tools, toys, etc... it can help to work backwards from projects to skills.

No matter what level of skill you're at, you can start looking at the software you use day to day and think "Could I build that? What parts would be easy? What might be hard? What might be tedious?"

Try that with a few different project ideas. There will probably be some tools/techniques/skills in common between them, some of which might be ones you have some skill with but don't feel fully confident.

From there, you have a topic of study, and can go dig deep into books, exercises, practice projects, etc. (Or find someone to mentor you and give feedback)

You'll know you're doing it really well when either (a) you're fairly certain that no one has a much better way of doing it than what you've already learned... and you've searched far and wide and come up empty or (b) the area of study becomes easy enough and automatic enough that you don't need to give it much thought... it just becomes automatic.

You'll know when you have something that can be improved when it distracts you away from the problem you're solving... repeatedly and not in an "essential struggle" sort of way, but a "I really wish I was better" at this kind of feeling.

Some level of proficiency is necessary to recognize these pain points and fix them. And the solution is usually to develop more competence, so long as it's in an area that really does matter to your work at hand. These two things work best as a spiral, supporting one another.

[ysavir]

Ultimately, it doesn't matter. The point of the exercise isn't to get better at those specific skills, but to develop an understanding of high-end proficiency, which you can later apply to other subjects.

Like many (proper) learning sets, the content of the exercise is irrelevant compared to the deeper lesson.

[awkward_yeti]

Yes I can see the deeper meaning of the exercise, yet, it helps to know what we're talking about specifically.

I am not proficient yet, and I would like to be, and I don't think it's one of those (When it happens you'll know it) moments, I believe there is a clear set of skills we need to work through first in order to see the forest for the trees.

My question therefore is, what are those skills exactly ?

[practicingdev]

The web of foundational skills for software development is vast enough that you can't really build it out from the bottom up.

What you can do though, is start with small projects and try to understand every piece involved in them, and why you did things the way you did.

Repeat this with increasingly complicated projects, testing and synthesizing what you learned.

[awkward_yeti]

So cross reference the common experiences from different small projects. That does make sense.

Have you done that ? Or are you doing it at the moment ? because some hints of those projects ideas will be awesome.

[practicingdev]

I am the author of the essay, so... yes!

The context I currently apply this in is that in the apprenticeship I'm running.

So for example, we work on business applications and some amount of complex analysis is needed because we work with raw problems (i.e. it's necessary to interview the users/customers directly, collect raw data, etc... collect and transform raw data from many sources before we can even start on a project, etc)

I would start by trying to give my apprentice small chunks of the work we were doing, at a task-based level. She would do fine when I could break it down into well-defined tasks, but not do as well if I just gave her some raw materials and said "OK, implement something that will solve <HIGH_LEVEL_GOAL>"

So we circled around that a lot, and realized part of the issue was the challenge of thinking rigorously and synthesizing lots of details. We dug into Gilded Rose kata together to practice that a bit...

( https://github.com/NotMyself/GildedRose )

Then after that, we went back to some more realistic work, talking things through... taking notes... etc. It helped for a little while, but then we were still hitting issues related to rigorous problem solving / analysis.

So then we went back and did some more exercises. This book chapter gives some examples of the sort of "fundamental lessons" that can be pulled from specific exercises, so long as you're looking at them with the goal of seeing the deeper ideas behind the work you're doing:

http://tinyurl.com/pbp-rigor (PDF)

This is the sort of stuff I've been working on lately, because I don't think there's a direct path towards getting the big picture if you don't have someone guiding you, aside from a ton of hard work and patience combined with continuous practice.

That said... keeping a journal does help. My apprentice has been working with me since the beginning of the year, and she writes notes daily on what she does, what she studies, what she struggles with, etc. Periodically going back through those is how we figure out what to do in practice and study sessions, and I imagine even if working solo... you could try that.

Hope that helps!