clean up formatting

Signed-off-by: S Smith <[email protected]>

src/content/architect.md

@@ -1,44 +1,46 @@
+Why are employers so eager to hire average employees? Is curiosity a crime now? It hasn't been enough to be "T-Shaped" in a decade or more, you've gotta at least be "M" shaped.
+
+During my latest interview process, I kept hearing some really strange feedback. Honestly, I couldn't make heads or tails of it. Maybe you can.
+
 > Thanks for your application. We really enjoyed speaking with you. 
 > You have a lot of interesting and relevant experience. I'm not convinced 
 > we can offer you the scope of work and hands-on architecture exposure
 > you mentioned you were looking for. Can we keep your details on file
 > in case anything more relevant comes in?
 > 
-> Regards,
->
-> You, Probably
+> ***You, Probably***
 
 Dear You,
 
 I'll take you at your word that you enjoyed our conversation. Shall we continue it?
 
-If any of your roles say, "Just show up and do whatever, because you're special," I'll take that one instead. Alas, nobody's ever offered me that before. My scope has always been boilerplate data entry, one byte at a time into a syntax checker, doing my part to keep the lights on. If that's a generic description, it's because it's the only way to cover everything.
+If any of your roles say, "**Just show up and do whatever, because you're special**," I'll take that one instead. Alas, nobody's ever offered me that before. My scope has always been boilerplate data entry, one byte at a time into a syntax checker, doing my part to keep the lights on. If that's a generic description, it's because it's the only way to cover everything.
 
 Despite years of working as a Senior `________` Engineer and not caring much how you fill in that blank, I've never had a job in tech I didn't like, and my coworkers have always been outstanding. When you can tick both of those boxes, the work never gets tedious, so you never burn out. If you're insinuating that I need to raise Cain to stay motivated, I politely reject your assessment.
 
-A few years ago I, too, saw the patterns that led to your conclusions. I've made conscious choices to keep my good patterns and stop my anti-patterns, but you couldn't have known that, or my judging criteria. It wouldn't be fair to say "you're wrong, you don't know me" without breaking down some of those choices in detail. If you are sincere in considering me for other roles, you'll have to get to know me eventually, so why not now? Here goes.
+A few years ago I, too, saw the patterns that led to your conclusions. I've **made conscious choices** to keep my good patterns and stop my anti-patterns, but you couldn't have known that, or my judging criteria. It wouldn't be fair to say "you're wrong, you don't know me" without breaking down some of those choices in detail. If you are sincere in considering me for other roles, you'll have to get to know me eventually, so why not now? Here goes.
 
-One of the patterns I chose to keep was taking purposefully diverse roles, technologies, tasks, and industries. Being a greenhorn in something is really hard, but I know of no better way to grow. The bonus I didn't expect: I got a lot of practice at getting up to speed. I start contributing in days, not months.
+One of the patterns I chose to keep was purposefully **taking diverse roles, technologies, tasks, and industries**. Being a greenhorn in something is really hard, but I know of no better way to grow. The bonus I didn't expect: I got a lot of practice at getting up to speed. I start contributing in days, not months.
 
-Still, simply growing is not enough - you need to grow towards something. I picked quality. It sounds narcissistic, but I didn't choose it for the connotations of superiority, or the higher pay, or truthfully, even for the pride of a job well done. 
+Still, simply growing is not enough - you need to grow towards something. I picked **quality**. It sounds narcissistic, but I didn't choose it for the connotations of superiority, or the higher pay, or truthfully, even for the pride of a job well done. 
 
-The first reason is because quality is one of the few things in this world that isn't up for debate and doesn't change as years pass. It's remarkable to me that five people from anywhere in the world can look at a table, or a video game, or art, or anything else, and all pretty much agree on its level of quality. 
+The first reason is because **quality is one of the few things in this world that isn't up for debate** and doesn't change as years pass. It's remarkable to me that five people from anywhere in the world can look at a table, or a video game, or art, or anything else, and all pretty much agree on its level of quality. 
 
-The second reason -- and I'm defining quality as robust, maintainable systems -- is because I think "legacy code" gets a bad rap. Today's new feature is tomorrow's legacy code. But not just any legacy code: my legacy code. My legacy. When I one day shuffle off this earth, my legacy code will represent a sizable chunk of what I leave behind. If it's all replaced in ten years, because that was easier than maintaining it, that's not much of a legacy.
+The second reason -- and I'm defining quality as robust, maintainable systems -- is because I think "legacy code" gets a bad rap. Today's new feature is tomorrow's legacy code. But not just any legacy code: my legacy code. My legacy. When I one day shuffle off this earth, my legacy code will represent a sizable chunk of **what I leave behind**. If it's all replaced in ten years, because that was easier than maintaining it, that's not much of a legacy.
 
-In other words, I'm not trying to be a visionary leader. I'm trying to craft things that last. Doing that consistently and at velocity requires a leader to clear roadblocks, but I'm very happy for that to be someone else, because I'd rather be building... and there's plenty of time for management-level positions after the arthritis starts.
+In other words, I'm not trying to be a visionary leader. I'm trying to craft things that last. Doing that consistently and at velocity requires a leader to clear roadblocks, but I'm very happy for that to be someone else, because I'd **rather be building**... and there's plenty of time for management-level positions after the arthritis starts.
 
 I take your point that my work history suggests that I have a talent for that sort of role. My default perspective is top-down, and doing traditional bottom-up development didn't come to me naturally. But I practiced it until I loved it. I suspect I come across as more top-down in first impressions, but the reality is the opposite. Give me tests and deployment confidence first, design and architecture second.
 
-The reason I _can_ step outside my scope and rearchitect an intractable problem is simply because I've practiced it. My intuition for design surprises me more than you would imagine, because tech has never "clicked" for me. I feel like the concept implies complete understanding, and every year that seems to get further away. In fact, the only thing I know for certain ends in a question itself. "We can build it however you want it, but can you afford it?"
+The reason I _can_ step outside my scope and rearchitect an intractable problem is simply because I've **practiced** it. My intuition for design surprises me more than you would imagine, because tech has never "clicked" for me. I feel like the concept implies complete understanding, and every year that seems to get further away. In fact, the only thing I know for certain ends in a question itself. **"We can build it however you want it, but can you afford it?"**
 
-Lots of developers learn Java and have a great career, but I chose to go broader because that's where unknowns are. I suspect there are no impossible problems in computing. Circuits are binary and arithmetic. Everything else, we made, and we can make it differently. If one solution is too expensive, and another won't work on mobile, and a third has "bad tokenomics," but my gut tells me there's still a thread that shows promise, I dig a little deeper or a little wider. I get more T-shaped in the process, which makes me a better engineer, which makes my next solution better. As a result, I'm more likely to end up outside my job description, because I tugged at threads until I became a SME in this, too. That's the simple answer -- I don't innovate because I want to change things up every week, but because the process of innovating leads directly to increasing quality across the board. People should do everything; specialization is for insects. 
+Lots of developers learn Java and have a great career, but I chose to go broader because that's where unknowns are. I suspect there are no impossible problems in computing. Circuits are binary and arithmetic. Everything else, we made, and we can make it differently. If one solution is too expensive, and another won't work on mobile, and a third has "bad tokenomics," but my gut tells me there's still a thread that shows promise, **I dig a little deeper or a little wider**. I get more T-shaped in the process, which makes me a better engineer, which makes my next solution better. As a result, I'm more likely to end up outside my job description, because I tugged at threads until I became a SME in this, too. That's the simple answer -- **I don't innovate because I want to change things** up every week, but because the process of **innovating leads directly to increasing quality** across the board. People should do everything; specialization is for insects. 
 
-I chose the pattern of trying to being involved outside of my silo. Of course, always accepting curiosity, challenges, and new environments does create a high likelihood that I'll fail and be terribly embarrassed. On the other hand, you can't aimlessly wander into an R&D budget, so its not like I've unilaterally decided to change my own job description, either. I have to be pulled into these roles by the Jira Commanders. I won't bother to deny that I've often ended up on whatever project the CEO has the biggest personal financial stake in at the moment. But I started earning that trust before I started my first day, and I kept that trust by delivering value.
+I chose the pattern of trying to being involved outside of my silo. Of course, always accepting curiosity, challenges, and new environments does create a high likelihood that I'll fail and be terribly embarrassed. On the other hand, **you can't aimlessly wander into an R&D budget**, so its not like I've unilaterally decided to change my own job description, either. I have to be pulled into these roles by the Jira Commanders. I won't bother to deny that I've often ended up on whatever project the CEO has the biggest personal financial stake in at the moment. But I started earning that trust before I started my first day, and I kept that trust by delivering value.
 
 But that's plenty of rambling on my philosophy. Let's talk about yours, because you wouldn't be the first person I've heard the following criticisms from.
 
-I'll grant you the benefit of the doubt that you didn't assume I'm a cowboy because I'm self-taught. That assumption wouldn't be wrong often, and I did spend a bunch of years as a cowboy, but I stepped across that line a long way back on the journey towards quality. I push idempotent commits to my personal repo with a title and description just like every other senior developer, but I do it knowing that the only contributor who will ever read it is my future self. Because that guy's a stickler, and he reads git blames.
+I'll grant you the benefit of the doubt that you didn't assume I'm a cowboy because I'm self-taught. That assumption wouldn't be wrong often, and I did spend a bunch of years as a cowboy, but I stepped across that line a long way back on the journey towards quality. I push idempotent commits to my personal repo with a title and description just like every other senior developer, but I do it knowing that the only contributor who will ever read it is **my future self**. Because that guy's a **stickler**, and he reads git blames.
 
 But if the top-down perception didn't come from the cowboy, it's gotta be the resume. I'll be the first to admit my resume's covered in projects I spearheaded. I'm not blind to the fact that it gives the appearance that "solo architect" and "lone wolf rockstar" are the only hats I can wear, but that's certainly not the full portrait. It's just the one that gets painted by an unfortunate anti-pattern: PDFs are still trying to be an analogue for paper.
 

src/content/candidates.md

@@ -1,30 +1,32 @@
-Long have I pondered the best question to gauge a candidate's level of maturity in software engineering. Reliably dodging "interview prep" can be tricky. Asking about specific skills encourages deceit. I've decided the question has to be open-ended, promise a "happy path" forward, but leave traps along that path that experienced engineers will highlight, caution against, and avoid. This is what I've got so far:
+Long have I pondered the best question to gauge a candidate's level of maturity in software engineering. Reliably dodging "interview prep" can be tricky. Asking about specific skills encourages deceit. I've decided the question has to be open-ended, promise a "happy path" forward, but leave traps along that path that experienced engineers will highlight, caution against, and avoid. This is what I've got so far.
 
-> You're tasked with upgrading the Python "requests" library to support Python 4.
-> This library provides an HTTP client, and it's a dependency for millions of Python projects.
-> You've just installed Python 4.0 and imported the library. It loads fine, but it crashes the first time you try to use it.
-> The error message reads, _"InvalidSchema: No connection adapters were found."_
+**You're tasked with upgrading the Python "requests" library to support Python 4.
+This library provides an HTTP client, and it's a dependency for millions of Python projects.
+You've just installed Python 4.0 and imported the library. It loads fine, but it crashes the first time you try to use it.
+The error message reads, _"InvalidSchema: No connection adapters were found."_ What do you do next?**
 
-> What do you do next?
+Just ask the question, then let the candidate talk.
 
 ## Expected from Senior/Staff Engineer
 
-### Run my test suite / improve test coverage / confirm in Python 3
+**Run my test suite / improve test coverage / confirm in Python 3**
 
 This gets to the crux of the problem: the candidate had no control. Confirm this behavior is actually a regression before debugging further.
 
 Great candidates will refuse to go any further without verifying test coverage. Fixing this error, in a library this extensively used, is almost certain to cause regressions for downstream users.
 
 Top candidates will ignore the above, declare the public interfaces sacred, rip out the internals, and specify an appropriate version bump.
 
-### Check the release notes for Python 4
+**Check the release notes for Python 4**
+
 This gets second billing because people who say this know what's up. It's a great place to start in general, and it's never the wrong answer.
 
 Great candidates will find the Python 4 SME, even if they're in Finland, and schedule a time to chat with them.
 
 Top candidates will ask why the developer of the 'requests' library wasn't directly involved in the launch of Python 4 from the start. They would have installed the first release candidate a year ago.
 
-### Search source code or repository for "InvalidSchema" / "No connection adapters were found."
+**Search source code or repository for "InvalidSchema" / "No connection adapters were found."**
+
 This is the most logical diving-in step. It can help the candidate understand the scope of the problem; will it be a one-line change or a massive refactor?
 
 Great candidates will search the entire organization's repository, not just the source. Problems are rarely isolated.
@@ -33,14 +35,16 @@ Top candidates will note that hearing words like "schema," "connection," and "ht
 
 ## Expected from Junior/Mid-Level Engineer
 
-### Search Google for the error message
+**Search Google for the error message**
+
 Nothing wrong with research. Google's a great default first step.
 
 Great candidates will limit their search to specific sites that cater to low-level developers.
 
 Top candidates will intuit that the task has probably never been attempted before and doubt the efficacy of a search.
 
-### Start a debug terminal / try to trace the code that's failing
+**Start a debug terminal / try to trace the code that's failing**
+
 It's good troubleshooting, but it's a little too early to be looking at traces.
 
 Great candidates will talk about debugging intricacies, likke setting breakpoints and trying to jump the failing instruction.
@@ -49,7 +53,8 @@ Top candidates will only start here because "the debugger is always running when
 
 ## Expected from Intern/Junior Engineer
 
-### Ask someone with more experience for help
+**Ask someone with more experience for help**
+
 Candidate literally hasn't tried anything on their own yet.
 
 Great candidates will post their question in a common area, like a Slack channel, rather than "asking someone"

src/content/money.md

@@ -10,7 +10,7 @@ We just had a really good century. People who invested wisely made a ton of mone
 
 > The Market Can Remain Irrational Longer Than You Can Remain Solvent.
 >
-> ***—John Maynard Keynes***
+> ***John Maynard Keynes***
 
 I wonder what year it was when the someone thought of the "130-minus-your-age" rule. The premise is sound -- when you're younger, you're more risk tolerant, because you have plenty of time to make more money. You can be invested 100% in stocks, which ostensibly return more than bonds. As you get older, you have to preserve your existing capital, because you don't have time to lose it all and start over. 
 

src/static/css/base.css

@@ -147,6 +147,10 @@ blockquote {
         font: 1.5em/0 serif;
         color: #545454;
     }
+
+    > p > em > strong::before{
+        content: "—"
+    }
 }
 
 blockquote::before{