My biggest success for this class wasn’t technical. Writing a simple MERN app isn’t a mysterious thing any more than learning to play an instrument. Time and practice. Rushing it will only mess things up. My teammates are more skilled than I am, but I wasn’t doing anyone any favors by trying to match them. But that’s exactly what I was trying to do. And I didn’t know where to start. The result was me trying to eat the whole elephant at once.
My breakthrough was remembering to relax. Once I did that, I started to identify specific paths of research. From there, progress started to come.
Having said that, my most important technical breakthrough is not something I’m exactly proud of, but it’s a perfect example of what I’m talking about above. I was working on styling our app. My only experience was some very basic CSS, but our MERN app uses the Bootstrap library. At the start, I roughly understood Bootstrap to be a facilitator for styling and that it had some other prebuilt UI features. Separately, I had heard of Sass as a styling tool – an extension to CSS I guess? I didn’t have time to learn all that though! My team had decided on Bootstrap so I better get to figuring that out. And if Bootstrap was what I thought it was, the whole point of it should be to help with changing the look of the app. Working on these initial assumptions, I immediately began searching for resources on how to style using Bootstrap.
Now you might be saying, “just read the documentation.” I’ll take a quick aside to say that I don’t agree with the RTFM mentality as I’ve typically experienced it. “FMs” are usually exceedingly long, technical, poorly written anyway, and 99% doesn’t apply to what I’m doing at the moment. To be clear, I understand that the actual documentation is usually the best source of information. However, when I want to do one “simple” thing under pressure of a deadline, I look for the executive summary first. The documentation does not know what my immediate problem is, nor when my work is due. The introductory tutorials are usually too simple and don’t address my use case. Getting further into the docs often feels like reading a dictionary in order to learn a language. At my experience level, it’s a reference more than a teaching aide. So I figure out a general plan and then use documentation to drill into the details. In short, I need to understand the problem before I start asking questions. Reading documentation from the beginning and then hoping I find what I need in time is… not helpful. Documentation does not work independently of time and experience
Obviously, I researched some sub-optimal solutions. I read all about how I should import individual component-level CSS style sheets to override Bootstrap defaults. For one thing, component-level style sheets might be good for scalability and reuse, but I found that it overly complicated implementation for a simple application like ours. A more serious problem was that every style that I applied felt as if I was fighting Bootstrap, not being helped by it. The app looked terrible. I started to think – does every Bootstrap app look the same? Is the default it? (something that I later learned is an actual complaint about Bootstrap) It all just felt wrong. It shouldn’t be so awkward. But I kept pushing forward with the approach because I had been making some progress, and I didn’t want to start over entirely.
What I should have done is slow down and back up when I started to see that my approach wasn’t working. When I finally did that, I found other resources that referenced Sass. As you’ll recall, Sass was that other styling tool that we weren’t using. At least that’s what I still thought at this point. I looked deeper and found out that Bootstrap already uses Sass. Oops. All my answers were found in the node_modules folder – a place I had always been (wrongly) warned not to tread. Once I found all the Sass files, I was able to start modifying the styling variables more easily and with better effect. I further learned about live compilation of Sass into CSS in order to avoid modifying the source files. That was one of those “Oh, that’s neat” moments. That led to proper import of the CSS in a method that worked for my use case, and eventually how to dynamically change styles in the app using context – a fun feature with interesting constraints on how I implemented styling. More importantly it taught me to understand the React context hook which is a key functionality for all of React, not just for a styling feature. And so it goes. One thing to another.
The moral of the story, to quote my my high school football coach, might be “Slow is smooth, and smooth is fast.” In other words, progress is first slow and iterative before it is fast and effective.
Turing my reflection toward the Capstone course itself. Strengths, Weaknesses, Opportunities, Threats:
S – The biggest strength of this course is that it’s a little taste of what the industry is really about. It’s not an academic course. No major “new” technical concepts are taught as part of the syllabus (i.e. I already took the WebDev course). This course is about teaching yourself what you need to know to accomplish a broadly defined task in coordination with teammates and to deliver a product to the customer on a deadline. It feels like I should be getting paid for this. I imagine that’s the point.
W – I would have been put more at ease with a clearer understanding of specific requirements. That’s not really a weakness. No one is going to hold your hand in the real world, after all. It’s also rare to get perfect instructions. Finally, being given latitude is actually a good thing (if you know what you’re doing), right? Still, being provided a slightly clearer “done” state would have alleviated some stress.
O – The biggest opportunity for improvement would be to assign projects sooner. I know I could have used every extra day. I also know it’s not so simple to coordinate, and some time does need to be afforded for students to explore the projects. However, if there is any margin at all, it could be applied to providing that time for project work.
T – I wouldn’t say there are any serious issues. Maybe I should have saved the project assignment timeline issue for this bullet. Time is valuable for a project like this, and one quarter goes fast. Having that first week or two for research and overcoming any start of project confusion would have been nice.
Leave a Reply