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.

Childhood activity that most translates to current successes

Rose Fan

I can’t pinpoint any one particular childhood activity that I think translates to current successes. There are many that probably seem like candidates - Mock Trial, playing an instrument, blogging, attending a Magnet high school focused on math and science. And yet, to draw a nice little connection between those and the environment I’m in today, no matter how seemingly correlated, still doesn’t seem honest or genuine.

I thought that school and the boundaries of childhood were quite mundane. If you knew how to play the system, you could win. But it was a rat race of scores and grades and rankings that were standardized ways of measuring people and comparing them against each other and I didn’t like that. In the last few years, when I’ve been outside of those confines and have found a company that doesn’t emphasize traditional roles or structure as a means to an end, I’ve felt a lot more empowered to make decisions and figure things out.

I attribute my current successes to relatively current (i.e. no longer childhood) and drastic changes or pivot points of my life, when I finally felt like the reigns of my life were in my hands. Childhood for me doesn’t map to them, at least not in an obvious way.

Abby Bangser

I am a true believer that who you are at a young age translates to who you will become as you grow up. While I have grown tremendously from my education, work experience and travel adventures I think I am still at heart the same kid that was full of passion and drive. Growing up my parents were great about helping me do anything I wanted to try, which revolved heavily around sports (even ice hockey, though much to my mothers dismay!). Through sports I learned how to be gracious in defeat yet tenacious during competition. I learned about the impact of a weakest link in a team, from both the strong and weak positions. I learned when to lead and when to follow. And most importantly I learned how hard I could push myself and the amazing results when I did so.

Those lessons are pretty standard if you talk to any former athletes, and there are a million articles and studies that translate these into future leadership and business success. But to translate this into being in software development or a consultant took a little thinking. One thing that I remember doing even from a young age is learning from everyone. This meant even if I didn't agree with someone or I couldn't master the skill that moment I filed it away in my rolodex (this analogy in itself is thanks to one of my coaches) and kept it on file to re-attempt at a future time. I think that this understanding that everyone has something to share and teach translates brilliantly to having success as a consultant. Coming into a client's office with the humility to understand you may not have all the answers allows you to make an even greater impact while also leaving better off yourself.

Linda Goldstein

The problem with my childhood as it relates to my professional life is the perception of some people that it was too recent. I have, several times from different sources, gotten "Aw, you're my daughter's age."

I am not like your daughter and I do not have any familial obligations relevant to this situation. I am the person trying to help you learn how to refactor code, write unit tests, and generally meet deadlines. Please try to put on your professional hat and remember this.

In my opinion the love of learning is easier to have when one has not learned to not love learning- which implies that age is a form of handicap in the field of development. I have met devs with thoroughly white hair who are fast enough on the uptake to leave me in the binary dust, and I am honored and delighted to work with them and try to imitate their learning.

The activity in my childhood that I think contributed most to my current state was reading excessive amounts of science fiction.