blog: communciate clearly

src/content/blog/2022-04-10-recognise-and-reduce-risk.md

@@ -28,6 +28,6 @@ If you know your customer is extremely price sensitive, then building a $99/yr s
 
 Risk is risk.  Risk from product (what) and risk from engineering (how) cannot be meaningfully separated once you take more than three steps backwards.  
 
-Your job is to reduce risk for yourself, your boss, or your company.  If you have any interest beyond the pure craft of software, aim to reduce risk for the most number of people possible
+Your job is to reduce risk for yourself, your boss, or your company.  Build software that reduces overall risk for the people who use it.
 
 [^1]: I think we (I) separate the _what_ from the _how_ because they are often solved by a CEO and CTO.  Just because a problem is solved by two people does not mean it is two problems.

src/content/blog/2022-11-05-communicate-clearly.md

@@ -0,0 +1,38 @@
+---
+title: "Communicate Clearly"
+date: 2022-11-05T17:08:10Z
+slug: 2022-11-05-communicate-clearly
+author: Thomas Wilson
+---
+
+The hard thing about most ideas is arriving at them.
+
+Most ideas themselves are easy.  For example:
+
+* Many smaller changes to software reduces the chance that a single change can break things.
+* People who exercise more are more likely to live longer.
+* Everyday somebody is discriminated against because of where they were born, who they love, or what they believe.
+
+Always try to communicate clearly.  This is especially true when you're communicating with other people.
+
+I am a recovering over-explainer.  
+
+By always explaining and contextualising, I was communicating less clearly.
+
+For a long time I would say (or write) an idea alongside the journey of how I got there, or the consequences/next steps. 
+
+I thought I was making my point clearer.
+
+I thought you always wanted to help someone think how you think, or understand why something is/not good/bad.
+
+Sometimes you can dilute an idea, suggestion, or observation by explaining it.  It makes your point less clear.
+
+Other times, the explanation is just too unfamiliar, and _you_ are the one with the expertise.
+
+Either way, the explanation of the thing you're trying to say probably isn't as interesting (or relevant) as the thing itself.
+
+Explanations can take up a lot of the air in a room.  They take time to say, and energy to understand.  That's time and energy that could be spent doing the thing you're saying.
+
+As you become more of an expert, people (rightfully or not) expect you to have made the explanation or assertion.  
+
+

src/routes/engineering-principles/+page.svelte

@@ -0,0 +1,47 @@
+<script lang="ts">
+	import Navbar from '$lib/components/Navbar.svelte';
+</script>
+
+<Navbar />
+
+<main class="thomaswilson-container">
+	<section class="main">
+		<h1 class="main__text">Software Engineering Principles</h1>
+		<p class="main__text">This is a collection of things I've learned about, and while, building software. <br />  
+			They are best guesses. <br/>
+			I reserve the right to be completely wrong about all of them.</p>
+	</section>
+
+	<section>
+		<ul class="principles">
+			<li class="principles__item"><a href="/blog/2022-10-22-maintenance-plus-plus">Make your software opinionated</a></li>
+			<li class="principles__item"><a href="/blog/2022-03-13-discover-complexity">Discover Complexity</a></li>
+			<li class="principles__item"><a href="/blog/2022-03-02-concentrate-on-concentrated-tests">Concentrate on Concentrated Tests</a></li>
+			<li class="principles__item"><a href="/blog/2021-12-12-build-the-platform-ship-the-product">Ship the product, build the platform</a></li>
+			<li class="principles__item">
+				<a href="blog/2022-04-10-recognise-and-reduce-risk">Recognise and Reduce Risk</a>
+
+			</li>
+		</ul>
+	</section>
+
+</main>
+
+<style>
+
+	.main {
+		border: 1px solid black;
+		padding: 12px;
+		align-text: center;
+		display: grid;
+		place-content: center;
+
+	}
+
+	.main__text {
+		text-align: center;
+		line-height: 180%;
+
+	}
+
+</style>