Best Lessons Learned to Date

When I first started to code, I was naive and simply hungry to consume as much (mostly) useless knowledge about as many languages as I could. I learned the basics of Python, JavaScript, Java, PHP, and C++ without taking the time to truly understand them and build meaningful or even interesting projects with them. In this article, I'd like to take the time to review some of the best lessons I wish I'd known from the start. I can only hope that these insights, some of which were learned the hard way, will help those interested in pursuing computer science as a major and/or career. I invite you to learn from my mistakes and my victories—in every article of this newsletter—so that your journeys are at least slightly easier.

1. Important Topics

Many topics you'll encounter in the field are interesting and it's tempting to yearn for knowledge in all of them, but I've found that some are more important than others and worth devoting more time to learning. In this article, I'll cover two general computer science topics I have in mind, but in later articles, I may go into further detail about other important topics (including ones specific to the two main domains I work with: web development and artificial intelligence).

Data Structures

How we organize, manage, and store data is incredibly important in computer science and that's what data structures are all about. As programmers, it's important that we not only understand these structures on a conceptual level but also how to implement them in our language(s) of choice and how to effectively choose the best structure for our specific purpose. I find that GeeksforGeeks is often a useful resource for learning, and they happen to have a helpful directory for their data structures resources here. (Shoutout to Jonathan Cazalas, Ph.D. who was my instructor for CSC 3280 - Data Structures.)

Algorithms

At its core, computer science is all about utilizing technology to solve problems, especially ones that are often too computationally intense for humans to reasonably solve. Our heuristics for solving these problems and the step-by-step process of how we implement the solutions are algorithms. These algorithms help us solve a wide variety of problems such as sorting, searching, and encrypting. Thus, it is important to understand algorithms on a conceptual level so you can analyze their efficiency (in time and space), choose the right algorithm for your purpose, and be able to create your own algorithm if needed. GeeksforGeeks also has a tutorial directory for algorithms, which you can find here. (Shoutout to Jason Lewis, PhD who was my instructor for CSC 3380 - Analysis of Algorithms.)

2. Good Coding Practices

There are a plethora of resources out there explaining a wide variety of practices for writing good code. Like habits, they're something you have to continuously work on and improve, but the sooner you start the easier it can be. I'll admit that I still struggle with some of these practices, so by all means do as I say and not as I do. Here are just two of them (in a later article, I'll deep dive into this with tons of resources).

Readable Code

You should always strive to make your code readable through the use of tabbing, white space, comments, and good naming conventions. Many languages don't require that you use tabs or even white space, but it's good practice to indent lines "properly" (inside loops, if statements, functions, etc.) and put white space in appropriate places (between functions, classes, etc.) to make your code more appealing to whoever will read it. Additionally, you should do your best to name everything in your code (variables, classes, functions, etc.) such that it explains its purpose while being concise and following the language's general naming convention (i.e.: camelCase for Java and snake_case for Python). For things that aren't self-explanatory, you should leave comments explaining what the code does. We need these good practices for readable code because a few months from now you may not know what your code does anymore or you may be working as part of a team where your colleagues have to understand what your code does without a twenty-minute explanation.

Don't Repeat Yourself (DRY)

There are multiple ways to refer to this principle and alternatives are found in other principles, but in essence, DRY is all about modularity in your code. If you intend on doing the same thing multiple times in your code, then it should probably be its own function. A good, thorough explanation of DRY can be found here.

3. Practical Experience

As important as it is to learn everything on a conceptual level, it is far more important that you demonstrate your ability to apply what you've learned. Therefore, you should always be working on projects especially as you're learning something new. For example, if you want to learn React (or some other JavaScript framework), then I suggest diving in and trying to build a website or two using it. It won't be the best website at first as you'll be learning everything on the fly, but as you learn more and improve so too will the website. Another good way to gain practical experience is to contribute to open-source projects, which can sometimes be a really easy way to break into it—here's a nifty guide for you. With all of this said, I highly recommend keeping track of your contributions (projects, open source work, etc.) and possibly even making a directory for said contributions (like I have here), so you can easily add them to your resume or link them upon request.

4. Read Often

That's right, I'm recommending that even if all you want to do is code code code, you should also read read read. I say this for multiple reasons: tech is an ever-evolving field and so it helps to stay up to date on certain trends, learning a new technology will involve a lot of documentation and article reading, and getting to the root of bugs is often all about reading the stack traces and answers on sites like StackOverflow. Additionally, reading these technical documents will prepare you for when you ultimately have to write them—yes, if you make something that people may use at some point, then you need to document it properly please for the love of all that is holy.

5. Version Control

Resources like Git and GitHub (or alternatives like the ones listed, ironically on GitHub, here) for version control will be one of your best friends, so you should learn them inside and out early on. Version control helps you save progress, collaborate with others, manage version releases, and other important aspects of development. For an example of a GitHub profile, you can view mine.

6. Fresh Eyes

Struggling with a bug or how to do something specific in the language you're working in? Sometimes it's best to take a break and/or have a friend, peer, or colleague take a look at it. Countless times, before I got better about debugging, I would spend hours trying multiple approaches to fix a bug then take a twenty-minute break and fix the bug within five minutes of coming back to it. We tend to get stuck in a rut and that kills our problem-solving capabilities, so sometimes we need to take a break to get out of that rut.

7. Keep Secrets

This one probably sounds a little weird, but what I mean by this is that there's some stuff you need to protect as a developer (i.e.: API keys, login information, database credentials, etc.). Thus, you must learn how to prevent this information from being made public including how to not upload it to your version control system of choice. For GitHub, that entails keeping these secrets in a .env (environment) file and adding the file's path to the .gitignore file—this file is also handy for when you have massive datasets or downloaded packages (like with Laravel or npm) that you don't want or need to push to your repository.- Side Note: This is, in fact, one of the lessons I've learned the hard way. I accidentally pushed an API key to GitHub once. Thankfully, this key was not of major consequence and GitHub notified me, so I was able to immediately remedy it and regenerate my key. If you ever accidentally push one of these secrets, you NEED to regenerate or reset it as someone may have got ahold of it even if it was only public for a few seconds.

8. Be Structured

One I'm still struggling with a bit and learning is to be structured and purposeful in your development. It's easy to get a random idea and just try to run with it, but often you'll reach a point where you realize you have no clue how you want this to turn out or what you're even doing. Take some time to genuinely flesh out your idea, choose what you want to build it with (and why), consider how it can be accomplished and structured in your chosen technology, and create some actionable steps. There are a few methods to accomplish this, but a common one that I've learned a bit about is called the Agile methodology ( Atlassian provides some useful information about Agile here).

Conclusion

I hope you found this article helpful and/or interesting. I tried to keep each section relatively brief, so this article didn't get too long and there is room for expansion in each topic for future articles. Thanks for all the support thus far!