Reuel's blog

Advice I would like to give to my beginner self as a programmer

This year (2023), I reached the milestone of 10 years as someone who writes code for a living.

As an important milestone, I decided to reflect on the journey and list some advice I would have given my younger self 10 years ago. These are personal thoughts that I would have liked to have heard at that point in time and which would probably have got me to a more advanced stage by now. Some may sound harsh, but they would be good to have heard them from the beginning. Some I already knew (but I'd like to reinforce them anyway), and some I didn't.

Advice 0 - Filter the content you consume (including this one)

In the past, before the internet, one of the challenges was finding content to learn. Now that you are in the information age, the problem is that you have too much information, and probably most of it are not good. You're going to have to learn how to find the best content.

You may not have the experience to do this well at the moment. Start by looking at what the person you want to consume content from has achieved as a professional, and then decide if they are worth your attention and your time.

Advice 1 - The most important language you can learn is English

If you are not a native English speaker, you are already behind those who can consume knowledge in English. It's not because there isn't good content to consume in your language. It is because by knowing it, you are not limited by the content in your language, and because you now can communicate with almost all the world. By being exposed to better content (after filtering out the bad), they'll make you improve faster as a programmer.

It is a vicious (or virtuous?) cycle: More content in English leads to more people consuming content in English, which - guess what - leads to more content being produced in English.

Take documentation, for example. You're going to have to read a lot of it. Although many people work hard translating them, the process is challenging and error-prone. It is always better to go straight to the source. It will save you from a lot of headaches.

Don't fall into the trap of trying to be perfectly fluent. The main aim here is to understand and communicate ideas clearly. You'll make a few grammatical mistakes here and there, and sometimes won't know how to pronounce some words. Unless you're writing a scientific paper, you'll probably be fine.

Advice 2 - Don't start learning with JavaScript. You will regret it

Your first programming language is so crucial that you should be more careful when choosing it.

You are starting from a place where you know almost nothing about computers or programming. Your first language will be responsible for helping create in your mind your conceptual model of how computers work and how you approach them to solve problems.

JavaScript was designed to run in a browser. I know people will tell you that it even runs on a Tesla these days, but there are so many layers between your js code and the actual hardware that it can make you think that things work in a way they don't. Knowing only JavaScript and saying you understand computers is like saying you are close to an NBA star player when you only see him on TV.

Look for a compiled systems programming language, preferably with simple syntax. Golang (Go) may be a good option, but C is probably the best option (and people will call me crazy for saying this).

Advice 3 - Avoid web development if possible

You are just starting out, so everything will be new and exciting to you. You will learn about frontend, backend, databases, and lots more. But after some time, something will happen:

You'll realise that most projects aren't that different from each other. They're basically a bunch of forms that read some data to store in a database, and read data from there to display to the user. They can become so repetitive that I don't doubt web developers will all be replaced by AIs in just a few years.

In most cases, there won't be that many really challenging technical problems to solve, as they'll be more like business processes automated inside servers.

Do you know the worst? The tools will change so frequently that it will become a nightmare to keep track of all the changes and updates, and you will eventually give up on that.

There are more important problems to solve in other fields.

Advice 4 - Programming is not easy. Don't let anyone tell you otherwise

Programming well is a craft that takes years to learn, a lot of diligence, and a lot of practice.

You'll have to make a lot of mistakes to learn. You'll have to fix tons of bugs to avoid them in the future. You will become someone who can translate problems in the real world (or even in machines) into instructions for a fantastic dumb machine (the computer) to solve for you with its limitations. It takes time to do this well. And it is hard. It is not impossible, but hard.

Advice 5 - The beginning is hard, but it gets better

The bar to enter the market is getting higher and higher. You already have to learn a lot to get your first job. The good news is that once you are in, you will not have too many problems if you continue to learn relevant things. The learning combined with your experience will keep you employable throughout your career.

Advice 6 - The beginning is hard, but it only gets worse

But it is not all roses. In the beginning, you will not have many responsibilities, will not have to solve the most difficult challenges, and will probably have someone to look up to. Over time, if you want to grow in your career, you'll be required to solve even problems that get more challenging each time and without supervision, sometimes without a clear idea of what's going on. You'll probably also become the one who has to support others.

Advice 7 - Seek help

You'll never know everything. Accept that. You are probably not the most experienced programmer in your team, and your colleagues know that.

Of course, you should try to solve things on your own. But if it takes too long, don't hesitate to ask for help. It shows that you're doing your best to help while also showing that you don't want to slow down your team's progress.

If you have the chance, if a more experienced colleague is going to solve a problem that you find difficult, ask to join them (even if it is just as a listener). It shows that you want to improve. Every good team likes to have people who want to move forward.

Advice 8 - Write code over and over again

I like to think you are training to be an athlete of thought. At the end of the day, that's what you're doing: Using your intellect repeatedly to solve problems through a machine.

Soccer players study their movements and practice passes and kicks over and over. Basketball players watch their moves and practice free throws over and over again. Musicians train harmonies, scales, and music pieces and practise them repeteadely. You get the point.

It is about repertoire. The more problems you solve, the better you get at solving problems.

Advice 9 - Don't enter the tutorial hell

You'll find lots of tutorials for lots of things on the web. Don't make the mistake of just "saving it for later" somewhere and feeling like you've you made some progress. You haven't. That's just self-sabotage. Find one or two good resources on what you want to learn and only move on to the next when you have completed them. Real progress comes from practice.

Advice 10 - Programmers have strong opinions

This is something you should learn now to avoid some confusion in the future. Every programmer comes from a different place, from another background, and will have their own opinions about many things. The more experience you have, the higher the probability of disagreeing with other developers on specific topics.

Advice 11 - Agile methodologies can do more harm than good

The most important thing is to have a team of skilled people (both soft and hard skills). Without them, you're likely to have problems no matter what methodology or processes you have.

Advice 12 - The Agile Manifesto may have good ideas

Remember what I said about programmers having strong opinions? Well, the Agile Manifesto is almost everything the authors could agree on. Anyway, the values and principles can be good advice.

But be careful. You'll see a lot of companies out there claiming to be "agile" just by trying to implement "agile methodologies" and not being productive at all. You'll also find companies that don't use a specific methodology but can apply the values and principles very well to their reality.

This is so serious that even some of the authors say that "agile" is dead. You should learn something about this.

Advice 13 - Learn how to learn. It's your job

This is one of the most fundamental skills you will need to develop. Programming is a non-stop journey of studying and learning new things.

Try to learn a little of neuroscience and how the learning process occurs in your mind, and take advantage of that.

Advice 14 - Take more breaks. This will become increasingly difficult as your career progresses

As your career progresses, you will be given more responsibility. The more your project needs you (as a developer, a leader, or a manager), the harder it will be to switch off completely.

Advice 15 - That guy with 5 years of experience doesn't know much

When you see a colleague with around 5 years of experience, you should learn from that person. But don't follow blindly. When you reach this milestone, you will understand.

Of course, there are exceptions.

Advice 16 - That guy with 10 years of experience doesn't know much either

Same as above.

Again, there are exceptions.

Advice 17 - Try to do things the hard way sometimes

"You shouldn't reinvent the wheel" is a common phrase in the field. Depending on the context, it can be a good guideline.

But there is value in trying to do things the hard way sometimes. Some of the benefits are:

I've seen projects that had dependencies on huge libraries to use just one or two functions, and also projects which avoided that by putting in a little extra effort once and then not having to worry about version updates, security updates, or anything like that. It is good to have both approaches available in your toolkit.

For example, have you ever tried to implement a string split() function (without using your native split function, of course)? This is an excellent exercise. You should try it someday.

Advice 18 - Start thinking more about business.

Programming is (usually) a means to an end. Many of us go into this world to play with computers and make them obey our orders.

In reality, most of the time you are just using your skills to solve the problems of a business to keep the money coming in. It means your time will be spent fixing bugs or implementing not-so-demanding features.

So, don't fall into the trap of only caring about the technology by the technology itself. First try to really understand the problem you are trying to solve and then think about the optimal solution and choosing the right tool for it. If you don't understand the problem well, do some experiments to gain that knowledge and then go back and write a good solution.

Advice 19 - Computers are not slow. Your code that is not good

Imagine a simple and fake CPU with one core running at 1GHz that can't execute instructions in parallel. This means that it runs 1 billion cycles per second.

Suppose that a very slow instruction takes 1 million cycles to complete its execution. That means 1000 executions of that slow instruction per second. Is your computer really slow?

Advice 20 - Learn the fundamentals

Learn about data structures and algorithms. Try to learn something about CPUs, memory, and operating systems. You may not always use this knowledge directly, but it will help you solve problems in ways that other people cannot see. More than that, you will eventually need it explicitly, and it will make a huge difference. Trust me.

Advice 21 - Maybe you don't have Impostor Syndrome. Maybe you really are an impostor

There are at least two possibilities here. The first one is that you've set the bar is so high that you can't reach it. The second one is that you have not done anything relevant. The best way I can think of to combat this feeling is to do a frequent reality check. Write down the problems that had a positive impact and were challenging for you to solve at the time.

If you have things on your list that are getting harder and harder, you're on the right track. You may think you're not good enough, but at least your thinking will shift from "I'm a fraud" to "I don't think I'm good, but I've done some good things." Keep pushing.

If you feel like a fraud even doing that, consider seeking professional help.

On the other hand, if you don't have much on your list, well...

Advice 22 - Learn C

This is probably one of the most important advice I can give you.

C has a simple syntax, so it don't need to take too long to learn and make your first programs. This means that you will spend less time fighting the language and more time solving real problems.

But don't be fooled: becoming a master in it will take time and effort. C gives you almost nothing: no strings, lists, dictionaries, or hash tables. You'll have to implement them by yourself or use a library made by someone else. On the other hand it will give you almost total power to do whatever you want with your program.

Other languages try to prevent you from making mistakes. C assumes that you know what you are doing. And that's the point.

You will screw things up: You'll have segfaults, undefined behaviour, you'll try to access memory you shouldn't, off-by-one errors, memory leaks, and all this will make you a more disciplined and safer programmer. And you will take that to every other language you work with.

And as a final bonus, if you can do something in C, you can (probably) can do it in any other language.

Advice 23 - The OOP they taught you is not real OOP

If you've ever used get() or set() you're already doing it wrong. Strange as it may seem, OOP is not about objects, it is about messaging.

The general idea is that objects are entities that can send and react to messages with specific behaviours. They are like the cells in a living body with their own complex behaviour (encapsulation) that communicate with each other through the bloodstream.

The internet can be used as a good example of an OO system (devices are the objects, packets are the messages).

After trying to really understand it, I either can't understand it at all, or I understand it well enough to think that it's not a good approach to software development and we should stop pretending it's something it's not.

To understand more, you can watch Alan Kay's talk about that.

Advice 24 - Polymorphism is not exclusive to OOP

Polymorphism is the idea that you can change the behavior of a program without changing its API (basically the functions you call). But, contrary to what many might say, this is not exclusive to "OOP" languages.

You can do it with header files in C, where all you have to do is change the .c file that implements the function signatures. You can think of this as compile-time polymorphism. You want runtime polymorphism? Okay, just use function pointers.

Advice 25 - Programs are data + operations

CPUs are components that have operations implemented in hardware, and those operations transform data from one format to another format. That's it. "Objects" don't exist, structures don't exist, and even variables don't exist. They are just abstractions.

Abstractions can be very powerful and very useful. But if you only know abstractions, you will never be able to get the computer to do what it does best: process and transform data. Make your abstractions take advantage of that.

Advice 26 - The university will not make much difference in your knowledge*

You could have dropped out earlier, or gone into something more relevant like mathematics or statistics.

For the most part, you are on your own. At most, you'll make a few good friends.

On the one hand, being on your own has some advantages: It's a skill you'll need to develop anyway for your career as a programmer. On the other hand, no one at the university will prepare you for it. Maybe there are some real professors there, but most of them are just idiots with PhDs.

Guess what: You can learn on your own in the comfort of your own home, and also meet some people on the Internet. Just make sure you develop some discipline and don't be mediocre.

Advice 27 - Most degrees and bootcamps will not teach you anything about computers

What they want is to make money by teaching you the most trendy frameworks and basic concepts that are required in the open job positions in the market, but even that knowledge will not be deep enough for you to do a good job. Learning takes time and effort.

Advice 28 - Computers are your instrument of work. You better understand it well

Would you trust a doctor or physiotherapist who didn't understand anatomy? Would you enter a building designed by a civil engineer who didn't know the foundations of how to plan safe buildings? An airplane pilot without a license? Why should anyone trust you to implement their systems if you don't understand your tool well?

Advice 29 - Your tools will break. Be prepared to fix them

All the most popular libraries and frameworks out there will tell you wonders and try to use a lot of hooks (pun intended) to convince you that they can solve all your projects' problems. That's simply not true. This is not because they are bad (although I think most of them are), but because there is no way the developers can anticipate all the problems their adopters will have to solve, and they will also try to provide a lot of features to reach the maximum number of adopters, which can also mean that you will have a bloated software from the get-go and not use everything it can provide.

It also means that they will break sooner or later. You can be sure that there will come a time when you have a problem so specific to your project that the framework will not solve it for you, and you will not find a solution on StackOverflow (or ChatGPT, or whatever). And that is when you will learn what it means to fight your tools and frameworks.

Try to develop the ability to identify the good tools and choose the ones that will not get in your way.

Advice 30 - Seek opposing views

Following up on the previous advice and expanding on more general landscape, everything (tools, languages, frameworks, processes, architectures, patterns, the list goes on...) has its pros and cons. Don't ignore that.

Every time you are interested in something, try to find an argument of why you should not use it. You will learn from mistakes of other people. You may learn more about the tool than just looking for good reviews and tutorials. After that, you will have a better background for your decisions.

You can do searches like:

And avoid AI for that. Look for real people's experiences.

Advice 31 - There is ALWAYS a trade-off

You always pay a price for all your decisions. The problem is that most of the time we are not aware of this reality.

Make sure you have a notion of the prices you are going to pay and learn to choose them wisely.

Advice 32 - Level up your communication skills.

If you want to become a programmer so you don't have to talk to people, you either need to learn it or you better work on your own stuff (alone).

I have seen projects go really wrong and getting way more expensive and problematic than they should have been just because people were unable to communicate, explain, and understand what had to be done.

If you can't explain to a 5-year-old what needs to be done, you probably don't understand the problem very well. Listen (or read) carefully and try to understand the problem to the point where you can explain it to another person without much problem. When someone tells you to do something, repeat it as you understood and correct what is wrong. Ask questions. Make suggestions. Try to anticipate problems. Give options. If possible do this before starting any activity. You will avoid more problems than you can even imagine.

Advice 33 - Comparison is only bad if you choose the wrong people to compare yourself to

This does not mean that you should choose someone as your role model and try to mimic everything that person does. Not only is that unrealistic and unhealthy, you also playing with a high chance of disappointment.

What you should do instead is try to understand what the person does better than you, and how you could incorporate some of those disciplines and habits into your own life.

Advice 34 - Don't run away from hard problems

Companies will only hire you to solve the problems they cannot solve themselves. If you can't, what's the point of hiring you in the first place?

I'm not saying that you should try to create a spaceship when you barely know how to commit a file in Git (at least not early in your career). But you should definitely not run away the challenges that will force you to make some effort to learn something you have never done before. You should go after them. You are a problem solver.

Not too hard, which can be frustrating, not too easy, which just wastes your time.

Advice 35 - You don't want to be a junior

The market today is very hard for those trying to enter the field. And it will probably get harder with the growth of AI.

Look, I'm not saying this to discourage you. But the rules of the game are simple: Companies need money to operate. They need to spend their money on people who they are confident will generate more money for the company than the company invests in them. From the company's point of view, this is an investment. These are not usually juniors.

Your goal should not be to find a job as a junior programmer. Although it is a stage everyone has to go through, your goal should be to answer the question: "How can I grow past the junior phase as soon as possible?". "What can I do that can provide real value to companies?"

Programmers are already expensive, and usually companies have to pay more to keep you than just your monthly salary (e.g. benefits and taxes). How can you show that you're worth the investment and that you'll generate more than what they have to spend on you? Think about it.

Don't take this personally, but nobody really cares about your to-do app or your Netflix UI clone. Those problems have already been solved. If the companies needed to solve the problem you learned about in a tutorial, they would get the solution from the tutorial in the first place, not from you. Show something different. It doesn't have to be a herculean problem, but at least show that you can solve more substantial problems.

Advice 36 - Recruiters are not your enemy (mostly)

As I said in the previous advice, programmers are expensive, mainly because they are in short supply. There are a lot of open job positions and not enough qualified people to fill the gaps.

During a selection process, recruiters and agencies want most of all to find someone who is a good fit for the job, because that means they will also benefit (in terms of reputation and commission, or simply by saving time to attend to the company's needs). Many of them also get a sense of fulfilment from helping someone progress in their career.

But, they just can't let everyone in. As it also involves reputation, if they let an unqualified person pass the processes and the person doesn't do well in the job, it can backfire on them.

Look, interviews are complicated for both sides. It is so complex that there is no consensus of what the perfect process for an interview is.

Some companies have many phases of interviews: Cultural fit, technical assessment, technical challenges of days, talk with CTO/CEO, talk with HR, and so on. That is stressful, expensive for the company, and tiring for both recruiters and candidates. Many candidates complain about this mainly because you can reach the final phases by making a lot of effort and not passing in the end.

On the other side, some companies have short interview processes. A little talk here and there, basic technical assessments, and that's all. The problem with this is that it is so little time to know someone and know if they are the right person. Worse than interviewing someone is hiring the wrong person. That's a disaster.

Look for recruiter tips, learn about the company you are applying for, prepare some questions, practice the answers to some common questions, and go for it.

But...

Advice 37 - Don't lie on your resume or in interviews

Recruiters are professionals. They have a lot of experience or a background in psychology (or both). Unless you are an Oscar winner, it is extremely easy for an interviewer to know when you are trying to cheat and deceive them.

They will find out if you lied on your resume or you are trying to lie during the interview. Just a follow-up question about what you said you knew, and it is game over for you. Either way, you demonstrate that you are not a trustworthy person.

If you don't know something, don't try to act as if you knew. Just say "I don't know".

If you know something partially, say something like: "I've never used this in a large project, but what I know is X, Z and Y" (in a summarised way).

There is no guarantee that you will get the job, but this will demonstrate that you can acknowledge the gaps in your knowledge. It will also show that you respect the recruiters' time and treat them as professionals.

Advice 38 - Always give your best

Always give your best in your job. That doesn't mean you have to work 40 hours a day. It also doesn't mean your best will be the same everyday. It won't.

Always giving your best means that you should strive to reach the end of the day with the following thought: "I did all I could possibly do today." Some days it will be a 3-line bug fix. In another, it will be all your working hours (and some extra hours) helping the team discover a bug in production that is stopping the service for strategic customers.

Your efforts will pay off sooner or later. You'll earn the trust of your team and managers (and you should take care of that), and they'll know that you are someone they can count on. That will turn into promotions, more responsibility, more challenges, and so on.

If you are not up to give your best, you should move on. You are doing a disservice to your current company and your current colleagues.

If your company doesn't value what you're bringing to them and they are only taking advantage of your hard work, it is also time to move on. Now you'll have some experience solving problems that you can tell on the interview for your next company.

Advice 39 - Your health is more important than your career

I know you have bills to pay. But if you try too hard, you will have to pay for the medicine too.

Do exercises, have hobbies, talk with friends, all of that good stuff you should already be doing. They will keep you sane.

But...

Advice 40 - Learn to make some sacrifices

Nothing comes for free. There is no easy path to progress in life. The good part is that you will value your achievements more when you reach them.

Also, don't try to rush things. This may seem contradictory to the advice that you don't want to be a junior, but it is not. The idea here is to develop yourself and work towards your goals with discipline. Time flies. When you least expect it, you will reach your 10-year career milestone like I did.

That's it. I hope the guy 10 years from now will have something valuable to tell for both of us.