MA Conference for Women 2019 || Experience & Tips

Hey guys! There were roughly 12,000 attendees at the MA Conference for Women last week and I had the wonderful opportunity to be one of these attendees on behalf of my company! (I am an associate software engineer for those who may not know.)

IMG_6251
At the Reebok “It’s a Woman’s World” Booth in the Exhibition Hall

I took the train into Boston and was at the convention center all day long with booths to see, sessions to attend, and people to meet. When we arrived, we received attendee “swag bags” filled with snacks, a water bottle, the event guidebook notebook, and other miscellaneous items.


Tips on how to make the most of the event:

Processed with VSCO with au5 preset

luckily I was warned of these, i’m now queen of the event
  • Arrive early: by 7am to head into the line or else you’ll have to spend time outside in the cold waiting to get through security and this way you’ll be one of the first to grab breakfast (free) and hit the booths down in the exhibition hall
  • Skip the coat check–bring a warm enough but lighter jacket to carry or else you’ll have to be in line twice and there’s sooooo many coats in the coat check
  • Use the womens restroom: I know, like isn’t that obvious? They actually convert a bunch of the mens restrooms into womens restrooms for the event, but the permanent womens restrooms have a lot more stalls. I accidentally waited in line for one of the converted restrooms for a long time only to find there were only 3 usable stalls and the other half was urinals!

 

Overview of Events and Sessions I Attended:

full schedule hereIMG_6168.jpg

Opening Keynote Session

IMG_6331Featuring Simon Sinek, Amanda Southworth, Yara Shahidi, and others; we were welcomed to a day of reminders that we can kick ass!!!

  • Sinek focused on the infinite game: explaining how learning from our competitor and using what we can study from them could help us become better ourselves and get stronger (and vice versa).
  • Southworth told her story of mental health and how coding not only helped herself but enabled her to help others too.
  • Shahidi is asked a question and answers with how she was taught at an early age about financial independence and how to be smart about money; saving it, spending it, and donating it.

Exhibition Hall (ft. sponsor booths, small business marketplace, and roundtable discussions)

Processed with VSCO with a5 preset  Processed with VSCO with a6 preset

  • So. Many. Things. Being. Given. Away.
  • And so many photo opportunities!
  • Essentially, I came home with (on top of the swag bag stuff) a T Shirt, schrunchie, button pin, mirror, mints and lip balm, crystal nail file, travel brush and sewing kit in one, pens, magazine, candy, and more!

Unplugged: Reclaiming Balance in a Connected World (POE)

Screen Shot 2019-12-21 at 4.11.15 PM
(from left) Tiffany Schlain, Mary Laura Philpott, and Stephanie Humphrey
    • This was an interesting panel session on unplugging from the social media world, turning 24/7 into 24/6.
    • Tiffany Schlain (filmmaker, founder of The Webby Awards, author) talks about a “tech sabbath” of sorts that her family has done for almost 10 years now where they unplug from their devices for one 24-hour period a week and focus on the present.
    • Mary Laura Philpott (author of I Miss You When I Blink) catches attention from the Type-As of the room, those who love lists and getting things done once they’re started. It’s her journey of accepting that our time is our time and it’s okay to take it back to do what we want.
    • Stephanie Humphrey (technology and lifestyle content creator) discusses how she tries to unplug even with a career that consists of being on social media. Setting time for planning in one period and then scheduling posts is a must.

The Likability Trap: Women, Leadership and the Double-Bind

IMG_6332Alicia Menendez, asked us a question: do you want to be likable or do you want to be successful? Her answer is to ALWAYS. CHOOSE. SUCCESS. People will always either like you or not like you for various reasons and it should not hold you back from reaching your goals.

  • Yvonne Garcia, Minda Harts, and Erica Keswin joined Menendez in discussing their own experiences of having to choose between being liked or being successful in their workplace and the feedback they have sometimes received from it.

Keynote Luncheon: Malala Yousafzai, Tara Westover, Megan Rapinoe

IMG_6333

All of the women involved in the keynotes, panel sessions, and other discussions have all done something to be recognized as leaders, mentors, or just those to look up to. During the keynote luncheon, we also were lucky to hear from Malala Yousafzai, Tara Westover, Megan Rapinoe, and others.

  • Yousafzai spoke of her journey that most of us have heard about (if you need a refresher) and how her father continued to push for her education when extremists who took over their town banned girls from school and how it has developed her into the strong woman she is today. She continues to fight for 12 years of education for girls in countries who are less able to receive the opportunity.
  • Westover joked about how her job is to be a professional narcissist, telling her story about how she was raised in a family that did not believe that the government, education, and other things were genuinely real (instead seen as a conspiracy). She eventually went on to being enrolled and educated at the age of 17 and then went on to get her PhD.
  • Rapinoe was her authentic self with Kara Swisher; it was highly entertaining to listen to them discuss important topics like how Rapinoe was fighting for equal pay among professional soccer players (ex. how the womens soccer team is not compensated the same as the mens soccer team), the upcoming election, and various other topics.

While leaving the convention center, I realized that I was feeling so empowered, a feeling that I had not felt in a while. It makes me want to continue to chase after it all.

I’m hoping to get the chance to continue attending The MA Conference for Women and other events like this! The 2020 Grace Hopper Celebration for Women Technologists is also on my radar and I can’t wait to launch into this potential opportunity!

QAn’t Wait to See You Again

CS SERIES (16)Before I dive into my final installment of this CS series (for now), I wanted to say thank you if you actually read any of these posts and thank you to my new followers for dealing with the notifications you must have gotten.

For this last post, I wanted to discuss the article 5 Reasons You Are Wasting Your Testing Time by Joel Montvelisky. The author expresses how everyone can do testing but not everyone can do “good testing,” which incorporates more than just what is basic checking.

A short list of main reasons why a lot of people tend to waste time that could have been spent testing other things includes:

  • Not having clear goals
  • Not understanding what or how much the feature means to your End User
  • Not keeping track of what was tested and potential discoveries
  • Not consulting what you already know or using references
  • Not giving feedback that could be shared to help others

Sam CS (22)I agree with most of what Montvelisky says as I have personally noticed what has happened from my experience as a Software Quality Assurance Intern when any of the five things above took place based on a task. It is important to understand that sometimes these things may be out of your control but you should still try your best to avoid miscommunication wherever possible.

Montvelisky’s content has not necessarily changed the way I will work as I have already been consciously making an effort to understand what I am reviewing, how stuff is meant to work, logging tasks, connecting tasks to previous occurrences, and communicating with the QA team. If I had read this article before I started working, it would have been more useful as it would serve as a foundation to how one should think of testing beyond the basic functionalities.

Something I wanted to emphasize is the post-test reviews and feedback sessions with peers. I found that if someone else needed to learn about a project or a task had to be communicated with a client, logging any kinds of notes or information was better than not having anything prepared to discuss. They do not necessarily have to be posted for everyone to access but it would be good to note it in any sort of text editor for future reference. I think an example of when to note things is if you found something that does not prevent your current task from being approved but it still affects something for the overall program.

Overall, when testing things I believe you should trust your instincts on reporting things you find. It helps when you try to imagine how much it could affect a program in the long run if not brought to someone’s attention, even if it may seem minimal.

Best of Luck,

Sam


Article: https://qablog.practitest.com/5-reasons-you-are-wasting-your-testing-time/

Adapt or Git Left Behind?

CS SERIES (15)As my last fall semester comes to a close, I wanted to write about an article on something pretty interesting I learned about in my software construction and design course.

On Stackify, Thorben Janssen wrote Design Patterns Explained–Adapter Pattern (with code examples). Overall, this article re-instilled how design patterns make it easier to write more well-structured and maintainable code.

I found it useful to see how Janssen discussed the two different versions of the class adapter; the class adapter pattern (which implements the adapter using inheritance) and the object adapter pattern (which uses composition to reference an instance of the wrapped class within it).

Similar to how we learned the concept in class, something I appreciated is the “real-life” example or comparison used to describe the physical adapters we use when traveling. When we are traveling and do not have compatible power sockets, we must find a way to be able to charge our use our devices without having to change the whole make of it. A way of doing so is by using adapters; which does not change the overall product or device, it just allows you to be able to plug it in.

An situational example that I can think of when explaining adapters is if you have ever been zip-lining or done a ropes course (like Go Ape) where you are attached to a harness. When you are transferring from one line to another, you can use a metal contraption which helps guide you while connecting and disconnecting from paths. That metal contraption serves as an adapter, not changing what you are but allowing you to use something.

I agree with what message Janssen is trying to express about how great design patterns are (the adapter pattern specifically) when it comes to writing code. His content allowed me to think about real life situations in code form when he introduced the basic and premium coffee machines to brew coffee using the adapter pattern. One of the best ways of learning concepts, in my opinion, is to compare it to a real-life situation and then show people visualizations to help them better understand what you are trying to explain and the article did both.


Article: https://stackify.com/design-patterns-explained-adapter-pattern-with-code-examples/

Test Yourself Before You Wreck Yourself

CS SERIES (14)Testing, testing. I may need your approval on this article I read by Software Testing Magazine on Approval Testing. Approval testing, as defined by this article, is a way of software testing that results in presenting the before and after of an application for a user (ex: software development team) to review it and potentially approve it. It’s more of a visual representation of testing and one of the major cons is how the results have to be checked manually.

Some testing tools mentioned include: Approval Tests, TextTest, Jest, Recheck, Automated Screenshot Diff, Depicted (dpxdt), and etc.

The main purpose of the software testing tool, using TextTest for example, is checking that the text output after running program from the command line in different ways.

What I found interesting is how a user can see that a test technically could have “passed” or “failed” but still decide to mark it as the other because they choose what feature they are looking for in the end. This makes it a little more flexible to use approval testing as it is more of a guide or guideline for a user instead of only seeing one word and then a short description of what could have gone wrong. I think this process is much more transparent or descriptive with a user about what could have gone wrong or what went right.

One way the content has changed how I will think about the testing is how there are so many more types of software or programs out there than we can imagine which help us better code or create our own software and programs. This one is especially good for visual coders and testers who like to see their results firsthand to compare what they are expecting with what they actually got.

Overall, I found this article was useful because it introduced me to thinking about a better way of logging the differences between what the reference result is versus the actual result. I did not disagree with any of it since it showed us how we can use approval testing to our advantage while still being honest about its limitations.


Article: http://www.softwaretestingmagazine.com/knowledge/approval-testing/

Top 5oftware Architecture

CS SERIES (13)When using architecture patterns, how will you know which one to choose? Peter Wayner, an independent author for TechBeacon takes five architectures that the majority of programs today use and broke them down into their strengths and weaknesses. Through this, it seems like he is hoping to guide users to selecting the most effective software architecture pattern for their needs.

If this article does not clear up enough information, Wayner also brings up a book, Software Architecture Patterns by Mark Richards, which focuses further on architectures commonly used to organize software systems.

The fives types discussed in the article are:

  • Layered (n-tier) architecture
  • Event-driven architecture
  • Microkernel architecture
  • Microservices architecture
  • Space-based architecture

The one I found most interesting is space-based architecture because at first when I thought of space, I was thinking of the other kind. The one with the sun and the stars and the moon. But then I realized–what does that have anything to do with software architecture? Space-based architecture is listed as “best for high-volume data like click streams and user logs” and I think this one is pretty important, especially during times like Black Friday and Cyber Monday. I personally experienced the frustration of not being able to access a site (adidas) due to high volume and it really does not help a business.

Another architecture I found thought-provoking is micro-services architecture because of the way Wayner introduced the concept, “[s]oftware can be like a baby elephant: It is cute and fun when it’s little, but once it gets big, it is difficult to steer and resistant to change.” The author providing an example of this made me think about how a site with so many users and things happening at once actually just had many different separate services but they were put together as one. I was a little surprised to think of Netflix in that way after all the times I’ve used it but it makes much more sense now.

Overall, I found all of the information pretty useful and clear to understand as Wayner described what they were and then listed the caveats and what they were best for. I would recommend using this as a reference or quick review of common software architecture designs if someone needs it.


Article: https://techbeacon.com/top-5-software-architecture-patterns-how-make-right-choice

Nice Demete[r] You

CS SERIES (12).pngThere are lots of “rules” we must follow in object-oriented software development and the article The Genius of the Law of Demeter by Javadevguy summarizes how they are useful. From what I put together, it seems like the Law of Demeter took abstract concepts and basically put them into a universal set of rules for Object-Oriented code.

I thought that the law of demeter must be a big deal if someone decided to sit down and write a lengthy blog post about it. This content ended up being interesting as it tried to convince readers why they should obey this “law.” The Law of Demeter basically paves the way for what users can do to a given method. It is kind of like considering the restrictions or possibilities based on the method. One of the takeaways I got from this is how there is a lot of focus on communication between two objects.

Sam CS (18)

The rules listed in the article are as follows–noting that it says “For all classes C, and for all methods M attached to C, all objects to which M sends a message must be”:

  1. self (this in Java)
  2. M’s argument objects
  3. Instance variable objects of C
  4. Objects created by M, or by functions or methods which M calls
  5. Objects in global variables (static fields in Java)

Another useful takeaway I got from this article came from observing the code examples Javadevguy included; how Rule #1 covers that any method can be called on the current object. I also noted when there would be an instance where the law would prohibit something is not “sending a message” to any already existing object that is held in instance variables of other classes.

This will affect the way I continue to do work as an Object-Oriented developer. I mean, in life when you learn there is a more useful or structured way to help you achieve more effective results, you would want to try or follow it, right? For my future use, I will acknowledge (like other blogs and articles) that the Law of Demeter is less of a law and only a suggestion or a guideline.

Overall, I would say that the content has helped further solidified my understanding of some Object-Oriented coding concepts. I agree with the content as it is trying to help people become better developers or better understand the Law of Demeter in general.


Article: https://javadevguy.wordpress.com/2017/05/14/the-genius-of-the-law-of-demeter/

Is Your Interface Two-Faced?

CS SERIES (11).pngWhen coding, users always have to be conscious about the way their code may be implemented or used in the future by different services leading to potential misuse. After reading Code Health: Make Interfaces Hard to Misuse by Marek Kiszkis, it made me think about how important communication between testing code is.

I found this content useful because Kiszkis featured some examples that can show how an interface could be misused easily. The examples included:

  • Requiring callers to call an initialization function
  • Requiring callers to perform custom cleanup
  • Allowing code paths that create objects without required parameters
  • Allowing parameters for which only some values are valid, especially if it is possible to use a more appropriate type

Sam CS (17)It is also good to remember that at the end of the day, code should be defensive but not too defensive to the point that complexity is increased and performance overall is reduced. Kiszkis says “it is not always practical to have a foolproof interface” because there will be situations where some requirements are things that cannot be expressed in an interface.

After seeing so much content based on being careful about what you code it is surprising how this article says it is not necessary to plan too hard. I kind of understand why Kiszkis would say this but personally, I kind of disagree with this. The reason why I disagree is because if someone does happen to end up with more time to work on something than expected and they know it will make something more efficient, then why not go for it?

Overall, I appreciated what was shared in this article in terms of encouraging users to try and see issues that can arise with their code when it comes to interfaces. The main takeaway for me is that if something is brought up, or triggered by undefined behavior, a user should try and make it impossible for this to happen. A way of doing so is by adding things where necessary, like certain slots in his example. It does not have to be too specific but detailed enough so that it covers different aspects, similar to how we try to prepare for everything when it comes to equivalence class testing.


Article: https://testing.googleblog.com/2018/07/code-health-make-interfaces-hard-to.html

 

[W]in Tech

CS SERIES (9).pngOver the weekend, I had the chance to sit down and listen to another podcast episode by Developer Things. The title, Women in Technology (with Megan Horton), caught my eye as I am always on the lookout to learn about other women’s experiences in technology.

The podcast series’ goal is for people to learn new developer things each time they listen so here’s what I learned on the career side related to software construction, design, and architecture:

  • The stigma of “nerds” begins in elementary school so girls start to stray away from STEM even in the limited amount of programs there already are for computer science in earlier education years. This eventually results in the number of females in CS in universities–like mine–is so low along with the numbers of those who move onto the software development workforce.
  • There are jobs out there like writing software for watering fields based on whether the sun is up or down or varying weather conditions. It reminded me a bit about how we used duck stimulator as an example to learn UML diagrams and had different actions performed for each duck.
  • Career advancement is not always a straight path. People tend to switch into computer science as a major or switch into technology when they want a career change. I’d like to point out how the host of this episode took the opportunity to say Horton came from the funeral business to killing software bugs.
  • You won’t always have to write code: there’s so much out there–you could have a passion for anything and do something tech-related in that setting.

The content has caused me to think more deeply about what I will do in technology, I mean of course I’m going with software development or software engineering but what is the overall goal throughout my career timeline going to be? What kinds of companies will I end up working for? What projects or passions will I follow along the way? Overall, I enjoyed the podcast with Horton as she discussed the ups and downs of being a female in technology and her experiences in the industry so far.

I don’t think I was there for the time when people would be kicked off the internet because someone needs to use the phone as discussed in the episode but I do experience times when my connection isn’t consistent. It really makes me sit back and think about how technology relies on constant power and a steady internet connection.

A major takeaway that I continue finding myself writing about is how we will always be learning something new in technology as things are always changing–as long as the power is on.


Podcast: https://stackify.com/podcast-women-technology/

Hey Siri, Google This

CS SERIES (8).pngImagine being several years into your role as a developer; you’ve had a long week, a big project to push tomorrow and suddenly… you’re stuck on something. And you’ve double-triple-quadruple checked to make sure everything is working by code review but you cannot put your finger on how it is not quite perfect. What’s wrong? Let’s find out.

This is the first course-related podcast I’ve listened to for a blog post and if this is one of the only podcasts you will listen to, I recommend this one.

Jonathan Cutrell started off the podcast by saying “If there’s one thing that makes developers self-conscious it’s probably their googling history–more specifically things that they google that they forgot how to do.”

People can talk about code for days but they do not talk about the toll of what a developer thinks of themself when they are stuck on a part of their code or need to rely on the internet for something. This honesty makes it easier for university students and entry-level developers to understand the pace they are learning at is their own and that not everyone is perfect at coding even after years of experience.

Something that changed the way I thought about this is how important it is to know the pattern or routine of a concept. Things Cutrell says great developers care about is how understanding patterns and principles transfers but not necessarily the actual code itself. “Great developers” focus on the overall concept instead of wasting time on the small details of a language.

Due to this thinking, I realized I never considered how a developer can be the best of the best in one language but if they had to convert it into another language, the translation would be a little different. The real life comparison to this would be if someone were speaking with broken English. This does not mean they are not smart in any way, it’s saying that they are focusing on the main idea instead of a small detail they are trying to get through. They use their time more efficiently by moving on to a big concept instead of worrying about the syntax that they can easily google.

Overall, I appreciate what this article brought up as I was expecting it to be about just googling things but it dug a little deeper and mentioned what a good developer should focus on.


Podcast Episode: https://spec.fm/podcasts/developer-tea/204292

WWJD? What Would JUnit Do?

CS SERIES (7)A few weeks ago, I was introduced to JUnit testing in my Software Quality Assurance & Testing course. The blog post tutorial linked below is one I would recommend to those interested in learning about assertion. Reading this post has helped me review the concepts I have learned and I will share what helped me better understand the topic of writing basic assertions with AssertJ.

I found this content useful as it started off by covering whether a user had Maven or Gradle for declaring the dependency and then we get to dive into scenarios when a certain feature would be used. Some examples of what you can test with assertions includes: boolean values (true/false), whether or not something is NULL, comparing the result with a number or string (EqualTo()), object references, and arrays that are equal.

There is a walk-through of what we want to test with a basic scenario of when we would want to use it and this information makes me appreciate how much this kind of testing helps simplify things. It adds more structure to what we would like to do and by being able to import it, saves us so much more time in the end.

Honestly, in class I tend to spend more of my time trying to follow steps instead of absorbing what the material is and this article really helped me realize things like “oh, so this is why we use this line of code” or “so that’s why this is always there.” As a visual person, I appreciate the articles which actual include code examples for us to see what’s being used or added to explain a concept which was very helpful in this case. I do not disagree with any of the content provided as it is much more technical and there is reasoning behind each part of the process.

Overall, I would keep this article bookmarked and may come back to use it as a reference whether it be for a future testing assignment or just for trying to refresh this in my memory. As a side note, installing gradle on our laptops in class enabled us to run our tests through the terminal which was a pretty cool experience.


Article: https://www.petrikainulainen.net/programming/testing/junit-5-tutorial-writing-assertions-with-assertj/