Just Take It

Most of the time, I have to work hard to reach my goals. Nothing seems to come easy. In fact, it’s often an uphill struggle.

Every once in a while, however, this pattern breaks. Out of the blue, an opportunity presents itself. Often, it presents itself as a challenge. It would take me out of my comfort zone to accept it.

I love these challenges. They have proven to be my greatest opportunities to evolve and improve myself. This is how I ended up co-authoring a book (which you can order here). This is how I ended up getting interviewed for a podcast. This is how I more than doubled my contracting rate in under 8 years.

For opportunities to find you, you have to be out there. Get your CV out. Connect with people, both online and offline. Every once in a while, a proposal will present itself.

Be open-minded. Consider the worst-case scenario. Is there a risk involved? Can you afford to take that risk? What is the reward? Is it worth the risk? Once you did that, you might find it makes sense to take the leap. If so – go for it!

Life is full of opportunities. We can easily cruise through it missing them all. How comfortable are you with the notion of looking back and knowing you had all these chances to do something awesome and you let them slide?

Next time you are challenged out of your comfort zone, try taking on the challenge face-on. You never know what could happen.

I may get commissions for purchases made through links in this post.

A Debt That Can Never Be Repaid

I’ve been writing code for over twenty years. In twenty years, I’ve learned there’s never enough time to write all the code I want to write.

Developers have been struggling with the constraints of time since the first lines of code were punched into cards. There is never enough time to add all the code we want to write into the program.

I’ve seen this problem tackled in many different ways. TO DO lists, TO DO comments and tech-debt tickets are just a few. The principle is always the same: take a note, leave it for later.

And, without fail, the same thing happens. The software grows, the requirements change, new requirements are introduced. The tech debt never gets addressed.

This is a problem. Tech debt can only be one of two: important or unimportant. If it’s unimportant, keeping track of it is just noise. Why do it? If it’s important, we’re knowingly leaving a problem to fester. This is even worse.

If there’s one lesson I’ve learnt from experience, it’s this: don’t take on technical debt. If this means delaying a new feature, so be it. Be transparent with your constraints. Deliver a done product, not a patched solution.

There are few things more frustrating when coding than to find a three-year-old TO DO in the code. Is it still valid? Should I investigate?

If it deserves keeping track of, it deserves getting done. As Nike said, just do it.

Let Me Sleep On It

Experience has taught me there’s truth in the saying that location is everything. Having lived in amazing homes in poor locations and decent homes in great locations, I am sold. To me, the amazing home in a poor location is nothing but a golden cage.

Choosing a decent home has a price, however. It means less space to store things. Which means one needs to be smart about their storage solutions.

The most significant and efficient solution I have to date is my guestroom bed. It’s an Ottoman and I bought mine from IKEA. It has served me well for over seven years, and still serves me to date.

Other than its mattress, it really is nothing but storage space. It’s built as a hollow, sturdy frame. It has a compact mechanism allowing me to easily lift up the mattress. That mechanism also means I need no space around the bed to open it, as it opens upwards.

If you, like me, are looking for smart storage solutions – then I highly recommend checking out the Ottoman beds. Rest assured, you’ll have plenty of extra storage space.

I may get commissions for purchases made through links in this post.

Keep Your Comments To Yourself

I’ve been writing code for well over 30 years now.

In 30 years of coding, I learned my code has to make sense to me long after I’ve written it. Later on, I started working on code shared with others. My code had to make sense to them, too.

When code got really complicated, I used to add a comment to explain it. I thought that would solve the problem. It didn’t.

Comments rot. We update the code, and forget to update the comments. Sometimes, the change happens far from the comment but still affects its correctness.

Quite often, comments imply our code would not be clear without them. This, in turn, means when I try to understand the code where it is used I am likely to have to navigate to its definition to read the comment.

Other comments are just the result of habit and add no value. Worse, some comments just add to the confusion.

I have learned to avoid comments almost entirely. It took me years to understand what self-documenting code meant, but I get it now.

Be explicit. Name your constants, variables, functions and classes based on what they do. Make sure the name is accurate. Avoid abbreviations.

If a line isn’t clear – refractor it. Extract a meaningful variable. Extract a well-named function. Move it to a well-named class.

With this insight, looking at my earlier attempts at clear code… Well, I have no comment.

(You can read about this idea in depth in Uncle Bob’s Clean Code)

I may get commissions for purchases made through links in this post.

Watch It

I don’t watch live TV. The whole notion of being fed content with no control puts me off.

For years, that was the primary way to consume content. TV, radio, even newspapers. We had very little control over our content, if any.

Then came VOD. Then came music services that let us listen to whatever we wanted. Then came Netflix. Nowadays, there’s no reason to be force-fed content.

Admittedly, if you’re a sports fan, you have little choice. If you can’t wait to watch the next season of a show, you have a problem, too. These are probably the only cases where you need live TV.

The rest of us? We can save money. If you’re not watching live TV, it’s very possible, depending on your country, that you can stop paying for it. In the UK, it’s as simple as going here.

So if you’re like me and prefer to choose your own content – stop paying for a service you are not using.

If Only I Could Take Back Time

My time on this Earth is a finite resource. I can’t get any more to what I have. Sure, I can live healthy and make sure I live a bit longer and enjoy the time I do have more. But that’s about it.

This is why I grab every opportunity to avoid wasting time. If I can skip tasks, automate them or speed them up, I’ll do it.

This is why I find the “play speed” feature to be so great.

A lot of websites offer this feature. Most predominantly, YouTube does. Every time I watch a tutorial or a guide, I look for the option to play it faster. This makes sense because quite often, the videos are slow by nature. The presenter may be taking their time. They may be derailing. They can usually go faster.

Imagine a x1.25 speed on a one hour video. That video now plays in 48 minutes. That’s a 12 minute gain. In some cases, even x1.5 works. In those case, you save 20 minutes per hour!

So the next time you watch an online walk-through, look for the option to play it faster. You may get a lot of your time back. Magic!

Easy Money

I work hard for my money. Granted, some people work harder. Every once in a while, though, you hear of other people. People who get it easy. They make a fortune with hardly any effort.

The truth is, these people probably fall into one of two groups: those who got extremely lucky, and those who scam others to make their fortune.

Either way, there are no fail-proof shortcuts. I know we’ve all been told this before. It’s true. There is no easy money. This is really worth remembering.

I’ve seen intelligent people fall for scams such as MLM (multi-level marketing, also known as pyramid schemes). These are clever traps. They lure you in with the promise of high income. They end up selling you some bogus product which you get stuck with. Avoid these schemes.

The lottery is a similar scam on a world scale. I used to call it the suckers’ tax. When you understand the lottery can only exist when the vast majority of people end up losing, you can stop wasting your money there.

Making money is hard. There are many ways of doing it, but none are easy. If it seems too easy – it probably is. Don’t risk what you can’t afford to lose. Work hard. Be smart. Have patience and be persistent. You’ll get there.

It’s All Or Nothing, Part 2

Every once in a while, it’s time to get a raise. With inflation, and a growing skill set, it makes sense.

As a contractor, I usually stick to one of two opportunities to secure a rate increase. I would ask for a higher rate when assigned greater responsibility. I would also increase my rate when switching contracts.

Let’s focus on the first scenario. When I ask for a rate increase, I do so risking everything. If I’m turned down, I terminate the contract.

You cannot ask for anything without willing to fully commit to using your leverage. False promises dent your credibility. If you ask for anything and don’t get it, there must be consequences. Accept not getting what you asked for, and be ready to never get it.

What reason does anyone have for giving you what you want? Clearly nothing happens if you are turned down. Business is business, right?

So either ask for what you think you deserve, willing to act if turned down, or don’t ask. Otherwise, there IS harm in trying.

So Predictable

Good code should have test coverage.

However, writing tests is not a box-ticking exercise.

If tests are not written well, they are not helpful. One characteristic of a good test is that its results are consistently reproducible. This helps us see what the problem is every time we run the test.

There is a common mistake I see developers make. Trying to cover a wide range of scenarios, they use a random value in their tests.

To be clear, I am referring to run-time generated random values, not random values generated in advance and hardcoded into the test. The latter can be fine.

When you use random values in your tests, you may end up with flaky tests. Your tests may pass some of the time, and fail at other times.

Both scenarios are bad. If the tests pass, you may have missed out on a bug. Your tests no longer give you confidence. If the tests fail, you don’t know what values made them fail. Will they fail when you run them? Maybe. Maybe not. Maybe only after you ran them ten times. This is time-consuming.

You get the idea. Tests should be boringly predictable. If you want to test multiple values, test them all. Use a parameterized test. Use a loop. Don’t use random values.

Testing should give you confidence. Keep them predictable. If you want the adrenaline rush of gambling, go to Vegas. I hear it’s lovely this time of year.

Beauty And The Beast

I was recently interviewed for a new contract. One of the questions I was asked was this: which would I say was more important: beautiful code or a good, polished UX.

I found it to be a very important question. Paraphrasing, this was my answer:

Beauty is in the eye of the beholder. We should first define what beautiful code is. For me, beautiful code is clean code. It’s maintainable code. It’s easy to understand. It has good test coverage.

And so, I would argue beautiful code is more important.

The reason is quite simple: with clean code, introducing new features becomes easy. You are less likely to introduce regressions. Fixing bugs becomes easier, too.

This all translates to a better product for the end user. And so, by prioritising beautiful code, you gained both goals: beautiful code AND a better UX. Consistently.

The opposite is not true: if you prioritise UX and knowingly neglect code quality, you will soon realise you’ve made a mistake.

Adding features would become a daunting task. New bugs would frequently occur. Fixing new and existing bugs will become a nightmare. The product will become a scary beast.

Eventually, the user experience would suffer. You will end up losing both goals.

And so, my choice would always be to go with beautiful code. I’d rather not meet the beast.