Naguel (Page 3)

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

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.

3 min read

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.

Work experiences

Suffering from the wannabe career plan syndrome

A career plan or career path (whatever you prefer to call it) is the way to have some motive to get up in the morning and go to the office. Without it we are just repeating each day in a loop without a long-term goal: get up, shower, go to the office, leave 8 hours later, eat, sleep, and redo.

4 min read

Is it money what motivates you to get up each morning? That's fine, but that won't work as a stimulus for ever. If you're good at your job you might be able to get money in another company, so that's not the problem here.

When you put money aside and you don't have a career plan... why are you going to work? At some point you'll realize that even by redoing the same day for the next 3 years nothing for you will be different. Isn't that sad?

Have you ever gone to one of those places where you can play arcade video games like Daytona USA? Do you remember that game or any other racing video game? You might recall that countdown on top of the screen that you have to beat, by crossing a checkpoint, before it reaches zero.

That whole concept of going through checkpoints is the career plan, is the reason why you keep your feet on the gas and try to get better on each turn. So, it goes 5, 4, 3, 2, 1 aaannnd checkpoint, and now focus again to get to the next checkpoint having in mind that the following turns must be perfect to avoid losing those precious seconds.

By now you can expect that I'm going to say that not having a career plan is a bad idea for both the company and the employee (I'm not a best-selling author, my way of writing is pretty much straight forward), but you know what's worse than not having a career plan?

Having a wannabe career plan

Designing a career plan is always hard for a company, specially during this era of acceleration where things change too much too fast. So, when trying to accomplish one, companies end up half way with a sort of a career plan that meets nobody's expectations.

A good way to spot a failing career plan is when it's all about fancy titles for the employees but with no well-defined task or responsibilities. For example, in my line of work you can start as Junior, then Semi Senior, Senior... let's assume then Technical Leader, maybe Technical Manager later, following Architect, and finally Developer Ninja Evangelist (I don't know).

Sounds great, and usually each promotion deserves popping a bottle of champagne as it's really a great accomplish. The problem appears when you start getting new job titles but your actual day to day job remains the same.

Yes, that happens a lot. You get your paycheck saying that you are the Manager of All Employees in the company, but you're still doing exactly the same job you were doing for the last five positions (checkpoints). After three promotions you'll wake up one morning and go "Waaaaait a minute".

At some point employees realize that the company is failing at providing a real career plan so this whole concept becomes an internal joke.

The solution is quite simple for the people inside a company with the responsibility to came up with a career plan: sit the duck down, give this task the priority it deserves, take note of your long-term plans, listen to the employees, and create it.

Not having one, or having an incomplete one, is doing more damage than you imagine: employees without motivation, a high turnover rate, low productivity numbers, a lot of complains in the office... good people leaving the company without even submitting to a negotiation process because money doesn't even matter anymore!

Really, non-existence career paths or wannabe career plans will kill a company from inside, and I can't stress that enough.

If your company experiences some of the symptom above, then again people inside your workplace with the responsibility to came up with a career plan should start working on this.

Who? Well, you're part of this task too

The company you're working for won't be able to come up with a career plan by itself, and for sure they can't download a career plan from the Internet. So is essential that you take part of the making of.

No matter your current position, you can identify that there's no career plan in your company and instead of whining you can contribute with what you see is next for the company but missing a role to accomplish it, or what you want to do inside the company but there's no role right now you can aim at.

At the same time, when talking about a promotion or your next role, demand the exact task and responsibilities you will be taking on, and also demand specificity about the tasks you won't be doing anymore (that you would be leaving behind for other to take care of).

If none of that is clear, if so the company is suffering from the wannabe career plan syndrome, then it's up to you to come up with what you want to do next. Come on, don't expect everything on a silver platter.

Having a career plan is good for you as an employee not only for all the motivational purposes I mentioned but also because it will help you to build your professional profile, help you to improve your hard and soft skills. Even if you already thought of not having your current job for the rest of your life, for sure you'll need to show your resume in the next job interview.

And it will look much better if it evidences a career.

Work experiences

Average is officially over, so don't be that at work

Average is officially over because it won't take you, your company, your team, anywhere. There was a time when you would learn a skill and that would be enough to succeed at work, but nowadays what you learn has an expire date as much as the milk in your refrigerator.

4 min read

Let me take a moment first to thank the "Send a free sample" Amazon functionality, because it's always hard to find a good book, but when it goes smooth by reading then you know you find your perfect match.

This is what's happening to me with "Thank You for Being Late" by Thomas L. Friedman, a book that talks about how things (technology, globalization, climate change, biodiversity, etcetera) are going super fast and how the society struggles to keep the pace, and it's like a how-to deal with everything that's going on today.

During Chapter 8, Friedman talks about how we are leaving the Holocene epoch for work. What's the Holocene? A "perfect Garden of Eden period when everything in nature was nicely in balance", as the author would describe it.

Basically, really really basically, following is "everything" that Friedman thinks about what's happening to work:

In those “glorious” decades after World War II [...] you could lead a decent lifestyle as an average worker [...]. And by just working an average of five days a week at an average of eight hours a day, you could buy a house, have an average of 2.0 kids, visit Disney World occasionally, save for an average retirement and sunset to life. So many things then were working in favor of the average worker.

[...] many workers in this labor Holocene enjoyed what was known as "a high-wage middle-skilled job" [...]. The high-wage, middle-skilled job has gone the way of Kodak film. In the age of accelerations, there is increasingly no such animal in the zoo anymore. There are still high-wage, high-skilled jobs. And there are still middle-wage, middle-skilled jobs. But there is no longer a high-wage, middle-skilled job. Average is officially over.

Now you know from where I took this post title.

Giving the extra mile?

There's no point on thinking about this concept at world scale, but instead try to apply what Friedman says to your workspace or personal work experience, either as an employee or employer, either as a Developer or a Technical Leader (if you don't mind me using terms I can relate to).

I remember that we had a money award at my previous job called "The extra mile" which worked as follow: everybody can nominate a coworker laying the reasons why we though he or she deserves the price based on that coworker performance for the last month, and then somebody from all the nominees gets the money.

Personally, I never quite understood why this award existed or why... how to... nominate somebody. Are we now supposed to reward people for just doing their job? Isn't that the salary what's for? But after reading this book now I get it, we're celebrating not average people! Which is terrible sad.

If you have a friend who is a Doctor then he or she can tell you about the end of the Holocene epoch concept. Your friend probably said that getting the Doctor title isn't enough nor the end of the journey, is a checkpoint not the end of the race, as Doctors need to keep on studying for the rest of their lives if they want to be "something". That now applies to all working areas.

Spoiler alert: there's no end of the race... well, probably there is, and it's called mediocrity. If you are average, please, don't ask for a raise, because you're putting an expiration date on yourself... your team, your company.

No politician in America will tell you this, but every boss will: You can’t just show up. You need a plan to succeed.

That was Friedman again.

Enough of abstract concepts, let's get (even more) real...

I'm a front end developer, do you work as a web developer or something similar? Then we can both remember a time where your resume can only include HTML and CSS, and that would give you any job. SASS was a nice to have, and a JavaScript framework a bonus point.

Now if you open LinkedIn the job offers will list Vue.js as mandatory. For a framework released 4 years ago now Recruiters ask for 2 years of experience, but 2 years ago was in no one's picture. That's a mind-blowing perfect example of how things became so fast so quickly!

What do you think is the JavaScript framework... or web development technology... you are not learning this year, but companies will require two years of experience starting next year?

On another topic, everybody is saying that 2019 is the year of Progressive Web Apps: there's a lot of post about it, a lot of talk about it in conferences, Vue Storefront exists for nearly a year, Magento is releasing PWA Studio in the following months... Are you doing PWA or at least do you have it on your roadmap? Or are you planning on pass on this year without touching it? If so, cross your fingers for your competitor to think alike.

Are you a designer? Are you still delivering static PSD files or are you doing animations already?

Remember that showing up at work is not enough, that's only average, you need a plan, you need to keep on moving.

I always liked to say during performance reviews or interviews that everybody has access to the same documentation, the same resources, tools, software, the same mentors inside a workspace, so the difference between good employees and bad employees, the difference between those who succeed, those who fail, and those who meh (averages) is the personality.

Anyway, I'm not saying that to excuse companies from responsibilities.

Celebrating not average is sad because it means that everybody but that one who won "The extra mile", including the whole company, will struggle in the near future. Are we all average but one?

Shouldn't we stop and rethink what we are doing, where are we going and how are we getting there?...well... stop and rethink... I know how ironic that sounds in this post about the era of acceleration.

Web development

Change Googlebot crawl rate

If you are thinking about controlling the crawl rate using the Crawl-delay directive on your robots.txt file, forget it, Google ignores that. You need to use what's remaining of the old Google Search Console

2 min read

As weird as it sounds it could happen that Google hits your site at a pace your server won't be able to handle, causing page speed issues and a potential site down related to a high CPU usage and too many MySQL connections.

Google claims to be smart enough to be able to self-regulate the crawl rate at which it hits a site (they said that they have "sophisticated algorithms to determine the optimal crawl speed for a site"), but that's not true all the time.

If you can contact your hosting provider, they might be able to tell you the number of requests the bots are making (where around 20000 in the last six hours could be enough to cause issues) and the logs for those calls.

185.93.229.3 - - [23/Sep/2021:05:32:55 +0000] "GET /about/ HTTP/1.0" 200 20702 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Make sure that the IP you are seeing on the logs are really from Google not being smart about the crawl rate, and not a DDoS attack in disguise.

If you are certain about Googlebot being the one causing the problems with your server, you need to adjust the crawl rate first, and then block Google, temporarily, while you wait for the new crawl rate to take effect.

Adjust the crawl rate using Google Search Console

If you are thinking about controlling the crawl rate using the Crawl-delay directive on your robots.txt file, forget it. Google ignores that.

You need to use what's remaining of the old Google Search Console, not the new fancy one, here https://www.google.com/webmasters/tools/settings.

Selecting the “Limit Google's maximum crawl rate“ option will display a slider for you to configure a lower crawl rate.

How low? I can't tell you exactly, since that would depend on your site and server capacity, but as reference I remember configuring it as follow for a Magento project living on a size XL AWS instance.

1 requests per second
1 seconds between requests

You can try something like that, or even lower, maybe at 0.5 requests per second.

Block Googlebot temporary for a few days

So, here's the catch: the new crawl rate setting is not immediately applied.

After saving the new crawl rate you'll get a message saying that "Your changes were successfully saved and will remain in effect until Sep 17, 2021" but it's not until you open up the confirmation email that you'll read that "within a day or two, Google crawlers will change crawling to the maximum rate that you set".

This means that your site will keep on getting hit at the same pace for a day or two, so the solution is to block Google for that period of time while you wait for the new crawl rate to get into effect.

Remember to lift the ban on Google after 2 days, and monitor for the following days that Google isn’t affecting the site performance again (so confirming the new crawl rate is working, otherwise you might need to bring it down a little more).

Work from home

Hiring a remote developer but as an actual team member

We all know in what we are thinking when talking about a remote position: sell/buy some hours, receive/assign some tasks, deliver/expect some code, repeat, whether you are the developer or the company... Well, it doesn't have to be that way.

4 min read

At some point on a developer career it's possible that we'll get an offer to work for a foreign company as a remote developer, with a contract, from our home, in maybe a different language. And as a company it's also possible that you'll be thinking on hiring some remote Senior developers.

As a front-end developer who worked as a Technical Leader in a local company, I was afraid to make the jump into a remote position because my main fear was to get stuck on coding only, without the possibility to bring something else to the table, just putting color on some buttons and nothing else for the next 5 years.

Well, it doesn't have to be that way, and thinking that a remote position it's only useful as the way I described before it's just lame thinking.

It's not simple, and it's up to the company

As a remote developer we can try to get out of the pre-formatted remote role model, but basically is up to the company we work for to give us the space to do so, to acknowledge the advantages of having us as one more team member and not as "the remote developer".

Companies usually set aside the remote developer from the development decisions (ironic, I know), despite the fact that sometimes that remote developer possesses a higher seniority than the local people, or more experience on the particular subject being discussed.

When a company turns to the idea of hiring a remote developer it's because they're searching for a Senior in terms of coding, because they have a tight deadline or the current projects they're having are becoming more complex day by day.

Your local team will need 3 weeks to finish a task so you hire a remote guy who'll get it done in 1 and allows you to remove pressure from the local team so then they can focus on something else... and repeat. Sounds familiar? It also sounds like a software factory, and that's fine if that's what you're aiming for, but don't expect team work on a software factory, don't grumble when you got stuck in quality, and don't blame the dev team when they not improve the delivery times.

For the same price you're missing somebody who can bring more, who can grow the team in terms of quality, delivery times, complexity of the tasks that can be carried out by the whole company, etcetera, just because... you're afraid?

Afraid of what?

You're afraid of giving full permissions to a guy you "don't know"? Are you afraid of giving decision power and all the company's credentials to somebody you've never seen before just because he can disappear from one day to the other?

I've seen local team members actually disappearing a day or two without notice, also people walking out of a meeting because of drama, developers working on a freelance project while being on working hours at the physical office.

Don't you have that kind of people at your office? If so don't give me that I've-never-met-the-guy excuse.

If the developer is going to be an asshole, it's going to be that either sitting on your office wearing a suit or in pajamas at home. If he's going to procrastinate, if he's going to spend 7 out of 8 hours in Facebook, he's going to do so either under your watch at the office or from the bed at home.

Come on, you're already know that, I'm just stating the facts.

I've seen developers on-site expending 90% of the day at YouTube, right in front of my nose, and I've seen spectacular remote Project Managers, Business Analyst, and developers, of whom I don't care if they are at YouTube or not because they deliver. Because I've trusted them.

I bet you can relate, I bet you already have some remote people who perform better than some local team member, so I also bet that you're starting to realize that this idea of not making the remote developers a real member of the team it's all just about unjustified fears.

But chat it's not the same?

Along with those fears stated above comes the "communication issues" also known as: just more excuses. Of course, it's not the same to have a face-to-face meeting than having to call somebody over Skype, but is it really that big of a deal?

I really don't stand this excuse, and I don't think we should spend too much time debunking it when we're living on a society where my +60 years old mom knows how to call me over WhatsApp, where my 20 years old sister knows how to share a video over Facebook while adding her own thoughts about it.

So, if 20 billions human beings can found a match on Tinder and potentially start a relationship or just have sex... I think we can overcome the "communication issues" when working on a Magento 1 to Magento 2 migration.

Turn on the camera and you'll see how all that remote things disappear. I'm being real, that helps a lot when you are trying to add the human factor to the communication process because it's not the same to say thing to a mic than to a face even when inside a monitor.

A developer sitting away at a 15 hours flight from your office can still give the same as the one sitting on your local branch. In this globalized world these excuses don't have a chance.

Front End

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

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

4 min read

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.

Work experiences

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 developers companies. 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.

4 min read

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

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

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?

2 min read

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 TablePlus) 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.

Cloudways

"kex_exchange_identification: read: Connection reset by peer" fix for Cloudways

There are great articles out there about solving this issue that requires you to edit some complicated files you never touched before on the server itself, but luckily, for those using Cloudways, the solutions is way more simpler.

1 min read

Basically, if you are seeing that message while trying to connect to a server, like over SSH, it means that your IP is banned.

First thing first, if you want to confirm this issue is really because you are banned, ask somebody else (or change how are you connecting to the Internet to get another IP) to cat the /etc/hosts.deny file inside the server.

If your IP is there, you can consider yourself banned.

To allow you back to the server, go to the "Security" tab inside the server configuration, within the Cloudways Dashboard, and whitelist your IP.

Make sure to "Save changes" after adding your IP.

Work experiences

Leave your stable job and stop being a coward

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.

3 min read

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.