DEV Community: Carlos La O Trujillo

3 Paths to Become a Web Developer

Carlos La O Trujillo — Mon, 24 Apr 2023 14:04:31 +0000

Learning how to code is hard. But if you choose the wrong path for you, it could be even worse. So let's take a look at what those are and what the pros and cons are so YOU can make a smart decision.

Path 1: Get a Degree

To be a web developer, you don't, and let me repeat, you don't NEED any degree. Well, formal education is not bad at all, but in tech, a lot of stuff that you don't need is being taught on the basis of broadness instead of depth. So there is value there; the only caveat is that today, companies value depth in knowledge more than broad knowledge. In the last 20 years, the marketplace has opted for specializing, and not only in the tech industry. That's why a college degree, where you will get just "a solid base," is not enough to get you a job just because.

Pros:

Looks good on the resume (especially if you went to an Ivy League University, MIT, Harvard, etc.)
More rounded education
Solid understanding of foundational concepts
You can expand beyond a single branch, not just web development
Live the college life (if you do on-site)
Make friends and connections with peers and teachers (very valuable for future projects or job opportunities)
Career services are often a lot better, research opportunities, internships, etc., that other alternatives don't offer

Cons:

Expensive, very
Time commitment
Long and rigid structure (that's what she said 🤦)
Focus on being broad, not on depth
Worthless classes or outdated curriculum
Heavy on math, which you don't really need a lot for web development

I still recommend going to college if:

You are young and want to experience college life, on-site, no remote BS; (you're young and want to have fun and be around your peers and make connections, YOLO and YOYO, I don't see anything wrong with that)
It's debt-free (don't get in debt for something you can learn for free, especially this kind of money)
It's an Ivy League University (these universities do make a difference in your resume, so if you can get into one of those, don't overthink, the workplace treats those with more respect, and you will definitely get an interview just by listing it on your resume)

Otherwise, I'll go a different route, just because of the time caveat. Four years to get a degree where you can go another route and start getting experience and being paid way sooner sounds like a better alternative for me.

Path 2: Bootcamp

Bootcamps are great; they are a condensed way to learn and acquire skills in a fast-paced environment. The downside is that, unfortunately, it's not for everybody. They are usually expensive, ranging from 7k to 17k, and insanely fast-paced. The good thing is that they dive into specifics and don't go around the bushes when it comes to content and specialization.

Pros:

Good for teaching a skill set that's genuinely useful on the job
Get good fast (based on how quickly you can learn)
Networking, could be mentors, could be new mates you made in the bootcamp; in any case, you can leverage that you're not learning in isolation
Mentorship and support from real professionals in the industry

Cons:

Expensive
Fast-paced (some of them may be too fast)
They don't guarantee a job
Certificates of completion don't mean anything
Quality varies among them

I'll recommend bootcamps if:

You have money to spend
It's on-site; take a holiday and do it right, remote bootcamps have lower completion rates than on-site, and it's good to know and share with fellow coders and network
They have a good career services program that can help you with your soft skills after you've got the technical part, so you can receive an offer as soon as possible
It has a good track record and longevity in the industry, because they will have the best mentors and the best quality of curriculum and personnel.

Path 3: Self-Taught

My personal favorite, self-taught is well, self-explanatory. You get yourself a few resources you like and get your hands dirty.

Pros:

Cheap
At your own pace
Since you're not following a rigid track, you can learn from different sources and get the most updated information, or maybe expand on topics you find more interesting

Cons:

Difficult to stay focused and motivated
You're missing out on networking opportunities, which is a big one
Lack of guidance or mentoring
Some employers might not like that you don't have a traditional background, so you might need to prove yourself in their eyes to get your first job

I'll recommend self-taught if:

You can't leave work to focus on learning to code
You want to learn to code as cheaply as possible
You already know your way around computers and know how to find good resources online
You are disciplined and consistent, which is a big one
You're not afraid to ask strangers for help

And that's a wrap! I hope you find this helpful. Keep calm and code away!

Carlos

How To Write Quality Code: A Simple Guide

Carlos La O Trujillo — Sun, 16 Apr 2023 20:33:43 +0000

Writing good code is a goal that should be on every developers to-do list. In the beginning we are learning the ropes and getting used to seeing code everywhere, so we dont worry too much about the right or better approacheswe just want code that works.

However, as we start to get used to coding, make it work doesnt cut it anymore. We then wonder if what we are doing is actually our best, and if not, how we can improve.

If you want to ramp up and improve yourself, you will have to take your coding to the next level. This guide will help you understand what it takes to write good code and the mentality that you need to never look back.

Dont Stop With the Big O

If youre not a computer science graduate, you probably havent worked a lot with Big O. Big O is a mathematical notation that allows the measuring of a computer algorithms speed and memory size when hypothetically there are infinite inputs.

Its a great measure for code efficiency and cost, but beyond that, Big O cant measure anything else. It is a mathematical tool used to measure complexity in our code; however, it doesnt weigh the human variable, the specific system requirements, or our software architecture.

Im not suggesting you should neglect Big O, but you should take it for what it isa mathematical approach that forms part of the criteria of what is quality codeand by no means take it as the absolute measure. Big O is a good starting point to measure your code quality, but dont stop there. You still have work to do.

Aim for Code Persistence

Code persistence is one of the most undervalued factors in what makes quality code. In a nutshell, its the measure of how much of your code will live through all stages of generating and maintaining production code from feature idea to final test and deployment, and through refactoring, debugging, and the implementation of new features on top.

Think about how much of your code passes through all those filters and makes it to the finish line and, more importantly, how much of it stays there through all new revisions and future implementations.

Its a waste of time and a huge roadblock when some code has to be partially or entirely rewritten because nobody knows what it does or how it works or because its more cost-effective to write it from scratch instead of trying to make it work. That piece of code is not quality code, and its not persistent through the changes that happen over time.

Systems can change, and so can requirements and technologies, but good code will survive with little or no modification.

Next time youre writing code, sit and think How can I solve this problem in a way that only needs to be coded one time? The solution will not be as obvious as you might think. Get imaginative and create some great code.

Technical Solutions To Boost Your Coding

There are a plethora of plugins, add-ons, and formatting standards, but most likely you will be forced to use specific tools or standards on a specific job. But dont see that as a bad thing. On the contrary, limitations will force you to learn new coding patterns and be flexible with your skills.

These tools will help you be organized and uniform about your code, but they wont do the work for you. The best tools you have are being conscious about what you are doing and consistent about it.

Here are some technical ideas to improve your code quality :

Use a linter.
Adhere to a coding standard.
Comment your code appropriately.
Use good names (variables, functions, etc.).
Don't forget about cache invalidation (jk 🤣🤣🤣)
Dont neglect proper testing.
Take advantage of automated code review tools and continuous integration tools.
Share your code and ask for feedback (code review).
Be aware of the projects big picture.
Pair programming with an experienced developer.
Stay up to date on updates and new libraries.
Read Code Complete and Clean Code.

Getting technical with your code can be a huge help, but that also can set you back if you dont know how to use your tools properly. Find that sweet spot where you leverage technical knowledge without wasting time over-engineering your code.

Write Human Code

Kyle Simpson has explained the idea of writing human code, meaning writing code with the explicit idea that it is for us, not for the computer. Yes, the computer will compile, link, execute, and interact with the code, but nowadays there are so many layers of abstraction, that our code barely translates its exact intention. So its pointless to save some characters here or to use font ligatures because they will parse faster.

This human code idea is brilliant. It allows you to write programs as legibly and easy to understand as possible, always thinking about our future self or co-workers that will deal with it.

Of course you should make sure you dont diminish performance (Big O) and other factors like coding standards, but always have in your head that this is a message for a human being and not just pieces of code to make something work. This is a huge mentality switch that will help you write better code.

Use Common Sense

One of the big hassles of changing jobs is getting to know the new codebase. Anyone disagree? I thought not. Swimming in that huge pile of old and new spaghetti of uncommented code can be nerve-wracking. But after a few weeks, it all starts to make sense.

Do yourself a favor and use common sense about how youre fitting your new code into the old codebase. Your new code can be slick and fast, elegant and communicative, but if it is on the wrong file, or the wrong scope, or the wrong block, it will still look out of place. Context is important; where you fit your new code is important. Remember youre writing code for you and your co-workerswhere you park it could generate great confusion or insightful clarification.

Design patterns in the codebase mean a lot, so dont disrupt them. Go with the flow. If your project bets heavily on functional programming, dont go around creating classes and methods like a maniac; it will look bad on you, and it will confuse everyone. Writing good code is where instinct meets knowledge. It takes time to get both, but the reward is a true form of art.

Five Questions To Ask

Before you ship any code, there are five questions you should ask that will exponentially increase your awareness of whether what youre uploading is good or just another temporary solution.

Before every commit, try to answer these questions:

Does your system break if you make a bad change to one part of your code?
Can your code be reused on another part of the system?
Can your code be updated or upgraded easily over time without adding bugs?
Is your code easy to understand, and does it follow logically?
Is your code efficient and small in size?

If you cannot give a clear and satisfactory reply to any of these questions, it means you should go back and reconsider your code. Pretending a problem doesnt exist wont make it go away.

Hasta la Vista Baby

Sometimes it is just better to rewrite the whole thing. Old technology, a bad codebase with a lot of bugs, new requirements that need completely new architecture, and escalation issues are several reasons why this can be a viable option. For whatever reason you are considering it, make sure its the right decision and that next time you get it right and make code that will last.

Writing quality, long-lasting code is not only possible but necessary. A survey from Tidelift and The New Stack of professional software developers, showed that 70% of a developers time is spent reading code, and the average output is about 10 lines of code per day. This means that we spend a lot of time figuring out how the heck our system works instead of actually writing some code.

Like everything in life, great code is about balance ; there is no one-size-fits-all answer. It depends on your system, your inputs, and the results you want to achieve. But you need to know how to tip the scale and compare, how to go back and adjust, and how to write code that never dies.

This guide will help you write better code. Dont just read it. Study it, share it, give some feedback, and above all apply it.

Great coders arent born like that; they strive to be better over time.

Remember, keep calm and code away!

Carlos

7 Things I Wish I Knew When I Applied for My First Developer Job

Carlos La O Trujillo — Mon, 10 Apr 2023 01:37:13 +0000

Landing your first developer job is hard. Perhaps not a very popular statement, I know, but its the truth. The industry can be elitist, and there are more newcomers every day. Thats not a bad thing. It just means more competition for those who dont have prior experience.

However, facing occasionally elitist attitudes or having to compete with many others doesnt mean it is impossible to get your first job. I mean, we all started from somewhere, right?

In this post, Ill give you some advice on how to stand out from the crowd and make yourself noticed. If I could go back in time and give myself a few tips to save me some time and sweat, Id definitely send myself this guide!

So, here are the seven most important things that I wish I knew when I started applying for my first job.

You Know Nothing Jon Snow

The technology industry is vast. Remember that we are building upon over a century of inventions, discoveries, research, and development. Trust me, nobody knows it all. Im pretty sure that if I asked Elon Musk a simple trivia Javascript question, he would shit his pants because, of course, thats not his area of expertise.

I felt intimidated looking at those developer roadmaps online, and when your finger scrolls more than two times to see all the stuff there is to learn, you get scared and depressed. Dont worry, I know there is a lot, but with discipline and time, you will get there. Some of my friends often asked me, Is it hard to learn to code? and my answer is always the same: It is not hard; it just takes patience and practice.

Your goal is to know enough to get your first job, and boy oh boy, I wasted time trying to dip my toes in every flashy library I came across. Stick with something and dont deviate. Sure there will be stuff that youll miss, but you dont want to become a jack of all trades. That will lead you to being the master of no job.

My point here is that its OK to be ignorant about a topic or a subject. We only need enough to build something. Building stuff is the key to knowing stuff. This might sound contradictory, but as usual, practice beats theory.

When theory may get you started and give you the unknowns, practice and the research that comes with it will teach you how to really code. This is the main reason why a lot of people get stuck in CourseLand; they just move from tutorial to tutorial, just mimicking and copy/pasting, and never truly understanding whats going on.

Now, remember, it has to be practice and the research necessary to overcome the failures and solve the problems that will emerge along the way.

Online Courses Teach Just the Basics

Maybe Im being too absolute here, given the fact that I attended an online Bootcamp that despite being overpriced, turned out to be fairly elemental.

I tried them all: YouTube, Codeacademy, TeamTreehouse, freeCodeCamp, Udemy, Pluralsight, you name it. There is a considerable content gap in the programming world from beginner to intermediate that nobody is addressing, and thats because it is your work to do it.

To get out of the newbie sandbox, you have to learn how to learn. That is, you have to learn how to integrate your knowledge, see the big picture, and be able to come up with your own learning patterns and tricks to solve problems. Thats what programming is about: solving problems. Everything else surrounding this core purpose is just a collection of tools that we use.

Therefore, please dont get stuck in CourseLand. Instead, build and solve problems to find your learning process. When you do that, you can learn wherever you want and get the skills that you need to be successful.

Impostor Syndrome in Place

This syndrome is very well known, not only in the tech industry but also across the board, especially in the high paid/high skills job market. If you havent heard of it, its basically the feeling of not belonging or that youre not qualified for the job; ergo, you feel like an impostor.

Its totally normal to feel this way. Who on earth would feel like a bossand act like oneif it were their first day in a job that they got with no experience, possibly even with no college degree, while making a significant amount of money?

I dont know about you, but my blood pressure would be through the roof. The bad news is that there is nothing we can do about it. I watched a bunch of YouTube videos, I read many Medium articles, I knew everything about how to overcome it, but still, no amount of knowledge in the world will take the pressure away; you have to own it.

The best way to deal with it is by pushing through and to fake it till you make it. If you feel like youre not ready to apply, submit the application anyway; if you are afraid of going to that interview, go anyway; if you dont feel comfortable to reach out, send the email anyway.

The best way to get comfortable is by failing and doing it again, until success. Get your hands in the mud, and dont stop until youve struck gold.

Potential Will Get You Hired

For the most part, companies know what they want. If you are interviewing for a developer position, and you dont have any relevant experience in your resume, its obvious that if you get hired, it will not be for your amazing coding skills, much less for your experience in the field.

Companies hire new grads and newcomers in the industry for their future potential. Of course, you cant just apply with zero skills and zero projects, expecting that magically someone will notice your potential. You have to build stuff so you can show stuff.

Having no real developer experience doesnt mean that you dont know how to code; and that is what the companies are looking for in the junior and entry-level developers: that they demonstrate they have potential to become a proficient developer.

The more your resume, portfolio, cover letter, and projects show that you are interested in becoming a developer, the more chances you have of getting hired as one. There is a behavioral component as well: Being committed to ramping up your skills, polishing your projects, and acing the interview will not only demonstrate that your skills are promising but also that you have a deep interest in the matter and that its very important to land the job.

I was never aware of this until later in my career. When I was first starting, all I cared about was to get the skills, and the rest would follow. At the interview for my first job, I got sent homework to build a landing page with a subscribe form and sent it back in 48 hours. It was a simple project: I could use any technology as long I fulfilled the requirements. I sent it back in 24 hours, with each line of code carefully reviewed, hosted on Github Pages, and even with a couple of background options. Im almost positive that this meticulous code and going the extra mile tipped the scale for me.

All the candidates that apply for the position you want probably will have fairly the same skills as you. Think about that for a second. Find a way to set yourself apart, and show you have more potential than the competition, and you will get the job.

Asking for Help Is Not a Crime

Asking for help on the internet is not dumb; on the contrary, it is very brave. Put yourself out there, and almost every time you will find a bunch of people willing to help. In the unlikely case you found yourself in one of the lets decapitate and burn the noobs type of communities, please help yourself out. There are mean developers out there; sorry, thats just the reality.

Fortunately, the vast majority of developers remember their own initial struggles, and almost all are willing to help. Just remember to follow a few basic rules: Only ask for help after you have tried to solve the problem yourself. Dont go around asking a question that could be easily answered in the first three results of a two-word Google search. Overall, do your homework, and if its too much for you, then ask for help.

Google-Fu Is Vital

Google-fu is unofficially one of the most valuable skills that you can harness in your arsenal. Its the ability to search efficiently on Google, filtering bad results, reducing search time, and improving your productivity.

Its a mix of skills that include search terms used, filtering, fast scan reading, rapid test, efficient bookmarking, and others. Google-fu will incredibly improve everything that you do on the internet.

Unfortunately, it takes time to get decent, but dont despair. Spending long butt hours will do the trick eventually. What you can do is become more aware of it so that you can develop this skill purposely, and eventually faster.

Look at how you search for and filter results in Google. What are your criteria for a good result, what is your opinion on some of the websites that pop up, do you actually know some websites that are showing up, are you comparing results?

These and a lot more other questions are what you can ask yourself to become more aware and change your search strategy. Trust me, after a while, the people around you will start to ask, How do you know which to choose? Why do you choose that one? or How do you get what you need at the first search you do?

You will start to unveil the true power of the internet, getting the good out of it, and disregarding the useless. Its like a superpower.

Put on Your Employers Shoes

This is pretty obvious, but the majority of people have the wrong approach to it. You may think that everything boils down to experience: The more you have, the more chances you have to get the job. Thats all your employer cares about.

Fortunately, its not like that; your employer is more focused on value, remember this. Value is the companys currency. The more perceived value you can provide, the more the chance you have of getting the job.

Even though experience is a potent item that injects value in your application, it isnt the only indicator. Commitment, ethics, hard work, and passion are incredible indicators as well. The way you market those values and make your future employer know that you excel in those is a problem all newcomers have to face.

You should still spend the majority of your time in the technical skills; there is no question about it. But also dedicate some time to develop your soft skills and how you want to present to your public, aka interviewer, that you can render an incredible value even with less experience than other candidates.

We Have All Been There

Beginnings can be hard, but theres a silver lining: You are not alone. In fact, we have all been there in every single thing that weve ever done. Coding and getting your first job are not any different.

In an ideal world, we would have all the experience we needed, and we would know all the things required. But in this world, its a matter of gradation. We have some sort of experience, and we know some things.

I hope this guide has given you a little head start. Get some perspective from my mistakes. As Eleanor Roosevelt once said: Learn from the mistakes of others. You cant live long enough to make them all yourself.

And remember, keep calm and code away!

Carlos