[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding learning and loving CSS with Hui-Jing Chen, UX designer at Shopify.

[00:00:19] HC: So CSS became like my hammer and I just smashed everything. But the one good thing that came out of it is that I was exposed to a lot of lesser known CSS properties.

[00:00:30] SY: Hui-Jing talks about how playing professional basketball led to becoming a developer, how she became a CSS expert, and why you should always read the specs after this.

[MUSIC BREAK]

[AD]

[00:00:48] SY: TwilioQuest is a desktop roleplaying game for Mac, Windows, and Linux to teach you real world developer skills. Take up the tools of software development, become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.

[00:01:05] Heroku is a platform that enables developers to build, run, and operate applications entirely in the cloud. It streamlines development, allowing you to focus on your code, not your infrastructure. Also, you’re not locked into the service. So why not start building your apps today with Heroku?

[00:01:22] Cloudinary is an end-to-end image and video management solution with a powerful API that lets developers upload, store, create, optimize, and deliver your media with ease. They have a generous free plan as well as advanced plans with enterprise configurations. So check out Cloudinary today at cloudinary.com.

[00:01:42] MongoDB is an intuitive, flexible document database that lets you get to building and MongoDB Atlas is the best way to use MongoDB. It’s a cloud global database service that gives you all of the developer productivity of MongoDB, plus the added simplicity of a fully managed database service. You can get started free with MongoDB Atlas at mongodb.com/atlas.

[AD END]

[00:02:13] SY: Thank you so much for joining us.

[00:02:14] HC: Hi, thank you so much for having me.

[00:02:17] SY: So you came into coding from a pretty nontraditional route. You played basketball full time in Malaysia. I think you might be our first basketball player that we’ve had on the show. Can you tell us how you went from basketball to development?

[00:02:30] HC: I used to play basketball full time. And I say full time when people say, “Oh, professionally?” I’m like, “No.” Professionally means you get paid.

[00:02:39] SY: Big difference.

[00:02:40] HC: Yeah. But this was like the national team. And being 19, you’re like, “Yeah, the flag is the biggest. That’s the biggest thing. Who needs money? What is money?” Right? But all jokes aside, it was really one of those things, it’s like a highlight of your life. So how it works in Malaysia is that you can do a centralized training thing. So I think it’s slightly different in the States or in most countries where there’s like this big competition. You are with your own clubs for the most of the year and then you go for the national team. Ours is different. There’s just you and everyone else on like about 30 other ladies. You see each other all day, every day, we were all staying in the same place. So we train two times a day for six days. We get Sundays off. So it sounds like a lot, but the training session is about two to three hours. So throughout the day, you’ve got pockets of free time and you can do whatever you wanted during the downtime. So you could take a nap, you could eat, watch films. So I was just entertaining myself and I was also the IT person on the team. So people will come and like, “Hey, the internet is not working. Can you look at it?” And they’re like, “Oh, I can’t print stuff. Can you look at that?” And I’m like, “Okay. Sure.” So my coach just kind of saw me and he’s wanting to make this connection, right? “Oh, computers! Website lives in computer. Hey, can you do something about our association website?” Because I think we had a vendor to do it, but they left about two years ago. So the website was not updated for like a long time. So he was like, “You know, you seemed good with computers. Do you want to do something about it?” And in my mind, I was like, “It’s not the same thing, but sure.” So I was armed with very important skills. I could Google stuff. And I knew that if you right clicked on a website and view source. So armed with these two really critical skills.

[00:04:40] SY: That’s right.

[00:04:40] HC: I kind of Frankensteined a website together because I had an idea of what I wanted it to look like. I had seen like other national teams’ association websites. I’d seen the NBA’s website. So I just copied and pasted the bits that I wanted and then I showed it to my coach, took a look at it and said, “Oh, yeah, that looks nice. Can I add a content?” I was like, I just suddenly looked at him and I’m like, “That was not part of the feature requirements,” in my mind, right? So immediately after that, I kind of started working on a version two of it. So this meant that I was spending a lot of time and my roommate was like, “What are you doing?” Because she knew I wasn’t working, right? I was like, “I’m doing this website thing.” She’s like, “You’re spending all of your time on it,” and she just walked away and then that kind of flipped the switch of like, “I think I kind of like doing this.”

[00:05:30] SY: So you had this experience building something, which is very exciting and something you really enjoyed. How did you get from doing that to working as a developer?

[00:05:40] HC: Presently, I still believe this. It was luck. My first job wasn’t even in development. I kind of joined a small consultancy firm and it was like a typical office job. But one day as I was contemplating coming back to Singapore, I can’t even remember. It was an unrelated article that listed on companies that allowed remote working. So it wasn’t like I was actively looking for a job. I was like, “Oh, this is interesting, clickbaity, listicle I’m bored and let’s click it.” So there’s this particular company called Pixel Onion. It turns out they were a Drupal agency and they had a landing page instead of a website that said, “Oh, we’re so sorry that our website’s not up right now because we’re busy making yours.” So it was a really cute placeholder.

[00:06:28] SY: That’s a great placeholder.

[00:06:30] HC: They didn’t say we’re hiring or anything. I reached out and I got a one sentence reply. It’s like, “Oh, what are your strengths?” And then I counterpunched them with like an essay. And after that, I got replies. So it just so happened. So there were two bosses for that firm and one of them was going to be in Malaysia for some conference or something. He’s was like, “Why don’t we meet up for a chat?” I was like, “Yeah, sure.” So my conclusion is that they just took a huge chance on someone who built all of two Drupal websites in their entire life.

[00:07:07] SY: Did they know that when they gave you a job?

[00:07:10] HC: Yes. I was like, “I built this and that.” And I was like, you know, awkward grid like he-he-he, and I think it was just like… She looks like she wants it. So let’s just give it a try. We can only spire her later, maybe.

[00:07:26] SY: That’s true. So what was that first job like?

[00:07:30] HC: It was so much fun because I think it was at the stage in my career where like, “You don’t even know what you don’t know and everything’s so new.” I learned all the periphery around how to be a better developer in terms of like how to work on a T, like Git, writing responsible to Git messages. You think that this would be a common sense thing, but I have seen projects where I’ve seen seven consecutive commits and just said, “Fix.” Fix what?

[00:08:01] SY: That’s so helpful. Yeah.

[00:08:03] HC: Yes. So things like that. And I think it was really fortunate that I was exposed to this at my first job.

[00:08:10] SY: What kinds of projects did you get to work on?

[00:08:13] HC: It was fun because it was like an agency style setting. So got a lot of different projects and they were short term. We didn’t really have retainers for like major things. So personally, during my time there, I worked on a university website, church website, a lot of educational institutions somehow like Drupal. So we got those, but everyone wanted like a different design. So we had in-house designers and a UX team. So they’d come up with kind of really different designs all the time. And I think that was when I started to gravitate toward the front end of things.

[00:08:47] SY: So that’s where you got your exposure to CSS?

[00:08:49] HC: Very much so.

[00:08:50] SY: So how long ago was this? Set the time for me.

[00:08:53] HC: This is 2013.

[00:08:54] SY: What was the world of CSS like at the time? What were people using? What were they into?

[00:09:00] HC: Clients in Singapore at the time, I remember we were still using books. SAS was really big. Susy was, it wasn’t even a framework-ish, but it really did the math for you because Susy, I remember using Susy importing that and using it, like I have to build multi-column layouts and then now use Susy to do the math.

[00:09:23] SY: And what is Susy?

[00:09:24] HC: I think they call it a layout library or something because it kind of simplified a lot of the math for you. So the syntax was like, I think you just declare columns or something. I can’t remember because I don’t use it anymore, but I remember that it was good for math. And the reason why we had to do a lot of math when we were using floats back then is because of the way browsers would kind of deal with sub-pixel rounding errors and things like that. I suspect it was that, because usually, for example, if you want it three columns and you want it to make sure that your grid items didn’t overlap each other, every third child or something and then you’d have to change the margin. So there was a lot of nth-child things going on just to make the math work. So that was 2013. Responsive Design was starting to be something that, I think, because the phrase had been around for a while, but I think there’s a lag time between the developers and then the client. I feel that that was that when I first joined. So that’s what I can remember from that.

[00:10:39] SY: So if that was CSS back then, how would you describe CSS today?

[00:10:44] HC: It is so much more robust because from 2013 to 2020, I would feel the biggest difference is that Flexbox support is really ridiculous how well Flexbox is supported now.

[00:11:01] SY: And what is Flexbox?

[00:11:02] HC: Flexbox lets the browser determine the best size for your items. So this is going to sound weird, especially if you’ve not done web development before. But prior to Flexbox, how you would size things, how you lay things out is that you tell your browser like, “Okay, box, I want you to be 300 pixels.” Or if you want to be flexible, “Okay, you can be 30% of your parent container.” But with Flexbox, you kind of give the browser guidelines. You’re like, “Okay, if there’s a lot of space, I want you to go by this ratio. If there’s not enough space, you can shrink by this amount relative to the items next to you.” And then you give it a starting size. But you don’t control the end size, depending on the width of the viewport, which is the window or the browser window. It kind of determines what that size is. So it is a different mindset. It’s a different technique, I would say. So Flexbox is the first layout technique, whereby even the way you write the code is different. So what it used to be is that you would explicitly size a width or a height on an element and call it a day. For Flexbox, and the newer one is Grid, what you do is that you say to the containing element, “Apply display flex on the parent container and then all the children, all the direct children become flex items. So again, it’s a really different technique from what we used to have, but it’s also a lot more powerful.

[00:12:44] SY: So as you’re talking about CSS and the state of things today and what it used to be like when you first started, I’m sensing a lot of passion and excitement about CSS for me, which is very hard to find. I think most developers don’t know much about CSS and are also very afraid of CSS. What makes you like it so much?

[00:13:03] HC: Like I said, I have no computer science background to begin with. So I came in like practically a blank slate and somehow of all the basic web technologies you need for web development, which is HTML, CSS, and JavaScript. CSS kind of just felt more comfortable to me. I was not the best web developer at the time because I kind of fell into doing what I found most comfortable. So for like the first, I would say, almost year, I would try to do everything in CSS. So CSS became like my hammer and I just smashed everything. But the one good thing that came out of it is that I was exposed to a lot of lesser known CSS properties, and I really dug into each property. And there are like more than 500, if you look at the spec. And I managed to, because for example, people would want like an accordion. So an accordion is like a list of items. You click an item and it will expand. I think that’s where the name accordion came from. In an ideal world, you probably just like passing a few lines of JavaScript toggles in classes. Great. Easy job. No. This idiot wanted to do it completely in CSS. So I figured out how to do things like use the checkbox hack and then really spruce it up to hype it. It was a checkbox. So in that sense, it made my skill level in CSS go up a lot faster.

[00:14:41] SY: How are you learning? What tools, what resources were you using? What was your process?

[00:14:46] HC: So I found that the way that I learned best was not to binge on stuff. So I went for a variety. So I have an RSS reader. I still do. I don’t know how many people still use RSS feeds, but I did. I subscribed to a lot of web development, WADs, CSS-Tricks, Smashing Magazine, A List Apart, AWS. So articles were one thing. I think at the time books were still a thing. So I did read a couple of books. I can’t remember what they were anymore. I remember at least two or three. And then I also did those online courses. So I remember the first one I did was Codecademy. And so they had like intro to web development courses and there were multiple platforms that were offering the same course. And even though I finished Codecademy, I just went into the same course on other platforms because I felt that doing it in once doesn’t sink in. So we repeat it again and again and that kind of solidified a lot of things. And because I was already working at that agency job, it was also a lot of learning on the job. And I felt that’s a lot more motivating because you actually have a deadline. You’re like, “Hey, someone’s paying for this.” And there’s an actual deadline and then your learning becomes very specific. I was like, “I have to shift this very specific feature.” So I have to go figure out how to do it because the world of web development is so broad and so wide. Like if you don’t have a specific thing to build, you can get lost or distracted and then you kind of forget what you were first starting to learn. So I think having a project, so it could be an actual page project, like when I was working it’s something that you want to build, but that means something for you. You go to work and it helps focus the learning.

[MUSIC BREAK]

[AD]

[00:16:42] SY: Explore the Mysteries of the Pythonic Temple, the OSS ElePHPant, and The Flame of Open Source all while learning the tools of software development with TwilioQuest. Become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.

[00:17:00] No one wants to manage databases if they can avoid it. That’s why MongoDB made a MongoDB Atlas, a global cloud database service that runs on AWS, GCP, and Azure. You can deploy a fully managed MongoDB database in minutes with just a few clicks or API calls. MongoDB Atlas automates deployment, updates, scaling, and more so that you can focus on your application instead of taking care of your database. You can get started free at mongodb.com/atlas. If you’re already managing a MongoDB deployment, Atlas has a live migration service, so you can migrate it easily and with minimal downtime then get back to what matters. Stop managing your database and start using MongoDB Atlas.

[AD END]

[00:17:51] SY: As you probably know, a lot of developers do not like CSS. So why do you think that is if you found so much pleasure and joy in coding in CSS and working with it? What do you think is driving the people who don’t like it very much? Where does that come from?

[00:18:06] HC: I think it’s because it’s a completely different mental model from what most people think, what is considered programming. So this might be a slightly controversial thing to say, but I think in tech everyone has opinions and that’s great. Some people have opinions with a capital O. So they have “Opinions”. I think certain people have a very concise view of what programming should be, opinions about programming languages, how they should look like. For example, I think the general good practice for code is modularity. You don’t want code that affects other sections of your code base. That’s all well and good. And then they come in CCSS, which is a generally very global style of implementation and then like, “This is terrible. Who came up with this?” And I think it’s because you come in and your exposure to CSS is colored with your existing experience. So you’re judging CSS based on your idea of what a good programming language should be. But it’s completely different. One thing is that it looks deceptively simple because it’s just a bunch of rules, like text, color, green to screen. How hard can it be? Well, you can go into so much more. So I feel that for CSS, there are things that are really straightforward and really easy and then there are things that involve you actually understanding how the browser recognizes the CSS values and properties and what the project does to it. That’s why everybody gets frustrated, like especially earlier that it’s so hard to vertically center align something in the past. And then people just feel that this is something that’s supposed to be easy. But if you actually sat down, I don’t think they give an extra thought to, “Oh, how does the browser actually figure out where that center is and how to get that thing there?” It is still hard for the browser to figure out how tall things are. And I think Rachel Andrew, who is one of like the thought leaders of CSS, and I learned a whole ton from her, her talks always highlight that it’s hard to figure out how tall anything is on the web. And I think that a lot of people, it’s not something that they consider, because at the end of the day, I still feel that we fall back to what we’re familiar with. It’s called a web page. Consciously or subconsciously you still think of it as a physical page. And the way we design something for a physical page be it by hand or even in digital graphic software is that you can just move things around. It’s so simple. But the browser doesn’t work the same way. So again, that’s because it’s not the same thing. To me, it’s a lack of understanding, and so having preconceived notions of how it should be.

[00:21:13] SY: Yeah. So do you think that if we spent just more time with CSS and specifically with the intention to learn how it works, how the browser interprets these properties and display these attributes that we have, if we took the time to really understand it, do you think at that point, we’d learn to love it?

[00:21:33] HC: I wouldn’t say love it, but I think you’d, at least, be able to begrudgingly accept that it is what it is. And I say this because like, I really focused on the front end and I don’t mind writing backend code, but I won’t say I love it. To me, it’s like, “Okay, I have to do it. I’ll figure out how to do this, how do to do that, like database calls, whatever. But I’ll do it. I’ll do it.” I mean, to me, it’s something that’s necessary, but I won’t think to want to like change it. I feel that it’s another paralleled track of knowledge. The only thing I can hope for people want to pick up CSS is that try to let go of your… if you come in thinking, “Oh, this is going to be horrible, like CSS is terrible,” I don’t think you’re going to get very far. In fact, you’re going to get very frustrated because you’re trying to fit CSS into that box in your head where CSS isn’t shaped like that. So if you let go of that preconceived notion of what you think CSS should be, it’s a project like an alien language, right? You see an alien for the first time. Don’t try to force the alien and to speak English and then think the alien is stupid because they don’t speak English. You kind of like try to figure out, “Okay. This alien language, how does it work? What’s the word for apple here?”

[00:23:01] SY: So another aspect of CSS I want to touch on is the spec process. I know that one of the other things that you advocate for is reading original specs instead of just relying on blogs and tutorials. And I have to admit, reading original specs for me is still terrifying. I’m just so convinced that they’re not going to make sense to me and just reading other people’s blog posts and tutorials feels just so much safer. Why are you such an advocate for reading original specs?

[00:23:27] HC: To be fair, earlier written specs did not have the average developer in mind and I think that’s where that impression that that the specs were terrifying came from because I don’t know what they were writing. It looks like English. It sounds like English, but it definitely doesn’t feel like English. So it was very technical way of writing things. It was mostly to describe algorithms where we’ll describe how things are supposed to behave. Partly any diagram, this is what it is. It’s a spec. But like CSS shifted to a module style of specifications. So in 2000, a decision was made to kind of split up this huge, like, I don’t know, 500-page monolithic document into a specific module. So you have things like I mentioned Flexbox earlier. So you have a section of the spec that is just for Flexbox. You have a section of the spec that is just for say box alignment. So everything gets split up into little chunks. And I think with that, it was partly to make it easier for the editors to maintain as well. So you can’t work on a 500-page document all at once and updates would be really slow if you did it that way. So if you broke it up all up into different modules, you could kind of push certain things for like the committee is discussing a lot of issues around funds today, these meetings, for example. The font spec can move forward, even though the others are not moving. I think that was a rationale. And with that split, I think there was also discussions within the CSS Working Group, which is a group that maintains and develops CSS specifications is they made a conscious decision to write the spec in a more human readable format, in a friendly language, and they added a lot more diagrams. So my first exposure to the one spec that really sold me on it was Flexbox because it was pretty tricky to pick up. And I think because of how tricky it was, a lot of blog posts, I’m not saying all the blog posts are wrong. But you would come across a few that didn’t really have the right information on it or like the suggested techniques were not best practice, simply because I feel that it’s like the whisper game, right? Someone perhaps got their first article based on the spec. That was nice. And then another person based it on the blog post, but maybe kind of accidentally missed something out. And then the third person bases it on the second person’s blog post. And that’s where your information starts to go a bit off already. And as they chain it down and more people read blog post, then you find, “Wait, how come this doesn’t match up? That’s a bit weird.” Or like I try something and then, “Hey, it doesn’t really do what I wanted it to do because I base it off of an example in the tutorial. I’m not doing exactly the same thing.” So it doesn’t behave like I expect that stuff. That’s so weird. So I figured like, “Okay, let’s go to the source.” And the source is the source of the spec. And then I realized that, “Oh, hey, the picture is here.” It occurred to me, “Wait, this is how it is supposed to behave.” So by understanding the spec, you’re not only understanding how it’s supposed to behave. You kind of get a confidence that whether it’s your own like terrible code or you might have uncovered a browser book, because the one thing that I think most people that maybe 90% of developers, they would never think that it was the browser’s fault. You almost always think it’s your fault. Right? “I don’t know how this will work. It’s my own terrible code.” But like sometimes, and especially with CSS properties that are of the lesser use, for example, writing mode, writing mode affects the writing direction of a text on your page. It’s fairly new and lesser used. So they will definitely be bugs because browsers are just software. The projects you and I are working on, it’s just software. There are inevitable bugs in there, whether or not they get flushed out. So if it’s a very commonly used property. These bugs probably got flushed out like really quickly, but then there will always be lingering ones. And when you do this very specific use case, you kind of triggered it, and you never think that it was your fault. But if you read the spec, you’re like, “Hey, hang on, hang on. The spec says it’s supposed to do X and it’s clearly not doing X. It might be a browser bug.”

[00:28:12] SY: There’s also the process of giving feedback on a spec as the spec develops. Can you talk a little bit more about that process and where feedback comes into play?

[00:28:21] HC: The public side of it is, in fact, all of this work is being done in the open. So if you Google a CSSWG GitHub, you’re probably going to land on the W3C repository on GitHub where you can see all the working group editor drafts, and there are like thousands of issues there because even though a bulk of those issues are raised by the spec editors themselves, it’s not as if you and I can go in and ask a question or perhaps give some feedback on a particular property, for example.

[00:28:57] SY: So as a user, I’m wondering what kind of feedback I could possibly give on a CSS spec. Because when I think about the idea of giving feedback, I’m thinking of me having to be knowledgeable enough to have an opinion, to then have confidence in that opinion, to then give that feedback. You know what I mean? Like it feels like I kind of need to have maybe a little bit of authority to give feedback. What kind of feedback are we talking about?

[00:29:25] HC: If you ask me, I feel that the less knowledge you have the better because that’s where the new ideas come out. I feel like even myself, I’m not the most experienced. I’ve only been doing this for about maybe seven, eight years professionally, but I kind of fallen into certain familiar patterns. So I do teach HTML, like front end development to beginners and sometimes the questions they’d be asking like, “Oh, that’s actually really smart.” They would ask like, “How come the browser can’t do this?” My first response is like, “Yeah, because it doesn’t work that way.” But then I stopped myself. I’m like, “You know what? Actually you’re right. Why can’t it do that?” And I think what really brought me around is again, I listened to a lot of Rachel Andrew’s talks. And one of the things she mentions about how new CSS gets created is ideas. Sometimes we kind of fall into the trap of thinking that because it is this way, it will always be this way, but she made a point to say that it’s about what CSS cannot do yet. So the yet is very important because it means just because it can’t happen now it doesn’t mean it can’t happen in the future. And in order for us to kind of reduce the number of times where we have to ask, “Hey, how come the browser can’t do that?” We should think about it like, “I think the browser should be able to do that.” And then what will work, how that possibly be. And I think that’s why people who feel that they, “Oh, yeah, you got to be an expert to raise an issue or a suggestion or something.” I’m like, “No, not at all.” In fact, you should think of it as you are providing a fresh perspective. That’s how things get much better for more people. I just liked the idea of having broader perspectives.

[00:31:02] SY: Can you give me an example of a piece of feedback that was integrated into the final spec?

[00:31:09] HC: So Grid, right? Grid came out in 2017. The version that was implemented widely by browsers was what’s called Level 1. And there was a Level 2. There was stuff that was different to Level 2, specifically something called “Subgrid”. So this feature, what it would do, so I explained a little bit about how these layout models a bit earlier. So for Grid, what happens is that you declare a display grid on a parent that makes all the channeled items good items, so you can align them. But the problem with this initial version is that if you had content inside your Grid items, you can align them up to each other. So for example, you had three Grid items inside your Grid. The content within each of these three items, you couldn’t line them up with each other, but developers started asking, “But I want my inner content to be able to line up.” So maybe you had Grid items that spend two columns and there’s maybe an overlap in the middle, and you want the content inside the Grid item to line up. You couldn’t do that because the content inside your Grid item didn’t know about each other. So because so many people based their use cases that would be solved by having a property or an ability for nest items to kind of know about the greater grid. There were a lot of different use cases that were raised. All of that was written into the Level 2 spec. What I’m trying to say is that just because something gets released it doesn’t mean that’s it.

[00:32:53] SY: So how do we do that? What’s that process look like? If I hear about this new spec that’s coming out and I want to have some input, maybe share my opinions, give my fresh perspective, what would I do? How do I get involved?

[00:33:06] HC: So every browser kind of has an experimental version. So Chrome has Canary. Firefox has Nightly. Safari has Safari Technology Preview. So get those like early experimental builds because that’s usually where the browser engineers will have these features behind a flag. So you would have to go to some configs to turn on that flag so that you can actually try out this new property, see what it does and play around with it. And if you find a behavior that you find odd or there’s this something that you wanted to do, but it doesn’t, you could go to the GitHub for the CSS Working Group. So it’s CSSWG-drafts on GitHub, and you can file an issue. So like I mentioned, if you look on the issues section, there’s like thousands of issues. So you can just describe it and find folks on the CSS Working Group who will kind of read through, triage it, and give you response.

[00:34:18] SY: Coming up next, Hui-Jing talks about three of her favorite CSS properties out of over 500 properties that exist after this.

[MUSIC BREAK]

[AD]

[00:34:38] Images and videos are the heaviest resources users have to download when they use your site or app. Achieving great experience with media was a complex and tedious task. But with Cloudinary, there’s a powerful API that employs sophisticated algorithms, machine learning, and automation to deliver great media experience on any device for any framework in web or mobile app. At Dev.to, we’ve been impressed with Cloudinary serverless API platform and recommend it to developers as the one and only solution they can use to solve all their media problems.

[00:35:13] Over nine million apps have been created and ran on Heroku’s cloud service. It scales and grows with you from free apps to enterprise apps, supporting things at enterprise scale. It also manages over two million data stores and makes over 175 add-on services available. Not only that, it allows you to use the most popular open source languages to build web apps. And while you’re checking out their services, make sure to check out their podcast, Code[ish], that explores code, technology, tools, tips, and the life of the developer. Find it at heroku.com/podcast.

[AD END]

[00:35:52] SY: So you mentioned earlier that there are hundreds of properties in CSS. I think you said there were over 500. Is that right?

[00:35:58] HC: Yeah. Yeah.

[00:35:59] SY: Yeah. Wow. So do you have any favorites that most of us probably haven’t heard of before?

[00:36:04] HC: I’m not sure about having heard before, but yes, yes, I do have a favorite’s list. The top of my list is writing mode. So writing mode, what it does is it allows you to change the direction of the text on your page. So I believe most of us, especially if you come from English-speaking background or a lot of the West, it’s very common: top to bottom, left to right. That’s why English, German, all those languages, that’s how they’re written, but there are other languages, there have been in other directions. So Arabic, right to left. East Asian language, Chinese, Japanese, Korean, vertical, right to left. Mongolian, vertical, left to right. So in a sense, there are all these different languages. And I feel that the fact that we can do this with CSS, it’s a push toward having the web being truly global because I feel it used to be a software limitation that you could only display text in that writing system. So for everyone else who couldn’t, you kind of have to get used to a display that wasn’t really how your language is supposed to be displayed. But I think internationalization has always been a priority for the W3C. But language aside, that also means from a graphic design perspective, because if you look at even print posters, designers are very creative and the text goes all over the place. It used to be really happy to try and do that on the web, but with writing mode. So I always like to tell people that, “Yeah, writing mode is relevant to me because I speak Chinese. Sure.” But even if you can’t speak a word of Chinese, there are still so many graphic design opportunities, again, like changing the direction of the text. So that’s number one.

[00:37:55] SY: Very cool. What else you got?

[00:37:58] HC: I got CSS Shapes as second. So what CSS shapes is, is, okay, I don’t know how many people like look at fashion magazines. But if you look at fashion magazines, a very commonly out is you usually have a model in a very big post, like hands on their hips and the elbow sticking out. And they have had their texts just flow around this image of this model in this like beautiful outfit.

[00:38:23] SY: Yeah.

[00:38:23] HC: I’ve had multiple designers give me that design and it may not be models. It could be just, “I want texts to flow around this chicken because this is a fried chicken advertisement.” I’m like, “Everything on the web is a box. I’m sorry.” But with CSS Shapes, you can actually do that. So what CSS Shapes has is it has some basic shapes like circle on lips and polygon. So what polygon just means is that you can define coordinates for points. You can define a custom sheet and let your text flow around it. And the kicker is that you can even use images for this. As long as your images have a transparency, you can actually let the text flow around the cropped bits. So the text can flow into the transparent parts of the image.

[00:39:19] SY: Very cool. Got one more property for us?

[00:39:22] HC: I have to say Grid. This is a bit of a cliché because everyone’s raving about how great Grid it is. But to me, Grid is a really big game changer because of the breadth of what it can do. So Grid has a lot of properties that come with it. You basically only need three to get started. So you say Display Grit and then you define your template columns and your Grid template rows. So that’s just defining the Grid and then you’re off to the races. But the addition that I particularly like is something called “Grid Template Areas”. So what this does is that it allows you to name specific areas on your Grid and then you can assign an item to that area. So the fun part about this is, okay, let’s try to do this with words. So if you picture a say six by six grid, so it’s like 36 cells, right? I can say I want the first nine cells on the top left corner, let’s say. I’ll call it beer. I can either use the English letters, B-E-E-R, Beer, or I can either use an emoji. I can use that like beer emoji that we have nowadays, label that, and then when I have a good item, I can just say, “Grid Area Beer Emoji,” and it’s going to go into those nine cells. So you don’t even have to say, “Oh, yeah, I want it to start from the column number one to the column number four.” Numbers, I get not everybody’s thing. Don’t like numbers? It’s okay. Just assign an emoji and call it a day. I kind of like that, too.

[00:41:00] SY: Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Are you ready to fill in the blanks?

[00:41:07] HC: All set.

[00:41:08] SY: Number one, worst advice I’ve ever received is?

[00:41:12] HC: Quitters never win, I feel, is not great advice. I think I should explain.

[00:41:16] SY: Tell me about that.

[00:41:19] HC: Because I feel it’s too simplified. It lulls us into switching off mindfulness about why we’re doing what we’re doing. It’s like you’re on autopilot. I want to emphasize that it’s not about quitting simply because something is difficult. I think it’s about knowing when to quit. And I remember reading a book by David Epstein called Range, and he explicitly says the trick is staying attuned to whether the reason for quitting is simply a failure of perseverance or a recognition that there are better options available.

[00:41:55] SY: I like that. Oh, I really, really like that. Number two, best advice I’ve ever received is?

[00:42:01] HC: Strong Opinions, Weakly Held by this gentleman called Paul Saffo. I think to explain these four words, I think his point was you should allow your intuition to guide you to a conclusion. It’s not the most perfect conclusion, but settle on that and then prove yourself wrong. I think that was really interesting.

[00:42:24] SY: Yes, that’s a good one.

[00:42:25] HC: Yeah. It means that it means that you’re kind of keep refining this thought you have and you’re kind of poking holes in your own argument. And to make sure that it’s really watertight before you actually really come to this, this is it, I have poked as many holes as I could. I filled them up and I think this is a good point to have. Yeah, I think we ought to do that a bit more in our lives.

[00:42:53] SY: Number three, my first coding project was about?

[00:42:56] HC: Oh, we talked about this. I was revamping the website for the Malaysia Basketball Association.

[00:43:02] SY: Number four, one thing I wish I knew when I first started to code is?

[00:43:06] HC: On the days where it feels you aren’t good enough to be here, I would tell myself like have a little more faith in your ability to learn new things and also reach out to people around you for reassurance rather than stew in your own insecurities.

[00:43:22] SY: I like that. Thank you so much for joining us.

[00:43:25] HC: Thank you. Thank you for having me. This has been great.

[00:43:34] SY: This show is produced and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.