DEV Community

loading...
Cover image for Things I wish I knew before entering the tech space ๐ŸŒŒ part 3 of 3

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

technoglot profile image Amelia Vieira Rosado ใƒปUpdated on ใƒป6 min read

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




technoglot footer banner

Discussion (8)

pic
Editor guide
Collapse
juanfrank77 profile image
Juan F Gonzalez

I definitely enjoyed reading this series. Your writing style is quite fun. I felt like we were just having a chill chat.

Also, you validated some assumptions I have around skills, skills trump big-name courses and fancy certificates on LinkedIn. And not just tech skills, that point you made about teamwork is crucial.

There are several people very highly-skilled technical-wise that don't know how to communicate with teammates, managers, stakeholders, or share their knowledge with others or know what to prioritize in the work or negotiate a raise or so many of these, I'd say more important and transversal skills in the industry.

Good job hitting on all those points!

Collapse
technoglot profile image
Amelia Vieira Rosado Author

I definitely enjoyed reading this series. Your writing style is quite fun. I felt like we were just having a chill chat.

Hey Juan, thanks for the kind words! Means a lot ๐Ÿ˜Š (And here I was wondering if I had over spiced the series, hehe).

I'd say more important and transversal skills in the industry.

Certainly! Louder for the people in the back, please! I personally struggle to work with poor team players. I cannot understand for the life of me, how some people can't communicate basic things like "I'll be late" or "Something came up, I'll catch up with my duties later". Or how they always have an excuse for not doing what they were supposed to. Honestly said, I believe that some people in the tech space are deluded by the idea that they ONLY need tech skills to survive. That sole assumption is wrong on so many levels! Interpersonal skills matter a lot; I cannot stress it enough. ๐Ÿคท๐Ÿปโ€โ™€๏ธ

Thanks for sharing your thoughts Juan. ๐Ÿ™‡๐Ÿปโ€โ™€๏ธ I'm glad you enjoyed the series ๐Ÿ˜

Collapse
juanfrank77 profile image
Juan F Gonzalez

I believe that some people in the tech space are deluded by the idea that they ONLY need tech skills to survive.

Yes, yes, and more yes. That thing you mentioned is key. Everywhere around we see courses, programs, bootcamps, and whatnot that make the focus on tech skills and leave those other skills as some sort of "nice bonus".
I want to solve that, with some hacker-like curiosity of "breaking the code" of interpersonal skills which I think would be massively beneficial for people entering tech.

Thanks for putting that into words that I couldn't myself. Very helpful series you have there!

Thread Thread
technoglot profile image
Amelia Vieira Rosado Author

Everywhere around we see courses, programs, bootcamps, and whatnot that make the focus on tech skills and leave those other skills as some sort of "nice bonus".

I absolutely agree ๐Ÿ’ฏ! This needs to be addressed, otherwise I fear for the future of tech. I believe the only tech jobs (that I have seen) that stress on soft skills, are data-related jobs. For instance, most of these jobs will require the candidate to possess good communication skills, especially presentation skills (so-called data storytelling). I think other jobs in the field need to start stressing more on this "soft" aspect of engineers. Only then will we have the most well-equipped engineers possible.

(P.S. I remember the time when Linus Torvalds publicly announced that he would take some time to work on his communication skills. ๐Ÿ˜… Though funny at first glance, I found that a great move. It shows how self-aware he is)

I want to solve that, with some hacker-like curiosity of "breaking the code" of interpersonal skills which I think would be massively beneficial for people entering tech.

That makes two of us, hehe! ๐Ÿ˜ Once again, thanks for your kind words and for taking the time to share your thoughts. I truly appreciate it! ๐Ÿ™‡๐Ÿปโ€โ™€๏ธ

Collapse
miguelmj profile image
MiguelMJ

A good closure to the series. I was trying to think of something else to add but I think you have summarized pretty well the most common things beginners should know. For me, the most relatable were version control (in part one), learn by building, skills before certificates (part two) and test driven development (which I have never used! I need some experience with that). Great job, Amelia!

Collapse
technoglot profile image
Amelia Vieira Rosado Author

Glad you enjoyed the series, Miguel! ๐Ÿ˜Š

test driven development (which I have never used! I need some experience with that)

Hehe, welcome on board ๐Ÿ™ˆ I'll be sure to share my learnings on that in due time!

Collapse
devlorenzo profile image
DevLorenzo

Where do you get the cover images from?

Collapse
technoglot profile image
Amelia Vieira Rosado Author

Hello DevLorenzo, these are from undraw.co. They are free to use. Might as well update my posts to include the source, that's good practice ๐Ÿ˜ฌ