Think before you build

This should not be a surprise to any experience developer, but for new developers just starting out there is a tendency to sit down at your computer and just coding coding. Shortly following this, there are complaints that programming is hard, and why when they sit at their computer to they get a mental block and don’t know how to solve a problem?

The majority of time and effort in software development is about understanding a problem and then thinking ow ways to solve that problem. It’s not about sitting at a keyboard and typing code.Actually typing code at your computer is probably the smallest part of total time spent solving a problem.

If you find yourself sitting at your computing and wondering why you can’t solve a problem, take a step back and think about the problem first, and spend some time thinking of suitable approaches for how you can solve the problem.

When should you optimize your code?

Once new developers get beyond the basics, there is a tendency to start looking for ‘clever’ solutions to problems, or worrying about whether solution A is faster than solution B.

Unless you know you have a performance problem with a solution now, or have a design constraint where you know you need to account for a performance goal and ensure your approach will meet that goal, then you’re worry about problems you don’t have.

Spend time worrying about whether your code is easily to read and understand. Worry about performance problems when you understand what performance problem you have.

Donald Knuth is famously quoted as saying “premature optimization is the root of all evil” – meaning, don’t spend time optimizing for problems you don’t have. In his paper “Structured Programming with goto Statements”, the full quote where this well known expression originated has more context:

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%”

When you know you have performance issues then spend time to address them, otherwise, focus on making sure your solution works, and that your code is easy to maintain in the future.

Do you dread a programming language?

I came across this question online a while back ‘what programming language do you dread the most’ and thought it was interesting why a software developer would ask this question. More surprisingly, many answers from other developers shared what languages the dread and why.

Programming languages are just tools we use to do our job, which is primarily solving problems and building solutions to problems. We use programming languages are tools to achieve this end goal. To say you dread a particular programming language would be like a carpenter saying they dread using a hammer. There may be languages you like or prefer more over others, but to dread or fear a particular language is, to me, unusual.

Let’s say you do fear a particular language. What can you do overcome that fear? Often fear is from the unknown. If you’re less familiar with a particular language then spend some time getting more familiar with that language. Languages that you are more comfortable with are more likely the ones you’re more familiar with. If you’re in a position where you can make a tool decision and chose the language you’re more familiar with avoiding the one you fear, then that’s an easy solution, but at some point you may not be able to make such a decision, so invest time to get more familiar with the languages you’re less familiar with.

MacOS curl error: “zsh: no matches found”

I’ve seen this error before with MacOS’s zsh and I can never remember what the issue is:

> curl https://localhost:8080/example?email=test
zsh: no matches found: https://localhost:8080/example?email=test

You can get this error with multiple different commands for the same reason. The ‘?’ in the param to curl is interpreted as a substitution wildcard character. To avoid the issue, either escape the ? as \? or just wrap the whole url in double quotes.