I was getting errors from Certbot

invalid response from .well-known/acme-challenge

It took a lot of messing around but the problem lay with a Cloudflare setting.

SSL/TLS -> Edge Certificates -> Always Use HTTPS

Redirect all requests with scheme “http” to “https”. This applies to all http requests to the zone.

Certbot requests the verification over HTTP, as Cloudflare was rewriting it to HTTPs, it wouldn’t come through to where it had set up the temporary server in the Nginx plugin to serve the acme-challenge.

Businesses are usually around for longer than individual employees’ tenures. At some point, someone else has to take over your workload.

If you have an owner mindset rather than a custodian mindset this is difficult. Handovers are not easy. Trying to cover all bases and think of everything you might need to get from someone during their notice period is going to result in at least some of their knowledge being lost.

Framework choices can be critical. The wrong choice is going to cause a big increase in the amount of technical debt a project has and can harm the onboarding process for new employees, which already carries a high opportunity cost.

Problematic choices:

• Flavour of the month
• Too dated
• Custom

All of the above carry a high chance that you won’t be able to find a new hire that knows the technology involved. Obviously with a custom framework it would be impossible! All you can do if that’s what you have is hire someone with a solid and varied background and strong knowledge of the fundamentals of software engineering.

Opportunity costs are so often missed in a myriad of different areas.

For software engineering we of course have them too.

If you’ve not read The Mythical Man Month, you may have at least heard its central premise:

Adding resources to a late software project makes it later

Or perhaps more likely:

9 women can’t make a baby in 1 month

When a resource is added to a project, someone from the existing team needs to take the new person under their wing and help them get up to speed. That person could be doing something else instead that more directly adds value: this is an opportunity cost. That cost is excluding the time cost due to extra lines of communication that the aforementioned book primarily focuses on.

I’ve seen some criticism of Git recently, on Twitter, with a ton of likes, suggesting a large amount of people have a difficult time using Git.

Git is not that hard.

It really isn’t.

I think the problem stems from two main approaches.

### Problem the first: Shying away from the command line

The command line reveals all but can be daunting for the beginner. I’d come from TortoiseSVN and then Kiln’s Mercurial equivalent before starting down the git-path. I wanted a visual too. Gitk was dire, but gitg is excellent. You can run gitg from the command line from a repo directory and it’ll launch straight away and give you the nice familiar graph so you can see what’s happening. Despite using the command line most of the time I still use gitg alongside it constantly. There’s no substitute for the clear visual. I have an alias for git log that paints a pretty OK to follow graph into the terminal but you can’t beat that full UI.