Deeper understanding of the code and software systems we work on, is not only pragmatic and practical but highly enjoyable as well.
The usefulness is quite obvious: understanding gives us control and ownership of the systems and code we are responsible for. What we do not understand, we can neither fix nor change.
Interestingly, that deeper understanding not only allows us to be masters of our tools and not their slaves, but also is simply fun and brings lots of joy. There most likely are solid evolutionary reasons behind it - why is comprehension so psychologically satisfying? It actually makes a ton of sense - behaviors and traits that increase our control over the environment should be accompanied by feeling positive emotions strongly.
But, if it is both joyful and powerful, why are we so often prone to skip the struggle to understand and take shortcuts, accepting copy-pasted/generated solutions and generic answers, not analyzed?
At our core, we are lazy beings, driven to minimize our energy expenditure and maximize returns on its investment.
This laziness can be a great motivator to automate tedious and expensive processes and tasks, but at the same time, it is our inherent flaw when it comes to learning, expanding our knowledge, skills and by extension - control, influence and power (in healthy hierarchies based on competence).
In the context of a need to understand, given how many answers & solutions to similar problems are available out there on the Internet - recently even more than ever before and in the exact form we need, thanks to Large Language Models (LLMs) - it is no wonder why people skip on understanding so often by taking those shortcuts. Unfortunately, there are many pitfalls in accepting something that seems to work but we cannot explain how and why.
After all, why bother with learning the syntax and inner mechanisms of SQL (or any other query language), when we might just tell the LLM what tables are there and the data we want to retrieve. It is way easier to write a messy English prompt and copy-paste the result than to learn how to do it properly ourselves.
And I hear you, some people would say something along the lines:
Why should I trouble myself with constructing SQL by hand if I know it? LLMs can do it much faster for me and I do not lose anything, since I am already perfectly able to write and read this language.
Well, it really depends; you might be capable of reading and understanding it today, since you have done it repeatedly by hand in the past, but this ability will diminish over time. Eventually, we do lose what we do not use - and passive reading is not enough to keep these skills sharp. Sure, you may argue that since there are LLMs (and other reusable solutions), we will never have to write these types of things again and that the skills of searching, prompting, reading and verifying LLMs' output is all we need - it is the future. Well, given how LLMs work under the hood (probability), I would say that it is a highly optimistic and unfounded claim (ignoring LLMs long-term sustainability for now). Regardless, at their best, LLMs and other search engines are force multipliers - but we must have the force first and keep it strong. What is this force exactly? It definitely is not the ability to prompt and read the output. I do not see how we can develop and keep it sharp, if we are generating and copy-pasting solutions (maybe with a bit of refinement) all the time. Fortunately or not, struggle is a necessary component of deeper learning and mastery.
Of course, context is king here. For some skills, areas that we rarely use and do not care about that is totally fine, but our core skills and knowledge regularly used must be kept as strong as possible - otherwise, what is that defines us as software developers and problem solvers? Isn't it exactly our knowledge, experience, judgement and skills? It is impossible to develop and even keep it by just reading the code and solutions of other people and machines - we have to be actively engaged in the building and creation process ourselves.
That is why, in the context of understanding, we must fight against our lazy nature on a regular basis - spending much more energy than is required in order to keep expanding our knowledge, skills and by extension - control, influence and power. We ought to read the docs and sources. Grasp the reasons behind solutions under consideration. Know our tools and understand the tradeoffs they introduce. Engage creatively and design solutions & algorithms ourselves - do not just search/prompt and passively verify, hoping to get some working solution; somehow, someday, maybe.
Practically speaking, does it always make sense to grasp the code and solutions we work on fully?
Of course not - it depends and it is a spectrum.
Throwaway script that automates an operation of low importance and risk? Completely fine to copy-paste/generate. Internal UI/page used by two or three people? Same here; nothing wrong with copy-pasting/generating that one as well.
Code and solutions that we will own, maintain and evolve over months and years? They should be created in a language and technology we know deeply and can understand every line, word, character and/or config option (or at least are on a path for it to be the case). Here, we want to optimize for long-term understanding, maintainability and productivity, not the fastest & largest output at this very moment.
Are there in-between cases? Situations where we might reuse/generate something grasped only partially, requiring us to take more time to understand, fix and modify when such need arises?
If we work on a Minimum Viable Product (MVP), not being sure whether it makes sense/is going to work, or an experimental feature within the existing product - it is reasonable to lower the quality and comprehension standards a bit. After all, we cannot yet tell whether potential results justify the invested effort. We can treat it as taking on a cognitive debt - it allows us to move faster here and now, but we will have to repay more later on (if the product/feature works or fixing and/or modification is needed). But still, we must at least be able to grasp and verify it up to a point where we can confidently say - it works. Nobody is going to use and pay for broken products and half-working features. I would then also ask: is generating something the best way to find out whether there is a need and want? Maybe a better idea would be to get this knowledge first and then build a considered product/feature in the right way? But sometimes, it might be the case that generating, validating and rewriting it from scratch is a reasonable strategy to take.
A similar approach could be taken when it comes to technology stack - if we use a certain programming language, library or a tool just from time to time, it probably does not make much sense to invest time in deeper learning and mastery. Copy-pasting/generating something we understand partially but can verify results of, is sometimes perfectly fine. But again, here lies the tradeoff - by not going through the learning phase and struggle, where it is natural to be slower, we rob ourselves of the possibility of ever mastering given technologies and becoming productive with them. For our core technology stack - languages, libraries, frameworks and tools used regularly - mastery pays off hundreds and thousands of times. Not only are we more independent, since we just know things, but even more importantly - knowledge and skills have a compounding effect. The more we know and are able to do, not only we can build things on our own faster, but also acquire new knowledge and skills at an ever increasing pace. Coming up with new solutions and novel ideas is another side benefit of constantly increasing our competencies. That is why, we must never give up on learning and constantly pushing our cognitive capacities to their limits and beyond.
Related to the productivity topic touched on above is a problem of definition. How do we even understand, measure and evaluate productivity?
There are two main schools: output- and outcome-driven.
Measuring output is easy:
There are problems with this type of output-driven approach though:
If we focus more on the outcomes:
Of course, many spreadsheet-driven managers prefer outputs to outcomes, since it is often harder to measure the latter in numbers alone; they require more context to evaluate correctly.
It is a slightly different discussion, but I would argue that it is wiser to focus more on outcomes and less so on outputs. Long-term productivity and understanding is much more aligned with outcome-driven metrics: not every output makes sense; more is often not better and sometimes, reducing/taking something away is what actually adds value.
As the Fundamental Theorem of Software Engineering states:
Any problem in computer science can be solved with another level of indirection, except for the problem of too many layers of indirection.
Complexity of modern software development can be truly mind-boggling at times. How do these systems even work and are maintained? There are so many layers, components and factors, ever growing it seems:
What to do about this dizzying Complexity? Is it possible to understand even partially? There are so many layers, components and factors!
Worry not, there are some good news:
Let's focus on the latter.
What are Fundamentals?
Fundamentals are the most basic, rarely changing rules, constraints and mechanisms underlying tools, libraries, frameworks, protocols and various components used to develop software; as well as the core principles governing computers and computation.
A rather comprehensive list would be:
That is a lot! But let's remember that we do not have to and it most likely is not possible to master all those branches - but we should know a bit about each of them, aiming to become great at the chosen few.
When our focus shifts to these fundamental principles, over time, we develop certain universal intuition, a powerful meta-skill. Understanding deeply how computing & computers work, alone and in clusters, we are able to quickly grasp and foresee what is possible. Then, we are not bogged by the ephemeral details of always-changing tools, libraries, frameworks and approaches. Ironically or expectedly, once we have reached this level, it actually becomes a piece of cake to learn any new shiny object of the current day. That is something worth striving for!
As Leonardo da Vinci has said:
The noblest pleasure is the joy of understanding.
And as we have seen, in the context of software development, it gets even better - it is highly practical too, bringing us a lot of influence and making us powerful. The scope of software engineering is tremendously vast, but if we focus on Fundamentals, we can master it.
Let's then have the right focus and always keep pushing beyond our current cognitive capacities - experiencing pure joy regularly and gaining a lot of influence and power in the process!
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。