agile – WildKnitter Codes

Looking back and looking forward

The new Code Academy class is now two weeks in. They’re getting one more week than we did to complete their first projects. Also, this is one more week for the students to decide if this path is for them, and conversely for the instructors to determine who continues on with the program. I can’t decide if they’re lucky for the extra time or not so lucky, as they have one more week to agonize over whether they made the cut. Spoiler alert: other than early drop-outs, we all made the cut, as did the class before, so I don’t think they have much to worry about, if they put in the work.

I have been reflecting on what, back then, would have been good to know about the role I have now…

1. Unless you’re on some outlier team, you will LIVE the production release schedule. In training, I think we got a 1-hour overview of a typical release process. Luckily, I understood how this works from my days as a BA. However, I had NO IDEA how important it was going to be to understand all the phases, dates, and what I needed to do for each phase, especially the run-up to that crucial “Hard-Freeze” date. Trust me, you do not want to have to make any changes past that date. Your product owner will NOT be happy about having to put in a code-unlock request because of something you didn’t account for that came up in a last-minute QA check.

2. You will definitely need to understand how to test. Years ago, as a BA, I’d rail and scream when we tested a change and it didn’t work. “Don’t these people even TEST???” I’d complain to whomever would listen. I didn’t get just how hard it is to test code from one’s local using limited data. I’ve had to give myself a crash-course in updating, deleting, and creating data on the back end using SQL just to get enough data to cover the bare minimum I need to test a user story. Whatever language you end up using in your new role, I highly recommending that you become extremely familiar with whatever testing tools are available to you. I’ve shared ad nauseum about my struggles with GUnit and JUnit testing, but I’m slowing getting the hang of this kind of testing (coworkers, STOP LAUGHING!).

3. Speaking of user stories, we are pretty much all an Agile/Scrum organization now. Once upon a time, we were Waterfall which I LOATHED, both as a mainframe developer and as a BA. We all marched toward a project production date (which had changed four times) with faulty outcomes, because we just HAD to make that date—which, of course, would get changed again, due to some outside constraint. I find Agile to be better, because it’s much more flexible, and you get immediate feedback on what you’ve created so far. Instead of the dreaded “Day 2” project, you get to make adjustments and bug fixes in the next sprint. My Agile team works Kanban, which is geared toward more of a production environment—we are technically “maintenance” so this works beautifully for us. Once you get to your new team, and if they don’t bring it up, ask about Agile training.

4. Don’t be afraid to speak up if you’re having difficulties. Your team is going to be forewarned that you are a junior developer and will need some assistance. You will have a mentor to help you with basic coding issues—mine has been a God-send.

5. Eventually, you are going to be in a position to help someone else. Remember all the help that your long-suffering coworkers and mentor have given you and do your damnedest to be of assistance.

6. If you’re really stressed, walk away. Go to lunch, take a walk, disconnect from the coding for a bit. Your upcoming instructor Dana is going to tell you to do that, and when she does—listen and do it! Yesterday, I was at my wit’s end over some damned “500” errors I kept getting when running a SOAP UI project with my local machine to test my code (another one of those nifty testing tools to become familiar with…if I weren’t married, I go kiss the creator of SOAP UI—it’s the best!). Anyway, as luck would have it, I had to leave because I had a doctor’s appointment 30 minutes away, which gave me a good long break from the task at hand. After I returned, I looked at the code again and the SOAP UI results, and figured out the issue. I hadn’t brought in code that another developer had committed to GitHub that morning. Also, my SOAP UI project hadn’t refreshed for some reason. The logs showed updates from a previous version of my code. Once I remedied all this, I was able to run my code with no issues!

To sum it up, my new job has been hard, but definitely worth it. There were unforeseen challenges, but I’ve been able to persevere with the help of many incredible people. To the new class, keep plugging away, both in class and in your new jobs, and you will succeed!

You’re on all the TVs!

…or, my 15 minutes of fame.

A very BIZARRE thing has happened at my company in the past month. They are about to start up another Code Academy class for 2020, and they’ve just put out the notice on our Intranet site — with Yours Truly as the cover girl.

Perhaps I should back up. About a month ago, three of us alums from last year’s class were asked to come to Home Office (The Mothership) to have photos taken to shill for the new Code Academy campaign. We got down there and discovered that, far from being a few photos, this was to be a whole photo shoot! They had us walking around the building, carrying our laptops, looking like we were on our way somewhere important. We were coached, “Talk! Just like you would in any other everyday exchange!” I turned to the other two and said, “I don’t know about you, but our meetings are all Skype…we don’t walk ANYWHERE.” They has us sit at a desk, like we were working. They had us sitting around one of those collaborative tables, as if we were discussing something of great import—again, FAR from anyone’s reality. Any of my collaborations take place with people in Chennai at 8:00 am via Skype, or with people in the building at our desks, with someone inevitably teetering on one of those ridiculous padded filing cabinets that are supposed to double as a chair. We did all have fun with the photo shoot, and I was fairly certain my two much younger fellow alums were going to be the focus of the campaign.

But, noooo…

A few days ago, someone from another Agile team came up to me and announced, “We have a bet!” I looked at her…perhaps a bet over exactly when I’m going to self-implode from my ongoing GUnit testing cluster****? She got out her phone and showed me a picture she’d snapped. “Is this you? You’re on all the TVs in the building!” I looked and there was what had to be the worst picture anyone has ever taken of me, sitting at the desk pretending to work. She continued, “We were confused as to whether or not it was you, because that’s not your desk!” I raced down to the TV by the elevator and sure enough, there I was, large as life! I checked the Intranet site and there was an equally hideous picture of me with one of the alums. She, at least, looked good. I’m not sure what’s worse—that I looked every minute of my 55 years, or that they didn’t get all the detail of the hand-knit sheep sweater I was wearing—that one I knit all through Code Academy, to preserve my sanity.

Since then, I’ve had complete strangers stop me in the hallway, exclaiming, “Oh my God, it’s you! Your picture is EVERYWHERE!” The good thing about this is that I’ve also had people ask me about the Code Academy program. I’ve been able to give them an overview of the program and tell them that it was a fantastic experience, and that I’m very happy now that I’m a developer. Hopefully all this was worth it, and there will be a lot of applicants this year.

HappyDanceHappyDanceHappyDance!!!!

I DID it!!! I finally figured out what I was doing wrong with the JUnit testing. There is a line of code at the beginning of the test for a field that says “contextData.” Initially, it appeared to be some sort of memo or reference. As I’d exhausted every other option this week, short of Voodoo chants, I checked the field again and…I was wrong! Far from being a “memo field,” the code is actually used to pull in the data elements that have been changed in the payload. So, in my instance, I needed to add Date of Birth, Loss Date, and Driver Age to this string, separated by pipes, so that these are be accounted for in the test.

As a result, I’m FINALLY returning data, and the correct data to boot! I need to write up more JUnit tests for different scenarios, but at least I now understand how these particular ones work.

I also participated in a fire drill today—okay, it was more like a full-on 5-alarm blaze. Our BA (you remember him—the poor bastard who inherited all my work when I went off to Code Academy last July) found out that one of the user stories for his other agile group tanked in regression-testing. The developer who worked on it is offshore and was one of the many who was off for Pongal. It was my boss’ idea to put me on this as a learning experience, with the other developers. We all checked different things to see why this wasn’t working. My task was to scour the past release’s code for anything to do with the logic that was broken, and then compare to see what was overlooked and/or changed by the user story code in this release.

THEN, it occurred to me…I asked our BA, “What exactly DID the error message say?” I searched our GitHub repository for the exact wording, and FOUND it! The odd error message came from one of the new Gosu rules (.gr file) the user story added. I did my best to figure out what on earth the code meant that led up to it throwing an error. The other developers had in the meantime found other odd things to do with the test environment, so hopefully between all of us the group can determine how to fix the issue.

I have to say it was very exciting to discover that I can in fact troubleshoot code I had nothing to do with writing, and understand it! This is pretty good, in that I’m hopeless at troubleshooting knitting and crocheting mistakes for people when I didn’t personally create the article.

Now back to the JUnits! I’m hoping for a peaceful Friday to complete them…

HappyDanceHappyDanceHappyDance!!!!

As a result, I’m FINALLY returning data, and the correct data to boot! I need to write up more JUnit tests for different scenarios, but at least I now understand how these particular ones work.

Now back to the JUnits! I’m hoping for a peaceful Friday to complete them…

Work Day 32: Git-in’ Trouble…

Our Continuing Ed session was awesome today! Working from home enabled me to see the presentation much better on my large monitor. We covered Java and our instructor compared Java object-oriented code with JavaScript object-oriented code. Our takeaway exercise is to add fields to both sets where the fields are missing. It’s always good to have practical exercises to work on. I took copious amounts of notes to share with a fellow student who couldn’t attend today.

In other news, I lost my mind with #%*$^*# GitHub again. They opened up the February Release branch, so yours truly followed instructions for bringing in the branch…not entirely successful. I got some ghastly error in Git Bash saying there was “no such directory.” I think it said “no such directory anywhere” as if to imply nowhere on THIS PLANET. Following the Alum’s advice, I checked out the branch from Guidewire Studio instead, which worked. I applied the patch for my first user story. Oddly, one of the gs files added for my second user story was STILL out there, even though I’d switched branches and done a pull request. I checked, and the rest of the second user story code wasn’t there—just the new gs file. As I have the patch for that one, I deleted that gs out before committing my changes to GitHub. All seemed to work out well…UNTIL…

I checked the pull request and realized that somehow the gs WAS IN THE DAMNED BRANCH. Despite deleting it, the file had managed to hitch a ride on my first story commit! I was pondering possibly wiping out everything and doing a git clone to bring in a completely fresh copy of the branch to apply the patch again, when one of my coworkers made a suggestion.

“Delete it out of GitHub.”

Heh? After having it drilled into us in training that we’re NOT supposed to do that???

“Delete it out!” He insisted. He even sent me a screenshot showing the tiny garbage can icon on the GitHub screen.

As it turns out, the system prompts you to enter a reason for your actions, and notifications go out, so there’s a trail at least.

It still felt sort of…naughty… 😈

Work Day 2: This is Taz…

…he’s currently more useful than I am. At least he can sharpen pencils.

I met with my Mentor today over Skype, where he got a firsthand look at how SLOW my current work laptop is. He quickly decided that I’m better off reviewing documentation, becoming familiar with our company GitHub, exploring other links, reviewing the code, and doing tutorials until my new laptop comes in. So, I did all that today. I continued reviewing the Pluralsight video and W3 Schools for Java…until they got to the part about “objects,” “classes,” “constructors,” etc. That sonic boom you heard clear across the cosmos was my head exploding.

HEH???

My plan is to go over all that again tomorrow, and hope that overnight, while I sleep, tiny elves implant understanding in my brain, because I have NO IDEA what the hell it all means.

Day 16: Stringing You Along…

We had two major blasts today in class.

One: we got our Friday projects back. The good news is that, by and large, our instructor felt we did well. The bad news is that I completely spaced on putting all my inputs into a <form> element—apparently, I wasn’t the only one, and there were a few other things I missed that needed attention. We all had issues to correct, on which we spent most of the morning working. One issue, a link not working, turned out to be a non-issue. I suspect our instructor had us immediately work on our defects as, in real life, during an Agile Sprint, it would be expected that you would correct mistakes right away. As a BA, I’ve been on the other side of this equation (“What do you mean, you didn’t make the changes YET???”).

Two: we worked with strings today. We used different functions and methods, such as indexOf(), lastIndexOf(), substr, slice, etc. Before you ask, NO…this is NOT as much fun as working with that other type of string (a.k.a. yarn).

This all culminated in an exercise to parse out a full name by prefix (if present), first name, middle name, last name, and suffix (if present). After much wailing and gnashing of teeth, I DID IT!!! Woohoo!!!

Tomorrow we work on dates…no, not the type you eat…

Day 15: The Outside World

Last night, after class, I took a much-needed respite and went to a music festival concert. Our local orchestra does a concert series every Friday during the summer, featuring a different theme every week. Last night’s was a tribute to Elton John. It was a fantastic night.

Of course, that’s not what I’m here to talk about…earlier in the day, we all survived a 1-day—we’ll call it a sprint, for lack of a better word (Agile pun intended). We had eight hours to create a 4-page site featuring three financial calculators with about six different equations. I confess we got an assist from our instructor on one, but once we got that one done and figured out in JavaScript, it was fairly easy to google for the rest of the equations and plug them into our pages. It was fun, too, as we revisited our HTML and CSS coding with Bootstrap thrown in, and got to style the pages to our liking. We all ended up with pages that worked by the end of the day. It was A MIRACLE.

I raced to the concert last night, all excited to tell people about my wonderful achievement. Fun fact: unless people are coders, NO ONE really wants to hear about your adventures in coding. I was excitedly explaining my entire eventful day, my ups and downs and struggles to make the scripts work correctly. My librarian friend, who has taken coding classes as part of her library science degree, did understand what I was talking about, but everyone else looked like a deer in the headlights. It might have been more exciting to have the site loaded in a GitHub io repo to show them, but I hadn’t had time to do that.

We artists are SO misunderstood…the only thing less exciting for these poor people would have been had I tried to explain knitting short rows to them…

KT-ing to the new guy, or…do I REALLY know this little?

…and if so, why do I have so much documentation???

In preparation for my great move to Code Academy on July 8 I am in the process of doing KT with the BA who will be taking my place. I always assume people know what I mean by acronyms–KT stands for “knowledge transfer.” I have four days to impart my great wisdom (stop laughing) to my heir-apparent before the 4th of July weekend.

When my boss and I found out that I’d been accepted into Code Academy, after congratulating me on a job well-done, he informed me that he’d already found a replacement business analyst. I can’t decide if I’m relieved or insulted that I was this easy to replace.

In time-honored corporate tradition, the new BA is going to be doing his work and mine. We are in the wonderful world of Agile/Scrum now, so BAs don’t have as much to do as they used to. I know…BLASPHEMY! I’m probably breaking some sacred BA code by even mentioning it, but honestly our product owners now do a lot of the heavy lifting in getting our requirements. From what I’ve heard from BAs in other organizations, their BAs ARE the product owners–it’s not a separate role at all. Couple that with the fact that our product owner is a NINJA businessperson who also is very familiar with many systems…this is one of the reasons I decided that now would be a good time to pursue development work again. It’s only a matter of time before someone upstairs figures out that our BA roles can be just as easily performed by product owners trained to also document (remember: Agile…there isn’t as much anymore) and understand how the systems and the data flow. As it is, our product owner is also adept at designing test scenarios and use cases. Honestly, what’s left? When I first began being a business analyst back in 2008, we were still doing QA testing. This, of course, is now done offshore.

Despite all this, I still have quite a bit to impart to the new guy. He has some understanding of our system, but I’m filling in the blanks for him. I’m not too worried about him being lost because…well, see above. Our product owner, who used to work on the system as an adjustor ages ago, probably knows more than the developers.

And, in answer to the inevitable question…no, I have no desire to segue into product owner work. I really feel that this is all happening for a reason. Ever since my mainframe system work was shipped offshore back in 2008, I’ve missed developing. I’m excited about coding again!