<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Engineering on Stephen Shary</title><link>https://deployedthoughts.dev/tags/engineering/</link><description>Recent content in Engineering on Stephen Shary</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://deployedthoughts.dev/tags/engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>Make the Right Way the Easiest Way</title><link>https://deployedthoughts.dev/posts/right-way/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://deployedthoughts.dev/posts/right-way/</guid><description>&lt;p&gt;When working with other engineers, we should assume that their work will be like water flowing downstream.
When they hit an impediment, it will slow them, but they will find a way around it. Their role is to build things to
solve a problem.&lt;/p&gt;
&lt;p&gt;Understanding this, we should strive to build an environment where the right way to do something is
the easiest way to do it. Anything that helps an engineer complete their job in a faster, easier, and
better way will become a new tool or method that they will use. The greater the impact of that tool or technique, the
more likely they are to use it.&lt;/p&gt;</description></item><item><title>Steps to Solve a Bug Correctly</title><link>https://deployedthoughts.dev/posts/steps-to-fix-bug-correctly/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://deployedthoughts.dev/posts/steps-to-fix-bug-correctly/</guid><description>&lt;p&gt;There&amp;rsquo;s a right way and a wrong way to fix a bug. Done correctly, a fix addresses the root cause, not just the symptoms, and includes a test to prevent regression.&lt;/p&gt;
&lt;p&gt;Steps to fix a bug correctly:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;From the telemetry, and side effect output, determine the inputs that cause the bug consistently.
&lt;ul&gt;
&lt;li&gt;It is common that not enough information is available to understand the issue, add more telemetry if needed and repeat step 1.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;Add an automated test (at the correct level) that replicates the issue.
&lt;ul&gt;
&lt;li&gt;More than one test may be necessary to fully define the &amp;ldquo;edge cases&amp;rdquo; of the bug.&lt;/li&gt;
&lt;li&gt;This is only possible if you truly understand the root cause — a test written against a symptom gives false coverage.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;Write the minimal code needed to make the test pass.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;&lt;strong&gt;Thought:&lt;/strong&gt; There are many people that can aleviate a symptom, but the best solution is one that tackles the issue. Be the person that knows the &amp;ldquo;why&amp;rdquo;.&lt;/p&gt;</description></item><item><title>Why is the path beyond Sr. Engineer difficult?</title><link>https://deployedthoughts.dev/posts/senior-engineer-path/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://deployedthoughts.dev/posts/senior-engineer-path/</guid><description>&lt;p&gt;The path to continue beyond Sr. Engineer is difficult for several reasons. In my experience, the difficulty stems from
how career progression typically works for managers. Many managers in the technical field will start as an engineer and then
continue for 3 - 5 years in which they become competent to handle larger and more complex tasks. After that period of time,
the avenue of management opens up and there are opportunities to move all the way up to CEO, a long and lucrative ladder.&lt;/p&gt;</description></item></channel></rss>