A lot of tech companies decide at some point that they need to "fix the basics", but sadly some of them just refer to rebuild their technology, not a change in the development process. History repeats itself, let's never forget about that.

This is not an article about how to do the fixing, that's different for every company, all of them have their own problems, we can't just grab a "playbook" and think that everything will go as planned, it's a challenge and one that involves more that just making from scratch your code, with the idea that this time it will go well, it's about making decisions that affect the way that you approach work, because if you don't change the way you work, why do you believe that your product will be different this time?

If you find yourself in a company that's going through a process of "fixing the basics", remind your managers, tech leads and whoever is in charge of something inside, that if we don't change our process to do delivery, the same thing will likely happen again.

I recently heard "that's how we do things here, is very relax" and that made me worried a bit, not because of the relaxing part, I really like that, but because I don't see much technical vision, everyone does things as they want, just one person know about one part of the product, so is difficult to share context between the team and there are very few moments where the team can align how to build stuff that affects the features as a whole. This is the reason that made me think about the process, if no one is accountable of the way that we work, even if we rewrite stuff from scratch, is likely that problems will occur again, having to threw away the new work at some point, not too far in the future.

Software engineering is considered an engineering career, because we follow engineering practices and that implies having to "plan" stuff before just diving in the code and hack our way around to build stuff.

I have no intentions on writing how one must do things, just trying to remember whoever reads this that we have to be responsible and accountable of what we do, if we want things to last for a long time, let's take our time to design before starting to write code.

Fixing the basics is not just about code

In my journey to build this blog, as I mentioned in [the first post](/blog/hello-world), I created a custom editor where I can write my articles, using `MDX`, a mix of `Markdown` and `JSX`, this way I can write some powerful and dynamic articles, with code and live execution of that code.

 ![Example of the current editor](https://blogaravena.files.wordpress.com/2021/01/editor-example.jpg)
 
That image above is an example of how it looks right now, not too many options, but as you can see there's a live preview on the right side, and this is what I want to talk about now. As a live preview, it updates on every change made in the editor on the left, even when writing `JSX` code. This was challenging to me, because the component crashes if there is invalid MDX on the editor, for example, when you're just typing some code, like this incomplete button: `<butt`. It completely crashes, without any option to recover.

To fix this, I thought on a way to "cache" the component, in the last valid state, if there's any error in the future state, instead of throwing an error, it will render the cached version, until the `MDX` in the editor is valid.

## Error Boundaries
In React there is a concept called [Error Boundaries](https://reactjs.org/docs/error-boundaries.html), that let's you create a **class component** that will handle wherever "crash" happens on your code. Imagine it like a `try/catch` feature. I won't go into depth in that here, instead I recommend you to read that piece of documentation.

If you were paying attention, you saw that I said *class component* previously and that's because there's no way, natively, to do this using **functional components**, but there's a library that let's us do this called [`react-error-boundary`](https://www.npmjs.com/package/react-error-boundary). Read [this article by Kent C. Dodds](https://kentcdodds.com/blog/use-react-error-boundary-to-handle-errors-in-react) that explains how it works.

## Caching a component
In the example presented on the previous article I linked, he uses the `ErrorBoundary` component that you can import from the library, here I'm going to use a `HOC` (High Order Component) that will let us do the same, this is called `withErrorBoundary`.

The following example is the exact same thing that I'm using right now for my preview component:

```JSX
const Component: FunctionComponent<ComponentProps> = ({ content }) => {
	const [validState, setValidState] = useState<string>('');

	const WithErrorComponent = withErrorBoundary(ComponentThatCanThrow, {
		FallbackComponent: () => CacheComponent,
		onError() {
			console.log('onError');
		},
	});

	const CacheComponent = useMemo(() => (
		<ComponentThatCanThrow state={validState} setValidState={setValidState} />
	), [validState]);

	return <WithErrorComponent state={content} setValidState={setValidState} />
};
```

Here we're defining `Component` as a component that will render the `ComponentThatCanThrow` component. To avoid it from throwing an error and crashing the page, we manage an state `validState` and, with the help of the `useMemo` API, we cache a version of the `ComponentThatCanThrow` with the valid state.

On line 4 we use the `withErrorBoundary` HOC that I mentioned previously:

```JSX
    const WithErrorComponent = withErrorBoundary(ComponentThatCanThrow, {
        FallbackComponent: () => CacheComponent,
        onError() {
            console.log('onError');
        },
    });
```
This is the actual component that we end up returning on our component and its definition is pretty straightforward. The first argument is the component that can throw and then we pass some custom props to it, the first is the fallback that we want to render, in case of an error and the second is just a callback that will be executed when we have an error.

In our case, following the first code above, the fallback component is the same component that can throw, but with a `validState`, so our component will render the same cached one until it finds itself with a valid state again. We pass the `validState` and `setValidState` props to it, so it will update the state when is a valid one.

## Real component
Until now we only know that the component that can throw is called `ComponentThatCanThrow`, so let's take a look at how it should be to work with our implementation:

```JSX
const ComponentThatCanThrow: FunctionComponent<ComponentProps> = ({ state, setValidState }) => {
	useEffect(() => {
		setValidState(state);
	}, [state]);

	return (
		<MDX>
			{state}
		</MDX>
	);
};
```

Here the part that can throw is the `MDX` component. We update the `validState` of the parent component after the first render, with the  `useEffect` API. This will only be executed if the component doesn't throw with the current `state`, so we know its a valid one. If it throws, it won't be updated and our `CacheComponent` will keep the previous valid state.

I don't know exactly who needs something like this on the usual react project, but it certainly is useful to me on my website. Feel free to ask if there's is anything you want to know about it.

Error boundaries and cached components

Since the beginning of this year, 2021, I started in a new company, a well-known Silicon Valley startup, that's been around for 2 decades now. I'm talking about the note taking app, **Evernote**. I want to talk a bit of why I decided to come here and the challenges that I think I will encounter during this journey.

First I'd like to talk about my previos job, working as a consultant for ThoughtWorks. I was part of this amazing company for almost 4 years, this is the place where my career as a software engineer begun and I surely hope to come back in the future, but let's not get ahead and talk a bit about the past. Since this was my first job, the first engagement with a client that I had, one of the best, I have to say it, was a very powerful experience, working with a very powerful team that was assembled to start as the first team inside this client. I **learned a lot** and this is the team where I started to define myself as a **frontend developer**. This was the first year.

During my second engagement, I was asked to be part of a team where they needed some React experience to help rebuild the web interface of a payment platform. They reached to me and then I started, but not right away with React, since the client didn't want to prioritize this work right away, so I had to learn how the current frontend of this project worked and it was *bad*; they had the problem of <a href="https://en.wikipedia.org/wiki/Not_invented_here">Not invented here</a> and it made the whole company to built the web in a custom developed web framework, a mix of Backbone and jQuery stuff. Don't get me wrong, it was not a bad framework, but the following versions, not the first one and our project was using the first one. It took me sometime to get used to it and to bring the necessary arguments to push for the new frontend. In the end, it worked and we started developing the new project a couple of months later.

I have to say, **this has been the best team that I've been part of**, so many excelent people, across all the different roles. It was awesome. After one year of work we started to release the new version of the project and it was a huge success. We were a data driven project and we could see the benefits right away, there was no doubt that what we built was first class software. At this time I decided that I **wanted to specialize myself** as a frontend developer.  I was a part of this team for almost 2 years.

Then, the last year, 2020, I was part of 4 different teams and this made realize something that pushed me to resign and that is that I wanted to be part of a **product focused company**. Until now my job as a consultant made me move rapidly between different teams and different clients, specially at the end, not having much time to learn a lot about the business and always having the feel that I could have done better having more time to prepare. This was a hard year, the pandemic changed our way to look at job and we went full remote. **I had to take advantage of this**, since I wanted to be able to work as a *digital nomad*, not right away, but in the near future.

So my job hunting began, the first step updating my <a rel="noreferrer noopener" href="https://www.linkedin.com/in/jcaravena/" target="_blank">LinkedIn profile</a>, then applying to different product focused companies around the world and I mean this, I applied to some stuff in **SEA (South East Asia), Europe and USA**. At this point I was about to leave <a href="https://www.thoughtworks.com" target="_blank" rel="noreferrer noopener">ThoughtWorks</a>, this happened officially in November 13, but I was on medical leave since the end of October, since I had a urgent surgery to remove my appendix, the famous useless appendix that can be quite dangerous when it starts to have problems. During this time on leave and then without a job I applied to a variaty of product companies and started studying a bit again.

After not hearing from most of them, having a few interviews and realizing that it was not going to be too easy, I found from a colleage that <a rel="noreferrer noopener" href="https://evernote.com" target="_blank">Evernote</a> was offering positions in Chile. This was interesting, so I applied here too and the interview process began. I had 2 interviews with people in Chile and 3 others with people in USA, members of the team that I was being interviewed for. It was challenging to me, since I would have to make the interviews in English, language that I'm not quite used to talk, since I mainly write in it or just use Spanish.

Long story short, I made it and got the offer letter from Evernote and I have to say, its a lot more than what the market pays here for software engineers with my amount of years of experience, so I was quite happy with it, specially because it was more than the minimum salary that I calculated I needed to be able to live in Europe, the first continent that I want to visit when I start working as a digital nomad. I got the offer in mid December and I would **start working on January 5th, 2021**.

I've been here for 2 weeks now, the way we work is quite different to what I was used to as a TWer, a lot more flexible, working with teammates based in different cities of USA, without a fixed time during the day to be online, I just need to make sure that I'm working and finishing the work that I'm being assigned by now, mostly small fixes, to get used to the project. I've been assigned to work on the mobile app of Evernote as a frontend developer, but this time **mobile frontend**, not web. I'll be writing about this change in the future.

Now is my time to get used to the app, understand how we're working, how we're making decisions and help my team to build things that bring the most value to our users, I'm very excited to get to know the **product design team** and the **UX team**, to make sure we bring the best experience that we can build. I'm really confident that I will learn a lot working here, I hope to be able to make my network bigger, with people from different countries, backgrounds and with different approaches to work.

Here's to a different 2021, with new goals and new challenges.

**JC**

On changing to a product

Once again is time to share my thought on this site, this time, hopefully, will be the last that I start from scratch this blog.

This site is built using <a href="https://nextjs.org">Next.js</a> and <a href="https://wordpress.com">WordPress.com</a> as backend, fetching the articles and building a static page. I think that this is the best setup that I can use, as my personal blog, since I've been a WP user for years now.

This blog post is being written in a custom MDX editor that I build to be able to use JSX inside articles, hope it works well. I'll be talking more about this setup in future articles.

Welcome to my blog!


Hello World

I already told you that I'm back at the univerity to finish my bachelor's degree. To me this was supposed to be a boring thing, something that I'm doing because I need to be able to do a masters and/or PhD in the future, not because I really want. If you remember, I quit university 2 years ago.

But I found something interesting, there's a new professor here, a new face to me, and to my surprise, he was giving a lecture about microservices. I didn't think twice before joining it. My interest comes because I work with microservices on a daily basis at TW, so I wanted to know how is it to study it in a more "academic" way.

And something happened when I told him that I work at TW. It began by an email I sent him about what we do about microservices, just a short text with a few links and then he answer's me: "ThoughtWorks! Oh my...". That was interesting to me, here in Chile we're quite new, so a just a few people knows us, at least from the people that I know. That made quite happy actually!

So now I hope we get along well, I really want that, so we can learn a lot from each other.


About microservices

Last year I went to India in the best trip I've had until now, I think I talked about it before, not sure anymore. The thing is that during that trip we went to a place called [Ellora Caves](https://en.wikipedia.org/wiki/Ellora_Caves), the most beatiful place I've been to. I loved it so much that I was taking pictures of everything. The people that was with me had to tell me to hurry up, because I was stalling everyone and we had a lot to walk still.

In that place, being pressured by locals to buy things from them, I went to *help* a friend who was being harrased by someone tryng to make her buy something. So, me, the hero, ended up buying a necklace from that man. At first I didn't want to buy anything, just help my friend get away from the salesman, clearly it didn't work.

But I was super happy buying that necklace and been wearing it since that day to today, not as a necklace, but as a *bracelet*. I love it and I actually feel bad when I forget to put it on. It's silly, but I'm really fond of it and I want to keep wearing it, but **it broke today, again**.

It's the second time that this happened, I think the first one was close to this date last year. I know because it was before I went to Europe in October, so it must have been close to September, maybe August.

I fixed it last year using a fishing thread, because I thought it wouldn't break again with that, since when I bought it it just had a cotton thread. Now I have to look for a way to fix it again, probably going to use fishing thread again, since it worked really well.

![Bracelet](https://blogaravena.files.wordpress.com/2021/01/indian-bracelet.jpg)

I love it, and it deserves to be fixed again, even if it takes me a long time, since I have to move those stones it has one by one to a new thread. Yep, it takes times, but it's worth it for me.


JC's Writing

Fixing the basics is not just about code

Error boundaries and cached components

On changing to a product

Hello World

About microservices

It broke again