You know what you need to build․ You've worked out the requirements and have no other blockers to completing the project․ You've defined what success would look like․ You've found time to work on the project without distractions․ There is one more factor to consider:
Do you know the system you are trying to build?
Modern software tools help programmers write code․ Frameworks provide higher-level abstractions and other benefits․ Artificial intelligence tools help programmers generate new code quickly․ Even if someone writes code‚ that person may not fully comprehend the codebase․
A recommended solution might satisfy all present and known requirements and unit tests but later prove problematic in other ways‚ including design and maintenance issues․
This is where the next part of the CRAFTER framework‚ Technical Mastery‚ can help․
In Part 2‚ CRAFTER Clarity‚ we talked about preparing a solution․
In Part 3‚ CRAFTER Focus‚ we talked about ways to protect the mental resources required to do complex engineering tasks․
Now we discuss strategies for gaining problem-related knowledge and reducing distractions to increase knowledge about technical issues related to the problem․
🧩 What Is Technical Mastery in CRAFTER?
CRAFTER defines Technical Mastery as: 1․
Mastery is the ability to see the system through the syntax.
This distinction is fundamental․ Syntax knowledge allows programmers to use a programming language effectively․ Technical knowledge allows programmers to predict the consequences of running code and whether other systems are affected and under what conditions․ Engineers need information that is not available in API documentation or other resources about specific software frameworks or code snippets․
The purpose of education is to understand the mechanisms beneath abstractions‚ which you can then use to design other systems:
- Stable
- Scalable
- Maintainable
- Predictable
- Architecturally sound
CRAFTER describes three foundational principles related to Technical Expertise․
1․ Low-Level Understanding
2․ Constant R&D
3․ Architectural Reasoning
The practical use of its rules is another benefit:
Spend 10% of your workweek discovering "How" to do things‚ as well as "What" to do․
And it mentions an anti-pattern:
"Copy-paste" engineering and the use of tools not understood by the user․
Let's consider examples of everyday software development to illustrate these concepts․
🔬 1. Low-Level Understanding: Look Beneath the Abstraction
Abstractions benefit programmers․ Programmers use frameworks‚ dependency injection software‚ object-relational mapping software‚ messaging software‚ and cloud-based services to program at a higher level of abstraction․ Abstractions don't eliminate complexity; they just move it․ Programmers who understand the implementation details of an abstraction can contribute more to solving some problems than programmers who only know how to use the abstraction's interface․
Consider an ORM․
You can write a query with the same LINQ expressions that produces the same result․
But do you understand:
- What SQL will this generate?
- What indexes does it use?
- Whether the query is causing unnecessary database round trips?
- What is the performance impact of using change tracking?
- What happens if more than one transaction tries to update the same data?
- How the database execution plan changes with additional data?
It is useful to know Entity Framework Core․
Understanding what happens between your LINQ query and the database is a different skill․
Similar issues exist for other technologies․
| Abstraction | Knowledge required to understand it |
|---|---|
| ORM | SQL and query plans‚ debugging‚ transaction management |
| HTTP Client | Connection pooling and timeout‚ retry‚ and cancellation features |
| Message Broker | Message delivery guarantee and ordering capabilities |
| Dependency Injection | Object lifetimes and scopes‚ disposal |
| Asynchronous Programming | Process scheduling and synchronization |
| Distributed Cache | Consistency‚ expiration‚ invalidation |
You don't need to understand the internal workings of libraries you are using․ There is no point or need to understand them․ You do need to understand the layers involved in your solution to ensure its quality and maintainability․
An abstraction is an aid to engineering productivity․ It is not a replacement for knowledge․
📚 2. Constant R&D: Make Learning Part of Engineering Work
Technical information becomes outdated․ New software frameworks and tools are released․ Systems evolve․ Old technical solutions don't scale․ Engineers who don't keep learning make poor decisions about systems․ The CRAFTER methodology encourages engineers to include research and development efforts in normal working hours‚ in addition to or instead of working on the weekends and other free time․ A recommended practice in the CRAFTER methodology is described․
Spend approximately 10% of your work time learning the "How" of your job's "What․"
This is a general guideline for technical work․ What time someone spends on a job will depend on their specific job responsibilities and other workplace considerations․
The purpose is to allow time for a technical evaluation․
What should you investigate?
For example:
- Learn more about how a feature in a framework works․
- Build using an architecture you are not familiar with․
- Talk about possible solutions to a technical problem․
- Investigate a performance problem․
- Create a small proof-of-concept project․
- Compare the limitations of a library already used in production․
- Learn about new technologies that may improve existing engineering solutions to problems․
Key difference: using vitamin D vs․ learning about it․ Reading documentation is useful․ But trying a small experiment yourself gives you some hands-on knowledge of the topic․ Document your results․
The R&D loop
A simple approach:
1․ Question: State something you do not fully understand․
2․ Research: Study manuals and other materials and technical discussion forums related to the technology․
3․ Experiment: Build a basic prototype․
4․ Evaluate: Compare expected and observed behaviors․
5․ Documentation: Describe uses other than the one studied and problems discovered․
Not all experiments have to become production code․ Sometimes the key result of a project is that you learn to pass up a potential opportunity․ That is a step forward in engineering․
🏗️ 3. Architectural Reasoning: Understand the Consequences of Decisions
Technical Expertise is particularly valuable to engineers who communicate with others about different aspects of a project․ Actions taken by local engineers during implementation may affect other elements of a system․ A new abstraction creates new dependencies․ Useful integration features may create risks․ Simple data design choices may have high future costs․ Architectural thinking includes weighing the pros and cons of various design options․ Architectural thinking does not mean making all implementation decisions at an architectural level․ Architectural thinking does mean avoiding certain implementation decisions with future costs․
Evaluate trade-offs, not just implementation speed
Consider other factors‚ in addition to implementation time․ Here are three approaches to background tasks:
| Method | Advantages | Disadvantages |
|---|---|---|
| Synchronous processing | Ease of implementation | Response times and availability issues |
| Background worker | Separation of request and processing | Higher operational costs |
| Message broker | Decoupling and independent scaling | Message delivery guarantees and other distributed-computing concerns |
There is no correct answer to this question․ The best method depends on several factors related to system design and other considerations that affect system performance․ An engineer with an architectural background asks:
- What issue are we addressing?
- What assumptions does this design make?
- What happens if one of the components fails?
- What are the implications of this approach as the system grows?
- What operational challenges will arise?
- Is this a style other engineers can easily understand and support?
- When would this proposed action no longer be appropriate?
The aim is not to prepare for every future requirement․ The aim is to make smart decisions about present needs․
Make important decisions visible
If a technical decision has long-term architectural impacts‚ document it․ Documented technical decisions are known as Architecture Decision Records (ADRs) and may include:
- Context and problem․
- Considered alternatives․
- The selected approach․
- Reasons for making the decision․
- Expected risks and limitations․
This prevents loss of valuable technical knowledge held only by one individual․ This approach also makes it easier to modify the work in the future․
⚠️ The Anti-Pattern: Copy-Paste Engineering
One of the anti-patterns directly listed by CRAFTER Technical Mastery is Copy-paste engineering․ Copying code isn't necessarily unethical․ It's common and often encouraged for developers to rely on others' sample code and designs‚ along with preexisting libraries and patterns․ Unethical behavior includes copying without making an effort to learn․ Consider the following situation․ A software engineer encounters a new technical problem and finds a relevant code sample online․ She copies the code sample and makes small modifications for use in her own project․ The project is completed successfully‚ though the engineer does not know:
- Reasons for the initial decision․
- Assumptions made in favor of it․
- Whether the assumptions hold for the current system․
- Other dependencies required by the plugin․
- Error handling․
- Whether the copied answer is relevant to the current system architecture․
The result will include working code but lack conceptual depth․
Why is blind copying and pasting risky?
1․ Context is lost
Code written for one environment may take advantage of features not available in other environments․
An implementation approach that works for small applications is not appropriate for distributed systems․
2․ Complexity accumulates
Copied code increases the number of abstraction layers and other requirements and maintenance activities․
3․ Implicit assumptions are a form of technical debt
A solution may work in situations that are not specified or recorded․
When these conditions change‚ the code may be difficult to troubleshoot․
4․ Debugging becomes guesswork
If the engineer is unfamiliar with the component‚ testing the component may involve a process of elimination․
5․ Knowledge doesn't grow or expand
The immediate emergency need is met․ Other technical needs are not met․
The same risk applies to AI-generated code․
An AI assistant can implement a solution․ Code produced by an AI assistant may not be secure or appropriate for other reasons to use in your system․ The engineer must be aware of and confirm the outcome․
A better approach: Learn‚ Try‚ Confirm
Instead of imitating the design‚ use a systematic process:
1․ Understand: Learn about the functionality of the original code․
2․ Evaluate: Check assumptions and other requirements and assess effectiveness․
3․ Adaptation: Modify the solution to fit current systems and constraints․
4․ Test: Test under normal and abnormal operation and failure conditions․
5․ Explain: Be ready to discuss the pros and cons of adopting this practice․
A practical engineering test is this:
Can you explain what this code does and how and why it might be affected by changes to underlying assumptions?
If the answer is no‚ additional research may be needed on implementation․
The purpose is not to decrease code reuse․
It is to discourage recycling of code mindlessly․
🤖 Technical Mastery in the Age of AI-Assisted Development
AI coding tools are changing the economics of software development․ Software can be produced more quickly with AI coding tools․ Faster production of software does not always lead to better engineering․
In fact‚ the ability to generate large amounts of code makes Technical Expertise more valuable․
An engineer who understands the system can apply AI technologies to:
- Explore implementation alternatives․
- Generate repetitive code․
- Investigate unfamiliar APIs․
- Create test cases․
- Prototype architectural approaches․
- Improve documentation and other research efforts․
But the engineer should verify the results:
- Does the generated code follow the system's stylistic guidelines?
- Does it introduce additional dependencies?
- Are concurrency and failure scenarios handled appropriately?
- Does it fit with the domain model?
- Can the implementation be maintained?
AI tools should be used to enhance an engineer's capabilities‚ not substitute for an engineer's judgment․
The value of an engineer is not determined by the quantity of code they write but by the quality of the decisions they make about the code they write․
🧭 Technical Mastery as an Engineering Expectation
Technical Mastery in CRAFTER is more than a learning preference․ It is an expectation for CRAFTER engineers․ The CRAFTER Engineering Culture document describes CRAFTER engineers as self-correcting systems․ One belief associated with Technical Mastery is that technical knowledge is a useful asset that declines with disuse․ Some applications of this belief include the following․
Understand before implementing
Expectation at Cognitive Clarity:
If you can't answer the questions Why? and How?‚ you're not prepared to write code․
An engineer should be able to explain and give examples of a problem and the solution to that problem‚ as well as fundamental concepts related to the solution․
Reinvest in technical skills
Technical knowledge is not permanent․ Technology and other elements can make previous knowledge obsolete․ Engineers are expected to acquire new technical knowledge every week through exploration and other activities․
Protect the conditions for mastery
Technical skills require time and attention․ The Focus principle encourages providing time and attention for workers to learn about new processes and choices․ Technical skills may otherwise be only minimally developed․
Make technical decisions explicit
Technical conversations should be formalized․ When making a decision with technical consequences‚ document relevant technical details about the decision and other options‚ as well as expected outcomes․
CRAFTER deals with Decisions and Dispenses with Discussions: Technical decisions should be recorded in ADRs․ Other agreements made in discussions and meetings should not remain undocumented․
Take responsibility for what you build
Technical Skills are linked with Ownership․ Engineers shouldn't only be able to write code that compiles․ They should understand the internals of their implementations and other technical information and be interested in and concerned with edge cases and having ownership of their work from beginning to end․ Activities like these can help align individual engineers' interests with the interests of the organization as a whole․
Mastery is not best measured by self-assessments of engineers but by how well engineers reason‚ make design choices‚ and create systems․
📊 Measuring Technical Mastery
Technical skills are hard to evaluate․ Comparing engineers by the number of courses completed and technologies learned is not a good way to evaluate technical skills․ The number of courses and technologies learned tells us nothing about an engineer's technical judgment․
CRAFTER defines three diagnostic indicators of technical skills․ These indicators are intended to identify improvements in engineering capability and should not be used as performance measures to evaluate and monitor an engineer's productivity․
1․ Complexity Handling
What it measures:
Monitoring completion of more advanced architectural tasks․
Why it matters:
An engineer's technical skills are best measured by the engineer's ability to understand and implement more complex engineering tasks․ It doesn't matter how many engineering tasks an engineer has implemented․ What matters is how much more complex an engineering task an engineer can implement․
2․ Solution Quality
What it measures:
The number of regression defects found on completed tasks within 30 days of release․
Why it matters:
A solution is not valid just because it succeeds in early tests․ Its effectiveness can be tested by using it in its intended environment and with other system elements․ Such tests may reveal problems with testing or design of the component or system․
3․ Automation Ratio
What it measures:
The percentage of repetitive manual tasks successfully automated this month․
Why it matters:
Repeated manual tasks indicate that you should spend time engineering tools and solutions to eliminate manual tasks․
Automation reduces errors caused by people and frees engineers to work on more important‚ higher-value projects․
Technical Mastery Metrics at a glance
| Metric | Measure | Use |
|---|---|---|
| Complexity Handling | Successfully complete all high-architecture assignments | Evaluate technical skills |
| Solution Quality | Number of bugs and regressions found in completed tasks within 30 days of release | Identify quality risks |
| Automation Rate | Percentage of routine manual tasks automated this month | Identify tasks suitable for automation |
These actions should be taken into account with other information․
For example‚ regressive practices may result from poor understanding of customer requirements‚ not a lack of technical skills․ A low level of automation may result from few opportunities to use automation in the job․
Metrics are not a type of monitoring․ They are measurements․
Their job is to evaluate the company's engineering processes and look for improvements․
🔮 What's Next?
Technical skills allow engineers to develop strong systems and make technical judgments․ But knowledge does not automatically result in good outcomes․
In the next part of CRAFTER‚ we will address Execution‚ the engineer's capacity to deliver quality outcomes based on knowledge and other inputs․
🧬 Conclusion: Mastery Is the Ability to See Beyond the Code
Software engineering is not simply the act of translating requirements into source code. It is the discipline of understanding systems, evaluating constraints, managing complexity, and making decisions that remain useful beyond the immediate implementation. Technical Mastery is built through continuous investigation and deliberate practice.
It requires engineers to:
- Understand the mechanisms beneath important abstractions.
- Invest time in research and experimentation.
- Reason about architectural consequences.
- Evaluate trade-offs instead of following trends.
- Avoid blind copy-paste engineering.
- Verify generated and borrowed solutions.
- Learn from defects and improve technical decisions.
- Share knowledge so that expertise becomes part of the engineering system, not a single person's advantage.
Cognitive Clarity helps identify the right problem. Focus protects the ability to work on it.
Technical Mastery develops the knowledge and judgment required to solve it well.
The goal is not to know every technology. It is to understand enough to make the right engineering decisions.
That is Technical Mastery in CRAFTER.
Software engineering is more than coding a software product․ Software engineering involves learning about systems and making future-oriented decisions․ Building expertise in software engineering requires continuous education and experience․
It requires engineers to:
- Learn about the fundamental concepts of important abstractions․
- Take time to research and experiment․
- Consider architectural issues․
- Make trade-offs instead of decisions based on fashion trends․
- Do not simply reuse objects without checking if they are appropriate․
- Review current and proposed solutions․
- Use defect reports to make better technical decisions․
- Share knowledge to help other members of the engineering team gain your expertise․
Cognitive Clarity helps you identify problems to work on․ Concentration helps you stay focused on the problems you're working on․
Technical knowledge helps ensure that the person asked to address the issue has the necessary knowledge and skills to do so․
The goal is not to be familiar with all technologies․ The goal is to be familiar enough with each technology to make responsible engineering decisions․
That is Technical Mastery in CRAFTER․
Top comments (0)