Do you train for the unexpected?

Do you train for the unexpected?

We all have our “I can do one more” moments in the gym. When we’re super confident we have one rep more in us but we fail miserably.

It doesn’t happen every day or every week (if it does, you really need to slow the f**k down), but when it happens, it can lead to serious injuries.

Most of us know a few things about staying safe. Like, if you don’t have a spotter while you’re bench pressing, you leave the clips off so you can dump the weights to the side in case something goes wrong. Or to make sure you adjust the safety bars when you’re squatting so you can drop the weight if you fail to do that last rep.

If you’re into fitness, like me, you most likely spend a good amount of time looking for new ways to maximize your results. How to overhead press more, what workout splits are better, how many reps, how many sets, how low to squat, how high to press?

We search and try all sorts of training methods, exercises and workout splits.

But… when is the last time you trained for the unexpected?

Money is not a prerequisite to start an online business

Sometimes I have these thoughts of how it would be to start my own thing. To work on my own service or product. To chart my own path and call my own shots.

It usually happens when I’m on a long drive. All sorts of ideas cross my mind: fitness instructor platform, event services, cleaning services, homeschooling, and others.

Once I stumble upon a decent one, I start thinking about what would it take to make it real. What tools to use, how it would work, how it will make money, what people would be interested in it.

The problem is never money.

Assuming you have the required skills to build the damn thing, there aren’t any huge costs you need to support. You only need a domain and hosting. That’s it.

Let’s say you have that 100k budget to start with.

What would you do with it? What would you buy? Who would you hire? Will spending that budget turn your business into a profitable one?

Sure, it’s nice to have money, but they are rarely a prerequisite to start an online business.

The build cycle of a Laravel application feature

I wrote about having a crossword approach to writing software, but I haven’t given any real-world examples. I only said it’s better because it doesn’t let you wander around and dip your fingers into everything. It keeps you focused on what’s needed now.

Let’s say you’re building a content management system using Laravel. Here are the steps I’d take to build it:

1. Write the code to display the posts in some kind of list. You can get this done by just having a seeder in place and a simple query on the index method. Don’t worry about filtering or anything like that.

2. Write the code to show, store, update, and delete posts. Completely ignore any validation and authorization for now.

3. Notice I haven’t said anything about writing views. No html&css should be written so far. Views can wait.

4. Go back to the create and update methods and add some validation rules.

5. Sprinkle some authorization too. Don’t forget about the delete method.

6. If you need to filter the posts in any way, now is probably a good time to do it. Don’t forget to write tests that cover every filter.

7. Now that all the logic is in place and thoroughly tested, we can start focusing on the views. Style the index and the show views.

8. Add the create and edit post endpoints and style their views too.

9. Sprinkle some javascript where’s needed. Don’t over do it.

10. Pick the next feature. Make sure it touches as few things as possible.

Rinse and repeat.

Better, not perfect

I just finished something I’ve been working on for the past week and I am quite dissatisfied with the result. I’m not sad, nor annoyed. It’s something I never did before, so poor results were to be expected anyway.

What brings me satisfaction is that, one week in, and I already found more than a few ways to make it better. They are not ifs or maybes. They are obvious improvements that directly impact the end result.

Don’t waste time, don’t put much thought on it, “Just ship it” they say.

The reason behind “just ship it” is to get as much feedback as possible to help you gradually improve whatever you shipped. The faster you get the feedback the better.

But how do we know when it’s “ship-ready”? It will never be perfect, but when it will be good enough? You can’t just deliver some crappy version of your idea and expect people to like it enough to guide you in the right direction.

It’s good enough when you’re done improving the obvious.

More than ordinary

It’s immensely pleasing when the barber doesn’t need to ask how you want your hair done, or when the barista hands your favorite drink the second you sit at the bar, or even when things go wrong and apologies are made.

More than ordinary. We love that.

And we give back. It’s no longer just ‘a barber’, it’s ‘my barber‘. Not a random bar, ‘my favorite bar.

We return the favor. Always.

Eloquent trick #1: Replace conditionals with “when”

It happens very often that we want to apply certain eloquent query conditions based on what a request sends in. Sometimes it’s a “search by name” thing, other times we just need to filter the records based on a status column.

Usually it looks like this:

public function index(Request $request) 
    $posts = Post::newQuery();

    if ($request->term) {
        $posts->where('name', 'LIKE', "%{$request->term}%");

    if ($request->status) {
        $posts->where('status', $request->status);

    return view('posts.index', ['posts' => $posts->paginate()])

I recently discovered there’s an alternative to using conditionals. The “when” method executes a callback (second parameter) when the first parameter evaluates to true.

public function index(Request $request) 
    $posts = Post::when($request->term, function($q, $term) {
        $q->where('name', 'LIKE', "%{$term}%");
    })->when($request->status, function($q, $status) {
        $q->where('status', $status);

    return view('posts.index', ['posts' => $posts->paginate()])

It’s not all that better if you ask me. Yes, it hides the conditionals, but it also makes the code harder to read. Especially if you have more conditions to add.

I’d use this “when” approach for single conditions only.

public function index(Request $request) 
    $posts = Post::when($request->term, function($q, $term) {
        $q->where('name', 'LIKE', "%{$term}%");

    return view('posts.index', ['posts' => $posts->paginate()])

Two thoughts I try to live by

Seeing the full glass
If you’re walking down the street and a thief steals your hat, you probably get real angry real fast. It’s only natural, but I’d like to be able to see it as an opportunity to buy a new hat. The one I had was getting old anyway.

Doing the best yes I can
Don’t make a habit of saying yes to everybody and everything. You won’t be able to please anyone, not even yourself. But when you do say yes to something, you need to take responsibility and do the best yes you possibly can. It would be nice to be able to say “I don’t do much, but I do these few things extremely well“.

I’m bad at following my own advice, in fact, I almost always fail to do so, but I like to think someday I’d be able to stick by these two.

Thank you, apple, for letting us know we’re not alone

Feel bad for messing up something at work lately? You’re not alone :). Apple messed up big time.

The bug lets you call anyone with FaceTime, and immediately hear the audio coming from their phone — before the person on the other end has accepted or rejected the incoming call.

Read more here.

A crossword approach to writing software

One of our jobs as programmers is to think ahead so that we build the right things in the right order and at the right time.

“Ok, I’m gonna build this to do that, and then I’m going to add X so I can do the other thing that will do Y and everything should fit together.”

Our everyday thought process

The problem is sometimes we’re overthinking it. Sometimes we don’t need that extra class or that extra parameter. And that method we think we’ll use later might never be called at all.

Everything we write has a cost. Every extra class, variable, method, or parameter we add makes our code harder and harder to understand and support.

The reason why we fall into this trap is that we often don’t have enough information about what we’re building. We know the bulk of it, but details always seem to be slipping through the cracks. Building extra stuff is our way of trying to catch those hidden details. We call it speculative generality.

One way to avoid speculative generality is by taking a crossword approach.

The most effective way of solving a crossword puzzle is by filling in the easiest words first. Find and complete them, and you get more information about those other hard words you don’t really know what they are and how to solve.

The same principle can be applied when writing software. Instead of building a component from the inside out, do the opposite and start from the outside in.

Stop trying to figure out the hardest parts and go for the easy ones first. This way, while you move towards the core of your component, you’ll uncover more and more details about it.

Start by picking the smallest possible feature.

It’s on.

Writing is the hardest thing I ever did. And I’ve always been bad at it. But, as with everything else, with enough practice and dedication, it can get better. It will get better.

All the great writers I know say you have to write every day for at least one year to get good and even more to get noticed.

Because it takes so long to receive feedback (good or bad), most people quit. There’s no one there so they quit.

That’s why I’m building dashcopy – a community for people who want to become better writers and support each other by exchanging meaningful and helpful feedback.

The development starts this week and the first feature will be the ability to publish syntax posts showing poor vs improved writing. Over time, I’m hoping it will grow to become a valuable resource for all writers out there.

Stay tuned.