Fixed hierarchy in se post

1 files changed, 5 insertions, 3 deletions

diff --git a/content/posts/software_engineering.md b/content/posts/software_engineering.md
index de19077..5369ce6 100644
--- a/content/posts/software_engineering.md
+++ b/content/posts/software_engineering.md
@@ -3,7 +3,9 @@ title = "Notes on Software Engineering"
 date = 2025-02-04

 +++

 

-I worked at a large software company, [SAP](https://www.sap.com) for three years. But I didn't get to learn much about software engineering. SAP has its own tools and process that have already dictated how things work. But over the years, I have realized how important software engineering can be. Here I outline some of the lessons I have learnt (some with a lot of pain) about this. If you are reading this and don't know where you or ytour team stands on software engineering, take the [Joel Test](https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/).

+I worked at a large software company, [SAP](https://www.sap.com) for three years. But I didn't get to learn much about software engineering. SAP has its own tools and process that have already dictated how things work. But over the years, I have realized how important software engineering can be. Here I outline some of the lessons I have learnt (some with a lot of pain) about this. If you are reading this and don't know where you or ytour team stands on software engineering, take the [Joel Test](https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/). This is a living list and will be kept up to date based on my experiences.

+

+## Lessons learnt

 

 ### Terminal is the superior interface

 

@@ -33,11 +35,11 @@ Using the right tool for the right job is crucial. One could use C programming f
 

 Automation isn't always necessary. For activities that don't need to be repeated, things don't have to be done cleanly. However one needs to keep in mind that the above chart doesn't take into account if multiple people repeat the task. Automation also brings benefit in terms of consistency (all the results looks the same) and prevents errors in processes that are repeated many time. Humans are not made to repeat the same thing over and over again, we fail at it terribly.

 

-## A bit of documentation goes a long way

+### A bit of documentation goes a long way

 

 Maintain at least a [README](https://www.makeareadme.com/) file. This allows for people to understand what you are trying to do. Comments in code should describe what is being done, the code should do this. Comments are to be used to describe why something was done in a particular way. Even documentation should be limited because someone will have to maintain it. Documentation should help either the user or the developer, if not, it isn't necessary.

 

-## Tooling defines the friction in your process

+### Tooling defines the friction in your process

 

 Simple, fast and open tools are usually better in most cases. They allow for quick onboarding of team members, easy deployment of work and access to a larger community of experts. Understanding your tools also goes a long way in helping improving processes. A developer should be fighting with his tools; the tool should augment the performance of the developer. Standardize tools if possible but engineers usually bring a carefully crafted and deeply personal toolset with them; account for this.