Forem: Karla Dampilag

Turn your coding skills into revenue streams 🧑‍💻💰

Karla Dampilag — Sun, 02 Mar 2025 14:46:33 +0000

5 Side Project Ideas for Developers to Monetize as Micro-SaaS in 2025

Daniel Abel ・ Mar 2

You can't get what you want if you don't do this

Karla Dampilag — Sun, 19 Jun 2022 20:05:49 +0000

If you're asking for something from someone, then you need to do this first.

If you're in sales, customer support, or anyone talking to users or potential users, you gotta dial up the listening and empathy meters.

In fact, if you're asking for something from someone, such as but not limited to:

Sign up to your platform
Buy your product
Leave a review
Hire you
Give you a raise
Give your startup funding

Or literally anything else, then you gotta answer the question, "what's in it for them?"

What's in it for them?

I was recently on the receiving end of having someone ask me to do not just one thing, but many things. The interesting part is...

I didn't even know the guy.

Someone cold messaged me on LinkedIn to try out their NEW blogging platform, and encouraged me to publish my articles there. I already cross-post my blog posts to tech/dev blogging & community platforms, so he probably found me at one of those places.

Since the platform he's promoting to me is fairly new, I asked how it's different from the others I'm already using, and what kind of unique value it brings to the people they're trying to onboard, a.k.a. people like me.

He gave me lengthy details about the company and their platform that didn't answer my question. Unsatisfied, I Googled them myself. Even from their website, I couldn't find their UVP (unique value proposition).

But whatever, I gave the benefit of the doubt since startups usually polish their messaging, comms, and positioning during these early stages. No big deal.

Listening and empathy

I got busy with work and forgot about the platform and our conversation. But to his credit, he consistently followed up with me so I didn't completely forget about it. One day, I was able to find the time to publish one post on their platform, which was weeks after our first contact.

After more follow-ups from him, he asked if I'm interested to import all my existing articles on their platform. I told him about my experience when I published my first article there:

It was painful to use because they had no support for Markdown.

Markdown is supported on my self-hosted blog as well as on the platforms I use, so all I have to do is copy-paste if I want to cross-post. But this guy's platform only has rich text processing. That means I had to manually format everything when I published my first and only article.

I asked if they have plans to support Markdown in the future. Obviously so it'll be easier to do what he's asking me to do.

His response? He thanked me for my interest, gave more promotional speeches about why it's so great to use their platform, then asked me if I can get 3 more of my articles there, and then requested me to update my profile. He managed to say all those in three paragraphs.

He didn't even answer my question.

I decided not to publish the rest of my articles there, which is opposite of what he's asking me to do. It's mostly because I'm too busy these days, and manually formatting articles when I know I can just copy-paste has introduced a huge friction to keep publishing on their platform.

Communication skills

While writing this article, I had to revisit our conversation to make sure my story is accurate 😛

I noticed that he actually answered my question at the very end of his essay. It turns out they do support Markup. I felt dumb for not finding that option in their UI. Either that or their UX wasn't the best. Which is which doesn't matter for this article 😉

But I could have sworn he didn't answer my question when I first read his response. Then I saw an "edited" tag on his message. He might have realized it after he clicked send, then went back and edited his response.

If that's the case, it was too late. I already read it and decided not to use their platform at the time. I wouldn't even have seen his edit if I didn't feel the need to write about this experience.

Either that, or I missed his answer the first time. Either way, if he "listened" for real, and had empathy for the person he's talking to, he could have answered my inquiry first, and I would have already published all of my posts to their platform.

Only then would have been a better time for him to say more promotional text and ask for me to do more things on their platform, because he'd already informed me how seamless it is for me to do all these things he's asked.

It's a skill or a muscle to be exercised

I myself fall into the trap of not doing one or all of these things.

Some of us are naturally gifted at persuation and communication. Most of us aren't. The rest of us has to learn it like any other skill. But in my opinion, this is where we should start - at the basics.

Answer what's so good about your offer or request that's so valuable to the intended recipient. What's in it for them? Then listen for real, and have empathy throughout the conversation and subsequent interactions.

Am I a master at these things myself? Absolutely not. But this recent experience of being at the other end, made me realize how important it is to be mindful of our communication and persuation skills. What about you?

React - How to show then hide elements after a few seconds

Karla Dampilag — Sun, 12 Jun 2022 21:04:25 +0000

Ever wondered how to hide elements after a few seconds in React?

Problem statement: I want to show elements and make them disappear after a few seconds in React.

Solution: use setTimeout method from JavaScript, and hooks from React.

Achieving this behavior in React is similar to how you'd do it in Vanilla JavaScript - by using setTimeout. The only difference is you'll also use React hooks to store the visibility state, and set it to appear or disappear.

Consider this React example:

import React from 'react';

function App() {
  return (
    <div className="App">
        <button>Show alert</button>
    </div>
  );
}

export default App;

For now we only have a button. But we want an alert to show after clicking the button. Let's add the markup and necessary hooks for that:

import React from 'react';

function App() {
+    const [ isAlertVisible, setIsAlertVisible ] = React.useState(false);

+    const handleButtonClick = () => {
+        setIsAlertVisible(true);
+    }

    return (
        <div className="App">
-           <button>Show alert</button>
+           <button onClick={handleButtonClick}>Show alert</button>
+           {isAlertVisible && <div className='alert-container'>
+               <div className='alert-inner'>Alert! Alert!</div>
+           </div>}
        </div>
  );
}

export default App;

What we did:

used useState hook to create isAlertVisible and setIsAlertVisible.
created a handleButtonClick function for when the button is clicked, and assigned it to the onClick property of the button.
added the alert markup, and only show it when isAlertVisible is true.

We also want to add styles to the alert section, so it'll look more like an alert:

.alert-container {
  position: absolute;
  top: 2rem;
  left: 0;
  right: 0;
}

.alert-inner {
  display: inline-block;
  padding: 8px 16px;
  z-index: 1;
  background-color: #ffffff;
  box-shadow: 1px 2px 10px -3px rgb(0 0 0 / 70%);
  -webkit-box-shadow: 1px 2px 10px -3px rgb(0 0 0 / 70%);
  -moz-box-shadow: 1px 2px 10px -3px rgb(0 0 0 / 70%);
}

Now to the important part - we want the alert to disappear after a few seconds. Suppose we want the alert to hide after 3 seconds, so we'll use the useTimeout function, and pass 3000 milliseconds as the second parameter:

import React from 'react';

function App() {
    const [ isAlertVisible, setIsAlertVisible ] = React.useState(false);

    const handleButtonClick = () => {
        setIsAlertVisible(true);

+        setTimeout(() => {
+            setIsAlertVisible(false);
+        }, 3000);
    }

    return (
        <div className="App">
           <button onClick={handleButtonClick}>Show alert</button>
           {isAlertVisible && <div className='alert-container'>
               <div className='alert-inner'>Alert! Alert!</div>
           </div>   
        </div>}
  );
}

export default App;

And there you have it! Customize your alert to show more content, change the duration, change its style, go crazy 😉

A good next step is to extract this behavior and turn it into a separate Alert component. Make it accept different props from the parent, such as duration, content, position, and so on. Then whenever you need to alert a message, you can just re-use this Alert component.

Happy coding!

Test React hooks with React Testing Library - The Correct Mindset

Karla Dampilag — Sun, 15 May 2022 00:00:00 +0000

I noticed a common pitfall with people new to React Testing Library - testing implementation instead of functionality.

One example would be, trying to test if the useState hook has been called or not. Don't do this! It's going against the design of the react-testing-library.

The official documentation even states this:

You want to write maintainable tests for your React components. As a part of this goal, you want your tests to avoid including implementation details of your components and rather focus on making your tests give you the confidence for which they are intended. As part of this, you want your testbase to be maintainable in the long run so refactors of your components (changes to implementation but not functionality) don't break your tests and slow you and your team down.

In other words, testing internal variables goes against the philosophy of React Testing Library. This library is concerned with what the user sees, and the user doesn't know nor should care about internal variables and their values, and if they've been called or updated.

Think of what the users should see and expect, then test for those.

Instead of testing if the React hooks were called, or if they have the correct values, we should test how the UI should behave when the user interacts with the component. That would automatically cover whether or not our React hooks are working as expected.

The more your tests resemble the way your software is used, the more confidence they can give you.
— Kent C. Dodds 💿 (@kentcdodds) March 23, 2018

Real life examples

Think of it this way: each React component serves a purpose, and should act in an expected way. The way we implement how the component will "serve its purpose" may change along the way. You or a colleague might find a better approach in the future, and refactor the code.

If the component's expected behavior won't change despite these implementation changes, then the changes shouldn't break the tests.

For example, if you wrote a modal component, then it's supposed to show when you want it, and not show otherwise. How you implement this behavior may change throughout the life of your app. But at the end of the day, the users will expect it to behave the same.

That's why we should test the functionality, not the implementation, when testing React components. Did I say that enough times already?

So what should we test specifically?

When thinking of things to test, mimic the way the user would use the application. Things like:

When the component renders, what should the user initially see? This is where you use react-testing-library queries to check if the expected elements such as labels and inputs are present in the DOM.
If a user types into an input field, the user expects to see the characters present on the input field.
If it's a dropdown, then the dropdown should show the options when clicked, and then hide the options when an option has been clicked. It should also show the selected value. Again, the library's query functions are provided for this very purpose.
If you're prompting a user for a number input, then a good test would be checking if the user can input numbers, but not other characters.
When a user clicks on a clickable element, what should the user see next? A message prompt? A special interaction? A change in behavior? Some other element will show up? Or hide? And so on.
Fire any events to simulate user actions (e.g. input information in form, click button to submit a form, etc.)

A good tip is to make the test resilient to very small changes in implementation, such as changing lower case to upper case for labels, and so on. Remember, test behavior, not implementation.

It doesn't mean we should only test the UI behavior when writing any kind of unit test. I'm only talking about testing React components using the react-testing-library, which is concerned with the presentation layer of our code.

The other parts of code should still be tested as well. All the data manipulation, computation and other logic should have separate tests.

Besides, in the first place, the data layer of our code must be separate from our presentation layer (with which React or other UI libraries are concerned). And these other layers should have their own separate tests 🙂

Actual Examples

Now that you're approaching React Testing Library with the correct mindset, you're ready to look at concrete examples. For such examples, head back to the library's documentation. Another great resource is Guide to testing React Hooks. Their Introducing react-testing-library section provides very good examples of the behaviors we talked about.

Happy testing!

How To Learn React JS Quickly

Karla Dampilag — Thu, 28 Apr 2022 00:00:00 +0000

1. Learn JavaScript first

This is a no-brainer, but let's get it out of the way.

You can't really learn React fast if you're not familiar with the language that the library is built for.

I wrote a post listing beginner exercises in React, and even those beginner exercises need JavaScript as a prerequisite. If you skip JavaScript and learn React straightaway, you'll actually make your learning time longer because you skipped the basics, or the pre-requisite.

Not to mention that if you skip JavaScript, you'll have a hard time knowing which part of your code is just JavaScript and which part is React. How will you debug when you come across errors and bugs?

So if you want to learn React quickly, then get comfortable with JavaScript.

But how much JavaScript do you need for React?

At the very least, you should know the most important ES5 and ES6 concepts (ES5 and ES6 is the first and second major revision to JavaScript):

the let and const keyword
arrow functions
template literals
default parameters
array and object destructuring
for-of operator
find method
ES5 array methods
ES5 JSON methods
ES5 Date methods
modules (import and export)
promises
async / await (not ES5 or ES6, but ECMAScript 2016)

2. Understand declarative vs. imperative programming

This is the part where I failed, so I'm including it here so you don't have to make the same mistakes.

React is a declarative library, while JavaScript is an imperative programming language. That means learning React after learning JavaScript requires a bit of a shift in thinking, because they're almost opposite paradigms.

When I was learning React some years ago, I didn't even know I was doing imperative stuff on my React projects for my portfolio. In one job interview, the interviewer himself pointed it out and told me how it's supposed to be done in React.

Bless his kind soul.

I didn't have time to correct my code, but I kept what he said in mind. In another interview at another company, the interviewer pointed out the same section in my code. He asked me what I think I did wrong. Because I remembered what the first interviewer said, I was able to answer this question correctly. The whole interview was more engaging because I could talk more about my code and how to improve it. I got hired and work there until now 😉

To give you an example of these two different programming paradigms, take a look at exercise #5 at 9 Beginner React JS Exercise Problems

3. Read the docs

For any new library you've decided to use, never skip reading the documentation. If you're just learning how to code, I recommend you also learn how to read and make sense of the documentation of whatever you're trying to learn.

At work, you'll be using a lot of libraries. You have to get comfortable learning how to use libraries by reading their documentation. You just have to 😉

Code right away
Fail
Finally consult documentation

When I was a junior developer, I solely relied on Stack Overflow and tutorials. I was impatient and jumped straight to coding after scanning their documentation. This led to bad practices and lots of workarounds to force the library to do what I want. If only I read the docs, I would have implemented the logic better, because I knew the library better. No work arounds, no hacks.

You'll learn exactly how to use the library in different use cases, its features, limitations, and the creators' recommendations on approaching different scenarios.

If you don't believe me, here's my story:

We had a new hire that had the same years of working experience as me, who just learned React recently. Her past experience was Angular, and at this time I already had 1-2 years of experience in React.

Until then, I put so much importance in learning on the job. I thought everything you have to know for the job, you'll eventually learn ALL of it on the job.

But one time, I got blown away with her solution because I didn't know you could do it like that. When I asked her how she knew [insert whatever she did here. Sorry, I no longer remember what it was], she said, "it’s in the docs".

While I was correct that you'll learn the ropes on the job, she learned more effectively because she read the documentation first, unlike me 🙂

I've been working with React for a while now, and yet I still learn new things about the library from time to time. And the first place I go to is the official documentation, because... lesson learned 😉

4. Start working on small, tiny projects

You know what they all say in the learn-to-code space - don't get stuck in tutorial hell. And the only way to get out of tutorial hell is to work on your own projects to apply what you've learned from those tutorials.

If you're having a hard time with your own projects, maybe they're too big. Start small, and then work your way up to more complicated projects.

I wrote a list of very basic React exercise problems just for this very reason.

After these exercises, you'd want to move on to a small project.

For example, check out this step-by-step React tutorial for the Card Memory game: https://fullstackvault.xyz/blog/react-js-sample-project-step-by-step.

That's what's typically meant with "small" or "beginner React project".

5. Build bigger projects

After gaining confidence with a small React project, it's time to move on to larger React projects.

If you're struggling with ideas, check out the tutorials and project ideas at https://fullstackvault.xyz.

Should you take courses?

Since I got pretty comfortable with JavaScript, I didn't need to pay for any courses to learn React. But I still took a crash course on YouTube, that is basically a long tutorial for a large React project. I would say it propelled my knowledge faster than if I did all my curriculum on my own.

Yes, the documentation is good for learning the concepts that come with the library. But after that, it's time to put theories into action and solidify what you've learned by making your own projects. That's what the crash course did for me.

If you're ready to work on big React projects after going through steps 1-4 above, I highly recommend tutorials or courses that cover medium to large-sized React projects that were released recently.

React is updated very frequently, so you want to avoid outdated and obsolete content. I made a curation of very good resources for React here: fullstackvault.xyz

TLDR? How to learn React js quickly

Learn JavaScript first! How much exactly? It’s listed in the first item.

Second, understand imperative vs. dynamic programming, because learning React after JavaScript requires a paradigm shift. A concrete example plus an exercise is included in item no. 2.

Third, read the documentation. In item no. 3, I wrote why skipping this step might set you up to learn React ineffectively. So avoid developing bad practices from the get-go by reading the docs.

Next, get out of tutorial hell by working on your own projects. Start small and then gradually move to bigger and more complex projects. A list of beginner exercises plus a repository of advanced projects are linked in items 4 and 5.

And finally, if you have any concerns or questions, I’m always happy to help 🙂 Just drop a comment below. Other than that, happy learning!

9 Simple (But Important) React JS Coding Exercises You Need To Do As A Beginner

Karla Dampilag — Tue, 30 Nov 2021 00:00:00 +0000

You know what they say, if you REALLY want to learn React, build something! Don't get stuck in tutorial hell.

Well, what if you're not that far into your journey, and still aren't able to build full-blown projects?

That's what this post is for, which is inspired by the post, "12 Exercises to Learn React Native".

React JS Exercises

These exercises will help you apply the basic concepts of React through tiny projects. Once you finish all exercises, you'll know you've got the basics down. Then you can start learning more advanced concepts, and build more complicated projects.

So let's get started!

React JS Coding Challenges

Exercise 1: Hello World!

Every programming language starter tutorial teaches you how to output "Hello, World!" using the language.

But this exercise is not just for tradition.

This will asses if you actually know HTML, which is one of the many prerequisites before learning React. Start by rendering a square with a background color. Inside the square, render "Hello, World!".

Helpful links:

Exercise 2: Capturing User Clicks

What makes a web app different from a static website? A web app is interactive. Of course, there's more to web apps than capturing clicks, but it's important to start from the basics.

This exercise gets you started with event handling, which is a basic concept not only in React but also in JavaScript (which is again another pre-requisite before learning React).

Using the native HTML <button> tag, capture the click event and alert the message, "Clicked!".

Take note that capturing events such as clicks is done differently in React than it is in JavaScript.

Helpful links:

Exercise 3: Custom Component

In the previous exercise, we used the HTML <button> tag. But much of the power that React provides to us developers is being able to create our own components and reuse them.

You'll be creating more complicated custom components than a simple button in the near future, but we all gotta start somewhere.

In this exercise, build your own Button component and render it three times. On user click, it should alert which button was clicked:

The custom component should accept an onClick prop. On render, it should render the children betwen the button. This is the text you want for the button.

Think of it like the HTML <button> tag. Whatever text you place between the opening and closing tag is rendered between the button when you inspect the element in your browser developer console.

On user click, it should alert which button was clicked.

Helpful links:

Exercise 4: State and Props

So you're comfortable working with props, congratulations! Using props allows us to pass values or functions down to a child component.

State is another integral concept we must learn in React. It allows us to store values, and React automatically updates our UI when the values change.

That's one of the many beautiful things with React. We don't need to manually handle these things - React does the UI re-rendering for us when a value changes. But we must know how to use the state for this purpose.

This exercise is simple, and is a very common React tutorial out there. Use the useState React hook to track how many times a button is clicked, and display the number.

The number must increment each time the button is clicked:

Helpful link:

React state hook

Exercise 5: Mapping Through A List And Rendering

To get comfortable with React, you must learn declarative programming.

React is declarative. So you need to think in "declarative programming" whenever you work with React, and this exercise is perfect for that. This is the "opposite" of imperative programming which is the paradigm used in Vanilla JavaScript.

In this exercise, instead of manually and "imperatively" coding the render of each item in a list, use the map function to "declare" how React should render the list.

Given an array:

['dog', 'cat', 'chicken', 'cow', 'sheep', 'horse']

Use the map function to render them in an unordered list:

dog
cat
chicken
cow
horse

Once you learn the concept of rendering declaratively, you'll see how much life becomes easier (overstatement).

But think of it this way...

Our example list is not that big, but imagine if the list contains thousands of items, which is true when working with real-life data and real-world applications. You wouldn't want to manually code each <li> one thousand times, right?

And what if the data changes? This is the case when working with data in production environment. You'll have to change the code again.

But not when you rendered the list declaratively. When the data changes, and you rendered your data presentation declaratively, a.k.a. the smart way, then your declarative code does the change for you.

Helpful links:

Exercise 6: Mapping Through A List And Rendering (With A Custom Component)

In exercise 3, we mentioned that part of what makes React so great is that it allows us to create our custom, re-usable components.

You only created a custom button there. This time, you'll create a custom component that displays each item from exercise 5:

['dog', 'cat', 'chicken', 'cow', 'sheep', 'horse']

Instead of using the <ul> and <li> HTML tags, create a custom component that accepts a list as its prop, and renders it accordingly.

It's up to you how you want this list will look like. I decided mine to look like this:

What's the point of creating custom components? You'll be able to re-use them. Think of it like creating your own functions.

Instead of copy-pasting the same lines of code everywhere you need them, you put those blocks of code inside a separate function, and you just call that function whenever you need it.

This is very good practice because if you need to make changes to your code, you don't need to change it in every place where you used it. You just need to change it in one place.

That's one of the many benefits of using custom components. There are more reasons to using custom components, which needs a whole new blog post, but this is a good start.

Helpful links:

Exercise 7: Building A Form

Unleash some more power from React by building a form. React is great for this.

Build a form that accepts a first name and a last name. And instead of a boring "Submit" button, make a button that says "Greet Me" that when clicked, will alert "Hello [first name] [last name]!".

Here you will use a combination of concepts from previous exercises, such as using state, and event listening both on text input and button click.

But there is one specific concept we didn't tackle yet:

React forms and onChange() function

Exercise 8: Rendering JSON

Most of the time, the structure of the data we're working with in real-world applications aren't simple lists like ['dog', 'cat', 'chicken', 'cow', 'sheep', 'horse'].

A lot of data is stored in JSON format. This is especially true when you're fetching data from a database.

JSON stands for JavaScript Object Notation, a type of format for data interchange.

This type of data is just an object instead of a simpler datatype such as a string.

For example, an array of JSON objects looks like this:

[
    {
        id: 1,
        setup: "What's the best thing about a Boolean?",
        punchline: "Even if you're wrong, you're only off by a bit"
    },
    {
        id: 2,
        setup: "Why do programmers wear glasses?",
        punchline: "Because they need to C#"
    }
]

To keep it simple, let's keep it to only two items.

Using the array of objects above, render the jokes with React.

Here's how I decided to render mine:

Tip:

Create a custom component for rendering each joke.
Using the map function, map through each object in the array. Use the custom component to render each object.

Helpful links:

JSON
Flexbox

Exercise 9: Working with an API

Last but definitely not the least, work with an API and build a simple frontend:

Every React or any frontend developer must learn how to work with an API. When building applications, you receive data from the backend or an outside source which you will have to present nicely in the UI.

Fetch from this API endpoint: https://random-data-api.com/api/users/random_user?size=10

This will return ten random users.

Here we'll put together everything we did from the previous examples:

Show each user's basic info in a card.
When a card is hovered upon, the card flips to show more information about the user.
There should also be a button that when clicked, will fetch another set of 10 random users, which updates the cards.

Here are the steps for this exercise:

Fetch the data from the URL. You also have to handle converting the JSON response into a JavaScript object in this process. (See Response.json() resource link below)
Store it in React state.
Render the data based on the state.

Take note that most APIs return data in the form of JSON. Good thing we already covered JSON in the previous exercise 😄

Hints:

Do the fetching inside a useEffect React hook
Create a custom component for the card, which accepts a user JSON object. Map through the data returned from the API and render each one using the custom component.

Helpful links:

We'll also be needing a lot more CSS, especially for the card hover effect:

Card flip effect

Conclusion - React Practice Problems

If you're an aspiring React developer, these exercises will help you understand many concepts that are integral in both React and frontend web development as a whole.

Every exercise here is used in my daily life as a React developer. And I hope this helps you get closer to your goal. Soon they'll be second nature to you, and you'll be coding them without even thinking about it!

If you find yourself stuck, or need any help with the exercises, just let me know and I'd be happy to help.

I'm over at Twitter as well, and I have a newsletter where I send updates for new posts like this.

Hope you have fun learning!

What do you need help with?

Karla Dampilag — Sat, 13 Feb 2021 06:41:01 +0000

Let me start: I just started blogging here on dev.to because I want to give back and help fellow humans in the dev community. But I need help knowing what people need help with,exactly. What about you, what do you need help with?

A Programmer's Reflection

Karla Dampilag — Fri, 12 Feb 2021 09:06:50 +0000

Junior to intermediate developers can relate.

It All Started With A Client Meeting

Yesterday, the company I work for had a retrospective meeting with one of our clients. The team at our company that works on that project has met with the team at the client company that handles the project on their end.

It was scheduled for three hours and we talked about the past year, so obviously a lot of things were brought up and discussed. In the end, one thing in particular stuck out to me more than the other topics. It's not because the rest were unimportant, but because this one is an important realization for me.

Here's what happened:

When we came to the topic about the current situation of the project, a colleague of mine, a fellow developer, said something that led to this blog post.

He said that the system is not ready to use in production. That's interesting to hear, especially since the system is already released to production.

That's right.

While we're developing incoming features of the system, our client also rolled out the first version to one of their own clients. This is to test the MVP (minimum viable product), gather feedback, and train these first users to use the new system. That means development of new features and maintenance in production is already happening in parallel.

We're using the agile methodology, by the way. I'm going to share one of my favorite pieces of content regarding software development. If you won't read the entire article, I'll extract the best part for you:

Back to Basics

"Building software in an agile fashion will always be speedier, team members will be more motivated and overall outcomes will be better compared to the plan-months-ahead waterfall style development. As the benefits are immediate...

When building a product, do it in an agile way. Do small changes, get immediate feedback, do small iterations and make decisions that allow future changes as much as possible."

Source: What Agile Really Means

A Tug of War

Back to the meeting, my colleague proceeded to give examples why he thought the system isn't production-ready. The more detailed he got, the more I realized that his concern is the UI (user interface) and UX (user experience).

For example, this view is meant to do one thing. But to do that one thing, the user has to click in different places and do more steps, when it could have taken less clicks and less steps.

He's right, you know. But I'm not gonna talk about why UX is important, because we already know that (it's a whole other topic in itself). What I'm gonna talk about instead is what our CEO said in response to this.

"Well, first you have to make it work." He's also right. Spoken like a true agile practitioner. Our CEO then elaborated on making whatever you're building to work first. And then you can iterate based on the feedback, provided that you can. But more on this later.

My colleague repeated his concerns, and added that he studied this topic (I'm guessing formally, in school). And again, he's right. User experience is important.

Then another colleague said, that you can take your time perfecting every detail like this, and then you turn around and suddenly it's the deadline and you accomplished nothing.

While my colleagues were going back and forth in their discussions, the first thing that came to my mind is that the system is very big and complex. Despite the MVP out of the way, we still have a LOOOOOT of things on our plate for this project. And because of this, details in the user interface are obviously not going to be a top priority. At least not in this stage of the project, when we still have a lot of bigger features to ship.

The Client's Problem

So while our CEO and my colleague were still at it, the client butted in. Can you guess what the client said?

If you'd ask me, I might guess that he complained why the system isn't built perfectly in the first try.

But instead, he said that the current system that their clients are using, the same system that our product will replace, is very unstable. It could fail anytime. He didn't say this next part, but that also means that when it does fail, it will cost them and their clients a lot of money.

He did say that they are under a lot of pressure because of this, that's why they need to rollout ASAP. That's why they already rolled out to the first customer that could accommodate it.

This just confirmed the point of this blog post, which is:

In a perfect world, we can make everything pretty and nice in the beginning. In an ideal world, we have all the time and money we need. But we aren't in a perfect world. We are in the real world, where we have actual real-life constraints.

And in this case, the constraint is that the client has a budget, and they have a deadline.

What Do You NEED?

I totally sympathize with my fellow developer colleague who brought up his two cents. He's coming from a position of caring about the product, that's why he had this concern in the first place.

However, I do agree that as people who implement features, it's important to also see the big picture.
And in this case, the big picture is that replacing their current system with a stable one as soon as possible is the NEED of the client (while having the best UX is not).

Don't Be A Race Horse

I'm gonna share a very good metaphor my dad told me in a different situation, but you'd agree it applies here very well.

Race horses use this thing called "blinders" around their eyes, which prevents them from seeing what's at either side. This helps avoid distraction from other horses that are racing beside them, so they can focus and look ahead.

If, as software developers, we don't look at the bigger picture, we are like these race horses. We only see one side. For creators, this "one side" is usually whatever we're directly working on. I suggest we take the "blinders" off, so we could be more effective at what we do.

Developer vs. Engineer

I think this is what separates a software engineer from a software developer. I read something a while back, that at its core, engineering is "solving problem X, given Y and Z, while considering the constraints A, B, and C." A developer develops, an engineer engineers. A developer is concerned about developing a feature of the software. An engineer considers the constraints as well. And we only went over the business constraint. What about all the technical constraints?

That's why it is the engineers who design what the developers will build. And by "design", I definitely did not mean graphic design, but more on the system design.

Anyway, as programmers, a familiar pitfall is to get too caught up with our code. We get "married" to it. But what about the big picture? What does the client NEED? Why do they need it? And then ask "why" even more.

I'm not saying my colleague is stupid (he wouldn't be working at the company as a software developer if he is). I actually go to him for help regarding the parts of our system of which he is an expert. But we are both "juniors". Let me rephrase - we are both VERY juniors compared to our CEO, and it showed. And as we all gain more experience in software development projects, we gain wisdom like these. I surely did, and I'm sharing this so that hopefully I'm not the only one who learns.

And our CEO? As you might have guessed, he mentioned it's important to look at the big picture. Then he apologized to my colleague for not effectively communicating the big picture to us developers. That is some leadership right there (but again is another topic on its own).

Good Enough vs. Perfect

What about the whole, "it's good enough" versus "it's not perfect" debate that I introduced in the beginning?

Well, the answer is to prioritize, since we already established that we can't have everything.

In a perfect world, we can build our dream product because we have unlimited time and money. We don't. If you ignore that, then nothing is ever finished.

What about you, did you have a similar experience in your journey as a dev?

Dear Code Newbie, Here's A Tip

Karla Dampilag — Sat, 23 Jan 2021 04:15:48 +0000

This is in response to: How Do You Take Notes?

Disclaimer: the points below are more geared toward a code newbie. I'm betting that an experienced programmer won't find this helpful. But if you are one, do let me know if you did this or not, and if it helped, or what worked for you instead.

Here's what worked for me when I was a code newbie:

Write. Down. Code. Physically write it down... in your notes.

The "Success" Testimonial

A little backstory - I took web development courses back in college. At one point, we learned about an API called XMLHttpRequest. It's an old tech, but it's just another API that allows you to fetch data from a server.

Anyway, I wrote the whole thing down in my notebook - from setting up HTTP headers, to sending the request and accepting the response, along with all the magic you could do with the data. You know, typical web dev stuff.

I read it during my commute to class. I made it my goal to do all those things on the computer without referring to my notes.

Eventually, a lab test came, and guess what we had to do? You guessed it! Fetch data from some URL, display the "objects" on the browser, and so on. (I remember when using HTML tables to display responsively was the norm. Eugh 😀) Basically, we had to come up with a tiny CRUD app within the time given to us.

Needless to say, I passed the test since I already knew the process at heart. I remember toying with how I wanted to display the stuff on the screen (the last thing you want to spend time on). Meanwhile, my seatmates were still figuring out how to successfully get the stuff we needed to display.

Do Not Copy and Paste, But On Steroids

You've probably heard of the "do not copy and paste" tip from the coding community. This is in the context that you're learning something new. It's not a secret - the new and unfamiliar code you copy-pasted is too easy to forget. But when you write them on paper, you're applying some variation of "do not copy and paste"... it's on steroids.

What distractions?

You make it harder to get distracted from your computer (or phone). This is especially true for students who need to study for school. Interestingly, the longer I worked as a developer, the less I kept these kind of notes. It's easy to Google syntaxes and commands nowadays.

Beyond the syntax

But even experienced people in the industry still keep some notes... they're just a different kind of content.

For example, soon you might need to draw a diagram to help decide where and how to put relationships in your schema. Or you might need some mockups for this new feature you have to build.

In other words, you spew out quick and "messy" notes of your headspace. These are the kind of content you come up with during the planning and design phases of your work... before they get translated into the more beautiful diagrams and charts for your bosses and clients.

The point is, the notes may vary from person to person, but the purpose is the same - to get it out there, to make it reside in a place that won't go away. Your brain can only hold so much information.

Cheat sheets

Last but definitely not the least, you have your personal knowledge bank.

Remember when you Googled that unfamiliar thing? You had many tabs open. You then arrived with the answer after putting together some different sources. Well, you could pull out those chunks and keep them in a single place, where you can easily access them when you need them again.

Another thing - I noticed a popular term that people use is "cheat sheet". So if you've never done this before, here's some examples for inspiration: React + TypeScript Cheatsheets

The "Failure" Testimonial

Anyway, I felt the need to share this "tip" because I noticed that not everyone does it.

I don't know why, but even my classmates back in college didn't do this. They took down notes during lectures when we talked about theory, but they never did it during laboratory when we wrote actual code on the computer (and presumably applied the aforementioned theory).

I don't blame them - I myself didn't always know it was important to write things down. I was thinking, what's the point, I have a copy in my USB drive!

On my first year in college, we had a Programming Fundamentals course. To learn (and apply) these so-called "fundamentals", we solved small problems on our computer using the Java programming language.

It was fun. We did it all the time, so I found a way to solve the problems faster: I created a template of all boilerplate code, so all I had to do for each new problem is copy and paste the template, and then jump straight to coding my solution. Good bye boilerplate code, hello speed.

One day we had a "test" but there was a catch - no notes allowed. No plugging of USB drives. No Googling. Those were all considered cheating.

I understood the reasoning - the given test was meant to asses our problem-solving skills, applied through programming. When given a business problem, how would you approach solving it, and how would you translate your solution to code?

That said, how could you evaluate your real skills if you didn't solve the problem yourself, right? I repeat, this was school, not the real world where copy-pasting is actually common. There's really nothing wrong about it (unless you didn't even bother to understand why the solution worked).

Anyway, I knew how to solve the given problem. I was excited to implement it, except...

I couldn't get started because I didn't know the syntax of declaring the main method in a Java class. You know, the freaking

public static void main(String[] args)

That's it! That's literally all I had to type to get started, but alas, I couldn't remember 😀

Imagine the frustration of knowing how to do steps one to ten but you can't because you're stuck at step zero. In other words, help the poor girl, she's f*cked.

I want to add, the no-notes rule was kinda stupid, right? I mean, it's stupid to make a test unpassable if the student doesn't know the syntax. In the real world, you can Google the syntax. But then again, it was common for students to cheat. Meaning, a few gifted students already have a copy of the solution in their USB drives. How do they have it, you ask? They copy it from students from an earlier class. These are the students that can graduate but are f*cked once they get a job (if they can get one).

A Word of Caution

Eventually, these seemingly tiny things are things you'll naturally memorize as you keep doing them in your day-to-day life... as a student in your classes, or as a developer at your job.

But in the beginning when you're trying to learn a new language, framework, algorithm, or any new tech... writing things down helps you get familiar with them faster.

But don't just memorize! Obviously you also have to understand what the code does. In fact, make it more fun - simulate! On that same paper, give it different inputs and come up with the supposed output. If your textbook or course is teaching a concept in Java, and you're learning a different language in parallel, then re-write the solutions in the other language. This way, you'll know if you're truly proficient with that language.

I'm in no way telling you to write down every single code you come across with. That just doesn't make any sense. It's your job to determine what you think is important, what you think you'll need later, or what you think is fundamental that you'll need all the time. Then ingrain that in your brain (wow it rhymed). See again: example of a really thorough cheat sheet

What To Expect

Sometimes what you wrote down in the past has finally become second nature to you now. When you revisit those old notes, you'd be ashamed at how noob you were to even need to write those things down. That's good! It means you made progress, you're growing as a programmer.

Keep growing your knowledge repository, and within months (and years), you'll be amazed at how far you've gone. If you're an absolute newbie, your notes might consist of syntax stuff like how to declare a variable, how to loop over an array, how to assign a value, and so on. In months time, your notes may evolve into a collection of your data models of this new module you're building, and so on. You know, the kind of stuff that you can't possibly keep in your head, so you have to write them down?

Parting Words and More Theory

Back to my original story... as a new student, I had an itch to code most of the time, and I couldn't do that during my commute (I had no laptop back then). One can say that reading my physical notes was a way for me to scratch that itch even when I couldn't truly scratch that itch. Sure. But writing those notes and reading them when I had nothing to do... it helped me progress faster than if I just played with my phone during the commute.

I hope you have as much fun learning as I do. Happy coding!