How to determine if that remote developer job will throw you in the deep end or not

So you’re looking for your first remote software developer job but all the job postings list requirements beyond your current knowledge.

“I’m looking for a position where I can LEARN, but most remote positions ask for things I can’t learn on my own”

Maybe you’re a junior developer looking to enter the industry. Or maybe you’re seasoned but looking to learn some new technology, business domain, or how to solve some technical problem not readily available to you.

This can be even more daunting if you’re thinking about working remotely where you won’t have someone right next to you you can easily ask for help.

Whatever the case may be, your goal is to be able to advance your skillset with help from the team.

Fortunately, there is a way you can figure out if the company you’re interested in working for will throw you in the deep end without a life vest or if they’ll help you while you pick up speed.

And the way of doing this is rather simple – look at the company’s current engineering team makeup. A team that will provide support will have a mix of junior and senior developers. Any company committed to leveling up its employees’ skillsets and knowledge will seed a team with varying skillsets and knowledge levels. Senior devs teach the junior devs the art of software, junior devs – through asking questions – teach senior devs how to explain complex concepts, and both teach each other things they maybe should know but might now have ever encountered, like how to solve a particular problem.

It is in companies’ best interest to have all employees grow so that each employee’s individual value to the company increases. And companies that have a mix of skillsets will be more open to applicants and new employees who might not hit all their “required” checkboxes.

“This is great to know, but how do you find the makeup of the engineering team if you’re not actually on the team?” you might ask. Again, simple. Browse the company’s Linkedin profile, looking for current developers employed there and look through their titles. If this doesn’t provide much of a result, you can see if the company has a GitHub, Twitter, Facebook, etc. presence and browse there. If all else fails, you can resort to old-fashioned email and politely inquire there.

Don’t miss my next post!

* indicates required



 

Easy way to make Angular 2 services configurable

There are several ways to make configurable components and services in Angular 2 / 4 – APP_INITIALIZER, providers, dependency injection, etc.

But these can sometimes be confusing to use. An easy way to make your services configurable is to simply use a class setter in your service. An example can be found in the library I recently built ng-idle-timeout. (There are a couple libraries that do something similar, but were overkill for the most part)

This service is used to set the idle timeout (user has not moved mouse, typed, clicked etc for a length of time) for the UI. But obviously all consumers of the service will have different business requirements for what this length of time should be. In my library, the default is set for 20 minutes, but let’s look at how to override this.

The ‘setIdleTime’ method allows consumers to override the default timeout. Consuming this is very easy. To use this service, import it at the root module of your app (usually app.module.ts) and in your root component (usually app.component.ts) subscribe to the observer, like so:

You can implement this on an individual component if you wish, but as the root component is instantiated only once, it’s recommended to place it here.

The nice thing about this way of configuring services is the configuration method is contained and located within the service itself. There is no magic happening that is abstracted away by the framework.

 

How to use your on-site trips strategically as a remote employee

In organizations that aren’t fully remote, remote employees can sometimes be forgotten about, seen as black sheep or as separate from the group. To your colleagues, you can be seen as that weird cousin people only see for the yearly family gathering and who people sort of know but not really. If you’re a remote worker you probably have had that feeling of being excluded from the group, or showing up and people forgetting who you are. Even if you’ve had plenty of interactions with your colleagues in the past (maybe you worked on-site for a couple years), you’re not on people’s minds as much.

Have you ever visited the office, walked into a meeting, and had someone introduce themselves as if you’re new to the company? Have you gotten that blank stare from a coworker you just talked to over the phone last week about a deliverable, as if they don’t recall the conversation? Or maybe you wanted to be put on a high-value new project but were passed over for consideration.

The on-site trip (especially for those out of the state or the country) can be a great antidote to this, but only if approached with purpose. The on-site visit should not be seen as simply “working from headquarters for a week”, but instead a strategic opportunity to maintain existing relationships with colleagues, build new ones, and advance your career. And with only having so much “face time” as a remote employee, it’s important to make the trip count.

NB: this post assumes you take regular (of whatever cadence) trips to the company’s office on-site. If you don’t, there will be a separate post detailing why you should be.

In advance of the trip

I mentioned that it is not enough to simply show up when you travel on-site, but instead to be deliberate and strategic about the trip. That might sound abstract up until now, so let’s shine some light on how you go about that. Doing the work up front to identify opportunities for yourself as part of your next trip is the most important work you can do. These opportunities can take the form of any of the following (and any more you might think of):

  • colleagues to meet with
    — existing ones
    — ones you don’t know
    — ones new to the company
    — someone junior to you (possible to mentor them)
    — someone at your level
    — someone who is a level above you (possible to be your mentor)
    — hiring managers for open jobs within the company
    — your manager (grabbing lunch is usually a good idea to reconnect)
    — your manager’s manager, if possible
  • a presentation on a company-relevant topic you could give with your team members
  • organize a group outing

Note that it’s important to be strategic but also genuine. The list above is purposefully diverse in that it provides for opportunities that are not just beneficial to you, but to your colleagues and the company as well. Don’t express interest in projects or people just because you think they could benefit you or just for the sake of expressing interest. Have genuine interest in projects and people, and this will go very far in establishing positive relationships within the company.

Once you have a list of people, reach out to them to set up individual chats. Let them know why you’re reaching out (if it’s someone you don’t know or don’t know well). Obviously if these are coworkers you already know and have a good working relationship with, these chats can be super informal and can probably happen more organically as opposed to being scheduled. For those you don’t know as well, email is usually the communication method you want.

While the content of these emails is enough to cover a whole new post, be sure to let those you’re reaching out to know you work remotely and will be in town for so-and-so dates. This is important in non-fully remote companies as sometimes people will need to reschedule and might reschedule to a date when you won’t be in town, not knowing that you wouldn’t be able to attend.

After doing your reach outs, talk to your manager to review your upcoming trip. Hopefully your manager is already identifying opportunities for you, but it’s important to be more proactive when remote. Review your list of brainstormed people and opportunities to see if he/she might be able to help you with any introductions or ideas you might not have thought of. Obviously if you’re going to be meeting with any hiring managers in the hopes of transferring within the company, it’s probably best not to discuss this with your manager, but of course I don’t know your company’s HR policies so proceed with discretion.

Make sure your manager and your team members know you’ve got this “connecting time” booked into your schedule and that, while you’ll attend all mandatory meetings, you won’t have full availability while you’re in the office. Hopefully the trust element is already there and they’ll totally understand this, but if not make the case for how these “connecting times” are a way to make sure you’re not missing out on anything by being remote that could hurt your work and connection to the team. Few organizations will reject collaboration and anything that inhibits it, so this argument should help you in case of any pushback.

Lastly, depending on your standing within the company, you might identify a meeting you normally wouldn’t get invited to or hear about and ask your manager to get you looped in. This should be something just enough above your pay grade that it will be beneficial to you, yet not high enough that your being there will raise eyebrows. Do research ahead of time so you can have context and contribute to the discussion during the meeting.

While on-site

While you’re on-site, just because you already have a list of people to meet with doesn’t mean that you shouldn’t make an extra effort to introduce yourself to people you don’t recognize.

Be sure you’re prepared for your one-on-one chats ahead of time, taking into consideration the person you’re meeting with and the context of the conversation. It will be up to you to drive the conversation, so have questions prepared, be able to articulate what you do in your current role, etc.

Towards the end of your chats, let your new contact know you’ll be back in town in “X” number of weeks. This not only provides an opportunity for follow up but also suggests these on-site visits are a regular thing for you and you’re important enough to travel back regularly.

Depending on how the conversations go, if you think both parties are open to establishing a mentoring arrangement then feel free to setup more regular one-on-ones. Just be aware, usually these can take a couple times of meeting in person to establish enough of a working relationship to pursue something like mentoring, especially remote mentoring. So just be sure to use discretion here as to avoid coming off as socially tone-deaf.

One of the opportunities I listed was giving a presentation on some subject with your colleagues. This is a great way to gain more visibility for both yourself and your team, as long as – and this is important – the topic selected is one that is of interest and value to the company. This shouldn’t be a topic on some niche part of some design or development framework, or some obscure marketing technique, but something both meaty enough and general enough that you can present to an audience of individual contributors as well as more senior leaders. This is the strategic way to go about it if you are interested in career advancement as a remote employee. While you’re not going to get a promotion out of it, it at least raises your visibility among peers and leaders in the company.

This is something to talk to your manager ahead of time about so that he/she can help promote it. Doing the presentation with a group is also a great way of not putting all the focus on yourself as “that remote employee”. This way others will not see you as separate from the group but instead an integral part of it and you’re just doing what you would normally do if you were always on-site.

In general, when you’re on-site you want to make it seem like you’re always on-site. In meetings you’re not the “remote guy”, you’re “Dave, working on the re-platforming project” or whatever. Part of overcoming the “black sheep” hurdle is in actively contributing to conversations and meetings while you’re on-site. Don’t over-dominate the conversations, but also don’t shy away from speaking up often. Your colleagues don’t hear from you in the hallway and water cooler conversations, so consider this as making up for that (I’m partly serious and partly joking here). Speaking up will help deter any notions that you’re separate from the group or that remote inhibits or affects communication.

Another opportunity mentioned was to be on-point for organizing a group social outing. In keeping with the goal of not standing out as separate from your company, such an outing should not be for the express purpose of seeing you while you’re in town, but instead for the general enjoyment of the group.

A few days after the trip

When you get back home, follow up with your manager to discuss the trip. The reason to discuss the trip before and after with your manager is for more than just administrative reasons – instead it is to provide him/her with context for career development. Discuss what you got out of it, your plans for next steps, projects you might want to be involved with, opportunities for improvement, etc. Don’t be afraid to go into detail. Your manager will likely value any over-communication over just a “yeah it was a good trip”. Your company pays a lot for travel/accommodations so it’s important they know it wasn’t all for naught. Your manager may even get clued into “goings-on” within the company that he/she wasn’t even aware of, that might be of benefit to themselves to pursue.

Perhaps most importantly there might be projects or mentorships you pursued while on-site that are a bit of a reach for you now – be sure to discuss this with your manager to see if he/she can help push things from their end. Assuming you have a good relationship with your manager – and if you’re trusted enough to work remotely you probably do – he/she should be going to bat for you. It’s often forgotten that that’s what the “HR” component of management entails. And job expectations or not, good managers enjoy being involved in their reports’ growth.

Based on the context of your individual conversations, it’s good to follow up on these as well. People can get busy, so it’s good to follow up usually a couple days after you get back home. This helps you stay “present” even though you’re not physically there.

If you’re looking for an actionable timeline, the following is one I’ve come up with having taken several on-site trips in the last few months myself and have seen positive results from:

  1. 5 weeks out in advance of your next trip – brainstorm your list
  2. 4 weeks out – talk to your manager about your upcoming trip
  3. 3 weeks out – reach out to your list to setup time on their calendars
  4. 2 weeks out – prepare for presentation or outing
  5. 1 week out – prepare for the chats you set up
  6. While on-site – have your 1×1’s, presentation, outing, etc.
  7. Few days after trip – follow ups
  8. Few days after trip – follow up with manager

A side note

Before ending this post, it should be noted that if you’re not that confident in your communication skills, or are still very early on in your career or time with the company, it’s fine to take a gradual approach to this. Don’t bite off more than you can chew. You’ll have to take the advice and action plan here and measure it against your own unique scenario. You might have to skip “X” or maybe only reach out to “Y”, but the general idea and execution still stands. Maybe one trip you introduce yourself to one person, then two to three trips later you lead a meeting or go after a new job posting, etc.

There are plenty of more remote work posts coming, sign up so you don’t miss out on the next one

* indicates required



 

Closing connections and returning results using node-oracledb

If you’re using the npm module node-oracledb to connect to an Oracle database from Node, consider using this Promise-based and cursor-based wrapper/utility to return results from your queries and close connections: https://github.com/coreyc/oracledb-promise

This wrapper provides the following:

  • Only one function to call – executeSQL()
    • Pass in your SQL or stored procedure and any connection parameters
  • Promise-based, so chain off executeSQL() to return your execution results or catch any errors
  • Automatically closes the connection to Oracle and the result set returned from the database so no need to worry about memory leaks

I wrote this for a few reasons, the primary being a separation of concerns.  Instead of the calling code having to worry about getting the database rows from the cursor, checking for empty sets, closing the result set, and closing the connection to the database, this is all wrapped up in one nice function that handles this automatically for you.  Your code won’t be littered with node-oracledb module-specific code when all you want to do is get results back from the database.  Also, it’s very easy and common to get memory leaks when your result sets and connections aren’t closed so this prevents that.

 

Remote Work As Innovation

The recent obsession with capital “I” Innovation that has been rapidly gaining momentum the last couple of years has permeated across a majority of large, traditional companies with business models, technologies, and processes seemingly stuck in the past. Fear of competition and thus declining profits and stock prices appears to be the primary motivator behind this obsession, with many of these companies desiring to be more nimble and forward-thinking. This has given rise to the so-called Innovation Group within large organizations, corporate partnerships with startups, and hiring of expensive consultants and consultancies to come in and tell these companies “you should emphatically embrace our way.” These actions, often made very publicly as to cast off any prior signifier of “old,” seem to be a race to avoid being last to adoption. Through looking to startups (or more nimble companies), these old titans hope to bathe in the fountain of youth and emerge automatically renewed.

This post is prefaced with skepticism not out of discouragement; quite the opposite. I think it’s a great thing that companies, whether they’re “old school” or not, are acknowledging that they can’t keep doing things the way they always have been lest they be eaten alive in today’s market. These innovation initiatives are essentially a self-reflection exercise. However, I question these initiatives because they so often seem to miss an opportunity ripe for innovation.

While the idea so far has been to follow what the startups are doing to create innovative services and products (or what the consultants are telling you to do), I posit a new theory – both types of organizations are overlooking a major area to innovate on: their working model.

Too many companies require the same, century old working model of showing up at 9 in the same office location or handful of different office locations, communicating in real-time throughout the day, then going home at 5.

Remote work changes this. It’s an innovation on the old model and a ride into the future. And for companies that are already investing so much into self-reflection in the hopes of finding new ways to gain market share, they might as well examine all aspects of the company while the body is already cut open before it’s sewn back up.

The obvious should be stated that not all roles and not all companies will be a good fit for remote work. But if you are a software company – which most companies are nowadays, even if it’s not the company’s primary product – it’s worth considering adoption.

Smart companies will realize that many, many developers want to work remotely (more than just work-from-home every Thursday or Friday) if they aren’t already. Smart companies will dispense with the micro-managerial mandates of heavily synchronous, remote-unfriendly practices such as full-time pair programming, only using [insert tool here], and “always-on” Slack/IM/whatever. And smart companies will understand that developing more flexible environments for their employees will attract the best ones.

The way we’ve worked for the last century is ripe for change as it no longer makes sense in a globalized and techno-superfluous world. All the product, business, and technology innovation will be all for naught if your employee model is not updated as well to match that of the current working world, indeed if it inhibits working in such a world. Remote work policies, thoughtfully considered and adopted, are not just ends unto themselves but can be an opportunity to inspect and improve upon the rest of the working experience.

Adopting remote work is innovation too.

 

10 Observations after Working Remote for 6 Months

I turned my “on-premise” job into a remote one 6 months ago.  Here are ten observations from the experience so far, with the goal that these assist others transitioning or thinking about transitioning to remote work:

1. Able to eat a lot healthier

This was the most unexpected benefit of working remote.  It’s been much easier to cook (almost) all meals at home while remote.  When commuting to and working from an office it was always difficult to prep meals the night before, but working from home it’s easy to cook while working.  Rather than paying for expensive cafeteria or restaurant food that is lacking in nutrition, cooking meals at home with good food from grocery stores or markets is easy.

2. Need to plan out work locations

It’s been easy to fall into a pattern of working from home and not going out to coffee shops, libraries, coworking spaces, etc. to do work.  Planning out the day in terms of which locations I’m going to start or end the day at has been helpful in avoiding this trap.  Usually a change of scenery has greatly helped critical thinking when stuck on a problem.

3. Easy to forget timezones

If you’re working with a distributed team, chances are there is still a home office for your company that several of your team members work from.  Usually the home office time zone becomes the de facto time within which meetings are scheduled.  This was a slight adjustment at first, and planning things like trying to eat lunch an hour earlier took some getting used to.  Even now it’s still easy to forget this time difference sometimes.

4. Able to get more done, more effectively

Productivity is often one of the biggest concerns companies have when considering a move to a remote work model.  It may be accurate to say that doubts around effectiveness are the main factor behind this concern around productivity.  First, it should be noted that if you’re hiring employees you don’t trust to get work done in any location, then you’re hiring the wrong people to begin with.  Second, and most importantly, the transition to a remote model is certainly no easy effort but if it’s done right and team members have proper support, productivity can actually receive quite a boost.  Speaking anecdotally, I’m working with a team now that is entirely distributed across several states and continents.  I’ve noticed my personal output has greatly increased, with this increase mostly coming in quality (but quantity as well).  Our team has consistently completed work on time and even sometimes ahead of schedule, helping assuage any doubts our company might have head about productivity in the remote model.

5. Being the first truly remote employee has its pros/cons

Being the first truly remote employee within my organization, it’s been something of a pioneering experience.  The organization within which I work has had offshore contractors for many years but no employees who work remotely full-time (from another state entirely).  The biggest advantage of this for me has been that I’ve gotten to prove that the model works and move the organization ahead.  “Innovation” is incessantly paid lip service to by any and all companies these days, and while many of them may be pursuing legitimate innovations in product or processes, innovation around work itself is often neglected.  Remote work is the future and is slowly but surely gaining adoption.  Being able to help guide my company into this new frontier has provided both myself and the company with a lot of benefits.

Of course being the first has its downsides, the main being that the organization is still adapting to this kind of work.  Fortunately I’ve received support for it at high levels within the organization.

6. Can feel singled out, but this can be a positive thing

Continuing from the last observation, it can be easy to feel like the “remote guy” when you’re the only one.  Now that I’ve proven the model though, others within my organization are starting to join the ranks of the remote workforce.  Done right, you might find that others within your company respect you more for it as you’re essentially setting yourself apart from your coworkers.  Others will see that you’re trusted and respected enough to be granted this privilege.

7. Work is still work

The stereotypical image for remote work is some guy on a laptop working from the beach, but it’s not in any way that idyllic or cinematic.  Work is still work and if you’re on a tight deadline or putting out some fire, no grandiose scenery is going to change that.

8. Whiteboarding suffers

Depending on the type of work you do, not having a whiteboard can seem debilitating.  It’s a highly effective and quick tool for communication.  Similarly, being in meetings and not seeing what is being drawn on the whiteboard contributes to the communication gap.  An easy solution for this is to setup a video conference (either through Skype on someone’s laptop or a room VC if you have one) and point the camera at the whiteboard.

9. Having more frequent 1×1’s is helpful

I’ve had more frequent 1×1’s with coworkers.  This has helped fill the place of hallway conversations that you don’t get not being in the office.

10. A lot of other remote workers are out there

Working from coffee shops and coworking spaces I’ve seen a lot of other people in these spaces that are also working remotely.  These people have all varied in age, so it’s not just old or young employees pursuing this working model.  I suspect more and more spaces will open up, and existing ones catering to the remote worker as this becomes the future of work.

 

Calm Technology – CTA train tracker


This is the first in a series of projects that will be developed around the idea of applying “calm technology” to product design. Coined by Mark Weiser and John Seely Brown at Xerox PARC in 1995, calm technology can de defined at a high level by the following:

First, by placing things in the periphery we are able to attune to many more things than we could if everything had to be at the center. Things in the periphery are attuned to by the large portion of our brains devoted to peripheral (sensory) processing. Thus the periphery is informing without overburdening.
Second, by recentering something formerly in the periphery we take control of it. Peripherally we may become aware that something is not quite right, as when awkward sentences leave a reader tired and discomforted without knowing why. By moving sentence construction from periphery to center we are empowered to act, either by finding better literature or accepting the source of the unease and continuing. Without centering the periphery might be a source of frantic following of fashion; with centering the periphery is a fundamental enabler of calm through increased awareness and power. – Designing Calm Technology

The goal of calm technology is to have technology serve humans, not the other way around. In today’s world of being bombarded by ads, smartphone distractions, and apps that compete for our attention, it should be a goal to reduce technology to its essentials and push it to the background, while also allowing it to come to the foreground when it needs to. I think this is going to be a big thing in the coming years, partly as a reaction to the poorly designed technology experiences we are forced to deal with today.

Building a better train tracker

One area I lose a lot of time to technology is in figuring out when the next CTA (Chicago Transit Authority) train will be arriving. The timetables are not real-time so do not account for delays and having to pull out my phone to see when the next train is arriving and when I should leave in order to catch it inevitably leads to being distracted by the gateway of information a smartphone provides. This project was built so that I could easily and almost sub-consciously check when I should leave from my home to catch my next train.

Design considerations

The device is built using an Arduino MKR1000 powered externally and a single WS2812B LED, so these were the hardware parameters that were designed around.

Several considerations were given to solutioning for this design:

    How many trains should this track? From which station, and in which direction?
    How should the notification system operate? At what frequency?
    How should this be designed so it operates at the periphery?
    What technology choices should be made so that this device is a good “technical citizen”?

In order to quickly get this built and test its efficacy, the decision was made to just track one train line, station, and direction for now (the nearest line and station to my residence, and the direction I am most often heading in).

As for the notification system light and color were chosen due to their ambient, peripheral qualities. Obviously having an additional or alternative notification system that relies on a different medium (color choices, sound, etc.) would be necessary for those that are blind or color-blind.

Now there were several considerations given to frequency (times) of the light being displayed and which colors to use. The decision was made to calculate time based on travel time from my residence to the station, thereby reducing one more cognitive step (addition of travel time to station plus arrival time). A train tracker will tell you when the next train is arriving but does not usually include the buffer time you need to give yourself to leave from your location. It was a very conscious decision to avoid using red, yellow, and green as these colors already have meaning in relation to transportation and time. If the LED was set to red would that mean the train was delayed? Stopped on the tracks? Would it mean I should stop? If it was green would that mean I should leave? Would it mean the train is going and has already passed my target station? Note here that as the station is about a 6 minute walk away and I don’t want to wait at the station for that long, any train that will be arriving within the next 6-8 minutes will be “time to leave,” with 5-6 minutes being “I might make it in time” and less than 5 minutes being “too late”. The LED used is programmable, so there is only one light source and the colors settled on were blue (neutral) for “time to leave,” purple (neutral, but with enough red in the hue that it suggests importance or urgency) and nothing (LED off). The original design had the LED turn on to a brownish yellow if I had missed the time to leave for the train, but in order to reduce the cognitive processing needed by the user and to not distract, it was changed to just turn the LED off. The LED stays on and at its current color until a change in state of the train’s arrival time. So the design ends up looking as below:

Don’t leave yet

Time to leave

Might make it if you leave now

While periphery choices have already been discussed, it is important to note that as this device is designed to be running in the background all the time when it is turned on, sound as a notification was decided against. It would get annoying very quickly hearing even pleasant “time to leave” sounds due to the frequency at which trains arrive and leave the station. Light is more ambient and less disruptive. Also, the LED used is just small enough to not stand out, but bright enough to be noticed when you want to check if it’s time to leave.

In order to provide timely estimates, the Arduino fetches arrival time data from the CTA Arrivals API every 10 seconds. This seemed like the right balance between betwork bandwidth with getting timely data. Bandwidth used is already tiny (data is returned in JSON format in a few bytes) and the code is optimized to account for small Arduino RAM and storage size. And to turn off the device when it’s not needed, the on-board Arduino power button is used. It can also be unplugged from power and will restart automatically when it’s plugged back in.

Next steps/future improvements

As this is the first iteration of this product, several ideas may be implemented in the future. A priority is designing a physical case for this device to be housed in, removing wires from the user’s view and further reducing it to its bare essentials aesthetically. There might be several devices that a user has in their home/office/wherever this device might be installed that similarly rely solely on light as notifications, so some differentiation would be required here. Whether this is done through changing the light patterns, or probably more effectively, adding some simple signifier to the physical design of the housing, it should be obvious to the user what the purpose of this device is while still remaining on the periphery. Another improvement would be around power, as the device currently runs while plugged into AC. Moving to a long-lasting battery would make it easier for the user to move the device to another location while also further hiding the technology itself (wires) from view.

Lastly, getting this in the hands of real users and doing user testing would be valuable for product improvements. I’ve got some ideas for adding sensors to this to have some internal metrics running for product feedback too.

 

Monopoly on Empathy

Look through any User Experience (UX) conference presentation description, UX profile on Linkedin, or go to any UX meetup and the word you will hear most often is “empathy.” As UX has become more formalized as a discipline over the last few years this word has been a rallying cry for the industry. “We fight for the user!” and “We bring empathy to software applications!” are commonly heard. But this word is problematic for many reasons and it’s a massive oversight by the profession that it continues to be used. It is not so much because of the word itself but moreso because of its application and implications. While “empathy” is the most commonly used, it’s certainly not the only one in this tale of poor language choices. A pass at slaughtering these sacred cows will be made too. I aim to point out how this language problem is ultimately counter to the goals of UX (both the end user’s experience, as well as UX as a profession). For want of avoiding making this seem like a fastidious excursion into semantics, I will also tie this into how it impacts UX’s standing within the corporation at large.

The foremost problem of using “empathy” to define your profession’s existence is that you are essentially stating that you as a UX professional have a monopoly on empathy. You are implying that developers, marketers, business people, and anyone else peripheral to the UX craft are apathetic, indeed the opposite of empathetic. It is implied that without you, there would be no empathy for the user, as if the rest of the project team would, whether through menace or ignorance, create and deliver an application that confuses and demoralizes the user. Of course, this is absurd; no one will argue with you that wanting to ensure your users can easily use your application and accomplish their goals is a positive thing. And it should be made clear that UX as a group does not have a monopoly on empathy, just as it does not have a monopoly on the user. Other groups are perfectly capable of wanting to ensure the application works well and easily for users. This is all without even mentioning that “empathy” is a very presumptuous term altogether.

Perhaps the second-most offensive word in our UX existentialist vocabulary is “delight”. Within an application measuring delight is subjective at best, and I can guarantee that no user study that utilizes the encroaching practice of video recording will be able to suss out or give any reliable data whatsoever regarding delight. The misguided pursuit of delight has led to unnecessary animations, uncalibrated and perhaps even overly personal/conversational help text and copywriting, among other things. While delight might be nice in video games or entertainment, I would argue it is not something that is even needed in all applications. Do users even want or need to be delighted? Delight should mean they accomplished their goal or task with the application, not that they saw some pretty colors and slick button animations (…Material Design). Or receiving confirmation emails like “you’re totally awesome for signing up dude, surf’s up!”

The final piece of language we will pick apart is certainly the easiest to do so, due in part to its lesser frequency compared to the prior, but also due to the extremity of its claims – “changing the user’s life.” If “empathy” or “delight” were pretentious or presumptuous, laying claim to “changing the user’s life” through designing experiences is mega-pretentious. Too often this language is a mask for signalling of the offending UX professional’s importance, not the user’s. “We are changing the user’s life” is how this is most often heard. The language has become self-serving, ironic given that UX is meant to not be about the designers themselves but about the user.

Why are we seeing such language be used, and used so boisterously? As mentioned in the opening paragraph, UX has only recently become an “official” group within most companies. While UX has been around for a long time, it’s acknowledgment by the corporation is more recent. Thus the profession has had to utilize language that displays confidence in an effort to establish and formalize itself as part of its entry into the corporate landscape. There is without question a degree of pretentiousness and egoism exhibited by some in the design and UX professions. Is the self-righteous language we are examining the brainchild of those offenders? Perhaps, but the more plausible cause is this birth-stage of the UX profession.

Any discipline at early stages is both burdened and liberated by being able to define themselves. Software engineering is a couple decades ahead of UX and thus has had to work to establish itself within the corporation for much longer, so observing the software engineering profession can serve as a cautionary tale for UX as I believe the isolating language that developers often use has resulted in the profession shooting itself in the foot time and again with regards to its standing within the corporate hierarchy.

A common attribute of the language discussed above is moralism (or even self-aggrandizing). Whether or not this is intended, what we can see is a two-fold effect: through moralizing, you start to create a division between you and other groups (them below, you above); through using this language to establish a jargon of its own for UX, you start to become other. Creating barriers between you and other groups – isolation – is existential death within the corporation. Don’t follow the mistakes that the software engineering profession has made by rattling off technical jargon and buzzwords, feeling shocked at the business’ lack of understanding (or more accurately, caring). UX does NOT want to get the same treatment while making remarks like “yeah we just need to boost the level of empathy with this onboarding flow so that we can delight our customers a little bit more and the user’s life will be forever changed.” Do this and UX becomes “those guys creating experiences and delight for our customers… or something like that, I don’t know but they’re in the basement somewhere” rather than a partner of the business.

Furthermore, empathy and delight are not easily understand in business terms. Something like “helping remove roadblocks for users so that our products are better and get more people through the funnel” – now that is something that the business can understand AND it works in service of the user. Hopefully it is evident that vague and vacuous terms like empathy and delight are terrible word choices for a profession that is working to establish more respect for itself within an organization. The reality is that sometimes business goals cannot be ignored, and designers unfortunately cannot always make the decision that is in the best interest of the user. They can “fight for it!” sure, but it can’t always happen and this is ok.

My recommendation: get rid of the moralizing and self-aggrandizing attitude and use language that puts you on equal footing with the business while explaining the importance of paying attention to user needs. Language puffed up to display a confident attitude may have helped when UX was working to establish itself within the corporation, but it can only do a disservice now. Language plays a larger role in business than many of us wish to acknowledge, so change this before it’s too late. Before UX becomes a group that is relegated to lower rungs of the organization, rather than seen as a business partner. Understand whether users actually need empathy or delight. Dispensing with this language can only help UX in its goal of being seen as a crucial element of the business. Developers have their own self-alienating language they use, and have suffered for it. UX professionals should stop now and avoid it before it’s too late. Take a more research-driven approach to design and gather metrics (where you can). Focus less on capital UX and more on lowercase ux, that is focus less on the profession and its existentialism and more on user experience. And if you truly believe that a software application can be “life-changing,” then it is ultimately the application itself, that is to say, the product, that affects this change. That product is everybody’s job, not just UX’s.

 

Setting up Chrome Extensions for use with ES6

First time setup of Chrome Extensions can be painful if you’ve never done it before. Add to that setting them up for use with ES6 and you can end up spinning your wheels longer than writing code. I recently went through this while creating Reading List, which makes heavy use of ES6 as well as Ramda for the functional work. While Babel setup is fairly easy, the module loading presented some challenges. Having originally gone with SystemJS I faced a lot of difficulty in getting the tests to run. After switching to Webpack, for all the horror stories I had heard about it, the issues I was facing were resolved within the hour.

TLDR: You can see an example of the setup here https://github.com/coreyc/reading-list. It is somewhat barebones – intentionally – as so many JavaScript developers waste their time with tool configuration these days. This setup is meant to get you off the ground ASAP.

We’ll step through the setup as follows:

  • Transpiling – Babel
  • ES6 module bundling & loading – Webpack
  • Setting up the Chrome extension
  • Setting up unit tests

Transpiling – Babel

This part is pretty simple. Install the Babel tools we’ll need with the command below:

What does this install? Because Babel can compile several ECMAScript specs we need to install the preset for the version we want to use, in this case ES2015 (ES6). If we wanted ES7 we could install a preset for that too. We also need to install babel-loader so that we can integrate with Webpack. Lastly, babel-register is needed so that we can run our Mocha tests.

Next step is to tell Babel what presets we want to enable. Create a .babelrc config file if you haven’t already and add the following:

And of course if you want to use ES7 features you would add the ES7 preset to this config.

That takes care of Babel.

ES6 module bundling & loading – Webpack

We’ll be using the import / export statements from ES6, formatting our modules as ES6 rather than AMD or CommonJS. Webpack will bundle these modules up for loading in the browser. Install with:

Next we need to add a webpack.config.js file to the root of our project. Configure it like so:

The entry point for our app contains imports of the other files used in the project. It might look something like this:

bundle.js is the output of our modules after they’ve been run through Babel and Webpack. If you have any 3rd party libraries, include them in the externals property so that they won’t be included in the bundle. Otherwise all the code for that library will get bundled up and dramatically increase the file size.

From the command line, run the following in order to actually create the bundle and it’s source map:

Now we need to configure our npm run start command so that it does this bundling and serves up the files in one step. Add this to package.json:

That takes care of Webpack.

Setting up the Chrome extension

Chrome extensions have a config file of their own, manifest.json. Here’s the one from my project:

I won’t go into too much detail as this config can get really complex, but the main things to know are that you specify the icon, the HTML file you want to run when you click the extension icon, what Chrome API’s you need under permissions, then add your content scripts, which are scripts needed by the HTML file you specify. Disclaimer: you can also specify background scripts that run, but I did not make use of these. This setup is not tested for use with background scripts, although they may run just fine.

We take the bundle file output from Webpack and use it as our content script. An important thing to note is that you can specify when this file should run using "run_at". This is especially useful for when you need to use DOM events such as DOMContentLoaded, as extensions seem to block this event from firing. The "run_at" property is useful because it tells the script to execute when you specify, in this case at the start of the document load.

Next we need to add the bundle file to our HTML:

A side note here: I had to add the Ramda library to the HTML even though it was specified in the Webpack config as an external library. Not sure if this is the correct way or not, but it works. YMMV.

That takes care of Chrome.

Setting up unit tests

Now we just need to set up our unit tests. If you don’t already have mocha installed, run npm install --save-dev mocha . Add this to the “scripts” property of the package.json file:

Most info you’ll find on setup will recommend
"test": "mocha --compilers js:babel-core/register test pattern here"
but this seems to be outdated and the Mocha docs recommend just using –require babel-register. From the docs:
“If your ES6 modules have extension .js, you can npm install –save-dev babel-register and use mocha –require babel-register; –compilers is only necessary if you need to specify a file extension.”

Run npm run test and watch your tests run.
That takes care of unit tests.

 

Why is `compose` right to left?

I’ve been working my way through the excellent Mostly Adequate Guide to Functional Programming recently. Although I’ve been working with compose for a bit now, I needed to review why it operates from right-to-left (also known as “right associative”). A review of mathematical theory will help answer this question.

Function Composition

functional composition

The image above is read as “g ∘ f”, or “g composed with f”, or “g-compose-f”. For example, (g ∘ f )(c) = #. If we change ‘c’ to ‘x’, this function would read as g(f(x)). As you’ll remember from high school algebra and composite functions, this means you plug in something for ‘x’, then plug that value into ‘f’, then plug that value into ‘g’. This evaluation occurs from right to left, hence why compose is right associative.

To illustrate compose, consider the following:
f(x) = 2x + 2 and g(x) = –x + 3, find (g o f)(1)
Solution:
(g o f)(1) = g(f(1))
f(1) = 2(1) + 2 = 4
g(4) = -4 + 3 = -1 (remember, 4 was return value of f(1))
…and -1 is our answer from this function composition.

Left to Right

Developers don’t always think in right-to-left fashion, so if you want the reverse pipe (or sequence depending on the library), is an alternative to compose that operates from left-to-right.