Photo by NeONBRAND on Unsplash

Hi there and welcome (back)! 👋🏻 After a short radio silence, beating the lockdown blues, and some good ol' sleep deprivation, I am back with the last part of the three part series titled: Things I wish I knew!

If you are new here, go take a quick look at part 1 and part 2 (it's good stuff, I promise). And don't forget to share your thoughts in the comments 😉. Now, without further ado, let's jump right into it!

Quick recap

In part 2 we dived into the following topics:

• the importance of portfolios and work experience,
• how skills matter more than certificates,
• how tech goes beyond software engineering and
• the best way of learning is by building (So get to work 👷🏻‍♀️👷🏻‍♂️).

Today we will look at the last few things that I wish I knew before getting started in tech. (There's obviously more, but the points I shared with you in this series sum it all up pretty well.)

What the heck Test Driven Development (TDD) is and why it matters 🧪

This is certainly something I did not know about until recently. Yes, I had heard about the term before, but had never worked with this development approach. I must admit that it is NOT an easy concept to grasp. (So don't expect to get the hang of it overnight 😅).

If you weren't taught TDD in college or uni, or did not learn about TDD by yourself, you're in trouble. 😬 Just kidding. However, in my humble opinion, this is something every aspiring dev should jump into sooner rather than later. Why? Because it gives you an edge and it enables you to build robust solutions. Trust me, you don't want to throw something into production without testing it as thoroughly as human possible. Love a challenge? Throw that untested Frankenstein codebase in production and let me know how it went! 😅

In simple terms TDD is a practice that involves writing tests, before writing the actual code (or logic). The illustration below sums it up nicely. (I won't be going into much detail here but I have plans on posting more on this topic at a later time. Hit that follow button if you don't wanna miss out 😎).

Finally, I'd like to add that I find it tedious to have to learn TDD on the job. The reason being that the way I was taught to program is not anywhere close to what you will encounter in real life. So, despite going to college and having the best intentions, I still have a long way to go. But that's all right, I would not want it any other way. 🤷🏻‍♀️

The importance of best practices ✨

Good code practices go a long way. Remember, you are a developer/engineer, not a chef (nothing wrong with liking to cook though 😉). So please stop whipping up that spaghetti code! 🍝

In all seriousness: please invest time and effort in learning the best practices early on. Yes, you can learn those on the job too, but it is a bit counterproductive at times. Good coding practices are pretty much like good habits; a bit hard to adopt and grasp, but have many benefits. Conversely, bad habits and bad coding practices are very similar too; they are hard to unlearn. You have been warned. 🚨

If I could go back in time, I would have stressed much more on learning good code practices from the start. It definitely pays off. 💰

Scrum and being agile 💨

Scrum is all nice and dandy, until you put it in practice. Despite being useful, it is a taxing way of working. Here's why.

For those unfamiliar, Scrum is an agile methodology typically employed in the tech industry (also used outside of this field). So called sprints run for about 2 weeks, and at times 4 weeks (depending on the team). In addition to that, there's sprint activities such as Sprint planning, review and retrospective.

If you work with 2 week sprints, your sprint review and retrospective will last 4 hours in total (2 hours per activity). Likewise, the sprint planning will last 4 hours (usually split into two 2 hour blocks). Sounds exhausting? It is! After all, that makes up 8 hours, in other words a work day (don't worry, I don't think many teams devote a whole day to meetings. At least my team doesn't)! Enough math for now. 🥴

Once again, I won't go into full details, but do expect a post on this topic soon. Now don't get me wrong. Scrum works, and pretty well for that matter. I just wish I knew how time-consuming and exhausting these meetings are, before waltzing into them! 🥱 Better grab a candy bar while at it... 🍫

An app consists of various moving parts 🚴🏻‍

This is may not be evident at the start, but the more you work in tech, the more you come to realize and understand this. An app (or software, or whatever you want to call it), is a unit that is composed of several parts. For instance, you have the UI of the app (front end), the backend and the database. All of these components, or moving parts, work together to make the application function.

The more moving parts in an app, the more tedious it is to maintain the app. The components of the app have little significance as stand alone pieces. They need each other to add value to the user. It is also good to realize that front end and backend are two different playgrounds. Though both benefit from the same best practices, they need independent attention.

You'd be surprised how many juniors still don't get the relationship between the front end and the backend. Some even think that the front end connects directly to a database, effectively ignoring the backend altogether. (That train of thought makes little sense...)

My advice to beginners (or anyone for that matter): learn about ALL the moving parts that compose an app. Learn how they relate to each other. You may like front end better than backend, but please learn at least the basics of backend development. It will help you more than you think.

Teamwork makes the dream work 👌🏻

I must say that as an introvert, I like working independently (in other words on my own, by myself). There was even a time when I had a bit of an aversion to teamwork! Teamwork usually left me feeling disappointed and I often had to deal with slackers and deadweights. Needless to say, that was, and still is, frustrating as hell.

But as time passed, I have come to truly value teamwork. Frankly said, I now dislike working by myself. Strange, right? Not only is the workload heavier when you work alone, but you also have no one to interact with and learn from. In the end, we are social animals despite how anti-social some of us are. 😬

Working in teams has its benefits! Don't believe me? Read on. 🤓 Being able to work with others does not only help you develop interpersonal skills. It also exposes you to people with skillsets and perspectives much different than your own (which is more valuable than you may realize). Also, have you heard of the saying that goes: two heads are better than one? That one describes teamwork really well. When working in teams, if someone hits a roadblock, you can turn to anyone for help. Y'all can brainstorm about the problem and solve it much faster. Yeah, yeah. I hear you loud and clear; you can do the same with Stack Overflow and other forums. But that, though helpful, ain't teamwork per se. 🤷🏻‍♀️

Final words

Phew, that's it for this series! 🥳 Thank you so much for taking the time to read this post (or the whole series). I hope you enjoyed it and found value in it. If you did (or didn't), let me know in the comments below. What are your thoughts on this? 🤔 Anything you'd add?

Stay safe and code on! 👩🏻‍💻👨🏻‍💻

P.S.: More content coming your way soon! Stay tuned!

---

Still here? Catch me on Twitter or find me elsewhere! If you like my blogs and are feeling generous, kindly consider to 👇🏻