Getting started in software development: the majority of software development is not web development

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!

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.

Software development is about building solutions to problems, not memorizing language syntax

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 problems 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.