Forem: Luka Kukina

Traditional Education vs Self Taught Route in Programming (2022 edition)

Luka Kukina — Mon, 14 Mar 2022 14:23:30 +0000

This blog post will be written from the self taught programmer's perspective.
Backstory: after I graduated from college (Nutrition), I started learning programming in my free time: HTML, CSS, JavaScript and React. I was able to land my first job after just 3 months of studying, but ever since then, I was wondering if I should have went to a Computer Sciences university of some kind...

5 Years of College vs 3 Months of Self Taught

College gives you a plan, it gives you a structured path of learning, it gives you dedicated teachers who are teaching you stuff in a particular order, but...
College also gives you an extensive overview of everything that programming has to offer. I would probably have to learn plenty of technologies that I would not be interested in, many of the subjects that are not directly connected to programming would be hard to pass and if I went to college for 5 years, I would "lose" 20x more time to get a first "real" job...

The good thing about the self taught route is that you can turn your focus completely and solely on technologies that interest you and that you want to master.
On the other hand, there are a lot of questions that are hard to answer if you are on your own:

where to start from?
how to distinguish what is crucial to understand if you want to move forward?
what is not so important?
why are there so many ways to write things and who should I listen to?
is this still being used??

(so many questions 🤯).

And that brings us to...

Imposter Syndrome

I am not sure how it goes with the imposter syndrome when you have a computer science degree, but when you're a self taught programmer - it is very real. You will often think that things you don't know are actually some basics that you should have known. Also, you won't have the strongest programming foundations, and because of that you will think there must have been a better way to solve a problem. You won't feel as good reviewing a PR or giving advice, and you won't feel as competent as people with a computer science degree.
But, it's not always that bad, especially because the IT industry is full of very friendly people that are understanding and always willing to help you out.

Information Availability

It has never been easier or faster to get information you need. Because of that, more and more people are successful in becoming self taught programmers. But, that is not necessarily making it easier. With so much (different) information, paths and advices, it might be overwhelming for people and make them feel uncertain if they are moving in the right direction - it may even make them quit.

Job Opportunities

There are so many IT companies in the world and there are more of them each day. The amount of code that needs to be taken care of is huge and the amount of code that still needs to be written is even bigger. The point is: There are not enough developers in this world! This fact makes a computer science diploma less important when it comes to landing a job. Almost everybody should be able to land a job as a junior developer because there is such a large need for developers right now. You need to be a good fit for a company (sometimes more important than the actual knowledge), and you'll become a master of your craft as you work on a real world problems.

If I had to do it all over again

Many people might say that self taught programmers got it easy by bypassing college, but I actually think that it is the harder path. If I had to start all over again from high school, I would definitely go to a computer science college and earn myself a degree. But if I had to do it all over again from the point where I already graduated from Nutrition, I think I would choose a self taught route again, but this time I would also try to become a part-time computer science student to have a structured curriculum and a certainty that I have the necessary foundation.

Conclusion

Like with everything else, there are good and bad aspects on both paths. Many programmers that I've met said that everybody is a self taught to a certain extent. I agree with that, college would give me a wide spectrum of knowledge, but when it comes to mastering a craft, you have to dig deep on your own. By now, I was able to progress to a mid level JavaScript developer and at this point I think I have more benefits by working on real world projects, so I don't see myself going to college again. But, if you are in the similar position, I hope this post helped you in making your decision.

5 reasons why Frontend Developers love GraphQL

Luka Kukina — Mon, 11 Oct 2021 13:09:39 +0000

Besides creating those beautiful UIs our beloved designers give us, handling complex application logic and component architecture, we as frontend developers work with a lot of data manipulating in the process. In this post I will talk about how can a frontend developer be more productive and have a better developer experience by simply using GraphQL.

Probably like most developers out there, I used to work with REST APIs and mostly enjoyed it, but recently I've got an opportunity to work with GraphQL and instantly fell in love with it.
Here are the reasons why:

1) GraphQL has only one endpoint

When working with REST APIs, you are surrounded with a lot of endpoints, as their configuration is based on the names of the application’s entities they represent. On top of that, each entity has different methods to manipulate its data (POST, GET, DELETE, PUT, PATCH). All that taken into consideration,
basic REST API will look something like the image below:

With greater complexity there will be more entities and more specific endpoints/queries...

GraphQL to the rescue 🎉 GraphQL uses only one endpoint!

GraphQL server operates on a single URL/endpoint, usually /graphql, and all GraphQL requests for a given service should be directed at this endpoint.

2) GraphQL is self documenting

Developing big applications, having deadlines, difficult or indecisive clients is a developer's everyday experience and to be honest, sometimes, documenting the APIs isn't the highest priority task. Because of that, developer’s productivity and developer experience (DX) may decrease as more time will be needed to understand what exactly a developer needs, it gets harder to onboard other developers on the project and so on...

GraphQL to the rescue (again) 🎉 GraphQL is self documenting!

GraphQL documentation will keep frontend developers up to date with all the changes that might happen.

3) No more underfetching/overfetching

RESTful APIs assume for us which entity's information should be coupled together as a whole. They don't look at the design of the application.
With that said, frontend developers usually get more information than what they need to display on the screen. This is called overfetching.
On the other hand, some screens need a little extra information that we don’t get with only one GET request. This is called underfetching. To overcome this problem, we will make another request to fetch the data we need.
OK, now we overcame that underfetching problem, but remember that we only needed a little more information, so we are now overfetching again (I can smell an infinite loop here 😅).

GraphQL to the rescue (and again) 🎉 GraphQL lets us query for the data that we actually need!

Send a GraphQL query to your API and get exactly what you need, nothing more and nothing less.

GraphQL is actually a query language (Graph Query Language) and it lets us write our own queries. This way we can look at the given design and decide what information we need to fetch. And it is simple too: queries are written in an object-like syntax where you specify the keys and get back the key-value pairs like on image below:

4) GraphQL playground

That brings us to GraphQL playground - GraphiQL. GraphiQL is a powerful tool that lets you test your queries, see the response, check out the documentation, schema and types for the needed fields. Everything is typed and it even helps you with autocomplete as a nice finishing touch.
All you need to do is enable GraphiQL in your backend (BE developer will do that) and enter your only endpoint into URL.

Example of a free-to-use Rick and Morty API below:

5) Apollo Client

Even though Apollo Client is not the part of GraphQL out of the box, it makes the DX much nicer (...and post title: 4 reasons why Frontend Developers love GraphQL wouldn't be as catchy). Apollo Client most importantly provides us with three easy-to-use custom hooks for manipulating the data: useQuery, useLazyQuery and useMutation.

useQuery - we use it when we need to fetch the data when the component mounts. It returns an object containing data, error if any and loading state.
All you need to pass is a query and options object (if there are variables, anything that needs to be done onCompleted etc.)

const { loading, error, data } = useQuery(SOME_QUERY, options)

useLazyQuery - we use it when we need to fetch the data on some event (for example on search button click). It returns an array containing a function to use on some event and an object with data, error if any, loading state.

const [fetchOnSearch, { error, loading, data }] = useLazyQuery(SOME_QUERY, options)

useMutation - we use it when we need to mutate the data. It returns an array containing a function to which mutates the data and an object with data, error if any, loading state.

const [fetchOnSearch, { error, loading, data }] = useMutation(MUTATION_QUERY, options)

Conclusion

GraphQL was created by Facebook developers and it is used by many big companies which means it is not going anywhere. So, if you are a frontend developer and looking for something new to try out - start with GraphQL, you might fall in love with it! 🥰

...For more in detail information please check the official GraphQL and Apollo Client documentations...