My Attention Problem

Yikes, I’ve been really undisciplined about blog posts lately; I have two to catch up on this morning.

Tuesday, June 10

There’s nothing in my notes on Tuesday worth talking about for very long; I spent the entire day refactoring/redesigning and fixing the several tests that my work broke. There was one thing that happened that may be worth writing a blog about, if only to help me think through the problem and find a solution. 

I have an attention problem. If I get wrapped up in thought about something, I have this ability to tune everything else out to the point where people can be talking in the same room as me and I’ll have no memory of what they said, even if they were talking directly to me. This may not be an uncommon ability, but I’m really bad about not breaking away from whatever I’m working on when someone needs my attention (or when I just need to be paying attention to something else that’s going on). If I don’t fix that I’m probably going to have some trouble being successful in my career. A good example of this causing me trouble happened on Tuesday.

I guess at some point on Monday it was mentioned that we each needed to get SQL Server installed on our computer; I must have been wrapped up in thought at the time because I have no memory of that. Tuesday was fairly problematic for me in terms of getting code working and tests passing so I was in that state of stubborn focus through most of the day. The problem occurred when Jef started going over how to use SQL Server for our project and I didn’t even have it installed. This meant I was unable to engage with what Jef was showing us in a hands-on fashion, which meant that it was even more difficult to not be distracted by a major test refactor I was working on.

Auxiliary to my primary attention problem is my ability to convince myself that I’m paying attention when I’m not. Because of this, I have very little memory of what Jef presented us about SQL. I need to get caught up on that soon because right now I’m having trouble finding ways to contribute to this sprint. Hopefully in the future I’ll be able to catch myself not paying attention and eventually fix this problem; feel free to comment if you have any suggestions or insight.


My Fragile Ego

For some reason last week was a very anxious week for me and it cause me to miss most of my blog posts. I neglected to write my post for yesterday as well but I have no excuse for that one. At this point I’m not going to try to catch up on last week but I am going to try to recap yesterday. That might be a little difficult because I forgot to take notes.

Monday, June 9

Monday means it’s time to start another sprint which normally means that we start the day with sprint planning, but today we started with some code refactoring. At first we just organized our project files into folders which was easy and quick. We then started on the actual code refactoring during which our pace was a little sluggish. I’ll try not to get too deep into the technical details but we essentially we made a fairly small change that caused a ripple of errors in our code. It seemed fairly simple to me but I think I was afraid to just force my solution on the group (because 1. I could be wrong and 2. I try to not be too much of a control freak).

I did at different times voice an idea or two (including an unrelated concern of mine), but it seemed to fall on deaf ears. Looking back I think everyone was just caught up in thought about the problem (and it’s possible that I simply didn’t speak loud enough) but at the time it irked my fragile ego and caused me to check out mentally (and start playing 2048). We spent a good while on the last error, and when we found the solution it turned out to be a suggestion I made about 20 minutes earlier. Jef pointed out that wasting that much time can be quite costly and we should avoid that mistake in the future. I blame myself for not speaking up (and not paying attention) and we all admitted that we could listen a little better.

After our refactoring session we got into our sprint planning. Jef enumerated some features he wanted in the game, and we started tasking them out in order to weigh them and decide what we wanted to do. To me it still feels like we’re not focusing as a group during this process. It felt like we were still working as individuals when it needs to be a team effort. Hrm… maybe I’m wrong about that and the way we did things was fine. We did manage to get things tasked out and weighed in time, and our Scrum board looks pretty good. The rest of my day was a small refactor that took way too long because I ended up doing way more than what was needed. 

I think this week will be a little more comfortable and a lot less anxious for me, which will be nice.

My Edison Lesson

I’m still running late on these posts. I have plans tonight, so I’ll probably be making a late post tomorrow well.

Tuesday, June 3

Tuesday was a day of experimentation, and all of it revolved around the Quiz controller. I started the day by creating the Quiz controller, and when I paired with Jef a bit and he helped me build some tests for it. I hadn’t known how to even start writing tests for a controller so this was very educational. By the end of the day I had even written a few of my own. 

Throughout the day I added a few methods and did a bit of refactoring/redesigning. One of the biggest changes I made was turning the list of answers on a question into a Dictionary. In C#, a Dictionary is a list of Key/Value pairs, and the Key and value each have their own type. In my case each of my answers has a string key, which is the answer itself, and a boolean value, which is either true (indicating a correct answer) or false (indicating an incorrect answer).

The big challenge was getting the controller to know which question it was on in a quiz and/or what the next question is. I played around with using ViewData and properties on the controller without really knowing how they worked. I eventually got it to work with a few lines of code that called a couple of the methods on Quiz. Looking back I realize that there wasn’t much required to do what I wanted; I just wanted it to be simpler. I may have spent a little too much time on one thing, but I at least learned a little about how not to use controllers.

My Quiz Question Quandary

Yesterday afternoon was somewhat busy for me and ended with me going to bed as soon as I got home. So here’s another mildly late blog post.

Monday, June 2

It was the start of another sprint for us so our Monday morning of course began with a sprint planning session. This week’s work is going to be more vertical and individually assigned. What I mean by that is instead of just doing the C# layer or the UI layer of several features in programming pairs, this week we’re each taking a feature and writing each part of it individually. The items in our sprint backlog include a few new badges and an entirely new feature called challenges.

Challenges in our game are essentially going to be little windows that pop up at certain times that present, you guessed it, a challenge of some sort (whether it’s a quiz, or a little mini-game, or… something else. We haven’t created very many yet). These challenges are time-boxed, meaning you’ll only have about a minute to complete them. Some challenges will simply award points, while others may award a badge in addition to a few points. I elected to work our first type of challenge which is the quiz challenge. More on that later (probably).

The morning also included a brief lecture by Jef on SOLID, which is a set of Object-Oriented Design (OOD) principles. These principles include:

The Single Responsibility Principle
A class should have one, and only one, reason to change.
The Open/Closed Principle
You should be able to extend a classes behavior, without modifying it.
The Liskov Substitution Principle
Derived classes must be substitutable for their base classes.
The Interface Segregation Principle
Make fine grained interfaces that are client specific.
The Dependency Inversion Principle
Depend on abstractions, not on concretions

After lunch, I started my work on the Quiz challenge. I went in not being sure of how I wanted to handle questions; I had the idea of making a separate question class, but I hesitated to do that because it seemed like a lot for something as simple as a question with a few answers. I talked to Jef about this during a pairing session and he advised that I err on the side of creating too many classes rather than too few. When I wrote it out in code it seemed that he was right; It made sense for questions to have their own class. It keeps everything in one place which makes checking an answer a little easier. The pairing session also helped me clarify some requirements with Jef which helped me write and pass a couple of tests.

I left not long after 4 pm because of an obligation, but the day went well. Tuesday will likely involve more UI work.

Our Halfway Point

Friday night I went out to the company’s comedy night, so as soon as I got home (at about 10:30) I crashed.

Friday, May 30

The morning began with Tim Rayburn, one of the consultants at Improving and an old friend of my dad that connected me with Improving, dropping by our room and talking to us a little about what it means to be a consultant (or something along those lines). My memory is terrible and I didn’t write down anything he said (I should have) but I do remember that he emphasized the fact that as consultants we have to be constantly improving ourselves by learning new things. He pointed out that doing so will take up a large portion of our free time and because of that we are forced to prioritize our life. He mentioned a pluralsight course related to that subject called “Becoming an Outlier: Reprogramming the Developer Mind.” I haven’t taken the time to look into that yet, but I plan on doing so this afternoon.

Between that and lunch I didn’t do much other than finish my work on the expanded badge views (in order for them to be ready for review). After lunch we took some time to prepare for our review. This went ok; Along the way we discovered a few links that weren’t working so we had to figure out how to fix those. There were also a few things related to badges that I felt needed to change so I made some tweaks there. Both of these things violate our agreement to have a cutoff time for changes before review but at least some of it was necessary in order to have a successful review. 

Jef was the only one in the audience this time, but there was still pressure to perform well. I think we delivered on that; I don’t recall any big hiccups and our preparation really helped. My burn-down chart came in handy when explaining our scope reduction, so I’m glad I took the time to make that. This review was certainly an improvement on the last one. Afterwards Jef wanted us to do a modelling exercise so that we would be ready to do some modelling next week. That went pretty smoothly, and then we started our retrospective.

We had a lightning round of pluses and deltas before we got into the bulk of our retrospective, which was an exercise called influence mapping. For this Jef had us map out (in any way we like) the influences that led us to improving. I went with a listing of my parents’ degrees and job titles (as an attempt to connote genetic influence) along with a three part timeline. A timeline may not have been the best idea for me; I myself have admitted many times that my memory is terrible. After our timebox ran out we each took a turn explaining our influence map. It was interesting to see various backgrounds of everyone in the group.

When it became my turn it was clear to me that my map was a little sparse compared to the others, but I managed to think of a few more things to talk about (and I think I even went of on a tangent at some point). I mentioned being very lazy in the past, so after I was through Jef offered some very kind words of encouragement. He said that based on what he’s seen throughout the boot camp I am not a lazy person; he stated that it’s more likely that I was simply bored and lacked direction, and I think he was right. So that was nice.

This weekend marks the midpoint of the bootcamp. The last four weeks have flown by, and I hope to come out of the next four ready to become a consultant.

Our Crunch Time

My morning at work began with remaking our burn-down chart like I mentioned in my last post. After our daily scrum I asked the group how they felt about our progress in the sprint, and (with some Scrum Master coaching from Jef) we started a discussion about whether or not we could finish everything in our backlog and the possibility of removing some features. We decided to reduce our scope a bit and removed features that were heavy on design/graphics.

I think this was a good move and will allow us to finish sprint with all tasks completed. Today was however our last full day of work so we still had a lot to get done. We will have some time to work tomorrow morning but the second half of the day will be taken up by our review (including preparation) and our retrospective. Judging by what was left on the board at the end of the day I’m fairly confident that we will complete all tasks on the board in time for lunch tomorrow.

I don’t want to get into the technical details of the work Dave and I completed today because I don’t think there’s much to comment on. I will say that Dave and I have worked fairly well together this week. We’ve gotten a lot done despite both of us being new to MVC and Razor. Dave does have some HTML experience which has been very helpful. I still need to work on pairing; I tend to get in the zone and I neglect to communicate what I’m doing and actually involve my partner. Dave is pretty good at just working on whatever HTML stuff we might need when I do that but that doesn’t excuse my communication issues.

This week has been enlightening and challenging. I look forward to the end of it.


Our Slow Pace

This morning we decided that we as a group needed to know more about MVC and Razor syntax, so we watched some tutorial videos on those subjects. The videos were very helpful, but they took up a lot of time and I’m worried about how little we’re getting done this sprint. We made some effort to break tasks down to a finer grain but we still have very few completed. Even though I believe tomorrow will be very productive, I plan on calling attention to our lack of progress after our scrum tomorrow.

Today Dave and I moved forward a bit on the view we’ve been working on. We were originally thinking of using partial views for our different badges after seeing them illustrated in one of the tutorials. We played with that a bit before Jef steered us in the direction of using display templates, which seem like a much more appropriate option. The tricky part with that was figuring out a way to go through the list of badges and display each one according to its template (I think I need to study Razor and lambdas a bit more, along with a few other things).

Dave had an obligation that forced him to leave a little earlier than me. Soon after he left, I (well, Jef) figured out what I was doing wrong and fixed it. After that was done I just needed to generate and refine the display templates for each badge. Once I completed that task and confirmed that everything was working as it should I pushed up to the git repository. At that point I figured I was done for the day. I thought about remaking the burn-down chart since we changed/added to our tasks a bit, but I decided to do that in the morning.

but mostly posts about software development.