Naguel

I'm Nahuel, and these are my work experiences, ideas and thoughts as a web developer working on the eCommerce industry.

How to become a web developer in a lot of not easy steps

How to become a web developer in a lot of not easy steps

I'm being ask that a lot! No, for real, I'm not saying that for the sake of a cliche moment in the post, but the problem is that the answer is not that short nor that simple, hence this article.

Decide what's your thing

While the idea behind this how-to question is kind of the same, the answer depends exactly on what kind of developer you would like to be, because the offer is extensive out there.

I'm a web developer, a Full Stack developer that works with eCommerce platforms, so there lays my expertise, but maybe you are looking to become an iOS developer, Java developer, a videogames creator, or something else.

Clearly, the first thing you need to do is to decide that.

Take into consideration that if you are planning on making a living out of this job you will need to like it, and second you will need to investigate the job prospects of that choice you are now making (I don't think COBOL is really wanted these days, considering it's a language from 1959, for example).

Not all developers are the same, and not all guys and gals you see with code on theirs computers are creating a program for a PC (which I tend to think it's the general assumption when I say I'm a "programmer").

Start with some courses

I have to be honest here and say that I'm not impress by courses when I see them on resumes, because them alone tell me nothing. But I will assume here that you have no experience as a developer whatsoever, and that you are starting from scratch, therefore is safe to say that while a lot of courses won't land you on a job position, it's for sure the way to start.

It's the starting line not the finish line.

Based on what you decided on the last section related to what kind of developer you would like to become, now you can filter out some of the courses available all over the world.

My suggestion here is to go local, meaning pick a course provider from your city or country because they tend to have partnerships in place with IT companies in a way you can ended up as a trainee there after completing a course.

Investigate that. Not only find a course you would like to follow and suits you, but try to do it on a place (school?) that IT companies then use to recruit from.

Play around, play a lot

Courses usually end up with a real project you would be uploading into GitHub or similar.

That's not enough. From my point of view, practice beats theory.

After the course you will be on your own. Yeah, I mean, you can start a new one, but as I said before I'm not impress by courses as I expect "real" practice.

This is when you need to start building up your portfolio, meaning a GitHub with small projects, practice code, snippets, something to show, something not just only to tell others you are more than theory but also for applying that theory into real stuff, for actually keep on learning.

Do not forget courses will provide you with the basics, and you won't become a Senior developer following courses. It will be up to you, and that's with practice.

The way it happened to me is that I had a WordPress blog (not this one, another one, ages ago), with a basic theme that I wanted to customize. So I started doing small changes, then wanted more complex ones, and one thing led to another. That's how I started.

Land a job no matter the salary

With courses on your resume and a portfolio to show is time to become real. Bye bye training wheels!

Unfortunately, this is not easy, not because of the opportunities out there that I think are plenty on the IT sector, but because you will need to escape your comfort zone.

If you are reading this you might as well have a stable job already and this idea of becoming a developer is a plan for the short term future, so at some point, with courses already finished and code already uploaded into GitHub, you will need to decide how much salary you will be willing to let go in order to start on the business.

A trainee position won't pay much. Actually, if it pays at all that's a win already, but you need to start somewhere. For example, you can be a lawyer now and there's no chance your first job as a developer will match your current income. Accept that.

Take your first opportunity on the real world as a way to learn how a company operates for real, how working on a real project looks like. This is your chance to learn the real stuff.

Your first job might be a sacrifice in terms of money, but after this, with one job experience in your resume, the opportunities will increase exponentially.

I know, it's scary, but come on, you first job won't be a Senior position. Get real, face it, it will be worth it.

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

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.

A blank Ghost blog theme for development

A blank Ghost blog theme for development

This blogs runs on the Ghost platform built with Node.js, with a homemade theme that uses Handlebars, HTML, CSS and JavaScript, and if you are reading this article chances are that you're already a Ghost blog owner and that you're looking to develop your own theme.

The problem with the Ghost default theme named Casper, while it's extremely helpful to learn how to develop a custom Ghost theme, is that it is too complex or "it has too many things" you probably don't want for your blog.

For example, when creating the theme for this blog, I had to "deconstruct" Casper to start building on top of the ashes because I wanted a more simple theme, that has my own code wrote the way I wanted it.

Introducing the Pale Ghost blank theme

The Pale Ghost theme is a blank theme, developer ready, focused on the markup without styles, that already includes all the Ghost features for you to customize or remove in order to create your own theme.

I already searched for Ghost blank themes, and truth be told there are many out there, but none suits my desires. All the blank themes I encounter has too much JavaScript, or they are too much complex to the point they looses they purpose of being a blank theme.

This blank theme in particular is very simple, so you might be spending time in the styling part with CSS/SASS/LESS rather than working on the markup. And if you want to move stuff around, you'll find it's easy with the Pale Ghost theme as it is well deconstructed into different .hbs files for an easy development.

It also includes everything a Ghost theme can deliver, just as Casper, but with a simple implementation. The goal with this theme is to avoid the part where we as developers smack things down before actually building up.

For a more technical description of what this blank theme includes you can check the Pale Ghost theme's GitHub page.

Downloading...

You can download this blank Ghost theme from the Pale Ghost theme's GitHub page, where you'll find the "Releases" section.

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

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.

Understanding the product's name front end logic in VTEX

Understanding the product's name front end logic in VTEX

Is VTEX showing the name from the Product in the Admin? Or is it showing the name we entered in the SKU? Or is it showing both?... or why sometimes it seems like VTEX is using the Product name and in other occasions it is using the SKU name?

In other words, what's the name I'm going to see in the front end of my VTEX store when creating a new product?

I'm writing this down because I found there's always a confusion about what is VTEX showing as a name for a product when looking at it in the front end (like in a category or product's page) considering there's a tricky logic there that involves the Product entity and the SKU.

Product entity name and SKU name?

To avoid any misunderstanding, let's discuss first what I mean by "Product entity name" and what I'm talking about when referring to the "SKU name".

When I say "product's name" we all think about a product as a whole, the item itself and the name that item has. But a product in VTEX is divided into two thing: The Product (or the Product entity) and the SKUs included on that Product.

I know I might sound philosophical and delusional but just take a look at this screenshot so I explain myself better.

understanding-the-products-name-front-end-logic-in-vtex-01-1

Is our site showing the name from the first column or from the second one?

Which one is going to appear on the front end of the VTEX store?

It just depends on this simple logic you need to consider.

If the Product entity name is exactly the same as the SKU name, then VTEX will show only one. Take a look at the screenshot above where the names in both columns are identical, meaning the front end will only show "iPhone X 64GB Silver".

On the other hand, if the name in the Product is different from the name in the SKU, then VTEX will show the two names separated by a dash (-).

For example, if for the Product we have "iPhone X 64GB" and for the SKU we have just "Silver", then the result on the front end it is going to be "iPhone X 64GB - Silver". That simple.

understanding-the-products-name-front-end-logic-in-vtex-02

Knowing that, if you're facing the "problem" in VTEX with the front end showing the names "duplicated" or if you didn't understand from where that final name is coming... now you know.

Keeping both the Product and SKU with the exacly same text (not even a difference in the capital letters) will show only one name, no dash.