Nahuel Sanchez

A place to write down what I discover and learn everyday at my workplace. Front-end may be the main topic, but who knows, probably I'll be publishing something else.

Play spot the difference as part of your front end development process

I know that inside the front end development kingdom there are a lot of different sub species, different front end developers out there working in different stuff: a few more focused on the functionality closer to back end development, and some working on converting designs into code.

If you're a front end developer whose main task is to look at a PSD file and "make it happen" in code, then I can't stress hard enough how important is for the job that you achieve this successfully. And if you're thinking that this is obvious and there's no need for a post, trust me, it's still a common problem among developers... and it's hard to me to understand why.

What's the main task of a fire fighter? Extinguish a fire. What's the main task of a plane pilot? Fly the plane. Main task of a mother?... I have no idea, but my chips are on keeping the baby alive.

Jokes aside, what do you think is the main task of a a front end dev? Get a design, then implemented it as pixel perfect as it can be.

I saw this problem presented in a variety of seniorities, as it doesn't distinguish between Juniors and Seniors. Of course, the problematic is more present in lower seniorities, that's not surprise, but it still cause for rework in more experienced developers.

If "main task" seems like too much, as you probably thinking, just like I am, that a front end developers faces a lot of task during a day and it's hard to decide which one is the main one (again, related to the fact that your front end developer job description it's for sure different than the others), then just let's not get stuck in grammar.

It might not be your main task as a front end developer, but for sure is an obvious task, something that you should be already been achieving without anybody raising any doubt about it when you deliver.

So why aren't you? Or why you still have this problem in your team?

If it's your problem then awesome, today is a great day to start solving that. And if not your problem but something you see that happens within your team or company... then it's still your problem, sort of.

The most common excuses I heard about it is the lack of tools, or people using the wrong tools, to view and manipulate the designs.

"Oh, it looks different because I don't have Photoshop in my computer so I opened the document with other software that converts .psd files if you're using Linux."

That's not a good excuse and you know it.

We're missing a synchronization here between developers and people in higher position within the company when deciding on what tools to use. Are we going for Adobe Photoshop for the designs' team?, great, then let's make sure that we also have Adobe Photoshop in the developers' computers... and not Linux if we're going to deliver .psd files to them.

Here's another one, "We were on a hurry, so I couldn't spend time on making the implementation pixel perfect". I can only assume that the equivalent for that on a fire fighter would be something like "Oh, we were on a hurry, so we only extinguish the fire on the first floor".

That "explanation" is a symptom of a higher problem within the company that might deserves an individual post, but for the moment just stop the presses and evaluate if you're giving to the developer the necessary time to accomplish all the items included in yours definition of done. If not, then you're asking for the impossible.

On the other side, if you're the developer. Come on dev, stand your ground! Do not go for an impossible estimation knowing that you won't be able to deliver successfully. If the time frame won't allow you to go for a pixel perfect implementation, then speak up. If everybody is on board of what the outcome will be, then good, no surprises for nobody.

And finally, the Top 3 seems to be "I tested it on Chromium for Linux Mint and it looked exactly like the designs". Looks like a child of the first excuse, and still a bad one.

On the developer's side, ask for the specifics, ask what browsers you are supporting for that particular project, or ask for metrics from Google Analytics to know exactly what your final customers are using. And test, my friend, test it on more browsers (specially knowing that Chromium for Linux Mint can't have the final word).

If you're the company, or somebody with a technical seniority that have a say on technical decisions, then define what browser do you support and include them on your definition of done. Avoid having technical decision based on the personal believes of each developer on the team.

Spot the difference

Have you ever played that magazine or newspaper game where you have two almost identical images next to each other and the goal is to spot the 10 differences? Why don't you try the same game with your work before tagging it as done?

I've been on meetings where emotions are high, reviewing an implementation that clearly doesn't look like the designs, where the conversation last for less than a minute because all it takes from the person evaluating the job is to put the original design next to the developer implementation and ask "Does it look the same? Does it look like it is finished?".

And of course it doesn't. Just avoid that meeting by playing the game by yourself and prevents others from playing it for you with your work.

On a not much of a side note, I find the post "The Undefinition of "Done"" quite cool, so check it out as it might help with your development process.

The long standing cliche war between the sales team and the developers team

If you think this happens only on the company you work for, surprise surprise, this "war" appears in many software developer companies as I happen to discovered in a dev exchange session during a Magento Meetup.

So, what's the problem? It seems to be that the developers claim that the sales guys are selling too much, and sales shrug their shoulders and keep on selling because that's what they do.

For a start let's say for a fact that sometimes developers are way up to the eyes and can't handle either the amount of work they have or the delivery dates people up in the chain of command are expecting them to accomplish. I'm not whining about it, I'm saying it happens to me in several occasions and it's something companies acknowledge by time to time (therefore, a fact).

If you are a developer going through this, then of course you are going to complain when a new project arrives as "you simply don't have more time to do it and nobody seems to understand that".

Time passes and you, developer, contain your discomfort deep inside, only having as a escape pipe your rolling-eyes attitude when a new client is presented. That means that when you encourage yourself to talk about this problem, with the sales team, is already late: you're angry, the sales team is angry too because they know by talk around the water cooler that the developers are complaining, so the discussion is getting to nowhere.

Sorry to disappoint you, my fellow developer, but to keep the company open for business the sales guys must attract new clients. Sales gotta sales, and, on top of that, the company must remain competitive, which means that the estimates provided in the commercial proposals must be competitives.

Stand in the shoes of a client picking a company for his next project: you will look at the estimates written in the proposal from the different companies you're consulting before choosing one, in addition to take into consideration the quality their provide.

Finally, the sales team times are different than the ones experienced by the developers team. Pre sales can take months, so it's hard to predict right now how busy the developers are going to be in, let's say, 10 months from now.

If you put your dev problems aside for a second, the explanations coming from the sales team are understandable, so give the sales guys a break.

I can see that both sides are right but unwilling to listen to the other. Nobody talks to nobody, developers raise complaint among developers only, sales within sales, and the real problem is never faced.

Up to this point we must agree that developers happens to have too much on their plate, and sales must keep on selling because everything I just said, but nobody is going to quit doing what they're doing to solve "the problems from the other side", at least nobody is going to do just that literally.

Understand that it's not about your problems and their problems, but a problem we have as a whole team.

The first step toward a solution is to start seeing this as an integrated team between devs and sales, no separate teams. Otherwise, if you can't accomplish this, then become a freelance and sell your time by the hour, because whether you are a developer or sales you're only thinking about yourself and not seeing the big picture, missing an opportunity to be a better company and benefiting you, plus everybody in the process.

Start talking, and planning together, but don't wait until you're mad. And find common ground about the problems you are facing, because sometimes it's not about changing the reality you're living but more about facing it and accepting it. Everybody, devs and sales, acknowledging the same reality (the same reality being the key words in this sentence).

Not changing the reality but just accepting it? Here's an idea...

Wouldn't be better to work in a place where a salesperson sells "the impossible", but closes the door behind the client, turns to the developers and says "Look, this project's delivery dates are challenging, but it's a key client we had to win"? Wouldn't be better to work in a place where, after that, the developers team says "Okay, we both agree on the times for this new client to be very difficult, but since we both agree on that let's work this out internally"?

Resolve it indoors! Keep on selling, good job, then sit on the same table and plan altogether with the developers team how are you going to accomplish the deadlines. It's impossible to get it done in one month? What if two devs work on this instead of one as it was originally planned? Wait, does this augmented reality requirement must be on the go live or can it be postponed for the support phase? Work it out as a team!

When I say that it's not about changing the reality but accepting it I'm saying that as long as we agreed on the problem, as long as we stand on the same boat knowing what's going on inside the company, both devs and sales, there's an opportunity to fix what's going on.

And, if not, if you don't think this means fixing anything... at least you'll be working on a place where the "enemy" is not inside the same building, causing the working environment to be much better, less stressful for sure.

Magento virtual themes or why theme changes don't show up in the front end

You have a Magento 2 theme created (at least you can see it in your IDE and we're going to assume there's no typo in the theme.xml nor in the registration.php), you can also see it in the Admin, and finally you have it configured for your store.

Then you go to the front end and you see a Frankenstein's monster: the CSS is okay but the Layout XML is not being taken into consideration. The front end kind of knows which theme to load, but it's loading it only partially.

What it's going on? How do we fix it?

One of the possibilities is that the theme is set as Virtual instead of Physical in the database, causing behaviors such as the described above.

Magento 2 happen to have 3 types of themes, of which I have found very little information in the official documentation (just a minor mention in the Troubleshooting section of the 2.0 "Apply and configure a storefront theme" page but gone in the 2.2 version of it) but a convincing explanation in this StackExchange question.

We have "Physical themes" which are the well-known themes such as Blank and Luma, second we have "Virtual themes" which appears to be themes that extend a Physical theme but doesn't exist in the files (nothing in app/design), and finally we have the "Staging themes" which I have no idea what they are nor how they behave (sorry).

These 3 different types of themes are defined in the Interface Magento\Framework\View\Design\ThemeInterface as 0, 1, and 2 for Physical, Virtual and Staging, respectively.

If you go to your database (using the Terminal, PhpMyAdmin or an app like Sequel Pro) and take a look at the theme table, chances are that you'll find something like this:

If you encounter a 1 in the type column for your theme, there's your problem. Change it to 0 and everything will be fixed.

How the theme became Virtual without anybody setting it anywhere?

You're probably wondering how that 1 ended up there without anybody setting it (at least you're sure you didn't as you just find out about all this).

As described, Virtual themes are themes that doesn't exist in the code, meaning there are no files for that theme (how Magento expect us to use this type of theme is for me unknown).

If you're using a version control system such as Git maybe (maybe) you ended up for a moment in a branch without the theme files and somehow loaded the front end or ran a bin/magento command. For a moment only, Magento saw in the database that a theme is set and active but found no files in the code for such theme, so it changed it to Virtual.

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.