DEV Community: Shashi Lo

A Development Bootcamp after a Development Bootcamp

Shashi Lo — Mon, 09 Dec 2024 15:32:38 +0000

This project has been a secret until now.

Bootcamp Plus?

That's I envisioned this. With all the services out there offering plus subscriptions, this felt like it aligned. Attending a development Bootcamp is a great service to offer, but it comes with ads. Nothing wrong with bootcamps, but as you go through the program, it's going to only teach you as much as your brain can handle in the short amount of time given.

This is where an "AHA" moment occurred for me. I have spoken to many people who went to development bootcamps and self-taught developers, career switching into the tech industry. There was a common thread, it took longer to land a full-time position than they anticipated.

Is there a way for a shorter timeline? Were there programs out there that could support these individuals who have graduated a bootcamp, but now are left to learn on their own? And for those self-taught learners, was there any sort of support for them?

These questions came crashing down on me. When I started in the development world back in 2006, there was no social media for developers. The people I knew in the tech industry were my co-workers. I did not have a mentor, but I had co-workers helping me out. It was not easy going to them for help because I felt hopeless. I felt like I needed to understand these concepts and not having to always be asking questions. I didn't feel comfortable going to them about my development issues. I needed a mentor and I did not know how to find one, nor did I know I needed one.

I participated in an NFL survivor pool with a friend. He was the commissioner and managed over 400+ entries from around 80+ individuals manually on a spreadsheet. I approached him to see if he'd be open to having my Discord group of developers build an application for him at no cost. He agreed, and I went off searching for who ever wanted to participate.

This is where Bootcamp+ comes in. I saw a void. I saw that there were aspiring developers starving to find any sort of experience to help them land their first tech role. This is when I started to put my long waited plans to start cohort 0 for Bootcamp+.

Curriculum

This wasn't just going to be a normal Bootcamp curriculum. I wanted to put these individuals through a corporate process. It would require patience, learning, and a much slower pace than building a personal project. Many of these individuals had never worked in teams nor with a project process.

I wanted to bring in an Agile mythology. Every team, every company, has their own way of interpreting agile. Therefore, we are going to take the approach as well. We will figure out what works best for our team and adapt. I wanted to use Sprints and have stand-ups, but with the few months we've been working on this project, it's very difficult to do this when most of us are doing this part-time and this isn't our job. We've started meeting once a week to sync up and providing updates when we have them asynchronously.

Something new to these individuals was the high level planning of the technologies they were going to use. At first, it was very difficult because many of them just wanted to build before they had a well-thought-out plan. This would force them to learn the “why”. Why are we using this application, why are we using this technology, why are we building it this way. In the beginning, a few of the presentations were read directly from the documentation. I called them out on this and said this isn't a presentation of what they found. Anyone could go to a documentation site and read their docs. I wanted to understand if the technology they chose would be a good decision for the team and what task it was going to accomplish for our project. After some iterations, everyone understood the process. It wasn't easy, but we all learned that planning something before building was a vital process to building out an efficient project.

Processes that we have not yet gotten to yet are Sprint Demos, thorough code reviews, milestone branches, a release cadence, QA testing in the staging environment, and conflicts. I foresee that these will be a big learning curve as well, but my hope is that after we go through this and publically display our learnings, each one of these individuals will have a leg up on their competition.

Roles and Responsibilities

What I did was split up the team into 3 different disciplines. The UX Engineers, Frontend Engineers, and Software Engineers. By splitting the team into these specific roles, everyone had a clear focus of what they owned. This didn't mean they couldn't cross over into another role to help out. It just meant that they understood what their number one priority was.

UX Engineers would be the ones focused on bridging the gap between design and development. They would build out the UI Component library, work closely with our designer, and build out the layouts for our project.

Frontend Engineers would focus on the manipulation of data, client side application infrastructure, API integration, and more.

Software Engineers were our backend developers. They would focus on DevOps, database, server infrastructure, and more.

Why waste my time on something that has little ROI (return of investment)?

It's only a waste of your time if you feel like it. Just because others consider it a wash, doesn't mean it has to for you. I always look at the things I do as an opportunity to learn. Even when I lose at sports, fail on delivering on a task, or ate a pineapple pizza. I try to find an opportunity to get better.

This pertains towards the Gridiron Survivor project because there are immediate rewards for myself conducting this project. I'm using my precious time to manage this product, run meetings, find sponsors, and much more.

Here's a secret, I'm not losing if someone I care for is winning.

This process works and there's proof

Data may disappoint, but it never ever lies

I found this quote while building out my talk about Data Driven UX Decisions. It couldn't be more true.

In the beginning of this project, I was hoping that at least 1 member of our team would land a job after this project was done. Just 1. I can happily report that 1 person was hired after a few weeks working on this project. This project wasn't the sole reason this person landed their job, but it allowed myself and their employer to see their talents. There's no better way to interview someone without interviewing them than to build in public. If there's a way for someone to hear your thought process, see your work, watch you fail to understand how to not fail the same way again, then do it.

When you enter the interview cycle, most of the time you will not pass the first or second round. Heck, you may not even receive a call back. The individual that was hired from this project had applied to hundreds of jobs, receive 0 callbacks, and wanted to quit. When my friend and I reviewed their resume and portfolio, we understood why. None of them stood out. It was a very common portfolio that we would look at for 3 seconds and pass on.

How could a hiring team have known that this person was going to be a great hire if they gave them no chance at all?

Back to this individual. They are not thriving and enjoying every day of their new development role. I was able to meet them in-person and let them know what my “nod” was.

From the movie Groove: https://www.imdb.com/title/tt0212974/characters/nm0690263

Guy : Why do you do this to yourself? Don't even get paid, risk getting arrested, for what?

Ernie : You don't know?

Guy : No.

Ernie : The Nod.

Guy : The Nod?

Ernie : Happens to me at least once every party. Some guy comes up to me and says "Thank you for making this happen... I needed this. This really meant something to me." And they nod... and I nod back.

Guy : [scoffs] ... That's it?

Ernie : That's it.

This person thanked me for changing their entire financial future. It was a distant dream that it would happen, but it's now happening.

That's my “nod”.

My development thought process for building Frontendmentor.io my team multi-page challenge

Shashi Lo — Mon, 18 May 2020 15:22:38 +0000

I found my self seeing many development folks doing #100daysofcode on Twitter. I attempted this a few years back and lasted a week. It’s difficult to consistency code something amazing everyday when you’ve got a busy family life. When I saw Frontendmentor.io, I knew this was something I wanted to try. I didn’t have to be committed a few months to this challenge and could get it done within a week. I wanted to share my thought process behind every website design I develop.

Frontendmentori.io my team multi-page Challenge

Challenge Details: https://www.frontendmentor.io/challenges/myteam-multipage-website-mxlEauvW

GitHub files : https://github.com/shashilo/frontendmentor-myTeam

Live Preview: https://shashilo-frontendmentor-myteam.netlify.app

My thought process for developing a new website design

I’ve had the privilege to build many websites using a CMS, for a mobile application, and static pages. This is my usual thought process when dealing with responsive designs. For this project, I wanted to build it as a Pure CSS solution.

Get an understanding of the design artboard settings

Take a deep look at the document file settings. It will tell you a lot about what the designer wants for the design. If you look at a Sketch artboard, you can look at its layout settings. This will give you information on container max-width size, number of columns, gutter width, etc. Talk about being pixel perfect, this is the foundation that will setup you up to doing just that.

Visually check if the design will all be contained in a single wrapper or if it needs to be sectioned

Look at the design and you’ll see if it requires fluid backgrounds for each section. This is a clear indication that you need to create separate sectioned containers. It’s a lot harder to create negative margins, padding, positioning, etc. of a fluid element once you contain it. Therefore, it’s much easier as a developer to control the styles if you create individual containers within sections. For simple designs, you’ll see that the designer used a simple background for the entire page. This is when you can container the entire page into a single container.

(left) Single container. (right) Multiple sectioned containers.

View component styles

Make this a habit to click at every component you are styling in the art file. There are settings like font size, letter spacing, line-height, border-radius, box-shadow, opacity, and more. Our human brains cannot translate every bit of information when our eyes play tricks on us. The designer has trusted us to perfect their design to the best of our abilities. All the information is in the document, we just need to look at the details.

Mobile first

I do my best to construct my CSS making the mobile styles the default. If there’s a variation between breakpoints, I use min-width for the breakpoint that’s needed. This way the styles for the larger screens will remove once the user is on smaller breakpoints. Also, manipulating DOM elements to fit mobile is much more difficult than for desktop.

CSS > JS

There’s nothing wrong with Javascript, I just enjoy making things pure CSS as possible. For me, maintaining something in CSS is a lot easier than in Javascript. It may take some extra steps, but it’s rewarding when you didn’t need to rely on Javascript to implement a feature. I’ve done some research on performance, but there’s no clear indication that one or other would provide a greater performance gain than the other.

CSS directory structure

I’ve found that having a decoupling your styles into separate files is very useful. It doesn’t just keep it organized, but also trains you to not create large files. I follow the 7–1 pattern quite closely. Obviously, you want to alter the way you group your files and how you name them according to your project. Not every project will need the exact CSS file structure as the other one.

CSS naming convention

If you’re familiar with BEM, you’ll understand the pain points. It’s a good naming convention, but gets very repetitive the deeper you get into your styling. I was getting used to using BEVM, a variation of BEM, but soon found myself tweaking my naming convention. While Tailwind is one of the most popular CSS frameworks to date, I only like it for prototyping purposes. I don’t see the benefit of using Tailwind to maintain a large scale application or a website. The utility classes are great, but not when you have to use them to style every bit of your element. Therefore, in the project, I used a variation of BEVM and utility classes. Sounds like this would be a good idea for another blog entry at a later date.

I created something interesting

In the process of building this challenge, I found myself reusing a lot of CSS Grid styles. I’ve used Flexboxgrid in the past, and really enjoyed it’s simplicity. So, I create a SCSS library for CSS Grid using Bootstrap naming convention. While using it for this challenge, it was quite helpful. The design has many screen size variations. It presented many challenges because tablet and mobile screens didn’t use the same grid layout. There was an element that spanned 12 columns on desktop, 10 on tablet, but back to 12 on mobile. It wouldn’t be an issue with Flexbox because you can center things very easily, but no with CSS Grid. You have to explicitly call out where you want the element to start on the grid. I’m not sure if this is useful for anyone else, but I created some examples on Codepen.

https://medium.com/media/12043c59a1195c4b8895d51c46d6b31b/href

A CSS Setup Built From a Decade of Experience — Part 2

Shashi Lo — Fri, 02 Nov 2018 14:57:38 +0000

A CSS Setup Built From a Decade of Experience — Part 2

Continuing my 3 part series about the way I setup my CSS projects, the next question I wanted to answer was “why I do things a certain way”.

This is completely opinionated, but every developer will learn what works for them and every developer does things differently. Not everyone will learn by reading books, learn by watching tutorials, and/or learn by just coding. We all have our own ways we learn and implement things. Once you understand what works best for you, grab it by the horn and roll with it.

If you go into my car or go into my side of the closet, you’ll know that I’m not the most conscious person to keep these things tidy. But, if you look at my code and how I structure my directories, it’s pretty spicy. You betcha, I love food. If I could travel the world eating different types of ethnic foods as my profession, I’d do it in a heart beat. Any who, like Mark Zuckerberg famous said,

“I really want to clear my life to make it so that I have to make as few decisions as possible about anything except how to best serve this community.”

Decision Fatigue as it’s known. President Obama, Steve Jobs, Albert Einstein, and many more lived by this. The idea is that to use your brain power on something more important than picking your appearance. So now you’re wondering why I brought this up. It boils down to, why I do things a certain way.

I was called a “grid nazi” once. Yes. I’m Hmong Asian-American, so I’m pretty damn sure I’m not one. But what he meant was that I was very picky with his design and how it didn’t align with other elements because he was free-handing it. What I was trying to get at was that I liked his design, but I wanted to teach him how to be more conscious of keeping things symmetrical. Why? Because in design when things flow together, they’re more appealing. When things are cohesive, elements and components are seamless. So to the man I was providing constructive criticism, I was just simply providing my professional feedback.

In development, when I made critical decisions like being a “grid nazi”, it’s because I’m planning for maintainability. If things makes sense the way they are, why change it? But if there’s room for improvement and a way to make your code more maintainable, it should become a dance battle!

To clarify, what I mean by dance battle is you need to think of the pros and cons. Is it worth the time to restructure this particular code to be more maintainable. Next, what’s the effort level. Time = money as many say. Even if you’re not directly receiving money from your efforts, everything that you do with your energy is taking something else away. Therefore Decision Fatigue comes into play. In the agency world, there is no such thing. Oh trust me, I know. I’ve worked with many agencies and there’s always one sameness, deadlines. They’re never moved and scope creep keeps building up. I totally understand why though. You’re working for a client and they have an expected launch party or an event that this project correlates with. But there’s ways to educate your client to ease the stress level of your team.

Once of the best things I did was explain to a client that if they wanted to keep their deadline the same, we would have to create post-launch items to come back to after launch. This would be at no additional cost, but it would prolong the project. When you set clear expectations on what’s feasible with the amount of time allocated towards the deadline early and often, clients resonate with your concern about getting everything completed by launch day.

A CSS Setup Built From a Decade of Experience — Part 1

Shashi Lo — Wed, 11 Apr 2018 15:47:01 +0000

I’m often asked how I structure my CSS files for projects, why I do things a certain way, and why I’m so particular with my Git process. I have experience architecting projects with CMS’s like WordPress, Drupal and Magento E-commerce. I’ve also built custom PHP application solutions built with Codeigniter and Laravel. And lastly, I’ve implemented Javascript applications with React, Vue, and Angular in projects. I’ve got so much broad experience that I’d love to share with you.

First of all, in the spirit of decoupling things, I’m going to make this a 3 part series. I use SASS and SCSS files because I enjoy the syntax and I’m comfortable with it. I utilize GULP to precompile my SCSS files, but would use Webpack if it was for a Javascript project.

How do I personally structure my CSS files for a project?

It’s often confusing when you introduce a CSS directory naming convention to your team of developers. The mindset is, why make CSS more difficult to find things? If you are asking yourself this question, then let me ask you this in return. Why are all your components in separate files? It’s the same reason why CSS should be decoupled for the ease of figuring out where changes are, to allow Object Oriented programming, and less chance of merge conflicts.

The best thing I’ve experienced is to decouple your project structure. I start off with the 7–1 folder naming pattern. If you are working with a CMS, confine your folder structure towards the CMS. For instance, in Drupal you have blocks, views, nodes, pages, etc. These terms relate to the CMS. Therefore, if I’m writing styles for a view, I’m going to create a file inside the views directory of my SASS project just for this view. Therefore I would end up with this folder structure:

sass/

base/

blocks/

nodes/

layout/

pages/

views/

Now, if I was working with a Javascript application, my fold structure is different. It would be more component driven, but follow the 7–1 Pattern meticulously. Each component would have it’s own SCSS file to keep them completely isolated from other components. They will have shared styles, but thats when you put global or shared styles into specific files. In the instance of the 7–1 Pattern, ‘components’ are HTML DOM components and not your application components. I create a new directory called ‘elements’ and place my HTML component elements into that directory.

sass/

abstracts/

base/

components/

elements/

layout/

pages/

vendors/

As you can see, the 7–1 Pattern is a good start, but you should modify it to allow similar naming conventions towards your project. There is no right way or wrong way to do this, because in the end, all these files will be compiled into a minified CSS file anyway. It’s more of a personal or team preference on how you want to organize your SCSS files.

As a developer, your mindset should always strive to improve. As Olympic Gold medal sprinter Kim Collin quotes,

“Strive for continuous improvement, instead of perfection.”

So true because there’s always a better way to do something, you just need to figure out how.

The Birth of Fresh CSS

Shashi Lo — Fri, 24 Mar 2017 13:58:33 +0000

I was suppose to write an article each week for 52-Week Writing Challenge , but I was sick the entire week. So, I’m going to double up next week and write two articles. This is article 2 of 52.

Adding on from my previous article, My Journey to a Better CSS Framework, we at Creed Interactive felt the need to create a CSS framework that fit our team’s needs. We started to have great conversations on what we needed and how we would bridge the gap between design and development. One of the conflicts we were having were inconsistent component layouts. Some sections didn’t snap to the grid, while others went beyond the container. With further discussions, these are some of the features we decided on.

12 column grid

We decided to use a 12 column grid because the measurements made sense. In theory, 1200 is divisible by 2, 3, 4, 5, 6, 8, 10, 12, 15, 16, 20, 24, 30, 40, 48, 60, 80, 120, 150, 200, 240 and 400. That provides a lot of flexibility for creating components. So, overall, our grid is constructed in 12 columns, 80px column widths, with 20px gutter padding, and 10px padding on the outside of the grids.

1200px width with 20px gutters

With certain designs, we would remove the extra 10px on each side, but this was the standard we wanted to move forward with. Now, we have a good foundation to start our projects with.

Susy Grid System

Continuing the trend of a lean framework that doesn’t require loading unused styles, I decided to use Susy. At first, it was really different from what I was used to, but after working with it for a few months, I really enjoyed it. Building your grid on demand was key to my magic row. The idea wasn’t just to build identical columns with the row, but it was to build all sorts of different column combinations. Wouldn’t it be awesome if you could use “row-md-363” and it would create a 3 column grid with the first and last columns having a width grid size of 3 and the middle one being 6? Removing any and all column size call outs would allow for greater flexibility. We weren’t going to remove it entirely, but keep it as a fallback.

One Susy feature that was going to help me accomplish this was span nested context. It was quite confusing to me at first until I kept trying it. If you look at this example, it was going to allow me to build my row magic with Susy. The next step is to create a global variable that would generate the row classes I needed without manually creating them for all screen sizes.

https://medium.com/media/6c85b9311c27e16e34208f08cf2f7cc1/href

Breakpoints That Make Sense

Media query breakpoints can be difficult. You could use min and/or max width, you could define a range for the breakpoint, or you could target specific screens like retina monitors. After reading “The 100% correct way to do CSS breakpoints” by David Gilbertson, screen breakpoints made a lot more sense. We were working with the old way of pinpointing screen sizes according to what was popular back when NSYNC was the premier boy band. Nowadays, we have many different phones and tablet screen sizes. If you look at the example below, you can see why this new breakpoint view will make sense.

Image provided by David Gilbertson

What’s Next

We will look at the actual code of the framework and continue to build it out. Setting up a github page would be a good start and open sourcing it.

My Journey to a Better CSS Framework

Shashi Lo — Mon, 06 Mar 2017 17:57:55 +0000

I told myself I need to start documenting my thoughts and knowledge. I actually have useful things in my brain that could help others. Who knew!? So, I’m going to join the 52-Week Writing Challenge. My goal is to pour out my knowledge and experience about web development, mostly front-end. Anything from dabbling into a new framework to my daily work experience with projects at Creed Interactive.

How it started

How many times have you defaulted to using Bootstrap as your CSS framework because it just works? I’ve done it plenty of times. There are other solutions available, but when you’re working in a team setting, it’s difficult to introduce something new to developers who do not focus on the front-end.

With many viable solutions like Bootstrap, Foundation, Semantic UI, and more, its reasonable to think there’s no real need to create another framework. But I’m an innovator! I enjoy making things better, faster, more efficient, therefore, I’m going to build my own.

My Aha moment

We were conducting an audit on one of our client’s websites because it wasn’t performing well. The obvious issues were: large images, too many Javascript plugins, and large CSS files. You know what I’m talking about if you’ve worked with plenty of WordPress and Drupal websites. After optimizing and resizing the images down to the proper dimensions and minifying both Javascript and CSS files, the performance was much better. But knowing myself, I wanted more improvements. I’m a big fan of lean solutions and removing unneeded extra code. So I ran an audit with Chrome’s developer tools. When I went to look at the “Remove unused CSS rules”, I was surprised that there were over 1800+ rules not used on the homepage. By default, Bootstrap’s CSS file is around 192 kb and 151 kb minified. This doesn’t even include the Javascript file that is 47 kbs minified. Yes, you can remove some features and modify it’s core, but that’s more work on your end. Foundation does an awesome job of providing an interface for you to choose what you want to include/exclude in your base CSS file. But even then, I found myself wanting to something with my knowledge and skills.

My first thought was to create something lean but not too different. My team was familiar with Bootstrap’s class naming convention, so I was going to keep that part. Our team was also experienced in SASS, so building a base SASS system was ideal. I chose to use Gulp.js over Grunt and WebPack for our build system because it was lean and easier to learn. What I wanted to improve was the use of BEM (Block Element Model) CSS class naming convention. We also had been using Includes Media for our media queries. Lastly, I had to decide how we were going to build our grid system. After discussions with our creative director, we agreed that a 1200px 12 column grid with 10px gutters on both sides would be best for our future designs. At the time I was developing this new CSS framework, Flexbox was just becoming ready to use across all major browsers. In anticipation of this great news, I had a great idea of how to streamline building columns. Why do we have to call out individual column classes that have the same exact column width with the size of each column in it’s own element? That’s because we’re built to do it this way. Well, you don’t have to anymore. Let me save you a couple lines of code from your DOM.

In the example above, you can see the common way to call out a row and a few columns to build a footer with side by side links.

Doesn’t that look so much better!? If the columns are going to be the same size, why not control that in the row? It makes for less code and improved efficiency. Yes, it means less control over each column, but in some cases I find that it is a valuable trade-off.

The Magic Row

The ability to control the outcome of all columns within a row is amazing to me. Less code, less clutter, and increased efficiency. Let’s take a look at the magic.

Using wildcard selectors for the row class allows you to reference the different screen sizes (xs, sm, md, lg, xl) without adding additional code. Now, all references of the class name of row- will use the same styles.

The child combinator is something awesome. It will select elements that are direct descendants. Basically, your first cousin. This eliminates the use of individually assigning each column a class name.

https://medium.com/media/27d002c840b86ff4d890715ac85f0b63/href

What’s Next

Everyone wants to do things better and faster. In development, if you can’t improve what you do on a daily basis, you will fall behind and eventually be replaced. Learn how to do what you do with less. As they say, less is more.

I didn’t intend this to be an article of series, but if I’m going to keep up with my 52 blog articles in 52 weeks, I’m going to stop here and continue adding my thoughts on next week's article.