DEV Community

Yonatan Karp-Rudin
Yonatan Karp-Rudin

Posted on • Originally published at yonatankarp.com on

4 Engineering principles I've applied in real-life

My employer announced a couple of months ago that any employee who works for 3 years or more is entitled to a sabbatical. This sabbatical is a fully paid 1-month vacation (month of your choice). As I also had tons of vacation days, my wife and I decided to go on a 2 months trip to Asia. We wanted to go there for a long time. After some thinking, we decided that our destinations would be Thailand & Philippines.

While the trip was great, and we had a lot of experiences this post will focus on the other side. In this post, I would describe step by step how I used methods from my day-to-day work as a software engineer. Applying them helped me to solve problems in real life.

Eventually, something will break in production

As the old say goes, eventually you would have a production incident. In our case, it was sooner rather than later. A couple of hours after we landed in Thailand we discovered that we had a huge issue. Both my credit card & my wife's expired on the day we landed. That was a big surprise for us. Back home, your credit card provider will replace your card at least 6 months before it's expired. Yet, as we now living in Germany for almost 4 years, we learned something new. Here, you need to ask your bank for a new card if you want to have one (lesson learned!). Good thing was that we also brought some cash with us to the vacation.

So what did we do?

we started by estimating how big the problem, what is the impact, what are the options for solutions and how fast we need to apply them. The outcome of this discussion was very useful. We agreed that if we use Airbnb for booking for example we can save the usage of the cash we have with us. We also discovered that we had enough cash for a while, and thus we can start our vacation.

List the possible solutions to our problem enabled us to:

  • Understand the scope of the problem.

  • Understand the complexity of the possible solutions.

  • Choose the solution(s) that fit our needs best.

Retro & action items

When we planned our trip, my wife & I decided that we will book ourselves an Airbnb for 5 days. This will give us enough time to handle the jetlag, and enjoy the city. In the end, even though our jetlag indeed stayed with us for 3-4 days, we felt that we could stay for a shorter time. Moreover, our Airbnb was Ok, but not great, and a bit too pricey.

So what did we do?

As the title suggests, we had a short retro. We talked about what we did good, and what we did badly here. We agreed that going blindly is not a great idea. Moreover, what if we don't like the destination we're going to? Why should we commit for a long period?

The result of this retro was an action item that we used throughout our trip. We don't book any place for more than 2 nights. We can extend our staying later on if we like the place. This gave us the option to change the hotel if we didn't like it, or if we felt that we want to continue to our next destination.

This 10-15min discussion on the 1st week of the trip helped us plan ahead and avoid frustration later on. That's what I'm calling a good investment!

Always have someone checking your work

At some point in our trip, we had to book an internal flight. I've found us a flight, it wasn't on the ideal date, but it was the closest we had considering our current location. We booked the flight, we waited in our location for 3 days, and we went on a 6 hours boat ride. All that just to discover that I made a mistake and I booked the flight for a month after.

There are reasons why that happened, but the end result is the same. We arrived at the airport with no flight and no local money (mistake number two).

So what did we learn?

Like with your code, before merging you're asking for a review. We did the same. For any booking (hotel, flight, bus, etc) the other person validated that all details are correct. You would be surprised how many small issues we found in each other's bookings over the trip.

Requirements change

When we planned our trip, we wanted to stay for 1 month in Thailand, and 1 month in the Philippines. Yet, during our stay in the south of Thailand, we discovered that the weather was too hot. My wife doesn't like the hot weather, and thus we looked for a cooler destination. After some discussions, we agreed to cut our visit short and have a 3rd destination on our trip. That's how we ended up in Vietnam!

So what did we learn?

Nothing is set in stone. What you originally appeared as a good match can be discovered as a bad match. Always be open to changes based on what the user needs. We could have said "we already planned everything" and stay to our original plan. Yet, but changing our plan we enabled ourselves a vacation that was a better fit for us.

Conclusion

Applying practices from the engineering world to our real-life problems can be very beneficial. Many of our problems have already been solved in a different context, and we can learn from those solutions for our needs.

Want to connect?

I’m happy to connect on Linkedin or Twitter. Feel free to approach me!

Credits

Top comments (0)