DEV Community: Tatiana

The Best Way To Learn Programming in 2022: Execute.

Tatiana — Thu, 30 Dec 2021 18:04:21 +0000

2022 is around the corner, and you might have come across this post because you're looking for a beacon, that one resource that is going to help you finally become a software engineer. You're probably looking to improve your personal financial circumstances. Maybe you're wanting to try something new. Or maybe you're part of the Great Resignation and want to move towards a remote-oriented field. Whatever your story may be, it's likely that you've been searching for the perfect resource, the silver bullet that will take you from zero to engineer in a certain amount of time.

I talk to dozens of people in that same situation daily. I spend a significant amount of time helping folks learn to program and realign their journey when they realize they aren't where they want to be. My advice is tailored, and I spend a lot of energy giving comprehensive feedback or roadmapping. It takes a lot out of me! Despite that, I love to help people reorient themselves with their goals. It makes me happy to help. However, the most painful part is when people don't execute. And (not) surprisingly, most people don't.

Whether it's friends asking me what to learn and how to learn, strangers on the internet wondering what path they should take, I always provide a comprehensive answer and step by step what I did that worked, and what didn't work. Unfortunately, most people never make it past the "gathering information" stage, and simply never start. Maybe they realized programming isn't for them- which is completely valid! Maybe they were overwhelmed by just how much it took to be a successful engineer. Also valid! Either way, it's incredibly common that most folks I talk to who aspire to become developers never actually take the leap and start.

Success Leaves Clues

Tony Robbins says "success leaves clues". While he's talking about personal finance in this case, this piece of advice is evergreen. If you see someone in a position that you want to be in, take the time to ask for a coffee chat and see what they did. Ask them what worked, and ask them what didn't work for them. Then follow it. Keep in mind that there's a difference between what they personally did to reach their goals and what they're selling to you so you can reach your goals, depending on who you talk to. Be discerning.

As a completely green beginner, whatever curriculum you are going to try to piece together for yourself made up from a handful of different resources is likely being informed by a lack of experience. Find a well worn path instead of trying to forge your own. Now, this doesn't mean you can't be critical of the resources that you're about to commit to and weigh them against one another (remember, be discerning), but if a resource continues to pop up across the internet as a highly reviewed and frequently used resource, you can likely trust its quality. Do your due diligence, but don't let analysis paralysis stop you from actually starting, because at the end of the day, even if a resource isn't absolutely perfect, getting started is going to get you further faster than not starting at all.

Make a Plan

A significant reason why many end up not executing is because they don't have a plan. You've chosen your course or resource(s) and... now what? Don't prevent yourself from executing. Make it a point to set aside X amount of time Y days a week- be sure to bake in some much needed breaks. Even 30 minutes a day is better than zero. While you cannot accurately predict the time it will take to understand the material, try to set some tangible goals such as: "I want to finish 3 lessons this week", or "I want to complete a project over the next two weeks". Hold yourself accountable to this plan.

You Don't Need To Go It Alone

Some people never start because they're overwhelmed with facing this journey alone. In some ways, a lot of people think programming is like track. A lot of people think track is an individual sport. I can see why- you run your own race all by yourself, jump by yourself, throw a discus by yourself. As a former track runner, this assessment always makes me chuckle because track is very much a team sport. Development is a team sport too. While ultimately reaching your goals comes down to your individual skill, similarly to one's ability to run a race, other people with this skillset on this journey are there to provide help and motivation.

The development community is rooted in helping one another achieve our goals, whether it's as a learner, or as a professional. That's why we have StackOverflow, or any number of subreddits about programming, and a significant amount of Discord and Slack servers focused on providing help and insight across various technologies and programming languages. Find a community to rely on and pay it forward when you know enough to begin helping out (this is also a great way to reinforce what you've learned!). You don't have to do it alone, and conversing with folks who are also in the process of learning provides a sense of community and belonging that makes it easier to walk this road and continue to push forward.

What Are You Waiting For?

With all this in mind, if you're seeing this post before January 1st, 2022, start already! Don't wait for the new year to start changing your life. If you've seen this after the new year has commenced and you haven't started yet, this is your sign to get going on that course you've been eyeing. You can change your life if you simply execute.

If you're looking for a resource, The Odin Project is an excellent way to jumpstart your programming journey in 2022 for free. We host a comprehensive full stack curriculum with two learning tracks to choose from and offer a large and active Discord community where learners can help and be helped. I know, I know. Just above I said be discerning and be careful of what people are selling you. But hey, we’re totally free, and just one course in a sea of awesome content out there. Whatever you choose, get started NOW!

Let me know what your plan to learn programming is in the comments below!

Photo by Sincerely Media on Unsplash

5 Things I've Learned 6 Months into my First Software Engineering Role

Tatiana — Thu, 18 Nov 2021 14:14:13 +0000

It has officially been six months since I started at my current organization. Every day I'm still in a bit of disbelief that I was given a dream offer from this amazing company. Sometimes it doesn't even feel like work, and I'm lucky to be in a role where I have an incredibly supportive team with tons of mentorship, an interesting stack that pushes me daily, and lots of learning opportunities.

Reflecting on the last 6 months, here are some things I have learned:

#1. It's okay to not know everything.

I did recently write a blog about this very thing, but I think one of the most surprising things I realized very early on in my role is that we truly all are in a state of constant learning. I was put onto a team that was sold to me as a team that "skews pretty senior", and as a junior from a self-taught background, I was highly intimidated. I didn't want to be the person on the team lacking knowledge in, well... everything. However, I learned pretty quickly through pair programming and team meetings that these senior devs on my team who had worked at these amazing companies and had many years of experience under their belt had the humility to admit when they didn't know something. And these admissions are frequent! It was humbling and exciting to be able to learn alongside my teammates and even learn how they approach learning something new after years of honing their craft. It was also exciting to be able to drop a few new pieces of knowledge to folks more senior than me as well! I have found the relationship to be oftentimes symbiotic, and the fears I had about not knowing enough to keep up with a nearly all senior team were mostly unfounded.

#2. It's okay to not ramp up at the speed of light.

My organization has an onboarding roadmap that takes about 3 months to complete, as an estimate. This was a relief because I was completely overwhelmed by the sheer scale of what I would be working on compared to my prior work in open source and personal projects. I had no idea how I was going to meet expectations. Ultimately though, it worked out. While all of the feedback I received indicated that I blew that schedule out of the water and ramped up much more quickly than expected, the fact that the roadmap was slated over the course of three months did reinforce that I was totally able to take my time, rather than throwing me to the sharks with unreasonable expectations for immediate productivity.

#3. Get comfortable being uncomfortable.

A new role means a new stack, new services, and a whole lot of areas of focus. I was highly uncomfortable (and still am) with a ton of the services and tools I am using. Ultimately I approach it with a growth mindset because it's not a deficiency, it's an opportunity. Circle back to point #1 above- these moments of discomfort are what makes one grow. I found that being in a near constant state of discomfort has helped me grow exponentially in my technical sophistication and understanding.

#4. The Necessity of Understanding Architecture (When It's Time)

This is something that was completely unknown to me prior to gaining a SWE role. And frankly, studying this wouldn't have been all too helpful given the context vastly differs between working on individual personal projects and large scale systems that serve thousands of customers. A lot of what I'm learning and the concerns they address wouldn't necessarily be relevant to the small scale items I was working on prior to getting my job, so learning them now with immediately relevant services in real time has been super helpful to my understanding.

I'm currently diving head-first into Kafka and event-driven systems, and it's a lot to wrap my head around. However by listening in on working groups, reading implementation specs, and taking the time to read documentation thoroughly, I see the value in carefully crafting a system at scale. Do I fully understand the consequences of particular decisions? No, but I am now cognizant of the importance of being aware of the impact my code can have not just for a feature or bug, but the application at large, and that I have to "zoom out" to truly see why.

#5. The Value Of Rest

I am a high achiever that is constantly looking for the next step. The next promotion, the next project, the next step in my professional development and personal skills. "I got the job! Great. What's next? What can I do?"

It's not in my nature to be "okay" with being "okay"- I care a lot about my craft and how I can be helpful whether it's at work, in my open-source endeavors, or personally. This gives me a bit of a workhorse ethic when it comes to programming. I spend a lot of time after hours and on weekends trying to up-skill or do something related to my personal and professional improvement. However, I recently have come to a reality check (meaning, my body rebelled and forced me to slow down). I cannot work "pedal to the metal", "foot on the gas" 24/7. I have to rest, or I cannot be my very best, and I have absolutely been feeling it for the past few weeks. I love being the best, but it's not realistic to be the best all the time, effort and energy naturally ebbs and flows, and I have to accept that in a mentally taxing field, I must rest. With that, I have implemented a tentative rule to not code after hours, only on weekends.

The Next Six Months

Now that I'm largely settled in at my organization, I'm looking to thoughtfully balance continuing to exceed expectations while honoring myself with rest and proper pacing. I hope to take this opportunity to build an entirely new service to gain an area of expertise within my organization and mirror some of the more senior individuals that I work with who also have a particular domain that they know intimately. Another major focus of mine is increasing my knowledge of TypeScript and ensuring I write extensible, reusable code. Now that I'm working on greenfield services, I'm hoping to fully get on board with best practices and existing patterns across our codebase and I'm taking each code review to heart without taking it personally because I know my team wants me to succeed.

The first six months have been a trip and I am so grateful to be at this incredibly supportive organization, but now it's go time.

I Spoke to A Handful of Aspiring Devs- Here's What I Found

Tatiana — Sun, 07 Nov 2021 21:50:13 +0000

As a self taught software engineer and maintainer of a large open source programming curriculum, a major passion of mine is giving back and helping other folks break into tech as programmers. While much of my day is spent assisting people with programming questions on Discord, I've started holding virtual "coffee chats" and have spoken to a handful of aspiring software developers looking to break into programming roles over the last week and a half. I find that having a face to face, one on one interaction allows me to gain a better picture of what these non-traditional developers are working with and aspiring towards compared to text based interactions.

Many of these individuals have gone the bootcamp route, but haven't yet clinched a role after graduating some months ago. Others are just starting out on the self-taught track and are looking for the right motivation and path to take. Despite being at different points in their journey, I found that there were some standout roadblocks or misconceptions that were shared amongst these soon-to-be engineers.

Here are a few areas of focus that I would like to share with you all that I'm seeing amongst those I have consulted with. While I am not a career coach or recruiter, I know what worked for me, and what absolutely did not. And interestingly enough, nearly all of the below items were things I found myself doing (or not doing) at some point in my journey that ended up being things that didn't work out for me, so these coffee chats often felt like looking in a mirror at myself from about two years ago.

Always Have Something In Flight 🛫

Most of the folks I spoke to had not programmed since the end of their bootcamps or courses, some of which ended months ago! As folks coming from a non-traditional background, we have a TON to prove compared to CS-degree'd folks. An amazing way to prove ourselves is to work on personal projects to show our skills and that we care about improving on our craft. This keeps your Github looking active and your skills sharp. If you're into working out, you know that your gains begin to atrophy if you go hard for a few months, then stay away from the gym for even just a few weeks. Your brain and programming is the same! Don't let your skills atrophy! "Dreams don't work unless you do."

Don't Limit Yourself to "Junior" Listings 💼

Another commonality I saw with those who were in the job search phase who weren't having much luck was that they often limited the job search to roles that EXPLICITLY ask for 0-1 years of experience, or use the word "Junior" in their titling. It's entirely possible to nab a job that asks for more than a year of experience, or doesn't specifically use the word "junior". Don't self-select yourself out of the running, let the recruiters do that- that's their job. The worst that can happen is you get a "no". In my own experience, every position I ended up interviewing for asked for 2-3 YOE. Titling can vary by organization (mine, for example, uses Software Engineer I to denote more junior engineers, but never actually uses the term "Junior" in any titles), so you may needlessly be missing some roles geared towards or open to those without experience.

See It Through, Don't Jump Around 📍

While I completely understand the urge to collect courses like Pokémon cards, I saw that folks were trying to juggle tons of courses and resources at once. They often heard that they "needed" to learn something else, or they needed to know even more in addition to what they were already trying to learn. They also frequently worried about not knowing enough to get a job. Splitting attention like this can be detrimental if you don't see something through to the point where you become proficient. Pick something and stick to it- see things through. I struggled a ton with hopping around to different courses and never really got GREAT and had something to show for it until I saw something through. Start one. Finish one. Rinse and repeat.

Find Your Lane 🚦

The final item here is something I identified after speaking with developers who were often towards the early stages of learning. More than a handful were interested in more than a handful of specialties! It's awesome to have varying interests, especially given that programming is such a broad field. But again, splitting that attention is going to slow you down. Do a significant amount of research (but be careful to not fall to analysis paralysis) and pick your "lane", or speciality. That might be data analytics. That might be cloud development. That might be full stack web development. But you will find it very tough to have it all and while casting the widest net may seem like an easy way to get a job, ultimately being an expert at one specialization is going to be much more realistic in achieving your goals.

Conclusion

We are all walking our own unique path, and my journey may look different from your journey, which may look different from someone else's journey. Although we are all unique, there are some evergreen items we can all work on in order to get to our desired destination in the most efficient manner, and get out of our own way of being successful!

Hot Take: You Don't Need To Learn Everything (Yet)

Tatiana — Thu, 04 Nov 2021 01:24:38 +0000

Learners often begin their journey with a simple Google search: "How to become a software developer". That search often leads them to complicated skill trees listing hundreds of different technologies and concepts, a swath of Reddit posts, Medium articles, and YouTubers that claim that you need to know the frontend, backend, DevOps, 3 frameworks, 6 languages, and every data structure and algorithm you can think of in order to become a professional programmer.

Job descriptions are no more helpful when a newbie is trying to understand what you must learn in order to become a professional. Similarly to the above skill trees, job listings are often notorious for listing nearly every technology under the sun for a role. In fact, it's practically a meme these days.

Not only is the idea that you need to know a heck of a lot to get hired discouraging, but it's unrealistic. And we should change the narrative.

Here's a little secret, for the uninitiated: you don't need to know everything- yet.

Git Gud

It can be overwhelming determining exactly what you should learn, given the above issues with skill trees and job descriptions. How can you possibly be proficient in 10 different technologies, languages, and frameworks? The real answer is- it's hard, nearly impossible to be good at everything. So what can you do to be competitive, then?

Answer: Git gud.

I argue that depth > breadth when it comes to gaining a strong programming foundation and working towards that first developer role.

We've all heard of the following phrase (most often only the first clause):

A jack of all trades is a master of none, but oftentimes better than a master of one.

I think the entire quote is valid, to a point. Developers inherently need to learn many different things in order to keep up with the ever changing landscape of technology. Being rigid in your stack might not be feasible when trying to reach for growth not only professionally, but technically. To be clear, I believe that in order to be a great developer, having the ability to learn a lot of different things is basically a requirement. So yes, as a professional, "oftentimes better than a master of one" is pretty key.

But when you're just starting out, fundamentals and learning how to learn so you can be that great developer who can quickly ramp up on different technologies is far more important than trying to split your attention between multiple languages and tools.

Let’s think back to that first clause of the above quote- “a jack of all trades is a master of none”. It’s very easy to learn the basics in many things, but to develop competency and prove that to employers means moving past those barebones basics. Similarly to tutorial hell, we want to avoid the trap of being a perpetual beginner, while still growing that mindset of being a perpetual learner.

It's all transferable!

Believing that learners need not learn every new framework and tool of the month prior to searching for a job, or during their initial learning does not mean that those learners will be less equipped as professional developers. It also doesn't mean that one shouldn't have that sense of curiosity about other technologies. Ideally, learners should strive to get into a mindset where they can easily transfer their skills in one framework or tool to another if they need to. What's important is you have strong fundamentals.

Core programming concepts are frequently transferable across languages. If you know how to write a loop in one language, it's really just a matter of learning the syntax to write it in another. You've done much of the heavy lifting of learning the concept of a loop when you learned your first language. At this point, it's all about making sure what you type is syntactically valid. At the end of the day, a language, framework, or technology is just a tool. But it's a lot easier to learn a new tool if you have strong skills and depth in another already.

The Rockstar Developer

As I said above, we've all become familiar with the "rockstar ninja master Jedi" job listings that seem to ask for 10 years of experience in tools that have been around for 5 years, knowledge of four different languages, and 3-5 years of experience for an entry level role.

I can understand the kind of anxiety this may inspire that leads one to believe that to have a shot at this field, you must know tons of different tools and languages. That said, it may surprise you that often these things are wish lists, or things you'll get paid to learn on the job. Now, is it great to know these tools, languages, and frameworks before you apply? Sure. That's absolutely a plus to know those things. But it's entirely possible to gain employment in roles outside of your preferred stack, and honestly, it's common.

In my own experience, I was all in on the MERN stack. I was targeting companies that used that stack, for the most part. I had multiple interview processes (even getting to the final round!) where the stack was not MERN. My current employer uses a completely custom front/backend framework, TypeScript, and CoffeeScript. The only thing I had in common was that they used Node and MongoDB.

I lacked confidence that I would do well in the role even though I knew my skills would be transferable. I got the job anyway despite not knowing any of those tools! I'm currently working with technologies such as Kafka and Redis, which are also completely new to me. Despite all of these technologies and tools that I didn't know prior to my role, I’ve been doing great. This isn’t to say that there haven’t been hiccups, but it’s nothing the documentation, drawing on my fundamentals, and asking great questions can’t solve. We should give ourselves more credit for being flexible and able to learn.

Conclusion

Being a developer is committing to a career of constantly learning. You'll probably find that you're learning daily in the first few months of your first job. It's more imperative to learn how to learn so you can tackle the novel challenges you will face as your team works on new projects, rather than trying to figure it all out ahead of time. You don't need to know everything in advance. You'll often find that your team, regardless of their individual seniority, is learning right alongside you, and if they're humble, they'll shout it from the rooftops.

That said, don't sweat it when it comes to facing what seems like a mountain of "need to knows". Are all of these things great to know? Sure, knowing things well can be very helpful.

But if you're just starting out and aren't strong in any given technologies just yet, laser-focus your learning commitments and get really great at some key skills. Express your skills through some really great projects. Honing in on fundamentals and core skills will pay dividends when the time comes to branch out after you get that first job, and propel you forward towards that first job much faster than splitting your attention amongst an impossible number of tools too early. Git Gud- The rest will come.

Let me know your thoughts about this searing hot take below.

How I Solve Problems At Work: A Guide For New Coders

Tatiana — Sun, 19 Sep 2021 17:57:22 +0000

Introduction

To preface, I'm a core maintainer at The Odin Project, an open source, self-directed, online programming curriculum aimed at beginners looking to code. We help thousands upon thousands of learners in their programming journey yearly.

A frequent issue we often see our learners have is that they become overwhelmed with starting the projects throughout the curriculum. We start learners off with very specific instructions for the earliest projects, giving them specific variable names and functions they should have in their code, but as they progress through the course we step away from that and allow them to figure out the implementation of required features with instructions that become more vague the deeper they get into the course.

This mirrors a real life work environment.   As some of you may know, as professional software engineers, we don't always get the full implementation of the required work in our tickets. For those who aren't yet there, a “ticket” sounds just like what it is, a ticket that describes the work that needs to be done, whether it’s a feature or a bug fix.

Most of the time at my job, those tickets tell me what needs to be done, but rarely how, unless I’m looking at an implementation spec for a new feature, which tells you the variables, functions, and fields expected so everything can work together without engineers just patching together a bunch of random code with no coherent style and structure. Even with implementation specs, there is still a ton of room for interpretation for an engineer. In short, most of the time a ticket will simply say what needs to be done, with a completion criteria that broadly outlines the expected behavior for the feature or bug fix.

So without explicit instructions, how do I actually tackle the problem at hand?

Read The Entire Specification First

The first thing I do is read ALL of the requirements carefully, I don’t start with hacking away at the first completion criteria and then work through the rest of the criteria. I need COMPLETE context for the entire ticket so I don’t code myself into a corner because how I implemented the first criteria may contradict the fifth. New learners may think that it makes sense to work through a problem step by step, but the goal here is to gain a high level understanding of the entire job at hand.

For example, I might get a ticket like this.

Title: Resume Upload in XYZ service

Description: Add functionality that parses and uploads candidate resumes to S3, and adds the parsed candidates to the job.

It’s very bare bones, and tells me what needs to be done, but not necessarily how. That’s up to me as an engineer to implement. In this case, in real life I may have an implementation spec which adds more detail about expected functions and schemas, but for the sake of the example we'll keep it simple.

Breaking It Down

This barebones explanation in the ticket is great though, because there are multiple things that need to be done here.

Parse resumes
Upload resumes
Add candidates from resumes to the corresponding job

This gives me a great point to start at as far as writing out my pseudocode. They’ve already given me the general steps for what needs to be done. My pseudocode breaks this down even further. For our self directed learners at TOP doing these projects (or any time you have a personal project and you're stuck trying to actually implement a feature), you have these broad steps and you need to break it down even further to be able to effectively begin to solve the problem.

Pseudocode!

After understanding the scope of the work and what should be accomplished, I move onto looking to solve the problem. From here, I need to pseudocode before touching any actual code. For me, this means using comments in my file(s) to write out "instructions" for each piece of my feature or the solution for my bug fix. There are no rules to pseudocode! I use comments so it's easy to code along (more on that later), but pen and paper works, or your note taking app of choice works too!

As mentioned, I write down each individual step of what this piece of the application should do in plain English. I’ll possibly write the function names (which are not set in stone at this point) and add comments inside of those functions which describe very broadly what they should do. I am not worried about ANY code at this time, except for having in the back of my mind what something could look like. I don’t want to confuse myself with the details quite yet.

/* processResumes.js */

function uploadToS3(){
   // uploads to S3 bucket
}

function parseResumes(){
  // iterates over each resume

  // uses parsing library

  // creates candidate for job

}

  function submitCandidates(){ 
  // adds candidates to job
}

I broke down some of the steps into separate functions (which are not set in stone, they could be broken down more as I develop the feature), and I’ve written what they should do. I’m still not touching any code, I’m focused on tasks at this point. I’m not super focused on implementation itself, aside from a general idea of what functions might be needed and what they might be responsible for doing. But the key here is breaking things down into pieces in plain English (or your language of choice). I use "might" because at this point, the implementation is still shadowy and subject to change as I do more research into the task at hand.

I Broke It Down -What If I Don't Know How To Accomplish This Task?

Now, I have no idea how to upload anything to S3. Never done it before, but the following steps would equip me with the ability to learn. As a professional developer, I like to say that my actual job is reading and researching, not coding, and that my role is "problem solver", not "programmer".

My first order of business is probably going to be the Amazon S3 documentation. Any time I know I need to use a tool that I'm unfamiliar with, the first instinct is to check the docs.

Now, that might not pan out as my solution because my job might have a helper utility that does a lot of the heavy lifting for me. I will help me understand the tool better though! If that's the case, I'll look around for internal documentation about how we upload to S3. As a learner, unless you're using a library, you don't need to worry about this, the official documentation is king.

After 30 minutes to an hour, if I’m stuck and I’ve looked on StackOverflow, looked at our code base to see where else we upload to S3, and checked Slack for prior conversations about the subject and I just don’t get it, I’m going to ask questions to get unblocked.

Of course, in your personal projects and as a learner you don’t exactly have this luxury of internal documentation, an existing codebase, or Slack, so you might just jump to asking questions to get unblocked after doing your own research. No shame in asking questions, across my organization no matter how experienced an engineer is, they are asking questions likely daily.

Ask Questions

The goal of asking a question is to clarify where you’re stuck, and get unblocked so you can move on. I go into asking questions with an end goal in mind, remove whatever blocker I have in my understanding, not just of the work at hand so I can move forward. Before I type up a question, I frequently refer to this article to help formulate a question. Sometimes I find that as I follow these tips to form my question, I answer it myself!

From there, ideally I ask my question in the Slack (for a learner at TOP, this may be our or another Discord community), get it answered, or ask clarifying questions if it’s still unclear. Then I ask for resources if I’m still stuck on a broader concept. If I’m no longer stuck, then I get to the actual code! From there I translate my English pseudocode into real code.

Finally, let's write some code!

Let's consider the parseResumes() function above.

function parseResumes(){
  // iterates over each resume

  // uses parsing library

  // creates candidate for job
}

 In my pseudocode, I mentioned that I need to iterate over every resume. I can easily correlate that "instruction" to a loop. After, I know that I need to create a candidate from the parsed resume, so I know I will need to create a Candidate here and pass in the info from the parsed results. This gives me a good foundation to begin writing actual syntax.

 function parseResumes(resumes){
  /* I know I'll have multiple candidates from multiple resumes
so I choose to initialize an array */
  const candidates = []

  // iterates over each resume 
  resumes.forEach(resume => { 
    // use parsing library
    const results = parsingLibraryMethod(resume)
    // creates candidate for job
     const candidate = new Candidate(results)
    candidates.push(candidate)
  }

  return candidates 
}

  Notice how writing my code alongside my comments helps inform what syntax I should be using? I tell learners that planning your code in this way is a requirement before you touch any syntax. We need to know where we're going before we can start driving, right?

Conclusion

Of course, things are subject to change as I work through the issue, but using all of my resources and planning out a high level overview of what my code should be responsible for helps me ultimately be more productive and helps me figure out problems I may ultimately not understand at a first look at the requirements.

TL;DR, read all of the instructions first for context, ask questions and do some research if unfamiliar with how to approach a problem, and pseudocode in plain English (or your native language) what your app should be doing in order to break it down further.

Photo by ALAN DE LA CRUZon Unsplash.

Understanding the concept of state using Pokémon and React!

Tatiana — Tue, 18 Aug 2020 04:23:54 +0000

Struggling With Defining State

As a beginner, one might find themselves trying to wrestle with understanding the concept of state- something seemingly high level, and often Google search results are linked to popular frameworks and libraries such as Angular and React, which can sometimes feel out of reach as a beginner.

State is often used to define itself through circular definitions such as: "State refers to the state of your application or component!" Super helpful, right?

Or, we get solid definitions such as those found in Wikipedia's article on state:

In information technology and computer science, a system is described as stateful if it is designed to remember preceding events or user interactions; the remembered information is called the state of the system.

"Similarly, a computer program stores data in variables, which represent storage locations in the computer's memory. The contents of these memory locations, at any given point in the program's execution, is called the program's state."

For a super green beginner, the language may be overwhelming and a little too "techy". Stateful? Memory locations? Especially with web dev, where computer science concepts can often be glossed over in the beginning of one's learning journey, this can seem like a little too much to chew on.

The fact of the matter is, state is a relatively simple concept, but this simplicity may be the root of unclear explanations especially when someone experienced explains it. For those of us who are no longer green, we lose the "beginner's eyes" we used to have and often end up confusing a beginner even more with our unintentionally higher level explanations.

We will explore state in the context of a Pokémon Battle. While I will relate this example to state and give a very barebones example of how it is used in React, this article is less concerned with the best practices of React, Hooks vs no Hooks, functional vs class based components, state management, or even the code itself- we are strictly concerned with explaining the concept of state in a manner that is easily digestible.

Pikachu, I choose you!

To set the scene of our battle: we have a PokemonBattle component, which is the "stage" for our actual battle. We have two Pokemon components, each with a specific Pokémon and its information loaded into them.

<PokemonBattle>
    <Pokemon selection = {Pikachu}/>

    <Pokemon selection = {Squirtle}/>
</PokemonBattle>

Inside of our Pokémon component, we have our sprite, our health points bar, a box to hold our Poké's moves, and a box encapsulating our health points and any potential status conditions. This component may look a little something like the below:

<Pokemon>
    <HPBox hp = {this.state.hp} status = {this.state.status}/>

    <img src = {this.props.selection.imageSrc}/>

    <MovesBox moves= {this.props.selection.moves}/>
</Pokemon>

Visually, this is rendered as:

Looks pretty familiar, right? (NOTE:I know, this is a Charmander, but hey, Google Images was doing me dirty when putting together screenshots 🤷🏾‍♀️)

Right now, our state for each class-based component Pokémon is initialized in an object inside of our constructor like such:

state = {
    hp: 30,
    status: null
}

This object is the location where our the state of our individual components will be held. Our components will read their own state objects, and behave a certain way based on that state, whether this is visually or functionally.

Remember:

"Similarly, a computer program stores data in variables [...] The contents of these memory locations, at any given point in the program's execution, is called the program's state."

Hopefully, the above is starting to make a bit more sense! Our state object lives in each Pokemon component, and serves as the "data in variables" and "content" from the above definition.

Let the battle commence, and the state change!

Now, if you're familiar with Pokémon, you know that Pikachu is an Electric type. This means it has access to awesome moves like Thunder Shock, which has a high chance of paralyzing your opponent with a status condition of paralysis.

Pikachu, use Thunder Shock! (I know, this is also not a Squirtle. It's a Wartortle though, so close enough.)

We command our Pikachu to use Thunder Shock, and now our opponent is paralyzed. Previously, the Pokémon component holding our opponent had a state that included a property called status set to the value of null. When Pikachu used Thunder Shock, the code that was triggered updated the state of our poor Squirtle to:

state = {
    hp: 15,
    status: 'paralysis'
}

Our component holding our Squirtle will re-render, and now we can see a little widget showing a paralysis status in our HPBox sub-component!

State is dynamic, it holds values that we expect to change. This change then affects the behavior or look of our application or components.

In the above screenshot of the paralyzed Squirtle, can see the way state has affected our component. Our Squirtle now has a visual icon reflecting the status affliction in our state, and our poor Squirtle might not be able to move! So not only has our component visually changed, but some of our functionality is now limited due to the paralysis value being held in the status property inside of our state object!

Let's go back to Wikipedia's definition for a second.

a system is described as stateful if it is designed to remember preceding events or user interactions; the remembered information is called the state of the system.

We can liken this to our state object "remembering" that our Squirtle was hit with a move that ended up paralyzing it. After all, it was a preceding event and user interaction that affected our Squirtle's state in this way.

Hopefully by this point, you are now able to view state as the current condition or status of your application or component as affected by certain event in the midst of using an application, similarly to the way a Pokémon may be afflicted with a certain status condition in the midst of a battle.

Squirtle's Revenge

Real Pokémon fans know this is a bad matchup. Squirtle is at a clear disadvantage as a Water-type versus an Electric-type. But our clever Squirtle has a trick up their sleeve: Rock Tomb, a move that doubly damages Electric-type Pokémon, just like Pikachu. Through a stroke of luck and RNG, Squirtle escapes paralysis, and the state of their component is reverted back to:

state = {
    hp: 15,
    status: null
}

Squirtle may now execute the selected move, Rock Tomb.

Pikachu, however, isn't so lucky. The super-effective move has completely drained it of its health points!

Our Pikachu's state is now as follows:

state = {
    hp: 0,
    status: null
}

Based on our Pikachu's state, the player can no longer pick any moves, and at this point, our battle is over! The entire time, state has dictated the our battle, and our application at large.

TL;DR

It may sometimes be tricky to pin down a specific definition for state, and oftentimes those who are experienced may explain state in a way that might be a little too dense for someone totally green. My aim is at this point, you can conceptualize state in the context of a Pokemon in battle! State can be viewed similarly to the condition of a Pokemon in a battle, with the current health points, status conditions, and the like being dynamic and affected by a user's input. The condition dictates what we see on our screen, and what kind of things we can do with our Pokemon.

You can now run Github repos on Repl.it!

Tatiana — Thu, 12 Dec 2019 17:49:53 +0000

Repl from Repo

As someone who is still learning to code and is often doing so in a situation where I don't have access to my local files or a code editor (hint, hint, at work during my downtime on the organization's device), I've been using a similar in-browser editor to test ideas or work on my projects. I recently "discovered" repl.it because I needed an editor that could run Python or Node.JS in browser as I shifted my learning away from the front end HTML/CSS/JS combo. Repl.it has a ton of languages to choose from- even some "toy" languages like LOLCode. Even better, they just leveled up their Github integration.

I am pleased to find out that today they began rolling out "Repl from Repo", which allows you to run repos within Repl! It looks like they're still fleshing out the functionality, but it sure does feel good to have another avenues to run my projects and build them in scenarios where I don't always have access to my personal device or files. Even better, all of the repos where I'd have to download them and configure an environment are also able to be run through Repl, so I can easily try out cool looking repos from all types of languages without the commitment of a full on download.

You can now also add a "Run it from repl.it" badge to your README.md's on Github, which gives folks an instant link to run your project! Try it here with a game of Minesweeper. Be sure to click "Run" once repl.it compiles the project.

See more about the functionality in their blog post!

Breaking the "Wall of Awful" to get through the first 30 days of #100DaysofCode!

Tatiana — Wed, 24 Jul 2019 16:52:09 +0000

Selective Brilliance

Being 22 years old and being told that no, I am not lazy, and that my selective brilliance in academics didn't mean I just "didn't get" certain subjects, but instead that I had ADHD has been like getting a new pair of glasses. I can finally SEE. Granted, I could see before, but now everything is in crystal clear 4k.

Of course, being brought up in a culture that "doesn't believe" in ADHD, or other mental health issues for that matter, meant that the diagnosis was bittersweet. I was never the hyper wild child that couldn't be tamed at school or in the grocery store. Not the type of kid you think of when you think of a kid with ADHD. But I am constantly forgetful, have a spending problem, and feel the extreme urge to go down the Wikipedia rabbit hole at 2am because I just have to learn about the advent of fracking at that very moment. While I am still wrestling with my diagnosis and how it has unknowingly informed my upbringing and experiences, I am realizing that it also gives me the tools to tackle my next endeavor: coding.

I am notorious for having a new passion every other week. I recently found out that this behavior is prevalent in ADHD folks. Every new hobby is your new passion, every new exciting career path is "it" for you. Every new endeavor is the endeavor to end all others, until we typically get bored of it, or frustrated with the lack of instantaneous results, or it gets too difficult. Rinse and repeat. (This is called hobby jumping.)

Diving into Coding... Again

This is probably my third or fourth foray into coding. Each time I started with resources such as Codecademy, and Free Code Camp. They are great resources for beginners- but maybe not for neurodivergent folks like me who learn differently, and think differently than most folks. Many ADHD folks need structure to thrive, but simultaneously reject that same structure if it becomes to overbearing.

This need for some structure, but not too much, brought me to Udemy. As a complete beginner with some experience working in tech (IT project management and startup social media management), actually coding is such a broad topic with so many different subsections that it can get overwhelming. With ADHD in mind, this also leads to never actually starting anything. We tend to over research and consider 14 million possibilities before we actually execute. With a course being taught by an actual human who has hand picked the curriculum, I can self pace and follow a specific pathway at my own discretions. However, this hasn't stopped me from dying to try out Javascript, oh wait- Python, oh no, Swift- wait, let me buy 10 more courses that I won't start for another 3 months! Or let's try every CSS framework possible!

For folks with ADHD brains, we can often get caught wanting to do anything and everything, which leads to never doing anything. But once we finally stick to something, we have another barrier to break through- the Wall of Awful.

The Wall of Awful

The point to this needlessly lengthy post is that for folks with ADHD, we need to find our sweet spot to get over The Wall of Awful. The Wall of Awful is the reason why folks (with and without ADHD) can find it incredibly difficult to move forward with certain tasks. Sure, walking the dog takes about 5 minutes. But it's a painful process to will yourself into getting up, wrangling the dog, taking the dog around the block, and getting back up those stairs to your apartment. We can just put it off until Puppy Dog is whining so hard it could break hearts. Much easier than, oh, actually putting in some effort into something. You can see why with coding, and the time and effort it takes to truly learn and create something, this wall might be difficult to climb over. It is incredibly easy to just say, "I'll code tomorrow. I'll do my course tomorrow." But that stifles and destroys any progress I may have made.

How Have I Combated The Wall of Awful?

For me, accountability is key. I currently use the app Super Habit for iOS that tracks my "habit" of #100DaysOfCode. It's incredibly fun for me to see a little Github style streak view- seeing that momentum is what keeps me going.

I also have downloaded Flora, which is a Pomodoro style app where you can create a garden grown from all of your time spent "focusing" in the app. I feel like a terrible person every time I kill a tree after using my phone while a timer is running, so you could say it's pretty good motivation to stay off of my phone while I'm trying to code or learn new concepts.

I also have taken to publicly holding myself accountable on social media. I tweet constantly about my coding journey in between my tweets about activism and pop culture. I post on LinkedIn every time I hit a milestone. I have a coding highlight on my Instagram story and profile. Hell, even Facebook knows. Knowing that I have thousands of eyes on me if I suddenly drop off of my journey helps- why face the public shame of failing at something I went so hard for on social media for days at a time? Oh, the horror. Think of the likes I'll lose. /s.

That's nice, but what about your actual coding journey? That's why I'm reading this.

I've had this post in my drafts for weeks since joining Dev.to on my first day of code on 6/14/19. On Monday I hit my 30 days of #100DaysofCode. In that time, I have re-learned HTML and CSS (I spent a lot of time in my youth on Neopets and Gaia Online "coding" my profiles), and I am delving into Javascript. I think I have found a lover in Javascript- it's mindnumbingly difficult for me to switch gears to solving problems that require math after coming from a humanities and social science background, but my ADHD hyperfocus forces me in the best way possible to keep trying until I find the solution. You seasoned programmers call it "flow". I found the flow last night while attempting to recreate dev.to as an HTML/CSS exercise. There is no better feeling on this journey I've taken towards becoming a web developer.

In all, I think I have finally found "it" in coding. 30 days is the longest I've stuck with a hobby that I wasn't forced to stay in (I'm looking at you, piano and dance). My journey might be a little more difficult than neurotypical folks- I might have to review basic concepts a smooth 5 or 6 times more than an NT person before it sticks (and even then, it might not stick), I might have to rewatch a tutorial over and over and over again, and I might have to miss the glaringly obvious lack of a closing ()/{}/[]/; for an hour or two due to my infamous speed and carelessness, but it's the hunt for a solution that keeps me going.

Also- shoutout to r/ADHD_Programmers for being a community where other ADHD brains can congregate and bond over the common experience of moving too damn fast to catch up with yourself.

Here's to the next now 69 days of code!