Welcome back for another post in this series about becoming a software engineer. I'm a month behind on my post 😅, but some progress is better than no progress. Let's leave the banter out and get straight to the meat.

Highlights

• 179 kata completed to date on Codewars and a rank of 5kyu (595 honor points)
• Still struggling with keybr
  • Average speed of 34.7 wpm
  • Unlocked all lowercase keys
• Worked on updating my resume
• Attended a Twitterspace put on by Rizèl Scarlett about Developer Relations roles
• Read about Objects
• Read about the OOP
• Learned the first bit about API's
• Watched a good video on RegExp
• Listened to a cool National Geographic podcast episode about repurposing old cell phones to listen for illegal logging.

Resume Revisions

We had a class this week in #100Devs which covered some things to look for and avoid in resumes. The emphasis wasn't on making a resume that will get through the application algorithm, but rather will get you past the sniff test when a friend refers you for a role. Here were my main takeaways from the class:

• Your summary should hit hard and be 3 sentences max. Most people are going to spend more than a few seconds reading it.
  • Currently my summary reads like this:

    Creative, software engineer with a passion for developing efficient solutions to complex problems. A deep interest in AI, Open Source, and working with diverse teams to advance big ideas. Looking to bring my skills to a company with global reach where I can have a global impact.

• Don't include your photo
• Don't put your location, let them ask
• When talking about personal projects, use verbiage that frames it as delivering to a client.
  • ❌ Note-taking app
  • 👍 Quik Notes: Users can login to their profile and find their list of notes. They can add new notes through an input, which they can then edit or delete all notes in their profile.
• Make sure project names don't sound bootcampy.
  • ❌ Slot Machine Game
  • 👍 Windy River Casino Virtual Slot Machine
• Leave soft skills or trivial skills off the resume (Microsoft Word, Team Player, etc.)
• Lead with your summary followed by your employment experience.
• Don't do a deep dive when describing projects. Leave the technical details to a technical interview.
• Leave certificates off unless they are of high value and apply to the position.

Twitter spaces

I saw a twitter space that Rizèl Scarlett from GitHub was putting on about the Developer Relations role that is becoming more widespread in companies. There were three experienced people from the industry that joined the conversation: Ian Douglas, Kurt Kemple, and Brian Dorsey. I found the topic pretty engaging as I had heard the term DevRel thrown around a bit, but had no idea what it was. Seems like I could've googled it and found this simple definition from Wikipedia:

DevRel is an umbrella term covering the strategies and tactics for building and nurturing a community of mutually beneficial relationships between organizations and developers

A key point that Kurt made when going after a role in a company was to do your research on the company. In particular:

• If the company has a blog, read it
• If there are changelogs publicly available for the produce browse through them.
• Build something with the product
• Find people in the community using the product and ask them about their experience

Objects in JavaScript

The objects reading I did mostly covered the four pillars of OOP:

• Encapsulation
• Abstraction
• Inheritance
• Polymorphism

Encapsulation

Putting data and the functions to manipulate it inside of a "package" to isolate and abstract it. The user of the "package" (aka object) doesn't need to know about what has been encapsulation only the interface to use the data and functions.

Abstraction

This is very intertwined with encapsulation. Essentially you hide the inner workings of something and give some sort of simpler to understand interface to interact with that something.

Inheritance

Objects can inherit data and functions from other objects or classes. You can have a class of Animal where every animal has an age and favorite food. Then you could have a subclass of Dog where the number of legs is four and each dog has a breed. The cattleDog object created with the Dog class would inherit age and favorite food from the Animal class and also have the number of legs = 4 and a breed of 'Cattle Dog' from the Dog class.

Polymorphism

This one has been the most difficult for me to understand. From what I've read it is the ability of a class to have a method of the same name defined for itself. For example, we could have a class of Animal and a class of Dog:

class Animal {
    blink() {
        console.log('blink! blink!')
    }
}

class Dog extends Animal {
    blink() {
        console.log('wink! wink!')
    }
}

Any object instantiated with the Dog class would wink when the blink() method was called, even though it inherits blink from the Animal class.

RegEx

While doing my daily codewars challenges I started to see more and more regular expressions being used in the solutions. Even though Leon told us to ignore them and not use them as a crutch I wanted to learn them so I could better understand the solutions. After reading some articles and not really understanding I watched this great video by Corey Schafer.

After watching that video it clicked much better. I'd suggest pulling up some sort of RegEx sandbox while watching the video and do the examples along with him. Of course, I haven't memorized all the syntax of RegEx, but I can head over to the MDN cheatsheet and understand what I'm looking at!

Technology and Nature

The last thing for this week I'll share is this excellent podcast episode from National Geographic. The work that Rainforest Connection is doing is the exact type of stuff I'd like to work on in the future. Take modern machine learning and AI, pair it with "outdated" tech like old cellphones and place it in tree canopies. Boom! You have a cheap way to monitor for illegal logging activity. Hearing about the merging of technology and nature is truly inspiring!