The Gist

A generation that grew up with the internet has entered the workforce, and they’ve begun to make demands that some managers find uncomfortable. Millennials & Management addresses some of the generational disconnects between Baby Boomers/Generation X and the fresh faces of Generation Y.

My Opinion

The most difficult part of this book is coming to terms with the word millennial; a vague term used to describe those of us born anywhere between the early 80s and early 00s (Wikipedia agrees). The term encapsulates several distinct sets of young adults: those entering the workforce around the time the .com bubble burst; those entering the workforce post-9/11; and those still struggling to find jobs after entering the workforce in the currently receding recession. Fortunately, it does not generally include those whipper-snappers born with a cell phone in their hand.

From a series of surveys with millennials (1980-2000), Gen Xers (1960-1980), and Baby Boomers (1945-1960), the author finds that this generation has very different aspirations from their parents. Millennials saw their parents grow old slagging through a job they hated with the dream of a big fat pension waiting for them when they retire. Millennials were told they could achieve anything and would be rewarded for perfect attendence. Millennials want to live life to the fullest while they’re young and when they retire. Millennials think they’re entitled to work wherever they want whenever they want wearing whatever they want. Millennials are pretty much the reason that iPhones exist.

The author discusses her own company’s struggle to fit Generation Y into company culture. Her experiences arevery relevant and highly laudable, evolving from a crotchity old boss complaining about kids and their cell phones to an approachable, flexible manager who sits in the cube area with her employees and allows for remote work when appropriate. She describes how millennials want to be happy in their work, and thus always on the lookout for greener pastures. This causes a lot of turnover for younger employees who don’t believe they are living up to their full potential or don’t think they are being respected.

There is advice in this book for managing millennials mostly revolving around being more flexible for a modern electronic world. Being a part of Gen Y myself, I was doing a lot of mental head-nodding and “yeah, that’s how I want to be treated” during most chapters. However, there were a few areas where the author’s advice is essentially to pander to millennials, which I don’t necessarily agree with. There needs to be compromise and understanding on both sides every time.

The author also includes advice for millennials dealing with superiors and co-workers. Some of this advice is common sense and good manners, sometimes making it sound like it’s aimed towards snot-nosed kids; but generally the advice provided is valid and good to follow. I didn’t pick up any one-liners after reading this book, but I certainly found it helpful (and interesting) to see inside the heads of individuals with a Generation X or Boomer mindset. I think it will help me empathize with my more mature peers when discussing my career and ideas that are important in my working life.

Who Would Like This

It’s in the title. Millennials should be able to scrape some empathy out of this book for more mature generations, and maybe even for other millennials. Managers can also get an eye-opening view into how Generation Y thinks, especially managers having trouble relating to younger generations. Parents just don’t understand, after all. A good, short read for both sides of the equation.

Nine months ago I brought a team of 6 together to build a data analysis tool called Ollert. A few months later, I started working with SEP to find time to make Ollert better. Where do we stand today?

From a traffic perspective, we’re doing pretty well. The numbers are increasing steadily over time, as are the number of people who use the application on a near-daily basis. Although we have surpassed our modest initial goals, we would like to build up a larger audience in the coming months.

We’ve had about 1800 different users visit the site for a total of over 5000 pageviews. On average, users hit about 2 pages per visit and stay with us for almost 90 seconds at a time. About half of all traffic comes from social media such as Twitter, LinkedIn, and Reddit, but we’ve also seen some interesting traffic patterns come out of Trello, my blog, SEP Labs, and various other blogs.

Trello reached out to us a few months ago to congratulate us on making such a neat application using their API. They sent us some shirts and stickers for our trouble. It was an extremely satisfying moment.

On the technical side of things, we’ve made several changes to the application.

We removed the concept of “signing up” for Ollert, as it was the greatest cause of confusion on the site. I replaced it with a mechanism that “automatically” signs a user up when they connect to a Trello account using OAuth. This makes our lives easier because we don’t have to store passwords, and the lives of users easier because they don’t have to come up with and remember another password.

Every aspect of the site has been made faster. Server requests have been made faster by switching to unicorn and utilizing the “workers” feature. Trello API call times have been slashed - Board fetch time dropped from 1.8s to .18s, Label chart 17.6s down to .426s, WIP chart 18.2s to .221s, CFD 15s to 1s.

We added two highly-requested charts - the Burn Down and Burn Up. It takes a certain type of Trello board to make these useful, and I’m looking forward to finding someone one day who’s able to make good use of them.

We also improved the look of all pages (most notably the home page) with some help from SEP’s UX team.

Oh, and now it works significantly better on mobile.

What does the future hold for Ollert?

In the short term I’m looking to implement a Cycle Time chart and add in a baseline for the Burndown chart. Long-term is a little less clear, but we may have a sizable announcement soon.

The city is the original talent hub. Traditionally, those who ran the engines of capitalism thought: “Let’s gather a large numberof people in a small grographical are where they must live on top of each other in tight quarters, and we’ll be able to find plenty of able bodies to man our factories.” Most splendid, Sir Moneybags!

From the section titled “End of city monopoly”

The Gist

Remote by Jason Fried and David Hansson of BaseCamp (formerly 37signals), similarly to previous entry Rework, is a book that will surely resonate with most working Americans who despise commuting and the constant distraction of the modern office. Remote discusses the pros and cons of working remotely, with a bias towards the positive aspects.

My Opinion

I read this book in a day. I don’t mean a Saturday or a holiday of some kind (although it was Halloween, I suppose). I mean I read part of it in the morning, drove to the office, returned home in the afternoon, and finished it before dark. I love the authors' down-to-earth tone and I love the idea of telecommuting. There’s also lots of pictures. Yea, pictures!

Remote work is not a new concept, but the number of people choosing to telecommute has begun to dramatically increase. This is mostly because we all work with a digital wall in front of us all day called a computer, and many jobs don’t require direct contact with human beings the entire work-day. America seems to be coming to terms with the fact that our current corporate system is broken: the offices of 2014 are not the offices of the 1960s, but we still live in a world of endless meetings and sprawling cube farms.

Telecommuting opens up a world of possibilities. Obviously, a company offering remote positions will gain the opportunity to hire new talent from other cities, states, or even countries. Less obviously, current employees can be given the chance to be free from the shackles of a single office buildling in a single city. Instead of a company’s top talent leaving the company to go live in New Orleans instead of Chicago, the employee can choose to live wherever she wants and telecommute, keeping all the training and knowledge gained inside the company.

Co-working spaces are becoming much more prevalant in major cities across the US, and are a great home office replacement for those without a spare room. If you haven’t visited a local co-working space, I suggest you go visit one! Someone will gladly let you in for a tour and you can see what all the fuss is about. If you’re not into paying for an open-space membership, there are always coffee shops and libraries that are happy to house you on a daily basis.

The biggest downside to remote work seems to be in isolation: socializing becomes more of a hobby than a requirement. There may be chats, emails, and the occasional phone call to respond to throughout the day, but none of those can make up for face-time with other humans. Some individuals will have families to socialize with, but you can’t put all the burden on the people you love. Hobbies, meetups, and conferences would likely become much more important from a social perspective to an individual working remotely.

Who Would Like This

The modern workforce will eat this up. There is no way that millenials will put up with the archaic concept of 9-5 in the office. They (I suppose we, though sometimes it pains me to admit it) never take the status quo as a satisfactory answer.

I think that the blanket term “manager” would benefit from reading this book, but may be disgruntled by what they find inside. Handling people is not easy, and handling them remotely seems like an unsettling concept.

I despise estimating in hours. Hours are too granular. Hours are too difficult to distinguish from hours on a clock (they’re even spelled the same).

In any project where we work in hours, we always desparately task out stories in hours fill our capacity. Which is also measured in hours. We take people’s days off and we estimate that developers spend about ¾ of the day watching Youtube videos and reading Hacker News. So a developer works about 6 clock hours in a given day.

Then we start tasking out stories. We estimate that this task will take about 12 hours, this one about 8 hours, and we’ll top it all off with a task of about 4 hours for ad-hoc testing. All in all, this story is estimated to take exactly 24 hours.

Now we do some math. Obviously, since a developer can get 6 hours of work done in a day and this story will take 24 hours, the story will be done in exactly 4 development days, or exactly 3 real days. We watch our capacity (in hours) fill by 24 and note all the space that’s left.

Someone without reference to our developer-day-to-work-day comparison walks by. Excellent, it’ll be done in three days, you say? That fits the schedule perfectly, tell the client we’ll be done with that feature by Thursday. Let’s add some more to your backlog…

For all we know, this estimate may work out. However, from my experience, the 8 hour task and 12 hour task will probably spend about the same amount of time in development, taking anywhere from 1-3 days each. Fortunately, the “testing” task will only take about 30 minutes.

What’s wrong here?

Humans are bad at estimating. We become much worse at estimating when we start talking about knowledge work. I happen to believe we become even worse at estimating when we try to use time as a unit of measure. How long does it take you to get to work? I would say it takes me about 5 minutes. Google Maps tells me I would be lucky to get there in 10 without traffic. My estimation in minutes is bad, conflated by the monotony of performing a menial task over and over again.

When we have retros, we don’t discuss how incorrect our hourly measurements were. We have a hybrid system of estimating stories in points and tasks in hours. We discuss the discrepancy between estimated and actual story points instead, despite the disconnect between our task estimates and our story estimates. (Another reason we don’t discuss hour estimations at the retro is that it would take forever due to the high number of tasks and the granularity of hours (did this take one day or two, I can’t remember)).

Do I have a solution to this problem? Of course I do. Don’t use hours. Stick with points, and keep them as vague and hand-wavey as possible.

We often run into an issue of associating points with number of hours or days. “Well, a 3 takes us about a week and a 5 takes us about 2 weeks. This story seems like it’ll take about a week.”

Points do not translate directly to how long a story will take. Points do translate to how much work a story feels like relative to the stories which have come before it.

Eventually, you should have a big enough pile of 1s, 2s, 3s, and 5s that you can relate a new story to a previous story. This story feels like a 3, about as much work as that story where we had to herd those cats. This story feels like a 1, technically all I have to do is flip this boolean…

When starting a project, estimate stories but don’t try to estimate a capacity. Just see how many points you can get done in a sprint. Do it again for the second sprint. Keep doing it until your numbers balance out. This means that your estimates are becoming consistent and you’re getting over the new project hump. Now you can tell your manager that you should be able to get 20 points done in a sprint, because you’ve consistently bounced around that number the past few sprints.

Don’t get too hasty and start telling people that you should be able to do more points with each sprint. I hate to break it to you, but you’re not getting that much better each sprint. You need to adjust your point estimation to match your current competency level.

End rant. It’ll probably be a long time before we see the death of hourly estimations, especially with big-name tools like Rally and Visual Studio Online containing fields explicitly for that purpose. Just fight the good fight for now.

System tests: a boon to product verification, but also time taken away from raw development. System-level testing means bringing up the whole system and running through a set of steps to verify that the system is working properly on all levels.

We have lots of system tests on our project, some that check for the existence of UI elements, and some that verify that a user can go through the entire e-commerce process. Some of the tests require network access, so they take up to 3 or 4 minutes. I had gotten used to writing system tests with ruby and capybara, which I’ve always found straightforward and easy to write. But this current project is in ASP.NET MVC, which seems to have greatly complicated bringing up and automatically manipulating the system. Our current test suite takes over an hour to run and results in at least 10 consistently-failing tests (referred to as “flaky” for dignity’s sake).

Because of this, there has been talk about getting rid of the system tests.

Getting rid of system tests? Doesn’t this go against everything we believe in? Think of TDD! Think of the children! Think of acceptance criteria! Won’t somebody think of the children!

So I’ve been thinking: what is the purpose of system tests? The first thing that comes to mind is the obvious: to test the full stack. Often components work well individually but throw tantrums when forced to interact with the rest of the system.

Another obvious answer: system health. If the system tests are passing, then surely the site still works after my push! You did add a system test for that changeset, right?

I’m not satisfied with those answers. Those are great side effects to writing system tests, but they aren’t sustainable reasons. For their own devious reasons, someone can always delete a system test that would have broken with your code change. You can always write your system test steps poorly, resulting in incorrect (though passing) behavior.

The best reason for writing system tests is to find out what you’ve accomplished.

Sometimes when I finish coding a new feature, I ask myself “MY GOD WHAT HAVE I DONE.” There are unit tests in place, and they have great names like SetsIsValidToTrue and ReturnsSomethingThatsNotNull and DoesntCrashTheSystem, but they fail to tell me what just happened. So I switch context to the system tests. In writing a system test, I bring up the whole system, run through my Happy Path™ and my edge cases, and I can see precisely what I’ve done. I can watch my work succeed or fail. I can see when it takes way too many complicated page clicks to perform a task. I can see that when I click something too quickly the page fails to load. I can see that the URL is just plain weird. Most importantly, I can sit back and see it happening.

So I push my system test to the build server and it works fine until a few dozen other changesets go through on the same page and eventually the system test becomes flaky.

Where did we go wrong?

I have an idea on how to deal with this, but you’re probably not going to like it.

As soon as I push a system test, it becomes legacy. You are no longer allowed to edit this system test. If you are updating that feature, you are responsible to delete and potentially rewrite each relevant test. In doing this, you are now required to think about the way the whole system fits together every time you push a feature. System tests will become a picture frozen in time of the way the feature worked the last time it was worked on. System tests will no longer be a rolling history of what the system did, but an exact specification of what the system does. They become a piece of the development process to demonstrate the intended functionality of the feature.

In following this practice, we technically lose out on reusable system test code. I say good riddance, as testing code is the quickest part of any system to become bloated and convoluted. The loss in test creation speed could be worth the gain in developer knowledge of the intricacies of the system.