DEV Community: Mira Marshall

5 Things I Wish I Knew Before Learning How to Code

Mira Marshall — Thu, 09 Dec 2021 15:51:18 +0000

In 2019, I switched careers from being a lawyer to a software engineer. Here are some lessons I've learned over the last few years and will continue to reflect on throughout my coding journey.

1. It's Not Too Late to Learn How to Code

I was not one of those people that started coding when they were 8 years old. Other than customizing my My Space profile in middle school, I did not become interested in learning how to code until I was in law school. I'll admit, there was a bit of uncertainty starting, but once I got involved in different coding communities, I saw that there were many people in similar situations. Some were like me and switching careers in their 20s; others had families and children, while others had careers in other fields for decades and decided to learn how to code. So no, it's not too late to learn how to code.

2. Slow Progress is Still Progress

Learning to code can be pretty overwhelming, and I realized early on that a considerable part of software development is learning new things. If I could tell my former self something, it would be to take a sustainable approach to learn new concepts. Even if that's just 30 minutes of learning a day, that is still progress. Those small increments of consistent learning add up over time, which brings me to my next point.

3. Segment Your Learning

This concept of segmented learning is something that I continue to use when I learn new technologies. I will take a large concept and then break it into smaller portions to make learning more approachable. For example, when I started learning React, I broke up learning into smaller pieces. I'd spend a learning session focused on function components, then that would turn into another segment about state management, then a segment on React Hooks. I would take an extensive library like React and break it up into different features to make learning those features more manageable.

4. People Want You to Succeed

People want to see you win. There are communities of people who want to help you along your coding journey. Some examples are organizations and communities like Free Code Camp, Ada Developers Academy, Frauvis, and Write Speak Code. There are also more informal tech communities: don't underestimate the power of free resources on platforms like YouTube, DEV and Twitter! A lot of people on different platforms want to see you succeed and have provided resources to help.

5. It's Okay to be Selective When Interviewing

Everyone says that interviewing is a two-way street, but that is much easier said than done. When I was looking for my first full-time position in tech, I was so focused on getting my foot in the door that I didn't take a more critical look at the companies and teams during the interview process. Now that I can reflect on that time, I wish I had been more selective with the teams and companies I interviewed with. I'm happy with where I ended up and work with great people, but I think I could have saved myself some stress by focusing on interviews with teams and companies that I was interested in, not just focusing on getting a job in tech.

I'm still in the middle of my journey and have a long career ahead of me. What are some things you've learned that could help someone along their coding journey?

What is a REST API?

Mira Marshall — Sat, 04 Dec 2021 02:22:49 +0000

An introduction to RESTful API design.

So what makes an API RESTful? I’m sure the term REST API or RESTful API has come across your screen countless times in your coding journey. This article gives an introduction to RESTful API design principles.

Before diving into the six constraints, I’ll briefly describe what an API is and how REST APIs work. API stands for Application Programming Interface. REST stands for REpresentational State Transfer. It is an API architecture with design principles for client-server communication and features.

RESTful APIs communicate through HTTP requests to perform CRUD (create, read, update, and delete) operations in a resource. These operations correspond with method requests (GET, POST, PUT, DELETE). A POST request adds information, a GET request retrieves information, a PUT request updates information, and a DELETE request deletes information. An API that follows the six constraints outlined below is considered RESTful.

The dissertation by Roy Thomas Fielding coining the term REST API can be found here.

1. Client-Server Independence

In RESTful design, the client and server must be distinct from one another. The client requests information with a Uniform Resource Identifier (URI), and the server responds to the request through HTTP/HTTPS. Both the client and server should evolve independently. This independence allows for scalability on both sides.

2. Stateless

The Stateless constraint means that the client state is not stored between requests. The request from the client provides the server with enough information to understand the request without needing to remember any client state. Not storing data about the client request improves scalability.

3. Uniform Interface

A Uniform Interface ensures standard client-server communication across platforms. With REST API architecture, a request for the same resource should have the same data. As well as response status codes from the server such as 200 ok, 401 unauthorized, etc.

4. Layered System

The client does not always communicate directly with the server. There may be layers of communication. For architecture with several layers, each layer only knows about its immediate communication layer. The layered system allows for intricate tasks to be completed without needing to understand the complexity of what is being done to receive a response.

5. Cacheable

Cacheable data is information in the response that can be stored and used later.

Server responses should declare if the data is cacheable. For network efficiency, the data in a response from the server is either implicitly or explicitly labeled cacheable or non-cacheable. For cacheable data, the client can reuse the response for future requests.

This constraint improves performance for clients while reducing the payload and improving scalability on the server.

6. Code on Demand(Optional)

The final “constraint” is optional. Code on Demand allows for logic to be sent from the server to the client for execution. The server can send some executable code to the client. For example, if an API sends a < script > tag in its response, the client will execute the JavaScript.

There you have it, the six REST API architecture constraints. Hopefully, this helped fill in some knowledge gaps or gave you a good refresher on RESTful APIs.