DEV Community: Ivan Levenhagen

What do we look in a Software Engineer

Ivan Levenhagen — Mon, 18 Dec 2023 18:32:25 +0000

In my experience as a software engineer, I've found that excelling in problem-solving demands skills beyond coding. Effective communication, initiative, and ownership are essential. In this article I share on what I seek when evaluating potential software engineers for our team, and the practical skills I think are needed for success. So what are these skills, and why I think they are so important for success?

Communication is fundamental for a good software engineer. Our work isn't just about technical skills; it's also about explaining our ideas and solutions clearly. If you can't explain your solution well, it might mean you don't fully understand what you're doing, or proposing.

In our hiring process, we keep our code challenges as simple and open-ended as possible. This allows the candidates to show their problem solving skills, and also is an opportunity for them to explore something new, whether it's a new technology or a concept they may be unfamiliar with.

Ownership also shows how well a candidate documents their work, and how much they care for it. Similarly, writing articles and sharing them publicly is a great way to demonstrate ownership. It can offer insights into their processes, the obstacles they tackled, and the lessons they learned. Being willing to document and share not only benefits the community but also shows a sense of pride in the work.

In conclusion, I think that being a good software engineer, goes beyond technical skills. Clear communication, initiative, and ownership are just as important. Communicating your ideas, taking the initiative of proposing innovative solutions and having ownership of your work, is what truly makes someone excel.

If you want to work in a startup in its early stages, This is your chance. Apply today!

Woovi is a Startup that enables shoppers to pay as they please. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

If you want to work with us, we are hiring!

Photo by Chris Lawton on Unsplash

Using Conditional Put to Solve MongoDB Concurrency Issues

Ivan Levenhagen — Mon, 02 Oct 2023 12:26:19 +0000

When building applications, handling concurrency issues is a critical aspect of ensuring data integrity. MongoDB lacks an API for conditional expressions in inserts, a feature that is standard in databases such as DynamoDB, making dealing with concurrency harder. How can we effectively manage situations where multiple entities attempt to write to the database simultaneously, potentially compromising data integrity? In this article, we will explore three strategies to address this challenge: FIFO Queues, Distributed Locks, and our main focus, Conditional Put.

Concurrency issues occur when multiple entities attempt to write to the database simultaneously. This can lead to conflicting writes, potentially compromising data integrity. Guaranteeing that only a single entity will be able to write on a database given a condition, is crucial for some systems.

To address this issue, there are a few strategies we can use. In this post, we will go through three of them: FIFO Queues, Distributed Locks, and our main focus, Conditional Put.

Before diving into possible solutions, we need to identify our problem. Our scenario is the following: We're building an application where Users can request Races which can be accepted by Drivers. We will focus on the User requesting Races part. Our goal is that a User shouldn't be able to request two Races at the same time.

Note that this is an extremely simplified version of the data modeling. The focus of this post isn't the data modeling but how to solve a problem like the one presented.

Now that we have our 'schema' and problem, let's talk about how we can approach to solve it.

FIFO Queues

FIFO stands for 'First In First Out'. In our case, it would be a message queue without any concurrency, guaranteeing that all the requested writes would be always tried in the order they were requested. We can just add a check if the item already exists. In a way, we can say that FIFO Queues would guarantee that there wouldn't be any concurrent attempts at writing on our database.

The problem with this solution is scaling. Imagine we have thousands of operations being realized at the same time; a single queue wouldn't be very fast to handle it. This could result in a poor user experience due to latency. The advantage is that it is very simple to implement, especially if you already have a message queue system implemented in your application. All you would need to do is create a new queue for it.

Distributed Lock

Distributed Locks would be a more robust solution to our problem. In a Distributed Lock system, the system distributes tokens to consumers. We add a lock to our process and check if the consumer has a valid token. If not, we just return an error. This would allow us to still run concurrent processes; we could have only a single valid token available at a time for a User, per race requested. Whichever request acquires the lock first, wins the token and can write to the database.

This is a pretty robust solution, and it would also scale nicely. The problem with Distributed Lock systems is that they are very complex. Going deeper into them would be a subject for another article, or possibly even several more. Another point to consider is that you most likely would be introducing a new layer to your application, maybe something like Redis or possibly a more robust locking system.

Conditional Put

This is the main focus of this post, and probably why you're here. While MongoDB has a conditional expression system for updates with the $cond operator, it doesn't have one for inserts, which is where our problem lies. But that doesn't mean it's not possible to make Conditional Puts in it; we just need to be a bit more creative.

We can solve our problem by adding a new field to our Race model, which we will call conditionId. This field will be an ObjectId with a unique constraint attached to it.

So what is this id? What is it going to reference? This is where we get creative; this id will be the id of the last race requested by the user. Due to the unique constraint we added to the field, we can guarantee that only a single document will exist with it; all other attempts will fail at the database level.

Here's some pseudo code of how our logic would look:

const raceConditionIdGet = async (user: User) => {
  const [lastRace] = await Race.find({ user }).sort({
    _id: -1,
  });

  return lastRace._id;
}

const raceCreate = async ({ user, ...args }) => {
  const conditionId = await raceConditionIdGet(user)

  const race = await new Race({ ...args, user, conditionId }).save()

  if(!race) {
    return error
  }

  return race
}

Now you may think, what if this is the User's first Race? There won't be a valid conditionId, so what do we use? In this case, we can use the User's own id.

const raceConditionIdGet = async (user: User) => {
  const [lastRace] = await Race.find({ user }).sort({
    _id: -1,
  });

  if(!lastRace) {
    return user._id
  }

  return lastRace._id;
}

You can see that our conditionId acts very similar to the idea of the Distributed Lock token; the advantage is that we didn't introduce any new system to our codebase. But just like any other solution, it has trade-offs. While storage is cheap, does it make sense to save this id? What if we have multiple conditions? Would it be a good idea to just keep saving new ids, maybe even repeated ones in the same document?

Conclusion

Just like pretty much any other problem like this one, there is not actually a right answer; it all depends on your context. If you already have a message queue system implemented and are not expecting a lot of demand, the queue system will work just fine for you. You may (probably) be building something way more complex than our contained example, so the distributed lock may make more sense for you.

If you want to work in a startup in its early stages, This is your chance. Apply today!

Woovi is a Startup that enables shoppers to pay as they please. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

If you want to work with us, we are hiring!

Learn, Decide, Grow

Ivan Levenhagen — Fri, 16 Jun 2023 15:07:44 +0000

Working in a rapidly growing startup like Woovi requires you to adapt quickly to the market and customer demands. This environment often demands rapid decision-making. Being able to make decisions quickly, learn from them, and course-correct is crucial for us.

To make things easier, we document every single type of decision we take, showing both the tradeoffs of different approaches, and what we have learned from them. This way we take away some of the cognitive load, by making a map of our past mistakes.

For example one of the documented decisions we have is When to create a new Component. With a pretty small document we managed to save a lot of time from future decisions.

But while this helps in a lot of cases, everyday at Woovi we're presented with new challenges. These unexpected situations might seem daunting as they often necessitate quick decisions in the face of uncertainty.

To be able to move quickly in these scenarios, you need to understand and accept that not every decision you make will be the best one at first. Getting things right, especially on the first try, is extremely hard, if not impossible.

It's better that you fail as fast as possible and learn from it, rather than avoiding decisions due to fear of failing. Rather than seeing it as a failure, see it as an opportunity to learn, see what went wrong, and why, share with your team your discoveries. This mindset of 'failing forward' not only accelerates personal growth but also drives the evolution of our team and the entire organization.

If you want to work in a startup in its early stages, This is your chance. Apply today!

Woovi is a Startup that enables shoppers to pay as they please. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

If you want to work with us, we are hiring!

Photo by pine watt on Unsplash

Double Entry for Developers

Ivan Levenhagen — Fri, 31 Mar 2023 19:03:20 +0000

At Woovi, ensuring the accuracy of our numbers is crucial. Even the slightest mistake can cause irreparable damage. For this reason, we have a robust ledger system at our core.

If at any point in your career you find yourself working in a place that deals with numbers, you will undoubtedly come across the terms Double Entry Accounting and Ledger. But what exactly do they mean?

A ledger refers to the Book of Accounts, which is responsible for keeping track of all transactions. The accounts represent the 'where' of the debit or credit event.

One of the biggest misconceptions surrounding ledgers is the idea that all the accounts within a ledger are bank accounts. This is not true. While a bank account may use a ledger to keep track of its numbers, the ledger itself does not specifically concern bank accounts. Accounts within a ledger can be used to track virtually anything you want.

Another common misconception lies in the notion of double entry. Double entry transactions do not necessarily mean that there will always be exactly two entries within a transaction. Rather, it means that there will always be at least one Credit and one Debit within it. As long as the sum of credits and debits inside the transaction matches, it follows the rules of double entry accounting.

There is not a single correct way of representing something on a ledger; it all depends on your wants and needs. Let's look at how you can represent the same transaction in multiple ways using this example:

Suppose we have a lemonade stand in front of a shop. To let us stay on the sidewalk, this shop charges us 10% of each lemonade we sell, and we charge USD 300.00 for each drink. Yes, our lemonade is that good. So, how can we represent the sale of a drink on the ledger?

Both of these methods are correct ways to represent the sale of the drink on the ledger. It's all about what we want and need. Does it make sense for us to record the fees being paid by us separately? Will this number be useful for us in the future? It all depends on what and how you want to use the ledger.

Note that we have no mention of banks here. We have an account that tracks our earnings, one that tracks the small shop earnings, and one to represent the buyer. Do you want to know your earnings by customer? Create an account for each of them! Accounts on the ledger are nothing special; they're just another row on a database.

If you want to work in a startup in its early stages, This is your chance. Apply today!

Woovi is a Startup that enables shoppers to pay as they please. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

If you want to work with us, we are hiring!

Photo by Rod Long on Unsplash

Making Good Pull Requests

Ivan Levenhagen — Tue, 14 Mar 2023 13:37:38 +0000

At Woovi we have a culture that every dev should review all pull requests, due to that it's crucial that we follow good practices to make the reviewing process easier, and also give context on what we're working on.

A good pull request have a few characteristics to it, you can have more rules depending on the culture you're trying to nurture, but you should always try to follow these points:

Small / Atomic

One pull request should be responsible for a singular change when possible, this not only makes it easier to review, but it lowers the chances of introducing bugs to the code base.

Linked Issue

Ideally every pull request should have an issue linked on it. This makes it easier to track what's being done on the issue, improve the documentation of changes, and also makes reviewing it easier.

Tests

Regardless of how small a change is, almost all pull requests should have a test attached to it. Having tests for even small changes and bug fixes is important so we don't introduce the same bug on the codebase again. It's important that the tests are in the same pull request as the changes, not only it makes it easier to review the changes, it also makes it easier to review the tests.

Prints

If your pull request makes a visual change, it's important to always attach a print to it. It makes sure that everyone can easily see the change you made.

What Should You Do Before Making a Pull Request?

Before making a new pull request, you should make sure that the code you wrote is ready for merge, here's a few steps you can do:

Run the tests you wrote, or any associated with the pieces you're changing.
If your tests generated any snapshots, make sure to guarantee the snapshots are correct.
Run any commands that will generate code, like for example i18n and make sure to do the needed changes after running them.
Update any snapshots needed.

What Should You do After Making a Pull Request?

Your work doesn't end when you finish publishing your changes, after actually making the pull request you should also try to follow these steps:

Review your own code
Respond to comments and feedback the team gives you

Any feedback given in the pull request should be considered, when someone gives feedback on a pull request it means that they thought and properly reviewed your code, if you disagree with a point, make sure to respond with your own arguments. Feedback is not an attack on your work, so make sure to always respond to any feedback given. If you're thinking you're not getting constructive feedback, make sure to let it clear to team how you'd like feedback to be given.

Examples

Bad Pull Request:

Good Pull Request:

If you want to work in a startup in its early stages, This is your chance. Apply today!

Woovi is a Startup that enables shoppers to pay as they please. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

If you want to work with us, we are hiring!

Photo by Cole Keister on Unsplash

Adapter Pattern: Adapting Data from the Outside World

Ivan Levenhagen — Mon, 13 Feb 2023 20:53:29 +0000

Often while building applications we consume data from outside services, and even save parts of it on our end. A very common mistake is adapting your architecture for these services, what you should do instead is adapt their data.

On Woovi our application communicates with various different applications from the outside world, also known as 3rd party apps. These applications have their own data modeling and doesn't always fit ours, so we must adapt their data to fit ours.

This approach have some benefits, such as decoupling. For example if we consume a email provider and then decide to change to another one in the future, rather than restructuring our architecture to fit the new provider, all we would need to do is create a new adapter and everything should stay working.

Another benefit is that it lets us not only learn from others modeling, we can try to evolve them to what we believe is the correct approach.

The Adapter Pattern

When consuming data from third party, before saving it to our database, we always run it through an adapter function. This function job is to accept a payload and return a payload for our structure, to avoid losing data, you can choose to save the original payload on a metadata field or something similar.

Creating an Adapter Function

Creating an Adapter Function is pretty simple, using a very contrived example, let's say we want consume a API for geo location, and save the latitude and longitude that it returns in our database.

In our data, we decided that both the latitude and longitude will be different fields, but when calling this api, it returns both values inside an array instead:

latLong: [40.689247, -74.044502]

Rather than altering our modeling to also accept an array, all we need to do is adapt this field to ours:

const latLongApiToLocation = (payload) => ({
  latitude: payload.latLong[0],
  longitude: payload.latLong[1],
});

While this is extremely simple, it makes the data ours and we're not dependent of this API, all we would need to do to replace it is create another of these functions, while maintaining the data in the structure we believe in.

If you want to work in a startup in its early stages, This is your chance. Apply today!

Woovi is a Startup that enables shoppers to pay as they please. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

If you want to work with us, we are hiring!

Photo by Alexandre Debiève on Unsplash

You (most likely) don't need to optimize React

Ivan Levenhagen — Thu, 06 Oct 2022 16:18:48 +0000

One of the biggest pitfalls in software development is early optimization, we always want our code to run as fast as possible and try to squeeze every single drop out of it. But going through this process too early can do more harm than good.

Woovi is a Startup that enables shoppers to pay as they like. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

The most common mistake in React projects is the use of the useCallback and useMemo hooks, you (most likely) don't need to use these hooks, let's take a look how useMemo works to understand why.

So, what does useMemo do? It accepts two parameters, a Callback and an array of dependencies, and returns the return of this callback. The dependency array is used so useMemo can track if this value is stale, if the dependencies values changes, this mean we have to calculate the value again.

Now, all of this sounds amazing, so why don't we just useMemo everywhere? Let's take at this very contrived example:

const fruits = ['apple, 'banana', 'orange']
const initialFruit = useMemo(() => fruits.find(item => item === 'orange'), [])
const [fruit, setFruit] = useState(initialFruit)

While it's great that we're not running the .find on every render, we have to ask ourselves, is it worth it? useMemo itself is more code it isn't completely free to use, we added more complexity to our code which makes it harder to maintain. React is fast, you don't need to optimize every single thing, what's expensive in React is committing changes to the DOM not a simple calculation.

So when should I optimize React? It's actually very easy to know. If you're asking yourself this question, you don't need it. When the time comes that performance is a problem on your code, you'll know it.

Focus your time creating new features for your application, not optimizing code that you probably don't even need to.

If you want to work with us, we are hiring!

DEV Community: Ivan Levenhagen

What do we look in a Software Engineer

Using Conditional Put to Solve MongoDB Concurrency Issues

FIFO Queues

Distributed Lock

Conditional Put

Conclusion

Learn, Decide, Grow

Double Entry for Developers

Making Good Pull Requests

What Should You Do Before Making a Pull Request?​

What Should You do After Making a Pull Request?​

Examples

Adapter Pattern: Adapting Data from the Outside World

The Adapter Pattern​

Creating an Adapter Function

You (most likely) don't need to optimize React

What Should You Do Before Making a Pull Request?

What Should You do After Making a Pull Request?

The Adapter Pattern