Things I wish I knew before entering the tech space ๐ŸŒŒ part 3 of 3

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 ๐Ÿ˜Ž).

TDD Cycle

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?

that's all folks

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 ๐Ÿ‘‡๐Ÿป Footer banner

No Comments Yet