I have a good five digit amount of cash prepared. That's enough to buy plane tickets and pay drivers to get where I want.
I live in Europe and not far away from me is one of the largest European pagodas - even the Dalai Lama has been here. I'd just go there to start my journey. I could stay there for some time.
Actually, I think it's like it is always with the Buddhism; the plan is not to have a plan.
what if I want to start my contribution I just don't know which project to choose ? this assumes that I already know the project I want to contribute to.
Usually people begin by contributing to projects which they already use. For a beginner, it might be better to start contributing to a project which is mainly written in the language which they're familiar with. Also, try to find a project which is beginner friendly; they usually have some issues marked as 'beginner' or 'good first bug', and also have a CONTRIBUTING.md page.
Bonus: A good idea is to start contributing to a project which contain problems sets to be solved by coding the solutions in a particular language. You could send PRs for creating/implementing some problems. http://exercism.io/ is a good example.
For almost any project there is an infinite amount of work to do. Check out OpenHatch for opportunities, or just dive in for things you rely on. Big communities are great too, checkout Linux or one of the distros:
It's hard to put my finger on exactly what it is I don't like about it. After rereading the table of contents I certainly don't disagree with some things (gdb, valgrind, version control, package management, are all good things).
I think my biggest beef is it seems to approach C as if it is a general purpose language, and I would argue that in the 21st century C is no longer a general purpose language. It is at its best now when used for systems programming, embedded programming, and making portable libraries (and the last is also no longer the exclusive domain of C, as besides C++ there are a couple other languages that can export C abi compatible functions and have unobtrusive runtimes).
Also, Klemens seems to like autotools. I don't hate autotools as much as others, as I remember a world before autotools was ubiquitous and it truly sucked. However, the combination of compilers not sucking like they used to (if you are using C99, you have a lot more features than you did on some crappy PCC derived vendor supplied compiler, even if you stick only to pure C99, and the odds of your compiler not "just working" on the C99 code is pretty slim) means that for simple projects a makefile that respects the CFLAGS, LDFLAGS, CC &c. is sufficient; for larger programs, there are serious alternatives to autotools. Obviously none of them are as dominant as autotools, but cmake is certainly prevalent enough to be a good place to recommend people start at.
> 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 ?
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.
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.
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 ?
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...
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:
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.
