8 Things I Wish I Knew When I Started Programming

I don’t have a time machine, but you can learn from my mistakes!

Paul Hudson June 17th 2022 @twostraws

I've been programming for over 25 years now, and today I love it just as much if not more than when I started. But looking back on me as a kid just starting out, I really had no idea what I was doing, so if I were able to build a time machine today there are eight things I would tell a younger version of myself.

Obviously I don’t have a time machine, but that’s okay because you’re here, and if you’re just starting out with your programming career I can guarantee these things will prove useful to you too.

Before I start, I want to say the most important thing of all: young me was extremely impatient – I always, always wanted to jump ahead onto the next thing, without really taking the time to listen to advice. This caused huge problems in the first 10 years of my career, so if you’re already thinking “I’m bored already – I need to jump over to TikTok to watch some comedy fail videos,” maybe you’re on that same track. Trust me, it doesn’t end well.

Okay, you’re still here, so I guess that’s the first test passed!

So let’s get right into it – you can watch the video below, or keep on scrolling for the text version.

Sponsor Hacking with Swift and reach the world's largest Swift community!

1. Technology will change – don’t get stuck on stuff!

Seriously, no matter how much you love Thing X or language Y, it will evolve or go away entirely. I learned Java and C++ at college, I did PHP, JavaScript, and Visual Basic after graduating, then wrote software for Windows Mobile and Xbox 360, built iPhone apps using Objective-C, and more, and almost all those technologies have evolved beyond recognition or are more or less dead now.

And that’s okay – in fact, it’s kind of how our industry works. But it means I cringe super hard when I see language fanatics who insist JavaScript is the worst, or equally those who think JavaScript can do everything under the sun. There really is a reason there are lots of languages out there, and it isn’t because there are a whole bunch of bored language designers.

“I cringe super hard when I see language fanatics who insist JavaScript is the worst, or equally those who think JavaScript can do everything under the sun.”

So, take the time to experience a handful of languages or frameworks. Maybe that’s JavaScript, Python, and Swift, or C++, TypeScript, and Rust; it doesn’t really matter what you choose, because you can learn something from each of them. Each language does some things well and other things less well, but by gaining experience across several you’ll start to understand the advantages and disadvantages more clearly.

Even better, you’ll start to see how most of the core concepts we use as programmers don’t change: they don’t change across language, and they don’t really change across time either. Sure, some techniques like functional programming might go in or out of fashion from time to time, but there are hundreds of computing fundamentals I learned 20 years ago that are still just as valid today.

2. You won’t remember everything, so don’t try to

I don’t know what possessed me to think this, but I wasted a huge number of hours trying to memorize vast swathes of terminology, pieces of code, language structure, and more. I used to pore over tutorials in great detail, often completing the same one more than once just to make sure it “really sank in”, but then worry when the next day I couldn’t remember a particular code snippet and had to look it up again.

Here’s how it works:

If you learn something, chances are you will forget it quickly because there are a million other things to learn and they all take up space in your head.
When you try to use something you’ve forgotten, you’ll be forced to look it up again and relearn it – but in doing so you’ll actually force that knowledge into your brain a little deeper, making it easier to remember next time.
Eventually, the things that really matter – the things you use every week or even every day – have been forgotten and relearned so many times that they actually stick, because your brain has committed them fully to long-term memory.

There’s a phrase I use for this: “there is no learning without struggle” – when you really have to fight to understand something, it will stick in your head for a long time.

“If you learn something, chances are you will forget it quickly because there are a million other things to learn and they all take up space in your head.”

Everything else you can and will look up. Seriously, your Google skills will evolve dramatically – you might not remember the exact code to use, but you will remember the concepts and terminology that help you find the right answer quickly, and hopefully once you find a solution you can adapt it to fit your needs.

3. You don’t need a CS degree… but you will really benefit from some CS knowledge

First, for full disclosure I should say that I have a computer science degree, and for the most part it wasn’t helpful for me – I was already programming for several years before I went to college, so when they started teaching introductory programming I just kind of zoned out. Worse, I had studied computer science at high school, so I was already familiar with various data structures and algorithms. So, for me getting a computer science degree was more about being certified to some artificial standard, which when I was getting my first job mattered a lot more than it does today.

However, if you haven’t done that – if you haven’t really studied computer science at all – I do think it’s worth taking the time to cover all the basics so you avoid mistakes in the future. I don’t mean “what are variables?” because that’s more about learning a programming language, but instead it’s things like:

“I don’t want you to lose hours of your life wondering why your task is so hard when it’s already been solved a dozen times over.”

Common data structures: arrays, sets, dictionaries, stacks, and trees. You’ll might also think linked lists are important, but trust me: linked lists are used extremely rarely.
Common algorithms: binary search, sorting using quick sort, merge sort, and even bubble sort, or path finding using something like A. I don’t mean you need to be able to write a sort algorithm yourself, because honestly that’s something you’ll almost certainly never do apart from really annoying companies who think that makes a good job interview, but it’s really helpful to at least know how searching and sorting works* – the actual underlying concepts that happen.
Common techniques such as modulus, affine transforms, or creating hashes.
Common tools such as source control, basic command-line programs, and even some regular expressions.

You don’t need to be an expert at these things, I just don’t want you to lose hours of your life wondering why your task is so hard when it’s already been solved a dozen times over. If you know that these exist – if you at least understand them as concepts if not fully in practice – you’ll find they will serve you well for years to come.

4. You will always be learning

You might think this is a downside, but honestly constant learning is half the reason our job is so much fun: every year – sometimes every month! – something amazing happens in our industry, and you need to keep upgrading your skillset to stay on top of it all. It’s hugely exciting, and it’s important you learn to embrace this constant evolution rather than getting stuck in your ways because right now you think Language X is the best thing ever.

And what I’ve found time and time again is that nothing I’ve learned has ever been wasted – old ideas I had or code I wrote have come back to be useful time and time again. Sure, sometimes I’ve needed to rewrite the code using a different language or framework, but all the logic and concepts haven’t changed and are just as applicable today as they were when I first wrote them down.

“It’s important you learn to embrace this constant evolution rather than getting stuck in your ways because right now you think Language X is the best thing ever.”

So, if you spent six months experimenting in Python but ended up choosing C#, that’s okay – all that Python work will be useful for years to come, either because you’re able to transfer concepts more easily to C# and beyond, or because you can translate the code across to other languages, or because it just gave you extra experience with core programming fundamentals that work everywhere.

5. You should learn how to learn

It’s really important to spend some time figuring out what great learning looks like, because once you do that you’ll be much more effective for years to come. This is quite a big topic, so I’m going to break it down into some smaller tips.

First, everyone learns differently, and that’s okay. If you learn by watching videos, great. If you learn by reading books, awesome. If you learn by making stuff, cool – everyone learns differently.

Honestly, I think that’s self evident, but for some reason other people really struggle with this – when someone says “I’m learning how to code, what tips do you have?” they just jump in with an answer like “don’t read tutorials, just start coding!” And that advice is awesome – but only for folks who happen to learn best in that style, which is a surprisingly small proportion of people.

Learning to program is no different from learning a spoken language: most people learn best by copying others first, then learning to branch out. This means we need to see a heck of a lot of code before we’re confident building our own stuff. In fact, the most modern method of teaching code is called PRIMM: Predict, Run, Investigate, Modify, Make.

“Time and time again you will find folks who insist the One True Way to learn just happens to be the one way that works for them.”

This means you get shown some code and have to figure out what it might do when run. You then run the code to see if it matches your prediction, then investigate the code to see what it actually does in detail – you watch how values are created, modified, and used, or you add comments to the code explaining what it does. Once that’s done you modify the code: you make small changes to make it behave differently, slowly giving you more control over what it does. And then finally – only after the other steps – do you try to create something similar from scratch.

So, everyone learns differently – I know it sounds obvious, but time and time again you will find folks who insist the One True Way to learn just happens to be the one way that works for them. If you find that same way works great for you then you’re all set, but if you find yourself getting discouraged then try a different approach because clearly you learn differently!

Second, you need to actually spend time learning new things, and separately spend time applying what you learned. Sometimes folks spend get stuck in one of those two buckets, and it causes problems: folks who complete one tutorial then reach for another, then another, then another never really get around to applying what they learned, and there are also folks who spend all their time making and not enough time listening to new ideas, techniques, and approaches that others have developed.

I make a whole range of books teaching people how to program, and sometimes folks come in and say “I’ve just bought all your books – where do I start?” To be clear, I’ve published over 15 books to date, and these people just buy them all. Obviously I’m very grateful for their support, but at the same time I’ve seen too many people who are keen to spend money without actually putting in the time to use what they bought.

It’s like folks who join a gym and feel like that makes them healthier without actually going to the gym, or folks who have 100 untouched games in their Steam library but still want to buy more in the next sale – just buying tutorials isn’t enough. You’ve got to sit down and read them, and more importantly you’ve got to sit down and apply what you learned: try modifying whatever project you built somehow, or try making a wholly different thing using the same concepts or frameworks.

But on the flip side, as much as I love writing code, it’s really important I still make time to learn something new – I certainly don’t have all the ideas, so by reading books or articles, or watching videos, or attending conferences I get to see all the other incredible things other folks are coming up with, and they keep pushing me forward.

“As much as I love writing code, it’s really important I still make time to learn something new.”

Third, never be afraid to write bad code while you’re learning. Sure, you might not want to ship it, but often the only way to write good code is to write a heck of a lot of bad code first. You need room to experiment, to screw up, and to improve, so don’t sit there staring at a blank editor window – write the simplest solution to the problem you’re facing then improve on it, and you’ll learn a lot faster.

And the last mini tip for learning is that you need to feel comfortable asking questions – you need to feel comfortable saying “I don’t know.” This is particularly important in interviews, where it’s common to see folks trying to bluff their way through questions rather than just saying “I don’t know… but I’d love to learn.” Honestly, memorize that one answer and companies will be much more impressed by your interview performance – they can’t expect you to know every technology they are looking for, but they can expect someone who is excited to learn and happy to be taught.

Okay, enough about learning to learn, because I think you get the point: finding an approach that works for you, carving out specific time to learn and apply new things, write bad code again and again until you get good code, then find a place where you can ask questions, and you’ll be so much happier.

6. A little bit of mathematics goes a long way

This might sound controversial at first, but you don’t need to be great at math to be a programmer – you don’t need to be a star mathematician who can recreate complex equations from memory. However, some topics will come up time and time again, and at least having some understanding of those will help you. For example, I can't from memory write code to calculate the cosine of a number, but I know most languages a built-in cosine function, I know what it does and when to use it, and it’s been immeasurably helpful for things like smooth animations, physics calculations, and so much more.

“I do wish past me spent a little less time doodling in math class and more time grasping fundamentals such as discrete mathematics.”

I remember the first time I created a simple 3D game, I was trying to calculate the player’s movement in space using Pythagoras’s theorem – another piece of mathematics you’ll use a lot. Put bluntly, I was way off base because that was completely the wrong choice for handling 3D movement, and it took someone else to give me a kick and say “hey, you should be using matrix multiplication” for me to make any progress, and that extra knowledge has served me well in so many other places.

If you choose to specialize in particular areas of computer science, you’ll find you need to specialize in relevant areas of mathematics too – linear algebra becomes much more applicable if you start getting into machine learning, for example.

So, like some other things on this list, you don’t need to be an expert at mathematics, but I do wish past me spent a little less time doodling in math class and more time grasping fundamentals such as discrete mathematics – even understanding things like logic gates or basic graph theory can help you visualize how more complex code works.

7. You need resilience to be a good programmer

Initially you need resilience because you're learning a new language, and that’s tough – we set a lot of pressure on ourselves to be able to write code quickly, but if you were learning a language such as French you wouldn’t expect to be able to speak it smoothly after seven days, or even seven weeks.

But even once you’re past the learning stages, about once a month you'll hit a bug so bad or a problem so big you'll think you made the wrong career choice, and that you’re just not cut out for this coding thing. This is a bit like impostor syndrome, where you feel like everyone else would totally understand what’s going on, but you’re just not good enough. Usually what happens is that you fix the problem – which will sometimes be as simple as adding a single semi-colon, or flipping a plus sign to a minus – and suddenly all is right in the world again, and you’re back to thinking coding is awesome.

“About once a month you'll hit a bug so bad or a problem so big you'll think you made the wrong career choice.”

Along the way you’re going to pick up a huge range of debugging skills, including break points, watch points, logging, and more, but you will never – never – stop using the one you learned first, which is inserting a dozen print statements saying “HELLO” or “MADE IT HERE”, and that’s okay. It works!

8. Our job is about way more than code

Yeah, I know when you graduate it’s common to walk into what is sometimes called a “code monkey” job, where you effectively write code most of it not all of the day, but that phase doesn’t last as long as you might think – your job will involve emailing, standups, 1-to-1 meetings, issue triaging, reviewing code from others, resolving merge conflicts, and so much more.

So, take the time to learn how to work well with others, and build relationships. Believe it or not, it’s relatively easy for a company to teach a new hire how to code, but it’s much harder to teach someone how not to be a jerk. Spend some time connecting with others at meetups or conferences, build a solid network on social media such as Twitter, and when you can you should take the time to encourage and support others around you – teaching others is a great way to be sure you’ve truly learned a topic.

“It’s relatively easy for a company to teach a new hire how to code, but it’s much harder to teach someone how not to be a jerk.”

Sometimes we call these “soft skills,” but after so many years working I think that name doesn’t remotely fit – these skills aren’t easy! But they do matter, and you can always work to improve them.

One bonus tip!

To sum up, if I could go back 25 years and teach past me some things that would make my life dramatically easier, they would be:

Technology will change, so don’t get stuck on one language or framework.
You won’t remember everything you learn, or even 10% of it.
You don’t need a computer science degree, but you do need some computer science knowledge.
You’ll always be learning, and if you embrace that you’ll be happier.
You need to learn how to learn effectively.
A little bit of mathematics goes a long way.
You need a ton of resilience to fight through the problems you’ll face.
Our job is about way more than code.

You made it this far, so here’s one bonus tip for you: get yourself a mechanical keyboard. You can thank me later!

So, those are the eight things I would tell past me if I could. If you’ve been programming for a while, what would you tell your past self if you could? Let me know on Twitter!

Sponsor Hacking with Swift and reach the world's largest Swift community!