<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>
<h1 id="no-starchy-sugary-carbs">No Starchy or Sugary Carbs</h1>
<p>There are no starchy carbohydrates on this diet. no:</p>
<ul>
	<li>Grains (Corn is a grain)</li>
	<li>Starchy veggies (potatoes, yams, etc)</li>
	<li>Sugar</li>
	<li>Fruit (1 piece of fruit per meal allowed on weightlifting days)</li>
</ul>
<p>
	Focus on all the delicious food you can eat instead. Roast, steak, stir fry,
	bacon, kebabs, stew, cheese! Yum.
</p>
<h1 id="eat-more">Eat More</h1>
<p>
	Since there are no 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 9