<p>
	We've all read articles that use way too many words to get their point across.
	Or books that give way too much detail about a scene before getting to what's
	actually happening. I've become an expert in skimming headlines and paragraphs
	because it's all too common. Nobody has time for rambling.
</p>

<p>
	What if I told you your team is probably doing something similar in your
	codebase? What if I told you it was probably costing you hundreds of hours of
	work?
</p>

<p>
	I am ruthless about removing all code that isn't necessary. If there's a case
	being handled that I'm not totally sure will happen, I remove it. If there's a
	method that I wrote that I didn't end up needing, I remove it. If there's a
	block of code that is more verbose than necessary, I simplify it.
</p>

<p>Unnecessary code can happen in a few different ways:</p>
<ul>
	<li>
		When a programmer's strategy changes during the life of a task, and relics
		of the old approach stick around.
	</li>
	<li>
		When a programmer comes up with a solution that is more complicated than it
		needs to be.
	</li>
	<li>
		When a programmer tries to anticipate future needs and adds unnecessary
		functionality that may or may not be needed in the future.
	</li>
</ul>

<p>
	These may seem like minor details, but if left unchecked, the cost can
	compound and become enormous. Here are some of the underlying mechanics behind
	this cost:
</p>
<h1 id="comprehension-speed">Comprehension speed</h1>
<p>
	The number one goal of your code is to make it as fast as possible for another
	developer (or future you) to come into your code and understand what's going
	on. The faster they can understand, the faster they can be productive.
</p>

<p>
	If you leave code that's over-complicated or not necessary, you add the
	overhead of your colleague trying to reason about what that code does and why
	it's there. There's no hint to them anywhere that you left it in by accident,
	or that you were saving it for some future use, or that you didn't have time
	to simplify it. They'll need to trace through your code repeatedly until they
	can convince themselves that that code is in fact not needed.
</p>

<p>
	If there are many instances of leaving unnecessary things in your code, this
	confusion can grow exponentially and can end up costing your colleague
	enormously! They'll have to balance all the pieces in their head until they
	can finally untangle things and convince themselves of the way it works.
</p>

<p>
	It would be much better for you to have removed the unnecessary code in the
	first place.
</p>
<h1 id="extension">Extension</h1>
<p>
	Imagine one of your colleagues (or future you) doesn't give your unused or
	overcomplicated code the diligence it deserves. As a result, they don't
	realize that it's not necessary. This is where things get expensive.
</p>

<p>
	They've been tasked to build something in the same area of code as your
	unnecessary code, and they include your unnecessary logic in their extension.
	This exponentially increases the problem! Now a future colleague that looks at
	all of this code will need to reason about your original unneeded code, the
	new extended code, and how they integrate together in order to figure out
	what's going on. Of course, if this future colleague extends it even further,
	the problem multiplies again.
</p>

<p>
	I hope you're seeing how this can create a dangerous, exponentially growing
	problem in your code.
</p>
<h1 id="learning">Learning</h1>
<p>
	If a colleague is a junior developer, someone new to your technology or
	someone new to the area of code you're working in, they may not have the
	experience or knowledge required in order to realize that parts of your code
	are unnecessary or overcomplicated. They may take the bad example and assume
	it to be the proper way to do things.
</p>

<p>
	Similar to the previous example, this can be expensive if this dev then goes
	around and sprinkles in all this extra unneeded complexity around your
	codebase. If there are multiple people learning from your code, these habits
	can spread like wildfire. This is enormously expensive to catch and re-train.
</p>

<p>
	It's better to make sure that all your devs have proper examples to learn
	from.
</p>
<h1 id="a-better-way">A better way</h1>
<p>
	Imagine coming into a file and the code feels like it was written specifically
	to tell you what it's trying to achieve. There's no need to trace through
	lines of code repeatedly to reason about what the results of a block will do.
	There are no cases being handled that make you question “Oh do we handle that
	case? I wonder why…”. Longer blocks of logic are simplified into well
	organized expressions.
</p>

<p>
	This is the type of gift you can give to your colleagues by being diligent
	about simplicity.
</p>

<p>
	My strategy: When you're ready to submit your code, open your code up in your
	favourite diff tool (I use
	<a
		href="https://code.visualstudio.com/docs/editor/versioncontrol#_viewing-diffs"
		>the one in Visual Studio Code</a
	>), and repeatedly go over your code, making fixes and refactors to clean
	things up until you get through the whole thing 3 times without needing any
	changes.
</p>
<h1 id="conclusion">Conclusion</h1>
<p>
	Even though it can seem like no big deal to leave a tiny bit of unnecessary or
	overcomplicated code in your codebase here and there, it can be enormously
	expensive over time. On the other hand,
	<a href="https://jamesclear.com/marginal-gains"
		>tiny gains compound for huge results</a
	>. Code with a high signal to noise ratio enables your team to move faster
	than you thought it ever could! Be ruthless about simplifying your code!
</p>


Avoid this issue and save your team hundreds of hours

The Enormous Cost of Unnecessary Code

<p>
	I think the most impactful marker of how productive a development team is how
	collaborative they are. I set the expectation with my team that collaboration
	is top priority, and do my best to identify and facilitate collaborative
	opportunities. Here’s what to look for:
</p>

<h3 id="planning">Planning</h3>
<p>
	Collaborative teams work together to plan architecture and design before
	jumping into the code. Software that has had discussion and debate around
	architecture and planning is higher quality, better architected, and more
	valuable to customers. Having alternative views into a problem before jumping
	in identifies pitfalls and solutions that a single person may not have thought
	of.
</p>
<p>
	The time this saves long term is enormous. Your team will spend less time
	falling into rabbit holes, spend less time re-working hasty or single-minded
	solutions, and they’ll produce solutions that more accurately solve customers’
	needs.
</p>

<h3 id="unblocking">Unblocking</h3>
<p>
	Collaborative teams reach out to their teammates when they are stuck. A team
	that hasn’t developed the culture of intense collaboration will have
	developers that spend far too long spinning their wheels.
</p>
<p>
	Developers who reach out when they’re stuck get back on track quickly. They
	more often produce the proper solution. They complete higher quality work, and
	more of it.
</p>

<h3 id="experience-skill">Experience and skill</h3>
<p>
	Collaborative teams level up faster! Developers who work together share ideas
	and insights. They do research together. Leveled up developers produce higher
	quality, more value, and mentor your less experienced team members.
</p>

<h3 id="happiness">Happiness</h3>
<p>
	Collaborative teams are happier! High velocity, high quality, and constant
	learning makes happy developers. A happy developer produces better work. All
	developers (so far) are humans, and humans are social and collaborative
	animals.
</p>

<h3 id="no-collaboration">Without collaboration</h3>
<p>
	Developers who miss opportunities for collaboration may have their code reach
	code review before coming under any scrutiny — this is too late.
</p>
<p>
	There’s extra friction involved with asking a developer to change their
	approach when they’ve already committed the time. The existing code adds
	constraints to reviewers’ thinking, making other solutions less obvious. The
	long term cost of this is drastic.
</p>

<h3 id="how-to">How can I get my team to be collaborative?</h3>
<p>
	Set the expectation that collaboration is the most important value. Sell them
	on the benefits and get their buy in.
</p>
<p>
	The daily planning meeting is the most effective way to collaborate. Have your
	developers plan their day out loud and identify possible opportunities for
	collaboration and pair programming. Look for plans with complexity involved,
	and encourage collaboration to tackle that complexity together. Look for
	developers who might be stuck on something and encourage pair programming to
	get through the issue. Look for spikes or research tasks that can be tackled
	together.
</p>
<p>
	I recommend a video chat or in person meeting for your standup. Standups over
	Slack or other messaging systems aren’t real-time enough for collaboration,
	and typically result in status updates, not collaborative day planning. Your
	teams’ status should be in your project management software. Look there for
	work progress, and save your daily planning meeting as a catalyst for
	collaboration.
</p>
<p>
	Teams that aren’t used to collaborating intensely may need some practice to
	get used to it. Give your team some time to get through the initial
	adaptation. Good luck!
</p>


The most impactful cultural shift your team can make

Collaborative Software Teams

<p>
	We’ve been experimenting as a team with shipping the smallest increments of
	value possible. We are loving the results so far. Work is more enjoyable, work
	is higher quality, and more work gets done. Here are some of the reasons I
	think are behind this:
</p>

<h3 id="customer-value">Customer value</h3>
<p>
	Small work chunks ensure you’re providing constant value to your customers. By
	breaking things down, you deliver value to your customers more consistently
	and more often. Shipping an increment of value once it’s done captures a
	massive amount of extra value that compounds over time. Customers love
	software teams that ship often.
</p>

<div class="columns">
	<div class="column">
		<a href="/static/blog/small-tickets-customer-value-1.png">
			<img
				src="/static/blog/small-tickets-customer-value-1.png"
				alt="Missing out on customer value"
			/>
		</a>
	</div>
</div>

<div class="columns">
	<div class="column">
		<a href="/static/blog/small-tickets-customer-value-2.png">
			<img
				src="/static/blog/small-tickets-customer-value-2.png"
				alt="Capturing all customer value"
			/>
		</a>
	</div>
</div>

<h3 id="feedback">Feedback</h3>
<p>
	If you ship smaller stuff, you can get your customers' feedback on that stuff
	sooner. You can then apply that feedback earlier, and make a better product
	long term. All the improvements made due to early feedback compound to create
	enormous extra value for your customers.
</p>

<h3 id="quality">Higher quality</h3>
<p>
	Smaller tickets are higher quality work on average. Since your pull requests
	are smaller, they’re easier for your developers to code review. There is less
	friction involved with reviewing (No putting off that massive code review),
	and better quality feedback will be given in each review. In a large code
	review, people skip lower priority feedback to avoid feedback exhaustion.
	Smaller chunks of work (and smaller code changes) avoid this issue, leading to
	more thorough reviews.
</p>

<p>
	Smaller chunks of work let developers focus in on one problem at a time, which
	means solutions are of higher quality. A piece that might have been a
	secondary consideration if bundled up in a larger body of work becomes the
	primary focus, so it’s given more deliberate thought and planning.
</p>

<h3 id="productivity">More work gets done</h3>
<p>
	Your developers are more productive with smaller chunks. It’s motivating to
	see your work consistently get shipped. It’s satisfying to continuously drag
	items to the “done” column. Smaller tickets have less friction associated with
	them. Developers are happier working on smaller, better defined chunks. All of
	these things add up to more work shipped overall, with less re-work.
</p>

<p>
	The next time you're dividing up work for your team, consider the smallest
	possible increment of value and break it down as far as you can. You've gone
	too far if shipping a piece doesn't add value on its own.
</p>

<p>Try it. I think you and your team will love the results.</p>


Increase your development team's productivity, quality, and happiness

Small work chunks

<p>Most of writing good software is accurate modeling.</p>

<h3 id="front-end">Front end</h3>
<p>
	Start with the slice of your software that is your primary differentiator. For
	most business software, this will be your user interface. What are the UI
	primitives on the screen? Cards? Lists? Is your data nested? Your front end
	data models should accurately represent your UI.
</p>

<h3 id="database">Database/back end</h3>
<p>
	Your database should be modeled after how your customers see the business
	concepts your software solves. What do your customers talk about? Invoices?
	Prices? Customers? Invoices? Products? Line items? Your database models should
	match the model in your customers’ head as closely as possible.
</p>

<h3 id="integration">Integration</h3>
<p>
	The first thing your front end should do when it receives your database models
	is transform them to the front end model. Typically this is done through a
	factory function or constructor. This way your front end programmers can work
	in the mental model of the UI without having to translate back and forth for
	every interaction in your front end.
</p>
<p>
	You should then create another set of factory functions or constructors that
	transform your data from the front end model back to the database or API model
	that you can pipe your data through on the way back to your backend.
</p>

<a href="/static/blog/accurate-models.png">
	<img
		src="/static/blog/accurate-models.png"
		alt="A diagram of backend and front end model integration"
	/>
</a>

<h3 id="refactor">Refactor and update</h3>
<p>
	Sometimes things change. It is critical to refactor your models when this
	happens. Working with an out of date model adds significant overhead to every
	single interaction with the code that uses it. This overhead compounds over
	time and adds up to be an extreme cost. Anytime you see code that works around
	an inaccurate model, schedule work to update it. In general, the up front work
	will save tons of overhead longer term.
</p>


A fundamental concept to improve your code

Accurate Models

<p>
	I use compound exercises over isolation exercises in my workouts, so I wanted
	to write about the trade offs. Here’s a small table comparing the difference
	between compound lifts and isolation lifts:
</p>

<div class="table-container">
	<table class="table">
		<thead>
			<tr>
				<th>Category</th>
				<th>Compound Lifts</th>
				<th>Isolation Lifts</th>
			</tr>
		</thead>
		<tbody>
			<tr>
				<th>Joints involved</th>
				<td>Multiple</td>
				<td>Single</td>
			</tr>
			<tr>
				<th>Muscles involved</th>
				<td>More muscles involved</td>
				<td>Fewer muscles involved</td>
			</tr>
			<tr>
				<th>Weight</th>
				<td>More weight can be moved</td>
				<td>Less weight can be moved</td>
			</tr>
			<tr>
				<th>Overall muscle growth</th>
				<td>More</td>
				<td>Less</td>
			</tr>
			<tr>
				<th>Muscle growth distribution</th>
				<td>Between many muscles</td>
				<td>Focused on fewer muscles</td>
			</tr>
			<tr>
				<th>Movement type</th>
				<td>Natural</td>
				<td>Natural and artificial</td>
			</tr>
			<tr>
				<th>Exercise examples</th>
				<td>Squat, Bench press</td>
				<td>Leg press, Chest fly</td>
			</tr>
		</tbody>
	</table>
</div>

<h3 id="joints-muscles">Joints and Muscles Involved</h3>
<p>
	The definition of a compound movement is that multiple joints are involved,
	and the definition of an isolation movement is that a single joint is
	involved. Since more joints are involved in compound lifts, it follows that
	more muscles are typically involved too.
</p>
<h3 id="weight-growth">Weight and Muscle Growth</h3>
<p>
	Since more muscle is recruited for compound lifts, more total weight can be
	lifted. For example, you can squat significantly more weight in a rep than you
	can in a leg extension.
</p>

<p>
	Because more muscles are involved in moving more weight, more overall muscle
	growth occurs, though that growth is distributed between all involved muscles.
</p>

<p>
	With isolation work, specific muscles can be targeted beyond what a compound
	lift would target that muscle at. Because of this, smaller muscles can grow
	beyond what they ever could if using only compound lifts.
</p>

<p>
	For example: if I do shoulder presses, a compound lift, I will target all
	three of my deltoids (shoulder muscles), distributing the load. If I wanted to
	grow my rear deltoid in a larger proportion, I could do face pulls and target
	just that muscle, pushing it close to its peak load. This way, I can get more
	growth relative to my other deltoids if I wanted to.
</p>

<p>
	Because of all of these reasons, the most efficient way to build muscle is
	through compound lifts — you’re recruiting more muscle per repetition. People
	will refute this, since isolation work produces more noticeable muscle
	quicker. Compound lifts grow you in natural and distributed proportions, so
	the growth is less noticeable. It’s up to you to decide which path you’d
	prefer.
</p>
<h3 id="natural-proportions">Natural Proportions</h3>
<p>
	I have a theory that since compound movements are natural movements, their
	consistent use will, over time, produce the most natural and therefore
	aesthetically pleasing physique. You can get bigger faster if you do isolation
	work, but unless your work is carefully organized, you will achieve a less
	natural, and therefore less aesthetic, look overall.
</p>


A theory of muscle growth

Compound vs Isolation Exercises

<h1 id="story">A Story Based on True Events</h1>
<p>
	Imagine you’ve been working hard at your new diet and you’ve made great
	progress. You’re down 5 lbs in 5 weeks. You decide you deserve a day off your
	diet, so you have a few beers with a burger and fries. You go to bed satisfied
	and ready to get back to your diet tomorrow.
</p>
<p>
	The next morning comes, and you step on the scale. You’ve gained 5 lbs. WHAT?!
	From one cheat meal, you’re back to your starting weight. You feel defeated.
	If you can undo 5 weeks of hard work in one meal, what’s the point?
</p>
<p>
	This actually does happen, and I think it’s the number one reason most people
	don’t diet successfully. There’s good news: The weight you put on is not fat,
	it’s water.
</p>
<h1 id="water-weight">Water Weight</h1>
<p>
	When you overeat, your body stores up extra water along with the extra food.
	Water is heavy. I’ve personally experienced weight fluctuations of up to 8 lbs
	after a weekend of eating and drinking whatever I want. The water weight
	disappears after a few days of eating properly again. You didn’t undo all that
	hard work!
</p>
<p>
	Can you imagine being the person in the story? How discouraging would it be to
	work so hard to lose weight but to be able to gain it back in a moment? I have
	a feeling that is the number one reason most people aren’t successful with
	their diets. They think they’ve put all their fat back on in a split second,
	so they give up and go back to their old way of eating. If only they were
	aware that it’s just water that will go away after a few days. If more people
	knew about this, I think we’d see a lot more successful dieters. So spread the
	word!
</p>
<h1 id="happy-ending">A Happy Ending</h1>
<p>
	Continuing our tale from above, you decide to stick to your diet again for a
	few days and you notice something amazing: the next day you weigh yourself and
	you’re 2 lbs lighter! You are a little more encouraged and sure enough, after
	2 more days you’ve completely flushed out all that water weight and you’re
	back to your pre-cheat meal weight. You’re actually a little lighter than
	before!
</p>
<p>
	You realize this is doable after all, and resolve to keep at it until you’ve
	reached your goal weight. You live happily ever after.
</p>
<h1 id="end">The End</h1>
<p>
	This is also a true story that does happen. Once you put on water weight, your
	body gets rid of it quickly, shedding up to 8 lbs in 2 or 3 days in my
	experience.
</p>
<p>
	Bottom line: don’t get discouraged after cheat meals or vacations. It’s just
	water weight! Your body will flush it out rather quickly and you’ll be back in
	action in no time.
</p>


A Story About Water Retention

The Reason Most Diets Fail

<p>
	I’ve had trouble with sleeping off and on through my life but I feel like
	recently I’ve cracked the code. Here’s what I found:
</p>
<h3 id="wake-up">Wake up at the same time every morning</h3>
<p>
	Your wake up time drives your circadian rhythm (your body’s internal clock
	that tells you when to sleep and wake up), so pick a time to wake up, and wake
	up at that time every morning.
</p>
<h3 id="bedtime">Don’t go to bed till you’re tired</h3>
<p>
	Too many people think that the right bedtime is the key to a good night's
	sleep, but it’s actually the right wake up time. If your wake up time is
	correct, your body will let you know when it’s bedtime.
</p>

<p>
	Don’t go to bed before you’re tired. You will lay pointlessly and your mind
	will wander and keep you up past when you’re supposed to get tired.
</p>

<p>
	I usually wind down and watch TV till I literally start having trouble keeping
	my eyes open. Only then I go to bed.
</p>

<p>
	As a side note to this, don’t do things close to your normal bedtime that
	might distract your mind from feeling tired, For me it’s things like
	programming or playing video games.
</p>
<h3 id="temperature">Find the right temperature</h3>
<p>
	This seems obvious, but sometimes when you’re laying there trying to sleep and
	it’s hot or cold, you don’t get up to fix itcuz you’re too sleepy. Temperature
	ideas:
</p>

<ul>
	<li>Crack open the window</li>
	<li>Close the window</li>
	<li>Turn up the heat in your room slightly</li>
	<li>Stick your feet out of the blanket</li>
	<li>Turn your pillow to the cold side</li>
	<li>Put your arms and hands against your cool wall</li>
</ul>

<p>
	Do whatever it takes to find that ideal temperature. Being too hot or too cold
	will crush your odds of getting a good night’s sleep. My brother has nicknamed
	sleeping as “A Quest for Cold.”
</p>

<p>
	Once you find the perfect temperature, you might need to make adjustments
	every time the weather changes.
</p>
<h3 id="snooze">Don’t hit the snooze button</h3>
<p>
	If you snooze too long, your circadian rhythm doesn’t know what time it’s
	supposed to set for. Snoozing doesn’t really feel good, doesn’t get you more
	rested, and wastes more of your day.
</p>

<p>Snooze once if you must, but no more than that.</p>

<p>Sweet dreams!</p>


Use your body's natural cues

How to Get a Good Night's Sleep

<p>
	I’ve been using a trick to be productive lately: when I find myself not
	wanting to do something, I break it down into a smaller chunk until it’s a
	small enough bite of something that I want to do it. I end up making more
	progress more consistently with this trick. A lot of times, I’ll end up
	achieving much more than the small chunk I’d set out for myself to do.
</p>

<h3 id="side-projects">Side Projects</h3>
<p>
	This past week, I wanted to add an app install button to one of my side
	projects, <a href="https://drinktracker.app">Drinktracker</a>. I went a whole
	week without even opening my laptop to work on it, so I broke the problem
	down: Instead of making my goal “build the install button,” I made it “work on
	the install button for 20 minutes.”
</p>

<p>
	I sat down with the intention of spending 20 minutes and built the whole thing
	over a few hours.
</p>

<h3 id="workouts">Workouts</h3>
<p>
	Anyone who works out regularly knows that sometimes you just don’t feel like
	going. In this case, instead of committing to my whole planned workout, I go
	to just do my warm up sets and see how I feel — giving myself the option of
	doing lower weight or fewer sets that day.
</p>

<p>
	Most of the time I’ve used this technique, I get to the gym, feel perfectly
	fine once I get started, and end up doing my original, full workout. There are
	some times that I have gotten there and done a reduced load, but at least I
	still showed up.
</p>

<h3 id="reading">Reading</h3>
<p>
	Everybody wants to read more books more often. What I do is I commit to read
	10 pages or 1 chapter every time I think to read my current book. A lot of
	times I read more than just the 10 pages I’ve committed to. Using this
	technique, it's easy to read 50+ pages a week!
</p>

<h3 id="momentum">Build Momentum</h3>
<p>
	Once you get started on something and make some progress, you build momentum
	towards productivity. You start with 20 minutes on one side project, end up
	finishing that over a couple hours, and it carries over into the next thing
	you want to do. You end up working on another project, reading a book, then
	doing yard work or cooking a nice dinner. Breaking down one thing and building
	that momentum can spiral upwards into a super productive day.
</p>

<p>
	PS: I sat down with the intention to just write some ideas down on this topic,
	but I ended up writing a whole draft!
</p>


How to make consistent progress towards your goals

Break Your Tasks Down

<p>
	After 8 years of experimentation, I’ve finally landed on a workout that works
	with my lifestyle and goals. Here it is:
</p>
<h3>The workout</h3>
<p>3-4 sets of 6-12 reps per movement.</p>
<h4>5 Day Version</h4>
<div class="table-container">
	<table>
		<tbody>
			<tr>
				<td>
					<h5>
						Monday
					</h5>
					<ul>
						<li>Deadlift</li>
						<li>Overhead Press</li>
						<li>Accessory (Biceps)</li>
					</ul>
				</td>
				<td>
					<h5>
						Tuesday/Thursday
					</h5>
					<ul>
						<li>Bench Press</li>
						<li>Row (Seated or cable)</li>
						<li>Accessory (Triceps)</li>
					</ul>
				</td>
				<td>
					<h5>
						Wednesday
					</h5>
					<ul>
						<li>Chin up</li>
						<li>Overhead press</li>
						<li>Accessory (Biceps)</li>
					</ul>
				</td>
				<td>
					<h5>
						Friday
					</h5>
					<ul>
						<li>Squat</li>
						<li>Chin up</li>
						<li>
							Accessory (Superset Biceps Triceps)
						</li>
					</ul>
				</td>
			</tr>
		</tbody>
	</table>
</div>
<h4>3 Day Version</h4>
<div class="table-container">
	<table>
		<tbody>
			<tr>
				<td>
					<h5>
						Monday
					</h5>
					<ul>
						<li>Deadlift</li>
						<li>Overhead Press</li>
						<li>Accessory (Biceps)</li>
					</ul>
				</td>
				<td>
					<h5>
						Wednesday
					</h5>
					<ul>
						<li>Bench Press</li>
						<li>Row (Seated or cable)</li>
						<li>Accessory (Triceps)</li>
					</ul>
				</td>
				<td>
					<h5>Friday</h5>
					<ul>
						<li>Squat</li>
						<li>Chin up</li>
						<li>
							Accessory (Superset Biceps Triceps)
						</li>
					</ul>
				</td>
			</tr>
		</tbody>
	</table>
</div>
<h3>Constraints</h3>
<h4>
	Workout Length
</h4>
<p>
	I work out at lunchtime on work days, so workouts must be capped at 45 mins
	per session. Volume is spread out throughout the week instead of all on one
	day in order to enable this. I think spreading volume throughout the week may
	actually be more effective for muscle growth as well which would be a bonus,
	but not the primary reason for the spread.
</p>
<h4>
	Basic Movements
</h4>
<p>
	I prioritize a naturally proportionate physique, so I choose basic exercises
	so that muscles grow in their natural proportions.
</p>
<h4>Strength</h4>
<p>
	I love playing sports, so strength is important. By choosing basic movements,
	I can lift heavy so that I can get strong enough that it makes me better at
	sports. Being strong also significantly decreases my chance of injury.
	Movements that allow for heavy lifting are the most important for overall
	health and longevity — they increase bone density and strengthen joints and
	ligaments.
</p>
<h4>Adaptability</h4>
<p>
	The 5 day plan is a superset of the 3 day plan. If I realize that I can only
	make 3 days in a specific week, I can revert to the 3 day plan and still be
	productive. If I can only make 4 days, I can do the 3 day plan and pick an
	extra day based on what I’m feeling I should do.
</p>
<p>
	In the 3 day plan, if I can’t make a Mon, Wed, or Fri, it’s easy to just move
	one of those workouts to a Tues or Thurs.
</p>
<h3>Questions</h3>
<h4>
	Should I do the 5 day or 3 day?
</h4>
<p>
	The 5 day will produce more results, but I recommend whichever gets you in the
	gym consistently.
</p>
<p>
	If you’re not sure, start with the 3 day and upgrade to the 5 day if/when you
	feel ready. The priority is building the discipline of going to the gym, not
	maximizing effectiveness. You can maximize effectiveness once the discipline
	is built.
</p>
<h4>
	How many sets should I do?
</h4>
<p>
	More hard sets equals more muscle growth. If you can do 4 per workout, great.
	3 will also make progress. 2 can be used if you’re coming off of a break or if
	you need a quick workout, but you won’t make progress if you’re consistently
	only doing 2 sets for a movement in a week.
</p>
<h4>
	How many reps should I do?
</h4>
<p>
	The key is to coordinate weight and reps so that you’re at least an 8 out of
	10 of perceived exertion. For example, if I bench 135 lbs for 10 reps, I might
	be able to do 185 lbs for 5 and get the same perceived amount of exertion.
</p>
<p>
	If you’re not grimacing towards the end of your set, you need to do more
	weight or reps. Work hard every set. Muscle growth is driven by the number of
	hard sets you do per week.
</p>
<p>
	More reps lets you use less weight, which I prefer these days. It’s fun to go
	for heavy sets of 5 here and there too though. Switch it up for fun!
</p>
<h4>
	How do I progress?
</h4>
<p>
	I suggest picking a rep goal to stick to for 6 weeks or so and if you crank
	out more reps than your goal, increase the weight by as little as you can for
	the next time you do that exercise.
</p>
<p>
	For example, if I’m doing 10 reps of 135 lbs on my bench press and I manage to
	do 11 one day, I’m going to increase my weight by the smallest possible amount
	and do 140 lbs (or 137.5 lbs if you have micro plates!) the next time I do
	bench.
</p>
<p>
	You can also try
	<a href="https://leangains.com/reverse-pyramid-training-guide"
		>Reverse Pyramid Training</a
	>, which is what I do and highly recommend.
</p>
<h4>
	What do you mean by natural movements?
</h4>
<p>
	There are 6 natural movements that your body can do:
</p>
<ul>
	<li>
		Horizontal push (bench press), horizontal pull (row)
	</li>
	<li>
		Vertical push (overhead press), vertical pull (chin up)
	</li>
	<li>
		Lower body push (squat), lower body pull (deadlift)
	</li>
</ul>
<p>
	My thinking is that if you do natural movements, your muscles will grow
	naturally proportional, which will be the most aesthetic looking.
</p>
<p>
	Natural movements also recruit the most muscles for a lift (since your body is
	adapted for them), so they allow you to lift the most weight and build
	strength.
</p>
<h4>
	Why this layout of exercises?
</h4>
<p>
	I did it this way so that you always have a day between doing the same
	exercise. It’s heavily inspired by Martin Berkhan’s
	<a
		href="https://www.google.com/url?q=https://leangains.com/reverse-pyramid-training-guide/"
		>Reverse Pyramid Training Guide</a
	>.
</p>
<h4>
	Why more upper body than lower?
</h4>
<p>
	Partially due to the fact that I’m a male and upper body growth is more ideal
	for males. Partially due to the fact that I get a lot of leg volume from
	sports and bike commuting. Partially due to the fact that if I did deadlifts
	and squats more than once a week I’d die.
</p>
<h4>
	What should I do for accessory work?
</h4>
<p>
	Completely up to you, but make sure they’re isolation exercises so they don’t
	get in the way of your main lifts. Start with bicep curls and tricep pushdowns
	if you’re not sure what to do. Standing calf raises are also a good idea (I
	haven’t made much progress with sitting calf raises for some reason). You
	could also just skip the accessory work and get in those 4 sets each of your
	main lifts!
</p>
<h4>
	How about for women?
</h4>
<p>
	Men and women should train the same. That said, If I were a woman I’d trade
	some of the upper body work for some lower body work since lower body muscles
	are more aesthetic on women.
</p>


My Workout

<p>
	We’ve all been there. You’ve gotten a report from a customer that one of your
	screens is agonizingly slow to load. You load it up and sure enough, it’s
	crawling. You think to yourself “Why didn’t I see this coming? How could I
	have written such sloppy code?”
</p>

<p>You did it the right way.</p>

<p>
	Slow code is a good thing. If you have slow code, that means you didn’t
	pre-optimize your software with what you guessed was going to happen in the
	future. Now, you’ve got your slow code right in front of you along with the
	perfect dataset to test it out with. You can solve a real life problem right
	now.
</p>

<p>
	The alternative would be trying to guess at what sorts of data your customers
	would throw at your screen one day and coming up with a solution that may or
	may not solve for the type of data your customers actually do throw at you.
</p>

<p>
	Performance issues are good. The right time to speed up your code is when it
	gets slow, and no sooner.
</p>


Slow Code is Good

<p>
	There's one big rule I tend to follow in my work that I think a lot of people
	could benefit from: I wait until problems hurt before I solve them.
</p>
<p>
	The scale of this could be large, from what database management system do I
	use, to tiny: Where should I put this new function? Premature problem solving
	leads to overcomplexity and subpar decisions that are hard to change. Worst of
	all, it's completely avoidable by
	<strong>solving your problem at hand</strong> over solving what you think your
	problem might become.
</p>
<h1>Some ideas</h1>
<h3 id="tech-choices" class="title">Tech Choices</h3>
<p>
	Say you're starting a new project, and you don't know what your data will look
	like. Rather than making assumptions about what you think your needs may be,
	<strong>pick the simplest or most familiar database system.</strong> Then you
	can quickly and cheaply make a more informed decision and pivot if and when
	your database choice starts to hurt.
</p>
<p>
	The same goes for other tech choices. When it's early or when requirements
	aren't totally nailed down,
	<a href="/blog/get-good-at-being-wrong"
		>pick something simple that makes it easy to pivot from</a
	>
	if and when challenges arise
</p>
<h3 id="organization">Code organization</h3>
<p>
	If you write a utility function that you're not sure where to put, just
	<strong>put it in the file that uses it.</strong> It'll be exactly where
	you'll think to look for it. Once your application grows and other modules are
	using that function, you can move it to its own file. If you end up with more
	related functions, you can group them together at that point &mdash; but only
	at the point you find it difficult to find one, ie. when the lack of
	organization actually hurts.
</p>
<h3 id="another-scenario">A non-work scenario</h3>
<p>
	If you bought your first video game, would you buy three game bins, label one
	"A-H", another "I-P", and another "Q-Z", and put the one game in one of those
	bins? Of course not! You'd just put that one game on your TV console and
	wouldn't think about organizing until you have enough games that you have
	trouble finding what you're looking for.
</p>
<p>
	The same goes for your codebase: Don't over-organize before things become hard
	to find.
</p>
<h1>Stop premature problem solving</h1>
<h3 id="better-decisions">Better decisions</h3>
<p>
	Reactive problem solving keeps things simple and usable before your problem
	arises, and creates better solutions in the end. By the time you're
	solutioning, your problem is well defined and you're solving based on facts
	rather than guesses.
</p>
<h3 id="pivoting">Easier to pivot</h3>
<p>
	By deferring your problem solving, it'll be easier to implement the correct
	decision since things were kept simple. It's easier to add complexity than to
	refactor it.
</p>
<h3 id="focus">Better focus</h3>
<p>
	By saving theoretical problems for when they hurt, you create bandwidth to
	focus on the real problems in front of you.
</p>
<h3 id="framing">Frame painful problems positively</h3>
<p>
	It's common to react to a new problem as a bad thing and think "I should have
	solved this already."
</p>
<p>A better reaction: "Now is the right time to fix this."</p>
<h3 id="time">Give it some time</h3>
<p>
	It can take some time to get comfortable with not having potential solutions
	to every one of your potential challenges, but once you get comfortable with
	it, I think you'll find your work will be higher quality and lower stress.
</p>


A simple tip to produce quality work

Don't Solve Problems Till They Hurt

<p>
	I've been slowly tweaking my diet over time and I think it's at the point
	where it can help others, so here it is.
</p>
<p>Since I've been on this diet, I've:</p>
<ul>
	<li>Simplified my life</li>
	<li>Lost fat</li>
	<li>Built muscle</li>
	<li>Had high energy</li>
	<li>Enjoyed food</li>
	<li>Felt full</li>
</ul>
<p>
	This is the result of me researching and experimenting with nutrition my whole
	adult life!
</p>
<h1 id="protein-and-fibre">Protein and Fibre</h1>
<p>
	At the core of the diet is two macronutrients,
	<span class="has-text-danger">protein</span> and
	<span class="has-text-success">fibre</span>. Every meal is centred around your
	plate being half <span class="has-text-danger">protein</span>, half
	<span class="has-text-success">fibre</span>.
</p>
<p>
	What this means is that every meal is half
	<span class="has-text-danger">meat</span>, half
	<span class="has-text-success">fibrous vegetables</span>. Some common meals I
	eat are:
</p>
<ul>
	<li>
		<span class="has-text-danger">Steak</span> and
		<span class="has-text-success">blanched veggies</span> (one or more of
		broccoli, brussels sprouts, green beans)
	</li>
	<li>
		<span class="has-text-danger">Chicken breast</span> and
		<span class="has-text-success">salad</span> (With whatever toppings you
		need, ex: olive oil, balsamic vinegar, cheese, etc)
	</li>
	<li>
		<span class="has-text-danger">Beef Stew</span> (w/
		<span class="has-text-success">carrots</span>, no potatoes)
	</li>
	<li>
		<span class="has-text-danger">Pan fried pork tenderloin</span> and
		<span class="has-text-success">blanched veggies</span> (I'm a big fan of
		blanched veggies)
	</li>
	<li>
		<span class="has-text-danger">Tuna</span> and
		<span class="has-text-success">salad</span>
	</li>
	<li><span class="has-text-danger">Scrambled Eggs</span></li>
</ul>
<p>
	I hope you see the theme there. Just pick any meat and any veg, make them
	delicious, and eat them together!
</p>
<p>
	<span class="has-text-danger">Half Plate Meat</span> +
	<span class="has-text-success">Half Plate Veg</span> =
	<span class="has-text-info">Protein-Fibre Meal</span>
</p>

<a href="/static/blog/protein-fibre.png">
	<img src="/static/blog/protein-fibre.png" alt="A protein fibre meal" />
</a>

<h1 id="eat-more">Eat More</h1>
<p>
	Since there are fewer calorie-dense carbohydrates in this diet, you need to
	eat a <strong>lot</strong> more food than before to make up for it. Just eat
	more of equal sized servings of protein and fibre. I tend to eat two plates
	(half protein, half fibre) of food per meal.
</p>
<h1 id="drink-water">Drink Lots of Water</h1>
<p>
	Sometimes, when you think you're hungry, you're actually thirsty. Drink a ton
	of water every day. I'm talking at least 3 litres, ideally closer to 5. Just
	be sipping water all day. It's simple and satisfying.
</p>
<h1 id="cheat">Cheat Once a Week</h1>
<p>
	For some reason, it's easier to keep this up if you eat whatever you want once
	a week. I use Saturdays for social and societal reasons. If you crave
	something during the week, don't think "I can't have this." Think, "I can have
	this on Saturday."
</p>
<h1 id="no-exercise">No Exercise</h1>
<p>
	It's a myth that you need exercise to lose fat, and I don't recommend doing
	any extra exercise beyond what you already do as a part of your normal life.
	Changing your activity levels will mess around with your hunger and give you
	unpredictable results. Worse, extra exercise will add more effort to your
	journey to health when the diet will provide better results on its own.
</p>
<p>
	The only exception to this rule is if you're lifting weights. Any other form
	of extra exercise is not recommended.
</p>
<h1 id="get-started">Get Started!</h1>
<p>
	That's all you need to get started with the Protein-Fibre diet! Read on for
	some sciencey ideas behind the diet, or go fry up a steak and toss a salad to
	get started.
</p>
<h1 id="science-for-nerds">Science for Nerds</h1>
<h3>Calories and Satiety</h3>
<p>
	On the protein fibre diet, you are eating the two most hunger satisfying
	(satiating) macronutrients. Because of this, it is virtually impossible to eat
	too many calories on protein and fibre &mdash; you get full before you can eat
	too much.
</p>
<h3>Insulin</h3>
<p>
	Insulin is the fat storage hormone. Its presence signals your body to store
	blood glucose and fat as body fat.
</p>
<p>
	Fibre blunts insulin response and protein has a net neutral insulin response.
	You'll never be signaling to your body to store fat. In fact, you'll be
	producing the anti-insulin, glucagon, which signals to your body to burn
	bodyfat and use it as energy.
</p>
<h3>Cheat Day</h3>
<h5>Ghrelin</h5>
<p>
	Cheat day once a week regulates your ghrelin (your hunger hormone) response.
	Carbohydrates seem to uniquely control ghrelin so it's important to eat some
	once a week.
</p>
<h5>De Novo Lipogenesis</h5>
<p>
	The thermic effect of carbohydrates is higher when your glycogen stores are
	full, meaning it costs calories to store those carbs as fat, through a process
	called de novo lipogenesis. So your 4 calorie per gram carbohydrate ends up
	being close to 3 calories per carbohydrate when storing as fat. A great reason
	to binge once in a while vs snacking here and there — Your body seems to
	prefer it.
</p>
<h1 id="extras">Extras</h1>
<p>
	If you're looking to go above and beyond, I recommend looking into two more
	impactful things: <strong>Intermittent Fasting</strong> and
	<strong>Strength Training</strong>.
</p>
<p>
	Learn about <strong>Intermittent Fasting</strong> in James Clear's
	<a href="https://jamesclear.com/the-beginners-guide-to-intermittent-fasting"
		>The Beginner's Guide to Intermittent Fasting</a
	>.
</p>
<p>
	The best <strong>Strength Training</strong> program I've ever done is Martin
	Berkhran's
	<a href="https://leangains.com/reverse-pyramid-training-guide/">
		Reverse Pyramid Training </a
	>.
</p>


A satisfying approach to food that works

The Protein-Fibre Diet

<p>
	There's one constant I've been thinking about in software: we're wrong a lot.
	It's the nature of our job &mdash; we're building systems for people whose
	jobs we don't know, with tech we're still learning, and whose components are
	connected in ways we've never seen. We're going to make assumptions and
	mistakes. Optimize for them!
</p>
<h1 id="get-rapid-feedback">Rapid Feedback</h1>
<p>
	If you know you're going to be wrong, the best thing you can do is get your
	software in front of someone who can tell you where you're wrong as quickly as
	possible. At the core of your process should be rapid feedback. Build the
	minimum viable product of every feature you build and let your users and
	customers tell you what works and what doesn't.
</p>
<h1 id="choose-simple">Simplicity is King</h1>
<p>
	Simple software is easier to modify when it's wrong. It's also easier to
	justify throwing out if it's really wrong. Simple is best. Since you're going
	to be wrong a lot, you should always pick the simplest of any options
	available to you.
</p>
<p>
	Users also happen to like simple software, but that's another blog post...
</p>
<h1 id="simple-tech">Pick Low Friction Tech</h1>
<p>
	Choose tools that let you be productive as soon as possible, so you can find
	out where you're wrong as soon as possible. This usually means choosing a
	platform as a service rather than rolling your own super backend. I tend to
	default to Google's
	<a href="https://firebase.google.com/">Firebase</a> platform.
</p>
<p>
	When you're wrong with a custom backend, you've got to throw away all the work
	you did on it, in addition to building out the correct solution. If you had
	gone with a platform as a service, the cost will be only to build the new
	correct platform, since you didn't build this super platform in the first
	place.
</p>
<h1 id="get-good">Get Good at Being Wrong</h1>
<p>
	Next time you've got a decision to make in your software projects, ask
	yourself, "What's the cheapest way to be wrong?"
</p>


Leverage your assumptions and mistakes

Get Good at Being Wrong

<p>
	I've found alcohol moderation to be hard at times, so I thought I'd put
	together some simple strategies and thoughts I've found helpful.
</p>
<h1 id="fifteen-minutes">The 15 Minute Rule</h1>
<p>
	Whenever you finish a drink, take a glance at the time. Don't pour another
	drink until 15 minutes from that time. It'll keep you less drunk and focus you
	on other things that are going on. You'll probably also end up spacing more
	than 15 minutes here and there.
</p>
<h1 id="fun-source">Is booze your fun source?</h1>
<p>
	If you find yourself wanting a drink and you're not sure why, ask yourself if
	it's because you're bored. I've found myself in situations where I'm kind of
	bored so I think about having another drink as entertainment. If you're in
	this situation, give yourself at least
	<a href="#fifteen-minutes">fifteen minutes</a> and try entertaining yourself
	some other way.
</p>
<h1 id="autopilot">Is your consumption on autopilot?</h1>
<p>
	I've found myself consuming too much in the past due to not really thinking a
	whole lot about alcohol at all and letting my subconscious steer the
	situation.
</p>
<p>
	The way around this is to re-program your mind so that your default is
	mindfulness rather than constantly having a drink in your hand. Using the
	<a href="#fifteen-minutes">fifteen minute rule</a> is a great way to train
	this into you.
</p>
<h1 id="hunger">Are you hungry?</h1>
<p>
	It's easy to want a drink when you're hungry. Your stomach is empty, and a
	drink will help. Consider if you actually want to have a drink or if you could
	have some water or food instead.
</p>
<h1 id="nobodys-perfect">Nobody's Perfect</h1>
<p>
	This is a hard habit to change. If you're making progress over the long term,
	you're doing it right. It's important to keep at it when you mess up. Nobody's
	perfect.
</p>
<h1 id="drinktracker">I made an app to help out</h1>
<p>
	I made an app to help with alcohol moderation. You input how much you drink
	and at what time, and the app tracks how many drinks are in your system. Over
	time, you get a sense of what numbers you want to see.
</p>
<p>
	There are cues to help with the tricks I describe here too. There's a little
	indicator that tells you when your last drink was, and it turns from black to
	green once fifteen minutes has passed.
</p>
<p>
	If you get too many drinks in your system, the app will turn yellow and then
	red in order to suggest that you might need to slow down.
</p>
<p>
	Check it out here:
	<a href="https://drinktracker.app">https://drinktracker.app</a>
</p>


Some tips and thoughts I've found helpful

Alcohol Moderation

<h1 id="spike">Spike Your Productivity</h1>
<p>
	Get to know your tools!
	<a href="https://tweeres.ca/blog/productivity-toolkit">
		Your tools are part of what sets you apart as a developer.
	</a>
	Using your libraries effectively means less code. Less code means less surface
	area for bugs and less time for your peers to understand and get productive
	with your code.
</p>
<p>
	Many times I've seen people write some complex piece from scratch only to have
	me review their code, point them to a library we've already got included in
	our project, and showing them that what they've done is already implemented
	there. Guess who had to redo their work using the library?
</p>
<h1 id="take-time">Take the Time</h1>
<p>
	Spending that extra bit of time to thoroughly understand everything that your
	chosen tool does is well worth the investment. Take however long it takes to
	feel confident that you know it inside and out. It can be anywhere from a few
	hours for a smaller library to days or even weeks for larger projects or
	frameworks. The more your app relies on the tool, the more sure you should be
	that you know it intimately.
</p>
<p>
	If you choose to use Firebase for example, you're going to be relying on it
	for your entire backend, which means the majority of your code will be
	interacting with it. You better make sure you know everything that Firebase
	can and can't do for you before you start writing production code.
</p>
<h1 id="proofs-of-concept">Small Proofs of Concept Can Speed You Up</h1>
<p>
	Making small throwaway tech demos can really help in this. When I was working
	on a bitcoin project, I was learning
	<code
		><a href="https://github.com/bitcoinjs/bitcoinjs-lib"
			>bitcoinjs-lib</a
		></code
	>. I created a simple app with
	<a href="https://github.com/facebook/create-react-app">Create React App</a>
	that generated a Bitcoin
	<a href="https://en.bitcoin.it/wiki/Mnemonic_phrase">mnemonic phrase</a>
	and then generated a number of
	<a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki">
		Hierarchical Deterministic (HD) addresses.
	</a>
	It only took me a couple hours! This simple test helped me understand the
	<code>bitcoinjs-lib</code> tools much quicker than if I had endlessly pored
	through the documentation, and saved my codebase from exploratory code.
</p>
<p>
	I usually stick these small projects in a subdirectory in my project called
	<code>poc</code> (proofs of concept).
</p>
<h1 id="exception">An Exception: Lodash</h1>
<p>
	There's an exception to this rule: <a href="https://lodash.com/">Lodash</a>.
	There's so much in Lodash that I don't recommend knowing the whole API front
	to back. Instead, I suggest picking through their docs whenever you encounter
	an issue that you think is probably a common problem.
</p>
<p>
	For example, if you think "I need to sort these items in a pretty standard
	way, and I don't want to labour over <code>Array.prototype.sort</code>. Lodash
	must have a way to do this." You're right! Head over to their docs and you'll
	happily discover
	<code><a href="https://lodash.com/docs/4.17.5#orderBy">orderBy</a></code
	>. Keep doing this as I have and you'll eventually learn a lot of the lodash
	API.
</p>


Know Your Tools

<p>
	Your approach to building software is one of two things that defines how
	effective you are as a developer. The other is
	<a href="https://tweeres.ca/blog/productivity-toolkit">
		technology selection.
	</a>
	Here is my approach:
</p>
<h1>Readability</h1>
<p>
	My number one goal for all code I write is to make it as readable as possible.
	That is, if someone (for example, me a month from now, or someone who's never
	seen it before) looks at my code, how quickly can they understand what I'm
	trying to do? The sooner a developer can get their bearings in your code, the
	sooner they can contribute. I've had instances where I've spent hours poring
	through a piece of code before I understood it well enough to finally be
	confident in how to approach my problem. This time should be minimized.
</p>
<p>
	This is, in my opinion, the number one goal of code. Everything else is in
	order to support enhancement of readability.
</p>
<h1>
	<a href="https://en.wikipedia.org/wiki/KISS_principle">
		Keep it Simple
	</a>
</h1>
<p>
	Simple code is easier to reason about than complex code. If I'm faced with a
	coding problem, I always think: "What's the simplest and most obvious way I
	can solve this?" A complex approach could run more efficiently or make you
	look smart, but it will most certainly increase the time it takes for another
	engineer to understand your code. We want to avoid that.
</p>
<h1>As Little Code as Possible</h1>
<p>
	This is an application of the previous two ideas. As a rule of thumb, the less
	code there is, the less there is to reason about, the simpler your code will
	be, and the quicker developers will be able to understand your code. Don't do
	in 20 lines what you can do in 10.
</p>
<h1>Your Code is a Liability</h1>
<p>
	Every line of code you write is a committment to maintain that code in the
	future. The less code you write, the lighter your maintenance workload will
	be. As a rule of thumb, I ask myself "Is this piece I need a differentiator in
	my project?" If not, I try to find a service or an external library to help.
	Which brings me to my next point:
</p>
<h1>Use <a href="https://npms.io/">npm</a> Libraries</h1>
<p>
	We know that less code is better, and the most effective way to use less code
	is to use someone else's! npm is the largest collection of open source
	packages in the development world, and it pays off in spades to use these
	packages and collaborate with the community. By using and contributing to open
	source packages we are sharing our most expensive resources: our developers.
</p>
<h1>Use Functional Programming Concepts</h1>
<p>
	I've found that functional programming concepts have drastically improved the
	simplicity and readability of my code. It can be daunting to shift to fp, but
	incorporating one concept at a time makes it easier. React as a UI library can
	help since it promotes functional programming ideas such as immutability.
</p>
<p>
	My favourite book for learning about functional programming is Kyle Simpson's
	<a href="https://github.com/getify/Functional-Light-JS">
		Functional Light JS book.
	</a>
</p>
<h1>Do Code Reviews</h1>
<p>
	A code review is simply having a developer go and check over your code after
	you've completed it. I've found this useful even when working alone &mdash; I
	go back and check over my own code a few times to look for stuff that is
	unclear, incorrect, or unnecessary. Studies have shown that
	<a href="http://www.ifsq.org/finding-ia-2.html">
		every hour of code review saves 33 hours of maintenance.
	</a>
</p>
<p>
	This is a massive savings that no development team can afford to pass up.
</p>
<h1 class="title">Do Test Driven Development</h1>
<h3 class="subtitle">(when it makes sense)</h3>
<p>
	When writing software that has a bit of complexity to it, it's useful to first
	write a requirement as a test, watch it fail, then write code to pass the
	test, and watch it pass. Then repeat for each requirement in that module.
</p>
<p>
	I've also found simple post-deploy tests that check for a 200 OK response from
	your important URLs useful.
</p>
<h3>Writing Good Tests</h3>
<p>
	A lot of teams nowadays aim for 100% coverage in their testing suites, which I
	disagree with. Sometimes the cost of writing a test isn't worth the value it
	provides, so it's worth doing a bit of a cost-benefit analysis before you try
	to test every single function in your codebase.
</p>
<p>
	One rule of thumb I use is that if I can write a quick test to check the
	result of a single complex function, then I go ahead and do it. Another rule
	of thumb is writing a simple test for each bug I find so that it's caught if
	it happens again.
</p>
<p>
	When to write tests is more of an art than a science, and I recommend
	exploring with more and more tests until you get a feel for what is worth
	testing.
</p>


How I Write Good Software

<p>
	An engineer's toolset is part of what sets them apart. Well chosen tools allow
	him or her to stay focused and productive.
</p>
<p>
	You can get a short version of this post at my
	<a href="https://github.com/tweeres04/what-i-use">
		what-i-use Github repository
	</a>
</p>
<h1><a href="https://reactjs.org/">React</a></h1>
<p>
	React is declarative and encourages a functional programming approach. It's
	focused on just one thing and does it well: User Interface. I can plug in
	whatever technology I want for other areas of my project.
</p>
<p>
	React has a massive community which makes getting support simple. A quick
	google search gets me solutions to any issues I'm having, and leads to awesome
	curated content like
	<a href="https://reactpatterns.com/">React Patterns</a> and this
	<a href="https://devarchy.com/react">
		React component collection
	</a>
</p>
<h1><a href="https://firebase.google.com/">Firebase</a></h1>
<p>
	Firebase is a Backend as a Service. It provides a place to host my app and a
	database to store everything. It also provides a simple API for authentication
	and security. The documentation is clear and concise, and since it's owned by
	Google, it's constantly being invested in and improved.
</p>
<p>
	Firebase also has some awesome extras that make it go above and beyond like
	realtime data updates and simple push notifications.
</p>
<p>
	Having Firebase take care of backend services lets me focus on what makes my
	project shine.
</p>
<h1><a href="https://bulma.io/">Bulma</a></h1>
<p>
	Bulma is a simple CSS framework that provides a number of well-designed and
	commonly used user interface components like buttons, cards, and toolbars.
	Using Bulma's preset components saves me the tons of hours of CSS development
	I'd need to build these components from scratch every time.
</p>
<p>
	Bulma doesn't come with any Javascript, meaning it can focus on what it does
	well: CSS and design.
</p>
<h1>
	<a href="https://github.com/facebook/create-react-app">
		Create React App
	</a>
</h1>
<p>
	Create React App is the fastest way to get up and running with a React Single
	Page Application. It sets me up with a configuration that works for most
	projects so I can focus on building software. It has an active community so it
	also keeps me up to date on best practices for code linting (checking for
	common coding errors), compiling (turning source code into production ready
	code), and other development operations stuff it takes care of.
</p>
<h1><a href="http://eslint.org/">ESLint</a></h1>
<p>
	ESLint highlights errors, common potential areas for bugs, and unclear code. I
	hook it up to my text editor so it shows warnings and errors as I code. It
	drastically spiked my efficiency when I started using it.
</p>
<h1><a href="https://prettier.io/">Prettier</a></h1>
<p>
	This is one of the newer tools I use, and it is incredible. Prettier formats
	my code every time I hit save. It'll add in semicolons and proper spacing.
	Since prettier does it automatically, I don't spend any time thinking about
	code formatting, which means I'm focused on what matters.
</p>
<h1><a href="https://lodash.com/">Lodash</a></h1>
<p>
	When programming, less is more. The less code I write, the less code I
	maintain, the less surface area for bugs. Lodash provides a set of commonly
	used tools that I use regularly. It saves me from rewriting the same things
	over and over or maintaining my own versions.
</p>
<p>
	Since Lodash is open source and used by tons of other developers, I'm sure
	that it's all well tested and bug free.
</p>
<h1>Functional Programming Concepts</h1>
<p>
	I use concepts from functional programming because I've found they keep my
	code simple, concise, and easy to reason about.
</p>
<p>
	My favourite book for learning functional programming is Kyle Simpson's
	<a href="https://github.com/getify/Functional-Light-JS">
		Functional-Light-JS Book.
	</a>
</p>


My Productivity Toolkit

<p>
	I see a lot of people make the same mistake over and over again when asking
	for help. They ask based on their most recent thought -- which is the obvious
	approach -- but they’re making a key error: their most recent thought doesn't
	give any information into their problem! For example, someone will ask
	questions like:
</p>
<ul>
	<li>Is my chest too high when I’m squatting?</li>
	<li>
		Can you help me write a regular expression for a string I’m trying to parse?
	</li>
	<li>How can I release and renew an IP address?</li>
	<li>How can I figure out what studs my walls have?</li>
</ul>
<p>
	These questions don’t give your expert enough information! You've got to
	include the original problem you're trying to solve. Some improved examples:
</p>
<ul>
	<li>
		Is my chest too high when I’m squatting? I’m feeling back pain when I come
		back up
	</li>
	<li>
		Can you help me write this regular expression? I’m trying to parse this
		string out into a list
	</li>
	<li>
		How can I release and renew an IP address? I can’t get to facebook right now
	</li>
	<li>
		How can I figure out what studs my walls have? I’m trying to hang a small
		picture
	</li>
</ul>
<p>
	The reason this extra context can help is that you may not actually need the
	answer to your latest thought:
</p>
<ul>
	<li>
		If you feel pain when you squat, you might have errors elsewhere in your
		form, such as in your shoulders or knees, but if you don’t include that
		extra information, the person you ask is likely to just say “Your angle
		looks good, keep it up!” when they may have noticed something else about
		your form had you included the extra context
	</li>
	<li>
		If you’re trying to parse a list, you might not actually need a regular
		expression! You might be able to do it with a split function. If you
		included that extra info, your expert may have explained that you don’t need
		a regular expression and saved you a ton of time of going down the wrong
		path.
	</li>
	<li>
		If you’re trying to get to facebook, you might release and renew to no
		avail, only to find that your problem was with your web browser! If you
		included your intent, your expert might have taken you through some
		troubleshooting steps to identify the issue rather than learning how to
		release and renew without actually fixing your problem.
	</li>
	<li>
		You might figure out what studs your wall has, but if you’re hanging
		something small, you probably don’t need the extra support of wall studs and
		are wasting your time! If you included your intent, your expert may have
		explained that you don’t need to worry about it since your drywall can
		handle the weight of what you’re hanging
	</li>
</ul>
<p>
	I see this issue almost on a daily basis. You can save yourself, and the
	people you ask for assistance, a ton of time if you include the context of
	what you’re trying to achieve.
</p>


Tyler Weeres

Blog Posts 18