DEV Community: Adith Widya Pradipta

3.5 Years as a Front-end Engineer - Things I Learn and What Next?

Adith Widya Pradipta — Wed, 14 Jul 2021 13:53:20 +0000

Originally posted on my blog.

Every once in a while, we software engineers/developers face a moment where we have to slow down our thought and take time to rethink, reshape, and eventually replan our careers. Have we made our career so far on the "wise" path? Did our progression was the best decision for our individual development?

So far in my software development career, I see differently now about "promotion." Frankly, I was even scared of it. And I am not pretending about it. Everything is now inside the merit-based "scope." For illustration, was I deserve to receive that promotion? Was it based on my skills or just my experience (how long I've been) at the company?

But in reality, you can't decide your fate about everything, and it's all right. I will never be ready for everything. Our career growth is no exception.

So, as my attempt to maintain my expertise (and improve it) and be ready for everything in the future. I've read some books, digesting some tutorials, creating courses, launched a product, and now writing a blog. So in this article, I'll share my learning so far.

(Try to) Think Like a Software Architect

The truth is, I've never been a software architect. My three and a half years of career as a software developer, mainly as a developer. Wait, what? Did I indicate that software architect and software developer is different? Yes, I did. According to this book: Fundamentals of Software Architecture by Mark Richards and Neal Ford.

The mental difference is based on "How to see at some point of view." But before I dive deeper into that, I need to explain why I think this is such an excellent book to read and to be prepared for the next challenge. As I am reading this book, I reach what I felt was the correct path on my own. In the end, I will go ahead with what I do now. As my career path grows, I will have little time to do actual coding tasks and be involved more in decision-making.

My takeaways from learning this book will not incorporate all of the book's contents. It only satisfies about 3-6% of the book's overall contexts. So everyone still needs to absorb the book to get all the meat.

My key takeaways from the book are from Chapter 2: Architectural Thinking. During my entire career, when it comes to picking a technology stack (tool, library, or framework), I begin with the benefits of the tech choices. But I never analyzed the trade-offs. Talking about architectural thinking, I need to look at the help of a given solution (or a stack) and explore the negatives, or exchanges, associated with a solution.

I'll take an example from Lee Robinson's tweet. He's the Head of DevRel at Vercel, the company behind creating one of the most delicate React frameworks: Next.js. Still, regardless of how convenient it is to use Next.js, it also comes with negatives or trade-offs.

Deciding to use the frameworks has to come after deliberation of the trade-offs. For occurrence, is our team is already proficient with another language/framework and doesn't want to switch? Is the web products we want to build will need a lot of JavaScript to run? Or maybe our team is not a React person and more of a Vue person?

Before deciding on the stack, addressing those trade-offs makes the difference between (most of) developer thinks vs. software architect (should) thinks. And finally, the actual answer for those questions is always, "It depends." You can't Google it. And the final decision must be taken after we proceed with solutions we genuinely evaluated based on our concerns. It can depend on the business needs, environment, people, and a host of other factors.

Technical Breadth vs. Technical Depth

I've talked about pondering trade-offs before. But this part is the hardest (at least for me personally). When I need to choose when to add stuff, I must know, maintain expertise of things I already know, and knowing what I don't know. It requires very effective time and energy management.

Someone says that a good place to learn to program is on the job. I've learned so much on the job, but I also learn so little on the job. Don't get me wrong, I fully agree with learning on the job. Because I feel know how to do a lot on the job, to an extent. When I hit that wall, it's hard to get around. There needs to be time to learn other than just on the work I am currently doing.

So I've spent more time learning outside my work. I am maintaining my expertise on something I already know (like taking the Epic React course by Kent C. Dodds) and expanding my expertise for something I don't know (like discovering Rust). But I feel like it is something that I can't do forever. Let me clarify.

My work as a software developer required me to have a significant technical depth to perform my job. Means I need to stack up "stuff I know." But that is not enough; I also need to maintain it. I've been doing web development work with React since 2017. I can say I know a lot about it. But it's 2021 now, my React knowledge is quite obsolete right now if I'm not maintaining and upgrading my React stuff these days. That's why I called it keeping the "stuff I know" or Technical Depth.

Fast forward to the future, and by recognizing other's personal experiences, Technical Depth simply is not enough. I am required to have broad knowledge about other technical stuff outside my current expertise. Because the kind of information a tech person should have value differs within career stages. It is more in the "stuff I know I don't know" field. I've heard the good news about Rust; it is syntactically similar to C++ but with many improvements. The development was even supported by some notable names, including Brendan Eich (the creator of JavaScript). I can't code the language yet. But I know Rust will solve particular problems in a way JavaScript can't.

If a developer transitions into the architect or decision-making role (like a lead developer). A large part of the value of that role is a broad understanding of technology and how to use it to solve particular problems. It is more advantageous to know that three solutions exist for a specific situation than to have singular expertise in only one.

When my career has come to more decision-making, it has to either pursue Depth or Breadth of technical expertise. A broad understanding of a wide variety of solutions is valuable. Hence it has to be Technical Breadth with more weight to choose from rather than Technical Depth.

I've said it before that it's the most challenging part for me. Choosing one of the options rather than both. The skills I've already acquired until today are "hard-won." Either it hard for me to learn, or it was expensive. Someday I will "say goodbye" to all of them. Only taking fundamental skills with me to wade through the next stage of my career.

Increase Productivity and Produce More Values

In my earlier days as a software developer, I didn't value time like I do today. I didn't even know the difference between Productive and Busy. At the end of every workday, I'll feel satisfied when I busy all day. It feels good to be busy back then.

Turns out they are different. You can be busy without being productive. But you can be effective and produce a lot of value without being gaudy at all. It was felt mystic when I knew it, "Do more with less time?". Since that day, I decide to persevere productivity more.

But it wasn't that easy. It requires a lot of habits to fix to achieve better productivity. My sleep habits weren't that good. Turns out, everything has come down to this. Improving my sleep habits opens many possibilities for better productivity.

In my earlier days, I spent all working hours just to finish all the tasks on my full-time job. My skills and speed to complete all tasks in a day weren't that good. It has to do something with my learning habits. Because every day after work, I always feel exhausted. But I also feel delighted with what I did every day. No energy left to do extra Coding or learning stuff. But that doesn't mean I will sleep right away; instead, I was playing games. Eventually, I had a lot of late nights sleep cycles.

When I finally fix my sleeping habits. I have more energy to do more. I started to do part-time jobs, creating content and doing a business that gives me passive income. It's not about hustling; it just a way to avoid wasting my precious time. When I can get more done, I'll have more time to learn, be better at my job, creating value in my business, and earn more money to provide for my family.

Epilogue

It's been a very fruitful moment of my life. I started in engineering career as a Coding Bootcamp graduate. It was a very fulfilled experience to have been able to have a time in my life as a software engineer. Three and a half years (and counting) to do the work as a front-end engineer pave the way to various possibilities, meet new friends, create more values, and provide my family better. Even before being a front-end engineer, I thought I will never have a spouse.

I should have also written a blog to summarizes my life pre-engineering career. So I can finally say thank you to all persons who helped me have a better life by accepting me as an engineer. If you want to read it, stay tuned for further updates!

Why We Use React Hooks useState

Adith Widya Pradipta — Thu, 01 Jul 2021 13:41:46 +0000

Ever wonder why we have to wrap every data/state inside our React component with useState? Why don't we just use a simpler approach like making variables with a let keyword, and initiate our state there? Like what we can do in Svelte for example.

Let's talk about it deeper with a code example:
*Also, you can play around in this CodeSandbox

import * as React from 'react'

function ReactComponent() {

  // What if we just do it this way?
  let favoriteFood = ''

  const handleChange = (event) => {
    // Let's change the favoriteFood variable
    // to hold our new state
    favoriteFood = event.target.value

    // Let's peek the value we type to the input in console
    console.log(event.target.value)

    // Prove that the variable/state value is change
    console.log("fav", favoriteFood);
  }

  return (
    <div>
      <form>
        <label htmlFor="favorite">Favorite Food:</label>
        <input onChange={handleChange} id="favorite" />
      </form>
      <p>
        {favoriteFood ? (
          favoriteFood
        ) : (
          'Type your favorite food, please!'
        )}
      </p>
    </div>
  )
}

export default ReactComponent

As you can see in the code example above. We use a simple variable to hold our state. The code is working if you see it on the console panel. It shows change on every word we type to the input. But you will notice instantly, that your favorite food name is not displaying on the render. Nothing.

But, why? The code is not showing any errors. What we type to the input is perfectly showed on the console panel. Even the variable value is updated.

Turns out, it has to do with the "render" part in React. And that's the part where one of the React Hooks API called useState will do the job flawlessly.

In the previous code example, we're not using any "mechanism" on our state initialization. We just using a pure variable with a let keyword. Nothing in the code is telling React to update the render (rerender) when we trigger a state update, to show the new value of the state to the user interface.

Let's hold keywords for this: Trigger a state update, New value of the state, and mechanism. After that, make a change to the code like below:

function ReactComponent() {
  //let favoriteFood = ''
  const [favoriteFood, setFavoriteFood] = useState('')

  const handleChange = (event) => {
    // Remove all the codes before
    // And change to this:
    setFavoriteFood(event.target.value)
  }

  // ...rest of the code
}

Now we finally use the useState API. Notice we have two elements inside what useState returns as an array: favoriteFood and setFavoriteFood. We can also call it accessor and mutator (adopting from other programming language concepts).

The accessor (favoriteFood) is where React useState stores the state for us. The mutator (setFavoriteFood) is what React useState gave to us for the function we can trigger to update our state in the accessor. And after we trigger state update with setFavoriteFood, now favoriteFood will hold our new value of the state.

Okay, what the difference then with our previous approach? With a simple variable with a let keyword before?

That's where React useState is performing the difference. React useState has a mechanism that will tell React to always updating the render on every state update. Because after we trigger setFavoriteFood, the state inside favoriteFood is updated, then we need something to work for us to update the DOM with the current updated state we have. And voila! What we type on the input, is immediate shows on the render. Thanks, React useState!

It concludes the sole reason why we really need React useState to manage our internal state in a React component. Because we are provided with a built-in mechanism inside the API to control the rerender on every state update.

But, what if we don't want to trigger rerender when we store something and later change it? That's the job for React useRef. Maybe we can talk about it in another blog post 😋