Forem: Live Long & Ponder

How I Found A Weapon Against Imposter Syndrome

Live Long & Ponder — Sat, 30 Dec 2023 01:08:53 +0000

From PM to Engineer to Interior Designer, imposter syndrome can be found anywhere

Back in school, it was easy to track how well I was doing.

I had conferences, grades, constant teacher feedback, and comparisons with my friends.

With all those in mind, I could focus on certain areas and adjust as necessary.

Reality hit me hard when I got into the “real world”.

A real job with loose expectations and little feedback.

I began to think I wasn’t doing well since no one was there to give me a grade or tell me I needed to do something different.

Working hard is great, but I realized I didn’t understand if my hard work was up to snuff or if I had optimized processes.

This process grew into my ever-dreaded IMPOSTER SYNDROME.

No Feedback Feeds The Imposter Monster

I wasn’t aware of how well I was doing my work, and began to compare myself to people around me. “Oh this person is doing so much work, I must be doing something wrong”.

Instead of asking others about their habits or schedules, I looked only at their output.

I may have been doing well, but couldn’t convince myself that was true.

This meant I was comparing my whole stack of work, to only a layer of theirs.

This isn’t ideal, but I was young and too afraid to ask questions at the time.

I continued this cycle until I moved on and became a PM and a leader of a team.

Learning How to Give and Receive Feedback

As a new PM I had no idea what I was doing.

I was an emergency fill for someone who spent a day bull-rushing through everything he could think of, then handing me the reins.

Oh yeah, and a massive deadline was one week away, perfect timing.

Luckily I had a group of experienced teammates I could rely on. They helped me get up to speed and were very open to telling me when I was wrong.

I learned I could no longer operate in a silo the way I used to, and sought to fix that.

We started 1:1 feedback sessions called “slowbacks” every Friday. It opened my eyes to what was missing.

Some of the first feedback I received was:

You seem like you’re afraid to fail, don’t be
Have more confidence
Approach unknowns with humility
Ask more questions

This woke me up and I still have DON’T BE AFRAID TO FAIL as a note on my home screen.

Personalize a Feedback Loop to Tame the Monster

Learning how to give and receive constructive criticism gave me a confidence boost.

I wanted to ensure that the application of these practices worked in any new team or position.

It’s not realistic to think I’d always have helpful teammates or a group accustomed to the practice of feedback.

I needed a personal system.

To do this I needed goals to measure my growth.

I started by setting some personal goals, using the techniques I wrote about here:

How a Personal Trainer Taught Me to Tackle Difficult Goals

Now I needed some way to check in on my goals.

One of my goals was to become a better frontend developer and moved to a new team for it.

Our team didn’t have specified time for feedback so I had to create my own.

I established my goals with my lead, and I began to sometimes ask for feedback. No set meeting, but asked whenever there was availability.

I would steer the questions towards my performance in certain areas given my focus each week. This would help me hone in on specifics, rather than receiving a general “You’re doing fine/bad”.

I came out of each session with notes to take back and examine against my goals.

Relevant notes would help adjust my scope all with my personal growth in mind.

There was a noticeable change in my positional confidence.

The sessions served as guardrails to help guide me to improving not only as an individual but as a teammate.

I understood my role better and had actionable steps to take for improvement.

After a while, this sort of transparency started to permeate through the team. More and more people shared where they wanted to grow and started asking for feedback.

Now we are working to make a more regular schedule for each teammate.

Everyone wants to get better, sometimes we don’t know how or when to ask.

This works great if you’re in a team, but is more difficult in positions where you may be the sole producer.

In this case, you can still garner valuable feedback, with more reflective effort.

Take time each week to review all the tasks you had.

If they were set by you were they valuable and effective?
Can you replace some?
Can you take on more?
Can I show my work to an unbias party for assessment?
Was this work pushing toward my end goal?

The person you’re asking will be yourself, and you will have to be objective about your work.

Treat it like a second-self holding you to higher standards, and ask a lot of introspective questions!

Conclusion

Imposter syndrome can manifest in many ways.

I let it seep in by working in a silo.

To help fight it you’ll want to establish goals and guardrails to keep your eye on the prize.

Don’t be afraid to ask others to help keep you on the right track, by being open and honest about your goals. It may inspire others to do the same!

If you’re in a place where you don’t have the luxury of outside feedback, set aside some time for personal reflection. Take time each week to look at your recent work. Ask objective questions to pull out the true value of your work.

Imposter syndrome is something everyone feels. Being willing to take it on can be rewarding for individuals and teams alike.

How have you fought back against Imposter Syndrome? Let me know!

This Article was originally posted on Medium

…Until Next time =)

Note-Taking Weapons I Use to Tame the Tech Beast

Live Long & Ponder — Thu, 21 Sep 2023 19:37:38 +0000

Tools to boost your productivity to conquer the workweek monster

In this modern era, almost everyone has multiple computers around their house.

Problems are now solved by devices specifically crafted for that purpose.

Want to play games with the highest possible graphics? Build a powerful PC.

Want to work while traveling? Get a lightweight laptop.

Do more design while traveling? Get a 2–1 tablet/laptop combo.

Want to play games on the go? Get a Switch.

Combine this with machines issued by companies, and you're left with many devices spread across your household, with all your thoughts/notes spread across them.

I've found this problem infuriating as I want all my notes to be consolidated in one place so that I can reference them easily whether I'm on my PC, work laptop, phone, tablet, or home laptop (it's too much I know).

I think other people struggle with this problem as well, so I wanted to share a few tools that I've found useful that help me fight back against the multi-headed hydra of technology. (Not affiliated with these in any way, just enjoy using them)

Gitbook

Gitbook has come a long way since I started using it, but it's a helpful tool that you can use to keep notes across devices.

I've used the free version extensively and enjoyed the ability to create multiple sections to keep my thoughts separate, but accessible.

For example, I created a section dedicated to learning used to keep track of notes and other important topics related to my technical growth.

As I've talked about before I've moved into a programming position which comes with a firehose of information.

The “Backwards” Journey From PM to Engineer: Why I Chose Code | by Live Long & Ponder | Jul, 2023 | Medium

Live Long & Ponder ・ Jul 24, 2023 ・
Medium

To help control the blast of info, I've used Gitbook to consolidate my learnings and reference them no matter what platform I'm using.

They have solid formatting for code blocks, a variety of plugins you can utilize, and much more to help keep your technical notes looking concise and professional.

One helpful feature is the ability to invite others to shared spaces and collaborate on work. This allows you to better coordinate with your friends/co-workers, without duplicated effort.

The downside of this feature is it doesn't have real-time collaboration.

I've kept interpersonal interactions in a separate private section that I want to remember such as feedback I've gotten, or funny interactions I can use to roast somebody later.

I often forget those little details so having the ability to access them anytime is immensely valuable.

If you're looking for somewhere to keep track of technical info all the time, this is a great option.

gitbook.com

Google Docs/Keep

Google Docs is a household name when it comes to productivity.
Collaborating on documents together and generating ideas live is extremely easy when using the tool.

There is also a mobile version now that allows you to have the same functionality as the web version without too many drawbacks.

Keep allows you to set small notes that can integrate into the rest of the Google suite. Combining the two results in a powerful combination that can help keep your productivity high.

One downside is organizing your notes in Google Drive isn't always convenient. If you're trying to document it on your company drive, and take personal notes on the side, it's easy to get jumbled up in the shared drives with the amount of files and folders you have to sort through.

Another place this falls short is technical documentation.

It's much easier to insert code blocks and Markdown into more catered solutions like Gitbook/BoostNote.

But Google Docs thrives as a general-purpose tool.

I've found the most value when I'm coordinating my current tasks through Google, keeping notes in Keep, and working on a Google doc with others.

I jot down my own thoughts on the side while collaborating with others all at the same time in a seamless manner.

Google Docs: Online Document Editor | Google Workspace

Use Google Docs to create, and collaborate on online documents. Edit together with secure sharing in real-time and from any device.

google.com

Other Contenders

I've used the 2 above extensively, but think the contenders here are worth looking into as well if they fit your needs.

No one solution is perfect for everyone so take a look and see if it best fits you!

BoostNote

BoostNote is another solution that showcases a variety of powerful features. I found it most useful in collaboration with others in real-time.

Some things are locked behind a paywall, but their prices aren't too extreme. Free, $5, or $8/month.

boostnote.io

Microsoft OneNote

Microsoft OneNote Digital Note Taking App | Microsoft 365

Microsoft OneNote has your digital notebook needs covered. With OneNote 2016 we've made our notebook organizer tools even stronger and collaboration easier.

microsoft.com

Notion

Your connected workspace for wiki, docs & projects | Notion

A new tool that blends your everyday work apps into one. It's the all-in-one workspace for you and your team.

notion.so

Conclusion

With multiple devices, it can be extremely frustrating to not remember where you wrote something down. Or not even have the option to write something down.

Using one of these tools you won't have to worry about searching your local notes on your PC, Laptop, or phone, and instead have an easy way to keep track of your thoughts.

I have been able to jot down quick ideas in Gitbook on my phone and elaborate on them later with my laptop without losing too much context. As someone trying to write more often, this is extremely important to me.

Those ideas you generate are precious but often fleeting, so write them down quickly!

Use these tools to your advantage to use less mental power recall and direct it towards creating!

I hope these tools can be as useful to you as they have been to me, Write on!

Originally posted on Here
My Medium Profile!
…Until Next time =)

Two Legendary Tales: The Unicorn Project Vs. Phoenix Project

Live Long & Ponder — Thu, 17 Aug 2023 12:34:20 +0000

Learning how to deliver value from revolutionary books

When you hear Unicorn vs. Phoenix you might think of two fantastical beings outsmarting each other in a mystical battlefield.

Or maybe you are a very literal person and think of a bird fighting a horse, to each their own.

It would be fun to someday write about the results of that battle, but for the purpose of this article, we'll stay grounded in reality.

The Unicorn Project and The Phoenix Project are two books by Gene Kim focused on telling a similar story from different perspectives. The goal is to inform the reader about key tenants of DevOps through the stories of Bill Palmer and Maxine.

This isn't meant to be a book review of either but aims to tell you how I think reading both can provide incredible value, no matter where you fall in your daily hierarchy.

Background

I felt ensnared by screens in my daily life. I would stare at a computer screen all day for work, relax on my phone, watch some TV, and maybe end the day back on my PC. This started to weigh heavily on me.

I wanted to stop using my phone so often, to cut down on screen time and also improve my mental health. So I got into the practice of building constructive habits. (Shoutout Atomic Habits by James Clear)

Photo by Lala Azizli on Unsplash

One place I identified I could cut down my screentime was during Lunch.

I was using my phone a lot during my lunch break. Working from home had me watching YouTube, scrolling social media, or playing games during the break.

I decided instead to start listening to audiobooks to keep my eyes off of my phone while allowing me to do other activities like stretching, walking outside, or playing with the dogs.

The Phoenix Project felt like the perfect place to start.

It focused more on the management side of IT operations and software delivery by telling a personal story full of insightful lessons, rather than giving you an entire instruction manual full of complicated jargon.

I didn't even know The Unicorn Project existed, but I began listening to that immediately after finishing The Phoenix Project. Focusing more on the developer's experience in the same storyline again from a personal perspective was such a refreshing way to peek behind the curtains.

Should You Read Both?

TL;DR: Yes

Don't think that as a manager you should only listen to The Phoenix Project or as a dev you should only care about The Unicorn Project. Both will provide context that ties the entire story together, and make sense of the decisions being made from all levels.

It was eye-opening first to hear the pressure and rigidity being forced upon Bill (upper management) that affected Maxine (developer). Other people on the ground floor were frustrated with decisions being made because they didn't see the battle above them fighting for the right decisions.

Taking these learnings to the real world can have a tangible impact.

Understanding both sides of a crisis will develop workplace empathy and knowledge, making everyone collaborate to attack the problem, rather than each other.

If you become the embodiment of those values, you will be an invaluable asset no matter where you are placed.

The next time you're in an uncertain environment with other people throwing new solutions into the mix, slow down and try to view the problem as a whole.

We often get too narrowly focused on one specific task from a particular angle, we forget others are viewing it from their unique angles.

Understanding where each side is coming from will help generate a solution that can lead to more success and collaboration since you will probably discover you've been looking at the same beast, just with different glasses.

Personal Value

As I've talked about previously, I've transitioned from a PM position to a developer role. So both books have given me invaluable personal lessons I've tried to bring to my team, and I'd like to share them with you.

The "Backwards" Journey From PM to Engineer: Why I Chose Code
My journey from PM to Engineer: A series of lessons Learned from a Backwards Transition

The “Backwards” Journey From PM to Engineer: Why I Chose Code | by Live Long & Ponder | Jul, 2023 | Medium

Live Long & Ponder ・ Jul 24, 2023 ・
Medium

Phoenix

Listening to The Phoenix Project as a PM helped me relate to the issues that I was facing daily, and gave me ideas on how I could solve my personal issues. I felt like I was gaining knowledge on how to conduct my job more effectively.

It became easier to collaborate with others and find creative paths to solutions that had been hiding from the team.

When I was a developer I felt like I could understand the unseen battles that my managers were going through, since PMs don't always explain every meeting they attend.

It became easier to tease out questions that could help the team understand the issues facing our team from a higher level. As a manager, you don't want to overshare high-level problems, but I found that unified teams that understand the problems ahead of them are far more effective as an informed unit rather than an informed leader with underlings flailing blindly to accomplish goals.

When each individual in a team is aware of the direction and overall goals of not just the product, but the organization, you build focused and effective solutions rather than something that only meets some of your criteria.

This applies to more than just corporate or large-scale organizations, you can practice this in daily life. Don't be alone when solving problems, invite others to collaborate and share your goals. You will be amazed at how much impact informed individuals aligned to solving clearly laid out goals can have.

Unicorn

As a PM listening to the daily issues Maxine faced really opened my eyes to my ignorance. I never truly understood the daily hurdles that developers faced until I heard them and experienced them myself.

I finally understood that I expected too much without truly spending time to figure out why some days seemed so unproductive. I admit my mistake, and now can practice better empathy towards others I work with.

It's easy to get stuck in a routine as a PM because Google Meets or Zoom are hardly ever down.

Compared to developers, sometimes builds don't work, or one tool was updated which is breaking existing code, or someone implemented a change that broke everything or…

The list goes on and on, with a seemingly unique issue arising each day.

The beauty of The Unicorn Project is discovering how collaborating towards those issues and documenting discoveries can eliminate daily issues across so many lives.

Maxine ran into the same daily issues as everyone else, but instead of accepting it as truth, she sought out creative solutions and creative people to clear these hurdles for everyone.
We took this to heart and instead of saying:

"I'm having build issues, I'll look into it but not sure when this will be done, then I can help out on other objectives."

We say:

"I'm having build issues, can we take some time to address this and come up with a documented solution as a team so that it doesn't affect anyone else?"

This change in how we collaborate increased our productivity but more importantly established collaborative norms focused on helping others, rather than shunning them.

Conclusion

I use Developer or PM a lot, but these lessons are beyond the tech industry. Any manager and employee can benefit from the lessons that these books provide. Understanding other people's job roles and responsibilities not only helps us solve problems better but also become more understanding humans.

The Phoenix Project and The Unicorn Project may be focused on tech and learning how to implement DevOps, but they also provide an opportunity to be more empathetic humans.

Reading both books offers a unique way to see two sides of the same story. Next time you encounter an obstacle, realize that there are multiple sides to it and take the time to step back to understand more than just your perspective.

Humans accomplish amazing things when working together, so be the one to welcome collaboration into your daily routine.

…Until Next time =)

Originally posted on Medium

Cover Image: Generated by Microsoft Designer
Photo by Lala Azizli on Unsplash

Why Developers Abhore Meetings

Live Long & Ponder — Thu, 13 Jul 2023 23:04:51 +0000

Practical tips for leaders and engineers to improve the quality and productivity of meetings

Nobody enjoys days with long endless meetings, or a thousand short ones sprinkled throughout, but as a developer, these days are the least productive and most disheartening.
This article aims to point out what makes for ineffective meetings, and how to establish healthy and productive meeting culture in a team. I'm hoping to provide a unique perspective as I've done work both as a developer, and a product manager within the last year alone.

The Developer Struggle

If you're a developer you know the pain of staring at a problem, diving through dozens of files and lines and methods to get an understanding of the issue. You finally get a grasp on what's causing the issue and are planning on taking action when all of a sudden PING a meeting is starting.

After attending a meeting you probably didn't need to be at, you come back to look at the code and need to catch the train of thought that left the station an hour ago. Even if you were documenting your actions from earlier, it's hard to grab that context again.

This context loss is even more painful when you're having trouble getting your local environment to build. You could spend hours troubleshooting problems before you even get to implement your feature.

At last, you finally get to writing some code and BAM it's lunch. Another 30 mins to an hour later you have to restart the cognitive process.

As a developer, you run into new problems every day and are working hard to find creative solutions to them, whether it's planned in the story or some new update breaking your local environments. Being pulled away to other tasks in the middle of work can be jarring and slow down the problem-solving nature of the work.

This is a small example of how even one meeting can disrupt a productive flow.

What Makes a Meeting Unproductive?

Having meetings is oftentimes unavoidable, but how can we shift from having a lot of unproductive meetings to having a healthy routine of effective meetings? First, we need to understand what a bad meeting looks like.

Too Many People Invited

If the audience is too big, engagement will be lower and people will be less inclined to chime in. The bigger the group, the more people will think "This doesn't involve me, why am I here?"

"That could've been an email"

This statement comes up way too often in the working world. The meeting starts and ends with only one person talking, and spewing out information that doesn't need discussion. With no discourse between other teammates, people will wonder why this info wasn't sent out in an email or announcement.

No clear agenda from the beginning

When there is no agenda for a meeting, the discussion may revolve around a general topic, but it is only through dialogue that the actual problem being addressed can be identified. This is one of the main ways a 30-minute meeting can be stretched to an hour.

Rabbit holes are followed

A byproduct of bringing up good questions is that sometimes they lead the group off-topic. When the facilitation doesn't table the pursuit of that specific thought, meetings get off-topic and end up wasting valuable time. Also if no one is taking notes and tracking these topics, valuable insights will be lost.

All of these characteristics unfortunately compound into the creation of extra meetings. The original topics are left unanswered, more questions have come up and what's the solution to answering the original problem and all these new ones? You guessed it, more meetings.

Creating a Solution

Fortunately, many of these issues have simple solutions and can be addressed by establishing team normals.

If you're the person who is running the team and holding these meetings, try to implement a couple of techniques to drive efficiency as a whole.

Establish core working hours

Work with your team to set aside a block of time so that they can expect to work uninterrupted, this can greatly increase productivity and team morale. The chunk of time (say 9 am to 12 pm) will contain no scheduled or unscheduled meetings unless absolutely necessary. A couple of benefits:

Teammates will feel free to tackle problems because they understand they won't be interrupted by a pop-up meeting.
The team will feel like the work they are doing is valued because specific time is allocated for it.
Other entities trying to schedule meetings with your entire team will have a better understanding of what your availability looks like.

Establish team meeting norms

Meet as a team to establish what meetings look like internally. Does everyone need to have their webcam on? What meetings are recurring? Where do we keep track of our "parking lot" topics for later? What do we do when a meeting is going over time?

Solidifying and writing down these expectations will help the team have a better idea of what meetings will look like. They should understand what meetings happen every week, and what unexpected meetings with other groups will look like. Make it a collaborative effort so that meetings no longer feel like they are owned by just one person, they should be owned by the team!

Re-visit these norms every once in a while so that new members can feel like their input is valued as well, and things to get too stagnate.

Always have an agenda

If you've ever gotten an invite from your boss with the only subject being "1:1 time" you know the pain of the unknown. You begin to search your mind for any possibility of what you did wrong, or what happened recently that could bring this topic up. A clear meeting agenda should dissipate those worries, and have the topics laid out in the open.

If everyone is on the same page before the meeting even starts it will be much easier to stay on topic, stay focused, and ask the right questions. It should contain the problem being addressed, who is invited, and how long the meeting is expected to go.

All this will establish who needs to be at the meeting, if it's strictly a technical meeting, it should be noted that only developers need to attend. This crucial information will let everyone know what to expect and facilitation will be much easier as you can parking lot many topics by referencing the agenda.

The Developer's Role

If you're a developer in all this, you shouldn't feel excluded from encouraging these ideas. Your opinion should matter in how meetings are handled even if you're just attending!

Encourage good meeting practice by speaking up when you feel the discussion is off topic
Voice your opinion on how recurring meetings are being handled. If they aren't effective, ask to collaborate as a team on fixing them
Participate in discussions - unique perspectives are often the key to coming up with solutions. Your point of view could be the answer!
Actively advocate for core working time if you feel you don't have enough time in the day to produce effective code

Developers can become undervalued and overworked if the leaders don't understand how even simple meetings are taking away from work. It's not always understood how much work is done just to get things up and running sometimes, so be an advocate for yourself and make your opinion known.

Conclusion

Meetings can be incredibly useful, but also incredibly arduous, we should all strive to make them effective. We should constantly be evaluating how we are conducting them to make sure we haven't slipped into ineffective habits.

These tips are nothing groundbreaking, but they are good reminders to look at how we are respecting our and our coworker's time.

Hopefully, you can bring these to your team and see a positive change in how you work together. Good luck!

…Until Next time =)

Originally posted on Medium
Photo by Campaign Creators on Unsplash

This Week in Learning 5 - 9 June

Live Long & Ponder — Fri, 09 Jun 2023 20:18:45 +0000

Interested in what I learned this week? Yes? No? Well I'm going to tell you anyway! Some programming concepts, but also some real-world ideas too.😊

General

When you're working on creating forms that will be displayed by the browser and you want to do your own custom validation (like YUP or Zod) be aware of including the required attribute on your element. When Chrome sees this, it will usually throw an error and say something to the effect of Please Fill Out This Field before hitting your validation messages. It can be a frustrating experience as a user, but there's one easy solution!

Just include a noValidate as an attribute in your form and your own validation should run without Chrome yelling at you first. like this:

<Form onSubmit={handleSubmit} noValidate>
...

Firefox does it as well, but this fixes it there too! Tell those browsers to shush.

DTOs and MVC

I've been trying to wrap my head around Model-View-Controller (MVC) patterns in general and the pattern that includes a service layer. A service layer would sit in between a Controller and Model tasked to complete any domain-specific logic that doesn't exactly fit into just a model or controller.

In that model, there will be Data Transfer Objects (DTOs) that encapsulate data to send from one place to another within an application. This can help reduce the number of calls by basically combining multiple calls into one. There's some logic to help assemble/disassemble these, but that's covered much more in-depth in resources like these.

Martin Fowler Post
DTO Explained

I've only just started diving into these concepts, but DTOs while powerful need to be used in correct situations so that their greatest benefit shines, rather than introducing unnecessary complexity. If you read into Fowler's post you'll see a few examples of when implementing a DTO is a good idea, and when it's not.

When to Separate React Components ⚛

I found a problem this week when using react-hook-form where the whole form kept re-rendering on a change rather than just the field I wanted to change. One solution I found was to separate the problem components out into their own place so that the re-rendering would stop. I was left with a pretty basic form, with other logic held in different files. It worked, but it didn't completely sit right with me. If this happens in other forms and I keep separating things out, at what point does it become an anti-pattern? I want the code to be clean, organized, and concise but how can I do that if I keep moving components out of forms?

I think the culprits were useWatch and useFormContext and not fully understanding controller in that library. If you have any ideas or thoughts on this problem let me know! I'm still learning that library so any ideas or thoughts on understanding are welcome.

Final Thoughts 💡

While there were a lot of programming findings, I also wanted to document some thoughts on life.
Be kind and patient to those you interact with, because you don't know everything going on in their lives, and they don't know everything in yours. Work can be stressful, but outside life can be even more strenuous, and everyone processes those 2 things very differently. Sometimes happy events for others can remind people of past pains, and all we can do is have an open heart for our fellow humans.

Keep an open mind to learning in all things, whether it's about programming or the person next to you, you never know what beauty you'll find within!
…Until Next time =)

The Codewars Experience

Live Long & Ponder — Thu, 16 Mar 2023 14:41:15 +0000

What is Codewars?

Codewars is a platform where you can practice your coding skills by attempting various problems in the languages of your choice. You will be given prompts with varying difficulties, and the way that you "solve" them is by passing all the pre-defined tests.

You can test your code before submission against a couple of easy tests and then submit for a larger set of more obscure cases to make sure you have everything covered. The tests are great for debugging, and they give you space to try creating your own!

After you submit, you can examine what everyone else has come up with, and see where your implementation landed. Popular solutions will be labeled with "Best Practice" to highlight people who solved the code optimally and with solid programming techniques. "Clever" solutions solve the problem in creative ways, such as importing some library that solves the problem in a niche way. It's helpful to examine what others have done and see where you could've improved.

My Experience

Codewars is a helpful practice tool. I've been doing Javascript and Python problems and it's finally helped me feel like I'm back into the engineering headspace. Recently I have been starting my day by solving one or two just to get my brain warmed up, which has helped me establish a healthy morning habit.

After college, I was having a hard time just thinking of problems that I wanted to solve to get back into a problem-solving mindset. I wanted to turn back to the projects that I used back in school, but did I want to crack open that old laptop and try to understand what my college brain was doing? Plus, I think I lost the charger...

Codewars has helped me look at problems and try to solve them in creative ways. I usually start with a way that won't solve the problem optimally but establish a "good enough" understanding, and then implement a more efficient solution by researching. For example, if I know I need to iterate over something, my first solution would be to use a regular For loop. I can break it down in a traditional and readable manner, and then address how to optimize it after. When I have a solution passing some tests, I can go back and examine the loop to maybe incorporate List comprehension in the case of Python. Or in Javascript, try to utilize the map() method. This helps me learn how to examine my solutions for readability and implementation. Using this method I've gotten close to some of the one-line "Clever" solutions, and it feels really good to have implemented something efficiently.

Doing these problems have led me to find some new websites that have become helpful resources, like RealPython or GeeksforGeeks, but also reinforced the obvious ones like stackoverflow and w3schools. Each website has its way of explaining concepts and sometimes I found it easier to comprehend one site compared to the other.

For example, I found w3schools explanation of list comprehension a lot more concise and easier to understand than GeeksforGeeks explanation.
Both explain the same concept differently and it might change per person. In my case, I wanted a quick and dirty solution and mostly syntax, which I felt like w3schools provided, while g4g provided a lot of in-depth examples. If I wanted to take the time and dive a little deeper into the subject, I would definitely return there.

Now I feel like I'm sharpening my programming skills as well as my research skills. So many resources can give a correct way to solve a problem, but sometimes you just need to cater the results in a way that makes the most sense to you. The more I practice that, the faster I can recognize what will be useful to me in the future, and save me time in the long run.

Wrap-up

All of this to say, I think Codewars has been an awesome place to hone my skills in not only problem-solving but also research and selection. Being able to find the right documentation, at the right time is an invaluable skill, and also one that will never be fully perfected. New content and ways of thinking are always progressing, just recognizing where you are and what you want to learn are key to making that leap.
I will be attending a hackathon soon and I'm really excited.

Have you had similar experiences in Codewars? Have you had a negative reaction? What other sites have you found impactful on your journey whether or not you're a beginner or an expert?

If you're also interested in solving problems together, let's all collaborate and solve Codewars or project euler(next) together! Community and teamwork are extremely important in our field, so let's encourage each other!
Comment down below and reach out!

React Stateless and Stateful Components

Live Long & Ponder — Fri, 03 Mar 2023 20:00:06 +0000

So far I've learned a few of the basics of React, and starting to get a better grasp on State. My last post covered a little on the initial uses of state and hooks in React, but now I'm learning about how state should be updated between components so that things are done cleanly.

Stateful vs Stateless components

A stateful component is just a component that houses state, while a stateless component does not. Pretty intuitive naming there :). While one houses state and the other doesn't, both can still utilize props.
If you're unfamiliar with props the terms can get a bit confusing. Props is the name of the object that holds passed-in information about a component, while this.props is the expression used to call that information. You'll often times see props used as a way to reference other passed in data, so try and be mindful of what context you're reading about props in, as it can get a little twisted sometimes.

At first I didn't understand how the information was passed between the components, did it matter if one had state and the other didn't? Is state supposed to be passed between them? Then this statement from Codecademy.org made it all come together:

A React component should use props to store information that can be changed, but can only be changed by a different component.
A React component should use state to store information that the component itself can change.

Knowing this will arm you with the core knowledge to build stateless and stateful components correctly in React.

Parent/Child relationship

To get a better idea of how the information is passed between components, its helpful to think of the relationship between these components as Parent and Child to begin with. In this relation the parent will be handling state the child will be receiving information that can be changed by the parent component.

Lets look at the job of each of piece broadly, then show some examples.

Parent

Defines state
Defines method to update state
- If it's a class component don't forget to bind the method to the constructor for the current instance
Passes method on to Child

Child

Receives method to update state
Calls method by using props
Which in turn calls the parent to update the state Info is updated to user

Conceptually, that all makes sense, now lets look at an example and break it down.

Example

Starting with the parent, we remember it defines state, establishes a way to change that state, and passes that long to the child.

// Parent.js
import React from 'react';
import ReactDOM from 'react-dom';
import { Child } from './Child';

class Parent extends React.Component {
  constructor(props) {
    super(props);
    this.changeFood= this.changeFood.bind(this);
    this.state = { name: 'Steak' };
  }

    // without the function breaking down the event object, this newFood would be a full event Object 
  changeFood(newFood) {
    this.setState({
      food: newFood
    });
  }
  render() {
    return <Child food={this.state.food} onChange={this.changeFood} />
  }
}
ReactDOM.render(
    <Parent />,
    document.getElementById('app')
);

Setting the state is accomplished within the constructor, and since this is a class component, we also use the this.chageFood.bind(this) statement for our event listener. We make sure to do this so that we don't run into an error but it has to do with Javascript binding and how this is invoked. If you'd like to take a look into an article that dives deeper into it, I found this one helpful:
FreeCodeCamp Explanation

After that, our parent establishes a way to change our state, which is done with our changeFood method. This method uses setState as a way to make an update to our state.

Now we can see in the Parent's render function, we have an attribute of food and an event listener onChange which calls will call our state setter function.

Now that we have a decent idea of what our parent handling state looks like, we'll take a look at the child component.

// child.js
import React from 'react';

export class Child extends React.Component {
  constructor(props) {
    super(props);
    this.handleChange = this.handleChange.bind(this);
  }

  // takes event object as parameter, extracts the piece from the event object, and then passes the correct piece back to the original parent funciton
  handleChange(e) {
    const name = e.target.value;
    this.props.onChange(food);
  }

  render() {
    return (
      <div>
        <h1>
          My favorite food is {this.props.food}!
        </h1>
        <select id="yummy-snacks" onChange={this.handleChange}>
          <option value="Steak" >
            Steak
          </option>

          <option value="Pizza" >
            Pizza
          </option>

          <option value="Burgers">
            Burgers
          </option>

          <option value="Not Healthy Food">
            Not Healthy Food
          </option>

        </select>
      </div>
    );
  }
}

Remember, the props here in Child are used to store information that can be updated by other components but not itself.

Here the child received the state setting method from the parent, and will use this.props to call it, there's just one issue. If we just used this.props.onChange in the child, we'd run into an error because we'd be passing back an event object to be displayed while the parent is expecting a string.

That's why we have the this.handleChange method:

  handleChange(e) {
    const food= e.target.value;
    this.props.onChange(food);
  }

This allows us to take the event object as a parameter, and pull out the value we need (food), to then pass as an argument to our onChange method.

Don't forget the ever important
this.handleChange = this.handleChange.bind(this);
since we are using a method utilizing this we need to include this within our constructor.

Now when the parent receives the information from the child (our food of choice) it can accurately update and display the new state. This is done by this method in the Parent:

  changeFood(newFood) {
    this.setState({
      food: newFood
    });

Now whenever the user selects an option from the drop down, our app will be able to handle the change in state, and correctly render a new value. Our Child component is doing it's job, by utilizing props that are updated by the Parent. Our Parent is doing it's job by setting and updating the state, and focusing less on displaying info to the user.

Siblings

An additional way to handle this situation is by using Sibling component updates, where you would utilize one component to display the information, and one component to display a way to change the information. Meaning, one Stateful Parent, with 2 stateless Children. One stateful child would pull in the props and display it to the user, while the other would display a way to update the state.

To apply it to our example, one Child would hold the logic for the dropdown and display ways to change our food, while the other would simply display what had been selected by using the props.
This can help separate the logic and make it a little cleaner and easier to read.

Wrap up

Thanks for coming along with me on learning about Stateless vs Stateful components. Let me know what else you think I should've included, or if I got something wrong! This is just a wrap up of a topic I learned about this week and wanted to share it with you all, as well as connect with people who may be learning the same thing.

Life is a long journey of learning, and I’m just happy to be sharing my stories with you.

…Until next time =)

Arrow Functions and State in React

Live Long & Ponder — Mon, 13 Feb 2023 20:45:10 +0000

Learning React has been interesting, but I've found myself having a hard time understanding State and Hooks. Partly because I'm new to understanding arrow functions.

Seeing something that is so engrained in my mind like a simple example function:


 javascript
(function (a) {
  return a + 100;
});

Transformed into this:


 javascript
a => a + 100

has been a little mind blowing. I love the simplicity of it, but it can get a bit confusing after being so used to "function { ... return... }"

A trick that has helped me is that if a function is simple enough, like the example above, an arrow function is removing the words function and return and simply splitting the parameters from the expression to be returned by using an arrow. When there are no parameters, you'll just see ().

Combining that logic with the idea that functions in Javascript can be assigned names, just like you assign a variable to a value, it gets a little easier to understand arrow the below arrow function.


 React
const increment = () => setCount(prevCount => prevCount + 1);

Increment is the name of the function
() just means there are no parameters
=> indicates everything to the right is logic to be calculated to return some value.

Now what is the setCount and why is it calling prevCount? This brings us to tracking state, and understanding it with arrow functions simplifying the logic.

State and Hooks

React hooks help us keep track of State, by providing an easier way to manage internal tracking of a components current value. Hooks allow you to do all this without having to use component classes, and the dreaded this keyword.

One of the beginning methods called is useState(). When called, it will return an array defining a current state, and a state setter.


 React
const [count, setCount] = useState(0);

count is the current state
setCount will be the function to update our state
0 is initializing the state

If you're unfamiliar with the syntax, you can look into array destructuring here.

Destructuring assignment - JavaScript | MDN

The destructuring assignment syntax is a JavaScript expression that makes it possible to unpack values from arrays, or properties from objects, into distinct variables.

developer.mozilla.org

The nice thing about useState() is that it will automatically call render() indicating that the component will need to re-render, without us having to include that in the code. Just be careful to not include it within the render function or you'll be stuck in an infinite loop. It also allows us to keep track of state from one value to the next.

When a component is initialized, React will use whatever initial value is passed as an argument in useState(). But, this means when the component is re-rendered using setState(), React will use the previous state to update the component!

When needing to update your state, you'll often need to call upon the current state to calculate the value of what you want set next. In this case, it is best practice to update state with a callback function.

In JavaScript, a callback function is a function that is passed into another function as an argument.

Take a look at the following example that combines all of the concepts.
When our state setter (setCount) calls the callback function, the state setter callback function takes our previous count as an argument. The value returned by this state setter callback function is used as the next value of count (in this case prevCount + 1).


 React
import React, { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);

  const increment = () => setCount(prevCount => prevCount + 1);

  return (
    <div>
      <p>Keep clicking the button, you've done it : {count} times</p>
      <button onClick={increment}>Click me</button>
    </div>
  );

Every time the user clicks the button, the count will be updated by 1, and the component will re-render with the current number of clicks.

Here the logic is separated out from the return statement, but this could be calculated within the button and would look like this


 React
<button onClick={() => setCount((prevCount) => prevCount + 1)}>Click me</button>

It is more readable and cleaner to handle it the first way, but it can be done within the if desired.

That was a quick recap of a couple things I learned last week, and I'm hoping to show a similar recap each week. Let me know if you have any tips/tricks or any topics you'd like me to look into! I look forward to learning with you all.

I want to use this space to show what I'm learning, and speak with people who are learning themselves! Also, if you're a React expert and have feedback about what could be done better or is incorrect, please feel free to comment.

Forem: Live Long & Ponder

How I Found A Weapon Against Imposter Syndrome

No Feedback Feeds The Imposter Monster

Learning How to Give and Receive Feedback

Personalize a Feedback Loop to Tame the Monster

Conclusion

Note-Taking Weapons I Use to Tame the Tech Beast

Gitbook

The “Backwards” Journey From PM to Engineer: Why I Chose Code | by Live Long & Ponder | Jul, 2023 | Medium

Live Long & Ponder ・ Jul 24, 2023 ・ Medium

Google Docs/Keep

Google Docs: Online Document Editor | Google Workspace

Other Contenders

BoostNote

Microsoft OneNote

Microsoft OneNote Digital Note Taking App | Microsoft 365

Notion

Your connected workspace for wiki, docs & projects | Notion

Conclusion

Two Legendary Tales: The Unicorn Project Vs. Phoenix Project

Background

Should You Read Both?

Personal Value

The “Backwards” Journey From PM to Engineer: Why I Chose Code | by Live Long & Ponder | Jul, 2023 | Medium

Live Long & Ponder ・ Jul 24, 2023 ・ Medium

Phoenix

Unicorn

Conclusion

Why Developers Abhore Meetings

The Developer Struggle

What Makes a Meeting Unproductive?

Too Many People Invited

"That could've been an email"

No clear agenda from the beginning

Rabbit holes are followed

Creating a Solution

Establish core working hours

Establish team meeting norms

Always have an agenda

The Developer's Role

Conclusion

This Week in Learning 5 - 9 June

General

DTOs and MVC

When to Separate React Components ⚛

Final Thoughts 💡

The Codewars Experience

What is Codewars?

My Experience

Wrap-up

React Stateless and Stateful Components

Stateful vs Stateless components

Parent/Child relationship

Parent

Child

Example

Siblings

Wrap up

Arrow Functions and State in React

State and Hooks

Destructuring assignment - JavaScript | MDN

That was a quick recap of a couple things I learned last week, and I'm hoping to show a similar recap each week. Let me know if you have any tips/tricks or any topics you'd like me to look into! I look forward to learning with you all.

Live Long & Ponder ・ Jul 24, 2023 ・
Medium

Live Long & Ponder ・ Jul 24, 2023 ・
Medium