Forem: Nicolás J. Engler

From development and into product management, yet another tale

Nicolás J. Engler — Mon, 28 Mar 2022 02:22:39 +0000

It is a rather common path for developers, no matter what branch they're located in, to go from development to technical leadership, and eventually –sometimes– into management. As I've already stated frequently in the past, my career path has been traversed mostly solo, not in the sense of freelancing on my own but rather in the sense of never having a clear mentor to guide me through the muddy waters of the tech industry, an industry I decided to become a part of more than 10 years ago.

When I first started as a developer, considering that moment to be after having my first real freelancing gig, my boyfriend and mentor passed away, and ever since I've been doing my best to absorb the experience of others to understand what is the best way to conduct myself in whichever role I'm currently situated. My experience with an in-house role was fairly limited and lasted only about 6 months when I moved to Buenos Aires, but every instance before and after my attempt at working in a "traditional" physical office were done from a small town, giving me zero access to a face-to-face dev community, and thus limiting me to, again, getting all my knowledge and third-party experiences only from the wonderous world of the Internet.

I always considered myself to have a keen eye for organization and attention to detail, which gave me a great advantage not only when it came to translating designs into HTML and CSS, but also to organize my work without too much hardship. Kanban boards, ToDo lists, excerpts for clients, Gantt charts, they were never really something strange to me, and they indeed came super handy when first starting freelance jobs. This is a quality I assume naturally helped me take somewhat of a management role while developing the sites or apps I was working on, no matter if independently or as part of a team. When collaborating with a group, most project managers were thankful of this capacity, which is why I decided to value it and kept on nourishing it.

Even if organizing the tasks in the project isn't your main responsibility, helping your team have a clear vision of the current status and next steps is always desired. Same goes for proposals for features and approaches to solving different problems, for example.

As my responsibilities naturally grew when I kept on expanding my skillset as a developer, I eventually started freelancing for WayTooDigital, and I induce that my contractor, Agustín, found the capacity of a developer to be able manage a team from a technical standpoint valuable, since he offered me to join in a somewhat more solid manner soon after a couple of projects. Accepting was one of the best decisions I've ever made, as it opened up the possibility to get my hands dirty directly with clients and the product design process altogether, and this was mostly enabled by Agustín's trust that I was up for the task from beginning to end.

Meanwhile, I kept getting more involved in the lifecycle of a product and I was able to add my, and my team's, own touch to the ideation and execution of each project, allowing us to grow both in the management department and in the latest technologies used for different types of requirements. Navigating this stage while trying to excel in both engineering and the arrangements of instructions to get a product to life is incredibly challenging, and this is where I had to make a decision on which front I wanted to be the most involved in. I eventually decided that my interest leaned towards management and this is where I steered into properly organizing what I needed on my end to provide my team with the best tools and processes for them to work and focus on their expertise areas. I was rather inexperienced in this front, so I ran through a list of what I was able to grasp were the areas that successful product managers focused on:

Helping the team in a "cross-functional" approach, considering each step of the way as a key part of a whole so they can collaborate holistically
Accompanying designers and developers in depth when reviewing feature proposals or deliveries to properly prioritize and stage releases
Helping clients, product owners and stakeholders understand already set realistic roadmaps with input from all parts of the team

As I kept on getting deeper and deeper into this, I struggled to keep up with the requirements I considered were needed for my team to be successful, especially having a hard time with Proof of Worth and impostor syndrome on my end. Shreyas Doshi helped me a great bunch with this when I read the following Twitter thread:

Proof of Worth, a gentle product management rant:

When an early-career PM starts on a team, they might be told that they must build credibility with the builders (eng, design, analytics…)

They must prove their worth.

Fine advice, but it can go wrong long-term.

1/11
— Shreyas Doshi (@shreyas) May 30, 2020

I know I'm cutting this short, and there isn't exactly a conclusion to this entry, as this role for me is still an active living and breathing ongoing process, but I thought that sharing how it went so far might help other people in the same place as me, who might not exactly have a mentor or someone to lean on to explore an unconventional road to an already established role in the industry.

Best of luck to all new managers out there! It's a wild wild world, but we got what it takes to make the best of it.

My typical day

Nicolás J. Engler — Sun, 14 Feb 2021 12:56:52 +0000

This post was somewhat influenced by Michelle Barker’s post, which in turn was encouraged by Colin Devroe.

Routine is good for me as long as I can keep a straight score, but as soon as something ruptures those habits everything falls into chaos, which is why the last couple of years (and I mean that literally, it must be around 2 years or a little bit less) that I ended up finding a system that works for me and has a decent amount of structure but still is flexible enough to allow interruptions without throwing everything into disarray.

Because of everything I’ve written in the previous paragraph I won’t be using hours but rather chunks of the day to describe what I do daily:

Early morning: I wake up, do my skin care routine, and prepare some quick breakfast (it usually is a banana smoothie with strawberries or blueberries, peanut butter and honey. It can also be eggs, toasts and coffee). Once breakfast is ready I head over to my desk -lately that means the living room table of my apartment- to either read emails or organize the day. If there are bills to pay or I need to settle something, this is the moment where I try to be as productive as possible: concise answers, resolutive approaches.

Mid-morning: Once those early morning tasks are done, I start by prioritizing what part of my work needs to be done with more urgency. Said work can either be bug fixing, feature work or documentation (depends on the client I’m working for at the moment). Some days are harder than others when it comes to having the drive to get to business, which is why I’ve been setting goals as a way to fuel my motivation. So far it’s been working good enough. At this time, if I get hungry this is the moment where I’d grab some cookies, yogurt or an apple.

Middle of the day: Munch munch, crunch crunch. This is where I take a little time to, only lately, prepare a home-cooked meal with my boyfriend and sit and watch a short YouTube video while we have lunch together.

Early afternoon: Where my energy is at its lowest, which I why I use this time to answer Slack messages, set up calls, and check for new emails. I try to keep all activities that don’t require much focus in this timespan so I don’t, for example, code mindlessly.

Late afternoon: Sometimes this means 6pm, other times this means 1am. It all depends on the task I’ve been working on, how much I procrastinated or how complex it is. I been trying to keep it to 7pm at maximum, and that’s mainly because I head to the gym at the end of the day to catch a quick 50-minutes crossfit lesson (or an acting lesson if it is Tuesday) and be back home by 8 or 9pm. Once back home I take a shower, cook something with my boyfriend and our roommate, watch a TV show episode (lately that is Ryan Murphy’s “Pose”, but a couple of weeks ago it was Attack On Titan so we could catch up to the fourth season), and if possible be in bed by midnight. I used to read a decent amount a couple of years ago and I’ve been trying to get back to that but I have to admit I’ve been failing miserably (which is sad because with the whole Twilight Renaissance the internet has seen lately I would very much like to read the entirety of Midnight Sun).

Aaand that is a typical day for me. I obviously switch it up whenever something new comes up, like having to babysit my nephew (I became an uncle like 4 months ago, yay!) or go to a doctor’s appointment, but the overall succession of events looks like the list above.

Looking forward to read your typical days!

How to fix unexpected gaps when printing flex-based elements in Safari

Nicolás J. Engler — Wed, 10 Feb 2021 15:10:35 +0000

TL;DR: if possible, switch all your Flexbox containers for block-level elements. Changing display: flex for display: block should do the trick as long as you don’t mind stacked content when printing (otherwise you’ll need to tinker around to rearrange your print layout)

I’ve been working for a client for almost 3 years now, his project involves students and teachers that usually require printing guides to use whenever they don’t have an internet connection to use on their devices.

The platform uses different modular types of content (some of that is video along text, other are images in a grid, and other components are just plain text), which is why whenever building the print styles I decided to remove any extra whitespace along with background images, plain images, iframes etcetera. When testing said print styles, everything seemed in order in major browsers like Chrome, Firefox and Edge, but Safari, for some reason, included weird large gaps in between paragraphs and/or titles and content.

Theory 1: hidden images, iframes and grids were causing these gaps. Seemed unlikely given those elements all had the display property value set to none. After checking out these elements in the devtools, manually removing them from the DOM and printing a PDF, it was obvious this wasn’t the solution.

Theory 2: CSS page breaks needed to be set in order to get this page printing properly. After setting up page-break-before, page-break-after and page-break-inside property values wherever the issues arised, I tried to print a PDF using Safari but none of these changes gave me the expected results.

Theory 3: Similar to what happens with some older JavaScript plugins when combined with Flexbox, there might be sizing issues when printing, causing large computed numbers for widths or heights. After switching all my display properties to use a block value rather than flex, everything showed up as it should in the generated print PDF file using Safari.

I was lucky enough that the print layout for this use case was simple, and stacked content was the inteded result. If you need to print layouts that are a bit more complex, you are most likely going to have to dedicate some time to rearrange your components so they play nicely.

I can still see it: a case for graceful degradation

Nicolás J. Engler — Wed, 13 Jan 2021 22:57:27 +0000

There are plenty of pieces written about how we should strive for progressive enhancement and leave graceful degradation behind, and I understand the case for that given how the current front-end development ecosystem works, and the status of the tools we're currently given to work on a day-to-day basis.

One of the main reasons I'm so uncomfortable working with junior developers is that they are at a loss when you start explaining to them how package managers work, since we're no longer toying with just HTML, CSS and JavaScript files. Third-party dependencies are often needed for progressive enhancement to be achieved. Juniors are unaware of what Node.js and npm are, how to get them (don't even get me started on the differences between OSes), how to use them on their project. The learning curve is steep and progressive enhancement requires fully-fledged scripts that understand the bells and whistles of a product, or an entire dependency that takes care of that.

It's understandable for larger companies or larger teams to have the time to train their juniors to apply this approach, or have a dedicated developer working on it, but for smaller team it is additional pressure on deadlines and there's an awful lot of guilt-tripping from peers when you decide to go for graceful degradation rather than take the time to progressively enhance a feature or product.

If we head over to the W3 Wiki on Graceful Degradation vs Progressive Enhancement:

Your product by definition is so dependent on scripting that it makes more sense to maintain a “basic” version rather than enhancing one (Maps, email clients, feed readers)

That's how it works for smaller teams. I realized this while talking to a client that needed to ship ASAP in order to meet a hard deadline. The case was the following:

Have an accordion that is able to expand and contract on click
Have it be fully accessible, critical importance on keyboard accesibility and semantics
Make it readable even in older browsers

I had a tough time balancing my options: create a small script from scratch to make this happen, include an external library, OR use a native HTML element that degrades gracefully and is fully readable in unsupported browsers.

Enter HTML details

After some discussion of time vs. maintainability, accesibility, and other factors, the client decided that it was best to go for the native details element, fully supported in the latest version of most browsers, almost-entirely customizable, and gracefully degrading to a list on older browsers. This was the perfect solution when considering our timeframe and feature requirement. Check out this pen on CodePen that I worked on and helped me decide what approach to pick.

The bare HTML end result looks something like this:

  <details class="warning">
    <summary>Facts and knowledge about COVID-19</summary>
    <p>Some text to be hidden.</p> 
  </details>

  <details class="info" open>
    <summary>For the public</summary>
    <p>Social distance, quarantine and isolation</p>
    <p>Hand hygiene, cough etiquette, cleaning and laundry</p>
    <p>When children have acute respiratory tract infections</p>
    <p>Risk groups and their relatives</p>
  </details>

  <details class="alert">
    <summary>Facts and knowledge about COVID-19</summary>
    <p>Some text to be hidden.</p> 
  </details>

Pretty straightforward, right? You can wrap around that snippet in a tag of your choice to put it in a specific predefined context that's semantic, and both details and summary elements are customizable via CSS without much complexity.

The W3 Wiki is pretty biased towards Progressive Enhancement, but cases like this introduce a simple question: is it worth overengineering something that requires a minimal investment of time and LITERALLY zero effort to maintain?

Lea Verou wrote an article that isn't entirely related to this, but presents another question that is worth asking: do we need to keep overcomplicating stuff for developers whenever it isn't needed or crucial? How do we plan to keep introducing folks to front-end development given how fast the requirements list is growing?

How to improve loading time performance with Gulp and Puppeteer on a Drupal site

Nicolás J. Engler — Tue, 30 Jun 2020 04:05:34 +0000

By now Drupal is a fairly known content management framework, which is why some companies choose to build their site using it given its history and how robust it is.

I've been working for a client for about 2 years now, and they have a rather large Drupal site with multiple dependencies. For this client in particular I'm in charge of front-end development and some back-end integrations, and currently we're using a Gulp-based workflow to manage static assets. This process involves Sass compilation, image compression, and JS minification/concatenation, among other stuff.

In a routine check, a member of the client's team decided to run the site through Google's PageSpeed Insights and to my dismay our initial score was pretty low, ranging between 20 and 30. After this report I decided to dig in a bit deeper and see how we could improve our PSI score which led to some interesting takeaways. Not only we were using a bunch of third party scripts for different tasks (some scripts weren't even necessary anymore) but we also realised that Drupal tends to position render-blocking content at the top of the page, inside the head tag, that could be either deferred, preloaded or moved to the bottom of the DOM right before the closing body tag.

But moving our render-blocking content to the bottom of the document wasn't enough, since we were now getting pretty awful performance on metrics like our First Meaningful Paint. Based on this we decided to see if there was a proper way to create critical CSS and include said declarations inline in the head of the DOM, this would help us improve our FMP and perceived loading times keeping the benefits of moving the rest of our render blocking resources to the end.

Approach No. 1: Hand-picked critical CSS

Our first thought when moving forward to create critical CSS rules to include on the site was to generate a hand-crafted separate file. This process was running smoothly until we tried to import some partial Sass that depended on Bootstrap mixins and variables, which eventually led to dependency hell defeating the purpose of critical CSS. We were unable to create a critical CSS file since we were including a bunch of unneeded declarations because of dependencies.

Approach No. 2: Fetch the homepage critical CSS using a tool like Chrome/Chromium DevTools' Code Coverage

After learning about Chrome/Chromium DevTools' Code Coverage we thought "What if we could run a headless browser when the build process runs and use the DevTools to fetch our homepage's actually used CSS which also includes stuff like navbar, menu, text sizing and color, etcetera?"

Enter Puppeteer: Puppeteer is a Node library which provides a high-level API to control Chrome or Chromium over the DevTools Protocol. Puppeteer runs headless by default, but can be configured to run full (non-headless) Chrome or Chromium.

The first step to include Puppeteer in our workflow was to add it as a dependency:

npm install --save-dev puppeteer

And then we include the dependency in our gulpfile.js

const puppeteer = require('puppeteer');

After Puppeteer is available to work within our Gulpfile we proceed to create a new task (named css-critical) in charge of generating the critical CSS file and declare a variable to hold the URL from which Puppeteer will fetch our critical CSS:

gulp.task('css-critical', async function() {
    const URL = 'https://exampleurl.com';
});

With that in place, we now need to declare a new empty string variable to hold whatever we gather as critical CSS, and launch a headless browser with a viewport of 1440x900 pixels:

gulp.task('css-critical', async function() {
    const URL = 'https://exampleurl.com';
    let criticalCSS = '';

    const browser = await puppeteer.launch({
        headless: true,
        args: [`--window-size=1440,900`],
        defaultViewport: null
    });
});

Our next step is to open a new page, start the CSS Coverage tool, load our site, store the results in a variable called cssCoverage and finally stop the CSS coverage tool.

gulp.task('css-critical', async function() {
    const URL = 'https://exampleurl.com';
    let criticalCSS = '';

    const browser = await puppeteer.launch({
        headless: true,
        args: [`--window-size=1440,900`],
        defaultViewport: null
    });
    const page = await browser.newPage();

    await page.coverage.startCSSCoverage();
    await page.goto(URL, {waitUntil: 'load'})

    const cssCoverage = await page.coverage.stopCSSCoverage();
});

Next we'll need to select the used data ranges returned by the Coverage tool in order to compose our final CSS file.

gulp.task('css-critical', async function() {
    const URL = 'https://exampleurl.com';
    let criticalCSS = '';

    const browser = await puppeteer.launch({
        headless: true,
        args: [`--window-size=1440,900`],
        defaultViewport: null
    });
    const page = await browser.newPage();

    await page.coverage.startCSSCoverage();
    await page.goto(URL, {waitUntil: 'load'})

    const cssCoverage = await page.coverage.stopCSSCoverage();

    for (const entry of cssCoverage) {
        for (const range of entry.ranges) {
        criticalCSS += entry.text.slice(range.start, range.end) + "\n"
        }
    }
});

After this is done and ready, we'll proceed to close the page, close the browser and dump the content of our criticalCSS into an actual file, that will later be inlined into our Drupal html.html.twig template.

gulp.task('css-critical', async function() {
    const URL = 'https://exampleurl.com';
    let criticalCSS = '';

    const browser = await puppeteer.launch({
        headless: true,
        args: [`--window-size=1440,900`],
        defaultViewport: null
    });
    const page = await browser.newPage();

    await page.coverage.startCSSCoverage();
    await page.goto(URL, {waitUntil: 'load'})

    const cssCoverage = await page.coverage.stopCSSCoverage();

    for (const entry of cssCoverage) {
        for (const range of entry.ranges) {
        criticalCSS += entry.text.slice(range.start, range.end) + "\n"
        }
    }

    await page.close();
    await browser.close();

    require('fs').writeFileSync('css/critical.css', criticalCSS);
});

With everything in place, all that's left to do is to inject our critical CSS file into our template and move all render-blocking CSS and JS to the bottom of our DOM. html.html.twig should end up looking something like this:

{%
  set body_classes = [
    logged_in ? 'user-logged-in',
    not root_path ? 'path-frontpage' : 'path-' ~ root_path|clean_class,
    node_type ? 'node--type-' ~ node_type|clean_class,
    db_offline ? 'db-offline',
  ]
%}
<!DOCTYPE html>
<html{{ html_attributes }}>
  <head>
    <head-placeholder token="{{ placeholder_token|raw }}">
    <title>{{ head_title|safe_join(' | ') }}</title>
    <style media="screen">
        {% include directory ~ '/css/critical.css' ignore missing %}
    </style>
    <js-placeholder token="{{ placeholder_token|raw }}">
  </head>
  <body{{ attributes.addClass(body_classes) }}>
    <a href="#main-content" class="visually-hidden focusable skip-link">
      {{ 'Skip to main content'|t }}
    </a>
    {{ page_top }}
    {{ page }}
    {{ page_bottom }}
    <css-placeholder token="{{ placeholder_token|raw }}">
    <js-bottom-placeholder token="{{ placeholder_token|raw }}">
  </body>
</html>

And that's it! This approach helped us move our PageSpeed Insights score between 50 and 60 points up from the initial 20-30 we were getting.

Some improvements that can potentially be done:

Remove duplicate declarations by comparing critical CSS generated and regular CSS
Remove unwanted elements that might not be considered critical for the site, i.e.: a slider, video decoration, animations
Create a page-by-page approach to serve critical CSS that's adjusted for each page rather than just one page used in general

React explained to newcomers

Nicolás J. Engler — Sat, 26 Jan 2019 14:14:16 +0000

How would you explain the benefits of React to a dev that has never worked with the library?

I'm mentoring a friend that's currently mastering JavaScript/jQuery, but I'd like to eventually introduce him to a more modern stack (most likely webpack, React AND Vue, Babel, etcetera). I was wondering what's the best approach to explain the benefits of React as a whole without making that explanation too complex.

The case against style consistency in the profile of product designers

Nicolás J. Engler — Sun, 23 Dec 2018 05:09:25 +0000

I have always been a very anxious person, at least ever since I can remember. This can be either a blessing or a course for developers, and designers, depending on the situation. Allow me to give you an example I've come to experience firsthand: if I need some sort of drive to grind through a task or to learn some new skill in order to keep up with the latest technologies (and trust me, there are plenty of those), anxiety controlled in a healthy manner can be weaponized and turned to my favor. But on the other hand, when things go wild, anxiety can also paralyze me.

The last couple of weeks have found me revising my portfolio and social media profiles over and over again just because I feel I'm not good enough. I'm constantly seeing these amazing Dribbble and Instagram profiles of great product designers or coders, and they seem to be all about great visuals and total consistency, they are entirely devoted to developing and selling their own brand by showing all of the amazing products they've worked on. I truly believe I don't have that in me.

Ever since I started my professional life, in those first years under the "web designer" title, I've worked on a wide range of products, sites, apps, and whatever else you can think of that involves planning, design and/or development. The projects I tackled go from sites for the local dairy industry to animations for an Android app to find accountability partners. My mind ran wild thinking of ways I could've improved and cleaned up my online presence using these past experiences to show some sort of brand and patternization of whatever I presented and introduced to the public, but that just isn't possible because for every project I had put into part of myself and my craft, there was also a big range of differences that impeded said "patternization".

After some days of deliberation and crippling thoughts, I wondered why is it that I absolutely had to show this side of myself? It's true that I tend to overshare my little experiments. I create pens in CodePen and post videos on Twitter/Instagram as well as gifs on Mastodon, but I should be doing that, right? I want my potential clients/employers to see that, I want them to hire me because they enjoy that part of myself, because they want that in their projects and creations.

We're constantly bombarded with this expectation that product designers must excel in every field they work on, whether that is UX, UI, front-end development, planning, back-end development, etcetera. I can't do that, because I end up dreading the tasks involved in that approach, and because I have to refrain from doing some things that bring me a lot of joy, like sharing and fiddling with experimental snippets of code in front-end playgrounds. I've come to terms with the fact that my design and marketing side might not be as strong as other people out there, and that it is OK, we can't be good at everything we do. Being at peace with this allows me to keep on pushing through with the things I'm good at, and just as I'm finishing these lines I remember when I wrote this.

How to assign a custom layout to a page according to its URL alias in Drupal 8

Nicolás J. Engler — Sun, 28 Oct 2018 14:38:48 +0000

For the past couple of weeks I've been working as a contractor for an NYC-based NGO that's using Drupal 8 to power their site. My first task was to move their styleguide from a design done in Figma to actual components built with HTML and CSS inside Drupal, but there was a trick: the styleguide had to be set up as some sort of general type content and all I was able to customize was the URL alias.

I went on and duplicated the page.html.twig in our subtheme in order to customize that and work there, later renamed the file to page--styleguide.html.twig. After that I created all related content and used a URL alias that was styleguide happily knowing that (as stated by Drupal's documentation) it would pick up the custom layout automatically without the need of indicating anything.

Narrator: the custom layout wasn't picked up by Drupal

I wasn't able to find why the custom layout was not being used, so I decided to do some googling and found a useful function to suggest Drupal which layout to use. After some tweaking I ended up with the following snippet (placed inside my .theme file)

// Set up hook
function themename_theme_suggestions_page_alter(array &$suggestions, array $variables) {

  // Check if the content being loaded is a node
  if ($node = \Drupal::routeMatch()->getParameter('node')) {

    // Get the node's ID
    $nid = $node->id();

    // Get the URL alias based on the ID of the node
    $alias = \Drupal::service('path.alias_manager')->getAliasByPath('/node/'.$nid);

    // Check if the URL alias matches the styleguide's
    if ($alias == '/styleguide') {

      // Suggest Drupal to use whatever custom layout we have defined inside /templates
      $suggestions[] = 'page__styleguide';
    }
  }
}

I'm by no means a Drupal expert, quite the contrary, so I'm not entirely sure if this solution is properly executed or performant for that matter. If you know a better way to solve this, feel free to leave a comment!

4 tips on how to work remotely from a small town and not die trying

Nicolás J. Engler — Mon, 08 Oct 2018 01:21:14 +0000

Originally on Medium

Working remotely from a small town can sometimes be even harder than doing it from a big city, which is why a good support system and some online friends can make a big difference.

I’ve been working remotely for about 8 years now. My first gig consisted of getting a new web design from a .psd file to a layout using HTML and CSS (I was incredibly under-qualified for that job, by the way) in my bedroom while living at my parents’ house.

If you’ve never been an in-house employee or freelancer, working remotely is usually easier the first couple of months or years, since you’ve never experienced the dynamics of working side-by-side with colleagues or having a pre-defined routine guidelined by social norms, which is why you find the habits that coexist inside an office unknown to yourself. Working remotely is hard sometimes if you lack the hability to find drive and inspiration to get you going or the self-determination to have a set of working hours, for example. But if you live in a big city, you have co-working spaces that can be great if working in a shared space is what gets you going or if what you need is some outside pressure to get dressed in clothes other than pajamas. Sadly, small-towns don’t usually have co-working spaces (at least in third-world countries), and living in a small town while getting your job done is way different than being a digital nomad passing by for a couple of days or weeks, and that is why I decided to make this list.

While I’ve had a 6-month gap in my journey of being a remote front-end developer/product designer (that deserves another post), approximately 96% of my work life has been done in a town of a population that rounds to 45.000 people. Here are some bullets on how to be as productive and motivated as possible while being remote and living in a small city:

Share an office or get used to coffee shops:
If after some time of working remotely you start missing that human connection and the small-talk that happens in an office, I suggest you find an office that’s willing to rent you a desk or go to a small bar and turn yourself into a regular customer.
I, personally, rent a part of the office a couple of friends have to run their print shop. We split some expenses and I get a place in the household, so to speak. Being around people definitely helps me avoid the dread of being home alone, and it also forces me to get out and walk a couple of blocks, catch some fresh air, and maybe even run some errands in the process.
If you don’t find a local community, search for one online:
As you can probably imagine, a city of 45.000 in an under-developed country isn’t exactly a place swarming with designers and developers, which is why finding a community here is incredibly difficult. Because of this I found myself building an online community with some former colleagues, and also using spaces such as the Toptal or the Designlab Slack teams. Sometimes I even Skype with some friends and we each work on our own stuff while chatting a bit and asking for feedback, this is great to feel yourself accompanied by people that works on similar stuff as you do and bond at the same time.
Get into webinars:
Meetups and gatherings will probably happen a few times or be completely nonexistent in your town, which is why you should get used to webinars in order to get cutting edge training and education in real time. I’d also suggest to coordinate meetups and let the town know, you’ll probably be the only one attending but sometimes other unknown colleagues or people looking to get into the industry might appear and realize they’re not alone!
Make sure your working space or home-office is in proper conditions and adequately delimited:
I’m going to assume that if you’re working from a remote location you’ll probably also want to take advantage of working from your own place, and for this reason you’ll need to have a proper working space (or an office inside your home if that’s a possibility), adequately decorated and separated from the rest of the other rooms in your place, with all the tools necessary to get the job done. This is useful to keep in mind that this is where work happens, and also to maintain focus while grinding without getting distracted by your significant other(s) or family.

And that’s it! That’s what has gotten me through to this day while working a lot of miles away from the HQs of my employers. While these are not some life-revealing tips, as obvious as they seem, I didn’t realize that most of them would improve the quality of my job and the work-life balance needed to avoid burning out, so I’m leaving those here for other that might be in my position to find out.

I honestly hope this leads you to a better situation work-wise. Until the next post!

Explain the new spec for CSS' font-variant property like I'm five

Nicolás J. Engler — Wed, 04 Oct 2017 12:23:54 +0000