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.

Grace Hopper presentation abstracts

The Grace Hopper Celebration of Women in Computing is "the world’s largest gathering of technical women in computing." Write a submission draft using their submission guidelines:

Rose Fan

Abstract: The traditional approach of hiring based on primarily on degrees, resumes, and other “sheepskin” indicators is losing steam among today’s latest generation of tech organizations, especially within the tech-y start-up scene and culture. This talk examines the different types of non-traditional hiring techniques and incentives that companies are using today - and also links them to the long-term positive externality of happiness that they bring.

Title: Non-traditional hiring & long-term happiness at work

Objectives of the presentation: To illuminate the not-so-obvious link between thoughtfully placed workplace hiring practices and the downstream effects on overall happiness in organisations that enforce them, especially those that emphasize learning and teamwork over experience and ownership.

Audience: who should attend?: Recruiters, professionals who are interviewing for candidates, students who are looking for job opportunities, folks interested in the psychology behind workplace happiness

The format of the panel/workshop/presentation: A content-rich/word-poor slide deck (images, infographics, videos), with the speaker facing the audience

Proposed session length: 25 minutes, with 5 minutes for Q+A

An overview of the information to be presented:

- speaker intro (3 minutes)
- talk about examples of “happy” places to work (5 minutes)
- talk about different incentives, day-to-day perks
- examine the hiring process at those places (5 minutes)
- talk about self-selection
- examples of non-traditional hiring practices/interviews
- describe the relationship/connection between long-term career happiness and the short-term hiring process (5 minutes)
- illustrate that the difference between hiring wholistically and by credentials
- examine historical examples of groups of people that enjoy long-term career fulfillment
- talk about take-aways (5 minutes)



Linda Goldstein

Abstract: Those with experience or interest in coding on non-remote group projects will love this interactive workshop on the art and science of pair-programming, featuring many classical examples of how to Do It Wrong in order to discuss the principles behind the practice.

Title:  Workshop on Highly Collaborative Coding Environments (Pair Programming)

Objectives of the presentation: Introduce the concept of pair programming to those unfamiliar with it, along with the basics of how it works

Audience: who should attend?: Both professional developers and students interested in becoming developers, especially at companies which use agile methodologies.

The format of the panel/workshop/presentation:  Fishbowl-style, with one facilitator up front, and two audience members sitting at a desk near the front center of the room, facing the projector (which will be projecting a scenario), with the rest of the audience sitting in ranged semicircles behind the desk. The desk will have two mics on it. The two desk positions will rotate among willing audience members.

Proposed session length: 90 minutes (at 10-15 min/scenario, plus an introduction, this will let us run through 5-8 scenarios)

An overview of the information to be presented
Introduction of the facilitator (1 min)
Overview of what pair-programming is and how it works (8 min)
Proposed scenarios (can be changed on request) (10-15 min each, ordered by priority)
- How to tell your pair what you're looking at (pointing vs. line numbers, pronoun confusion)
- How to admit ignorance (2 scenarios)
- How to draw out a silent pair
- Why pairing is a good idea
- Why pairing rotation
- Why to not commit on a red build
- Why refactor
- Why to commit often


Apryl Gordy

Abstract: Oftentimes as a minority female, one will find themselves in technology classrooms with many that don’t look them and none that do. Is the pipeline of minorities in technology-based fields drying up? Is it the fault of schools that some people can't look to their left or right to see someone that looks like them or of a community? Is there/what is the bigger picture? How can we help?

Title:  The Minority Pipeline: A Candid Discussion

Objectives of the presentation: To shed light on what it’s like to go from the classroom and notice that you are the only one that looks like yourself, to the workforce where it is generally the same. The honest truth of why this may be and to gather help and ideas on what we can do to change it.

Audience: who should attend?: Both professionals and students of any and all races willing to discuss, recruiters looking to feed the pipeline and anyone willing to help try to change the way things are now.

The format of the panel/workshop/presentation:  Lecture/Discussion style setup, with a slide deck for enhanced delivery.

Proposed session length: 30 Minutes

An overview of the information to be presented
Introduction of the facilitator (2 min)

Overview of how one derived this topic  (3 min)
-personal school experience

Brief slide deck (zoom style) with a few statistics (10 min)
-childhood situations
-statistics (graduation rate, prison rate, adolescent pregnancy)
-correlation with college admission statistics
-correlation with the technology workforce

Candid Discussion between all audience members (10 min)
-does the audience agree?
-what are the opinions of those outside the general minority

Call to Action/ Q&A (5 min)

Tech-misogyny and diversity efforts: how do you react?

When you see offensive things about women in tech like the ones mentioned here, what does it make you feel, and how do you decide what your public response, if any, will be?


Amanda Snyder
I don't think it's fair within an panel, conference, or job position to mandate diversity. You're making too many assumptions when you create this mandate. First, you're assuming equally qualified women applied to the position, and were rejected simply because they are women. The mandate just creates a pressure on the company or conference to add in one women, who may not have an equal skill set, just to fill a quota. This is unacceptable, and in the end this really won't be helping others perception of women if we lower the bar for their acceptance. However, this isn't to say that there isn't a problem with having only men in a work area or conference, where women are clearly present in the field.

We need to create a mandate where it can put the responsibility on the conference organizers to draw more women in. When a business is looking for more women to hire, the responsibility should fall to the recruiters to add more women to the applicant pool. This is where it all really begins. The recruiters have to go out and advertise the company to more women organizations, and find creative ways to get more women to apply. That way, there is no responsibility from the interviewers to hire the one percent of women who applied just to get numbers up. This same idea should be applied to conferences. There should be a mandate that speaker applicants must be an equal percentage of women. Now the responsibility is on the conference to appeal to various women in the industry to get them to apply, and not the job of the selection committee to be picking the one or two women.  


Sarah Hutchins
Seeing offensive things just makes me think this contributes to the problem. Women already require a lot of work to get to speak up, regardless of whether it is true, there is a feeling they just will not be as welcome as men.

Seeing all male speakers or being in the minority contributes to feelings of having to represent or that there is little representation because there was no one qualified. Women feel a lot of pressure not to go to tech conferences and the high male ratio, unconscious male-targeting marketing, the idea that conferences just don’t have much to offer them, and horror stories from other conferences all contribute. There are even other women urging them not to go since they felt it was a waste of time or because they feel like other women so frequently tend to “contribute to the problem”.

It is hard to put together a public response to this, because of the feeling it will be dismissed. I am a woman and there is already a feeling of being little more than a token at this sort of thing. The frequency you hear something like “More women should apply because there aren’t enough women” or “You should apply so there is are more women candidates” contribute to the feeling that even if we start getting women on panels, they will be there as tokens, not as qualified speakers in their own right.

As a result, I have to come to what will be an unpopular decision. While the website which prompted this article missed the point made (no women on panels sends a bad sign) it brings up a good point. Diversity of gender for diversity’s sake is meaningless. Forcing your speakers to fit into ratios will not result in better conferences and instead will tend to dilute the quality as the focus shifts from interesting and well designed presentations to gender.

Perhaps we should focus on the fact there tends to be few women candidates. Studies and experiences of organizers show that so long as they get a pool of qualified candidates with significant representation, the speakers chosen (even when chosen blind to the gender of the candidate) will tend to match the representation in the pool.

So instead of a public outcry at one person missing the point, perhaps this should be a public call to answer this question: Why is it so hard to get women and minorities to apply as speakers?


Rose Fan
Last week I attended a session by a fellow ThoughtWorker on the topic of effective communication. He asked us the question “When somebody, anybody is communicating, whether in speech or writing or any other way - do they ever think they are in the wrong? Are they ever saying something that they believe is the wrong thing to say and that has no justification in their mind?” We pondered that for a little bit and agreed that the answer was “No. Nobody ever intentionally does that - we’re all acting in our best interests, whatever those may be.”

In this case it’s easy to sneer at Andy Rutledge’s parody website. It’s easy to point fingers at him and use unsavory words to describe his character. It’s easy to make fun of how much time he must’ve spent lining up his divs and thinking of mean acronyms to troll this subject. It’s easy to blame him - a face, a man, a name - and unite against him as a public enemy. We are those who advocate for diversity on panels, conferences, etc! Andy is not! Burn him at the stake. Am I right or am I right?

But that’s focusing on the person, not the problem. And in Andy’s case he does bring up some valid points despite them being presented in an immature, sarcastic and hurtful way. It’s those points I’d like to examine and counter - those best interests that he has for doing what he has done.

I read Andy’s follow-up post entitled “Much-needed explanation”. There I found a much more reasonable argument that he sums up as: “I’ll say again: the cult of diversity is blind to individuals and recognizes only categories and demographics...People are not categories, but sovereign individuals.” I chose to take this as the core message that he built his site upon. It doesn’t excuse the site, but again the site isn’t worthy of discussion - the core message is.

At face value it’s not a disagreeable proposition. Yet I do not support it 100%. Despite the ideal of people being treated as sovereign individuals, we can’t hide the fact that categories of people have been discriminated against in the past or have faced barriers to entry in technological fields that other categories have not faced. I’m not talking about just tech conferences here - I’m going back as early as grade school education. Over time as they are funneled through narrower and narrower paths that routinely disfavor or marginalize these groups - degrees, programs, jobs, promotions - these categories are what end up underrepresented in tech panels and conferences.

Echoing Amanda, I think widening the pool of qualified speakers who are women and minorities by actively recruiting them is the way to go here. Proactively seeking those candidates and encouraging them to apply is what we can do for them - but once they are in the pool, admit them on their merits and force no pressure to meet any diversity quota. If there is enough diversity in the pool of those who are putting themselves out there for tech panels, the increased presence of women and minorities in these areas should unfold naturally.

Some including Andy argue that such women do not have a presence because they simply don’t exist; as such, the pool of qualified speakers always results in men not out of discrimination but rather out of lack of well, anyone else. But I disagree. The women are out there. The minorities are out there. They’re hidden because they are more cautious. Less likely to raise their hands when they are unsure. More aware of how they may be scrutinized and more afraid of uttering a mistake that would negatively reflect on their entire gender or race than on themselves as idyllic “sovereign individuals.”

If we recognize this difference, then as an industry we should seek out those women and encourage them to put themselves out there to apply. After the application, all is fair game and admission truly may be gender and race-blind.


Linda Goldstein
To me, the issue that the original topic was trying to address was that the percentage of speakers at technical conferences who are women is much lower than the percentage of women in the industry at large, and that since it is unlikely that this is due to a skill differential, possibly some kind of social bias or intimidation factor is at work. The post then goes on to describe one person's overreaction to a suggestion on how to increase the percentage of women speakers at conferences.

How do you make the speaker list at conferences more diverse? We don't want to set up a quota because that would decrease the perceived (and probably actual) average quality of speaking. So let's go one level of abstraction closer to the root cause. (We don't want to fix the root cause right now- that's out of scope and probably a 13-point card that should be split)*

How do we get more women into the conference pipeline? For specific suggestions, I sat down with some smart technical ladies (many of them have posted on this blog already) and got...

- Not zero to zoom: first I would want to give a version of my talk in a smaller venue with a more trusted / smaller group of people (like a Continuous Education presentation or a Home Office Day presentation or a lightning talk or a local meetup, etc). This would result in feedback which I could use to improve. Repeat until comfortable.

- Have something (that I think is) new and interesting to say. Usually when I think about a presentation topic that I could use, I end up thinking "everyone knows about this already". I don't want to give repetitious or low-quality presentations, even just for practice or in an attempt to further my career.

To avoid quotas, attack at the pipeline. If your pipeline of qualified applicants is half and half, and talk abstracts are reviewed on merit (i.e. without names attached) then the outcome will be equal (unless women actually submit worse abstracts- which is a fact that I do not currently believe).

In response to the original question:
1. When I see misogyny on the internet, I feel mad. Also resigned. The world is full of trolls, and a lot of them work in my industry. I'm lucky to be at a company where conscious attention is paid to not being jerks.
2. Usually silence, lest the trolls turn on me personally. But I'm trying to become braver.

* This is a dev joke. See http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/

Do you know your top three strengths?

When is the last time you really sat down to think about your top 3 strengths?  In any company it is very important that you are able to promote yourself. You have to be able to toot your own horn. But how can you begin to tell people how great you are, when you don't have a clear picture of your own strengths. Men have historically been better at broadcasting their strenghts, so it was time the women spoke up and gave ourselves some praise. 

Abby Bangser

Thinking about individual strengths and articulating them are two very different things. I think this is the critical takeaway from the quote by Nora Denzel in her 2012 Grace Hopper key note speech. She takes the common idea of "it's not what you know – it's who you know" and takes it a step farther and adds "it's who knows what you know". In being asked to identify my three strengths I'm immediately reminded of years past and interview mode. "What highlights my hard work?", "What identifies me as a team player?", "What do they want to hear?". However, if my two job hunts taught me anything, in order to continue to grow both personally and professionally it is best to utilize strengths rather than try to redefine them.

Therefore, for each strength I have identified ways I have leveraged as well as needed to curb them:
Thorough: As a Quality Analyst I obviously use this strength when identifying test scenarios. In contrast, there are some times where the cost/value ratio is such that following the deepest of rabbit holes is not valuable.
Self-driven: I have always had a wide range of interests. This has resulted in playing 5 different competitive sports growing up, completing college with a diverse resume and Political Science major and since then entering both investments as well as software development career paths. Without the self-drive to learn and practice these skills I would never reach the levels in each activity or job that I desire. However, this innate self-drive can lead to head down working at times when leaning on teammates may result in a different and even more interesting set of learnings.
Thoughtful: I think that this has translated into both my history of coaching and mentoring because I love seeing the look on someone's face when they see their hard work pay off. But also setting personal high standards. Sometimes these arbitrary targets and expectations can lead to undue stress and worrying. While this isn't particularly great for me as an individual, it is even worse if my stress is a weight on others.

By embracing both my strengths and weaknesses I have found a place at ThoughtWorks that allows me to grow and learn without expending energies to try portray someone I am not. In identifying and reflecting on my strengths I have found that they are not what I may have thought in the past. My wide range of interests has often made me feel less than thorough and my self-drive has left me independent. For that reason I look forward to continuing to grow and see where my current path leads to!


Linda Goldstein

Strength is difficult. I prefer elegance to brute force, and 'strength' smacks of brute force. So what I use as a strength is to try to not use strength. Maybe this is a thing that our culture teaches women to do, to want. Although in code I tend to start with what I call 'the barbarian solution' - the simplest thing that will work as soon as possible - and then evolve the solution towards elegance. This is only bad if you don't do the second step, but skipping the second step offends my sensibilities, so I'm moderately safe as long as I'm still offended by solutions which would be more valuable if they were more streamlined.

1. Learning quickly. I've seen that long-term lack of encouragement to learn new things can reduce a person's tendency/desire to learn. Fortunately, I am very encouraged in this by TW. :) The downside to this is that once the curve on a new project levels off- once a lot of learning has taken place and the rate at which new things must be learned arrive slows down, I have to connive strategies in order to keep my interest from waning. A good strategy is to embrace perfectionism and stretch yourself to refactor the codebase to be as close to perfectly fitting the standards that your team can agree on as possible.

2. Helping people learn about code without offending or overly distressing them. I think of this as presenting data in such a way that it is intriguing rather than off-putting. Being considered "arrogant" is a problem that a lot of people at our company worry about, because it comes up fairly often; so I am proud of this and want to bring it up frequently.

3. What I call "yeah totally" - the ability to attack new tasks in my area of specialty without spending significant time worrying about the task being unusual or impossible. This is fuelled by the successful outcomes of learning quickly.

Is it hard to come up with a list of strengths? Well, a bit. I stalled out at two for a while. Thinking of my strengths isn't an approach I normally take. It is awkward for me to talk about my 'strengths' because part of my mind is always wondering who is about to disagree, and whether it's really strong enough to count, and whether it's the right question to ask in order to improve the rate and quality of things that I do. What if I get caught in a mindset where I end up saying "that's not one of my strengths; I can't (don't want to) do it" ...that is not a good place to be. So I hope that my "yeah totally" will be strong enough to offset the "strengths" mindset that I worry about. Strengths are dynamic and situational, and affected by the people with whom you surround yourself.

Amanda Snyder:
When thinking about my top 3 strengths it's much too easy to think in a general sense. We’ve all been so trained to come up with the buzzwords that all interviewers want to hear. So I wanted to think of this more in the sense of whom would I balance on a project? I think it’s more important, when making a team of people, to know whose strengths are going to balance out others weakness?

1) Building of complex logic from the ground up. My first strength has to do with how I approach learning. I have the ability to start with a small logical concept, and then to continuously add more and more logic. When I am able to start small, and build from the ground up, I can understand some of the complex logic systems. On the flip side of this, I would need someone who can take in small bits and pieces of a systems, and not be discouraged by the gaps and holes. When the whole picture isn’t there, I have more trouble staying focused, however this also fuels a drive within me to fill in every gap I can.

2) Teaching others. The second strength comes from feedback I have received after pairing with colleagues. It’s something that I wouldn’t naturally accredit to myself, as I’m not sure that I will ever have perfected this skill. It’s certainly not an easy task, to teach others, and efforts can be easily mistaken for judgment or criticism. The style of teaching must change from person to person, and it’s almost impossible to accomplish unless the student is willing. However, if I can get them to a place where the thought enters their head “I can do this”, then it’s just a matter of how they get there.

3) Attention to detail. The strength takes form in multiple ways. The first is when I’m pairing in a language I’m not very familiar with. The attention to the details allows me to help find bugs in code through comparison with examples or references, even when I’m not sure what all the code is doing. The second area this strength helps me is in an appreciation for good testing. I think the ability to test functionality and think up all the outlying situations is something I am able to do better with my attention to the detail. Being able to question ‘What happens when’ involves a great understanding of all the small scenarios, which could overlap to cause a problem.

Each of these strengths can be complimentary to someone else’s. Someone who can take in the whole picture, someone who keeps things moving and doesn’t loose sight of the goal when there’s teaching to be done, and someone who can move quickly without worrying about the details. I don’t think that I can’t also become these people, given then right environment, but I’m not them yet. For now I am content in sticking with my strengths. It can be hard enough for me to not conform to others styles in leading, teaching, or even pairing. However, to be able to realize that I may be there to tip the balance from time to time away from their strengths is something I am still learning how to do.

New Year means New Authors

Kate Moczydlowski
I’ve been a Consultant with development tendencies at Thoughtworks since September 2011.  I’ve never been one to say no to learning or trying something new.  I have an eclectic range of interests ranging from: writing poetry, to dancing,  to classical literature, to cooking, to the dissection of movie plots, and most likely anything remotely technology related. I’ve been developing for as long as I have had an internet connection, because who didn’t make a geocities page back then? I work hard and take great pride in everything that I do. That’s a nice way of saying I can be a little bit of a workaholic. Trying to find that balance is something I find myself really trying to achieve and am ever curious how others do.

Now I am not a person who likes to define herself too much. I like being abstract and open to change. The few traits that I choose, or at least hope, to define me are my kind heart, an open mind, and a childlike curiosity(mentioned above).  I have a passion for making the world a better place everyday, even if it is just by giving a stranger a smile.  I think there is something so powerful in something so simple as a smile or a laugh. 

I am excited for what the future will bring, through the challenges and triumphs the experience is what makes us who we are.  I can only hope to experiences ahead help me move the mountains I want to move and create a ripple in time.

Abby Bangser
I joined ThoughtWorks in March of 2012 as a Quality Analyst. In college, I majored in political science and worked in real estate investments for over 3 years. My investment job showed me how much more productive a person or company can be when utilizing technology properly. Soon web scraping and excel macros were just not enough to maintain my interest, so I looked to move into even more code. Software development is a field that I can see staying in for a long time, since it will not only continue to challenge and excite me but also provide me with a chance to do great things in the world, especially through ThoughtWorks' social impact work.

In my free time, I am an avid traveler. After college, I got my Dive Master certification in scuba diving, which has provided an amazing added perspective to my trips. At home, I love coaching as well as playing as many rec sports as possible. Have to say, dodgeball and kickball are arguably be the best out there!


Apryl Gordy
My name is Apryl Gordy and I joined ThoughtWorks June of 2012. Before that I was hard at work at IUPUI (Indiana University-Purdue University Indianapolis) majoring in Mechanical Engineering Technology. While attending classes I was active on campus with many different student organizations that focused on changing the world we live in while accepting the differences amongst us. My love for dissecting technology and piecing it back together, along with my hope for a better social and economical just place of living, all lead me to accept a position at ThouhgtWorks as a Developer. The promise of continuous learning, improving, evolvement and challenge keep me here..along with the beautiful smiling faces you see everyday.

In my spare time, I enjoy traveling. I’ve had the pleasure of visiting 38 of the 50 states, and 7 different countries within 3 different continents. I love music and have been able to call myself a drummer since the 5th grade. In addition to that I am a lover of electronics, cars and sports. So if there is either a carshow, NBA or NFL game, drumline or electronic store in the vicinity, you better believe I’m front row center drooling over the magnificence.

Sarah Hutchins
I joined ThoughtWorks August of 2011 as a developer coming from a computer engineering background. Whilst in college I pursued a variety of interests, always trying something new. This combined with my hope for humanity caused me to pursue a career at ThoughtWorks. I enjoy the traveling and the challenges presented by the variety of projects ThoughtWorks takes up.

Outside of traveling, I enjoy spending my time doing outdoor pursuits such as biking and hiking. I also usually have a couple instruments on me which I am in the process of trying to learn in my spare time.

Are We There Yet?

The 2012 theme of the Grace Hopper Conference was 'Are We There Yet?'. The Agilistas wanted to take a look into what this question meant for each of us, and how we would propose to begin answering it.

Linda:

I want to talk about teams I have been on, and their gender diversity, and my observations on how it affects dev work.

On my current team, we're half female- including the dev team! Our tech lead is female. Our product owner is female. It is very different, and I enjoy it a lot.

Instead of making small talk about football and cars, we talk about haircuts and volleyball and being a girl scout troop leader. Mentioning that I like someone's shoes gets agreement, not disdainful looks. (I have a strong memory from a previous project of someone saying something like "Jeez, girls always talk about shoes." )

It is comfortable. I'm not sure why; I think it has something to do with subtleties of communication style. That said, I don't think that our communication is not noticeably better than on any other project I have been on.

We don't have "cat fights". (I seriously cannot believe that I was asked that by an industry professional, however jokingly.) There is not backbiting. We are not catty. We are professional. We get work done.

A few projects ago, I was on a briefly all-female dev team. I think this is a phenomenon which is only likely to happen at ThoughtWorks, and even here it's an oddity. I think that our communication was excellent. Perhaps we spent a little more time on arts and crafts setting up our card wall than other teams do, but it didn't impede our progress. We were very collaborative. I don't think that all-female teams are a good idea, just as I don't think that all-male teams are a good idea. Diversity of viewpoint is valuable.

Being the one female on a team of all male devs is awkward. Even if no one says anything scathing or accidentally sexist, the feeling of realizing that you are the only person in the room without a beard does not make up in amusement value for what it offers in winceworthiness and isolation.

Amanda:

Lately, I have been having more discussions on whether or not it is alright if we have a 'women only' event. The common response, as childish as it may seem, is if there can't be a men only club, you can't have a women only club. The difference is, that most of us live in a men only club.

Most project teams I have been on have been majority male, and most of the time I have not minded that. I have no problem being one of the guys, and sometimes I do prefer to not have so many women around. However, the problem of being surrounded by mostly guys always seem to come back when I need someone to talk to.

And I have been astounded by how many guys are ready to start that conversation. It is truly amazing how many guys do want to hear what it's like being a women in technology. How many men want to be part of the support network, but not all of them know where to begin. It is up to us, in the end, to be able to explain what it's like being women in technology. However, to figure out exactly what I'm feeling, does take a support network of women to be able to talk to, hear stories from, or just be with.

We don't want to have to put up a sign saying 'No Men', but the fact is that we just aren't there yet. These conversations need to start small, and it takes time. So for now, we will continue to have our women only club meetings. Because without meetings like those, voices like these might not be heard.

Megan:

No! I get excited when there are other females on my team, I get downright giddy when I hear of another female developer walking anywhere near my team area. Downright giddy I tell you.

We are far from there.

There is talk about this gender gap in technology, big talk happening often.. which is amazing. But to make change, to get there, we need small talk. We need talk in our project teams, we need talk in our offices, talk between women, talk between men, talk between men and women. This is one (of the many) things I love about ThoughtWorks. We are having these conversations. And I’ve been surprised to learn that men don’t understand what it’s like being a female dev, and even more so.. that they are actually interested in understanding, so that as a team we can make better software.. together.

Then we need actions, small actions.

The gap is there because of reasons that start way before we start our careers. So we all need to think about how we're talking to little girls (and boys for that matter) each day. Whether directly related to how we talk to little girls or not, studies have scientifically proven that gender bias is real. And we’re all guilty of it, whether we realize it or not. So please, let’s realize it. More so, let’s make a conscience effort to reevaluate how we’re judging our colleagues based on their gender in the field. We need to think about our hiring practices, are you removing the names from code submissions before you send them out for review?

Ladies, we need to find our own voice and then to help other females out there find theirs. Other studies have shown women are less likely to speak up in a group of men. And I believe that once women have been given “permission” to speak up, they are much more apt to do so. Give your fellow female colleagues permission, and then make sure they know they don’t need it. Make it an expectation in your workplace that they will speak up.

There are so many avenues to read about us not being there yet. My plea is that you take it one step further. Figure out how you can contribute on a small scale, even if it’s just a conversation with one other colleague about the issue, or rethinking how you talk to a little girl just once. Until then, you’ll find me practicing my ninja skills and kidnapping female dev’s from other teams so I can work with them on my own.