Nahuel Sanchez

A place to write down what I discover everyday as a developer. Code and that may be the main topic, but probably I'll be publishing something else too.

You're looking at all the posts published under the tag Work experience.
← Go back to the front page

Leave your stable job and stop being a coward

I worked on the same place for almost 6 years until one day I quit.

That statement, while true, is extremely simplistic and it's not like I woke up one morning and said "Today is the day I move forward", but instead took me a lot of thinking and time (more than a year) until I reached that decision.

What took me so long? Mainly lack of bravery. Chances are that if you are reading this post you're a coward too, but that's okay, it can be our secret, and you shouldn't be ashamed of that. My cowardice is known as "being too much time in the comfort zone" by other posts you might find on the Internet, but I don't want to be that polite and instead call stuff by its names.

My lack of bravery grew over the time fed by the fact that my job was secured in this place after 6 years. I'm not saying that I was irreplaceable, but after 6 years it's not like somebody were going to fire me overnight.

Also, routine mixed with flexibility. I knew I had a job from Monday to Friday, a secured job, something to do within a company with many clients, and on the other side if I wanted to slept 2 more hours I could do that and there was no problem because they knew how I was and that I was going to work towards objectives (meaning me sleeping two more hours in the morning won't jeopardize any project). You know, comfort zone.

Something started to bother me, and it was the fact that inside me I knew that my performance could be better. My work done could be delivered with a higher quality and especially in less time, and I could be learning something different, new, or a different way to accomplish my job description's objectives.

I was somehow stuck, and I wanted to know how the work can be done from a different perspective, under a different pair of eyes. Like the "I want a second opinion" phrase in the medicine world.

It's a sentiment hard to put on words, that you're probably feeling too, that I compare to the need of leaving your parents' house to live by yourself.

If one day you make the step, you're in for a smoothie of feelings starting from "What the hell am I doing?" to somehow relief, peace, panic, adrenaline for sure, happiness. If things goes well (it can fail, I mean, sorry, but this is not quite an inspirational post... things can go terribly wrong so think twice, haha) you'll find yourself smiling on the back of your Uber ride while looking over the window (with a stupid face in my case).

As I don't want this to be a motivational post, and as I don't want to sound like I'm saying "leave your work, leave everything behind and pursue your dreams because life", let me pitch in some disclaimer points here.

We need to know that jobs are not like yogurt and they don't have an expiration date based entirely on time. If you happen to be on a job for 3 years, 5 years, or whatever, don't quit just because you believe that you're being too much time in the same place.

I don't believe in the feeling that a cycle is completed based only on the time you spent on that cycle. There are more than years spent on the same chair, so if you're happy where you are just keep going and that's just okay.

Consider also that being mad is not a reason to quit. If you're mad, and you quit just because of that, chances are that you are, at least, to blind to think this through, to contemplate all the possibilities and choose wisely.

I once saw somebody saying "I quit" right in the spot of a performance review, not even letting the performance review finish, not even giving an hour to think about the big decision of leaving a job. Of course, that was just words and total regrets the following day, but still works as an example.

Mad? Make peace with yourself and with the company you're working on before taking a decision. Stop thinking of companies as "big evil corporations", and you'll probably find (as I did) that the company you work for is given everything they can, so allow them some mistakes.

If you are getting fearless and thinking about leaving your stable job, do it for the right reasons.

I'm hoping this personal post, my personal experiences that most likely is totally different to what you're going through, helps you think more deeply about the current situation you're living with your current job.

Do not forget about the emotions while selling something

I'm selling two iPhone X, Space Gray color, both with 256 GB of capacity. When I bought them I wasn't sure about getting the 64 GB version or the bigger one, but I made up my mind in favor of the 256 GB version and I'll tell you why it was a great decision.

Last year I went on a family trip with my mom and sister to a Brazilian beach where cellular signal wasn't available all the time, meaning LTE was a luxury, and also finding WiFi was a Tom Cruise's "Mission Impossible" remake possible plot.

In this scenario, the idea of today's about everything being in the cloud and not in the physical devices was a no go for me.

The trip was beyond great. I spent a lot of time in the water with my sister trying to record the best slow motion videos: sometimes trying with just the water, sometimes filming the sand to see if that improves the video, then letting my sister try some tricks in front of the iPhone camera over and over again until we get something good.

At the end of the day we ended up with many many GB of videos, and a job not done yet. Before dinner, all nights, and most of the times waiting for our mom to get ready, we selected the best shots in order to create a video, cinematic music included, to show to mom as if we were two Directors showing the final cut of a Hollywood movie to a film criticism.

The other phone, while exactly the same, it was just used for some work stuff. It's a great device for reading emails, writing emails, and taking notes.

The difference lies in the emotions

While both are the same technical speaking, they are not the same emotionally speaking. If I still need to prove my point I'll will continue telling you fake stories including a beach, a mom and a sister until your eyes get wet and you rip this phone out of my hand while letting me keep the one used for work... because that's the whole point.

I know it's very obvious I'm appealing to your emotions in the last story, but the true is that we're all victims of this trick in a regular basis.

Think about it. Think about the last time you bough something on Amazon, eBay or Mercado Libre, when you searched for a product you already knew, ended up with three or four browser tabs with similar publications of the same product, different price within a short range, and then you made a decision from where to buy based on not much logical data but confidence on the seller, the aspect of the website, the fact that one had a better description with a video of real people using the product, the fact that one had reviews from previous buyers.

Think in Coke showing a couple jumping of a cliff into a lake, McDonald's showing a single mom with his kid laughing while eating fries, a perfume showing a good looking guy with three Victoria's Secret angels.

I remember a local ad I often see on TV showing a divided screen where on the left you can see a cute lady getting ready to go out on a sunny day, and on the other side a big man wearing a hood and preparing his tools to break into the house of this lady the moment she step out. There you have the victim, the villain, the conflict... and the hero? A trustworthy armored door at an accessible price.

And Apple?, oh, boy, those guys really know everything about selling feelings instead of products. I remember during an Apple's Keynote somebody, probably Tim Cook, introduced "Live Photos" (you know, that feature that records a few seconds before and after an static photo) and said something like "This feature allows you to see a photo, gently press on the screen, and get a sneak peak of what was going on during the shot of that static image".

A time machine that shows you 3 seconds of video and audio around the static shot. Right in the feels.

What you're selling is a hero

Your product, service, software... whatever is the thing you're selling, it can be the hero of a story. A story where there's a problem your potential customer has.

The problem is the villain in the story you need to start telling. It can be pretty obvious like in the ad for the armored door, or very subtle like in the McDonald's ad where they tell that they know how hard it is to being a single mom but still you can come upon great moments with your son in their stores.

Spot the villain, disclose the problematic, then introduce the hero to your customer so they lived happily ever after.

How a VTEX developer looks like from a technical point of view

If you happen to be on a similar position as I am where one of my task is to conduct interviews and vote on someone getting hire or not, you also have to be able to establish if that person can work with a specific platform.

It is not the same working on a VTEX store, an ORO implementation, or in a Magento project. For each platform you have to have a specific set of skills, and again, depending on the platform, more experience on some specific skills are necessary and the seniority on a specific ability vary when you change the CMS you are messing with.

VTEX requires a front end developer with a signed certification from his mother saying that he's great with those "Find the n differences" puzzles you get on the Sunday's newspaper, because the primary task he'll face is to transform a given design into "code", as pixel perfect as it can be.

So, how it looks like now?

Translated to actual skills, for a start it means we're looking for someone very good at xHTML, CSS (and/or any CSS preprocessor like SASS or LESS), that can also handle simple JavaScript logic or jQuery for basic UX interactions.

Bear with me if you not agree on that "simple JavaScript logic" statement, because there's a reason why I said "for a start". With this specific developer you are kicking off the team you need for a VTEX implementation but you are not finish yet.

Based on my experience, someone with the ability to handle the layout will cover a high percentage of what the project needs. Seriously, even on highly custom VTEX projects always the largest amount of workload falls on the person who handles the implementation of the designs and that's why is very important to have someone who nails this task.

The next step is to choose between two options: we either look harder for a person with the mentioned skills that can also handle the logical part of a development, or we get another team member for this job only.

If we go for the first option, now finding the developer became a little bit more complicating.

I think that considering a lot of front end developers, on one end we have the "developer who handles the layout and leaves the logic to back end" and in the other side the "kind of full stack developer hungry for programming but with no love for the look and feel".

Our first option requires us to find someone in between, and that's hard (talking, again, from my work experience). Personally I'll go for this option, because, personally, I feel more comfortable with those "in between" developers. But that's just me.

The second option is more suitable when looking at this from a company level where you have multiple VTEX implementations.

Imagine an scenario where you have three VTEX projects ongoing, each with a person assigned full time implementing the layout only, and a fourth developer jumping from VTEX 1, to VTEX 2 and VTEX 3 working on the customizations only, while leaving the "make this as the designs indicate" to the full time assigned coworker.

The person in this second option needs to know JavaScript for real, because all VTEX front end custom stuff always falls on the need of use of JavaScript.

The developer, sort of acting as a back end developer in this platform (in a manner of speaking) will be dealing with the logical part of the implementation like struggling with the APIs and integrating with VTEX's Master Data.

But how it will look like in the future?

The platform is evolving constantly and it is on its peak on what updating the technology stack refers. This means that what I just said above still applies, but we need to consider what is coming.

In the not so distant future the idea of VTEX IO as the VTEX's web application development platform is that custom (and useful) customization that takes places on a specific VTEX store become an App, in a sort of plug and play plugin for that specific store and others.

For example, let's say you have to development something to get the users' email using a form in order to subscribe them to the newsletter configured using MailChimp. Do it once, make it an App, and reuse it on the future or sell it to other existing stores seeking for the same functionality.

In this new world, besides the fact that you need a little bit of npm and the use of a Terminal to set up your workspace, you'll definitely need to know React and GraphQL in order to build the application.

So don't get sleepy.

Developer's work success being too much about personality rather than hard skills

When giving a performance's reviews, one idea I used to pitch to somebody with the potential to be an even better developer in the future is that we all have the same tools in the company to improve ourselves.

Everybody has access to the same documentation, to the same in-house training programs, to the same software, to everybody's code, to basically the same people to ask questions and to learn from... and what's set the difference between someone progressing in his or her line of work and someone stuck is the personality each developer has.

This is something that bothers me in the sense that it makes me feel I'm losing control of any recruiting process I might been part of, or any "technical coaching" I'm giving.

Because while it might sounds as a "motivational speech" during the performance's review, let's do not lose sight of the timeline here. If we get to that point saying is more about personality than hard skills, then it was also more about personality a few months ago during the interview process.

What if interviews are all about luck and not about us evaluating correctly the hard skills of a candidate?

Sometimes it feels like it doesn't matter if I really really prepare for an interview, or if I improve my tricks to get to really really know the candidate's hard skills, because it feels like it all goes down to about how lucky we are as a company when we take our chances with a candidate by saying "Yes, come work with us". Does it happens to you?

I remember joking about this issue by proposing something like open the company's door, let 20 candidates join us, and we'll see how they perform during a month... and by the end lets "fire all the personalities" that didn't succeed.

Let's not waste more time with interviews and technical exercises! Everybody is welcome for a month, and we'll decide later who can stay.

Yep, that would be a fun disaster to watch. But again, this is sometimes what I'm experiencing with the whole recruiting process, and also I stand corrected by saying it's not really a feeling but an actual fact because we truly accepted people with serious doubts about their hard skills that in a short time became great developers, and we also let in promising ninja developers that resulted in a total fiasco.

So, what's the next step?

I don't know.

I'm struggling with this problem and this is more of a sharing my concerns post than a post with an outstanding solution at the end. But let's do some brainstorming in order to get some action items to work on later.

Probably the first idea is that we suck at interviewing because we don't have the skills or the tools to really get to know the candidate's hard skills pass the personality and what that person is selling during the interview.

We should improve the exercises we're giving, enhance the questions we're asking, and have a clear understanding of which hard skills we are looking for and to what degree of knowledge we're aiming for those identified skills.

Before that face to face technical interview, it seems like it's necessary to improve the first informal interview to rule out the personalities we do not want. Because, don't get me wrong, we do want people objective-oriented and willing to learn everything... but that's not the only things we want to depend from.

So, it seems like this last thing is more mandatory not to solve our main problem here but to avoid a different one.

When the process fails again (meaning when we bet for a candidate and things goes wrong again) we should be doing an analysis of what happened and we should be having metrics about failing and succeeding process in order to identify what's working and what's not.

The goal here is not to all say "Oh, we fail again, let's try again one more time" but more about getting the reasons behind the process that didn't go as expected, and getting hints about how to make it better.

I still do not know for sure how to solve this, but I get myself some ideas to sleep on it and I hope you too.

About how hard it is to find a front end developer capable of work with Magento

Is it hard to find someone willing (and able?) to work with Magento. And I'm not talking about finding an already "senior" Magento front end developer with n years of experience with that eCommerce platform and/or working in that specific field.

No. What I mean is that it is difficult to find someone who is already a front end developer but never worked with Magento. Will he be able to? Will he understand and like the platform? Is he willing to despite what he says during the interview?

I already write a post about how to interview a front end developer, and I'm not sure if I strengthened enough the idea of it being a kind of a bet. In this scenario we're betting twice as we not only need to discover if the person being interviewed possesses the skills to be a good developer but also if he or she can perform with a specific platform.

That fuzzy line between back end and front end within Magento

I encountered a lot of different "profiles" while interviewing. While the spectrum is really broad let me summarize this into two groups (nevertheless, not sure about the names I'm giving to them, but bear with me):

  • Web designers, or people focused only on the HTML and CSS (maybe jQuery?) part of the coding process. People whose main task is to convert a given PSD file into "a web".
  • Developers using the "hard tools" for coding complex logical solutions with, and not limited to, JavaScript and all its modern flavours.

The first group is excellent in that PSD to xHTML conversion process but they sort of depend on somebody to add the functionality to their creations, and the later group fails when the QA team compares what they delivered with the original design files.

So, someone in between, right? Right. But why?, because of that fuzzy line between back end and front end within Magento. :)

It depends on how the company you work for is structurated, and how the roles for back end and front end are implemented there, but under my experience I can tell that none of these groups that represents the two extremes of the wide range of developers I interview can work with Magento, or at least they can't on their own as they will always lack what the other groups knows... and we need both on the front end side of a Magento project for it to go live.

Again, under my experience, while working with people that falls into this two categories I either faced the problem of things looking good but not working as expected, or things that do what they're are supposed to do but with so many differences when I open the designs (and if you are thinking "it's only colors", think responsive web design).

How we find that "in between"?

Spoiler alert: I don't know for sure, but I can tell you what I'm doing right now and hopefully it will help you achieve the same as I'm looking for if you're conduction interviews.

I recently had a meeting with somebody from the recruiting team at the company I work for in order to polish the "mechanism" to identify people too attached to the mentioned groups in order to dismiss them at the beginning of the process, and there are a lot of hints in the candidate's CV that you can use.

Exhibit A is this imaginary resume that includes skills such as HTML, CSS, SASS and jQuery, which is excellent because we need those skills. Following we find a lot of background experience building corporate websites only, but never using a CMS as there is no mention for WordPress, Joomla, Drupal, or similar.

Finally, the work experience is a mix of marketing and design, mostly a transition from the later to a developer. The court rules guilty for being too much of a member of the web designers group.

A second example is this also imaginary resume that includes all the fancy words I already used to, such as Angular, AngularJS, React, VUE, Node... you name it... and a background experience that mostly includes working on the back end side of some sites.

I don't have to tell you to which group this imaginary candidate belongs to.

So, again, someone in between. Find that resume that have a mix of the trending topic's keywords for the first and second group, and you got yourself a feasible Magento front end developer. Or work the other way around: burn the resumes that falls into the extremes and what lays in the middle is the people you should interview next.

No group is better than the other

Don't get me wrong... or let me clarify.

I do not think one group is better than the other one, and if you belong to the first one there's no obligation to learn what the other group knows, neither the other way around.

Let me put another short perspective into this: if the company you work for (or the company you applied for, or your company if you happens to have one) really separates this two groups into really two separates job positions, and if you only have to worry about the PSD to xHTML thing because somebody else is handling the functionality... good for you, and go for it, as again this depends on the scenario you're standing.

That's why I mentioned something about the way a company is structured before, because in some places you might not need to worry about the "in between" as it doesn't apply.

Happy hunting.