100 Days of Code, Part 1

Image courtesy Business Insider - Flat Iron Schools India

Setting short-term goals is how a Sandwich lives: something that we can fit into the myriad of interruptions that are our days. Some of them are tasks - empty one rack of dishwasher, check for issues, then continue. Others are more important.

Planning time to fill out an application can be the most difficult thing. I love the ones where it says "Submit a resume and cover letter." I can do this: if it takes me seven or eight attempts to write a letter, they need not know.

But, often times the goals have a larger purpose - I'm currently doing the 100 Days Of Code, as a goal to both make sure I move forward daily with getting a job, as well as completing classes and a couple of projects. I will try and share some of my thoughts on it as I go.

As a part of 100 Days, I'm using Twitter more (if you use Twitter, change your password!) There is a marvelous supportive group there, and a lot of sharing. I have spoken to many of the people in less than 200 words, and shared their accomplishments. And had the delight of getting the same back.

Okay, so the 100 Days is supposed to let you get the habit of working on something every day, even if it's just for a few minutes. So, I failed at that - I'm using it to get things done. This seems to be that larger failing in the world of code, at the moment.

My mentor, great man that he is, is giving me huge amounts of the encouragement and support I feel I need, and the ones that I speak to on Twitter and elsewhere are also encouraging, and share thoughts and ideas (and code reviews) that help so much. Thanks to them, I have moved to a more-productive mindset, when I get the chance.

30 Days of Postman - for Testers!

https://www.pexels.com/photo/white-and-brown-cat-lying-beside-a-laptop-and-toys-5468268/ Photo by Karolina Grabowska from Pexels Working with developer- focused tools can be a challenge for some testers: we may know what the words mean, but haven't used those skills recently enough to make the tasks simple. Or we may not have ever used them, other than at a quick glance to make sure that what we are getting matches what it should be sending. And some give results that require us to go find another team member to help interpret the results. Being a more-independent tester has always been one of my goals - being able to use the tools that are common in the team, and be able to do at least basic tasks that support my tests with them. Our team used Postman for many of the API tasks that we had, so exploring this tool was a natural fit. There are alternatives it there, both graphical and command line, so feel free to explore! The items that you can do, and tools that ...

Drop-down values for injection

cover_image: https://www.pexels.com/photo/flat-lay-photography-of-gold-iphone-on-opened-notebook-beside-pen-583847/ canonical_url: --- Photo by Jessica Lewis 🦋 thepaintedsquare Learning in public is grand, and when you have a team that is willing to help with something that seems simple, but you fall into overthink for the wrong items, it can really help to type out your thoughts, actions, and what the program does to frustrate you. And in this case, getting a value I could see in the debugger was the issue The automation needs to check for page elements – and the drop-down selector triggers potentially different elements. Plus, depending on the user logged in, there may well be different options available in that drop-down. Then, I can get the options available for the user on the drop down, get their values, cycle through them, and verify each set of elements on the page. My test account for this has four options on the drop-down, so I budgeted a couple of hours to get ...

Redefining my Role

Confession: I am a nice person. I'm the one that will check on people - and be concerned if someone is acting off. Or donate money to make sure the potluck I can't attend has everything it needs. This has had an effect on my career: I was less willing to point out 'in public' errors in the code or things that just felt off to me while testing. And this stopped me from being the best tester I could be. Trying to be kind to someone that was having a rough patch, or simply not wanting to expose them to a potential attack was both me trying to get things correct, but care for them. I've decided to embrace this aspect of myself, and shift my focus. Being 'nice' to the product, or company must include being the voice for both end users and the team. Finding things that will be difficult for them, confusing, or flat-out wrong is a major part of my job. And this was also one reason I don't 'delight', at first, when something doesn't work as expected:...

Distorted Rovings

Search This Blog