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!

Updated the blog! Cue the code!

I know I haven’t been as prolific as usual lately…I blame our Agile team’s project. Normally, we deal with enhancements and fixes, which frankly I LOVE. I started out my mainframe programming life back in 1992 dealing with production and enhancements, so I’m quite comfortable “in that space” as they say in corporate-speak. However, our team has taken on a rather larger enhancement, which is frankly more of a project—they’re just not calling it that. Several agile teams and departments are involved in this. I know, in the long run, this will be good, as it involves a new integration with our system, so I’m getting to see how integrations are set up.

The bad part is that we are all working on our stories at the same time, so in the case of my current user story I’ve been having to code off to the side in a Notepad++ document, with the idea that I will be adding my function once the Util class is created. There is really no way to tell if what I’m writing will even WORK. I’m one of those people who needs those visual cues in the Guidewire Studio app (or Spring/Eclipse, if I’m coding in Java) to guide me. You know, “normal” print if everything is kosher and ANGRY RED if there’s an issue. I’m not used to coding blind. I’m sure, once I get more experience, I’ll find this easier, but right now it’s maddening. I’ve also been working on a GUnit test for this, which has been the seventh circle of hell. I think I’ve managed to find some existing GUnit tests that are close to what I’ll be needing, but AGAIN, I need to be able actually run this SOMEWHERE.

I’m also still working with the new guy. The latest thing is that I need to help him upload some Admin Scripts into GitHub for his user story…this is a clear-cut case of the blind leading the blind. I have a sneaking suspicion that my boss is suggesting I help him with all this different things as a way of getting me more familiar with different tasks. I’ve done exactly ONE of these previously, so this is going to be entertaining, to say the very least.

Thank heavens for long weekends…May you all have a wonderful Memorial Day weekend! I for one, plan to catch up on all my knitting and crocheting, which has been woefully neglected this week!

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.

Work Days 42 & 43: Surely You Mock

I know…I’m combining TWO days in a row. In my defense, one could consider these two days to be a continuation of each other, as I’ve been in Gosu hell since yesterday. Unbeknownst to us, someone–in the interest of anonymity, we’re going to call him Earl–pushed a GUnit test (like JUnit tests, only for Gosu) that uses Easymock 4.0.1 out to the release branch. Fun fact: many of us are still on Easymock 3.1. I found this out the hard way when I needed to do a fix for the role user story, but was dead in the water when I got two compiler errors after creating my branch from the release branch.

Come to find out, this has been an ongoing drama of “Dynasty” proportions since December 5. For my younger readers, that would correspond to “Real Housewives of Beverly Hills-on-steriods” drama, like that chick screaming to the cat in all the memes.

Anyhoo…The initial alarm was raised in home office with–in the interest of anonymity we’ll call this fellow Gungho Carl. Gungho complained back on December 5 that he couldn’t compile. Gungho is actually a kickass developer of uber nerd cred, so if HE can’t compile, there’s something seriously WRONG. From there, for the next several days, there were a flurry of frantic emails back and forth with basically the known Gosu world within my company. The news eventually filtered down to our office in the sticks, and landed with my mentor. He’d only informed a few people about how to fix this (including Earl), as I don’t think he realized how many of us were still on 3.1.

Per his instructions, I updated to Easymock 4.0.1, fired up the server, and…drum roll…

I got 1,018 compiler errors!

As a temporary workaround, because I was really desperate to get my user story changes done and into GitHub, someone (The Alum) had me just modify the other guy’s GUnit test in my local machine to use a parameter in keeping with 3.1 (the test didn’t affect anything I did).

My mentor, who was NOT PLEASED with the workaround, helped me today to get updated with 4.0.1 correctly.

In other news, I was shown how to do Git commands from within Guidewire Studio! I haven’t created a branch from there yet, but I managed to add, commit, and push my changes. Very exciting.

I’m also happy to report that I just checked, and TWO of my user stories are now in the Release Path!

However, as of this writing, I still have MORE work to do on my role story. This is my favorite screw-up category called “Pam needs to learn to read.” I created my role, but apparently someone felt it needed to WORK. Go figure. To be continued tomorrow…

Work Day 33: Git-in’ Trouble…again

I swear, the most difficult part about being a developer is not so much the coding, but all the other stuff. Today, I managed to merge the tech story changes correctly and iron out the discrepancies by doing a side-by-side comparison of the code as it is now vs. how it was back when my coworker did the original patch. I managed to put his code in the right areas. I then did a boatload of before and after testing to make sure it worked. Fun fact: our February branch has 50 errors when you run all the GUnit tests. Of course, some of this may be due to a lack of data for certain lines of business. Thankfully, none of these apply to my changes.

I managed to checkout the branch and push my changes to GitHub. However, THIS time, three weird updates that had NOTHING to do with my updates went along for the ride! I’m not sure WHERE these came from. They appear to be other people’s changes. I’m not sure if these were already part of the branch or what the story is. No pun intended…

On a more positive note, my new sweater is coming along. However, I may need to make a LYS run tomorrow or the next day. I’m almost done with the body and will need #10 DPNs for the sleeves.

Work Day 31: That thing from WAY back there…

Today was one of those days where I spend AGES trying to figure out where I went wrong with a GUnit test—this was the infamous “All Items” test. For some oddball reason, although the specific GUnit test I’m fixing was fine, the entire shebang had errors up the ying-yang. Basically, out of over 1000+ tests, only about 30 tests passed! I tried backing out my tech debt story code and reran the entire thing, and AGAIN, I had multiple errors.

Then I remembered. Back when we were setting up Guidewire, the Alum had me comment out some code in the build.gradle file after I’d brought in the November branch, before I fired up Guidewire (the code is apply plugin: ‘com.guidewire.cust-dist-deprecated-tasks’). Once I’d done that, I had to uncomment the code before firing up the server.

I realized that I had checked out a new branch (December) for this story. On a whim, I closed out of everything, commented out the plugin code, fired up Guidewire, and then uncommented it again before running the “All Items” test. Sure enough, that seems to have done the trick! The test without my code ran fine, albeit with 50 errors this time around (people have added tests since November). I need to now bring my code back in and run everything again, but I think I’m going to shut everything down and start anew like last time, to make sure.

As it is, I think I may need to adjust the code. For one of the jobs there have been many updates since June, and I think at least one block of the fix is a repeat of something that was added in later. I may try to run it first and then if I get errors, I’ll attempt to fix what I think is off.

Tomorrow is another Continuing Ed session with our Instructor. I’m attempting to cram in the reading from last week, review what we did, and review the info for tomorrow. Miraculously, he’s going to be going over some Java code. I’m not sure what little elf whispered in his ear to arrange this, but I’ll take it.

Work Day 29: I’m just watching the wheels…

Sometimes, lately, I do feel like I’m living that John Lennon song…

Why on earth do people keep asking if I’m okay…if I’m adjusting to my new role…if I’m happy???

This week I’ve had, at last count, five people ask me how I’m doing. One of my BA coworkers said something to the effect of, “Oh, that’s right…you’re doing both now…” You know, in that judgmental tone of voice adopted by people who disapprove of bisexual people. I corrected her, “I’m actually NOT…I’m a developer now.” There was dead silence on the other end of the phone. “Oh…” Like I’d just told her that someone in the family died. .

I had a one-on-one with our tech lead today, and again…”How are you doing? Is there anything I can do for you?” I suspect this was a result of that crazy call yesterday when they found out that I’d run 1008 GUnit tests I didn’t need to, and was a bit fuzzy about complicated GitHub procedures. The good news is our offshore guy finished my code review and approved it, so I was able to tell her that. I also picked out another user story, which sounds ballsy, I know, but there’s a method to my madness. Our former team member partially completed it before he left and it’s a tech debt story. I figure this is a serious opportunity to learn from someone and figure out how to modify actual Gosu code at the same time—the quintessential case of “Copying off Tim’s Homework”…

My boss asked me the other day how I’m doing, but in his case I think he’s just excited for me. Also, seeing as the company has made a major investment in me, I suspect people above him desperately want to see it pay off.

My favorite was my friend at the gym. I call her “the old lady,” but she’s probably around my age. “What the hell is coding? Why do you want to do THAT? Why aren’t you just retiring?”

Honestly, am I happy? I am grateful each and every day that I no longer drive to work, sit in the car in the parking lot, and just DREAD going in the building. Every day is a new adventure. I swear, the company trained me and are paying me money to have a good time every day, solving interesting problems. It’s like an entire day of Sudoku and crosswords, only with a nifty computer that can churn through an entire suite of tests in an hour (even though I wasn’t supposed to do those).

Am I okay? I won the freakin’ LOTTERY!

Work Day 28: I wasn’t supposed to do that?

…or “When you assume…”

Our offshore developer did my code review. He got back to me with some points he wanted to explain. As it was early, our tech lead arranged a call for the three of us. May we pause to say here that going over code with other developers is WAY easier than having tall, towering arguments with six business people on whether or not they want the words “Total Cost” capitalized in a report or not.

After I explained the amount of “deletions” (my changes for the word wraps and width limits seemed to show up as deletes and adds), he walked me through creating a branch from GitHub to apply my patch. I hadn’t done this yet, as my change isn’t being released until February. Instead, I’d cloned the November Release repo to do my changes and created a patch. He explained that I could at least check out a branch for now and push my changes there, without affecting anything in the main release branch, as long as we get rid of it before the December release. That way, he can properly review everything I did. I know what you’re thinking—did you learn nothing in boot camp? Yes, we used GitHub extensively in Code Academy, but we were dealing with a master and maybe five branches, at most. The company GitHub is IMMENSE with many, many repositories for many departments, that have many branches, where you make branches from branches for user stories. You honestly need a Dramamine before you attempt to sign in to look at it.

He asked where my GUnit test and coverage report were—or at the very least the screenshots. I showed him where this was in the documentation, and he pointed out that I still needed a coverage report. Thank God I didn’t have the webcam on because I’m sure my eyes bugged out like a squirrel about to be rendered semi roadkill. He patiently explained how to create this in Guidewire—it was simply a matter of clicking an icon. My cat Jack could manage it, if he had opposable thumbs.

And THEN, he saw the dropdown where I’d run my GUnit test earlier.

“You ran…all the tests?”

I explained that I’d followed the company GitHub Wiki instructions to the letter.

“You ran ALL the tests???”

Come to find out, I was only supposed to run tests pertaining to my code.

“Is that why it took over an hour to run?” Honestly, the entire process was three hours of my life I’m never getting back again.

It gets funnier. He looked at my code again and said, “and since you only changed the pcf files, and not any classes or methods, you really didn’t need to run a GUnit test at all.” I pointed out the one class test I thought pertained, but there was no actual change to that class, and it didn’t directly affect my two pcf file sections, so it was out of scope.

We left off there, so that the poor guy (being 10 1/2 hours ahead) could go home and go to bed. I thanked him profusely and hung up. He hung up the phone and I’m sure either howled with laughter over the crazy lady who thought she had to run the ENTIRE block of 1,008 GUnit tests for two tiny list view pcf changes, or fell into a dead faint.

My boss, who’s still on a high from me doing actual work now, thought the whole thing was hilarious.

Work Day 26: GUnit testing hell, part 2…

…but there was light at the end of the tunnel.

My mentor explained that sometimes the GUnit errors have nothing to do with one’s code change, as you’re testing the entire code base, with other people’s code changes. He had me back out my changes (luckily I’d done a patch, plus took copious notes on what I changed), rerun the GUnit test, put my changes back IN again, rerun the GUnit test AGAIN, to see if the errors are due to issues in general or due to my code changes. Why I didn’t think to do this myself, I don’t know, but that’s probably why they pay him the big bucks to be a Tech Lead. Sure enough, the errors were the SAME, so my changes didn’t cause them.

Now I just have to figure out what the difference is between a “code inspection” and a “code review.” I emailed our tech lead, asking if I needed to provide anything else in order to get a code review. Apparently, I need a code inspection before the code review. Call me silly, but I thought these were one in the same…I scoured documentation for old user stories but there is no there there. The ones I found say “Code Inspection: non-applicable.”

On a more cheery note, my name made our division Town Hall meeting! Once for having 30 years with my company, and once for graduating Code Academy, along with all my other fellow graduates. Very exciting—I can’t think I’ve EVER rated a mention at the town hall meeting. Granted, my name appeared on a PowerPoint slide, but still, it’s really exciting to be acknowledged for something for which I’ve worked hard. Several people came up to congratulate me…for the 30 years. I’m not sure why they were more impressed that I’ve survived 30 years at the company rather than having survived coding boot camp, but I thanked them.

Work Day 25: Fun with GUnit Testing

I’m in GUnit testing hell. My mentor is back. In answer to my confusion he explained that l needed to do a GUnit test, if the pcf code I changed uses Java and Gosu utility classes. It took me a good hour or so to trace through to see where these classes were—sure enough, the pcfs use several utility classes.

I’m not entirely sure I set everything up correctly for the test. All the utility classes are part of Java or Gosu “packages” which l don’t think you put under “gtest.” There was one class not in that category, which appeared to already be in the gtest path. I painstakingly followed all the directions to set up an “All Tests” GUnit run in Guidewire. There were a total of 1008 tests to run—35 failed. I’m not sure what the hell that even means. I suspect I’m going to need to meet with my mentor to figure all this out. There is some sort of mechanism to ignore certain tests, if not applicable. I’m hoping that was the issue—that I just needed to exclude certain non-applicable tests (and not that I’ve managed to screw up the entire application with my two small changes).

I also realized after the fact that I should have written a test to include that would have tested my ACTUAL change. I thought that this was an all-encompassing test, and that my change would be tested with everything else by osmosis or something. If you held a loaded gun at my head, I couldn’t begin to figure out how to write one. I looked at one of the gtest files and it was so confusing I almost fell into a dead faint.

I have this horrible feeling that figuring this out is going to involve another Pluralsight video…