Glenn Stovall
Author Archives: Glenn Stovall
When people talk about optimizing their site, they could mean a few different things. Are they talking about performance? Are they tracking a certain engagement, such as email signups or clicks on a call-to-action? These go hand in hand. Bugs and performance issues will cost you sales and signups. The same goes for Usability. The harder your site is to use, the less it will be able to help others. Accessibility is too often ignored by developers and stakeholders, but accessibility isn’t just for those that are differently abled. More accessible sites
When it comes to optimizing a page, that means you can’t focus on a single metric, you have to look at everything:
Before optimization is made, the decision has to be made: Do you want to improve on what’s already there, or build something new from scratch? In most cases, I’d argue that you would prefer to work what’s already there. This allows you to iterate and get improvements out the door faster. We tend to underestimate the cost of starting a new project from scratch. A site has to be in some kind of state before I’m willing to declare bankruptcy and start from scratch.
Here’s how I tackled updating a single page landing site. You can apply these techniques to your own sites or future projects.
One of the impetuses of this project was that no one had touched the marketing site in a couple of years. As a fast-moving company, the original messaging had grown stale and unreflective of where the company was today. It was time to take stock of who we were, what problems we solved, and who we aimed to help.
Most marketing pages make the mistake of being selfish. Here I am, here’s my product, here are its features, and here is my call to action, isn’t it awesome?
The world has enough of those marketing pages. That’s not a story worth telling.
Marketing pitches need to be thought of from a perspective of the reader first and followed then by service. No one cares about you, or your product. they care about themselves, and the problem you aim to fix.
What we want are structure and narrative. All landing pages should tell the same story. In 30×500 it’s called “Pain-Dream-Fix”. I call it the “infomercial pitch”:
Hey, you know ${PROBLEM}? Does that stem from ${ROOT_CAUSE}? Imagine your life without it! Well, now you can have that life with ${SOLUTION}! ${SOLUTION} will solve the problem, despite ${COMMON_OBJECTIONS}!
Go watch any infomercial, and you’ll see some version of that story in the first 45 seconds. We aren’t the main character in our story, our customer is Our product is either the Yoda to their Luke Skywalker or their Ocarina from Legend of Zelda: Ocarina of Time.
How do you decide what your narrative should be?
Before we start rewriting, it’s time to see what we know. Open a Google Doc and start taking notes on the following.
Our target audience is people in a specific segment of the logistics industry. For this reason, I’m comfortable using insider lingo and slang terms. This shows that we know how to “talk that talk” and can build trust.
They are typically reading this at some midpoint in the sales cycle. So, we don’t have to worry as much about the “What is our product / What is your pain?” questions and we can focus more of the “Why you should solve your problem this way.” part of the equation.
Answering questions like common objections and unique selling propositions may have been answered in existing material, such as brochures or sales scripts. We don’t get points for originality, we get points for effectiveness.
Once we’ve figured out the broad strokes, we can zoom in on the smaller but important bits of copy: Headings and calls to action.
How do you start optimizing small bits of copy? By iteration. Start thinking of several variants to each piece of the copy. Sky’s the limit. Here are a few principles from Breakthrough Advertising to help you get started:
If you want a fun exercise, try going to your webpage and try rewriting headlines and calls to action with some of these ideas in mind. For example, the site originally used the phrase “request a free trial.” That was inaccurate as it was more of a high touch sales process and personalized demonstration of the software. Instead, this was rephrased as a “free consultation.”
Once you feel good about what you have to say, and I cannot stress this enough, not before, It’s time to start thinking about how you’re going to say it, and what it’s going to look like.
I write in a simple text editor. This helps me focus exclusively on content and copy. By working in HTML or a rich text editor, the text gets muddled with design, and compromises are made in the content at the service of the aesthetics of the site. Both are weaker for it. The aesthetics of the site should support the message, not the other way around. I’d rather remove or replace elements instead of creating content just to fill them.
First, it means placing a priority on readability. People are constantly distracted online, which hinders their literacy at that moment. Make your text as legible as possible. Some rules of thumb for more readable text.
Once we’ve taken all of this into account, It’s to make sure that our site performs well. Every tenth of a second added to a page load decreasing the chance that people will read your site, much less convert. There are two main levers you can pull to improve your performance: Eliminate items that decrease page speed and increase page weight, or improve the ones that remain. Let’s look at each, starting with minimizing the existing page.
Every element on the page must make a case for its existence. The question you should be asking is “why should we keep this?” not “Why should we remove this?”. The second question has a default answer: Every element on the page provides the reader with more distraction, cognitive load, and page weight. Nothing is free. If any part of the page isn’t pulling its weight, it needs to be removed.
Let’s start at the navigation. This example is a single page site (If you don’t count the free consult form and tertiary pages like privacy policy). It contained a home button, but we also use the logo as a home button. That can go. In fact, all of the navigation besides the call-to-action and the log in button for existing customers can be eliminated.
Elements that don’t support the pitch are cut as well. We do not need a “meet the team” section, as the team is immaterial to the customer and problems they face. We do not need a map next to the contact form, an address will do. That means no more loading all the Google Maps scripts, so big win there. FAQ Section? Many were not so frequent, and we can address other questions with the copy itself.
With new persuasive copy and a lighter look, it’s time to start optimizing the page, so that people can read it as fast as possible.
Performance is important for a number of reasons. It is a well-documented fact that page speed has a direct effect on conversion rates. In addition, our research has shown that our potential audience is constantly in contexts where they are using older browsers and machines or may be on a mobile device in a remote area with poor service. So its time to start cutting the page down.
There are a million different tactics, tips, and tricks to optimize web performance. It is a very deep rabbit hole where you quickly hit diminishing returns. For now let’s focus on what can get us big wins without doing a ton of work or restructuring the page: Everything we can do to see less data or the line and do so in fewer requests.
To start, we can remove a lot of the theme cruft we’ve inherited. This page was loading five different JavaScript libraries that were not being used. As mentioned earlier, we were able to cut other dependencies like Google Maps. This theme also had several CSS configuration options that were of no use, so we can cut down on a lot of the CSS.
We can further reduce the page weight by ensuring that our images are optimized. For this I like to use ImageOptim for images and OMGSVG for SVGs.
After we’ve done these page weight tactics. There’s another two great tools available for free, and one of them is built right into your browser. First, there is Lighthouse inside of Google Chrome. It can also help by simulating mobile devices and slow internet connections. The other is YellowLab. Both of these tools can give you specific feedback on how to make your website load faster. Running your site through these can give you some other ideas for where you could find some improvement.
| Before | After | |
| Requests: | 90 | 30 |
| Page Size: | 1.6MB | 1.3MB |
| DOMContentLoaded: | 867ms | 640ms |
| Load Time: | 1.96s | 1.32s |
| Lighthouse Performance Score: | 57 | 97 |
| Lighthouse Accessibility Score: | 69 | 70 |
| Lighthouse Best Practices Score: | 67 | 80 |
| Lighthouse SEO Score: | 89 | 100 |
As you can see by the scores, there is still work that could be done. However, at some point, you start to hit diminishing returns on performance. Since we serve a small, targeted audience with a high touch sales process, optimizing this will only bring so much value. Compared to the price of doing a full-scale redesign, this approach nets a higher return on investment.
If you lack a systemized process for setting and achieving goals, your likely to run into all sorts of problems:
Plenty of people will tell you the importance of setting goals. What people don’t tell you is how to choose, set and accomplish them.
In Measure What Matters, John Doerr lays out an approach to goals to tackle these challenges. John taught this to industry juggernauts Google, Intel, Adobe, and Intuit and others. Its design increases focus, commitment, and ambition. Among teams, It fosters alignment, transparency, and accountability.
The system is OKRs, short for Objectives and Key Results. An Objective is something that you intend to accomplish, your goal: Your what. An objective contains several key results, which are objective, quantifiable measures of progress: Your how.
Here’s an example OKR From their website:
the system works like this:
Before deciding your objective, you have to decide where it is you want to go. If objectives are what you are doing, and key objectives are how you are doing it, then where you are going is your mission.
For example, Google’s mission is to “Organize all the world’s information.” Your personal mission may be raising your children or gaining financial independence. Your company may have one of these plastered on a wall or ‘about’ page.
Choosing objectives you can commit to takes deep thinking. Don’t try to define objectives no Monday and begin working towards them on Tuesday. Give your self some time to consider exactly what it is you want to accomplish.
When you’re ready to move forward, lets take a closer look at how to define quality objectives and key results.
Objectives need to be clear and understandable. In the Healthcare.gov example you’ll see that while the objective sounds initially vague, the key results give it precision. You can set up systems to measure each of these and determine objectively how well you achieved your goal. Another benefit of clarity is that it increases alignment within a team. There’s no debate about what we are all working together to accomplish.
Achieving every key result achieves the objective. If that isn’t true then you need to tweak your OKR. One trick recommended in the book is to try to rewrite your objectives and key results ending with “as measured by ________”. In this case, your objective is measured by the sum of all key results.
Objectives must be worth achieving. What’s the point of pursuing a goal that isn’t going to have a significant impact on your business or life?
You should timebox objectives. The time frame could be monthly or quarterly, but its recommended to not think in longer time frames. Longer time frames mean aiming for more ill-defined objectives. Shorter time frames may be ok at the start, as a warm-up, but it is hard to accomplish significant work in a weekly time frame.
Write down your objectives. If you don’t, then they cannot be clearly discussed and people cannot be held accountable.
Key results must be measurable. As a general rule, they should be a number. “Deliver prototype by 10/31” is a number. On that date, the number of delivered prototypes will be zero or one.
These numbers should also be objective. Getting approval from a manager is not a good key result is all it relies on is one person’s discretion. If you want to set results for measures of quality such as user experience, find ways to quantifiably measure that, through either analytics or surveys.
Key results should include measures of quality. All metrics are games, and key results should be defined to prevent harmful gaming. For example, “publish 100 blog posts this quarter” is a dangerous metric, because it contains no bounds what a “blog post” is. A team ignoring quality could hit this target in weeks if not days. You could improve this KR by also defining a metric around the impact of the posts, such as conversion rates, engagement, etc.
Here’s where I think the system goes from solid to genius: When it comes to setting your goals, you should aim for a success rate of 70%. Aiming for a 100% goal rate gives you an incentive to set less ambitious goals. Have a hit rate too low means you are setting goals that are unachievable. 70% is a good middle ground: You succeed more than fail, but you are still stretching and being ambitious.
Imagine how different education would be if you were encouraged instead of punished for tackling challenges outside your comfort zone.
As a gut check, take stock of how you feel when you look at the OKRs you are responsible for achieving. How do you feel? Do you feel very confident that you pull them all off? Then you didn’t stretch enough. Can you shorten deadlines or increase targets?
What if you feel scared like there is no way you’ll even come close? That may be a sign that you are reaching too much. Setting goals that are unreachable are defeating. If you know you won’t come close, why should you try? What will motivate your team?
But, if you look at your targets, and you feel like maybe you could achieve these, or at least most of these, if you push yourself, then you’ve found the Goldilocks zone. You have objectives that will test you, but with a test that you can pass if you get outside your comfort zone.
As my coach likes to say: “Get comfortable being uncomfortable.”
While objectives completion is always a clear yes or no, measuring progress and achievement can be more nuanced. Let’s say in our previous example of writing 100 blog posts in a quarter. You could write 70. While you did not achieve the goal, you did achieve 70% of it. Think about measuring each of your key results on a 0.0 – 1.0 scale, with the following goal posts:
These numbers should be from both objective metrics and self-evaluation. Consider the 99% uptime key result from the earlier example. If your site has 70% uptime, would you say that’s yellow or red? In that scenario, a more reasonable scale would be something like < 95% uptime is red, 95-98% is yellow, and 98-99% is in the green range.
You may also consider separating objectives into “stretch” and “committed” categories. Some goals may be important to hit and you should really be thinking about going for 100% there. Others may be more ambitious but also less costly if they fail, so aiming higher there is ok.
Instead of annual or quarterly performance reviews, the OKR system encourages continuous feedback with another acronym: CFRs. CFRs stand for Conversation, Feedback, and Recognition. Conversations should focus on facts over feelings, and process over outcome. These are not a replacement for annual or quarterly performance reviews, which are used to determine other measures, mainly compensation based on performance. It’s important that you divorce feedback on goals from compensation. Changing compensation is backward facing and about the person, while CFR discussions are forward facing and about the goal. Both are more effective when decoupled. Here are 5 questions from Measure What Matters that can help frame these discussions:
As teams work together, it’s important to remember to recognize when others do well in a public and visible manner. It helps people remember how their work helps others.
OKRs are primarily designed for teams, although I think they are valuable for individuals also. When working in teams, how multiple OKRs interact with one another is another powerful part of the system.
OKRs cannot be written and handed down from up high. You must write them collaboratively. However, One manager’s Key Result and be someone else’s objective. For example, let’s look at the Healthcare.gov example again. Let’s imagine that this OKR is from the CTO who is responsible for the project. One of the key results is 99% uptime. This could be an objective for the person or team who is in charge of systems administration, who could then define sub-KRs that could them achieve that objective. You can break the KR “Response time of under 1 second” into other objectives and key results for front end and back end development teams. While OKRs are not assigned top-down, they do cascade down or sideways. This helps people contributing at any level to see how their work connects to the bigger picture.
A single person should own objectives. If that’s not possible then they should be owned by a single team. Focus is important, so no single person or team should have more than five objectives. Another benefit is the focus that this brings. If work does not go towards or at least facilitate the pursuit of a key result, then you can confidently remove it from the backlog of tasks.
The interconnectedness leads to another feature of OKRs in teams: They must be transparent. Everyone can see everyone else’s OKRs along with progress. It helps keep people honest. It also helps avoid situations where teams are blind to others work. One team might be able to help another if they knew the challenges another team was facing. Or it is possible that teams have conflicting goals and are working against each other without knowing it. Transparency breeds accountability and alignment. This also helps encourage clarity in objectives. If everyone in the company can’t understand it, it may need some tweaking.
With these systems, you need to encourage a culture that supports safety. By that I mean if you are encouraging people to stretch for goals where they will fail 30% of the time, then people need to feel comfortable talking about mistakes and failures. transparency is easier when you know you will not be mocked or admonished for taking risks that might not pan out. On the flip side, you should also aim for a culture that encourages doing quality work and being a place where you can count on others to do so as well.
According to a study by Deloitte, the largest increase in job satisfaction and productivity comes with a company has clearly defined goals, written down, and shared freely.
I think OKRs are useful not only in a team setting but individually as well. After reading Measure What Matters I’ve begun applying the system to personal goals like finance. OKRs are a big shift that will not overhaul a company or a human overnight. Start small. Maybe you can set 1 – 2 OKRs on your own, or with your team. Try one for a weak or a month and see how it feels. If you are seeing positive results and getting your footing in systemized goal setting, you can begin to expand how often you use them.
I also would not recommend jumping in too quickly. Don’t try to define OKRs and commit and implement them on the same day. Take some time to reflect on what you are doing and how you’ve defined it. Another thing to remember is that OKRs can be flexible. Don’t give up on an OKR because its hard, but feel free to adjust definitions and key results if you find better ways to measure them. If you realize that an OKR no longer seems to have meaning or impact, kill it. If you finish your 3-month OKR in two, consider starting another one early.
By implementing these systems, you can overcome most of the common reasons people don’t achieve their goals. Let’s look at the list from before, and how you could approach setting goals differently now:
It’s not magic, but it’s also not easy. OKRs won’t magically make you a 10x productivity wizard or fix a toxic company culture, but it can give you a framework and a process from which you can make improvements.
Today the react-redux team released version 7.1.0, which adds hooks to react-redux! Here’s a quick comparison of how it could change how you write components.
useSelector: Pass in a function that takes the state as an argument and returns a value. Used to get a single value from state. Can act as a replacement for mapStateToProps.useDispatch: returns a reference to the dispatch object. It can act as a replacement for mapDispatchToProps.useStore: returns an instance of the store. Generally not recommended.An example component that stores a query and when a form is submitted to search. I wanted to keep the example simple, so use your imagination for the part where it fetches results.
import React from 'react'
import { connect } from 'react-redux'
const defaultSearchBar = ({ query, updateQuery, handleSearch }) => {
const handleSubmit = (e) => {
e.preventDefault()
handleSearch(query)
}
const handleChange = e => updateQuery(e.target.value)
return (
<form onSubmit={handleSubmit}>
<input
name="search"
value={query}
onChange={handleChange}
/>
</form>
)
}
const mapStateToProps = state => ({
query: state.query,
})
const mapDispatchToProps = dispatch => ({
updateQuery: newQuery => dispatch({ type: 'UPDATE_QUERY', payload: newQuery }),
handleSearch: newSearch => dispatch({ type: 'NEW_SEARCH', payload: newSearch }),
})
const connectedSearchBar = connect(
mapStateToProps,
mapDispatchToProps,
)(defaultSearchBar)
In our new example, we have a few differences: We eliminate the connect function, mapStateToProps, and mapDispatchToProps entirely. This means our component no longer takes in props directly. Now, our form looks like this:
import React from 'react'
import { useSelector, useDispatch } from 'react-redux'
const hookedSearchBar = () => {
const dispatch = useDispatch()
const query = useSelector(state => state.query)
const handleSubmit = (e) => {
e.preventDefault()
dispatch({ type: 'NEW_SEARCH', payload: query })
}
const handleChange = e => dispatch({ type: 'UPDATE_QUERY', payload: e.target.value })
return (
<form onSubmit={handleSubmit}>
<input
name="search"
value={query}
onChange={handleChange}
/>
</form>
)
}
If you have code that gets shared frequently between components, you can create a custom hook to keep all of that functionality together. Here’s an example of us isolating the redux-specific part of our form into its own hook:
useSearchQuery = () => {
const dispatch = useDispatch()
const query = useSelector(state => state.query)
const updateQuery = query => dispatch({ type: 'UPDATE_QUERY', payload: query })
const updateSearch = search => dispatch({ type: 'NEW_SEARCH', payload: search })
return { query, updateQuery, updateSearch }
}
The ability to create redux hooks above is interesting, but I am also concerned that it could make code harder to test, as testing these components is already dead simple. I’m not sold either way, but I hope this comparison makes it easier for you to make informed decisions about your code base.
Hooks are a great new feature in React. The first initial case I found them useful was where we had to create class components just because we wanted to use a single ref or store one variable in state. Now in those cases, we can use hooks to write more succinct code. Here’s a quick example using useState :
class SearchBar extends React.Component {
constructor(props) {
super(props)
this.state = {
query: ''
}
}
render() {
return (
<form action="https://duckduckgo.com">
<input
type="text"
name="q"
onChange={(e) => { this.setState({ query: e.target.value }) }}
/>
<input type="submit" value="search" />
</form>
)
}
}
const SearchBar = () => {
const [query, setQuery] = useState('')
return (
<form action="https://duckduckgo.com" >
<input
type="text"
name="q"
onChange={(e) => { setQuery(e.target.value) }}
/>
<input type="submit" value="search" />
</form>
)
}
useRef is similar. However, working with useEffectis a bit different. It’s designed to replace several lifecycle methods, such as componentWillReceiveProps, componentWillMount, and componentWillUnmount. It doesn’t map one-to-one to old functionality like state and ref, which makes it more difficult to “think in effects.”
Here’s what finally made it click for me: the first two arguments of useEffect are a function (didUpdate), and an array of dependencies. the didUpdate function can return a function of its own, a cleanUp function. When a component mounts or the dependencies are updated, didUpdate is called. When the component unmounts, cleanUp is called if present.
Once you grok how effects work (“when this variable changes, do something”) over the lifecycle methods, you can save yourself a lot of headaches in code. You no longer have to write code like this:
componentWillReceiveProps = (nextProps) => {
if (nextProps.position !== this.props.position) {
this.moveMap(nextProps.position)
}
}
You can now write more succicnt statements like this:
useEffect(() => { moveMap(position) }, [position])
Here’s another example is using useEffect to replace componentDidMount and componentWillUnmount for setting and clearing event listeners. By declaring the dependencies array as empty, you only call the didUpdate and cleanUp functions once each. No dependencies mean no updates.
componentWillMount = () => {
/* attach listeners to google StreetView */
const streetView = this.getStreetView()
window.google.maps.event.addListener(streetView, 'zoomChanged', this.handlePovChanged())
}
componentWillUnmount = () => {
window.google.maps.event.clearInstanceListeners()
}
getStreetView = () => { /* ... */ }
handlePovChanged = () => { /* ... */ }
const getStreetView = () => { /* ... */ }
const handlePovChanged = () => { /* ... */ }
const { addListener, clearInstanceListeners } = window.google.maps.event
useEffect(() => {
const streetView = getStreetView()
addListener(streetView, 'on', handlePovChanged())
return clearInstanceListeners
}, []) // empty dependency array = only called on mount and unmount
Instead of grouping functionality by when they are in the lifecycle, you can group them by concern. It makes your code easier to reason about.
There’s one problem. You can’t use useEffect (or any other hook) in a class component. Hooks are only available in functional components. If you want to refactor your lifecycle methods to use useEffect, you have to refactor entire class components writ large. This is both time-consuming and prone to error. What if you could refactor just this one part of the code?
Considering that:
We can see a solution: create a functional component that encapsulates the useEffect behavior, and use that in your class components! It’s a take on the adapter pattern from object-oriented programming: We create a wrapper that encapsulates the functionality of a piece of code (useEffect), while changing its interface. A hook in component’s clothing. 🐺
Here’s a simple one I use to replace componentWillReceiveProps checks like the one above.
const observer = ({ value, didUpdate }) => {
useEffect(() => {
didUpdate(value)
}, [value])
return null // component does not render anything
}
<Observer value={this.props.position} didUpdate={this.moveMap} />
You don’t have to pass the argument to didUpdate, but in this case I found that the easiest way to have access to that variable. You could also create a similar component to handle mounting and unmounting behavior.
const mountHandler = ({ onMount, onUnMount }) => {
useEffect(() => {
onMount()
return onUnMount
},[])
return null
}
You could combine these into one component, or create more specific adapters that encase more business logic themselves. Do what works best for your codebase. Ideally, these a stop-gap solution that help you refactor class-based components incrementally. Here’s the strategy I used:
In the end, You end up with code thats easier to reason about and more performant. Hope this helps!
Projects are sometimes doomed long before any designers or developers are brought in. Your work will never provide value or even see the light of day if you are working on something where the only possible outcomes are failure and mediocrity. But some can be saved. You can make it work. Your career will be better off if you can learn to avoid these projects and work within given constraints.
The first design decision on your project was made when a budget was allocated.
Mike Monteiro, Ruined by Design
I use Mike’s broad definition of design: making decisions on how a system works is doing design. Stakeholders, project managers, and developers all design. Marketers could also benefit by realizing what they do involves design. Some developers don’t see it that way. They think they just write code. That’s wrong. We’re problem solvers, systems designers, and the people who need to help others navigate this ever-expanding technological jungle we are building. We can deliver better work and more value to those we serve if we understand our role in the design process.
Let’s take another look at the budget.
Various software projects can be attempted, sometimes even completed, for just about any budget. You could build a real estate listing site for $5k, $50k, or millions of dollars. You could spend $32 million building a holistic solution and not ship a damn thing.
Budgeting for software is like buying a house or a car. There is a wide range of options, and it depends on your situation at the time and plans for the future. And like major lifestyle financial choices, typically the budget is the biggest constraint we have to consider when building software.
Then our challenge is this: how can you help projects fit into a predetermined budget?
Different tech stacks come with different costs. If you are implementing the work one of the biggest factors may be your experience with it. Using the shiniest new tool is often not going to be the most efficient. Plenty of successful projects have been shipped with WordPress, PHP, or Ruby on Rails, and were successful.
If you can’t fit every feature in, you have to decide which features need to go. That’s part of the design. As a developer, it is your responsibility to help stakeholders understand the value of work that may not seem apparent. People will want you to do your job poorly, and call it “cutting features.” Security, accessibility, usability, and testing are not up for debate in this conversation. Those are features, those are taking care of the people that use what you build. Ignoring them makes you a jerk.
Instead, strong candidates for deferment or deletion are features where you say “we may need it one day”, or “what if…”. If you aren’t sure if you need it and you need to make cuts, start there. The more user research that has been done at the point, the more confidently you can argue for these changes.
If a feature doesn’t need to be killed outright, then you can always defer it to the next version. Keeping things for a version 2 or 3 means can be more palpable than saying they won’t be done outright.
If you can’t cut a feature, maybe you can pare down a feature. I love the term Scope Hammering. As Jason Fried puts it:
We take the chisel to the big block of marble and figuring out how to sculpt, nip, and tuck a feature into the best six-week version possible. It’s all about looking carefully at a feature and figuring out the true essence. Not what can it be, but what does it need to be?
Jason Fried, How we Structure our Work and Teams at Basecamp
Make every form field, database column, and page defend its existence. For example, once I worked with a company that wanted users to enter their email, password, username, business name, age, and gender on a signup form. This raises all kinds of concerns, and opportunities to pare down scope:
Now we have a simple form with two fields. Its probably more effective with less and time and resources invested. And now that it is something that fits into a common pattern that brings me to my next point:
Something built from scratch has no more inherent value than an open source library, paid plugin, or 3rd party API within your application. One of the biggest mistakes I see developers make is to try and build their own solution when perfectly cromulent solutions exist. Often times, A pre-built solution will have been more battle-tested, and therefore reliable than building something from scratch. There are situations where it makes sense to build your own solution, but there has to be a good justification. Either there is nothing that exists, or what does exist meets your required use case (see previous two sections.)
Sometimes, you can cut features, reduce the remaining features down to their core essence, and find a way to piece together a solution with existing tools and services, and still not have a way to deliver what’s requested within budget. What do you do with stakeholders then?
You tell them.
Let me tell you a quick story. I once have several phone calls with a potential client. They wanted to start a new project that sounded interesting and seemed like it could do some real good in the world. I was excited, and so was she. Then, we get down to talking about price.
Me: “I think a project at this scale would be in the range of $15,000 – $20,000”
Her: “My budget is $500.”
I was crushed. I had put so much work into the project proposal and now I knew it wasn’t going anywhere. There’s another lesson in here about doing budget discovery, but that’s for another article. Instead, it didn’t matter what I designed. It was superseded by the design choice that was already made.
At this point I could have ended the call and marked the deal as lost in my CRM, but instead I took the opportunity to try and help this person understand the costs of what goes into software development, and tried to help them have more realistic expectations.
Project planning with stakeholders should be collaborative, not combative. If you can find alternate solutions that work within the budget, do it. If you can’t, have an honest conversation about it.
A project’s success lives or dies on every decision that is made along the way. Sometimes those decisions are out of your hands, but other times you have an opportunity to help those decisions end in conclusions that help a project move towards success. That’s the real job of a developer, not just to write code.
P.S. If you want to learn more about delivering software on time and within budget, you can learn more by checking out a sample chapter of Dependable.
Get the bonus content: Dependable Sample |
Recently I received these questions from a reader:
My Answer:
There are two ways you can generate leads: Inbound and outbound. I think of them as hunting and gardening.
Inbound leads are acquired through gardening. Gardening is consistent efforts to build trust and relationships with potential clients and colleagues. Examples include having conversations, writing, and speaking. Inbound leads tend to be of higher quality and an easier sell. When someone seeks you out specifically, you already have their interest, and they come with pre-existing knowledge of what it is that you sell.
However, gardening takes time. You cannot plant lettuce when you need to eat a salad for lunch. In those cases, you have to go out on the hunt. Looking for clients directly can get you work quicker, but it comes with a cost. When people are out looking for developers, you’ll be competing against the field. This means you may end up making less than you would from a higher quality lead, and end up in a position where you are treated strictly as a labor source, and not as a trusted advisor.
Some tactics are outlined here: A Guaranteed Strategy For Getting Your First Clients. These were intended for people just getting started, but can be put to work at any point in your freelancing career. In a moment I’ll outline my go-to hunting strategies, but first I’d like to show how the five tactics from that article can fit into this gardening/hunting paradigm:
Without getting into the weeds, I’d say one important takeaway here is that you need to find gardening habits and do them every day. Doesn’t matter if you are full on client work, or if you are in a slow period. ABG: Always be gardening.
But when you need work today, it is time to out on the hunt.
There are two tactics I’ve found the most useful for picking up work quickly. Direct Outreach and Prowling Slack Channels.
Ask any freelancer and they’ll tell you that one of their biggest sources of business is word of mouth. The problem with that is that it isn’t actionable. Sit on your butt and wait for work is not a long-term viable strategy. Instead, you need to make word of mouth proactive. Start reaching out to your network, and ask for referrals. “Do you know anyone who could use help with ${technology or business_domain}”? Asking to help others lets them know that you are looking without forcefully trying to sell them on your services, but does leave the door open if they have something for you.
I have found prowling slack channels surprisingly effective. There are a number of public Slack and Discord channels for developers. These may be centered around a particular tech stack or geographic region. These often have a #jobs or #gigs channel. It’s easy to keep an eye on them if you are already using Slack for work. When someone posts a job, try to respond immediately. If you can catch someone at that particular moment, you have a good chance at landing the business.
Two things about using Slack to hunt for work: Don’t make posts saying you are looking for work, and try to get the conversation off of slack as soon as possible.
The first is because it rarely works and looks pathetic. The second is because it is too easy to get lost in the shuffle of a slack conversation. Bonus points if you can hop on call that minute. You instantly raise the fidelity of the conversation and show that you are eager to help them solve your problem.
As an added bonus, these public Slack channels can provide a place to practice habits 3,4 & 5 from above. They aren’t a replacement for in person, in depth conversation, but the ability to lightly network 24/7 from anywhere in the world does have some value.
I’ve experimented with niching/positioning quite a bit. I don’t think it needs to be an all-in commitment. but it can help you bring some focus to some of the strategies above. First, let’s think of some of the ways developers can niche down.
If you are looking for some inspiration, Philip Morgan has written extensively on the topic. His page of specialization examples is a great resource to help get you thinking of ideas.
In my personal experience, I’ve seen the least amount of success with the third. The reason for this is that as a developer, the problems you are being brought in to solve don’t often map well to the domain knowledge of that industry. If they do, they tend to manifest in either the problem domain or the technology choice. While I’ve worked with several companies that looked to build a marketplace and complex ecommerce solutions, it leads to people looking for people with experience with common technologies in that space, like Stripe and Shopify.
This doesn’t mean that you can’t niche on a business domain, but to have success with that you will find yourself moving farther and farther away from doing software development. For that reason, I’m not going to focus much on that avenue here. Instead, let us look at how we can put positioning into practice with some of the above tactics.
First, positioning does not have to be a permanent or all-encompassing decision. There’s merit it not chasing multiple rabbits, but there is also more risk in putting all of your eggs in one basket. Happy Easter everyone!
Instead, let’s focus on using positioning to give us more focus and direction while practicing the above tactics. We can then try one or more experiments. For this example, I’ll take a technology from my recent work: React Here are some ideas for things I could do to find some react work:
The more you do these in tandem, the more they help each other out. Positioning can’t be a one-off strategy, and it can help you get unstuck when you don’t know what to write about, or who to approach. I never committed fully to one niche, however, if I found one of these strategies really started to pay off that may change one day.
If you have any questions of your own, feel free to reach out! Time allowing I’ll write a response like this one.
Why is speed important?
One of the most common recurring conversations I had with startup founders was how to get products and features out the door faster. Typically, all is running smoothly until it’s time to actually push your work out into the wild. People want to buy the poster that says “move fast and break things”, but they end up not doing the former, causing more of the latter. One of my core tenants in Dependable was to help move projects forward by making sure everyone checks egos at the door and gets out of their own way.
Fear is the project killer.
So why is moving fast important? When put on the spot recently, I blurted out “because life is short and we’re all going to die one day.” I thought I should try to collect my thoughts and phrase it in a less morbid fashion.
And to be clear, I am not an advocate of the “move fast and break things” mantra. Facebook lived by it & paid it no mind when they broke things like their interface, their trust among their users, the news media, or American democracy writ large. Moving fast without caring about destination or side effects isn’t speed, it’s haste and recklessness. It’s careening down the highway at 100mph, instead of picking the route to your destination with the quickest route and finding ways to cut out stops along the way.
So don’t be hasty, and don’t be reckless. But be quick, and be aggressive.
When people ask me how work is going, my response is “the good kind of boring.”
How so?
No pressing deadlines. No sense of urgency. A tried-and-true tech stack. Feedback comes in, and I implement changes. I send code off for review and review others — Features ship. Bugs die.
It’s not terrible. But, when my wife comes home and asks me to tell me about my day, I got nothing.
I’m not complaining, but “the good kind of boring” is still monotonous. Every job and every project has doldrums. Periods, where all there is, is the grind. Since these times are inevitable, what can you do to tolerate them better? I have found a few tactics that have helped me, but before that, here is why it’s imperative that you first take ownership of your boredom.
It is not your boss’s responsibility to make your job enjoyable, exciting or fulfilling. That’s on you. You don’t find a job that fulfills you; you find ways to build more fulfillment out of your work. Your happiness is more a function of your self-awareness and self-management than external factors. It’s part of your emotional intelligence. What’s causing your boredom, and what can you do to relieve it? It’s a learnable skill, just like writing, coding, or selling. Now on to those tactics.
Over the last few years, mindfulness has moved from Eastern religious practice to Silicon Valley fad. More than enough podcasts discuss it, so I won’t belabor the point here. Just know this: mindfulness doesn’t have to be a rigid morning routine or even a meditative practice. It can be 5 – 10 minutes of quiet, taking stock of your crazy monkey mind’s contents. We can all 5 minutes. Here’s a trick: The next time you are reading an article online, listening to a podcast, checking social media, or checking your email, don’t. Instead, take a moment to be present. Ask yourself:
Are you honestly working as hard as you can? Is there a way you can Daft Punk your tasks and do them harder, better, faster, or stronger? Actively trying to improve your skills increases engagement. Here’s how I turned one of my first gigs, a data entry job of endless Excel cut-and-pasting, into an enjoyable and fruitful exercise:
I hid my mouse.
Excel has roughly 37,000 hotkeys, of which I knew about 4. I decided to learn more
Are there other tasks you can do outside of your current position? Talk to your coworkers and see what they are struggling with. Another story: Part of working in automation is that you are in a constant state of obsoleting yourself. At one previous job, when I had automated all the significant sections of our marketing funnel at one company, I talked to coworkers about their processes. It turns out customer support had about 1.5 full-time jobs worth of tedious bullshit on their plate. I took on automating that and was able to get others away from their excel sheets so they could do something a little less boring themselves.
What if none the above work? No matter how hard you try to find meaning or challenge in your work, it still seems listless and dull. You doing as much as you can, and you can’t take on anything else.
Good.
That means you are fortunate enough to have a chance to work on your mental discipline. Just as emotional intelligence increases with study and practice, mental toughness increases with training. It works like any other way you increase knowledge or strength. You improve by pushing your limits. You’re bored? Keep being bored. Learn how to be bored. If it’s inevitable, then prepare. If you can’t improve your situation, better yourself.
Here’s a fairly benign component, that can give developers pause when its time to write unit tests for your components:
const ClickableButton = props => (
<button onClick={props.doSomething}>Click Me!</button>
)
const mapDispatchToProps () => ({
doSomething: dispatch(someFancyAction())
})
export default connect(
null,
mapDispatchToProps,
)(ClickableButton)
There is only thing worth testing here: That when we click the button, the function we passed in as a prop gets called. That prop function could be a complex chain of actions & API calls. You don’t want to stress about that, at least not in these tests. But to do this, are we going to have to create
There has to be a better way.
While you want your component to be the default export, you can export the unconnected component, and just test that! Hat tip to Dave Ceddia for show me a better way to export a connected component. All you have to do is change one line:
export const ClickableButton = props => (
As an additional trick, if you have any helper functions not attached to the component, you can export those as well for easy testing.
Inside our test, import the unconnected component. Then, you can create a mock function using Jest, and simulate the click using Enzyme. Here’s what the test looks like all together:
describe('<ClickableButton />', () => {
it('calls the doThing prop when the button is clicked', () => {
const props = { doSomething: jest.fn() }
const wrapper = shallow(<ClickableButton {...props} />)
wrapper.find("button").first().simulate("click")
expect(props.doSomething).toHaveBeenCalled()
})
})
Redux may come with a lot of boilerplate, patterns, and libraries, but at its core it’s simple. A current state and an action go in, new state comes out.
Just because the code is simple doesn’t mean it shouldn’t be tested. If you are using Redux in your application, that means your store is a core part of it. For that reason, you should have tests for every action your reducer could take, and every logic branch that they could take. But don’t fret! Since reducers aren’t complicated, neither is writing tests. With a little setup, you can follow this pattern and knock out reducer tests like a pro.
The only setup I use is to use the startState object if I need to have an initials state for every test. Unlike testing thunks, no mock stores necessary. Our initial state (and states we use in testing) will be plain objects. These tests should taste like vanilla.
const startState = {} // initial state shape if needed
I’ll pull the reducer example from an earlier tutorial about creating asynchronous actions. Code reuse, woohoo! 🎉
const postReducer = (state = {}, action) => {
switch (action.type) {
case types.LOAD_POST_REQUEST:
return {
...state,
posts_loading: true,
}
case types.LOAD_POST_SUCCESS:
return {
...state,
posts_loading: false,
posts: action.payload,
}
case types.LOAD_POST_FAILURE:
return {
...state,
posts_loading: false,
posts_error: action.payload,
}
//...other actions
default:
return state
}
}
}
And for quick reference, here are the action creators you can use to work with this reducer. We’ll need them shortly:
const loadPostsRequest = () => ({ type: types.LOAD_POSTS_REQUEST })
const loadPostsSuccess = posts => ({
type: types.LOAD_POSTS_SUCCESS,
payload: posts,
})
const loadPostsFailure = error => ({
type: types.LOAD_POSTS_FAILURE,
payload: error,
error: true,
})
export default {
loadPostsRequest,
loadPostsSuccess,
loadPostsFailure,
}
Every test I write for a reducer follows this pattern:
Here’s the template, in code form:
it('should apply the updates as expected', () => {
const start = { ...startState } // add or change fields as needed.
const expected = {} // expected result state
const action = actions.myActionCreator() //include arguments as needed
const actual = reducer(start, action)
expect(actual).toEqual(expected)
})
Boom. done. To keep things even simpler, if your application doesn’t have an initial state, you can declare start from scratch. As you’ll see below, you will want to tweak the formula for specific cases, but they will all follow this template.
Let’s see it in action. All our first action is responsible for is toggling a boolean value. Notice in this example, I’m not going to create an expected result state. Since we are only interested in one boolean, we can look at that value, and use Jest’s toBeTruthy() and toBeFalsy() matchers. If you’re not familiar with all of the matchers, here’s a quick list for reference.
describe('LOAD_POSTS_REQUEST', () => {
it('marks the current task as not loaded', () => {
const start = {
...startState,
posts_loading: false,
}
const action = actions.loadPostsRequest()
const actual = reducer(start, action).posts_loading
expect(actual).toBeTruthy()
})
})
Here we’ll want to write two tests: one to confirm we load the posts into
describe('LOAD_POSTS_SUCCESS', () => {
let actual
let expected
beforeEach(() => {
const start = {
...startState,
posts: [],
posts_loading: true
}
expected = ['some', 'posts']
const action = actions.loadPostsSuccess(expected)
actual = reducer(start, action)
})
it('marks posts as loaded', () => {
expect(actual.posts_loading).toBeFalsy()
})
it('saves posts in state', () => {
expect(actual.posts).toEqual(expected)
})
})
Similar to our thunk example, our failure use case looks similar to our success case. Still, it’s good to be thorough. Few things are as frustrating as expecting a useful error message and instead finding nothing.
describe('LOAD_POSTS_FAILURE', () => {
let actual
let expected
beforeEach(() => {
const start = {
...startState,
posts_error: null,
posts_loading: true
}
expected = 'Posts not found!'
const action = actions.loadPostsFailure(expected)
actual = reducer(start, action)
})
it('marks posts as loaded', () => {
expect(actual.posts_loading).toBeFalsy()
})
it('saves posts error in state', () => {
expect(actual.posts_error).toEqual(expected)
})
})
If there are errors in how your reducer updates state, it can be difficult to debug. While the Redux DevTools help, wouldn’t it be better if those bugs never even made it to the browser? To help prevent them from escaping, make sure your reducers are thoroughly tested. The pattern can easily adjust to other common reducer use cases:
Still have a particular action that you are having a difficult time with? It could be a sign that you have a messy or overly complex action or state shape, and some refactoring may be in order.
In a previous post, you learned how to make HTTP requests inside your redux application. We use redux-thunk, a library that enables you to dispatch functions in addition to flux-style actions. With it, you can dispatch functions to handle more complex cases such as asynchronous operations. But then how do you test them? Testing can be more work than writing the functioning code itself. Dealing with server responses and timing was hard enough as it is. Luckily, there are tools and patterns you can apply to work, and make your codebase more reliable with ease.
First, we’ll take a look at the tools that we will be using for testing. Then, how to apply them to our operation.
Here’s the thunk from the previous tutorial:
const fetchPosts = () => {
const url = '/our-app/posts.json'
return (dispatch) => {
dispatch(actions.loadPostsRequest())
axios.get(url)
.then((response) => {
dispatch(actions.loadPostsSuccess(response.data))
})
.catch((error) => {
dispatch(actions.loadTaskHistoryFailure(error))
})
}
}
Now, let’s get to work on adding some tests to this code, so that we can make changes to code base without fear of causing a regression.
First, we’ll set up our store. Since our redux application uses the thunk middleware, we’ll also need to apply that middleware when testing. Once we’ve done that we’ll create a function to help us set up our state for tests. Many applications have some kind of an initial state. Instead of creating that for every test, instead, we’ll create a helper function that takes a configured store, and combines the initial state with the state you pass as an argument.
import thunk from 'redux-thunk'
import configureMockStore from 'redux-mock-store'
export const startState = {} //put initial state here
export const mockStore = configureMockStore([thunk])
export const makeMockStore = (state = {}) => {
return mockStore({
...startState,
...state,
})
}
Next, let’s create a couple of helper functions for moxios. Axios & Moxios look at the status code to determine whether or not to resolve or reject the promise. These two functions will save us a bit of time when writing multiple API tests. These helper functions will save you quite a few keystrokes if your application has a lot of different HTTP-based thunks.
const mockSuccess = data => ({ status: 200, response: { data } })
const mockError = error => ({ status: 500, response: error })
For our tests, we’ll need to set up and tear down the Moxios adapter. It intercepts outgoing HTTP requests, allowing you to control the response the function you are testing gets back. Here’s what that looks like:
describe('fetchPosts', () => {
beforeEach(() => moxios.install())
afterEach(() => moxios.uninstall())
})
What do we want to assert here?
You aren’t testing any of the server-side logic. You aren’t testing that state changed because that’s the reducer’s job. You should write separate reducer tests for that. The thunk is only responsible for deciding which actions to dispatch, so that’s what to focus on.
So the jobs our test needs to accomplish are:
Altogether, it looks like this.
it('dispatches loadPostsSuccess with server data on success', () => {
const response = ['some', 'posts']
const store = makeMockStore()
moxios.wait(() => {
const request = moxios.requests.mostRecent()
request.respondWith(mockSuccess(response))
})
const expected = [
actions.loadPostsRequest(),
actions.loadPostsSuccess(response),
]
store.dispatch(fetchPosts()).then(() => {
const actual = store.getActions()
expect(actual).toEqual(expected)
})
})
Don’t just test the happy path. When writing tests it’s prudent to ask yourself, “what could go wrong?” Our server could throw an error response, so we want to test for that use case as well. In our example, the error test case looks almost identical to our success test case.
it('dispatches loadPostsError with server data on success', () => {
const response = 'error message'
const store = makeMockStore()
moxios.wait(() => {
const request = moxios.requests.mostRecent()
request.respondWith(mockError(response))
})
const expected = [
actions.loadPostsRequest(),
actions.loadPostsError(response),
]
store.dispatch(fetchPosts()).then(() => {
const actual = store.getActions()
expect(actual).toEqual(expected)
})
})
This is the purest example of how to test asynchronous operations in your application. Of course in the real world, it’s never quite that simple. If there are additional use cases that you can think of, be sure to write tests for those as well. For example, are there different kinds of successful or error responses you could expect from the server? Do you need additional logic to handle them? If so, it could be a use case for creating additional tests.
Think through your different use cases and decide the best approach.
Async is one of the toughest problems in front-end development. It’s one of the reasons Redux and React were created. React all started when Facebook had what seemed like a trivial problem: Sometimes, the “unread messages” count in the header and the footer of the page would be different. This Skinner box is so important to Facebook’s business model, they decided to build a whole framework around it. By managing all changes in a global state, and rendering components based off of that state exclusively, you eliminate these kinds of problems.
Most Async requests come from talking back and forth with the server. Let’s look at how we can make updates to our Redux state with HTTP requests.
Redux doesn’t come with a way to handle this out of the box. The typical model in Redux is that you call the dispatch function, passing in an action as an argument. The dispatch function gives that action to the reducer, which goes up to update the state. All of these are synchronous actions. What if we want to dispatch asynchronous actions? For that, we’ll be using middleware called “redux-thunk.” redux-thunk gives you the ability to dispatch functions or actions. These functions can then dispatch actions themselves, but more on that later. First, install the middleware:
import { createStore, applyMiddleware } from 'redux'
import thunk from 'redux-thunk'
const initial state = {
posts_loading: false,
posts: [],
posts_error: null,
}
const configureStore = () => createStore(
reducer,
initialState,
applyMiddleware(thunk)),
)
export default configureStore
A thunk is a special kind of action creator that returns a function. The function receives two arguments: dispatch and getState, which unsurprisingly is a function that returns the state. That’s another benefit of using thunk: it allows us to fire dispatches based on the current state, without passing in any arguments. Here are some examples:
const slowDispatch = () => {
return (dispatch, getState) => {
return setTimeout(() =>
dispatch(increment()), 1000)
)
)
}
const maybeDispatch = () => {
return (dispatch, getState) => {
if (getState().allowIncrement) dispatch(increment())
}
}
// If you want to be terser, you can write these as one-liners
const slowDispatch = () => (dispatch) => setTimeout(() => dispatch(increment()),1000)
const maybeDispatch = () => (dispatch, getState) => getState().allowIncrement ? dispatch(increment()) : null
aka good old Redux boilerplate. We’ll be following the
First, there are three actions, one that will tell us when the request started, one for handling success, and one for handling errors. We’ll create types for these. You could just use the strings instead of declaring constants, but this strategy helps you more quickly identify typos when debugging. A mistyped action will throw an error instead of failing silently.
// types.js
const LOAD_POSTS_REQUEST = 'tasks/history/request'
const LOAD_POSTS_SUCCESS = 'tasks/history/success'
const LOAD_POSTS_FAILURE = 'tasks/history/failure'
export default {
LOAD_POSTS_REQUEST,
LOAD_POSTS_SUCCESS,
LOAD_POSTS_FAILURE,
}
Then, we’ll create our action creators. Again, we could do this inside of our thunk, but this helps keep the code clean. You can also use these when writing tests, and they will help you write them more efficiently. We’ll create three: one to update the state when we are loading, one when we get a successful response, and one when we get an error.
import types from './types'
const loadPostsRequest = () => ({ type: types.LOAD_POSTS_REQUEST })
const loadPostsSuccess = posts => ({
type: types.LOAD_POSTS_SUCCESS,
payload: posts,
})
const loadPostsFailure = error => ({
type: types.LOAD_POSTS_FAILURE,
payload: error,
error: true,
})
export default {
loadPostsRequest,
loadPostsSuccess,
loadPostsFailure,
}
Now that we have actions, we need to handle them in our reducer. We’ll store three variables. First, a boolean to track the loading state. We can use this to toggle loading indicators in our interface. We’ll also store the results in an array, and store the error we get in response if there is a problem.
port types from './types'
const postReducer = (state = {}, action) => {
switch (action.type) {
case types.LOAD_POST_REQUEST:
return {
...state,
posts_loading: true,
}
case types.LOAD_POST_SUCCESS:
return {
...state,
posts_loading: false,
posts: action.payload,
}
case types.LOAD_POST_FAILURE:
return {
...state,
posts_loading: false,
posts_error: action.payload,
}
//...other actions
default:
return state
}
}
}
In the ducks pattern, operations are higher-order action creators. Thunks are one category of operation. Another way to think of an operation is an action creator+. It will dispatch actions, sometimes more than one, and sometimes take care of other business logic. Again what makes thunks specific is that return a function instead of an action.
In our operations, we’ll be deploying some combination of the three actions we defined earlier. We’ll be using Axios to make our HTTP request.
const fetchPosts = () => {
const url = '/our-app/posts.json'
return (dispatch) => {
dispatch(actions.loadPostsRequest())
axios.get(url)
.then((response) => {
dispatch(actions.loadPostsSuccess(response.data))
})
.catch((error) => {
dispatch(actions.loadTaskHistoryFailure(error))
})
}
}
And there you have it! Now that you’ve written your thunk, you want to make sure it’s well tested and resilient to change. In the next article, you’ll learn exactly how to test redux thunks.
There are so many different versions of JavaScript floating around, and browser support is always changing. How do you know which features you can use without transpiling or some kind of build step?
Correct Answer: ES6 (a.k.a. ECMAS 2015) is supported in all major browsers.
In April of 2017, all major browsers added support for ES6. Opera added support the following August.
But what about Internet Explorer?
Even Microsoft doesn’t want people using IE. They are pushing hard for people to adopt Edge, which also supports ES6. Only 3% of internet traffic comes from Internet Explorer, and that number is only going to decline. Unless you are in circumstances that warrant it, you can safely ignore Internet Explorer.
So start taking advantage of those new features!
Here are some of the new features you can safely use anywhere, including in the console:
So have fun writing better JavaScript!
“Help! I Landed A Job, And I Have No Idea What I’m Doing!”
Do you feel like you don’t know what you’re doing… like you’re a fraud?
Impostor syndrome is common in our industry.
Wondering when you’ll “just know” something and not be so reliant on Google & Stack Overflow? That day never comes.
Anxiety comes from chasing an ideal that doesn’t exist. Everyone relies on external resources. There is no “10x” developer that just knows the documentation from memory, that doesn’t have to reference.
Every single developer makes mistakes every day. Every developer has moments they have to reference the language docs for a particular function, even if they’ve used it 1,000 times before. (It was probably this one.)
What you know isn’t what’s important. What you get done is. Shift your mindset from “how good am I?” to “what can I get done?” It moves your focus from internal to external. Stop worrying about yourself, start worrying about others
Break the problem down. Solve the smallest part. Get something done. Start writing code before you understand. You don’t have to commit. Work with others, it’s a good reminder that everyone deals with the problem.
Most of your job is novel. You do things you have never done before and solve problems you have never seen for a living.
Everyone Googles. You can Google. I’m giving you permission.
All you have to know is the next actionable step, And go for it. Don’t read and study and noodle around the problem. Take action. Find answers as problems arise.
Have you ever had a disastrous interview experience? My worst: Three years out of college, working in web development, I was struggling with a linked list problem. The interviewer pauses, looks me in the eye, and says:
“…are you sure you studied computer science in college?”
spoiler alert: I didn’t get the job.
Sometimes, it can be a determining factor is whether or not you get a job. That may not feel fair, but that’s how it is. Likewise, being an interviewer is also a skill. Sometimes you’ll run across an interviewer that does something you might not agree with:
If this happens to you, how should you respond?
Whiteboard interview questions have problems, but they exist. If you are interviewing for jobs, chances are you’ll run into one from time to time. Recently, I wrote about how to survive whiteboard interview questions. I was met with several responses of people saying they would walk out of the interview. This thought is gobsmackingly wrong-headed. I’d like to explain why, and what you should do instead. If this is the mindset of the other people applying for these jobs, then shifting your paradigm a bit is a surefire way to get a leg up on the competition.
The good news: If you want a software development job, you don’t have to bury yourself if student loan debt. You can attend a coding boot camp, or take courses online. There are even free options out there like freeCodeCamp. You don’t need a license, only a chance. You can publish work online, from your home, for free.
But, this lack of gatekeeping means there is a burden on employers. How do you know that candidates have the skills they say they do? Resumes can be polished, and portfolios can be faked. That’s why you have to take tests to prove your skills. I’ve been on the other side of the table, and people come through that don’t know how to program at all.
That’s one among many reasons why all these interview practices exist that are both frustrating to experience and absent from other fields.
Earlier I said interviewing was a skill. How do you get better at any skill? You study, you practice, you get feedback, and you repeat. (Amy Hoy has a great in-depth write up on skill mastery)Writing code is great because you can efficiently complete learning cycles at home, 24/7. Write code? Got an error? Experiment or Google the fix. Repeat like your a while loop.
Some sites help you practice interview-style questions, but those will only assist with the technical side. They won’t help with the standing-in-front-your-potential-boss jitters. You could ask friends to help, but they can be kind to a fault, and likely aren’t interviewers themselves. The only way to steel your nerves is to step into the arena & live or die by your actions.
Every interview is an opportunity. Not just for employment, but to learn. You can get practice at the skill of solving real-world problems.
They’re not, but that’s not the point.
It’s solving problems, in unfavorable conditions, for people you don’t know, for reasons you don’t fully understand.
That’s what programming as a professional IS.
It’s not about your “technical skill,” it’s about your resilience. Do you have the creativity, the optimism, and the confidence to tackle problems you aren’t sure how to handle? Because at some point, you’ll need to find those traits in your career.
You won’t. Or at least your interviewers won’t hear it.
Every company gets good and bad candidates. If you walk out, it doesn’t tell the company they follow poor practices. It shows them you couldn’t handle a challenge. Instead of trying your best, you quit. Which perspective do you think people having will help your career?
I’ll concede that if someone was rude, vulgar, racist, sexist, belligerent, or just behaved in a way that was far outside acceptable professional norms, and I probably would excuse myself. But sometimes people seem rude in an instance, or there was something else going on. I wouldn’t write it off. Dealing with jerks, people who appear jerkish, or people who are generally lovely but are having a bad day and are exhibiting jerk-ish behavior in the one particular instance, is another real-world skill that will have to develop soon or later.
Deliberate practice at a skill you want to get better at is never a waste of time. Even if you don’t want to get better at interviewing, it’s a skill that increases your likelihood of getting what you want: A good job, a nice salary, and security as prosperity for you and yours. Isn’t that worth investing another ten or twenty minutes? What were you going to do instead?
Is a waste of your time when a company completes an interview with you and doesn’t hire you? No, it isn’t. Job interviews are like experiments: You expect and budget for failure.
It’s rare that you’ll get an offer for a job that you didn’t want. It’s a problem like getting “too bulky” at the gym on accident. But if you do get an offer for a company that you aren’t keen on working for, you can always turn them down. Tell them you are exploring opportunities and decided to go in a different direction. But not so fast! If you are interviewing with multiple companies (which I hope you are), you can walk into the salary negotiation more confidently. You can tell them you have multiple offers and see if they can offer something more competitive.
That job interview, you almost walked out of, because who needs to know how to traverse binary search trees these days anyway? It could be a bargaining chip that puts another $5,000 in your pocket every year.
Still, think sticking it out would be a waste to time?
Still, want to send them a message?
Still, want to quit?
When I fall out of my writing habit, most often it’s because I can’t decide what to write about. Choosing an article topic can be paralyzing. Here’s an exercise I use to come up with new topics. Afterward, the issue is not that I have too little to write about, but too much.
When coding, you don’t let “not knowing what to code about” stop you, do you?
No, you have a process to turn bug reports and feature requests into code. Having a process for problem-solving, like design thinking, get’s you unstuck and gets you moving forward.(For more on solving coding problem deliberately, check out this post from Justin Fuller: How to understand any programming task.)
Writing can be the same. And it’s important to keep up, It’s been one of the best skills I’ve leveraged to improve my career.
Photo by rawpixel on Unsplash
There’s plenty of places to look for initial topic ideas:
Once you have a topic, run it through the format gauntlet, and voila! Several new starting points for posts. Let’s take “refactoring a react components” because that’s one I pulled out of “recent challenges from work.” Your topics might look something like this:
“My topic doesn’t mesh well with one or more of the formats.”
No worries. Skip it and continue moving forward. You’re going to come up with more potential topics then you could write so don’t sweat it.
Write “X” instead. You don’t have to know the exact count until the end.
“I started writing, and it went off the rails.”
You don’t have to commit to these ideas. Sometimes I end up starting one article and finishing another.
“This topic is too long; I’ll never finish this!”
If something seems daunting, hammer the scope to a more specific topic. Sometimes the result is better. Would you rather read: “How to fix ‘ _reactNavigation.getNavigationActionCreators is not a function‘ error, or “How to debug JavaScript?”
“Writing about technical stuff is boring.”
Articles don’t have to be technical. Plenty of developers also like reading about topics like soft skills and career tips.
“I’m not trying to be a guru here. Why am I acting like I’m the expert?”
Your goal should be above all else, to be helpful. You aren’t writing for yourself; you are creating a small thing that can help someone else in the world. And isn’t that something we all enjoy doing?
“I Don’t know which topic to pick.”
Short answer, whichever one you can write, finish and publish. You can’t help anyone if you don’t ship. The whole goal here is to get over the paralysis of not knowing what to write about. Just take some inventory, sketch out some ideas, and get started! The more you write, the more you’ll find you have to say. Writing is a marathon, and you can switch lanes at any point.
Still don’t want to blog, but want to improve your professional writing? Check out the valuable writing package for templates & resources, available for free.
When working with Redux or other state managers, you want to keep your code pure. That means no side effects. Instead of updating an array instead you want to return a new copy of the array with the changes applied. This is tricky with JavaScript arrays since it isn’t clear which native functions change the array, and which ones return a new copy.
Pop Quiz: array.slice() and array.splice(). How many of them affect the original array?
a) Slice is pure, splice is impure.
b) Slice is impure, splice is pure.
c) Both are pure.
d) Neither are pure.
Highlight to see the result: Slice is a pure function, but splice changes the array. Confusing, right?
To keep your array edits safe, let’s look at some functions that perform pure operations on arrays. Examples are included in both ES2018 and older versions of JavaScript. These examples make heavy use of the spread operator, so if you aren’t familiar with it this may also help you get a stronger understanding of how it works.
//ES 2018
const purePush = (arr, el) => [...arr,el]
//ES5
function purePushClassic(arr, el) {
return arr.concat(el)
}
//ES 2018
const pureUnshift = (arr, el) => [el, ...arr]
//ES5
function pureUnshiftClassic(arr, el) {
return [el].concat(arr)
}
//ES2018
const pureCombine = (arr1, arr2) => [...arr1, ...arr2]
//ES5
function pureCombineClassic(arr1, arr2) {
return arr1.concat(arr2)
}
//ES 2018
const pureShift = (arr) => arr.slice(1)
//ES5
function pureShiftClassic(arr){ return arr.slice(1) }
//ES2018
const purePop = (arr) => arr.slice(0,-1)
//ES5
function purePopClassic(arr) { return arr.slice(0,-1) }
//ES2018
const pureInsert = (arr, el, i) => [...arr.slice(0,i), el, ...arr.slice(i++)]
//ES5
function pureInsertClassic(arr, el, i) {
return arr.slice(0,i)
.concat(el)
.concat(arr.slice(i++))
}
//ES2018
const pureReplace = (arr, el, i) => {
let copy = [...arr]
copy[i] = el
return copy
}
//ES5
function pureReplaceClassic(arr, el, i) {
var copy = arr.slice()
copy[i] = el
return copy
}
//ES2018
const pureDelete = (arr, i) => [...arr.slice(0,i),...arr.slice(i+1)]
//ES5
function pureDeleteClassic(arr, i) {
return arr.slice(0,i).concat(arr.slice(i+1))
}
All you have to is make a copy of the array first. You’ve seen it in the above examples. In ES2018, you can use the spread operator. In old JavaScript, you can use splice. For example, here’s a way to convert the reverse method into a pure operation:
//ES2018 [...arr].reverse() //ES5 arr.slice().reverse()
See the Pen Pure Array Modification Functions by Glenn Stovall (@GSto) on CodePen.
To people who don’t work remotely, it sounds like a dream job. Stay in your pajamas all day; no commute, no distracting open floor plan static. People don’t think about the downsides: The isolation, the loneliness. Left unchecked, extended periods of working from home are a mental health hazard. Isolation leads to depression and anxiety, which can lead to decreased performance, which adds to stress and can become a vicious cycle.
I’ve been there. Trust me, you don’t want to go.
Coworking is one solution, but it isn’t always viable. Sometimes coworking spaces don’t provide a productive environment, or there may not be one in your area. One solution that’s helped me is creating a Coffee Cowork meetup.
Photo by Nicolas J Leclercq on Unsplash
If you stick with this, you will have created a new social outlet and networking resource from scratch! This will give you a way to get outside of your house and outside of your head. And you can do it all for the cost of a cup of a coffee & a generous tip for hogging table space for a long time.
If you’re a frequent user of Netflix or Amazon, then you’re familiar with how they use what they know about you to tailor their platform to your tastes. Personalization is an effective marketing technique. It makes you a more engaged customer, and more likely to get out your wallet.
But you don’t have a team of data scientists or expensive enterprise level marketing tech. How can you apply personalization to your business?
Good news! None of that is required. You don’t even need any JavaScript libraries or frameworks! Here’s an example you can get started with: Changing the page based on query parameters.
We’re going to create a simple landing page, then make some optimizations:
Perfect project for a marketing developer. The more specific your copy is, the more it will resonate with the user. Imagine if the title of this article was “Hey Matt, here’s how to optimize your landing page for your premium icon set!” For all you Matts out there, wasn’t that nice?
See the Pen Dynamic Content From Query Parameters by Glenn Stovall (@GSto) on CodePen.
Fetch the query string (everything after the “?” in the URL.) It’s referenced here:
windows.location.search
Then, parse that string into an object so that you can access specific variables. Here’s a function that handles that:
/* Converts a query string into an object.
* example input: ?src=agency
* results: { src: "agency" }
*/
function parseQuery(str) {
//Remove '?' from beginning.
str = str.substring(1)
//split the string into key value pairs
var pairs = str.split("&amp;amp;")
//convert them into an object
return pairs.reduce(function(map, pair) {
console.log(pair)
var kv = pair.split("=")
var key = kv[0]
var value = kv[1]
map[key] = value
return map
},{})
}
It’s worth noting that every value is a String. If you want to interpret a value as an integer or float, you’ll need to use ParseInt and ParseFloat. For booleans you can use value == ‘true’
Now that we have a usable object, we can start manipulating the page. In these examples, we’ll be using the native document.querySelector and document.querySelectorAll methods. Using native methods keeps your code portable. You can use this code anywhere from a single page application to Google Tag Manager.
Here’s the function that hides our email opt-in. If we already have the visitors email address, we don’t need to keep pestering them.
if(profile.subscriber) {
document.querySelector(".course-opt-in").style.display = "none"
}
Similarly, we can update text. Here’s an example that looks for every instance of a specific class, and changes the text within that element. First, the helper function that makes the updates:
function updatePlurals(text) {
var targets = document.querySelectorAll(".target-plural");
for(var i = 0; i < targets.length; i++) {
targets[i].innerText = text;
}
}
And then a switch statement to call said function.
switch(profile.src) {
case "agency":
updatePlurals("agencies")
break
case "freelancer":
updatePlurals("freelancers")
break
case "startup":
default:
updatePlurals("startups")
break
}
What are some ways you could make your pages resonate with your visitors more? The more resonant your content, the more helpful and persuasive you’ll be to your audience. Here are some ideas for places to start:
I’m writing this using Siri’s dictation feature on my iPhone. This new method of writing first draft has been a game changer for me. It’s more accurate and sophisticated than I was expecting. Once I got used to the cadence(Saying “Period. New line.” and stopping every 30 seconds because due to technical limitations ), it’s starting to feel smooth. Although, I’m a little nervous about saying something like “.“ In real life.
As long as I don’t develop that weird habit, this is going to make me a lot better at talking I feel. Talking on podcasts and online videos always feel awkward to me. It’s odd to speak to an audience that isn’t there. Also, working from home had led to me developing a bit of a mumbling habit. I don’t have many people to talk to except for the dogs, or are currently perplexed by my pacing and rambling into a black rectangle. Speaking of the dictation requires me to be more articulate, and also not talk too fast. Another bad habit. I blame that one coffee.
Writing like this is fast! It takes a bit more editing, but this is the third piece I’ve written today. 40 minutes have passed.
I can write while walking. I spend all day gazing at a screen, desk-bound. “Sitting is the new smoking,” they say. But now I can write while standing or pacing. I’m also drinking more water because doing this a lot dries out the throat. I haven’t tested it outdoors yet; it says Siri requires internet access to work well. I don’t know how well the system will work outside but if it does, will be great to be able to write articles while I’m taking the dogs for a walk or when I have a random idea away from home.
I can feel what I’m writing more. I know it sounds cheesy, when you say something out loud that resonates with you it’s more obvious. It’s been my experience that the more energized I get when writing something, the more it resonates with others.
I get to edit my speech. There are all kinds of speech patterns you have that don’t notice until you have to sit and read them back. It’s like the feeling of listening to a recording of your voice but worse. However, facing these shortcomings is how you fix problems.
Are you need to use it is a decent Internet connection an hour and an app with a text box. I’ve been using Bear, syncing it with my MacBook, copying it in the Hemingway to do everything. Once I clean it up, I can publish it wherever.
If you have an iPhone or similar tool, and you like to write, or even if you hate to write, I recommend giving it a try.
After a second full-time stint, I’ve decided to seek full-time employment opportunities. I’ve had a few people ask me why I’ve made this switch, so here’s my reason why.
First, to clarify: I don’t mean to put freelancing as a profession or those who make that career choice on blast. I have plenty of friends running a business where they are happy, profitable, and thriving. This is me thinking through a decision based on my personal context.
So let’s start with a question:
A salaried senior level engineer can earn a salary of ~$100,000/year. Over 40 hours x 50 weeks, that’s $50/hour. Freelance rates of $75-$150 in some cases are standard. Therefore, the potential earnings are much higher. I know other consultants who say they pull in $250,000 per year. Sounds good to me!
Jobs come with benefits such as paid leave, a 401k, and health insurance. And ugh, is health insurance a big one in the US. The comparison between my plan and my wife (who works a full-time salaried position) is insane. Switching to her plan meant I was able to receive much more coverage at a much lower price.
There’s also the point that other financial institutions, such as banks, don’t think so highly of the self-employed. It’s more challenging to get a mortgage as a freelancer than as a “traditional” employee.
On top of that, for this math to make sense, you’d have to keep a steady pipeline of billable hours. Doing that requires sales and marketing work, so you’re now either working fewer billable hours or more hours than a comparable salary job.
Instead of the equation looking like this:
(effective hourly rate of $50/hour) vs. (effective hourly rate of $100+/hr)
It looks more like this:
EHR of $50 better health insurance 401k paid leave ---------VS----------- EHR of ~$100 worse health coverage responsible for taxes/retirement working more hustling to fill pipeline
And when it comes to filling the pipeline, that brings me to my next point:
Full-time employment is putting all of your eggs in one basket. One person can remove 100% of your income. By working with multiple clients, you can spread out that risk. If you rely on 4 – 10 people for your income, no one of them leaving is completely breaking for you.
But here’s the rub: In my experience, finding this kind of work as a freelance developer has become damn near impossible.
Almost every opportunity I’ve come across was of a full-time nature. Clients wanted 40 billable hours per week, and commitments of months, not weeks. Sometimes as much as 12-18 months! Employee protection rights laws be damned.
Working with multiple clients was more akin to doing 2 – 5 full-time contract gigs per year. You get all the risk of working for a single company, with all the fun of getting zero benefits!
So why bother? There’s one other reason:
Am I though? Building a business is all about leverage. As a service business, there are two ways to go:
I explored the agency route but ran into some issues. A lot of the opportunities I mentioned earlier explicitly wanted individuals, not agencies. Beyond that, I never cracked the code of balancing time & money, either hiring ahead of demand or getting a full enough pipeline to justify the work. Maybe with more time, more money, or more gumption, things would have been different. But 90% of business ideas fail, right? I try not to beat myself up about it.
Then there’s the second one. Creating assets. Running a service business requires designing services, and then marketing, selling, and fulfilling them. To build a product, you’ll also need to design, market, sell, and source that.
Building assets while freelancing is running two business at once. Also, working a job does not infringe on your ability to create products. My ultimate goal financially is to build assets that generate value and are worth something. It’s the only way to build wealth I know of that takes less than 40 years.
I never intended client services to be a permanent solution, but a bridge to something else. But after taking stock, I realize that freelancing is actually in direct conflict with that goal. It looks like my freelancing operation had left me:
So I asked myself: “why am I doing this?”
I couldn’t come up with an answer.
So if you know anyone who is hiring, hit me up.
Most creatives freelance at some point. Either as extra nights-and-weekends work, filling gaps between jobs, or building your own business. I advocate for learning the basics of doing client work. It gives you immutable job security. If you know how to find clients and profitable work, you’re never unemployed. The ability to fend for yourself provides freedom.
At some point, you’ll face the decision: should I freelance or work full-time? It’s a personal decision, and there is no correct choice. The only wrong choice is being indecisive and not moving forward.
First I want to distinguish between freelancing and building a service business. Freelancing could mean taking side gigs here or there and making a quick buck. If you are considering client work as primary income, then you must approach it as building a business, not gig hopping. You’ll need consistent sales and marketing processes, and the ability to manage your cash flow.
Long term, my goal is complete financial independence. I’m aiming to have assets that generate enough cash flow so that no longer have required work. The simplest, most conservative strategy is to have enough investments such that 4% returns pays for everything. In the interim, work is finding the quickest path to that solution.
From that perspective, we have a starting point. “Will freelancing help me reach independence faster than full-time employment?”
But that’s just one factor. If all we did were optimize for retirement, we’d all end up working in finance, fueled by a diet of rice and beans. In the interim, it’s about optimizing both cash flow and lifestyle until you are at a point you are no longer required to work to sustain yourself.
But wait, doesn’t freelancing provide more freedom? After all, that is the origin of the term, Although I prefer the Westerosi version of Sellsword. In some ways, it does.
But it’s complicated.
One of the reason’s people see freelancing as appealing is they see it as working whenever they want as much they want.
Spoilers: it’s not.
Freedom isn’t a lack of structure; it’s the ability to build the structure. You have 50 hours of work to do this week. When are they? You are working with clients and will need to be available to them at some point. You aren’t completely divorced from the 9-to-5 world.
But deciding how many of those hours you work and when is still under your control. You also don’t have to ask anyone for vacation time or over time. If you want to make more, work more. If you need a break, scale back the client work you’re taking on. Which leads to the other part of freelancing freedom:
If you want to make more money at a full-time job, how do you do it? Overtime isn’t an option for a salaried creative, so you’ll have to ask for a raise. You may be able to get a few percentage points, but that doesn’t substiantially move the needle. Usually, the only option is to make a diagonal leap to get a higher paying version of your job at another company.
When freelancing, you set your rates and capacity. Nothing is stopping you from doubling your rate on your next project. You also have more say on how you get paid. You can get paid upfront or net 60. You can bill hourly or with fixed fees. Sometimes changing your pricing strategy is all it can take to increase your revenue by 70%.
But neither of these are the real freedom most freelancers are looking for. What you really want is…
Who you work for is often the biggest factor in job satisfaction. If you work at an agency that takes on cheap toxic clients and then attempts to get profitable with volume, you’re gonna have a bad time. When you’re running the show, you get to decide who you work for and what kind of work you do. If you enjoy working with clients in the music industry, you can build a pipeline focused on them exclusively. Don’t want to write PHP anymore? Don’t have to.
“You’ll never get rich working for someone else.”
This quote holds true in freelancing since you are working on assets owned by other people. But you can make more working for yourself than you can working for a company. I know several freelancers who make between $150k – $250k per year, and they don’t live in Silicon Valley.
If you’re freelancing and your only billing hourly, you’re doing it wrong. With your independence, you should be finding ways to leverage time and money, not just trade time for money. If you charge a flat fee, you can shave hours off of development buy shopping the shelf instead of building something from scratch. You can outsource tasks to virtual assistants or subcontractors. These tasks allow you to skyrocket your effective hourly rate.
Owning a business means owning assets and systems that generate revenue. When your freelancing, you are still responsible for some of the work. In some ways, freelancing is more akin to designing a job for yourself and not building a company. You still learn a lot about marketing, sales, and self-discipline. Being a freelancer means less time working on your craft, but more time sharpening your business acumen.
Contrary to popular belief, employment is the highest risk professional position you can put yourself in.
When you are an employee, it only takes one person deciding that they don’t want you to work at your position anymore and POOF, there goes 100% of your cash flow.
When freelancing, you have a diverse set of clients. In one of them fires you, you should only be losing a small fraction of your income. If you have systems for finding clients, you also have a quicker recovery system.
(Note: much of this part is based on my personal experience and is U.S.-Centric. If you live in a country where health care makes sense, your mileage may vary.)
You can often get better health insurance at a lower rate than you could being self-employed. There are also some tax benefits if your employer offers you a 401k.
Laws and banking systems aren’t set up with the self-employed in mind. Want a fun challenge for yourself? Apply for a mortgage while self-employed.
If my wife weren’t traditionally employed, we likely would not have been able to buy our first home. It’s easier to get good credit when the bank sees that you have ‘stable’ income. The combination of credit score, a W-2, health care, and a tax-preferred investment account means that full-time salaried employment provides you with a lot of life infrastructure.
With great freedom comes great responsibility. Sometimes for 100% of a project. On a tea, people have specialized jobs, and you have a support system.
I knew a freelance developer who was frustrated with all the hours he had to spend hustling. “I wish I could just put on headphones and code all day,” he said.
The, he should get a job.
If you’re a full-time dev, that’s what your boss wants. This means more time focusing on your craft.
People think that freelancing is higher risk, but in reality, it’s higher variance. You may have lean or fat months, busy and slow seasons. Everyone isn’t cut out for variance. Jobs tend to bring more consistency: you work roughly the same number of hours with the same group of people forever and ever. You get roughly the same amount of money every two weeks, which makes budgeting simpler.
https://twitter.com/SICKOFWOLVES/status/905165803221385217
When surgery was invented, the job title “surgeon” came with no modifiers. It didn’t matter what needed to come off or go in, you could see the same person. As medicine advanced, the job splintered. More knowledge meant increased complexity which necessitated specialization. Soon you would see one person for your war wounds and a different surgeon for tuberculosis. This process continued today, where we now have many different specializations.
I’m getting there. I’ve watched a similar splintering happen to designers and developers throughout my career. At my first job at an agency, back in 2008, those were the only two titles in the production department. At today’s software company, you will find a mix of front-end, back-end, DevOps, mobile, native, UX & UI experts. All taking orders from a product manager or project manager, sometimes both.
I’ve seen a new type of position begin to branch off. The marketing developer. Sometimes called a growth engineer.
Today marketing departments of a certain sophistication require a programmer’s skill. You can make progress faster when you don’t have to fight the product team to gain access to it.
Since this idea is new to me, I want to attempt to put a finer point on it.
It’s an interesting field. One I expect to see a lot more of in the coming years.
I want to review a quote from Mike Monteiro’s book, You’re my Favorite Client:
—
So let’s look deeper into the design process, with a giant caveat. Every designer claims their own process… But whether you’re working on an agile or a waterfall process (or smartly between the two), all processes break down to some version of:
—
The section struck me when I read it. I used to eschew “design.” I was a developer. On the development team. Design was for the design team. But in development I always ran into a problem: I felt like a code monkey. I never had a say in the “what” or “why” of the work. I was a pair of hands doing as I was told. It’s frustrating.
That’s when I realized my problem was my aversion to design. I thought I wasn’t a designer. But design is more than what I thought it was. You can design a process. You can design a system. That’s what I wanted to be doing. I was a designer, I just sucked at Photoshop.
My exit strategy was to try to apply my technical expertise to marketing problems. At least in marketing, there is a clear goal and it’s marked with dollar signs.
So, can we apply design thinking to design a marketing system?
First, we have to decide what marketing problem we want to solve. It’s more specific than more money.
We have to know what we’re solving before we try to figure out how to solve it.
I’d like to add my own step (Every designer claims their own process 😉). Once we decided on a problem we must decide how we will measure results. Specifying how you measure results forces you to clarify your thinking on the problem. Then you have more clarity on what a solution looks like.
This is the most fun part of marketing. I feel like the marketing departments get a license to have a bit more fun than others. Sometimes an out of left field idea can create real monetary gain. If you want something more standard, there’s plenty of case studies and resources you can refer to. The challenge of marketing departments isn’t generation, but focus. That takes us to…
By defining metrics early, we’ve built a rubric for a pile of ideas. How will this idea move that particular needle?
Once you’ve done that you can do a cost-benefit analysis.
These questions inform costs, Metrics inform benefit.
Pretty straightforward. write the content and/or code. Do whatever it takes to get the idea out there quickly in front of as many eyeballs as you can.
You don’t always get a chance to watch people use what you built. User testing is not always an option. Instead, we have to use the next best things: analytics, and screen recording pools like HotJar.
Yet another reason the analytics or important: You’ll learn fast. For example, Open rates and click through rates vary wildly by industry. But if you see a variance in one email in your campaign, it could signal that you’re doing something wrong or ride. Adjust as needed.
This is where A/B testing is useful. You can’t test your way to brand new ideas, but you can improve upon a solid 1.0.
A solid 1.0 is the goal here. You won’t know what version 1.1 or 2.0 should look like until your first iteration meets the real world.
Moving fast means faster feedback, which means faster learning. If your idea isn’t working out better to find out sooner rather than later. That way you don’t waste time painting pigs with lipstick.
What I Learned:
I hate that I avoided design for so long. Design is in many ways of what I wanted to do all along, I just didn’t realize it. In my mind, I connected “design” to heavily with “the visual stuff.” Just because you’re not a “designer” doesn’t mean you can’t apply these principles to create better work.
A few weeks back a reader asked: Where should consultants start with marketing automation? I wanted to take a second to answer this.
Here’s the challenge consultants face: working to relationships based business. You want to be efficient without being robotic. How can you put systems in place that make you more effective without turning clients off?
Most of the times, I find it beneficial. It shows you put thought into having systems in place. It makes you look professional. As long as you aren’t being spammy, putting automation systems in place is a pure win.
Here are a couple of projects that you could knock out on a slow day. Something that won’t take a lot of time but will give you a long-term benefit.
#1. Build a post-engagement follow-up campaign.
Set up a campaign to send emails over the weeks and months after a successful engagement. That way you can automate asking the client for referrals, testimonials & case studies. If you want to be more personal, another option is to use a tool that sends reminders to you instead of them. That way, you could write a personalized one-off email instead of a canned response.
#2. Build a course to show off your expertise.
This is something I’m working on right now. I aim to launch the Marketing Automation Crash Course soon. It will provide more lessons about using technical solutions to make your marketing more profitable. You can put together a set of 5 to 10 lessons based on your expertise to educate potential clients. Two options here or to go wide or go specific. You could write a crash course to give an overview of your expertise, or about one specific strategy. For example, I’ve also considered doing a course just on analytics or specific campaigns.
#3. Automate your onboarding process.
Write a brief document you can give clients at the beginning of projects. One that clarifies how you’ll work together. Then, set up a system to email it to them. This could be an email automation tool like Drip, an email template tool like MixMax.
#4. An evergreen newsletter.
Build a system to keep in touch with clients on a regular basis without repeated drudgery. Take some of your best work and set up an automation it sends it to new subscribers weekly. Everyone gets the same welcome experience, sees your best work. And you don’t have to put up new work each week.
If you have any questions, feel free to ask in the comments below, I’d be more than happy to answer them!
There are three terms used for a technical service professional, often interchangeably: contractor, freelancer, and consultant. Let’s put a more specific point on it.
is the closest to employment. As a contractor, you are effectively an employee that doesn’t get benefits or pay payroll taxes. Engagements are often months in length, and 40 hours/week. A typical flavor is subcontracting, where you act as a resource for another agency. Your work is 100% production work. Billing is usually hourly, but sometimes it’s daily or weekly.
involves you taking on more product & project management, in addition to providing a majority of the production work. Length and size of projects can vary greatly, from one-day one-offs to ongoing engagements. Freelancing opens you up to other options for completing projects, such as bringing in a subcontractor of your own or shopping for solutions off the shelf. Freelancing bills for time or fixed-fee basis, and can also be on a monthly retainer.
Consulting…
means you don’t do any production work, only strategic, such as training, workshops, coaching, management of internal resources, or research. Consulting is typically fixed-fee and not based on time. It can also be retainer-based, with a fixed recurring fee.
There’s a hierarchy here. At each level, you start doing less production & more strategic work and open up the potential for higher earnings. At the bottom of the ladder, you have subcontracting where you grind out to-do items in Basecamp for a low hourly rate, where at the top you have consultants who are respected enough to be paid $X0,000 per month just to be available for advice.
In my experience, you’ll probably end up doing all three. My career has primarily been the first two. While the bottom level work is less fulfilling, it is easier to find and often steady. I know many a contract software developer who can grind out five figures per month, and six figures per year with contracting. It’s not “entrepreneurship” in the purest sense, but as the pelican can-open from The Flintsontes says, “It’s a living.”
I’ve talked to people who can open pure consultancies and build client relationships quickly, while others struggle. From what I can tell, the primary factor is trust. The most proof you have that you can deliver results, combined with the personal trust you build with people one-on-one, leads to higher opportunities. Examples of trust signals:
While reading Alan Weiss’s Million Dollar Consulting, there was a passage that I think helps clarify this even further, which you can use to point your efforts towards more efficient, and higher paying means.
Alan Weiss divides work into three categories: strategy, methodology, & delivery. Delivery is the act of producing whatever needs to get done to create the deliverables for a project. A methodology is the practices and procedures used to manage delivery. The strategy is identifying new opportunities for growth. It determines if a project should happen at all and if so, how much we should invest in it.
The strategy drives the methodology. The methodology drives the delivery.
He uses the formula to decide the value of project work: 50% strategy, 30% methodology, and 20% delivery.
This model maps to our earlier definitions:
In theory, if you can shift the kind of work you do up the ladder, you increase your value. How can you change the focus of your work such that you take more ownership of the strategy and methodology? I don’t think this applies just to professional services, but employment as well. I don’t think any boss would be upset with an employee that shared ideas on ways the company could cut costs or increase revenue.
Have ideas on how to shift your focus, or ideas you want to discuss further? let me know in the comments or reach out via email. I’ve been thinking a lot about this for my own business lately and would love to share notes with others.
It’s a common use case: You want to personalize someone’s email by using their first name. You may try to use a liquid snippet like this:
Hey {{ subscriber.first_name | default: "" }},
But there’s a problem. If the first name isn’t set, you end up with this wonky salutation with an awkward space:
Hey ,
There’s a bit of liquid syntax that isn’t well documented, if you add a hyphen to your brackets, Liquid will strip the newlines around the tag:
Hey {{- subscriber.first_name | default: "" -}},
This also works with logic tags which would look like this:
{%- -%}
Want more?
Check out some other Drip Quick Tips. If you get your subscriber’s first & last name as a single text field, here’s a workflow that splits first and last names.
When applying for a development job, especially if it is your first, you may be faced with a horrifying request: Stand up, grab a marker & get ready to code on a whiteboard.
No internet. No IDE. Not even a keyboard. Just you & the awkward silence of the interview room.
Whiteboard interviews are a debated technique. There are two problems; Firstly, they typically involve tackling questions that don’t connect to real-world work. They tend to be algorithmic trivia that many developers haven’t thought about since college. Secondly, you’re used to having access to tools that automate parts of your job like IDEs, as well as information resources like Google and Stack Overflow. If you will have access to these tools on a daily basis, why should you be tested on your skills without them?
The primary function of a whiteboard interview isn’t to judge your technical capabilities. It’s to test your mental fortitude. People complain that whiteboard interviews are unfair & distressing.
That’s the point.
When an interviewer asks you to stand up at a whiteboard, they want to see how you approach problems while under pressure. There are two crucial mistakes you can make here:
The best cure to fear is preparation. Here are some resources to practice whiteboard style challenges.
Getting frustrated is understandable, but it’s worth it to shift your mindset. Working under pressure, talking to people, and being interviewed are all practicable skills. Instead of getting frustrated, try to be grateful for the opportunity. It’s worth it to stick it out, and you should never walk out of a job interview.
Drip, an email and marketing automation tool, recently launched a redesign and repositioning of their service:
The colors aren’t important. What’s important is how Drip changed its self-image. Here’s the important bit from their new manifesto:
At Drip, our focus is on driving consumer sales, not B2B sales teams. We’ll give you the tools Amazon has, but in a way that lets you listen, not track. Understand, not target. Market to, not market at. Energize, not manipulate.
It’s a CRM built by and for ecommerce specifically. We call it ECRM and it’s a whole new way to build better, mutually-beneficial relationships with your customers, at scale.
This is a big shift from how Drip described itself previously. I use Drip, and I’ve used it for e-commerce. However where I have seen in shine before was in a B2B context: Software-as-a-service business, consultants, info-product marketers.
I don’t know the strategy behind the latest shift. I do know that Drip was acquired by Leadpages, and they have some of the brightest people in the digital marketing space. If Clay Collons wants to start the “ECRM”, as well as the “Yahoo Finance of Cryptocurrency“, I’m sure he has sound reasons why.
What’s odd to me, is every time I’ve suggested Drip to a client, I’ve received the same objection.
Drip is opinionated about the formatting emails, more specifically the lack thereof. They don’t have an email ‘builder’ like Drip. They are firm believers that overly-designed emails don’t perform as well as emails that look like someone composed them in GMail.
I’m inclined to agree. In my experience, many business owners do not.
It makes sense. People believe that “people don’t read” on the internet, and that stunning visuals catch people’s attention. This may be the case, but catching people’s attention does not equal building trust or persuading people to make a purchase.
“Sure, that works in the B2B world.” I’ve heard. “But in e-commerce, you need to have fantastic looking emails.
That may be true for some stores, but I don’t think it holds true as often as people think. In every email test I’ve ever run, the simpler email won. Hubspot has done some research on this topic: Plain Text vs. HTML emails, which performs better? Some key takeaways from that article:
So, I feel that unless there is compelling evidence otherwise, this argument against using Drip for your Shopify store.
However, I feel like with the easy workflow tools, Drip warrants consideration. It’ll be interesting to see what new features they launch, and how it compares with other solutions like Klaviyo and Mailchimp.
If you are trying to build a Shopify app in Ruby on Rails, you may run into an issue when you try to include a link to another path in the application. Open up your dev tools and you’ll see a message like this:
Refused to display 'https://96cbc4ff.ngrok.io/sync' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
This is a security feature in Ruby on Rails. By default, the X-Frame-Options header is set to ‘DENY’, which prevents your application from being embedded within in iFrame. Since Shopify embedded apps are contained within an iframe. This causes problems.
Add this to your ApplicationController:
after_action :allow_shopify_iframe private def allow_shopify_iframe response.headers['X-Frame-Options'] = 'ALLOWALL' end
If you are writing a private app, you can replace ALLOWALL with this line:
response.headers['X-Frame-Options'] = 'ALLOW-FORM mystoreurl.myshopify.com'
The first problem any service business needs to solve is deciding who they are going to serve. Being a generalist makes marketing harder. If you’re talking to everyone, you’re talking to no one.
Other consultants Philip Morgan and Jonathan Stark advocate for what they call the fool-proof positioning statement:
I help $TargetCustomer solve $expensiveProblem. Unlike my competitors, I $uniqueDifference.
So when I decided to start building a new agency brand, I decided to start by tackling this problem.
I’ve spent years floating around in startup circles, and there is still the pervasive myth that businesses start with a “big idea.” I can and has worked, but I don’t believe it’s a repeatable form of success.
Instead, I believe in finding the perfect group. Marketing buzzword types call this “community marketing” Once you have a group of people you want to build a solution for, you can ask them questions, you can research their problems.
You don’t have to come up with a big idea from scratch. You can let the market point you in the right direction.
One problem with choosing a target market is that there are so many options available. If you don’t feel the same, you’re just not looking at it hard enough. Look up. Look sideways. Look down.
To put in another way:
Answering these questions (which I’ve taken from Amy Hoy & Alix Hillman’s 30×500 course) lead to a litany of options:
The word decision means “to cut.” Choosing to focus on one of these markets ignoring the other nine. It makes the decision difficult. This analysis paralysis can lead to the Buridan’s ass problem: A donkey standing between two equally appetizing piles of hay chooses neither and starves to death.
The reason decisions can be hard is because of the cutting. Choosing one of these audiences means that I’m also choosing not to work with any of the others. It’s scary. I firmly believe that positioning increases marketing opportunities, but to our lizard brains, it feels like the opposite. How can I overcome this fear?
Not moving is death in this case. I needed to pick one market. Without choosing a market, talking to people in that market, doing research, and crafting targeting marketing messages is impossible. If that’s not enough, there were a few other realizations I came to that helped me get over the fear.
If I choose a market, do some research, and can’t make any sales, then I can always change. The internet has a short-term memory. Remember when I used to try to make money doing Warrior Forum affiliate marketing bullshit? Yeah, me neither.
What if an excellent opportunity comes along that doesn’t fit my ideal customer?
I’m going to work with them anyway.
I have pride, but I also have a mortgage.
Positioning is a marketing play. It is focusing effort in a single direction. Just because I am trying to land Shopify owners as clients doesn’t mean I will turn a SaaS client away if I need to make some additional income that month.
Now it’s time to make a decision. Which means it’s time to cut some of our potential audiences reality show style.
To get this business off the ground, I need people who typically hire outside help.
These are all great markets to serve with products, but I think building a service business around them would be difficult.
While I’ve working in marketing departments, I’m a developer at heart. I’m looking for companies that I help with code skill, even if I am not selling myself as a programmer. In my experience, SaaS companies look to hire full-time for these kinds of roles. Amazon sellers don’t own their platform, so there isn’t much need for custom development.
I’ve built several MVPs for startups, but there are a couple of issues with this market: They tend to operate on a shoestring budget, and 90% of them fail so it doesn’t make for a repeatable client base.
Of the four, I settled on eCommerce stores. I’ve always been interested in ways code can be leveraged to directly impact the bottom line, so an industry with the sole focus of selling things seems like fun.
Time to dive in!
Looking around at the eCommerce space, Shopify in particular seemed attractive for a number of reasons:
So there you have it, now I can say that:
I help Shopify Store Owners solve $expensiveProblem. Unlike my competitors, I $uniqueDifference.
And I can start researching to determine an expensive problem to solve, and a unique difference I can use in my marketing.
Are requests for proposals a trap?
It’s debatable. Some agencies and consulting make a lot of cash from some large clients. Others spend hours writing proposals and don’t make any progress. If you want to try your hand at winning RFPs, here are some sites you can check out:
Many sales conversations go nowhere. It’s frustrating and like it’s a waste of time. How often do you start a conversation with a potential client, only to have them ghost you after two emails? Having a process to follow up and start new discussions helps alleviate this problem. I use Pipedrive to keep track of this, and here’s exactly how:
Most consultants don’t follow-up. Most don’t have a process at all. Getting something, anything in place puts you ahead of 80% of the competition. This is the process that works for me. Your mileage may vary. If you aren’t sure where to get started, I hope this gives you some ideas.
The standard pipeline has seven stages:
Once a project is complete and handed off, I add people to the Happy Client pipeline. This ensures that I can stay in touch with clients, and make sure the work I do for them continues to provide value months down the line.
This pipeline is for regular outreach. I try to stay in touch with people at least once per quarter. This one isn’t a “pipeline,” it’s more of a hack.
Every morning, I get up, I pour a cup of coffee and work through the pipeline. One of Pipedrive‘s best features is that every time you complete a task, you are prompted to enter the next task. Sales are never allowed to linger. You either move towards a ‘yes’ or a ‘no.’ This helps ensure I always have new business advancing in my pipeline.
Looking for ways to spend less time doing parts of your job that you hate? You have three options:
I’m a minimalist. I like to take a Marie Kondo approach in business and life. Tasks get on out plate more quickly than they get off, and we don’t always stop to reflect and ask: “Does this work provide value? should we do it at all?”
Let’s assume for this article that the task has passed the sniff test. You can’t eliminate it. Then move on to the next two options: If a computer can do it automate, else we delegate the task to someone else.
There’s an important step before you can productively do either: document your process. Documenting your processes is something that you should be doing at any stage of your business, for a company of any size. I was documenting new processes on day 1 of my one-man shop.
Everyone has systems in their heads, whether they realize it or not. Do you have a morning routine? A strategy for handling your inbox? These are almost a process. However, I’m a firm believer that:
Ideas in your head are fuzzy and abstract. Getting a system out of your head and out into the real world has several benefits:
Many people get hung up here. Don’t. It can be anything that lays out how the job gets done. Some common examples:
You don’t have to pick one, choose the one that makes the most sense for the process at hand. Don’t try to force too much uniformity or rigidity. It also doesn’t have to be just one of these; it can be a mix.
Recently I had to consider the following facts:
So the conclusion was obvious. I shouldn’t be doing outreach; I should be building the outreach system. So I decided to tackle the problem in that way. The process is broken down into three parts.
By creating a process, I turned outreach into something fun instead of being a chore. Now I’m not just sending emails; I’m testing and iterating on parts of the process. I was able to shrink down the amount of time I spend doing the outreach so that I can spend more time doing work I enjoy.
Try documenting one of your systems today. It shouldn’t take you more than 20 minutes. Pop open a Google Doc, and write down the steps or create a template for just one task. See how much easier that task feels the next time you go to tackle it. How much more confidence you have. See how many minutes you save. Once you get over the hump and get started working on processes and see the benefits, it’s almost addicting.
There’s a weird gap in Drip’s functionality: You can’t trigger a workflow or automation rule for all new subscribers. You can trigger rules based on “Submitted a form,” but that doesn’t work for users that are created via import or API. Here’s how you can work around that:
Drip Doesn’t Have A Trigger, But Zapier Does
Zapier has the “new subscriber trigger” that Drip is missing.
You can use Drip to trigger Zapier to trigger Drip. Weird I know. For part two fo the zap, you can either add a tag to a subscriber or trigger an event. From there you can use Drip’s regular rules and workflows for all new subscribers.
Sometimes, applications have a limit on how many records you can import at once. Sometimes massive imports flag for a manual check, adding a roadblock to your work. Want to split one CSV into many quickly and avoid those pesky upload limits?
Here’s a short bash script I use to split .csv files into multiple files while maintaining the header rows:
#!/bin/bash
TARGET=$1
if [ ! -z $! ]; then
echo "Filename is required"
exit 1
fi
COUNT=${2:-999}
OUTPUT=$TARGET.split
mkdir $OUTPUT
tail -n +2 $TARGET | split -l $COUNT - split_
for file in split_*
do
head -n 1 $TARGET > tmp_file
cat $file >> tmp_file
mv -f tmp_file $OUTPUT/$file.csv
rm $file
done
echo "all done!"
Copy this into a file and run it from the terminal. I call it ‘niner’ on my machine. The first argument is the path to a CSV file. The second argument is how many rows you want in each segment. The default is 999, because scooting under a 1,000 row limit is why I wrote this in the first place 😉
By showing different variations of a product or feature to segments of your audience, you can quickly learn what works and what doesn’t. There’s a reason that every major tech company such as Google, Apple, Uber, etc. Use split testing as a part of their design and research process. Done correctly, you can learn about your customers rapidly and increase revenue. When done wrong, split testing can become an expensive waste of time.
Here’s what happens a lot when someone reads an article on ConversionXL and decide to start split testing:
When you test this way, you’re missing out on a majority of the value split testing provides. You need to approach split testing with the right mindset to get good results.
The variant on the left with additional parmesan converting 300% better.
The more you understand your customers, the better you can serve them. To learn the most you can, you need to approach testing with a scientific mindset. Instead of saying “Let’s try something,” or “Let’s pit Tom’s idea against Sarah’s and see who wins,” Start with a hypothesis. Say “If we make this change, I think this effect will happen because of this reason.” When you approach testing this way, every test will be a win regardless of income:
Before you run a test, ask yourself these questions:
Since we are testing, any reasonable hypothesis warrants consideration. If there is a justification, go for it. If you have a reason puppy GIFs would increase conversions with your audience, go for it. Ideas should come from anywhere in the company, not just the design team, marketing team, management. Employees working closer to customers and the product will often have insight other departments don’t. When coming up with test ideas, use data and research to back up your points, but keep an open mind.
Don’t take test results personally. Don’t use the phrase “my test” or “my idea.” Talk about your test in the third person. You’re a scientist, remember? Treat your thoughts with a healthy, cold, logical distance. You’ll need to because…
Most of the time, split tests lose more than they win. You’ll have ideas that you think are surefire winners that will bomb horribly. Think of it like baseball. The best hitter in the 2016 season missed 65.2% of his at-bats. Losses are temporary. Wins are evergreen.
Often the biggest challenge isn’t what to test or how to test, but getting buy-in that testing is the way to go. Split testing can be uncomfortable for some organizations; you want to help alleviate that awkwardness by highlighting the benefits. Even though you aren’t taking things personally, it’s still nice to let yourself have a moment to enjoy when a test goes well.
The more people that benefit from your testing, the better, When you get results, win or lose, share them with the rest of your team. Marketing, support, design, and management can all benefit from the data you can gather via testing. Keep sharing an open and company-wide process.
If you get your subscriber’s name as one field instead of two, it can make for some awkward salutations. “Hey John Smith!”
Here’s a simple workflow that will take full name fields and split them into first and last name fields for you.
Want to copy this workflow directly into your Drip account? Get the workflow below:
Email marketing is so much more than a “weekly newsletter” these days, and with powerful tools available at lower price points, a lot more companies can take advantage of these.
My go-to tool is Drip. It has a great balance of affordability, simplicity, and power. There’s a lot of businesses out there that could gain a lot of value from Drip, but it’s hard to see exactly how it would benefit them.
Here are the core features of Drip, and how they can be used to build evergreen revenue generating systems into your marketing websites, eCommerce platforms, and SaaS applications.
Drip has the standard functionality of simple email marketing systems of yore: You can create opt-in forms, and people can opt-in to your mailing lists. Once they are there, you can send broadcast emails to them periodically.
Instead of getting a one-time burst of revenue, you can set up launches that run again and again.
Send onboarding messages that educate and empower your user, thus increasing conversions.
Richard Felix of Stunning has some fantastic Dunning email templates you can use.
Groove uses this simple technique to increase Customer exit survey responses by 785%.
Use these email courses to provide value to your users, attract subscribers, and eventually pitch them on your products or services.
Everyone is different, why are you marketing to them the same? Tailor your calls-to-action based on what you know about the user.
Instead of pitching all of your products to everyone at once, only pitch certain products to people when it’s relevant.
Use customer data to personalize your marketing page or application.
Get business intelligence on which segments of your audience are the most profitable.
Run automated webinar and event sequences.
Increase the efficiency and accuracy of your high-touch sales by integrating with your CRM and sharing data.
Recover lost sales with cart abandonment campaigns.
Providing access to your Google Analytics account can allow consultants to gain insight and help you find better ways to collect data and make smarter decisions within your business.
Log in with your Google account. Do not share your Google account username and password with anyone for any reason. EVER.
Look towards the bottom left of your Google Analytics dashboard. as of this writing, that’s where you will find the admin panel.
Within the admin panel, under the middle column (property) click ‘user management.
At the bottom of the page, there is a form titled “add permissions for.” If your consultant is just doing an investigation. type their email address and give them “read & analyze” access. If you hired them to set up better tracking, give them ‘edit, read & analyze’ access.
Is your marketing department allergic to project management? Here’s a strategy that might help you reign in the chaos a little bit: Morphing my vague marketing tasks into discrete, measurable projects: I call them growth initiatives. Others call them experiments, which I don’t use here because when I say that people tend to think “A/B testing”. These are more encompassing.
An initiative has four essential components: What you do, how you’ll measure it, when to measure, and what you expect to see when you measure.
What kind of work is involved in a growth-based initiative? Anything aimed at moving the needles on important numbers. Some examples:
Decide what it is specifically you are going to do. The more specific the better. “Improve pricing page” is not a valid project. “Split testing headlines on the pricing page” is. The work should come with a hypothesis. Why do you think your new headline is better?
Decide what numbers you are going to watch and how you’ll get them. Tracking the effectiveness of an SEO initiative could be done by looking for an increase in organic search traffic in Google Analytics. Conversion rates could be tracked in Baremetrics or inside of your optimization tool. There’s no one true analytic solution. Use whatever is best for the project, even if involves slicing and dicing data in Excel.
How much do the numbers from step two need to move to make you happy? If you aren’t sure, make a wild ass guess. 10% for numbers you are satisfied with and 100% for numbers you aren’t is a fine starting point. Don’t fret too much about specifics.
Sometimes the data that comes in will come in a few days, other times it can take months. Make a note a specific date and follow-up to check your results.
You’re read that shorter subject lines get better open rates than longer ones. Shorter = more curiosity, so that makes enough sense to test.
Scoping the work: If you have a large enough email list (I’d say 2,500 – 10,000, depending on engagement), so all you need to do is send an email to the list with two different subject lines.
Decide how to measure: Your email service provider should tell you the open rate.
Estimate impact: I haven’t seen open rates across emails vary much on the same list, so I would start with a conservative 10% bump. 10% as it moving an open rate from 30% –> 33%, not 30% –> 40%.
Set the timeline: People don’t always check email daily, so I tend to give emails 72 hours before looking at numbers.
So, now we’ve formed our initiative. We’ll send an email with two different subject lines, and observe the open rate.
Think of some marketing or project ideas you’ve had banging around in your head. Can you work them into this framework? Give it a try on your next project and see how you like it. If you’ve been feeling stuck or confused, then taking this approach can help give your growth strategy clarity and direction.
Marketing and Growth are two terms have different meanings depending on company culture and context. Here’s how I think about the difference:
Marketing is the discipline of increasing the number of eyeballs on you. Marketing is focused on lead generation; building email lists, getting people to sign up for free trials, and general brand awareness.
Growth focuses on increasing revenue. Growth is any activity that directly aims to move a key performance indicator up and to the right. It needs to be deliberate and measurable. Most of the time that KPI should be tie directly to revenue. Every business, product, and audience are different. Therefore careful experimentation is what drives growth.
At most companies, Growth sits somewhere between product and marketing. Think about this user funnel:
That’s a pretty typical funnel for a SaaS company. Let’s think about how ownership of each part of the funnel would break down.
There are many different ways to use these terms, but broadly I would define marketing more as “driving people into the funnel,” product as “the end of the funnel” and growth as “the funnel.” I thought about this because I used to work in product, moved over to marketing, and now realizing, maybe what I should be aiming for is growth.
Let’s say you want to keep count of how many times a user performs a certain action in Drip, how can you do that?
Drip doesn’t support this feature natively, but it’s easy to implement. Here’s an example using a rule that counts the number of times a user completed a particular event:
Check out the value tag:
{{ products_created | default: 0 | plus:1 }}
We’re using the Liquid tags with filters in this example. Let’s break it down.
First, you set a variable:
{{ products_created }}
Of course, saying products_created = products_created isn’t very useful, so we want to use a filter to change the data that is output. In this case, we want to say:
products_created = products_created + 1
Which in liquid looks like this:
{{ products_created | plus: 1 }}
This would be fine if we always knew that products_created would be set. We can make this tag more robust by adding an additional filter to set a default to ‘0’ for those cases.
{{ products_created | default: 0 | plus: 1 }}
Using this snippet, you can increment fields in drip.
Software built for business should be useful to the consumer and valuable to the company that produces it. To optimize software towards these ends, you need a way to track results.
No analytics tool does this out of the box. You can install Google Analytics and see how many monthly visits you get without any additional work, but if you want actionable data, you need to lay some groundwork.
How difficult this task? It depends on the way the app or website is built in the first place. Understanding the need for analytics allows you to make a few small changes to your workflow, without affecting the user experience of your customer.
Optimizing Amazon listings requires hours of tedious research and calculations to find the best keywords. To solve this problem, Seller Labs was looking to launch Scope: it’s innovative market research and keyword optimization tool. They saw an opportunity to help sellers do a better job at optimizing their listings.
The market for Amazon Seller tools is cutthroat, so they knew it wouldn’t be easy. However, previous successes launching messaging software and deal sites proved it was possible.
I worked with Seller Labs to develop the initial version of the Scope Chrome Extension. The extension enables sellers to collect valuable data while browsing Amazon.com. Clicking ‘Export CSV’ replaced tedious hours copying into a spreadsheet. The extension had two modes of operation: free, which focused on automating the collection of data, and paid, which augmented keyword profitability data generated by Seller Labs’ proprietary algorithms.
The Scope free extension has generated over 10,000 leads. Combined with calls to action and marketing automation built to convert these uses, The Scope extension has become one of the most profitable marketing assets in the Seller Labs repertoire. If you’d like to try it out for yourself, here’s a link: Simplify keyword research with Scope.
Dear future client,
A lot of freelancers are happy to charge you an hourly rate & bill you based on the amount of time worked.
I’m not one of them.
I firmly believe that if I bill you by the hour, then our project has a much higher chance of failure.
Firstly, it immediately puts our incentives at odds. The way I would make more money is to take more time to get work done. I get rewarded, and you get punished for my inefficient work. You may think ” If you’re a trustworthy developer, you won’t do that.” And you’d be right. However, that means that the right thing and the most profitable thing are different. That’s a fundamentally broken system. I’m in the client services business. I should make the most money when I best serve my clients, not the other way around.
Another way I can provide better service is to spend more energy on solving your business problems instead of dealing with red tape. I don’t want our phone conversations or meetings to have a taxi meter dangling overhead. I don’t want to fret about whether or not sending an emails “counts” as billable time. How about instead, I just do what needs to be done, no matter how long it takes. And as a bonus, you’ll always know the exact amount you are expected to pay. Your accountant will appreciate it.
Lastly, it reduces potential solutions. Let’s say I find an off-the-shelf solution for your problem. I could buy it for $100 or build something similar for $1,000 in billable time. All other factors equal, you’d rather have the cheaper, faster option, wouldn’t you? Good, because I’d like to give it to you. However, billing based on time means I can’t do so without taking money away from myself, my business, and my family.
We’ll agree to prices based on your needs & the value I can provide. In cases where the scope and value are more clearly defined, this can be a payment of one or more fixed fees. For projects that require more exploration, this can be recurring fixed fees on a weekly or monthly basis. This model provides a balance of flexibility for both of us.
Then we can be in alignment: the only thing that will matter about the project is achieving success.
That being said, there are always exceptions to the rule. If you feel there is a strong case for working hourly than I’ll consider it.
However, if you insist on hourly billing because you are focused on effort not results, I’ll be more than happy to refer you to someone more focused on delivering code instead of business results.
Cheers,
Glenn
These are a list of books that I recommend often, but always have to follow with “I know what it sounds like, but…”
What it sounds like: yet another “lifestyle blogger” teaching you how to be lazy and still profit.
What’s actually in the book: The original lifestyle blogger shows you how to focus on optimization and automation first, and the principal business lesson of decoupling your time from your money. The title is famously born from split testing to come up with the most clickbaity title possible.
What it sounds like: A huckster is about to explain how all the other get rich quick schemes out there are bullshit, but he’s about to teach you how to get rich for real… and quick!
What’s in the book: A practical guide on personal finance for twentysomethings. It speaks to a seminal moment: when you are fresh out of college, getting their first salaries and taste of real money. They’re thinking about marriage, mortgages, or multiplying fruitfully one day down the road. How should you set yourself up for success financially?
This book doesn’t teach you to be rich, but it sure shows you how not to be poor.
What it sounds like: See above.
What’s it the book: I will Teach You to be Rich would have more fitting here. While it runs you over with Lamborghini metaphors, the message is simple: no one ever got rich working for themselves and stocking away money in a 401k. (called “The millionaire slow lane” in DeMarco’s parlance). Instead, this book shows the way to wealth is the acquiring cash generating assets. A must-read book for any entrepreneur.
What it sounds like: The asshole’s guide to negotiating.
What’s in the book: The decent human’s guide to negotiating with assholes. This one wins for the most misleading title; it is the exact opposite of the contents. Robert, who characterizes himself as a meek turtle throughout the book, discusses how he made sure people didn’t take advantage of him in business deals through rigorous preparation.
What it sounds like: Unlock the secrets of the formulaic 18-minute pseudointellectual spiel so you can go out and “change the world.”
What’s in the book: Ok, it is precisely that. Still, it’s one of the better books on public speaking that I’ve read. If you have better suggestions, I’m all ears.
What it sounds like: More Secret-flavored spirituality. Who needs hard work and discipline when you can succeed with feelings?
What’s in the book: A corny but insightful book from the 1950s about how self-image affects our performance is almost everything. Behind the antiquated prose is a ton of specific, tactical advice to help you improve your mindset. No mysticism here. As an example, imagine two freelancers who start the year with two different goals: the first aims to make $50,000 in revenue that year. The second aims to make $150,000. What would they do differently? Which one would you rather be?
Asking “how much will a website cost?” is like asking “how long is a rope?” or “how much is a house?”. But the client might not know that. They’ll want a quote in the first 5 minutes of talking to you.
How do you respond to these requests?
Definitely not with a price. Setting a price before fully understanding the requirements puts you at risk of underbidding, and potentially working a ton of cheap hours.
You can try to ask follow up questions to suss out the client’s budget. But what about when those don’t work? By the end of reading this article, you’ll have a set of tools you can use to move forward from these situations without binding your self to a price or work order that’s worth your time to fulfill.
Why are they pushing for a price at the beginning of the conversation? There are a few different possibilities:
Asking for budget numbers outright can be a turn off for some clients. They are concerned that if they say $10,000, you’ll say “here’s a $9,900” proposal. You’ll have to get there by more indirect means.
You’ll have to use your intuition to judge your potential next client’s situation of awareness. For this reason, I encourage getting the fidelity of communication as high as possible as early as possible. If you’ve only been speaking via email, pick up the phone or get the client on Skype. Meeting in person is preferable when possible. It will help you decide which tactic to use.
Explain that you need to know more before you can fully answer their question. If you use this line, have a next step ready to go. Here are some ideas, in ascending order of difficulty to pull off:
This way, you can try to steer towards a continued conversation. From there, you can learn more about the project and come up with a fair price.
I’m gobsmacked by the number of times I’ve asked the question, and a client blurts out their budget. “We have a budget of $15,000.”
This question can help you filter out clients with unreasonable expectations. You can’t accurately price a project based on a 3-sentence description, but you can at least tell a $500 project from a $50k project.
If your client thinks that a complete eCommerce solution costs the same a nice dinner and a bottle of wine, then you know that you don’t want to work with them, and can go ahead and end the conversation.
You show them a bit of the dark art of how you price your services, and in exchange, you have both educated them about market rates and give them perspective on where they may fall. Like the previous question, you have a similar effect of pushing for alignment: If what you offer at a particular price is wildly different than what the client expects, you can end the call.
The worst thing you can do is blurt out a way-too-low price because you didn’t understand the scope of what is being asked of you. Try the techniques above, and learn more about the project and the client before you make any commitments. And if you want to improve dramatically at the art and science of pitching & pricing software projects, I’d recommend Dependable.
tl,dr: no, you shouldn’t.
The United States Senate is on the brink of making a huge mistake. And it’s the same mistake that sinks software companies every day.
They want to rebuild a project from scratch.
It happens at software companies all the time, typically with new teams. They see a project full of legacy code that confuses and frightens them, and they decide they want to build a new codebase from the ground up.
(Dilbert 2014-08-12)
Ripping out an existing, working system is always a costly mistake. Even if…
But don’t take my word for it. Take it from Stack Overflow co-founder Joel Spolsky in this essay about things you should never do.
Next time your company is thinking about repealing and replacing an existing project stop. You’re opening yourself up to once again face reasons projects fail #1, #4, #7, and #10.
Look for ways you can improve the existing project without starting over.
Clients buy based not on what you can potentially do, but what you have already done. A portfolio showcases previous accomplishments, but if you’ve been doing work for a company, you may have an NDA or non-compete clause in your contract preventing you from showing off your work. Having a portfolio reduces the risk of hiring you for your client, but how can you put one together if you don’t have projects you can display?
Check your contract and talk to your employer before putting any work you did on their time in your portfolio. Sometimes it’s a no-go, other times your boss will let you include your work as long as you don’t claim sole credit and provide a link back to them.
Build something fun, that’s just for you. In addition to being a way to start building your portfolio, it can potentially be an asset to your business later. It doesn’t have to be large. A weekend hackathon project you shipped is better than a large scale dream project sitting on your hard drive.
Dribbble is a popular site among designers. They can share small samples and of their work. These brief glimpses are smaller and easier to finish than an entire project, and they don’t have to be part of a complete project. If you have an idea for a contact page design, then make just that. It can work as an example of what you can do.
When you haven’t done paying work yet, you can fake it until you make it. You don’t build trust by lying, so when you do design studies like these, label them as such.
If you are a developer, clients will often ask you for a link to your Github profile. You can fill this by finding open source projects where you can contribute.
When I first started freelancing, I always said I wouldn’t work for free. The fields of programming, design, and copywriting are young and ethereal. People don’t understand the work, can’t touch it, and don’t always know what it’s worth. I usually wouldn’t advocate for free work because when you work for free, you don’t only devalue your work, but the work of your peers.
There are times when free work can be beneficial to your business, but these are dwarfed by the number of times it’s a bad idea. If you are ever unsure, the answer is “No.”
It is never okay to work for free on other’s people’s terms. It is ok to work for free, every once in a while, on your terms.
Here is my go-to script when offering to do something free for someone:
“Hi, I’m getting started in offering $SERVICES. I’ve looked at your business and thought I could help. I’d like to provide $DEFINED-DELIVERABLE for no cost. All I ask is a testimonial and referrals if you are happy and honest, constructive criticism if you are not.
I’ll work for free, but I won’t work for nothing.
Let’s take a look at some of the key points of this script.
Non-profits are a sticky situation. I have a no non-profits rule, but that is mostly because working with them is a chore. Non-profits have fewer incentives for efficiency and greater incentives for making people feel good about themselves. It all adds up to a lot of decisions by committee.
Many people also think that “non-profit” equates to “non-money” which is not the case. Non-profits are businesses just like any store, manufacturer, or service provider. The difference is that they give excess money to the benefit of others (if they are honest). This also means they have the same budgets for web design, marketing, and outreach as they do for office supplies.
I’ll admit I felt a little seedy the first time I put a non-profit on a $1,000/month retainer, but helping them raise $15,000 in donations they wouldn’t have otherwise in 4 months assuaged my guilt a little bit. (I eventually fired this client because I got sick of every decision requiring a half-dozen sign-offs before getting completed. It could have been $25,000).
If you work for a non-profit, they should pay like a regular client, and you should treat them with the professionalism that warrants.
There is an exception to this rule if you believe in the cause and want to do it for your benefit. Just don’t try to spin your labor as a tax write-off, it’s more headache than it’s worth and won’t save or make you money.
If you work for free because you believe in the cause, the above rule about defined scope still applies: The project needs to be finite, and defined by you. Asking for referrals doesn’t hurt.
Mixing business with friends and family is a murky swamp filled with relationship-ending gators. If you do, the same rules still apply: pre-defined scope & a request for referrals, testimonials, and feedback.
One exception here is your mom. She gave birth to you, just make her a website on Squarespace already.
The most popular thing I’ve published online to date is an essay titled How I Used Writing To Double My Freelancing Rate as a Programmer. In it I talk about the value, you add to your business and your clients by being able to write professionally. Instead of retreading that ground, I want to focus on two ways writing, and publishing can help you bootstrap your freelance business: Writing can help you display knowledge, or it can help you gain experience.
I wrote an article called “AngularJS: An Overview.” I wrote this after working on my first AngularJS project for about a month. I went over the basics and created a “for dummies” guide to getting started. I didn’t intend to publish that article, but it got some traction, and even though it is a “just the basics” article, it got me the attention of some potential clients.
Writing about solving problems you have encountered in the past. It has led to some dry articles like “How to test controllers in Rails 4”, or “How to write a command line tool in CodeIgniter.” But such items have generated traffic. They are also an excellent way to “upcycle” your work. I figured out how to set up command line tools in CodeIgniter because a project necessitated it. I could have completed that work and helped one person. But by writing about it, I helped 1,000.
If a client ever asks about something like that, I can point them to that article. It is every bit as valuable and in some cases more than a portfolio piece.
Portfolios are about proving you can get the job done. Writing about the tools and techniques you use is another way you can do that.
Programmers, like kittens, are easily distracted by shiny things. The reason there are so many languages, tools, and frameworks is because of the combined force of the fun of creating something new and the disdain of technology once you are comfortable with it.
At one point my shiny thing was NodeJS: A way to use the knowledge I had of JavaScript on the back-end as well as the front-end. I had about reading two blog articles worth of knowledge about it, but that was enough to wet my appetite.
I was sitting in a local developer’s meetup where once a month, two people would give a talk on a tool, language, or technique they found interesting. Afterward, they were asking for volunteers to give a presentation the next month.
I volunteered to give a talk on NodeJS.
It may seem crazy to volunteer to give a talk on something you know nothing about, but it isn’t. What did I do?
The act of writing was a learning experience for both my audience and myself.
You don’t have to be an expert in a subject to write about it. In fact, quite the opposite. Writing is refined thinking. It makes your spastic monkey mind slow down, and put your thoughts in a straight line. When there are gaps, you read, and you fill them. Writing is a learning experience as much as it is a teaching experience.
If there is a skill or market you are interested in, start writing about it.
AB InBev is buying up craft breweries with increasing velocity, and not for the reasons you think. Chris Herron, an owner of Athens brewery Creature Comforts, explores the motivations behind these buyouts. As a current brewmaster and former Miller employee, Chris provides in-depth business insights into the world of big beer.
“How vain it is to sit down to write when you have not stood up to live!” Working in the tech industry means hours at your screens. If we aren’t, we may feel like we aren’t productive. This article flips that line of thinking on its head and should you need it, motivation to get off your ass once in a while.
Is it just me, or does the term “Jobs to be done” get thrown around a lot these days? This brief article is the first one where JTBD “clicked” for me. It comes was recommended by a project manager colleague, and based on his design direction, I feel like there must be something to this theory.
Want to sound more knowledgeable when you’re out for dinner? This article serves as a needle that breaks the snobbish membrane of wine tasting and teaches the fundamentals in an easy-to-digest manner.
This title makes zero sense out of context, doesn’t it? Amy Hoy, founder of 30×500, marketing her products on her site: Unicorn free. Amy is an advocate of bootstrapped businesses that solve real business problems, as opposed to funding-bloated Silicon Valley unicorns with no business model. The phrase “stacking the bricks” refers to the idea that you build businesses by getting small wins one after another. But this article is about a website rebranding. Amy and her business partner Alex took a very deliberate approach to building a new content-focused website that eschews the chronological blog format. I love this idea, and I plan on doing something similar in the future. 12 ways to make money w/ Drip was just the beginning.
Maybe it’s because they didn’t have experience. Maybe it’s because they thought the formula was rate = salary rate / 2000. They didn’t consider all the overhead and liability of being an independent business owner.
They start to charge their new clients more. $50/hour becomes $60 becomes $75, maybe even $100. But then, you have a conundrum. You still have old clients. Loyal, long-term ones that pay your old rates. These old dogs are paying $50/hour while the shiny new ones are paying $100 for the same work.
On the one hand, the long-term clients have changed from stable income to liability. You could replace them with someone that pays double. Keeping them around is bad business.
On the other hand, they bet on you when few would. They hung around through some tough times while you were learning the ropes. Raising prices on them or worse, kicking them to curb feels unfair. Not keeping them around is bad business.
You should raise your rates, but do it the right way. There’s a way to respect both your relationship with the client and your own business. Here’s how to approach it:
I always did my rate increases on January 1st. The benefit was two-fold. First, clients are more likely to make buying decisions for the next year at the end of the previous one; it lets them get a big tax write-off at years end and pursue new initiatives in the coming year. It also made it clear that this was a planned business move, nothing personal. Lots of companies make changes in the new year. Your clients, as business people, should understand, and respect that.
If you can’t wait until then, the starts of fiscal quarters work well: April, July, or October 1st. Any date so long as it doesn’t look arbitrary.
Don’t spring a rate increase on your clients.Your invoice should never surprise. Give them 30 days notice minimum. 60 is better.
Rate increases are more likely to be accepted if they sound reasonable. If you try to jump from $20/hour to $10,000/week, you are going to raise a few eyebrows and get more than one boot on your ass. Don’t raise your rates more than 50%. Even if you are charging the old client $50/hour and charging new clients $100, consider increasing their rate to $75. You could tell them you charge others $100, but since they have been a long-time customer, you are cutting them a break.
Tell them that the deadline is the deadline for new work booked, and does not affect the rate of previous agreements. If you agreed to a 50-hour project at your lower rate, you need to do that work at your lower rate, no matter what. Letting people know that there is a rate increase coming gives you a sense of urgency. Use it.
Don’t call this a rate increase; it’s just a price change. Be direct and professional. Don’t apologize and don’t sugar coat. You are a business person making a business decision and communicating that decision in a professional manner. Act like it. Own it.
Higher prices typically mean a higher quality of service. In what ways has the value of your service increased, or will increase, for your clients moving forward? Here are some examples:
● You’ve become better and faster at what you do. Your work is worth more now than when you started.
● Raising your rates means that you have to take on fewer clients so that each client will get more of your focus and attention.
● You’ve added or will add new parts to your service, increasing the value.
Bring these to your client’s attention when you bring up the rate increase. Don’t assume the justification is obvious, politely bring it to their attention.
Hi Client, I want to let you know I am changing my billing for the for next year. I'm changing my business, so I can take on fewer clients, and give more specialized attention to clients like you. All work booked after January 1st will be billed at the rate of $100/hour. All worked booked before then will remain at the old price. Please let me know if you have any questions or concerns. Regards, Glenn
Your clients won’t always greet your rate increases with welcoming arms and open checkbooks. Here are some common objections, and how to respond to them.
“I should get to keep my old rate.”
reiterate your earlier message: They can keep the old rate for work they book now, but new work will have to be at the new rate.
“Why Should I pay more for the same service?”
Point out your value add from before, and also that you know their business more intimately than literally anyone else on the market. Your client knows you, and you know them better than anyone. That makes you worth more. You have the ultimate unique selling proposition. Now is the time to use it.
“ The new price puts you out of my budget.”
Then tell them you are sorry your services are no longer a good fit, and if you can, point them in the direction of someone who can help them.
Do you have some older clients paying less than your new ones? Time to fix that. Choose a date, and put your plan in motion. Draft the email you are going to send.
Are all of your clients paying you the same, i.e. your top rate? Capital! Think about whether it’s time to put a rate raise on the schedule.
Either you outgrow your clients, or they outgrow you. Or one of you gets pissed and fires the other. Not every client relationship will survive this process, and that’s perfectly ok. You gave people every opportunity and reason in the world:
● You gave them notice of the increase.
● You gave them one last chance to get work at the old price.
● You gave them reasons justifying the rate jump.
● You gave them options if it didn’t work out.
If you follow the steps above, no reason for hard feelings on either side. And once you’re done, consider the outcomes:
● Your old clients are paying your new (or close to your new) rate. You are making more money for the same amount of work.
● Your old clients leave, and you replace them. You are now making more money for the same amount of work.
● Your old clients leave, and you don’t replace them. You are now making the same amount of money for less work.
There is no bad outcome here. So what’s stopping you? Time to fix this inefficiency in your service business.
One way of selling retainers to clients is what I call the “cell phone plan retainer”: A client pays you $X,XXX dollars a month, and you work for up to XX hours that month. In effect, you are pre-selling a bank of hours. This approach comes with tradeoffs: You get recurring revenue, and your client gets a fixed expense.
However, clients have a habit of making sure they use every single minute less they feel screwed, and you haven’t truly escaped the trappings of hourly billing.
One way you can transition out of this is to start offering “hours plus” retainers. For a price, you deliver XX hours, plus something else of value.
Let’s say your clients occasionally need stock photography. Good photography isn’t cheap. These wolves cost $249. Your client might look at you like that if you put that on a retainer invoice. And that’s a big cost that you shouldn’t just eat yourself.
Adobe offers a more reasonable option: subscriptions starting at $29.99. This expense raises another problem:
Let’s say that your clients need around five images a month, and the 40 images/month plan will always meet your needs. It’d be unethical to bill one client the expense, and let the rest gain from it. It’d also be unethical to charge the subscription as an expense to multiple clients:
Here’s your new retainer pitch:
“For $X,XXX dollars a month you get up to XX hours of my time plus unlimited stock photos.”
Your price should be higher for the type of engagement. Offering something unlimited may scare you, but in our example, you can upgrade to the $199 plan for 750, which is 150x your normal volume, and it’s only $0.99/image after that you have a good fail safe.
The unlimited offering means you aren’t just selling stock photos anymore, you’re selling freedom from ever worrying about how many photos to use or how much they cost.
That’s worth at least $100 to any discerning buyer. And it’s more than the subscription. And it gives you an opportunity to make a small step away from hourly billing and increase your profitability.
Photo credit: danxoneil via Visual Hunt / CC BY
Hey there,
I’d like to share a story with you about my first conference talk, back at the end of September.
September 28th, I arrive in Norfolk, Virginia for the speaker’s dinner. Brennan invited all of the speaker’s out to a fancy restaurant before the opening mixer at the Double Your Freelancing Conference . This conference will be my first time speaking at a conference. To prepare for any presentation, I have a routine:
The talk is never scary; it’s the anticipation that breeds anxiety, even though I know I shouldn’t be. The organization is on point, what could go wrong?
Matt Inglot takes the stage to give his talk. His slides broke. Matt didn’t miss a beat. My heart did.
Something could go wrong.
It was also Gina Horkey’s first conference speaking gig too (Don’t tell her I said that). She went on before me. We would silently cheer each other one whenever we passed by in the hall.
“We got this!” “Do we have this?” “We got this!”
Gina takes the stage. Slides are out of order. She dropped her clicker. It snapped open. The battery fell through a crack in the stage.
Fuck.
After that, it was my turn. I was a bit shaken up, but it went fine.
If I learned one thing from DYFC, successful lifestyle business
people know how to party.
Of course, we talked shop too. You know what people said about
the day’s presentations?
cared about her bad luck. “All that happened, and she was still
great.”
People who gave a damn about the things we feared most: zero.
Why did our talks work at all?
… if the presentation is a user experience, then I am just a UI.
That’s it.
I am a UI.
Nothing more.
And what’s a key attribute of a good UI?
It disappears.
It does not draw attention to itself.
And the moment I remember this is the moment I exhale and my
pulse slows. Because I am not important. What is important is the
experience they have. My job is to provide a context in which
something happens for them.”
We all took the stage aiming help people and did. We
disappeared. Broken decks and speaker pointers ceased to matter
because we ceased to exist.
Are you starting a new endeavor? Maybe you’re in the middle of
one, and you’re struggling to finish. Either way, try to take
yourself out of it for a minute. What problem are you solving for
who? Focus on that and success can find you regardless of rough
edges.
Cheers,
Glenn
P.S. This letter originally appeared on the Tuesday Pulse Every Tuesday I could be sending you letters about shipping products that provide value to as many people as
possible, and you can get over the personal problems that stop you.
Let’s say you create a special offer for a particular audience, event, or your mailing list. You can “hide” the page by not including it in any navigation, and usually, Google won’t pick it up. However, if you want to be extra sure, you can do so with the Yoast SEO plugin. You only need the free version.
Before you hit publish, go to the ‘advanced’ settings in Yoast SEO below your post.
Your settings should look like this:
Now you can hit publish and feel confident that your page will only be visited by the people you intended.
Pre-S Warning: This week’s post contains crass language. If kids are nearby, you may want to cover their ears.
My Mother works in Elberton, GA, The Granite Capital of the World at a local Quarry. Here is their #2 best selling product:
Tombstones.
I love companies like this, invisible enterprises that build something important to everyone. But this isn’t a letter about tombstones; this is a letter about their all-time #1 bestseller:
Gravel.
If you ever think you can’t provide value to the market, here’s a company making bank by selling tiny rocks on the ground, an abundant natural resource.
The quarry didn’t set out to be a tiny rock business. They set out to build beautiful monuments. The tiny rocks are a side hustle. Stonecutters work their craft, and tiny rocks just happen.
These rocks are gathered, bound, packaged, priced, and sold. This company took waste and turned it into a product that sells more than the product they showed up to build.
Every business has its tiny rocks: rubbish waiting to be butterfly-transformed into an asset. Here are some examples:
As a small business owner, resources are always tight. Without a lot of time or business capital, you need to get the most out of the resources you have. Look around you for tiny rocks, gold that you’re leaving on the ground. What have you been missing?
Working with bad clients puts your business in a vicious cycle. You start out meeting with a client that sets off your Spidey sense a little. You need to pay rent this month, so you agree to the work against your better judgement. You end up working with a client that belittles you, doesn’t trust, you and is unwilling or unable to pay you what your worth.
Scope creep is inevitable in software projects. But that doesn’t mean that all scope creep is inevitable. When a client asks you for functionality that wasn’t in the original spec, why are they asking for changes? There can be several causes.
Before I started my consulting practice, I had product aspirations. I bought about 25 domains, every time thinking this one was going to be the project that I would ship.
But I Didn’t.
Sometimes when a client reaches out to me, they open with a question like this:
“My real estate company needs a website. We need show our real estate listings. How much will that cost, and how long will it take?”
How many clients do you need to work with to be successful this year?
Putting estimates together for projects is difficult even in the best conditions. It’s even harder when client’s are pushing for a proposal before you’ve had time to get all the details, or you end up having to spend a lot of unpaid time putting together a proposal that ends up getting rejected.
There are a lot of JavaScript frameworks out there these days. It makes it harder to choose a front-end development workflow when starting a new project and write code that’s portable between different projects. Also, using a complex framework to solve a simple problem adds unneeded complexity and risk to a project, which makes getting that project out the door slower and more troublesome.
To get paid promptly, you need to send invoices promptly. And if you are billing hourly, then untracked time leads to uninvoiced work. Freelancing is hard enough without you taking money out of your pocket.
Here are the top reasons software projects fail, according to a report by the Standish Group. We’ve touched on these throughout the book, but I wanted to provide a quick refresher.
It can be difficult to stand out from the crowd of other developers, especially when a potential employer can post a job posting online and have dozens of proposals from developers overseas offering to do the same job at sub-minimum wage prices. How can you compete?
Do you have a client that wants to meet all the time, and for countless hours? Sometimes clients want to meet daily or will call you with no particular agenda in mind. How can you reduce these interruptions?
How to you find quality clients on freelance marketplaces like Upwork and Freelancer.com? Getting quality client work on these sites is nearly impossible. When an average Day Job in India pays as little as $0.65/hour, then doing web development online from the comfort of their home is a dream job. How can you compete?
In December of 2015, during a local Finish Day Event, I launched a new version of my site, GlennStovall.com. This case study is a breakdown of the rebuilding process, why I did, and the results I achieved.
I decided that publishing more content was going to be a larger part of my business in 2016. The problem was that I was managing the site on OctoPress, which was becoming cumbersome. That isn’t a slight against OctoPress but an acknowledgment that my writing and publishing process changed and that OctoPress was no longer a good fit.
You know what one of the most common causes of failure is for software projects? You don’t have a plan. Unlike building with more solid materials in construction, you can start making software before you know what the hell you are doing. Writing a program roadmap helps you make decisions earlier when they cheaper, and give you a reference point to make sure everyone involved is working towards the same goals.
One of my New Year’s resolutions is to create more valuable content in the coming year. In addition to my annual post-mortem, I wanted to share some of the most valuable lessons I’ve learned throughout the year so that you can apply them to your own bootstrapped or creative service business.
Getting clients as a freelancer is like a catch-22 problem. If you ask other freelancers how they find clients, they typically say “word of mouth” or “referrals.” How are you supposed to get referrals without previous work? Getting started seems impossible.
If you are thinking about starting a freelance business, you need to be proactive when it comes to getting your first clients. Building your business will get easier with time, but when it comes to your first customers, you have to hustle.
These are the five steps I took when I started my career. I recommend starting this process at least 30 days before you plan on leaving a current position / starting your freelance career, and continuing these habits until you have built a steady pipeline of client work, and doing them in the order presented.
I hate playing the back-and-forth “what times works for you?” game when it comes time to book a meeting. As a one-person shop, I’d rather spend my time providing value to clients and taking care of more important matters than spend time negotiating appointment times.
I use Calendly to make booking appointments easier. I can send people a link to my calendar, and they can pick a time that works for them. This technique also gives off an air of professionalism when dealing with potential clients.
A prospect requesting 1-on-1 time is a huge buying signal. As a consultant, these are the people that I want on my mailing list.
It would be awkward to ask the person you are meeting with to join a mailing list, so instead I combine a Drip opt-in form with my Calendly. Doing so allows me to create “Book an appointment with me” opt-ins on my site.
Want to keep your list high quality and remove people who aren’t opening your emails? Here’s an automation rule I got from Kurt Elster and Philip Morgan that can do just that:
You probably have different methods of adding users to your list. Or maybe you are testing whether or not asking for a first name affects conversion rates. Either way, there are situations when you want to use the first name if you have it and have a fallback if you don’t. Here’s a quick code snippet you can use:
<code>{% unless subscriber.first_name == null %}Hi {{ subscriber.first_name }},{% else %}Heya,{% endunless %}
Wagglez came to us with a vision for a local discovery and coupon app that helps travelers in new cities find the places that locals love best. They were in a time crunch to launch, and needed someone who could come in and quickly coordinate with a young development team.
For Tangent Solutions, a growing software products company, the biggest hurdle they faced was a lag time between contracts. Due to the scale of software and complexity in orchestrating development teams, software products often encountered problems like going over budget and missing target deadlines. They needed a solution that made complex estimates more agile.
Network storage company Coraid powers some of the most renowned enterprises. They were bringing a new product to market that needed some finishing touches to the website front-end and performance. They needed a creative development crew that could transform their existing interface into an easier to use, cleaner tool to help monitor server performance.
The founders of Borrowing Magnolia wanted to help the modern bride plan her dream wedding on a budget. They also knew of many newlyweds had dresses that would sit in the closet collecting dust for years to come. They wanted to help people turn their old dresses into an asset, and help brides to be find their dream gown.
If you are using Drip for your marketing automation, you might want to change the copy on the “Confirm Your Subscription” Link that gets sent when people fill out a form. This link is an important call-to-action, and this little piece of text can have a big impact on your subscription conversion rate. Drip doesn’t make it clear how to change this copy, but it is possible.
One part of the freelancing puzzle I haven’t solved yet is keeping cash flow stable. Here’s a lifetime graph of my revenue, month, by month:
There’s a lot of peaks and valleys. Good clients, bad clients, late payments, upfront payments. Sales slumps. Family emergencies. It’s all there.
About a year after I became a freelancer, I started another exciting venture in my life: marriage. Once we got back from our honeymoon, we had to start dealing with one of the mundane parts of marriage: Money. Merging finances and budgeting for the future.
Budgeting is hard when you have a reliable salary. Planning on variable income seemed impossible. The first year I was married I brought home $0 – $10k+ per month. How could I decide how much I could dedicate towards groceries?
I just got back from the first annual Double Your Freelancing Conference, and I haven’t felt this exhausted and excited in some time. I met so many great people and listened to informative talks by some brilliant speakers. Instead of getting into individual tactics and strategies, I thought it’d be more beneficial to you to share the big picture of how I’m planning on reshaping my business moving forward.
The keys to creating a successful business are simple, difficult, and patently unsexy:
Patrick McKenzie(@patio11, founder of starfighters.io) Just shared a buffet of bite-size career advice for software developers on Twitter.It’s too valuable to let it become lost as it floats away down the Twitter steam, so I’ve preserved it here for future reference and top-to-bottom reading.
It takes us 3.65 hours to design and implement a contact form.
I used to work for a web agency that wrote fixed quotes based on hourly estimates. When a member of the sales team is on a call, they are going to have to face a common question from clients at some point:
People have probably told you that two things every business should be doing is generating content and building a list. The problem with this advice is that it usually comes wit no “how” or a “why”. Writing content as a marketing strategy is a slow burn with abstract benefits. But a solid strategy can bring in more customers, help you build relationships, and help you position yourself as an expert to others. And writing content that does this is not as hard as it looks.
One of the scary factors of creating a content strategy is that publishing consistently is valuable, but that requires a commitment. When you don’t knowwhat to write about, how to write about it, or how to get readers, it’s easy to feel overwhelmed. Here’s my 9-step process I use to generate content; A Roadmap you can use to start mapping out your content strategy.
Metaprogramming is one of the unique features of Ruby. Metaprogramming is an interesting concept, and a tool can save a lot of time. It can also be confusing for developers and difficult to maintain if not used properly. Here is an example of how I used Metaprogramming to solve a real-world problem and save a few hours coding.
Continue reading
All businesses are inherently risky. Human beings are terrible at understanding and quantifying risk. Since most entrepreneurs tend to be human beings, this causes problems. Without having a clear picture of what risk is, how to identify it, and how to quantify it, making correct decisions about your business can be hard.
The biggest cognitive dissonance is that people confuse variance and risk. For the purposes of this article, I am defining variance as the variety and difference and outcomes of any given probabilistic event. A six-sided die has more variance than a coin since it has six different possible outcomes while a coin has two.
We define risk as the losses incurred based on the outcomes of one of those events. The greater the amount of loss and the greater the chances of that loss occurring increase the amount of risk in any decision.
Launching a new product can induce a lot of anxiety. If you have been working on your product for some time, it is easy to let the fear of uncertainty about public reaction take over. You might decide to push the launch the back until you can one feature a bit better, a part of the design a bit cleaner, or to fix one more outstanding bug. You end up pushing your launch back to next week, next month, or in the worst case, “one day”.
Apple just finished their 2015 WWDC, and there are some valuable lessons startups can learn from Apple’s marketing strategy.
When building client-side applications, your URLs are prepended with a hash. Removing this can make your routes more user-friendly and more easily crawled by search engines. Here is how you can remove the hash from your routes in an Angular app built on Ruby on Rails, and use the standard URL structure.
Continue reading
It seems like these days everyone wants to build a software as a service app. The siren’s call of monthly recurring revenue is hard to ignore.
SaaS products are a complex undertaking. I’ve worked on them before and seen how all the moving parts have to interact. There are plenty of SaaS Development tools, libraries, frameworks, and even other SaaS products out there to help you along the way. Where do you even get started?
If I were to start building a SaaS application today, and I say today because technology is always moving quickly, here are the tools I would use to build a SaaS application. This list focuses on the technical aspect of getting the software built, and not on sales and marketing. That is another listicle entirely.
These are notes and links from a presentation I gave to the Developers of Athens on testing client-side applications.
Every Year I take a look back at my business, and do the same exercise I do with every client project: a postmortem. I ask myself 3 questions:
This is a valuable writing exercise, and I’d strongly encourage you to do the same. This is my postmortem of 2014, as well as a review of how I did on my goals I set for myself at the beginning of the year.
I was listening to Episode 214 of Startups For The Rest Of Us, where the hosts Rob Walling and Mike Taber look back at their goals they set for the year, and give themselves between 0 and 1 points based on wether or not they felt they achieved that goal. Before I get into my postmortem, I wanted to go through the exact same exercise.
It seems like every year I have a vague goal of launching a product, and I tend not to do it. While I did launch a Productized Service, I didn’t create any kind of profitable project this year.
I’ll give myself half a point here. While I made some improvements in managing my time, I still feel like there is a lot of room for improvement. Some good steps forward I have made has been more diligent about scheduling my time, and eliminating tasks that kept me busy, but weren’t productive.
This was mostly in regards to sales and marketing. I started using PipeDrive to both systemize and keep track of the numbers on my sales funnel. PipeDrive also allows you to add custom fields to your leads, so I have started tracking 4 data points on each lead that I come into contact with:
This way I don’t only see how many leads I am getting, but I can drill down on which leads are the most profitable, which convert the best, and what are the best sources of leads that convert.
See PipeDrive above. Now I have a defined sales process, email templates that I use for communicating to leads and prospects at various points in the conversation. This has allowed me to spend less time selling and more time creating value. I also feel that I have a strong framework for writing proposals.
Since I’ve implemented these practices, the number of leads I get have increased, and my conversion rate as more than doubled.
In addition to raising my rates last year, I have eliminated work billed by the hour with the exception of some legacy clients. I finally implemented this towards the end of the year, and so far the results have been tremendous. I feel happier working not having to punch a time clock, client relationships are better, and I feel I am providing more valuable work.
I did experiment with daily and weekly billing, and that for the most part was a bust in my experience. Some people swear by weekly billing, however I found that many prospects didn’t “get” it, and it was just causing more friction in the sales process.
In 2013, I would divide up the bounty of each paid invoice into a few different buckets: a percentage for the company coffers, a percentage for Uncle Sam, and a percentage in my pocket. Now, I pay myself a monthly stipend regardless of income. This makes personal budgeting and financial planning easier, reduces stress during the lean months. This also means that I have more cash on hand in my company account that I can invest back into the business.
Email used to be one of those tasks that was a large time sink for me. Then I started practicing inbox zero. Now I check email twice a day, and each time I am able to get though my inbox quickly. Mailbox is a great app if you’d like to start practicing it.
On that same note, I started implementing the principles of Getting Things Done, which is essentially the principles of inbox zero applied to your to do list. I now have one task management system, and everything I need to do goes into an inbox. The inbox is processed daily, and then tasks are knocked off. Since doing this I’ve had almost nothing fall through the cracks, and I feel less stressed and more on top of things. I use the Mac/iOS app Things to manage my to do lists.
I’ve gone through multiple redesigns of this site, and my company site, Concordant Solutions. I finally decided to only manage one site, and give it a facelift. It’s an ongoing process, but right now I feel like my site is the best it has ever been.
I invested a lot more in writing content this year. I’ve had some articles gain some traction, including making the Medium.com top 100 one month. I also published a free eBook that has been downloaded over 1,000 times. Both of them have helped me reach more people, and have started many a great conversation. Here are my most popular posts in 2014:
While I had good intentions as far as releasing products went, I wanted to start building an audience of people beforehand. While the product idea never came to fruition, I’m glad that I started this. I have had some fantastic conversations, Got invites to be a speaker on a webinar, and get to keep in touch and build relationships with people at scale.
Building an audience also gives everything else I do more purpose. Now writing articles isn’t just about sharing content, it’s an entryway to building relationships.
Being self employed is lonely work. If there is one thing I miss from the employed world (in fact, I think this is the only thing), It is having people to relate to what you are doing, and being able to reach out for help.
This year I joined a mastermind with three other freelancers. Each week we hop on a Google Hangout, and discuss what is going on in our business. It gives each of a chance to get a few extra pairs of eyes on anything we’re working on, and a forum to even about frustrations we wouldn’t otherwise. I’ve learned just as much, if not more from the conversations I’ve had in these mastermind meetings than I have all the books and podcasts I’ve consumed this year.
After a couple of large projects and heavy workload, I became burned out towards the middle of the year. I had some money in the bank, and decided to schedule some time off to rest and invest some time in my business. This turned out to be the worst decision I made all year.
Firstly, trying to take time off and invest in my business was a poor plan. It really should have been one or the other. Secondly, It just enough small jobs rolled in that I didn’t really get to relax or make very money, leaving me dealing with the worst of both worlds. Finally, it’s hard to build up momentum after stopping. What was going to be a break of a few weeks ended up being more like a break of a few months, which really put pressure on both my cash flow and sanity.
On the bright side, this was also the moment that led me to do a lot of introspection and make some decisions about what my business was going to look like in the future.
Last year I formed an LLC and formed a company site called “Concordant Solutions”. Both the site and the brand was a failure in every metric I can think to measure it in. Managing two sites was more time consuming than managing one. Any content I wrote for my company site tended to fall flat, and did not generate leads of any sort. Explaining to people in person that I was “company” that was just one person, and what the hell “Concordant” means became exhausting and distracting.
For now, I’m back to being plain old me. The name Concordant Solutions now only exists in the world of contracts and invoices.
In September, I decided to join Colin Devroe in taking a challenge to publish something every weekday for 30 days. While I did finish the challenge, (and wrote a postmortem about that too), I don’t think it was that valuable of an exercise. It led me to publishing a lot of content that wasn’t all that good, and took up a lot of my time.
I think that if you were tempted to do something similar, writing every 30 days would be a much better goal.
This is something that has been on my goal list for a few years, and one I haven’t been able to capitalize on. I started work on a few, but I was usually stopped by the fear that I was launching a product for product’s sake, and not because I was unsure that It would be valuable. This is a fear I need to get over, so I can at least try to launch something to generate a more passive revenue stream.
I had some client relationships this year that didn’t go as well as either one of us would have liked.I did a poor job of managing the client relationship and their expectations. Since these experiences I’ve worked hard at streamlining my communication and pricing structure to support a better relationship.
At the end of the day, the relationship between a consultant and their client should be a partnership. However, I think we all do things that tend to frame it instead as an adversarial relationship.
My shift away from hourly billing was based on these principles. When billing based on time, the client has a financial incentive to decrease your contribution to a product, while it gives you a financial incentive to increase it. Right off the bat, this is the kind of adversarial relationship I was unknowingly fostering.
This is my primary goal for 2015. This year I learned about standard operating procedures, and how to separate yourself from your business. While I have written some procedures, My coverage is far from complete. The ones I have written have been valuable, and I really want to double down on this.
Standard operating procedures are just step one in building a more scalable, effective business. Even just by themselves, they reduce the mental overhead of making decisions, much like wearing the same clothes everyday. But beyond that, they enable you to hand work off or automate. Once you have a defined process, you can hand that work off to a virtual assistant, a subcontractor, or a python script. (Standard operating procedures are basically Python scripts for human beings).
When I started this business two years ago, if you asked me which parts of my job would be the first to be outsourced, I would not have guessed the actual production work. After all, writing code is what I do. Or at least that is how I used to look at it.
Now, I see that I have much more interest and provide more value in dealing with the “big picture” issues of both my own company and of my clients. Neither one of those requires me to write code.
I don’t plan on removing myself from writing code completely, nor do I plan to be a middle man that farms out work to the lowest bidder on the other side of the world. What I do plan on doing is sending well defined parts of projects off to other implementers, and relying more on people that have stronger skills than I do, such as graphic design.
I fully expect this to enable to provide more value to every one of my clients than I have in the past two years.
This year, I made some good steps moving from “guy who writes code” to “guy who solves problems”. This year, I want to hammer out exactly what kinds of problems those are. There is more than enough work available in the world, and being a generalist does more harm than good. In the coming year I hope to have a more clear positioning statement and brand. That might a new job title, it might mean a new company brand. What it definitely means is a marketing strategy that is laser focused on a particular set of problems that a particular set of people have.
I invested significantly more in my education and in networking than I did last year, and both paid off in spades. Many books I’ve read, groups I’ve joined, and services I’ve used have paid for themselves many times over. This year I’m excited to find more opportunities where I believe I can make my money work for me.
Self-explanitory.
The end of the year will be here soon. It’s a time to reflect on how the past year went, and plan for the next year. Three numbers determine your bottom line. By understanding these numbers, you will know what metrics you need to move to get the business results you want. By doubling just one of three numbers, you’ll double your revenue, without increasing your workload. So instead of saying, “I want to make more money next year”, by the end of this email I want you to say how you plan to make more money next year.
I recently read an article entitled five ways to build a $100 million dollar business. It discusses different business models that vary in the number and size of your customer base. Some businesses work with a few enterprise scale clients while others work with a larger number of smaller customers. Patrick Mackenzie mentioned on Twitter that “The math here is equally applicable if you are trying to build, say, a $200k a year business”.A $200k/yr consultancy is a goal that seems both attractive and attainable, so I decided to try and answer the question “How can you build a $200,000 consultancy?”
In a previous article about Yeoman, AngularJS, and Foundation, I talked about setting up a complete front-end scaffold with Yeoman, AngularJS, and Foundation. Now I want to look at how to test the AngularJS part of your application.
With the combination of modern browsers and mobile devices having support for HTML5, CSS3, and new JavaScript APIs, front end development has become a lot more complicated, but also exciting. There has been an explosion of tools as of late, and it can be daunting to know where to get started. Here are the tools and process I use to build a new front end application from scratch.
When a freelancer submits a proposal, they will often only include one offer. They will set the deliverable, and the price, and throw their proposal over the wall. When you do this, you give the client a binary option: Hire you or don’t.
By giving the client a few different options, you are changing the conversation into one that is more likely to end with the client hiring you.
Email marketing converts better than social media or content marketing. Nathan Barry has a great write up with the numbers. You can build a list by giving people incentives in exchange for their email address, reaching out to them directly, or offering people updates on an as-yet-unreleased new product. But once you have built that list, how do you write emails that people on that list will want to read?
When I left my job to become a freelance programmer, I was charging $50/hr in the beginning. I met other freelancers, consultants, and agencies in town, and a few of them charged $150/hr. Even the agency that I had worked at previously billed my time at $120/hr, which means that my level of programming skill was not the deciding factor. If they could charge that much for my services, why couldn’t I? There was a broken record in my head asking me the same question:
“what’s the difference between a $50 freelancer and a $150 freelancer?”
So I decided to start spending time learning about pricing, value, and all that “business stuff” programmers and designers love to avoid.