Alison Rowland

A bit of personal news: I’m starting on 10/15 as a Principal Software Engineer with StitchFix! I am going to be helping build up a newer function within the company which touches on many aspects of the business, including data science, marketing and warehousing, so I am very excited. I’ll be partnered with great folks running the business side of things, while helping build up a strong engineering team. It’s also fully remote. It’s a win, from my perspective, and I hope it is from theirs, too!

I have so many thoughts about my recent, four-month-long job search and career things that I would like to write about, such as how much longer it takes to find the right fit when you’re mid-career; career progression and sustainability; career hedges and ageism in tech; how the industry treats job applicants; interviewing well; title inflation and how to deal with it; the distributed worker trend among big tech startups; how interviewing practices affect diverse applications differently; the decision to move back to IC work after management; and what it looks like when companies understand high-level IC work. Whew! That is a lot, and if I wait until I can parse out my thoughts on all that, I’ll never get this announcement out. But for now, what I will say is that StitchFix had by far the most thoughtful, well put together interview process of any company I interviewed with. The problems stemmed from their real work, and the people were kind and genuine. They were the only company where every single interview had me coming away feeling better from the last, rather than beaten down. I’m still on the outside looking in, but I think they have created a truly awesome culture. And that’s what makes me so, so excited to be joining their team.

It’s fairly standard for Scrum ceremonies to be arranged according to the work week. Sprint Planning and Kickoff on Mondays, grooming sessions in the middle of the week, Sprint Demo and Retrospective on Friday. But is this the best sprint alignment for your team?

When planning team sprint ceremonies, take a lesson from vacationing on the beach. What do we do at the beach? There are two types of vacationers: outing goers and beach-sitters. I’ll speak to the latter, since that’s what I know best. Beach-sitters, as we are in my family, go to the beach to sit, swim, and snack. A typical daily schedule looks like the following:

• Wake late
• Don a swimsuit
• Sit on the beach, swim, and snack until late afternoon
• Come in, shower
• Get dressed in clean clothes for the evening
• Eat a leisurely dinner
• Go to bed

Notice that beach days are inverted compared to a typical personal routine of showering and dressing in the morning. If the beach goer puts on fresh clothes every morning and fresh clothes after showering before dinner in the evening, they will go through at least two outfits daily. Not very efficient! Fresh clothes donned each evening, and the evening’s slightly-worn clothes donned the next morning make for a much more practical routine. When in Rome…

So how does this relate to sprint teams? There are many reasons why one might want to start and stop sprints on days other than Monday and Friday. These reasons can be roughly bucketed into the following categories:

1. fixed concerns: e.g. weekends and holidays
2. variable, but semi-predictable concerns: e.g. PTO, WFH, all-hands
3. stakeholder concerns: e.g. standing executive meetings and availability
4. collaborative concerns: e.g. adjacent team sprints
5. continuity concerns: e.g. at-work time to think and plan

Having identified these categories, how do they apply? Fixed, variable-but-predictable and continuity concerns are generally good reasons to not schedule major sprint ceremonies for Monday and Friday, while stakeholder concerns will vary according to the company and executive context. Collaborative concerns can be more complicated to address. For example, say you have two teams: design and engineering, working on the same product or feature. Design has to be a step ahead of engineering, so when engineers kick off implementing a feature, there already exist designs ready to be translated into code. It’s also common for collaborators to be present at their sibling team kick-offs or demos, so it’s good to stagger their sprints to avoid standing conflicts.

Continuity concerns are also more complex. Look for a follow-up article regarding Sprint Gaps, which will talk about how to give your team time to recover from one sprint and be ready to thoughtfully start the next. Ending one sprint on a Friday and starting the next on a Monday can be a great way to lose continuity, flying by the seat of your pants from sprint to sprint.

That is a lot to weigh, and good stewardship of a project team is no trip to the beach. There are pros and cons to any sprint alignment. However, decision-making grounded in the values of per-sprint predictability, sprint-to-sprint continuity, and cross-team/stakeholder collaboration should result in a workable, or better yet an optimal, solution. But if you need a tangible reminder of how to flex your schedule to fit the context, I recommend booking a flight to your favorite tropical destination.

I’m redoing my blog from Jekyll to WordPress. Here we go!

Earlier today, I installed Solr on top of OpenJDK 1.6, running Tomcat 6. That went just fine, but I ran into trouble later, when I tried to install OpenGrok, which requires JDK 1.7. When I ran ant, I got this error:

-do-compile:
[javac] Compiling 245 source files to /usr/local/src/OpenGrok/build/classes
[javac] javac: invalid target release: 1.7

This was strange, since at the suggestion of this StackOverflow answer, I put this line after my opening <project> tag of build.xml

And the result was that I was already running 1.7. After a lot of trial and error, I got it to work by running update-alternatives to officially set the java version to 1.7.

sudo update-alternatives --set java /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java

Hopefully this can help out some other Java sysadmin neophytes.

I’m currently configuring an Ubuntu server with an NVidia Tesla GPU unit.

In the interest of actually getting things done with it, we are going to try out the PyCUDA library.

The PyCUDA Installation Docs for Linux don’t refer to installation via pip, but I wanted to give it a try. It mostly went without a hitch, except for a couple of things.

You’ll need to make sure that the cuda bin directory is on the system path.

export PATH=/usr/local/cuda/bin:$PATH

Then you’ll need to install numpy, which also requires having Python’s dev package installed.

sudo apt-get install python-dev
pip install numpy

At this point, if you run

pip install pycuda

You will get an error:

In file included from src/cpp/cuda.cpp:1:0:
src/cpp/cuda.hpp:12:18: fatal error: cuda.h: No such file or directory
compilation terminated.

This had me confounded, partially due to pycuda’s frequent exhortations in the install logging to run the configure script and Ctrl-C if certain things weren’t what I wanted, etc. But most of the warnings were moot, since pip removes the build directory if you cancel the install (I’m sure there’s some way around this), blocking manual access to the configure script, and there did not seem to be a way to pass configure flags through pip (would also love to learn if you can do this). But then I found this little gem at the beginning of the Ubuntu-flavored install docs:

> You’ll need $CUDA_ROOT set to the root of the CUDA install directory

Set CUDA_ROOT and you should be good to go!

export CUDA_ROOT=/usr/local/cuda