Kev's Development Toolbox

Frontend dev gets a lot of traffic in software development online communities where new developers are just getting started. That’s understandable, since if you have a computer with a web browser, you only need a text editor of some kind and you’ve got all you need to start writing and running code. It’s arguably the most accessible area of software development to get started with.

The fact is though that the majority of software development is not web dev, and most is not even backend apis to support frontend apps either. If you think about the electronic devices that fill our lives nowadays, our phones, tablets, watches, laptops, even household appliances like clothes washers, microwave ovens, all these devices run software. Modern cars have multiple systems that are comprised of millions of lines code. And this is not even thinking about the business systems that are behind the curtain and invisible to most people, financial and accounting systems, payroll processing, all quietly running 24/7

There is no golden rule that says you should start your career by learning frontend dev first and then moving into other areas. Pursue what is interesting to you. Over their careers some developers may move back and forth between roles, some may only ever work on backemd dev and never write a line of HTML Find what interests you and go for it!

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.