google reader refugee.
1878 stories

my employee is refusing to travel because her husband said she can’t

1 Share

A reader writes:

I’m a manager who has an employee who recently (late last year) accepted a promotion that involves travel. It would be a maximum of one overnight monthly, but more typically one overnight per quarter. She accepted the position knowing that this level of travel would be required.

However, she told me last week that she will no longer travel because her husband told her no and her religion tells her to obey her husband. I said the role requires travel and she accepted the role just a few months ago knowing that, so I’m not sure if I accommodate her dislike of travel and keep her in the same role. She says it has to be accommodated because it’s her sincerely-held religion.

I also know her husband recently took away her car because “queens don’t drive.” He drives her to and from work every day. When he arrives to pick her up, which is early every day, she gets really antsy until she’s released to leave because she can see his car from her desk window. She can no longer attend external meetings alone because she doesn’t have transportation, which has created problems already (she was going weekly to external meetings maybe 10 miles away), but technically her job description doesn’t say she needs her own car so my boss thinks we can’t enforce that.

Currently, we’re working around her “dislike” of travel and taking other people from her team. But it’s not really fair that she got a raise and promotion, and these people didn’t, but they have to do the travel requirements of her job. Several of them have said if they don’t get the salary boost we normally give to routine travelers, they don’t want to travel.

I think I should tell her travel is a nonnegotiable and offer to return her to her previous position and salary if she cannot or will not accept the responsibilities of the new position. My boss thinks that once she’s invoked “religious preference,” our hands are tied, but agrees that it’s becoming increasingly difficult to try to accommodate inability to travel, whether locally or overnight. What are our options here?

I think you need an employment lawyer to guide you through this, so I talked to two on your behalf.

First, a warning: I’m going highly legal with this answer, because the law is ultimately the thing that’s going to determine how you should handle this.

Also, some brief background on U.S. law on religious accommodations at work: Under Title VII of the Civil Rights Act of 1964, which applies to employers with 15 employees or more, if an employee asks her employer to accommodate a sincerely held religious belief, the employer must attempt to accommodate that request, if it can do so without “undue hardship.”

But your situation is sticky for a number of reasons, so let’s turn to the lawyers.

The first employment lawyer, who’s a regular commenter here, said this:

This is very detail-based and in real life, it would require hours of discussion and research to know. All we can do is to guess. To get an idea of what we’re dealing with, look here.

My feeling is that this is not actually a religious accommodation, but you need to be careful. You should consider talking to a local attorney, because you’ll be pushing back on an accommodation claim and that always carries a degree of risk.

That said, I would not tolerate this. There are no specifics here, but “listening to your husband” is unlikely to be viable: obviously you don’t have to give a third party that much control over one of your employees. (Lucky for you, by the way. “My religion prevents travel” would be harder to deal with than “my religion says husband is boss, and he says no travel.” Usually the test involves a “sincerely held religious belief,” and typically those don’t change at the whim of a spouse.)

My approach would be that when you hired her, there was an expectation that she would have to get from point A to point B. She needs to be able to do that. If it wasn’t in the written description but has effectively been required forever, change the description. You gave her a promotion that requires travel, so take the promotion away. This is what I would say verbally.

In writing, I would be a lot more cautious with my wording. I would lay out the test for religious accommodations, how to engage in the interactive process. How to work with the employee to find another suitable position, etc. Then I would work with her, and the expected result would be that she ends up giving up the manager position. Remember, you don’t have to accommodate everything.

Regarding the “When he arrives to pick her up, which is early every day, she gets really antsy until she’s released to leave because she can see his car from her desk window,” I would not tolerate that. “When your husband arrives early you act unprofessional and antsy. This is not acceptable. It is no different from any employee who checks out before the work day is over and it needs to stop.”

Also, on a verbal basis you might want to consider a domestic violence referral or applicable state leave laws because this level of control is, to put it mildly, unusual.

I also talked with Bob Cooper of law firm Buchalter. His take:

There are really two questions at issue here: (1) Is the employee’s request based upon a sincerely held “religious” belief if it based solely upon her husband’s religious or moral beliefs? And (2) If so, is the employer left without a remedy other than to suck it up and pay the employee for travel she now refuses to perform?

The first question is a more difficult one, since it is not clear that the husband’s preference that his wife refrain from all travel or from driving a car to perform her duties stem from actual, sincerely held religious beliefs … Although it may be tempting to disregard the husband’s beliefs and the employee’s belief that she must obey him as nothing more than sexism, the law is now so broad and murky that challenging the authenticity of these things as “sincerely held religious beliefs” is fraught with peril.

But the answer to the second question provides the remedy to this situation. Accommodating the employee’s self-imposed travel ban is one thing, but paying her for work that she refuses to perform is quite another. Whether it means returning her to her former position, or paying her less since she is no longer performing the essential duties of the position she accepted, religious conviction does not entitle employees to a windfall for work they refuse to perform. It might be better to pay the salary difference to those employees willing to travel.

I asked Bob whether the fact that the travel is only one overnight a few times a year might indicate that it’s not what the law would consider an essential function of the position, and thus if legally it wouldn’t be considered an undue hardship for the employer to accommodate the request. Also, more broadly, isn’t this giving her husband unacceptably broad control over how the employer is able to manage this employee and assign work to her? His response:

If the travel is only one overnight a few times a year, you are correct that there is a good argument that it is not an “essential” function of the position, or at least one that can’t be easily accommodated. That is why the preference would be to keep her in the promoted position, accommodate her professed religious belief not to travel, but also determine whether the position being performed without traveling merits less pay, since other employees are forced to pick up the slack.

Secondly, you are also correct that there is a concern in giving the employee’s husband too much say over how the employer chooses to conduct its own business, simply because his wife is an employee. You could stand firm on this and fight this battle, and potentially win it. But given the morass that is our federal law on this subject, I would advise to reach for the practical solution and determine whether the position merits less pay if it does not include travel. This way, the employer is still dictating its own business affairs, but remains in a legally unassailable position.

So, there you have it, letter-writer. But this is just to get you started. These lawyers are not your lawyers, and you’re going to need one of your own to guide you through this.

my employee is refusing to travel because her husband said she can’t was originally published by Alison Green on Ask a Manager.

Read the whole story
14 hours ago
Melbourne, Australia
Share this story

Bash quirks


Yesterday I was talking to some friends about Bash and I realized that, even though I’ve been using Bash for more than 10 years now there are still a few basic quirks about it that are not totally obvious to me. So as usual I thought I’d write a blog post.

We’ll cover

  • some bash basics (“how do you write a for loop”)
  • quirky things (“always quote your bash variables”)
  • and bash scripting safety tips (“always use set -u)

If you write shell scripts and you don’t read anything else in this post, you should know that there is a shell script linter called shellcheck. Use it to make your shell scripts better!

We ’re going to talk about bash like it’s a programming language, because, well, it is. The goal of this post really is not to go into details of bash programming. I do not do complicated programming in bash and do not really plan to learn how to. But after thinking about it a bit today, I think it’s useful to explicitly write down some of the basics of the bash programming language. And some things about the bash programming languages are quite different from other programming languages I use!

I really thought I knew this stuff already but I learned a couple things by writing this post so maybe you will too.

Variable assignment

In bash variable assignment looks like this:


and you reference variables with $VARIABLE. It’s very important that you don’t put spaces around the = sign – VARIABLE= 2, VARIABLE = 2, and VARIABLE =2 are not syntax errors, but will all do different unwanted things (like try to run a program called VARIABLE= with the argument 2).

Bash variables don’t need to be all-caps but they usually are.

Most bash variables you’ll use are strings. There are also some array variables in bash but I don’t really understand those.

global, local & environment variables

Next, Bash has 3 kinds of variables. The kind I usually think of first (and probably use the most often) are environment variables.

Every process on Linux actually has environment variables (you can run env to see what variables are currently set), but in Bash they’re much more easily accessible. To see the environment variable called MYVAR you can run.

echo "$MYVAR"

To set an environment variable, you need to use the export keyword:

export MYVAR=2

The next kind of variable is the global variable. You assign these just like we described up above.


They behave like global variables in any other programming language.

There are also local variables, which are scoped to only exist inside a bash function. I basically never use functions so (unlike in literally every other programming language I write in) I have never used local variables.

for loops

Here’s how I write for loops in bash. This loop prints the numbers from 1 to 10.

for i in `seq 1 10` # you can use {1..10} instead of `seq 1 10` 
 echo "$i"

If you want to write this loop on one line it looks like this:

for i in `seq 1 10`; do echo $i; done

I find this impossible to remember (how are you supposed to remember that there’s a semicolon after seq 1 10 but none after do?) so I don’t try to remember that.

You can also write while loops but I never do that.

The cool thing about this is that you can iterate over the output of another command. seq 1 10 prints the numbers from 1 to 10 (one per line), and this for loop is just taking that output and iterating over it. I use this a fair amount.

You can interpolate command output with either backticks or $().

# or 

if statements

If statements in bash are pretty annoying to remember how to do. You have to put in these square brackets, and there have to be spaces around the square brackets otherwise it doesn’t work. [[ and [ square brackets (double/single) both work but [[ is better because it works better when you’re combining two checks (like x=y && a=b).

if [[ "vulture" = "panda" ]]; then
 echo expression evaluated as true
 echo expression evaluated as false

Also, you can check for things like “this file exists”, “this directory exists”, etc. For example you can check whether the file /tmp/awesome.txt exists like this:

If [[ -e /tmp/awesome.txt ]]; then
  echo "awesome"

This is sometimes useful but I have to look up the syntax every single time.

If you want to try out conditions from the command line you can use the test command, like test -e /tmp/awesome.txt. It’ll return 0 for success, and an error return code otherwise.

always quote your variables

Another bash trick: never use a variable without quoting it. Here, look at this totally reasonable-looking shell script:

X="i am awesome"
Y="i are awesome"
if [ $X = $Y ]; then
 echo awesome

If you try to run this script, you will get the incomprehensible error message line 3: [: too many arguments. What?

Bash interprets this if statement as if [ i am awesome == i are awesome], which doesn’t really make sense because there are 6 strings (i, am, awesome, i, are, awesome). The correct way to write this is

X="i am awesome"
Y="i are awesome"
if [ "$X" = "$Y" ]; then # i put quotes because i know bash will betray me otherwise
 echo awesome

There are cases where it’s okay to just use $X instead of “$X”, but can you really keep track of when it’s okay and when it’s not okay? I sure can’t. Always quote your bash variables and you’ll be happier.

return codes and &&

Every Unix program has a “return code” which is an integer from 0 to 127. 0 means success, everything else means failure. This is relevant in bash because: sometimes I run a program from the command line and want to only run a second program if the first one succeeded.

You can do that with &&!

For example: create_user && make_home_directory. This will run create_user, check the return code, and then run make_home_directory only if the return code is 0.

This is different from create_user; make_home_directory which will run make_home_directory no matter what the return code of create_user is

background processes

I’m not going to say much about job control here but: in bash you can start a background process like this

long_running_command &

If you later have regrets about backgrounding the process and want to bring it back to the foreground, you can do that with fg. If there’s more than one of those processes, you can see them all with jobs. For some reason fg takes a “job ID” (which is what jobs prints) instead of a PID. Who knows. Bash.

Speaking of having regrets – if you accidentally start a process in the wrong terminal, Nelson Elhage has a cool project called reptyr that can save your process and move it into a screen session or something.

Be safe: set -e

When I write programs, usually I make mistakes. In most programming languages I use, when something goes horribly wrong the program will exit and tell me what went wrong.

In a bash script, you are usually running a lot of programs. Sometimes those programs will exit with a failure return code. By default, when a program fails, Bash will just keep running.

For example, in this script Python will fail (because the file I’m trying run doesn’t exist) and then it’ll happily continue and print “done”.

echo "done"

This is almost never what I want – if one of the programs in my script fails, I do not want it to just merrily keep going and do possibly undefined / questionable things! That is terrifying. set -e will make the script stop and hopefully prevent any damage. Here’s the safer version of that

set -e # put this at the beginning of your file

echo "done"

be safer: use set -u

In most programming languages I use, I get an error if I try to use an unset variable. Not in Bash! By default, unset variables are just evaluated as if they were the empty string. The result of this is

rm -rf "$DIRECTORY/*" 

will actually run rm -rf /* if $DIRECTORY is unset. If you use set -u bash will stop and fail if you try to use an unset variable.

debug: use set -x

set -x will make bash print out every command it runs before running it. This is really useful for debugging.

You can see all the other bash options you can set with set -o.

A lot of shell scripts I see people using in practice start with set -eu or set -eux. Safety!

lint your bash scripts with shellcheck!

Very recently I learned that there is a bash linter to help detect all these weird quirks and more!! It ‘ s called shellcheck and you can install it with apt-get install shellcheck.

Also it has a website! There is an example so can see the kind of errors it tells you about. It’s pretty awesome and I’m excited about trying it out.

Shellcheck knows about way way more bash scripting best practices than I do :). When looking at the examples I was like “wow, that makes sense but I would have never thought of that”.

There’s also a shell formatter called shfmt which seems useful:

bash is weird but it’s possible to remember some of the quirks

I think those are all the basic bash quirks I know! I suppose it is possible to rant about how bash is a Terrible Programming Language that you shouldn’t be using and why don’t we have a shell programming language that is less confusing, but it doesn’t bother me too much.

I just try to not write very complicated bash scripts, stick to some of the best practices here, and don’t worry too much about it. And it’s kind of interesting to learn about the weird quirks, anyway!

(if we’re talking about alternative shells, though – the shell I actually use day to day is fish. Fish is wonderful and I love it. But I still generally write shell scripts in bash.)

thanks to Mat, Marina, Kamal, Geoffrey, and Iain for talking about Bash with me!

Read the whole story
1 day ago
Melbourne, Australia
Share this story

Four short links: 22 March 2017

1 Comment

W3C Sucks, 2038 Ahoy, Swagger 3.0, and Javascript Bundling

  1. W3C Enabling Suing Researchers (BoingBoing) -- your periodic reminder that the W3C is captured by the enemies of open.
  2. 2038 Just 21 Years Away (LWN) -- an update on work to ease the 2038 problem. 2038 is my retirement insurance policy. [T]he point in early 2038 when 32-bit time_t values can no longer represent times correctly is now less than 21 years away. That may seem like a long time, but the relatively long life cycle of many embedded systems means that some systems deployed today will still be in service when that deadline hits.
  3. Visual Guide to What's New in Swagger 3.0 -- Swagger is a sweet way to define and document an API. I do like the side-by-side diffs showing old and new ways to do things, as a good way to communicate changes.
  4. Getting Started with Javascript Bundling and Webpack (YouTube) -- In this talk from nz.js(con), Tanya Grey teaches basic bundling, and this functions as a good walk through the mysterious world of Javascript tooling ... all those things you need to Do The Javascripts Goodly, those packages with names like "grunt," "gulp," and "browserify."

Continue reading Four short links: 22 March 2017.

Read the whole story
4 days ago
A headline like "2038 Just 21 Years Away" is why I love working in tech.
Melbourne, Australia
Share this story

the things you don’t know about work when you’re early in your career

1 Share

Last week, I asked what misconceptions you had when you were new to the work world, and what misconceptions you’ve seen from junior people around you. There were loads of insightful comments, and here are 15 of my favorites.

1. “When I was new to the working world, I thought that my boss knew everything about my work situation, and that if something was wrong or making me unhappy my boss would notice and fix it. If something didn’t get fixed, I assumed that the boss knew and had decided not to do anything about it. I know now that I’m the only person who’s fully immersed in my own day-to-day work, and I have to speak up when I want my boss to fix something (although it’s still difficult to do in practice).”

2. “I would say the biggest misconception I had is about how much people care about ‘who is to blame.’ In some situations, where something dramatically goes wrong, leadership might take root-cause analysis very seriously and pinpointing who did what wrong and when might matter.

In most everyday situations managers/leaders are far more interested in how you plan to fix the issue vs. who was responsible for causing it. That may mean that, yes, you will sometimes get poked in the eye for failures that are completely outside of your control. But that’s better than the black eye you will get from trying to explain (in detail) how the issue actually originated with someone else.”

3. “My biggest misconception about the workplace was that the people in charge will have everything together and really know what they’re doing. The more I work, the more I realize that just because you’ve got a fancy title, doesn’t mean you know what you’re talking about.”

4. “A complete lack of processes around you is very likely to hurt you. To explain: it’s good and useful to be able to be spontaneous and figure things out on the fly if there is an emergency. If that is how the day-to-day operations are run, you have a problem, because you won’t have enough space for personal growth – you’re likely to constantly be dropping long term projects at the last minute to fix the immediate stuff. i used to feel very important, until I realized I was stuck because I could never focus on anything long term.”

5. “I’ve spent 8+ years working with entry level customer service reps and innovation was a big focus for me with a number of the teams I’ve worked with. There were two misconceptions I saw A LOT of from newer employees (and honestly, even some who’d been around for a while):

* If a process or tool doesn’t work the way an employee thinks it should, it must be broken and in need of fixing. In a lot of situations where this came up, the employee didn’t have (and didn’t seek out) any background on why we did things the way we did, and just assumed management must be idiots. In reality, there were nearly always valid (and sometimes legal / regulatory) reasons why things worked the way they did. I was always happy to help investigate the why, but I saw a lot of generally good ideas go nowhere because the employee did no research and pitched the idea as if we were all silly for not having thought of it.

* If I see something I perceive to be a problem and report it, my work is done and someone else will fix it. This was especially egregious when the ‘problem’ was nebulously defined and limited to one or two people with no supporting data, but would require a lot of time / effort / money to ‘fix.’

It can be incredibly helpful to have newer eyes help you spot the opportunities in your processes and tools, and come up with innovative solutions the people entrenched in the processes and tools might not think of. But it’s important for employees to do their research, understand the background, and have a workable solution, which is something not everyone knows how to do when they’re new. Being innovative is more than just ‘having brilliant ideas,’ it’s doing the work to make them feasible, too.”

6. “I recently gave my notice, and I’m coming to realize that something that seems SO HUGE to me (quitting my first professional job) is just normal ‘doing business’ to everybody else. It’s a little more complicated than that, but I really expected my resignation to be much more drama filled than it actually was.”

7. “I think my biggest misconception was that I’d get regular feedback and plenty of it, and that I’d know where I stood at all times. As a corollary, I assumed that if anyone had a problem with my work, they would tell me and I would have the ability and opportunity to correct it. So if no one was actually complaining about me, I figured, ‘Hey, I’m doing great! If I wasn’t, someone would have told me.’

I think this was probably a carryover from both the school environment (where you get report cards telling you how you’re doing and you get your papers back with lots of comments on them) and my earliest jobs (where I was a teenager and worked for small local businesses, and where my supervisors weren’t hesitant to both praise and correct me as needed, and where most of my tasks could be pretty accurately described as pass/fail). Also, in both of those settings, corrections were confined to the work product itself and not to areas like attitude, affect, or how others perceived me.”

8. “My biggest misconception (and one I still struggle with sometimes even though I’ve identified it) is that you really don’t have to be ‘yourself’ at work. Many times, being professional means doing something or acting in a way that I would have that I would have thought of as fake or disingenuous when I was in school. Figuring out that what’s really important is being professional (like being polite and maintaining a pleasant working relationship with a coworker that you absolutely, positively can’t freaking stand and want to strangle on a daily basis) was a crazy wake up call.

My internal mantra is ‘These people are not your friends, they are just your coworkers. It’s not being fake, it’s called being professional. You DO NOT have to like them. You just have to act like you don’t want to murder them.'”

9. “I wish I’d known that it was okay to ask questions and that no one cared how smart I appeared to be — they cared that I could do my dang job and think on my feet. This one is a HUGE holdover from grad school in the humanities, where if you have to ask, you’re too dumb to be there. I am now really embarrassed of how much time I wasted faffing about trying to quietly figure things out instead of letting on that I didn’t know something that was (in hindsight) completely reasonable not to know.

I still struggle with this daily and am always impressed when a smart, competent coworker asks for clarification or says ‘wait, I don’t understand X.’ I always have this moment of shock, like, ‘oh, right! you can DO that!'”

10. “Beware ‘venting’ with your coworkers. It feels like you’re blowing off steam and that it’s helping, but more often than not, you’re just stewing in your misery and it’s making you more miserable. It will change how you see things. A groupthink can start to take hold where nobody is willing to give management benefit of the doubt because the group’s default reaction to everything is mistrust and skepticism, and it starts to feel like you’d be violating a group norm or shunned by your coworkers if you expressed support or optimism about something. In complaining so much about the problems, you end up ensuring the problems don’t get resolved because negativity torpedoes all attempts at change.

Nobody perfectly avoids venting all the time, but try to keep the number of times you complain about something without proposing a solution to a minimum. If you look at your IM history with a coworker and it’s one gripe after another that neither of you have ever brought to management for resolution, you are only furthering your own unhappiness even if it feels cathartic in the moment.”

11. “One of the greatest pieces of advice I ran across on here was to figure out which *tasks* you like, and which you don’t. Rather than think in terms of believing that the work is important and noble. Jobs are made up of tasks, and if you love or hate detail work, or talking to people on the phone, or writing, then having a lot of it or almost none will be a big factor in how you feel at the end of the day.”

12. “I underestimated how important it is for my co-workers to announce whether they are feeling hot or cold at different points during the day. Rookie mistake.”

13. “For me, it took a long time to realize that my criticism of the boss was problematic and short sighted. I always secretly suspected I was sooooo much smarter than he or she, that I saw the obvious answers to all the tough problems, and that the boss’s laziness or stupidity is what kept them from acting. ‘If I were the boss, I could easily fix this by doing A, B or C…’ was always floating around in my head.

Now that I AM the boss? I recognize how many tough decisions there are every day where making everyone happy is utterly impossible … and how much planning and thoughtful work can backfire due to things like bad timing, losing an important staff member, shifts in federal and state budgets, the overall political climate or even just bad luck. What I also never considered: all problems I didn’t see, because my ‘awful’ boss addressed them before they even became problems. Many times the boss was doing solid work that I didn’t understand or see as valuable because I didn’t understand the implications – I only saw the small fraction of the work that did go wrong, and scoffed about their obvious incompetence. The sample size for my observations, as it were, was utterly skewed to only notice the mistakes. I have a lot more empathy and respect for my old bosses today than I did back then.”

14. “You’re going to have to take enough initiative to get the information and things you need. A lot of things won’t be spelled out for you – it’s on you to ask for clarification, find the information you need, etc. You might not get multiple reminders that something important is happening – you might just get a single notification and you need to pay attention to it and remind yourself.”

15. “One of my early career mistakes was that I let my job at the time (daycare) be a bigger part of my identity/life than it needed to be. One very stressful day I got into a little spat with a co-worker/close friend. I went outside, sat down, and started crying. Another co-worker saw me crying, sat down and put her arm around me, and told me, this is your job, not your life. She had come to this country from Belarus for a better life for her kids. She was making about minimum wage working an assistant teacher position here, when she was qualified to be a center director back home. She helped me put the situation in perspective. Of course, everything blew over and work/my friendship was back to normal in an hour. Now I approach work as a means to an end. Ideally, I enjoy it and find meaning in it. But at the end of the day, it’s just my job, not my life.”

the things you don’t know about work when you’re early in your career was originally published by Alison Green on Ask a Manager.

Read the whole story
4 days ago
Melbourne, Australia
Share this story

My Weekend Parody

1 Share

Since this is my trailer week, how about a trailer for a fake movie I would really watch? I don’t know how this escaped me the first time around. But now that another one of these in in the theaters, why not? As fun as it is to poke fun at lesbian stereotypes, the deleted scene is actually my favorite. Though, come on gay ladies - who flushes a tampon? Happy weekend, all.

Read the whole story
10 days ago
Melbourne, Australia
Share this story

ask the readers: misconceptions about work when you’re early in your career

1 Share

On a post last week, commenters were talking about misconceptions about work that people often have early in their careers. For example, people new to the work world are often unsure or confused about:

* what it really means when people say you should show initiative (and that some types of initiative are okay when you’re senior and not at all okay when you’re junior, and some are never okay)
* how to balance showing enthusiasm and initiative with not being annoying
* how formally people at work interact with each other (with misconceptions on both ends of the spectrum)
* what a conversation with your boss should be like
* how much effort matters versus results
* how to figure out how much time to spend on things
* and so much more

So. What misconceptions did you have about work when you were new to working? And how did you figure things out? What misconceptions have you seen from junior people around you?

ask the readers: misconceptions about work when you’re early in your career was originally published by Alison Green on Ask a Manager.

Read the whole story
10 days ago
Melbourne, Australia
Share this story
Next Page of Stories