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.
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.
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.
All too often I see questions online from new developers about how they can progress from ‘tutorial hell’ or feeling that they’re not making any progress beyond a certain point. Programming languages are just tools. A programming language to a developer is the same as a hammer to a carpenter. You don’t learn how to use a hammer, you learn how to frame a house.
Beyond the few hours of learning basic concepts and syntax you should move straight to actually writing something, start with ‘Hello World’ and go from there. As you continue from that initial starting point, every new thing you read/watch/listen to should be followed by additional hours of putting it into practice. The real learning is when you write some code and run into issue and have to work out what the issue is and how to get beyond that point.
Here’s a useful insight that eventually you will discover: as you progress through your career and develop more experience, you’ll soon find out that the process of developing software is about trying something out, finding it doesn’t work, then working out how to make it work. There seems to be a misconception that becoming a better developer means you will be able magically flow code from your finger tips, but that’s not how it works. It’s an incremental process, you write some code, it doesn’t work, you work out how to fix it and you continue. The sooner you realize this and accept it I thinks to avoid some of the frustration from believing that being ‘better’ means something different.