Forem: A Pile of Loose Bricks

Patching the Cracks

A Pile of Loose Bricks — Sun, 17 Nov 2024 02:42:18 +0000

Over time, I have found that building an app is like constructing a house. You need to ensure a strong foundation and infrastructure, but you also want to decorate and furnish it to make it feel alive. As developers, we’re often caught in this balancing act: pushing out features quickly versus ensuring the app is stable and reliable through testing. It’s easy to get caught up in the excitement of adding new functionality or planning the next feature, but neglecting tests can lead to a crumbling foundation that will eventually cost more time and money to repair.

The red-green-refactor paradigm is a common practice in test-driven development, but it can be tempting to skip the "red" (test) phase when we’re still figuring out how a feature will work. While delivering features quickly might feel like a win, not writing tests introduces significant risks But just like building a house without inspecting the structure, we eventually realize that skipping tests has consequences. Bugs creep in, users report issues, and suddenly we’re spending more time fixing problems than developing new ones.

Additionally, skipping tests leads to the accumulation of technical debt over time. When we ignore testing, the code becomes a ticking bug bomb. Small bugs turn into bigger issues, and refactoring the app becomes more difficult with each additional feature. Just like ignoring structural damage in a house, the longer we wait to address these issues, the more expensive they become. Automated tests act as our early-warning system, letting us catch problems early before they spiral out of control.

Moreover, not having tests is often a "smell" that detracts from the quality of an application. For other developers joining the project, the lack of tests can signal deeper structural issues or make it harder to understand and trust the codebase. Without tests, new contributors may hesitate to make changes, fearing they’ll inadvertently break something. This can slow down development and make collaboration more challenging, particularly in large teams or open-source projects.

However, that doesn’t mean we need to test every line of code from day one. Testing doesn’t have to be an all-or-nothing approach. It’s about finding the right balance: testing core functionality and critical integrations that could break the app if they failed, and gradually building on that coverage as the app grows. For small personal projects, tests may not be as crucial, but for long-lasting or large applications, they can be lifesavers. Like building a house with a solid foundation, automated tests give us the stability to add more features with confidence—knowing that the structure won’t collapse under the weight.

Peer Review for Growth

A Pile of Loose Bricks — Fri, 08 Nov 2024 20:55:18 +0000

In my developer apprenticeship, I’ve learned that technical skills alone aren’t enough—effective communication is equally vital. A big part of my apprenticeship has been working on a capstone project with another apprentice. We each proposed our own project ideas to the instructors, and in the end, my idea wasn’t selected, so I joined another apprentice on a project similar to mine.

However, in the early stages, I felt we struggled with communication. I tried to be respectful of my partner’s workflow, giving them the space they needed to tackle tasks at their own pace and offering help if they hit blockers. But often, it felt like we were working in isolation, like two gardeners each tending to their own patch without sharing tools or tips. When asked about our project’s progress, I only knew what I had accomplished—not what we had accomplished together. This quickly taught me that strong communication is just as crucial as technical work; without it, the garden we were trying to grow wouldn’t flourish.

Thankfully, as we continued working together, we gradually improved our communication. We started small, using strategies we observed at our host company, like quick daily check-ins on workdays. Even though these check-ins were brief, they gave us the opportunity to share progress, voice concerns, and offer support to each other. Over time, this evolved into a structured approach: we began scheduling time to plan our next sprint, setting clear expectations, and reflecting on what went well and what could be improved from the last one.

Just like how a plant needs regular care and attention to flourish, these practices helped our project grow more effectively. We were able to measure our success and continually improve, as feedback became a key ingredient for collaboration. With these improvements, we developed a stronger sense of trust and cohesion, knowing that we were in sync on building our application. We also learned that using “I statements” and that, in order to receive open communication, you first have to be willing to express your own thoughts and feelings. It ensured that our voices were heard, like watering a plant so it could grow without being drowned or neglected.

As I continue to grow as a software developer, I’ll carry these lessons in communication and collaboration into my future projects and teams. Just as plants need time, attention, and the right conditions to grow, the same goes for building strong working relationships. Being proactive in seeking and offering feedback has taught me the value of open, honest exchanges—skills that will help me contribute more effectively to any team. By building trust and aligning with teammates, I know I can help nurture projects forward while creating a positive, collaborative environment. These skills aren’t just essential for project success; they’re also fundamental to growing as a professional and becoming a valuable team member in any organization. Like a garden that thrives with patience and care, the growth of any team or project depends on consistent effort, open communication, and mutual support.

Programming by the Scoop

A Pile of Loose Bricks — Fri, 08 Nov 2024 19:26:11 +0000

Whenever I tell people I’m a software developer, I often wonder how they interpret it—especially if they don’t code. Do they imagine a particular programming language, or maybe a scene from The Matrix with streams of green code cascading down a screen? And if they’ve done a little coding, do they immediately think of the languages they know best? To me, programming languages are like ice cream flavors. Everyone has a favorite, some people prefer extra toppings, and—sadly—some people don’t like ice cream at all.

When you were a kid, maybe your first taste of ice cream was one of the classics: Chocolate, Vanilla, or Strawberry. As you grew, you probably tried new flavors, discovered some you liked more, but still kept a “first love” flavor you turn to when in doubt. I’m the same way with programming languages. When someone says they’re a web developer, I immediately think of JavaScript or React. That’s what I learned first; it’s my “vanilla.” It’s what I know best, so I’m naturally biased toward it. Using a familiar language lets me focus on solving the problem itself without spending too much time thinking about the syntax or structure.

But as I progress in my journey and try out new languages, I find my tastes evolving. I might approach my next project with my “vanilla” language but add a few sprinkles or a swirl of cherry jam to enhance it. Or, I might try a completely different flavor—maybe Python for data analysis or Swift for a mobile app—and discover it’s suited for things I hadn’t considered before.

The more languages I try, the more I refine my preferences, learning when to use one language over another. And just like with ice cream, there are some flavors I don’t like (looking at you, Cotton Candy), but trying them still broadens my palette and helps me understand what I do enjoy.

So, at the end of the day, programming languages are about finding what fits your taste and goals best. It’s okay to be cautious with something new, and it’s okay if you don’t care for it. But keep an open mind, because your “go-to” today might change tomorrow. Embrace what works for you, respect others’ preferences, and don’t be afraid to expand your “flavor” palette.

Promise of Open-Source

A Pile of Loose Bricks — Sun, 13 Oct 2024 19:04:14 +0000

I will pivot slightly from my usual tech topics to discuss design, particularly the software commonly used. When I started my career in graphic design, Adobe Creative Suite was the “must-have” at the time. Photoshop, Illustrator, InDesign, and even Dreamworks were the foundation of my work in college and early on in my career. I was trained to manipulate, create, and design all within the Adobe Suite.

However, after graduation, I faced a harsh reality. While in school, I could pay for the suite with a student discount, but now that I was a professional, the cost exceeded what I could afford. As a newly independent designer, I couldn’t justify the expense, but I still needed robust tools to continue my work. That’s when I started to look into other open-source alternatives.

Thankfully, there are some well-supported open-source tools, like Krita, Inkscape, and GIMP. However, switching to these tools wasn’t an easy process. I spent years learning and mastering how to perform specific tasks all within Adobe’s interfaces and workflows. Don’t get me wrong; each tool has its unique strengths, but they also present challenges, especially when you’ve been trained in a very different ecosystem. I found myself having to relearn certain tasks or adapt my methods to fit these new tools. It’s been a learning experience that continues today, but over time, I’ve grown to appreciate the flexibility and freedom that comes with open-source software.

Ultimately, the shift from Adobe to open-source tools has been a journey of adaptation, patience, and growth. While the tools are different, the principles of design remain the same. The same could be said for development. I’m sure many of you may have similar experiences working with the many different tools available for development. Having access to open-source tools has opened new avenues in design—as well as development—by providing me with the means to continue learning and honing my skills without having to worry about a paywall. It provides opportunities for everyone to experiment and discover what they can achieve.

As I now continue my journey in development, I’m reminded that the tools we use may change, but the creativity, patience, and adaptability we cultivate are what truly matter. Whether you’re a designer learning a new software interface or a developer exploring alternative coding frameworks, the skills we gain in these processes are universally beneficial. Embracing open-source software has not only enriched my skills but also inspired me to explore new avenues in both design and development that I never thought possible. I encourage anyone, regardless of their focus, to take a chance and experiment with these powerful tools; you might just find a new favorite in the process and may even give back to the community you are in.

Progressing Past Uncertainty

A Pile of Loose Bricks — Sun, 29 Sep 2024 17:22:51 +0000

Woah, I’m halfway there. Thankfully though, unlike Bon Jovi, I don’t feel like I’m livin’ on a prayer. It is hard to believe how much has changed in the past 11 weeks. It was stated at the beginning of this program that it’s like drinking from a firehose, and I remember thinking (and writing) about how it was more like a thousand garden hoses. I had a hard time finding the right balance between work and life, and I remember staying up late some nights trying to figure out or troubleshoot various assignments. But over time, some of those garden hoses started to get turned off.

Don’t get me wrong; many are still gushing. However, I feel I have now reached a point where I can control them better. I have become more comfortable with not always knowing how to handle a specific ticket and recognizing that there are many resources I can call upon to help tackle problems. More importantly, though, I have improved at recognizing my self-confidence and progress.

In my previous position, I had (what I consider) the luxury of joining a start-up and building a solution from scratch. I worked with a small team, and I was able to become really knowledgeable about that codebase—how it worked and was pieced together. But that isn’t always the case in programming. Currently, the team I’m working with sometimes finds that our next sprint involves a completely different language that we need to learn to use and set up. Or we may inherit an existing codebase and figure out what needs to be adjusted when we create new features. I had to jump into multiple tickets that I initially didn’t know how to start, and then figure out how to solve those tickets and contribute code.

At first, this was very jarring for me. I was used to thoroughly understanding how something works—its ins and outs—before adding new features. So in the beginning of this program, I felt I had a lot of spinning plates, trying to keep up because I wanted to know how everything worked on a deep level. However, as I’ve learned, it’s nearly impossible for one person to know everything. And after cycling through multiple tickets and different stories, the unknown of not knowing how to do something isn’t as daunting. Because I know that if I don’t know something, it just means there’s something new to learn or a question to ask my team.

And I’m pleased—dare I say even a bit proud—of this recognition. Of being comfortable with the unknown. As I reflect on this journey, I realize that adaptability is key in tech. Embracing uncertainty has not only made me a better problem solver but has also opened the door to new learning opportunities. Each challenge I face now feels less like an obstacle and more like a stepping stone toward growth. I’m excited to continue this journey, equipped with newfound confidence and a willingness to dive into the unknown. Here’s to the rest of the program and all the garden hoses yet to be tamed!

Prioritizing Accessibility

A Pile of Loose Bricks — Fri, 20 Sep 2024 17:26:33 +0000

In today’s digital landscape, accessibility is not just an add-on; it’s a necessity. Reflecting on my personal experiences, I recall several times struggling to navigate websites that were visually cluttered and difficult to read. I often found myself emailing links to my desktop because the mobile versions were broken. I can only imagine the challenges others face with varying levels of accessibility.

Unfortunately, this is not hard to imagine. I recently read that 96.8% of all website homepages have some accessibility failures according to WCAG guidelines. Considering that 1 in every 4 adults in the US has some type of disability, this statistic is staggering. Yet, I have noticed that developers often do not prioritize accessibility in their products. I admit that I have been guilty of this as well. While working on some of my older projects, I was more focused on getting the site operational rather than ensuring it was user-friendly. Once I launched a project, I often moved on without taking the time to analyze and improve it.

Does this sound familiar? It reminds me of Test-Driven Development and the red-green-refactor approach. Perhaps this is why so many sites fail to be accessible; they wait until after developing a product to enhance its usability. As developers and designers, we influence the success of our products and solutions. We should prioritize accessibility from the outset, even before writing a single line of code.

In our journey towards creating inclusive digital experiences, it's essential to remember that progress is more important than perfection. By integrating accessibility into our development process from the beginning, we can gradually improve our products and make the digital world a more welcoming place for everyone, one step at a time. If we stay consistent with our conventions, I believe we can improve the experience for all users.

Pursuing Clear Communication

A Pile of Loose Bricks — Fri, 06 Sep 2024 20:55:40 +0000

I will be the first to admit that deciding to make a mid-life career change isn’t an easy choice. Some people take a lot of time to research all the different potential careers they could switch to. Others jump in without looking, while some fall into a new path without even planning for it. When I first realized I wanted to make a career switch, I was a planner. I spent months internally debating what direction to take, flip-flopping on what I wanted to do. Each option felt like both an exciting possibility and a potential risk, but I soon realized that making the change wouldn’t just be about choosing a new direction—it would also be about how I communicated that decision to those closest to me.

Before I could fully dive into changing my career path, I knew I needed to have an open and honest conversation with my significant other about how this decision would impact our lives. I wasn’t exactly nervous, but I wanted to make sure I conveyed my thoughts clearly so we could collaborate on this life change. To prepare, I wrote down my thoughts to start organizing my reasons and concerns. I also did some research on potential career paths and tried to gauge what their realistic outcomes would be.

Thankfully, they were very supportive of my decision. We talked through the various options together and addressed any concerns that either of us had. Instead of it feeling like a solo journey, it became a shared conversation about our future together. It wasn’t easy at first trying to balance my day job, family commitments, and exploring new paths, but it was a necessary step to discover if this was truly what I wanted.

Looking back, making a career change in mid-life was far from simple, but it was one of the best decisions I’ve ever made. It taught me that it’s never too late to redefine yourself, as long as you’re willing to embrace the uncertainty and do the necessary work. It also taught me that I don’t need to do it all myself and that I can rely on the help of those close to me to be able to reach new goals. My advice to anyone standing on the edge of a similar decision? Don’t be afraid to take the leap, but take it with a plan, and include those closest to you in your decision.

Playing in Sync

A Pile of Loose Bricks — Sat, 31 Aug 2024 20:29:18 +0000

Let me ask you a question. What do you think is the difference between teamwork and collaboration? They are often used interchangeably, and understandably so. There is a lot of overlap between the two, and they are often used together. But to me, teamwork is when individuals work on a specific task in combination with others to achieve a goal. Meanwhile, collaboration is more holistic; it is a group of people working together creatively, brainstorming various solutions, and bouncing ideas off each other to solve a common goal. Put simply, teamwork is like a team of sports players passing a ball to each other to score points, while collaboration is more like a band writing a new song.

In software development, I believe both are essential for team dynamics. However, after going remote, it’s more challenging to keep collaboration from falling through the cracks. In the office, it was easy to swing by your co-worker's desk, brainstorm on a whiteboard, or notice when someone was stuck and offer a helping hand. But when everyone’s remote, those spontaneous interactions are harder to recreate. Even though tools like Slack or Zoom try to bridge that gap, they can't fully capture the non-verbal cues or the flow of an in-person discussion. You’ve probably felt this yourself: it's tough to gauge tone in a chat message, or maybe you’ve been in a video call where everyone talks over each other because body language is harder to pick up.

To combat this, it’s important to carve out intentional time for collaboration. One approach is setting up regular, structured communication like daily stand-ups, virtual "coffee breaks," or team retrospectives. Additionally, formalizing how your team collaborates through a team charter—whether you call it group guidelines, an operating manifesto, or rules of engagement—creates a space where everyone can voice their expectations. Giving people the chance to express what they need from the team and to feel heard goes a long way in building trust and creating an open, collaborative culture.

When you establish that foundation, collaboration becomes more like a well-orchestrated symphony rather than just ticking off tasks. Imagine a team resolving tickets like an orchestra performing a complex piece of music. The violins transition in as the cellos ease off, while brass and percussion harmonize to deliver a powerful melody. Just like that, a junior developer writing unit tests works alongside a senior developer creating new endpoints. Everyone contributes their part, and the sum is greater than the individual effort.

But what happens when collaboration breaks down? Perhaps you’ve seen it: miscommunications, delayed feedback, or even duplicate work being done because team members aren’t aligned. That's why it’s crucial to foster an environment where ideas can be freely shared, and people can ask for help without hesitation. Tools like pair programming or peer code reviews can simulate that face-to-face experience, encouraging real-time collaboration even across distances.

Sure, it’s possible to develop in isolation—just like a solo musician can write and record an entire song. But, when you open yourself up to working with others, you gain access to fresh perspectives, new ideas, and creative solutions that you might not have thought of alone. To me, that’s the best part of software development. No one person can know everything or keep up with every new technology. But together, we can innovate, improvise, and push boundaries, like a jazz band riffing off each other to create something greater than the sum of its parts.

So, the next time you're deep into solving a problem or building something new, remember: you’re not just scoring points on a task list. You are part of an evolving, creative process—one that transforms simple tasks into a shared experience where we can learn, grow, and create meaningful work. That's the true power of collaboration.

Peaks and Plunges

A Pile of Loose Bricks — Sat, 17 Aug 2024 17:33:44 +0000

I’ve been around tech my whole life. But for a majority of it, I would classify myself as a consumer, not a techie. In fact, the first time I had unlimited access to the internet was when I went to college. Sure, my family had dial-up for a couple of years when it first came out, and I would go to my local library, but in either instance, my access was limited. I remember visiting my friend’s house and sitting in a chair next to their computer as they would set up their MySpace pages or build a geo-page of who they thought were the best music artists of all time.

However, my first exposure (at least in my mind) to the world of web development did not come until my senior year of college. I had to create an online portfolio for my artwork. I disliked the generic templates that website builders like Wix provided at that time, so I opted to build my website myself. Coming from graphic design, I had access to the Adobe Creative Suite, so I worked in Dreamweaver. Looking back my website was …. awful. It was very bloated, hard to read, and the minor Flash animations (HTML5 wasn't a thing then) I added were glitchy. And don't get me started about all my nested divs and broken floats. But it got the job done and I was quite proud of it. I got a great sense of accomplishment from learning how to build it myself compared to some of my classmates' sites which all looked the same.

Now there is an argument that the site was merely a way to present our artwork. But at that time I felt that the website itself should also reflect our artwork. It was the first spark that I discovered my love of blending my art with technology.

After college, I tried the designer career route, but I realized it was not for me and I missed being able to tweak and fiddle with code. So I took some time to learn languages and technologies that I hadn’t heard of at the time, like React or NodeJS. I fiddled a tiny bit with JavaScript beforehand so I figured, “It can't be that hard.” To this day I distinctly remember some of the ups and downs of the rollercoaster ride of learning new technologies. Getting frustrated debugging, racking my brain all day only to wake up with a Eureka moment and realize I was missing a bracket.

I would actually classify that time period as my first real entry into development. And it’s been a wild journey since then. I have gone through self-taught, to bootcamp, to getting my first job, to being laid off, to freelancing, to part-time. Some of those times were darker than others, but there have been a lot more brighter moments. I have many fond memories from my bootcamp and my first career that I think I will carry for the rest of my life. The euphoria I felt when getting the signed contract from my first freelance client. And now I’m working at a company I never thought I would be able to when I first started this career transition. Sure, it’s still a rollercoaster, and I’m sure there will be many more twists and turns, ups and downs. But I’m thoroughly enjoying this ride, and I am going to continue enjoying it as long as it runs.

Pivoting to Programming

A Pile of Loose Bricks — Sat, 10 Aug 2024 18:12:08 +0000

When I first decided to change careers, I was worried that I would have to prove my worth. I had heard horror stories of gatekeepers saying that you’re not a true developer unless you can do x, y, or z. Coming from a non-technical background didn’t help.

But it turned out I was wrong. I found software development to be a welcoming community for people of all knowledge levels and backgrounds. And it makes sense. With technology constantly evolving, it’s nearly impossible for one person to know everything. However, when you have a room full of people who all think the same way, it’s hard to come up with solutions that are outside the box. So instead, we build relationships and work with others to form a strong team composed of individuals with varying degrees of knowledge and diverse backgrounds.

For me personally, I have found a range of non-technical skills that I am able to bring to the table. Some are more noticeable than others. For example, my background in graphic design is easily transferable. I am a strong believer that front-end development is pretty much the same thing as graphic design. The only difference is that graphic design leans more toward static, non-moving mediums like paper, while front-end development allows you to stretch and move elements around a screen.

Other skills may not be as noticeable, but they are still very useful. Coming from a customer-focused background, I have learned the importance of open communication. By keeping the customer informed about the status of their job, whether it was good news or bad, I found it much easier to find solutions. In some cases, the customer may be more willing to give extra time to be able to complete their job or provide more resources for us to use. It became a two-way street, where instead of having to figure out a solution by myself, we were able to tackle it together.

I could go on listing other transferable skills, but I’m not a fan of huge blocks of text, so I’ll keep it short. But I did want to share the main two since I find myself using them almost daily. When I started my new job, I had to undergo training in Agile methodology, and I found it amusing how similar it was to the communication methods and skills I’ve been using throughout my career.

I also believe that open communication within my team fosters a stronger level of trust, which is very comforting. After all, who wants to work with people they can’t depend on or trust? Well, I’m sure some do, but I, for one, would rather work with like-minded people to uncover and build solutions. As the saying goes, “Two heads are better than one,” but I would add, “as long as they’re working together.”

Plunge In

A Pile of Loose Bricks — Fri, 02 Aug 2024 17:32:52 +0000

“Every adventure requires a first step.” This quote is often thrown around when someone starts talking about trying something new, and in many ways it is accurate. But what that first step is can vary. Generally, it's encouraged to take one small step at a time, but sometimes it is better to jump in feet first and see where you land. After completing my first week with my host company, I feel I fall into the latter category. Most of my week consisted of training videos and meetings, which I expected. However, that doesn’t change the fact that it's like - as mentioned multiple times - “drinking from a firehose.”

To combat that overwhelming influx of information, I try to adopt a couple of habits at the beginning. My main one is taking notes, and writing down the answers to all the questions I have. In doing so, I slowly started building my own personal documentation system to refer back to so I don’t have to ask the same question twice. In time, it also provides me a time capsule that I can look back on to see how far I have come, or as a way to remind myself what it is like when I (hopefully) have an opportunity to mentor the next generation of developers.

Another habit I'm trying to establish is to schedule a short break at some point to take care of myself. Sometimes it may be a 5-minute stretch, other times it may be taking a 15-minute walk. But having that separation from my screen and keyboard helps ground me in what I am learning and stops me from “powering through.” Some would argue that powering through is a good thing, but I have found that it leads to me glazing over the information and not absorbing it, which is a waste of time.

That break also is useful for giving myself time to self-reflect on how I’m feeling. If I’m anxious, I can take time to breathe and think about why. When I’m excited, it gives me the opportunity to enjoy the high and the feeling of accomplishment. Granted, I don’t always succeed in acknowledging my status, but having that break has given me more time to reflect on it.

So yes, the firehose is spraying gallons of water on me right now, but I know in time that valve will be reduced to be more of a garden hose. Until then, I can work on improving my habits to catch as much information as I can while ensuring I don’t get swept away in the flood.

Priming My Workspace

A Pile of Loose Bricks — Fri, 26 Jul 2024 22:17:30 +0000

Separation of concerns. In the tech world, that phrase generally refers to the design principle of separating a complex system into more manageable parts. However, ever since I started working from home, I have started seeing it in other places outside of my codebase.

When I worked in an office, I found it really easy to keep my space clean and organized. In hindsight that was because that space was dedicated to my job only. It was easier to disconnect from that headspace once I was done with my work because the work was literally in a different location. But now that my workspace is also in my home, I find it harder to keep that separation, which could be a concern.

Some aspects are easy to keep distinct. I have a work computer and a personal one, and they do not overlap. Granted, both of them are on top of my desk, so I have to keep experimenting with different layouts to accommodate both. Other aspects are not so easy. For example, my pile of notes and sticky notes covering my desk. I find myself constantly shifting and adjusting things from one side to the other to make room for whatever I’m doing. And no matter how many times I go through and organize it better, new items seem to creep in or materialize back. But, I guess that is more of a reflection of my style of working. If I don’t have a tidy space (both physically and mentally), I tend to feel overwhelmed, even if my to-do list is only two items long.

Who knows, maybe finding a happy middle ground like splitting my desk space in half will improve my environment. Or, in time, I could get a completely separate desk to be a mini-work island in the sea of my home space (though if I do, I’m definitely going to get a standing desk). I could start small by having two different colored sticky notes, one for home and one for work.

Until then, I will continue to check my posture, set my Pomodoro timer to make sure I take mental breaks, and keep tweaking my workspace to fit my lifestyle. Sure, it’s not as easy to have my space separated in black and white, but now I am able to discover a whole new set of colors to bring to my environment. For now, I just need to put down some primer first. That reminds me - I should probably get around to painting my walls.