Onboarding

Prompt: Onboarding new teammates/myself 

Amanda Snyder: 

I’ve seen onboarding be most effective when everyone on the team helps to reach out. It’s too easy for a single person to forget to mention something, or for that person to become very busy and not have a time for an onboarding at the moment. When each team member takes a small part in helping out, then no single person gets labeled as ‘In Charge’ or ‘The Person to Ask’. This is important, because it sets the stage for teams where everyone does what needs to get done, and nobody waits for someone else to step up. It easier then one may think to get into the bad habits of ignoring easy wins because it’s ‘not our responsibility’, or ‘but so-and-so always handles that’. Onboarding should be approached the same way any part of the project is. If one person knows how to do everything and handles all the responsibility, the team won’t move forward if something should happen to them or if they get tied up. However, if the knowledge is a shared knowledge, and each person on the team is able to contribute to the onboarding, then smooth transitions are easy to make at any time. 

 

I’d be the first to admit that I have been guilty of this in the past. It is sometimes easier to just step and take care of everything that needs to be done in one fell swoop. However, I have also felt the pain of later on assuming that if I were not around, then others would pick up most of the onboarding efforts. It does not work this way. I didn’t put in the effort to spread the knowledge and create the expectation that everyone was to help in the onboarding. It’s just as important that no one team member take too much charge, as it is for everyone to step up and help. Watch yourself to see if you are always the one to introduce someone to a project, and if so, make sure to ask others to help out while you can support the learning. Don’t wait till schedules fill up, time pressure increases, or you’re rolling off, and assume that others will know what needs to be done.  

Linda Goldstein:

I believe that the most essential onboarding step is to immediately be introduced to every one of your new teammates; it is easy to accidentally ignore and offend even the most kindly and professional new teammates while you’re still gaping at this new space which you will be spending so much time in. 

One of the most essential early onboarding steps is to get the new teammate all of the user access credentials that are needed to check email, push code, deploy, view+edit cards, etc. Forgetting or postponing this makes everything else into a ridiculous nuisance.

On the projects that I have been on, the same few steps always apply to solo developer onboarding. This is the stuff that I personally have to do before I can really “get” the code. Usually it is best to do this after hours or in gap time when you are not pairing.

• In 1-2 sentences, what does the project do, and why? Be able to explain this from memory.
• Clone the codebase as early as possible to a computer that you have access to after hours.
• Look thoroughly at the build script: what artifacts does it create? Can it generate a database, upload artifacts, deploy? Where does it get its dependencies from?
• Start from the main() (or index.html, or equivalent) of the codebase- follow one possible usage path all the way from the UI down to the lowest code layer you can find. (Repeat this several times)
• (If there is a database) Connect to the database. Look at every table. Look at the dependencies between tables. If you find any stored procedures, look up where they are called in the code. 
• Fun activity: find a well-tested class. Delete the class and re-implement it using only the tests as a guide. When all the tests pass, compare your code to the original.

Aubrey:

 

To introduce people to the new domain, I’ve seen a mix of personal browsing-the-code, guided walk-throughs, and general overview sessions take place.  In the last two cases, I think this has been most effective when the person being onboarded has contact and explanations from more than one source.  Just as each person has a certain learning style, each teacher has a certain style in conveying important information, and will focus on different aspects, even when giving a general overview.  

As far as resources to help onboarding, use of collaborative online tools to hold logins/ credentials, relevant documents to peruse, and contact information for talking to people with specific knowledge is great.  The tools I am most fond of, however, include Trello, a collaborative card-wall system I use to track things I’ve learned, problems I faced and may face again, tools I want to use that I’ve seen others using, and handy things I should remember.  As well, my very favorite tool that I think helps most with onboarding is literally a map of the land, a layout of how everything connects.  With the whole project structure laid out, it is easier to understand how each part interfaces with the whole, and domain-specific knowledge becomes easier to apply.  

Nikki:

I worked with a TWer that rolled on to our project and complained that we had not onboarded him thoroughly enough. Then when we got new people later on, he was very good at making sure that he took them through the system quite thoroughly so that they were in a better position than he had been. I was grateful that he improved the system, however my thoughts from this were (1) maybe he should have been asking more questions and (2) I don’t think that he ever succeeded in communicating about the culture - this could only be learned over time by just hanging around with the project members.

When I rolled on to my last project I paired with other BAs to test their stories, follow the steps that they had written in the acceptance criteria, and follow the steps in the automated tests. These things got me up to speed extremely quickly; it was a useful feedback for the stories as we discovered some things that had been missed; and I got to know the culture and the style of analysis that the team was following. BA pairing is good!

I would ask everyone to be able to quote the elevator pitch. Which means that we would have to have one in the first place. It would be nice if this was placed in the good news about delivery emails too!

Sarah:

So far the most effective onboarding I have seen is a quick introduction to the purpose of the project (elevator pitch style) and then introductions to everyone on the team along with what they do. After that, for devs, jumping in and pairing with people has worked out well. Although, so far the difference between whether or not they should be rotated or stay on the same story seems to have some contention. Thus far I would argue that rotating them through all the devs is a bonus since they see the system from many points of views as well as how their new team members work. By rotating them on to different stories, they should also be exposed to other team members’ work (BAs and QAs). Team activities during this initial period are also a huge boost for a good introduction to the team’s culture.

This all said, I believe the most important part is the quick explanation as to why the team is there. The rest can be picked up from being around and asking questions, but if the team as a whole does not have the same idea of purpose, it is easy to come off with the wrong impression.

Rebecca Sliter:

My thought process tends to mimic concentric circles, so I'll start with a microexample before expanding on the process :)

"What's your experience with [technology X]?" is  the best thing I've learned to ask my pairs. On my first long-running project, I considered myself such a n00b that I figured whoever I was pairing with had more experience with the task at hand than I. Not so. It's always good to figure out where your pair's coming from.

Asking, "what would you most like to improve?" and, of yourself, "what should *I* improve?" are questions I've been using lately. It gives the askee (a teammate or yourself) ownership of the improvement. Generally speaking, we do better work when we're personally motivated to do so.

I often try to gain confidence by understanding a single part of my project, be it a functional area of the codebase or the team dynamic. Once I've ramped myself up to that I can onboard others as well. Pay it forward!

The ability to teach the team something is a great indicator of onboarding progress. Sometimes this means speaking up during a retrospective to solve an issue on the team. Other times this could be holding a lunch and learn, driving a refactoring, or helping the team get up to speed with a new tool.

These are vague, less-technical suggestions, mostly because I've realized that learning how to learn is the most difficult part of starting a project, a new language, or a workflow. The strategies I've mentioned help me to focus my approach to self-learning and/or onboarding a teammate.

Mangalam Nandakumar:

Joining a team as a new member especially when the rest of the team has been working together for a while, can be quite challenging !! For a business analyst this can be a little more challenging having to understand the depth and breadth of a project in a rather short time, and with limited opportunity to pair !! 

The first thing I tell myself when joining a team is to not feel left out, and to try to not be daunted by all the jargons and friendly banter that the rest of team shares ! I keep reminding myself that it takes time to fit in (particularly if you are an introvert) and to just wait it out ! 

The next thing I do is to set realistic expectations for myself - if this is a long running project that I have just joined - I don't expect to be up and running in a week's time ! So I have conversations with the project manager, client principal (or anyone who sets expectations with the client about when I can  be billable) to set this straight and to get an idea of what the landscape looks like. 

As a business analyst probably replacing a BA already on the team, these conversations become very important - since they set the pace for how the transition and onboarding happen. 

All things being sorted out, I usually start by testing what has already been developed. This gives me a good wide perspective of what the project does, gives me time to try and play with some functionality, make notes and observations, and maybe even uncover some defects ! 

I take this as a foundation for further conversations and delve into an 'inquiry based learning' mode where I quickly gather information about what I need to know rather than learning everything about the project - and that speeds up my learning curve! 

The next best thing to testing, is to pair with the BA on writing some stories - I would like to jump into this as early as possible - since this helps me learn about what processes are followed on the team - how is the story structured? How involved is the client during this phase? Who in the team is involved in story kick-offs, etc. This again helps me ease into the team, and build relationships ! 

But there will be always be that one day, when teammates and the client will begin to trust you !!! That is the day you know you have been ‘immersed’ ! :) 

Abby Bangser:

While I do not think that there is a definitive best way to onboard, there are two topics that I have identified so far as important.

The first is to set expectations. While you may know that the new person coming on is supposed to be rewriting your build pipeline by week 2, they may not realize that expectation. Similarly if you are the person rolling on and you know that this is a new technology you are working with, try to identify timelines with your team for when you will be self-sufficient. This can get tricky if you are rolling on in a leadership position, but it if its possible it would allow a lot more free communication.

The second topic is that of fitting in quickly. This can be as small as following the trends for lunch or being assigned a desk, but can be as big as getting access to the code base and actually throwing points during an estimation. Often times people will delay getting code access since there is pairing anyways, or hold off on estimations because they do not yet know the process and standards. This is valid, but can also set up an even bigger hurdle to onboarding. The more time spent on explicit “onboarding” through paperwork and presentations the harder it is to explain why someone is still unfamiliar with the file structure of the project when they are one month in.

Finally, while the concept of “I don't know what I don’t know” is real, the person onboarding is the only one that can know their learning style. Speak up about what it is you need so that you can contribute, and ask for it!

Benefits of group blogging

Prompt: Does group blogging benefit you? Does it benefit your company? If so, how?

Rose:

Group blogging provides a forum that I find valuable. Having a somewhat regular prompt or a question to think about not only stimulates my brain to reflect, it also provides the opportunity to connect, converse, and empathize with others who respond to the same prompt. I think it’s a particularly useful way of staying in touch; the nature of our jobs at ThoughtWorks means at any given time we’re strewn across the country (sometimes the world), but having the blog keeps us united in a small but meaningful way. Cheesy but true!

Abby:

My biggest fear on being a part of a blog is whether or not anyone cares about what I have to say, and I can’t say this will ever get completely quelled. However, I find more and more that it is not about the many people who won’t find it valuable, but instead about the personal value I gain from the thought that goes into writing a post. I find both the personal reflection and the group conversations a chance to learn a lot about a new topic and my relation to it. I do obviously hope that some who read these posts find value in whatever way they qualify that, but even if its just that they formulate their own answer to the prompt in contrast to all of ours, that can round out the full reason for my participating in this blog.

Linda:

I think of the written word as a reference point, and enumerating ours externally improves the technology ecosystem in which we work by enriching the perspectives available to others' inquiry in our field. Also, as the people who spend a lot of time in the thick of things, our insights are fascinating and valuable to people who are concerned with this business, but not yet or not currently on-site.

Technical/industry blogging gives your admirers (and project managers, and yearly review participants) something to point at when saying "this person is awesome". It's an easily linkable, skimmable, and quotable source of brag and usefulness.

When I blog alone, I am a tiny voice with unfounded opinions in an uncaring wilderness. When we blog as a group, we're having a public discussion on interesting topic, with each of our posts adding value to the whole, and encouraging each other to meet our group post goals.

Bill K:

The reasons I show people the Agilistas blog are several. The obvious one is how great it is for a group of women to have a public presence in an overwhelmingly male industry. There is more to it, though. I know the authors. I watched the first wave of Agilistas join TW, and I know what adversity they had, how they bonded and supported one another, and how they did great work for our clients. To me it's a lot more than countering the image of the predominantly male industry. I'm proud to know them all and look forward to the day when they run the company!

I'm also proud that this first generation has passed the torch to another generation. Maybe that's not even the right way to say it. The current Agilista bloggers didn't need any prompting and took the initiative on their own.

I have shared this blog many times over the last few years. I know that other women in our company are happy to see it. It is still not common to have a group of women working together and blogging. Every time I've shared this link, people have responded to me by saying how happy they were to have received it.

I hope I haven't embarrassed any of you too much, but I am very proud to know you all and have you all in TW. You have made it a much better place.

Sarah:

Group blogging provides a regular forum of expression which is valuable. By providing a prompt, it gives a both a goal and a start of thought. These prompts may or may not be answered in a personal self-reflection irrespective of their value simply due to the chance one may not even think of it or believe it is a valuable thought.

It benefits the company by providing a place for people to have an exchange of thought which others can hopefully derive value from.

Advice to my former self

Prompt: You’ve been a ThoughtWorker for X years and Y months. Think back on your first day on the job - where you were then and where you are today. What advice would you offer yourself? What do you wish you had known back then?

Rose Fan: Analyst, 3 years (June 2010)

Be prepared.

You’re new in the company, on the client site, in the workforce, and in the industry; accept that your lack of experience will inevitably put you at somewhat of a disadvantage, especially if you’re joining a team of analysts who have been there for years. However, what you lack in experience you can partially make up for through plain hard work. Do your research before meetings. Get to know your clients and customers before you meet them. Read up on system terminology and documentation. Get your projector set up before your meeting invitees show up. In short; do everything you can within your reasonable capacity to be as prepared as possible. Even if you don’t know the answer to everything, doing some homework will permit you to at least be able to follow the conversation and get ramped up all that much faster. Anyone can build up domain knowledge over time, but a hard-working analyst who demonstrates preparedness and who radiates confidence in the face of unknown or new territory brings value on day one.

Say yes. Or ask “can I get involved in that?"

At ThoughtWorks you will likely come across many opportunities. Some will be presented to you in an obvious manner (e.g. a recruiter asks if you can fill in for an interviewer); others not so obvious (e.g. you overhear water cooler chatter about an XD workshop happening next Friday at the SF office). In the case of the former - say yes! In the latter, ask to participate. Being proactive and willing to wear new hats are qualities that are valued very highly here at ThoughtWorks and will take you far. Worst case scenario would be that you don’t get to join in this round of fun - but your name will be remembered the next time an opportunity comes up.

Go to pub night.

...and roll-off parties, team dinners, movie nights, and other forms of get-togethers outside of work. ThoughtWorks wouldn’t be what it is without the relationships that we have with each other. The weird, funny, thought-provoking conversations we have after-hours are a perk of the job! Take the time to cultivate friendships and to get to know your team. Being friendly and personable will establish a deeper level of trust and respect at work too. You’re young and silly and likely in a foreign city - go out and have some fun, girl.

Linda Goldstein

I've been with ThoughtWorks for 2.5 years (since January 2011). I keep my code interview code in a private repository on github, in large part because it is very different from what I write nowadays. Very few entry-level developers know how to design for maintainability.

1. Don't allow yourself to split your attention towards technical side projects until everyone on your project thinks you're quite good at most stuff and an expert in at least one thing.

1b. Okay, but only one side project at a time.

2. Having a mentor who knows about these things is invaluable when it comes to learning people skills and politics.

2b. Soft skills are at least half your job, and having them makes both learning and teaching tech stuff go much more efficiently.

3. Maximum "Yeah, totally" is maximum win (most of the time.)

• "Are you coming to team lunch?" "Yeah, totally!"
• "How would you feel about going to Dallas to work on a Java project?" "Yeah, totally!"
• "Can you come to San Francisco for a workshop on Android?" "Yeah, totally!"
• "We need someone to do X huge task; can you take it?" "I'm kind of overloaded right now and I think I might explode. So probably not, sorry."
• "Can you help interview a candidate today?" "Yeah, totally!"
• "Can you look at this code?" "Yeah, totally!"

Apryl Gordy: Analyst/Dev- 1year, 1 month (Hire Date: June 6, 2012)

Breathe! It’s ok- It is perfectly fine not to know the answer to every question asked to you, the important thing is that you must not be comfortable with not knowing. Search for the answer or find someone who knows the answer. Always be learning and absorbing what comes to you in the form of information.

Ask all the questions- Be that 3 year old child that asks why for every single reason. Even if something seems to be right, question it. ThoughtWorks wouldn’t be the place it is if everyone went with every decision because “it is right” or “because that’s how it’s always been done” or “just is” Don’t ask because others say you should, but ask with the intent to understand the true meaning of why and don’t stop asking until you fully understand why.

Roll with the punches- often times with being in a part of a consultancy changes come at the tap of a keyboard. Don’t fight the change just go with it, it makes life so much easier.

Sit up straight in your chair!- You’ll thank me in your old age when your back doesn’t have a hump in it.

Saying ‘no’ is permissible- ThoughtWorks is a place of an abundance of opportunities and it can seem like you’re drinking from a  firehose if you try to do EVERYTHING. Step back, analyze the opps and then decide which way to go. It is great to participate in many things as possible; during hours, after hours, fun stuff, technical stuff...and all things in between. But know when too much is too much and be comfortable and able to say ‘no’.

Do not be afraid, Be confident!- You may not know it now, and it may be scary, but trust that you can learn it. Fear is merely a perception, change your perception and you become fearless. You were hired to do something you know very little about, but trust that you can get to the place of being an expert on it one day. A journey cannot be started if you don’t take the first step. You can learn it, YOU GOT THIS! They know you can do it, you have to be more sure than them that you can too.

Be you, be bold, drive your journey- you will often find that suggestions will be made for you about what is best for you. Not everyone knows what truly is best for you, but you always should and do. Acknowledge that what is being said or expressed comes from a genuine place, but be bold enough to say that you disagree. Set your own goals and share them, but don’t let others create the path that you should go down in order to meet that goal. Hear what they have to say, alter your plans if their suggestions are better than what you came up with, but don’t let it change you or what you envision to be the next goal checkpoint.

Always remember to smile, laugh and HAVE FUN!!!!! - Somehow it brightens others day when you smile. And on the opposite side, if you don’t...some take you for being the angry black kid in the office :-) Having fun daily makes this thing more enjoyable. So grab as many nerf guns as possible, crack as much jokes as necessary and laugh at yourself when you make stupid mistakes. Laughter heals even the most stressful situations. Don’t think of this as going to work every day, just say you’re headed to the fun!

Abby Bangser - ~1.5 yrs

"If you know 4 musical notes, teach someone who knows 3."

This might sound cocky when you know so little, however it will keep your mind open to learn from every single person you speak to, so be ready to absorb. At the same time, the opportunities to learn extend beyond technical or consulting skills and into the realm of teaching and leading in ways you can't even imagine right now. The quickest way to learn something new is to offer to help so pay attention to new opportunities. Don't underestimate the power of getting to know your team outside of work and definitely don't underestimate the need to know when to slow down so that you never have to stop. Lastly? Have fun...there are a million opportunities so find the ones that make you happy because that will always yield better results!

One thing from our projects this week

Note: most of us are on different projects

Having the proper number of environments is crucial to truly complete what you have deemed the "definition of done". (Apryl)

We just started an architectural change which will take us from Enterprise Java Beans to Spring beans... translating beans is astonishingly tedious. (Linda)

Take the time to find out how much effort it would take to make something better since the investment you could put in might save you much pain down the road. (Sarah)

We're able to track who is working on what story with avatars of ourselves stuck on our chosen story card, and we're making sure we're pairing evenly with a well displayed chart. (Aubrey)

I am currently working on identifying flows for the UI tests for the first time; this has been a project since the UI tests so far have acted more like unit tests and therefore have been multiplying and their cost/value ratio is suffering. (Abby)

One thing I learned this week:

I learned that a library called UTFgrid exists, which is designed to load map data on mobile connections and/or legacy browsers by displaying the map tiles as ASCII art! (Linda)

Apart from learning that I'm not built for living at high altitude, I saw in action the importance of networking; TW is a wealth of knowledge and opportunity when it comes to picking the brains of all the talent in the company. (Chisara)

Sometimes you have to make a choice between two opportunities; one may come once in a lifetime... others come more often; pick one, be happy with the decision, and don't look back; that decision may change your life! (Apryl)

A title can tell you little more than what the presenter believes they are saying. (Sarah)

I learned that code bases won't necessarily have passing tests right out of the box on IntelliJ, even when the build passes on the command line. (Crystal, at TWU)

I learned that Postgres allows users to have roles, giving greater flexibility when changing permissions. (Aubrey, at TWU)

How do you manage time effectively?

MJ

I struggle with time management. I am always stressing about the next thing. Over the last year I started consciously working towards doing things to help reduce stress and help keep me on top of things.

1. I allot time to plan my week.
• I fly out to the client on Sunday nights. I dedicate the first half hour of the flight to just thinking and writing down what to expect the week ahead.
2. I put stickies on my laptop to remind me of deadlines
• This helps me glance over to ensure that I have the deadlines under control
3. I try to set up auto pay for bills
• I don't like to miss monthly bill deadlines. I find auto pay very convenient
4. I do expenses before dinner on Monday nights.
• I am hungry and tired. I get through expenses and reward myself with an awesome meal.
5. I force myself to reply to email immediately. I find that if I put those away I end up procrastinating. Being prompt on email is very appreciated at work and in personal life.
6. I plan to get all my work related commitments done during the week. I like to keep weekends completely personal. This means I really push myself during the week and end up having to give up on going out to eat every night etc but this system works for me.

Tools I love:

• Evernote (they had me at auto syncing)
• A moleskin journal and an amazing pen I always have with me
• At home I have 3 small colorful white boards to help me organize tasks

Linda

Every morning I read through everything in both my personal and work Gmail inboxes, take care of what is urgent, and put things I need to do but can't do right then onto my personal Trello board.

My Trello sections, in order (ordered this way both because I have more sections than I have screen real estate, and because the leftmost one is what comes up first when you open the Android app- therefore the one I want to use on the go is the one that I put on the left:)

• Goals for the next six months (run workshop on [X], post blog on [Y])
• Review (stuff I want to do sometime- like do the entire Rails Zombies sequence on CodeSchool, read the book Testable JavaScript)
• Now (stuff I am currently working on and don't want to forget, like expensing my hotel bill, picking up a package, and doing my OOBootcamp homework)
• Done (this is my brag list and I archive everything in it every two weeks or so)
• status (this, combined with the Done list, is what I brag about to my TW People Person or coach every few weeks)
• Do Later (this includes goals for longer than the six-month term, like "go scuba diving", "go to Grace Hopper Celebration of Women in Computing" and "get LASIK")

I rely on my Google calendar to tell me when I have lunch meetings, after-work events, home office days, and plane flights. I rely on my teammates (and I guess my client-email-system Outlook calendar) to remind me of team events like IPM and retro, although these are very regular and easy to remember.

Rose

I find that I manage time best when feeling a little bit of pressure/stress. Too much induces panic, too little laziness. Just the right amount of that ominous “I should probably get this done...” feeling is what kicks me into action and lets me maximize my productivity.

I’ve picked up a few tips and tricks along the way for keeping myself in that sweet spot of feeling motivated to do work. They work for me; as always, your mileage may vary.

• Writing things down has a different effect from typing it out. Maybe I am just old school but I find comfort in the feeling of ink on paper. I also tend to remember things better that way. Most of my to-do’s, reminders, and other scraps of words are captured in a notebook that is always in my backpack or by my side.
• Routine is key. Setting an expectation with yourself for accomplishing recurring tasks is the best way I know to keep the regular ebb and flow of work at a manageable level. For example, every Monday night I go on a run with my coworkers. When I go back to the hotel, I make dinner and do expenses. It’s not rocket science, but it works, and my brain appreciates the consistency.
• Timeboxing, timeboxing, timeboxing. When you are juggling multiple priorities in a limited amount of time, it’s wise to sit down before and think to yourself, “how much time should I be spending on this?” I admit to sometimes getting analysis paralysis and obsessing over the details for way too long; telling myself I only have an hour to look at task XYZ helps me focus and place some artificial pressure on myself to go for the low hanging fruit within any project.
• Don’t neglect sleep. It’s easy to let your work send you into the wee hours of the morning. But too often we underestimate the importance of clear thinking from a well-rested brain - and we feel the pain the next day when we are groggy and unfocused. I believe that the immediate gain of a few hours of time is not worth the next day’s diminished returns. The brain is like a muscle; overusing it without sufficient time for it to mend and restore itself is bad news bears. Give it the same rest and respect that you would the rest of your body.

How does work-life balance on travelling projects work?

Linda Goldstein

As a travelling consultant, I commute via plane every week to a city where I know very few people other than my coworkers, so we naturally hang out and explore the city. 

I am very much in take-advantage mode when it comes to attending events on this project; there are too many for any one person to do, so I pick the interesting ones. On a large project there are always sub-groups of people going to the movies, to the grocery, a running trail, yoga, rock-climbing, dinner...

Sometimes the client developers come in super-early (6am, anyone?) and leave equivalently early. (A common reason for this is to avoid bad rush-hour traffic.) This can limit the amount of time you get to spend together as a team and make problem-solving later in the afternoon more difficult. It also means the team has more "temporal coverage" which can be important if some of your most important customers work early in the morning, or are in a different time zone. 

Many people bring lunch to work; some eat at their desks. Some take longer lunch breaks. If my pair says "I'm not taking lunch today because I'm leaving at 1:30 anyway," what do I do? Do I take a regular lunch? Do I hurry my lunch or postpone it to try to get more pairing time in? As always, it depends... Mostly I don't want to let the work stall because one person is out of the office.

It is very easy to prevent yourself from saving time to sleep and exercise adequately. As a travelling consultant with a great team, I need never have a dull moment again. But sometimes I need to make some dullness for myself. :)

Amanda Snyder

One of the most important goals for a company should be to provide a healthy work/life balance for each employee. This became even more important when I began on travel projects. However, the company can only do so much. 

The more important part has become the people, and for me it is about being with people who can still surprise me at the end of the day. The people who really care about something and can introduce you to an activity or group that you may never have tried before. 

However, it can easily become exhausting trying to optimize each weekend with travel, and get to know each city when you only have so much time during the week. I have found that planning so far in advance takes up much of my time, and trying to have events during the week with work and then all weekend is too much to handle. 

I have found a nice balance in keeping to a strict schedule a few nights a week, having a running night or a night dedicated to expenses, a night just for cooking dinner each week. Then it’s just as important to have nights dedicated for exploring new events, going to dinner, and being with others. This schedule, however, relies on having those passionate people, who are willing to plan an event once in awhile, and help out to take the weight of planning off my shoulders.  


Abby Bangser

“Choose a job you love, and you will never have to work a day in your life.” 
― Confucius

While this is a very famous saying, I am not sure I agree. I think that loving what you do is different than trying to make a living from what you love. While that is a very fine line, it is what allows me to have a work life balance. After changing careers into software development I have found enormous enjoyment in staying late to problem solve that tricky nice-to-have, spending all night getting caught up in a side project that will never see the light of day and getting lost in the rabbit holes that are links within articles. This makes my hours “on the job” where I am improving my skills and becoming a better software consultant add up fast.

But having my true loves be outside the scope of my job allows me to always get those necessary breaks. These range from an hour at the gym each day, to evenings at the theater or a sporting event, all they way to week long vacations to go scuba diving. What makes consultant life so perfect for someone with these diverse interests, is the diversity of people and work sites that continue to fuel so many rewarding activities. My suggestion for everyone would be to treat their current home towns like a travelling consultant would. Never take the museums, concert venues, sports teams or simply walking around and taking everything in for granted as they help tear you away from your desk when you are closing in on that 12 hour day.

Kate M

I often get asked about how being a traveling consultant affects my life. There are of course many perks to traveling, but the challenge comes when you get off work in a city foreign to you. How do you constantly readjust being in a new environment, with no roots? Some thrive off the challenge and some feel gradually drained by the effort of constantly calling a new place home.

Everyone is in a unique position, however. It's an ever-interesting mix of family, responsibilities, friends, and hobbies which makes juggling life difficult as a traveling consultant. I am one for creating roots, so it has been an interesting journey for me. I easily make a new place my home in little time. I initially keep myself busy by exploring. I stay weekends instead of going home. As time goes by, I find spots I like (that sometimes remind me of home) and I create roots. I live in the city rather than just visiting. I become at home because I know the streets and places. I let myself be engulfed in a city.  At some point I act more like a local than someone who's only going to be there a few months. For me its about making the most of the hours after work.

I also know that when I want to stay in a place somewhere (and I have a tendency to fall in love with cities) that it is always an option. When I am ready, and when I want to have a little deeper roots. Everything is what you make it, and I make every place my home. Having a place called home is important to me. It's what helps me find that normalcy that I am missing. That comfort and that feeling of being somewhere familiar. 

And that's how I make it work for me, and I know it might not one day. Which might mean change but might not.

Working on a legacy project

Chisara Nwabara

In many ways, working on a legacy project is much more challenging than working on something fresh. You are dealing with an old dog; a creature that is less malleable and, in my experience, often times less willing to take on new tricks when push comes to shove. It takes a lot of patience and also an understanding that even though this dog is stuck in its ways, it has years of experience that should not be overlooked. So, in my opinion, the challenge is determining how best to leverage said experience so that it can be applied to the practices you’d like to bring to the workbench. Once you are able to balance the your knowledge/experience with that of the client's, the project goes much better. Linda Goldstein

I am currently on a Java project that started before Java had non-generic lists. Last month, we had to code around a bug in Java that was fixed in 2011. There are code comments from 2002. At least three different editors, with three different code generation and indentation styles, have generated code in this app. There are both DOS and UNIX line endings. Using Vector was considered good practice at some time during the lifecycles of this app. As far as I can tell, at no point has dependency management been used; all the jars are checked in.

Legacy is a challenge. You can never fix everything all at once. And what I consider a 'fix' may break something that was written several years before I learned how to code. In order to actually understand what you're doing, you have to learn not only what is a bad idea today, but why it was a good idea five years ago.

"Learn from the mistakes of history, or you will repeat them" is the common wisdom- but, like the prime directive of retrospectives says, "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." Those mistakes of history? A lot of them weren't mistakes. They were conclusions given a different data set than we are currently operating with.

Working within legacy constraints is a complicated puzzle. On this project, I get to make something more elegant every day. There are a lot of low-hanging fruit. It's not boring yet.

When it comes to how working on a legacy project affects my interactions with people... there is fear in this codebase, and you can smell it in the null checks and in the comments. There are too many unknowns left over from 2004; there is too much "just in case" code. I write it too; the fear is justified. The test coverage is low, and you can never be quite sure what the code upstream will do, since the Single Responsibility Principle was not (and is not) always universally approved of.

A legacy project is a complicated ecosystem in every way; it is very far from the relative simplicity of "rails new testproject" and I do sometimes wish that the only code we had to contend with on this project was written by people using the same approximate temporal set of best practice references as we.

Sarah Hutchins

I have never honestly worked on a legacy codebase. Even now, my current engagement is around teaching the client a better way to write code and the codebase is little more than an example minefield. However, I have been on the other team - the ones from whom you inherit the code, the ones who have to somehow impart all the knowledge built up, the ones who made those decisions which come back to haunt the project.

It is very easy to start out with good intentions and watch things slowly unravel. Between business indecisiveness, lack of experience, and the odd technology choice for which there is no choice, compromises end up finding their way into the codebase. The more functionality which gets added, the more cluttered the domain model became. Pressures make it difficult to do a domain model level refactoring and before you know it, our greenfield project became just another cluttered codebase.

Ramping people up in this situation is never pleasant, and unfortunately, the second wave onboarding tends to be roughest. No matter how much you try to cover when explaining things, there seems to always be that one class which gets missed or that one testing standard. Furthermore, as one of the original members, so much of the knowledge has become second nature it becomes difficult to ramp up someone from nothing. It is one thing to claim you need to tell them everything and quite another to actually do it. After all, how would you explain walking? It is a skill we learn through trial and error over a period of time and we constantly refine it as we use it. We get to the point where we can no longer consciously remember everything involved in it because the knowledge is ingrained. After being on a project for a couple months, it can feel like that. As a result, a lot of pressure ends up on the one getting ramped up since they have to ask questions about the knowledge you do not even think about anymore. Naturally this can lead to frustration over the seemingly convoluted codebase. Then, as the original team, you watch the new people come in and decry many of the decisions made without knowing why the decisions were made. Things start to get added to the codebase without the context of the old guard and it becomes even more disjointed.

This is not to say new people being added is a bad thing. It is a very good thing as new thoughts and ideas are added. The new people are also not weighed down as much by the knowledge of the past and will have a much easier time questioning decisions. Cycling in new people is one of the better ways to keep a project innovative and without the new blood, it is very easy for a project to stagnate. Furthermore, once you get through the second wave of onboarding, ramping up those who follow can be quite a bit easier. At this point you have both the originals who have the context and the second wavers who had to struggle through and can remember their difficult spots. Later ramp-ups can take advantage of both to not have to figure out all the right questions since the previous group has already been there.

Abby Bangser

While I do not think all “legacy” systems are the same, often people associate legacy code with a buggy, hard to understand code base with limited test coverage. If we look only at a situation which falls into these categories it can be a very difficult situation for a new Quality Analyst to roll on to. How do you test something that even the most project experienced testers and developers do not fully understand? Questions abound, including...How can we be sure this change doesn’t cause a bug somewhere not immediately obvious? Was this an existing bug or a new one? Where else does this change show up?

However, what I have found is the biggest struggle is not in the risks, but in redefining the concept of a “quality product” in the eyes of the customers and development team. Obviously the current team takes great pride (and should) in their product and the customers rely heavily on the application. However, everyone from developers to users have learned (and I quote) “work-arounds to work around their work-arounds”. This deep understanding of already unsteady processes leads to a desire for consistency even when it perpetuates the acceptance of bugs and hardships for the users.

There are ways to introduce change by deciding today that anything new will be written under the new standards, and to refactor existing code in a slow by steady manner. The fragmented and duplicative nature of legacy code can make it difficult to change existing functionality that spans lots of the application (ie: a standard for how to submit a form which may not be user friendly but is “copy and pasted” around to many screens). By building any new versions with modular pieces you can kickstart the refactoring process and before long have all instances called from the same method which allows for a one step change. This consolidation of changes is more likely to be approved by the customers since consistency will be maintained.