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.

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)