30 Programming Truths I know at 30 that I Wish I Knew at 20

I'm 33 years old at the time of recording this, and I've worked as a developer for over 12 years in various roles with a variety of brands and businesses. Here are 30 programming truths I know at 30 that I wish I knew at 20. Number one: watch out for long chain dependencies. That meme about modules being the heaviest objects in the universe is true for one main reason—long dependency chains. Dependencies are like a tower of cards.

You knock one out, and they all come tumbling down when packages have deeply nested dependencies. Don't fall into the trap of creating packages or modules that keep stacking up. Number two: you should learn multiple languages. I started off with PHP, HTML, JavaScript, and CSS.

As plain and bog-standard as you can get. I didn't really start using more programming languages until about three or four years into my career as a developer. By that point, I was so comfortable with what I knew that I struggled to try anything else. It felt like starting from scratch. This was a mistake because those languages trapped me in a specific area of development where I had no awareness of other languages and what they could provide, and it even cost me a few job opportunities.

Number three: always check for truthy values. Always avoid double negatives and almost always check for truthy values. Reading code where you're checking for truthy values is much easier. If you have to use a negative name for a variable, like "isNotAPizza," then never combine it with a logical negation. This creates a double negative, which is difficult to read and adds unnecessary cognitive load.

Number four: the language you start with doesn't matter. I already mentioned what I started with. Some people might argue and say to start with something else, but the truth is that what you start with doesn't matter; it's the fact that you get started that counts. Do a little bit of research into what you want to build or which area of development you want to work in. Make an educated choice and then go from there. You're not bound to any one language, and learning your first language makes learning the next one easier, and so on.

Number five: Practice data manipulation, especially arrays. The majority of programming software revolves around moving data from one place to another, manipulating, shaping, and trimming along the way. So, get really good at shaping and understanding data structures. In particular, become proficient with arrays. They're present in every programming language and will be the most common type you work with.

Most of the time will be spent sorting, filtering, and trimming data that's stored in an array. Number six: Master your tools. Speed and efficiency trump the latest and greatest. There's no point in using the latest language or framework if it takes you two to three times longer to complete the same task compared to using a stack that you're comfortable with. Software requirements change.

In this high-speed world, being able to deliver quality quickly matters. Number seven: get really comfortable with typing. This one might change in the future with AI tools and voice control getting significantly better for software, but for now, we're all mostly typing. If you're getting long, uninterrupted blocks of time for coding, then you'll simply get more done by typing quickly, efficiently, and accurately. It's what we spend the majority of our time doing, so it makes sense to actually give it some practice.

Find a keyboard that's comfortable for you and get really cozy with it. Look into features like Vim motions for better code navigation, so you don't have to reach for the mouse. Have fun with tools like Monkeytype. Number 8: Embrace your curiosity.

Lots of people will tell you to go this way or that, learn this thing or that, and take this career path or that. Instead, listen to your mind. What do you think about when all is quiet, with nobody around?

What blog or Twitter post caught your eye? Follow these trails of curious thought and then dive deeper. Genuine curiosity will lead you to places other people simply won't go because they don't feel that same spark. That's where you can shine—intrinsically drawn to exploration.

Number 9: Avoid the "else if" pattern. Avoid "else if" like the plague. It's verbose and creates a strict linear form of logic that could be better simplified with something like a switch statement. Sometimes, conditions can be grouped together, allowing for standalone "if" statements, followed by a final default return at the end of the function.

It's just neater and easier to follow. Number 10: try both a scripting language and a compiled language. They both have different strengths and weaknesses. They behave differently, and it's a good idea to try at least one of each so you can get a feel for how different they can be and where they are similar. The workflows tend to be different between the two, so you might find one style suits you and your values better than the other.

Number 11, and I'm going to stop counting with my fingers now. Try both object-oriented programming and functional programming. These are two paradigms with very different approaches to how code is written and behaves. Like the last point we mentioned, they both have strengths and weaknesses. People can become very zealous about these two approaches, so it's best to try both and understand how they work.

I was brought up with object-oriented programming but found that I much preferred the data flow with functional programming and found it easier to test as well. Try both and broaden your horizons. Number 12: Don't abstract too early. Abstracting something too early in development could lead you down a path that makes it difficult to come back from again.

When you find yourself in a situation where you could create an abstraction, ask yourself these three questions: Do I know the majority of the cases where this abstraction will be used? Does the abstraction make sense not just to me but to anyone else? Is the abstraction valuable, or is it simply hiding messy code? If you're not sure of the answers to these questions, then you might want to reconsider before moving ahead.

Number 13: Forget dry and try damp. Most developers swear by this one, but there's one problem with it: we repeat ourselves all the time. It's a very concrete statement.

Don't repeat yourself. That assumes forever, right? The problem is that it needs a bit more nuance than that. There are times when repeating yourself is acceptable. If we extracted every piece of code that we used twice, we would probably never stop.

A good rule of thumb I found is this: Have I coded this same logic at least three times? Can it be tested easily? Are there any special cases where I'm using this? It forces you to think about the abstraction and whether it's valuable or not.

Bad abstractions can create unwanted coupling and complexity. Number 14: Work on communication skills early. This is a big one that can limit your ability to progress in your career. The further up the career ladder you go, the more important this skill becomes, because your duties and responsibilities expand. Your work increasingly involves leadership, mentoring, and guiding practices and principles within your engineering team and environment.

You'll need to communicate with people from all parts of the business and adjust accordingly. If you can't communicate simply and effectively, then you'll struggle to build confidence for yourself and your team. Quack number 15: Use the rubber duck. This vital piece of equipment could make or break the difficult problems you face.

Okay, it’s not vital to have an actual duck. You can achieve the same effect on your own or with another person, but make sure to use this technique. Rubber duck debugging has been widely documented as an effective way to break down problems when you're struggling. The basic principle is to explain the problem, preferably out loud, to the duck. Stepping through the problem with the duck helps you analyze it from a different perspective.

And communicating clearly and precisely is a skill in itself. This will test whether you fully understand the problem or not. Go grab one of these tools so you can succeed! Being nice is a skill in itself. This will test whether you fully understand the problem or not.

Go grab one of these bad boys so you can pass. I'll put a link in the description for this one: Number 16. If the duck fails, then take a walk. Sometimes, not even the almighty Gandalf can save us.

If that's the case, then getting up and going for a walk could be the answer. Everyone's heard of Steve Jobs' famous walking meetings. There's plenty of science that explains the benefits of walking, and I try to get in a daily walk of at least 45 minutes each day. I have a whole video where I talk about daily walks; you can go check it out. Whenever I've been stuck on a problem, debugging with the duck out loud or someone else just doesn't cut it.

I find that getting up and walking away from the desk for five to ten minutes helps me. It's a combination of movement and giving our eyes a break from the screen that allows our brains to process information differently. Get up from the desk more. Number 17: Be a lifelong learner.

I believe you can never really master anything. Nobody ever goes to the grave having completed everything in a given topic. There is always more to learn. In that case, embrace being a lifelong learner. The goal is not to complete your training and then sail away happily ever after.

The goal and the game are to constantly improve, learn, and grow. It will be much easier if you embrace this and enjoy the process. Don't see it as extra work; life is work. Some of the most enjoyable parts of life come from being engrossed in a deep state of work and flow.

Enjoy the learning. If you struggle to enjoy what you're learning, then try something else. Your intrinsic curiosity will guide you to things that feel like play but work for others. Number 18: Write more.

It is a core skill for life. There is not a single profession in this world that is not improved by the ability to write better. And it isn't just about writing better for the sake of it; it's about what comes from the writing itself. Writing clarifies understanding. It's an incredible tool for learning.

One of the most powerful tools you'll have for learning, discovery, collaboration, and communication is the ability to effectively name your work. Specifically for programming, it helps with writing documentation, pull request reviews, and the readability of code. Speaking of which, number 19: get good at naming. The two hardest things in programming are cache validation and naming things. Make a real effort to work on the second one.

Naming things is the difference between code that people can happily work with, maintain, and grow, and code that people can’t follow, update, or understand. Keep naming simple and readable. For example, use descriptive adjectives and variable names to convey intent, so people know what it’s being used for without having to look at its contents. Remember the principle: Keep it simple, stupid.

A widely used phrase in programming: simplicity is hard to achieve, so it's important to take our time, break things down, and find a way to make complex concepts simple. Simplicity does not mean easy. Achieving simplicity is an art, and it can be quite challenging. Avoid getting dragged into needless complexity.

It is the death of software. The more complexity you introduce, the more chances you create for your code to fail. Strive for simplicity. Number 21: Use comments in your code as a last resort.

Apart from packages, libraries, and modules, I really do feel that commenting your code is unnecessary. Don't feel the need to comment on every line of code. Documentation isn't the same as commenting on code. Good engineers can understand what the code does by following its path and looking at the variable names, provided they are named well. Essentially, the code becomes the documentation.

If something is particularly complicated and it's not obvious how to make it simpler, or if its usage is confusing, then do reach for the comments, but use them sparingly. Two little ducks 22. Study with materials, and learn with projects. We gather and collate knowledge by reading, listening, and watching. We learn through implementing, creation, and action. Don't get stuck in tutorial hell; you'll learn nothing.

Once you study some information, test yourself on it. Use it. Create something. Programming is a skill, a craft, and a creative outlet. You simply don't learn through passive activities.

There's a great video by a Python programmer that explains that creating is the highest order of learning. Number 23: Start with small projects that pique your curiosity, then work your way up. It's easy to see what people create online and feel a bit jealous. Or it might be desire, excitement, or whatever you feel when you see something someone is creating that looks great. However, when we're starting out, it's better to tackle small problems and projects and build our skills from there.

"Seeing a project through to completion is a skill in itself. If you tackle something too big, too early, you'll struggle to see it through to the finish. If you're curious about building something, try to focus on a feature or piece of functionality that you can tackle on its own. You can build it end to end and learn its ins and outs in greater depth. Number 24: write your code in long format to start with."

This might sound weird, but for some programming languages, it's a good idea to write out the long-hand format. For example, in CSS, there are multiple properties like margin, padding, and border-radius that encapsulate multiple properties into one. If you write them out with each property defined individually, you'll understand all the components that go into that one encapsulation, some of which you might not have known about or understood without doing so. Number 25: build a framework or package.

If you find yourself using the same copy-paste code between projects, then go a step further and create a shared package or module. If you want to understand how ReactJS or VueJS really work, try implementing some of the features in your own framework. There's a significant difference between the code we produce for ourselves and teams and creating something that can be distributed, shared, and used through open source. It will teach you invaluable lessons about coding. Number 26: Build a CLI tool.

This one can be a lot of fun. We spend a lot of time in our terminal tools, and we use many things through the terminal. Build something you can use that improves your workflow or just something you think is fun. It's a very different experience than writing most of the software you do day to day, and it can be a really exciting talking point you can have with other developers as well.

Number 27: Get friendly with logging. Monitoring and observability of systems are vital for production software. You need to be comfortable with implementing logging mechanisms, but also with reading logs, accessing logs in various ways, and debugging using logs. They are your window into what’s happening in your applications and provide visibility of potential problems ahead of time. Number 28: Handle your errors explicitly.

Some languages do this better than others, but if you know a potential error could occur, then handle it explicitly. Some languages enforce this, like Go, while others, like JavaScript, may fail for various reasons without providing any clues as to where the failure might occur. If you anticipate that something might fail, make sure to account for it. Number 29: Use the debugger. Everyone uses console.log, print, echo, or whatever method is available to debug their code.

But using an actual debugger will give you insights into what's happening in your code, where things are happening, and in what order. Debuggers aren't hard to use once you understand what they do and learn the basic controls. They significantly improve your ability to debug. Number 30: Get comfortable not knowing. A lot of the time during programming, you're going to feel lost, frustrated, scared, and even a little bit dumb.

But that's part of the process for learning anything. You're not going to know how to do something until you've done it at least once. You won't know how to build a web-based calendar component. You won't know how to build a search-based API. You won't know a lot of things.

There's no manual; there are great resources online, but not for everything. You have to be comfortable being uncomfortable in order to grow. The majority of software development and programming involves problem-solving. You'll need to accept that you don't have all the answers and instead break problems down until you can find a solution. Bonus tip number 31.

Keep working on the fundamentals. Avoid shiny framework syndrome. AI is everywhere right now. People think traditional coding will die off. It might, but that time is not now.

Learning the fundamentals will always serve you well in the long run. If you understand code at a deep level and the fundamentals of software engineering, you'll be able to adapt to any language, any framework, and any tool, allowing you to keep moving forward. There's a great quote from Kobe Bryant that says, "I never get bored with the basics." The best in the world at anything all master the basics, the fundamentals. It's not fancy tricks and complex skills they know that make them the best.

It's about mastering the fundamentals. This means being able to adapt to any situation and consistently staying on top. Don't follow the next shiny framework that comes along simply because it's trendy. You can pursue it for fun if you wish, but don't abandon everything else for it. Focus on the fundamentals.

If you like this, then check out the next video where I share insights on what great developers do versus the average developer. Quack! Click it, please.