Making Obsidian Really Work

While documenting with Obsidian and Github Markdown, following tips have been most useful:

Headings...

are H1 to H6, use # sign the number of times you want the heading type e.g. #### is for H4

Linking... 

• to a document: type `[[`, a list of documents you can link to appears
• to a heading in another document: type `[[`, a list of documents you can link to appears, select the document to list, the use `#` sign, the headings that can be linked appears, just click the heading to link to
• to a text block in another document: type `[[`, a list of documents you can link to appears, select the document to link to, the use `^` sign, the text blocks that can be linked appears, just click the text block to link to
• to a heading in another document: type `[[`, a list of documents you can link to appears, select the document that is currently being edited, the use `#` sign, the headings that can be linked appears, just click the heading to link to
• to a text block within the document: similar to anchor tags, type `[[`, a list of documents you can link to appears, select the document that you are currently editing, list of text blocks in the document appears, select the text block to link to

• to an image

            ![[AbsolutePathOfImage]]

• to an image with an alternate name to display

            

• to an image and resize

            ![[AbsolutePathOfImage|500]]

Using tags

#FollowedByNoSpace is a tag, used in search and in generating automated knowledge graph management

Arrows

• Up arrow (↑): ↑ 
• Down arrow (↓): ↓ 
• Left arrow (←): ← 
• Right arrow (→): → 
• Double headed arrow (↔): ↔

Colouring the text...

• View developer console --> (on Mac: ⌘ + option + i)
• And then edit CSS elements when it becomes necessary

Superscript or Subscript

• Prefer to use latex formats
• Superscript ^
• Subscript _

OR

• In the developer console, use html tags 
• ^{some text}
• _{some other test}

Managing Technical Debt

Introduction

The gap between the current state of a software system e.g. inefficient code, design flaws, missing documentation etc. is usually called technical debt. It represents the future cost that will be incurred when addressing such shortcomings e.g. as fixing bugs, refactoring code, improving documentation, making the system more secure and scalable.

Technical debt, incurred intentionally or unintentionally is not necessarily a bad thing in all cases. In some situations, technical debt results from strategic decisions made to meet urgent business needs or to gain a short term but competitive advantage. However, it must be managed and paid down over time to prevent any overwhelming hinderances to future development. 

Technical Debt Management Framework

To effectively manage technical debt, it must be recognised, documented, and tracked as part of the software development process. This helps make informed decisions about when and how to address the debt by balancing short-term goals with long-term sustainability and quality.

The industry recognises and categorises a number of forms of technical debt. However, the following are of most interest for an investment banking enterprise:

Difficulty column gives an indication of effort that may be invested in managing and repaying a given category of the debt. As an example, the commonly identified 'Architecture and Design Debt'  is quite difficult to identify and measure in hindsight, because the decisions are soundly supported by business needs. Usually 'Architecture and Design Debt' is also closely related to other debts e.g. 'Integration Debt' and thus very difficult to even monitor and track. This debt is also very difficult to repay since architecture and design are rarely revisited without motivation and certainly not only with just the intent to repay by remediating and refactoring code.

The framework considers 'Architecture and Design Debt' as an umbrella encompassing 'Code Debt', 'Performance Debt' and others as remediation sub-categories (add a column) with the following considerations:

• Performance Debt: Monitor performance using APM tools, identify performance bottlenecks | Set performance benchmarks, track metrics | Continuously monitor performance, allocate resources to address issues | Variability of workloads, difficulty in isolating performance causes | 
• Code Debt: Evaluate code quality using metrics such as cyclomatic complexity and code duplication | Maintain code documentation | Conduct code reviews, implement automated code quality checks | Complexity of large codebases, rapidly evolving code

One may want to add 'Skills Debt' to the framework. It is medium difficulty, can be more scientifically measured & remediated and helps to repay other types of technical debts by a well managed and self motivated team.

The framework as well identifies challenges to expect and lists some generic steps that could be taken to alleviate the issues while actively managing and repaying technical debt.