The way I use it is to assume certain things, and then consider the consequences of them. I wish I could have discussed this more in the article, but the specific example got long enough that a theory tie-in would have been a lot for a blog post.
But anyway, things like feedback loops (both positive and negative), oscillations, stocks, flows, control points, system boundaries, etc. etc. -- these are all tools for giving both names and operational patterns to different things you'll see happen in a system.
And once you have that, you end up with a better mental model from first principles that lets you anticipate and work with certain aspects of systems before you learn its behavior through trial and error / best practices.
I need to dig deeper myself, but I found "Thinking in Systems" from Donella H. Meadows a good primer on the basics . So far the best benefit systems thinking has given me is a changed perspective on things, but I think it'll help for doing more detailed analysis with a bit more study and practice, too.
Also, if you're looking for a whole book on systems thinking, albeit in a more general context, it's worth checking out "Thinking in Systems: A Primer" by Donella H. Meadows.
Once you start thinking about this stuff it's impossible to not see it everywhere. But for programmers, ops people, etc. that's a good thing... because our jobs depend on it.
I wasn't expected this to be posted on HN, but I'm happy to discuss in the comments rather than having folks head over to Twitter.
I assume many people here already are self-employed or work remotely, but I can throw in my two cents on any questions you might have if you aren't... or if you are but just want to hear from someone else's perspective.
Salience is a big part of proficiency. If you're productive and familiar with a tool, and it wouldn't be terribly important to your actual needs to optimize that aspect of things... then even in the situation where there might be a better tool out there, it'd be fine to stick with what you know.
But on the other hand, if you struggle with a tool because you're using it in the wrong context, and you're either not aware of that because you're missing the bigger picture... or you're aware of it but refuse to step away from dogmatic best practices to customize for the situation at hand... then that's a bad thing.
So, the question of whether or not to go and find "the best tool" is a matter of whether it's salient in the context of the problem you're solving (and a bit more generally, the kinds of problems you solve day to day)
So proficiency involves to some extent choosing what not to learn as much as it does what to learn.
(1) Novice... does not understand anything but basic knowledge in the abstract sense
(2) Competent... knows how to apply knowledge to solve concrete problems
(3) Proficient... sees how particular solutions fit into the context of different problems (i.e. what tools to use, when, and why)
(4) Expert... picks the right tool for the job without having to do careful analysis... works from intuition by pattern matching against fundamental concepts combined with past experiences.
(5) Master... picks the right tool for the job without even being consciously aware of the fact that they're "doing work" at all.
It's important to remember that all of these levels apply within specific contexts... you can be master one thing while being a novice at many other things.
But each step along the path is a gate of sorts: in that you can't really understand what it's like to be an expert in anything until you're an expert in at least one thing, and building expertise is easier when you have done it at least once.
But a big problem (which we're mentally hard wired to be biased about) is evaluating our own skills, as well as the scope of experience of others.
This is why someone with local expertise often thinks they can speak on topics outside of their actual expertise, and why people tend to believe them when they do.
"Thinking, Fast and Slow" by Daniel Kahneman is the best book I know on that topic. Totally worth reading.
To me the terms are roughly interchangeable if taken in their general meaning, or at least easy to confuse with one another.
But when I wrote this article, I hinged it off of specific definitions assigned to the terms in the Dreyfus Model, which although not exactly commonplace, is an established bit of literature (for example, Pragmatic Press uses Dreyfus Model to indicate expected skill level for readers of their books)
So I stuck with their definitions and attempted to restate those definitions (informally) in the article.
But I'd be fine with you calling these Thing 1 and Thing 2, as long as they mapped to the definitions provided.
What the article refers to as competence (Thing 1) is something programmers generally recognize as valuable, because it is valuable! Essential, in fact.
What the article refers to as proficiency (Thing 2) is something programmers probably also recognize as valuable, however... many do fall into the trap of thinking this: Thing 2 is what you get from being really good at Thing 1 in many areas.
In truth, Thing 2 is what you get from being halfway decent at Thing 1 in many areas, and then with a view of the bigger picture, getting really good at specific aspects of Thing 1... in the context of your actual work, goals, etc.
In other words, Thing 2 = Thing 1 X TheBiggerPicture.
Now if I were to use my own way of thinking about this... I actually thing of Thing 1 (competence) as tactics, and Thing 2 (proficiency) as strategy.
But I think that could end up leading to an even more confusingly overloaded set of terms.
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.
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.
But anyway, things like feedback loops (both positive and negative), oscillations, stocks, flows, control points, system boundaries, etc. etc. -- these are all tools for giving both names and operational patterns to different things you'll see happen in a system.
And once you have that, you end up with a better mental model from first principles that lets you anticipate and work with certain aspects of systems before you learn its behavior through trial and error / best practices.
I need to dig deeper myself, but I found "Thinking in Systems" from Donella H. Meadows a good primer on the basics . So far the best benefit systems thinking has given me is a changed perspective on things, but I think it'll help for doing more detailed analysis with a bit more study and practice, too.