So, Friday was the day I’d been nervous about. It was our first sprint challenge at Lambda School. Its essentially a 3-hour, timed project that assesses whether or not we’ve retained what we were taught during the week and are able to recall and make use of it quickly enough to complete a task in the allotted time.

A lot of people breezed through the challenge. I wasn’t one of them. I was working on CSS code right down to the time limit. I managed to complete the challenge (or so I thought) but I didn’t get to any of the additional stretch goals.

This first challenge had three components:

1. Type out answers to 5 questions about html, css, the box model and git
2. Complete a 2-page coding project that focused on html and css
3. Make commits and a pull request to our team lead using Git Bash and GitHub

Self-study questions

So, answering the 5 self-study questions wasn’t too difficult for me. We did have to edit the markdown file on our fork of the GitHub repository for the project and type our answers there though. Doing so also forced us to make sure we knew how to fork the repository, clone and edit it on our computer using VS Code, make edits to the readme.md file and then use Git Bash to upload it back to Git Hub. Once we had that process down, we had to also add our team lead as a contributor, for grading, and make a pull request so the TL could access the fork. I was able to do this all fairly quickly, which left me with a good chunk of our 3-hour time to focus on coding the project.

Minimum Viable Product

The MVP was the bulk of our challenge. We were given two html pages with accompanying css. The first page was mostly set up, but we had to make changes to it. We had to add elements that were missing – like a navigation bar, images and links – after referencing a design document. It was a PNG file that showed what the completed homepage should look like. There was also a middle section of the page that contained 10 black boxes which we had to modify so that they each displayed pre-selected colors from a list.

I was able to complete this part of the challenge fairly quickly. It was similar to other projects that we’d worked on during the week. For the colorization, I used html IDs, which we’d learned about early in the week, and even used in some exercises, but which I, personally, hadn’t used in any projects since. I think it took me about 30 mins or so, and I was happy with the result. It was a spot-on reproduction of what was given to us in the design document.

The second page is what took up the bulk of my time. We were tasked to mark-up and style an About page using a design document (another PNG) as a reference. We had to add a header and navigation, certain links and mirror the design that we’d been given using html and css.

I learned something while working on the second page: using someone else’s mark-up can be hard. It doesn’t necessarily conform to how I think. Their way of dividing the page wasn’t necessarily how I’d do it. They used virtually no semantic html – I remember a lot of <div> tags with no context. This spilled over into the css, because classes that were created in html were called in the css and weren’t necessarily what I’d have chosen.

I had a hard time filtering through the code and making it work in a way that made sense to me. The first big problem was that almost all of the content in the page was grouped together. After quite some time running through it, back and forth, and trying to style certain sections, I was able to divide the main content into smaller parts that I could style more individually. I had to do this because there were parts that were divided by images, and by horizontal lines, which needed different styling from the main text.

It took some trial-and-error, and although this part of the project strongly resembled sections of the Flexbox project we’d worked on during Day 3, it was made much more difficult for me because I hadn’t come up with the individual tags to section-out the page, and I didn’t necessarily want to break the existing css, which relied on the provided html and structure.

Submission and review

After taking the entire three hours to format the page to my liking and make it as close to the design document as I could, I pushed it to GitHub using Git Bash. I had already created a pull request earlier, after I had answered the self-study questions, so our team lead would see all of the pushes and commits I’d made to GitHub and assess the most-recent version for grading purposes.

I joined the Slack channel for our group after submitting. I saw that some people in my group had breezed through the challenge and  enjoyed it – one person said it was fun! Several were surprised at how well it had gone for them. I commented that I was worried, because I’d just barely made MVP by the time limit.

Reed, our team lead, then took some time to go through each of our pull requests and give us an initial evaluation. He didn’t do this on Slack, of course, because of confidentiality concerns, so he initiated a Zoom session with each of us, individually, as he finished reviewing each submission. I think maybe 3 hours passed before he got to mine.

We spoke about the experience and I told him that I thought I’d completed MVP, but I was concerned because I was slow. He had me open my local copy of the project in VS Code and we went through it together. We examined the code in the editor and the output in Chrome. We also used Chrome’s Inspector to look at select elements in the browser, to see how elements were grouped or styled.

It turned out, I actually hadn’t met MVP, but I was close. I was able to answer questions from Reed that demonstrated that I had a good understanding of why certain elements weren’t exactly like the design document’s version. Some of it had to do with my reverse-engineering the provided html. This had been a huge slow-down for me. When I repositioned the starting or ending points of certain <div> elements, I had inadvertently left a piece of the page out. This had a big effect that I didn’t catch – it was in the footer – because that main <div> had some associated css that styled it in a way that was crucial to how each <div> on the page was supposed to appear.

Reed thought that maybe I had forgotten to style the footer, or maybe something else (I can’t remember the other thought) but I was able to quickly explain what had gone wrong to him, and later on, I corrected it in the code. The footer explanation was part of a series of such that helped him to determine that I had a good conceptual grasp of how the page worked and how it was supposed to function using the html and css.

Another detail that I missed was small size differentiations between parts of the bodies of text. There were elements that made use of the entire allocated width of the page, and there were elements that made use of only some of it. So, I had to alter certain width properties in css and use Flexbox properties to correctly align them. I was able to do this as well, afterward, but I felt bad that I’d missed it in my rush to complete the page.

There were also horizontal lines (horizontal rule, or <hr>, in html) that I had placed slightly imperfectly. One was supposed to span the width of the page, but others were only as wide as their individual flexed containers. They all had to conform to proper alignment as well.

In the end, I adjusted those as well. It was after the official submission, so I don’t know if it counted, but at least my final commits could show that I understood enough to correctly duplicate the page based on the design document. I was able to add rounded corners to “buttons” as well that changed color when moused-over. I did this using hover, which we had gone over earlier in the week, and with border-radius, which I’d picked up on my own. I really like the combination of the two to style buttons.

I didn’t get to attempt any of the stretch goals, which included topics we hadn’t yet covered in class, but I expect we’ll see this week. These included:

• Adding a new page from one given in the navigation bar, including coming up with content and images for it
• Introducing css animations to the site, which I also haven’t learned yet
• Building a contact page with a form that includes any inputs we choose
• Adding responsive breakpoints using media queries

Afterword

I’ve had some thoughts about how I’d approach the project again, if I had to do it, and one of the big ones is that I think I wouldn’t have just jumped in and tried to modify the code after reviewing it. I think I’d have been better-off if I printed the design document or sketched it out and generally plotted out how I’d want to section-off elements on the page and what specific formatting options I’d use to place them where they need to go – especially which Flexbox options I’d use for each section, and what css I’d use to further refine elements after they’d been positioned by Flexbox.

I’ve been blogging through this a lot, and it takes quite some time, but I also need to do some of these projects and challenges over again, to get more practice and really ingrain how to use certain formatting tools in my head. Hopefully, this (and sketching out a general wireframe for each page) will increase my implementation speed, because I’m now convinced that I’m the slowest person in my group.