Tag: software development

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.

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.

New developers starting out with little to no hands on/real world experience are often encouraged to build a portfolio of personal projects that they can share with a prospective new employer. It’s a great idea too, as a technical interviewer if I’m interviewing a new developer with no experience, an example project that they share online can give a useful insight into how they build a solution to a problem, and demonstrates that they’ve at least had some hands-on experience, even if it is with a personal project.

A question that is always asked in online new developer communities, is ‘can anyone recommend some good ideas for a personal portfolio project?’. This is missing the point and the purpose of a personal project. It’s not to show you have a good idea for a project, it’s to show you can develop code in a professional way that would be comparable to other developers on a team you are applying to join.

It’s really doesn’t matter what the project is or what it does. Build anything that can demonstrate you can write code that’s easy to read, is well structured, is not overly complex, and has good unit tests. It doesn’t matter what it is. As a technical interviewer if you show me a link to a portfolio (Github or anywhere else), I’m going to quickly browse the code to get an idea if you can write code that would be acceptable to my team (meaning, meeting the above criteria).

There seems to be a misunderstanding with some new devs that if you have an awesome idea for a portfolio project that will impress an interviewer, but it really does not matter what it is or what it does. Focus on developing clean code with good unit tests and that will be far more impressive to your interviewer than the project itself.

When you are first starting out to learn a programming language and software development, it’s easy to get stuck in a rut with tutorials and watching videos etc. While it’s essential that you learn the basic constructs of any programming language, the real learning comes from trying it out and actually building something.

What should you build? This is a common question online, you often see new devs asking ‘what are some good ideas for building a personal project?’. It doesn’t matter what it is or what it does, just build something. As you build an app (e.g. a web app with a backend db), you’ll run into areas that you don’t know how to do yet, so use that as a jumping off point to grow skills in that area. Rinse and repeat.

Starting out you’ll find it will be slow going because there’s too many things you haven’t had to do yet (how do you package and deploy your app, if you need to deploy your app to a server, how do you install and configure the server, or how do you deploy to the cloud?), but you’ll work it out and grow your skills in the process.

As you get more experienced, you can pick projects to work with a specific skill or technology area to grow skills in that area, for example to grow skills working with a specific nosql database or anything new tech that you want to gain some experience with.

In the process of actually building something, you’ll find you’ll learn far more that just watching an online tutorial. Try it and see!