Continuous Improvement: Work

Preface: Asynchrony (my current workplace) started a beta test of their advocacy program last fall.  The advocacy program is “a program in which an employee guides a colleague in career options and feedback and advocates for career growth.”  What this really means is that you pick an advocate at work, and talk through your day to day job and career growth with them.  Your advocate encourages you to solicit feedback from your colleagues as well as act on the feedback and make goals in order to continuously improve yourself.  My advocate is immeasurably helpful and just plain awesome.

There was a company-wide meeting last week, and one of the founders talked about the importance of continuously improving.  He said that you should always be able to answer the question: “What are you improving on?”  One of the things he talked about was the importance of being open about what you’re trying to improve — if everyone is open about it, they can help each other improve.  Overall, I found the talk to be incredibly inspiriting to fight against inertia and work on improving myself.

I wrote my year-end review in December and made only a couple minor modifications so that I could post it online.  I am very nervous about posting it online after various coworkers remarked that future employers would view this negatively.  However, I know that I would have liked to read other people’s reviews to get a good idea of what to aspire to and to see their progress over time.  I also realize that I do not want to work for a place that does not value honesty about areas in which I can improve.  Without further ado…

I’m really glad to be back at Asynchrony.  I was able to receive reviews from people I worked with over 8 months ago and from people on my current team.  This allowed me to see my progress in the past year as well as comment on goals from last year’s review.  Overall, I am happy with my ability to collaborate well with others, approach issues with positivity and perspective, and break down problems in a way that make them adapt to change well.

This year, I am proud of:
-My dedication to being client focused – Both my team lead and my executive sponsor commented on my ability to listen to the client for what they want/need and then help them prioritize it.  At demos, I always take note of minor tweaks that they want and find time to squeeze them in.  While my team and I focus on getting major features done, I consistently try to implement most of the smaller details that the client really wants.  Many of my team members have commented on how I maximize time spent coding that results in rapidly increased customer satisfaction.

-Driving features to completion with a commitment to maintainability – [the client] will be taking over the iOS app that we are creating for them with their current team of developers, who do not have any iOS experience.  When we make decisions as a team, I find myself reminding everyone that complex written code is not  easily understood by iOS novices and that we need to find a solution that is consistent across the code base, as well as easily explainable and maintainable.  This commitment to simple architecture does not only help our client, but it helps us as well to stay organized and quickly implement new features.

-Commitment to teach others – I am giving an iOS Accessibility talk as a Lunch And Learn to the QA team.  Over the past year, I have become very knowledgeable about the challenges of a variety of disabilities and how the iOS framework tries to mitigate these impairments and provide a quality experience.  In particular, people with visual impairments often use VoiceOver on their iOS devices.  Many developers and quality advocates at Asynchrony, and elsewhere, do not realize that they are responsible for adding content to apps to make them amenable to VoiceOver.  It is not a priority to add accessibility to the app in the current project I am on, but I feel that it is a responsibility on our end to be committed to making our code compliant with Accessibility Guidelines.  I personally will work extra hours on my own time to add in accessibility in my current project. My goal is to increase awareness about iOS Accessibility features and mentor my peers on the ease of adhering to Apple’s Accessibility Guidelines.  Besides teaching other developers about accessibility at Asynchrony, I am mentoring junior level software engineers outside of work. Additionally I am teaching classes for Software Carpentry, a non-profit that has programming/testing/version bootcamps for scientists.

Progress towards goals from last year:
-Confidence – Both from reviews from members of [my previous] team and from my year-end manager one, it became evident that there is some room for improvement on my side when it comes to having a rich theoretical computer science background.  I struggled with leading a pairing session with more aggressive developers.  In the past year, I have been able to work on iOS projects by myself and with other developers and become more confident in my iOS skills.  A year ago, I would cede control of the keyboard to other developers that I viewed as more qualified.  Now, I can come up with a plan of attack for a story and be equally as active as my pair.  My experience in creating the iOS Bootcamp at Asynchrony and being responsible for the entire life cycle of an app at a different employer, helped me rapidly gain confidence and experience in the iOS realm.  One of my recent reviewers remarked: “As a pair participant, I think you do well as both driver and navigator as I’ve seen you work with senior developers as well as novice developers with ease.”  One of the benefits of the advocacy program is that I can get positive feedback which helps my confidence as well as helps me trust others enough to make mistakes and try again.  This confidence also helps me stop second guessing myself and contribute more towards architecture discussions.

-Test-driven development – A year ago, I felt comfortable writing code and testing the code after the fact. My test writing abilities have evolved to the point where my tests are meaningful and they help drive writing easily readable and maintainable code.  After starting on [my current team], I was exposed to stubble, an iOS testing framework.  I picked stubble up easily, and test-driven development seems more natural to me. After a couple pairing sessions with my team members on [my current team], I was able to pick up on how to properly segment code into small, easy-to-understand chunks that are readily testable and lend themselves nicely to mocking.  I quickly learn from example tests and exemplary pairs, and this experience has made me feel really comfortable with test-driving code as well as isolating challenging areas and working through them to make them testable.

-Picking battles – As other many inexperienced developers, I did not have perspective on what battles were the important ones and what battles were not worth the energy.  I rapidly gained this experience in my time away from Asynchrony because corporate America is full of battles.  The team as a whole on [my previous team] loved to argue, and I was not immune to that.  One of my reviewers from the past commented that one of the growth areas for me is to learn to apply a more dispassionate approach to solving team and technical problems. I try to be very conscious in discussions now to come up with solutions to problems, instead of dwell on the negatives of a project.  A few of my more recent reviewers have noted: “you have been able to see both sides of the argument and I think your opinion tries to consider what the best option for the moment is. You do not pretend to be in love with the code and makes for a real objective viewpoint in my opinion.”  Personally, I still strive to find a good middle ground towards being passionate about a project but not letting that interfere with delivering a quality product to the customer within their requirements.

What I need to improve on:
-Design patterns – As compared to last year, I have a better understanding of the primary iOS design patterns.  Most of my reviewers noted that there is room to learn more design patterns, especially those used in other languages. This will allow me to gain perspective on the pros and cons of different languages as well as the tradeoff and impacts of the design patterns themselves.  I have multiple design pattern books, and I make it a point to research new design patterns I come across while pairing with others.

-Diving into complex architecture – Current and former team members have commented that with time, I will gain more exposure to more complex architecture.  Currently, I have deep knowledge of the core data stack in iOS projects, but I lack a deeper understanding of the security and networking layer.  I have been trying to remedy this in my current project by taking on complicated tasks that involve expanding the network layer.  I am committed in being highly involved tackling harder programming problems, instead of shying away and letting the more experienced developers solve the issues.

-Knowledge of databases and web/server programming – The majority of my experience in programming is writing data analysis scripts in Python and writing iOS code for iPhone and iPad apps.  On [my past team], I got a taste of backend programming, which made me aware of my lack of knowledge in that space.  I have already taken steps to amending this. My first step was to team up with an experienced server-side developer and have them explain certain best practices, their pros and cons, and how one could improve based on that knowledge.  I have also been asking other experienced backend developers to explain the basic concepts for REST-ful APIs and database structures. My personal project this year is to create an iOS app that communicates with a REST-ful backend service.  I develop a feature in the iOS app and then build out the corresponding back-end component. Since I am an experiential learner, I believe this will be the best approach to get some exposure to backend development and come up with more advanced questions and concepts in the future.

-Communication – Already, I have been asking team members to explain their thought process more than I had previously.  Some of my team members have noted that I ask questions without fear and do not pretend to have knowledge about things.  However, I feel that I can improve my communications by continuing to ask questions when I do not fully understand something.  My percentage of asking questions has increased over the past year, but I am striving to make it even better.  I can also improve my communication with more aggressive pairs by not backing down when my pair is dominating the pairing session.  While I have definitely improved on typing more during a pairing session, I often can be intimidated by certain pairs and allow them to overrun me.  I am soliciting suggestions on how to remedy this situation, and I am actively trying to implement them.  To battle my fear of failing and fear of inconveniencing my pair, I am working on communicating plainly with my pair about my hesitations early on, so that they are known and we can work through them together (and hopefully my pair can open up about their fears as well).  Lastly, I should communicate with my team and the client better so I can improve my story writing skills.

Personal goals:
-Complete an iOS app and submit it to the app store – I am currently working on two projects at home.  I hope that I can complete one of them from start to finish and publish it in the app store in 2015.  I would like to have a professional designer style the app as well.

-Become a team lead (long term goal) – I enjoy leading a customer to a better product while not overcommitting our developer team.  My personally type is well-suited towards trying to understand people’s motivations and short-comings and trying to help them become better team members. On my current team, I am often the middle person between the developer team and the client by giving both sides perspective on what is important.  I currently lead a large portion of our demos to the client and talk to the them about what we can commit to every week.  I would love to have more experience leading meetings and driving expectations to be within the scope of the statement of work without alienating the customer.  I need to work on my ability to keep a team motivated to do their best work within the constraints of the customer, the budget, time, quality, and unexpected problems as well as understand how to make comfortable tradeoffs.

-Continue being passionate about my project and making work an enjoyable place for my team members – I want to help my team members stay positive and pivot easily when changes occur.  I would also like to stay committed to quality and consistency despite pressing deadlines and lack of resources.  I want to help my team grow as programmers and individuals as they help me grow as a person.

Feedback for executive leaders:
-Commitment to Accessibility – I honestly believe that Asynchrony can become leaders in the tech scene by having a commitment to make our apps accessible.  Adding Accessibility to apps adds an immeasurable sense of quality to those that require accessibility elements.

-Opportunities to mentor and train people – I love to teach classes for Software Carpentry (2-3 day bootcamps to teach a quick introduction to programming, version control, and testing) but I always use vacation days to do this.  I wish there was a way to do this as part of my job — I already have a mentee at Asynchrony and will be an advocate next year, but I would love to be on a project that could take on a LaunchCode candidate or help out with the intern team.

-Feedback from upper management about continuous improvement/transitioning to leadership roles – It would be interesting to know what skills Asynchrony looks for when picking team leads so that I can work on honing those skills.  Examples of concrete metrics to show upper management would be helpful to show continuous improvement.

1 thought on “Continuous Improvement: Work”

  1. I love this. I agree with you that if someone decides not to hire you because of this post, you shouldn’t work there anyway.

    It’s funny that you’re thinking about backend and REST-ful things since I need to set up a very barebones database for a javascript project I’m working on. Coding buddies!

Leave a Reply to Anya Cancel reply