#self taught engineer

[blobpost]

Mini Project Retro: Building a a Product Landing Page Page With HTML & CSS

One of my last freeCodeCamp Responsive Web Design projects: a product landing page. Like before, there were some user stories to guide it, an already-built example, and simple instructions to avoid using fancy libraries and frameworks so you can learn the ropes with the basics.

The end result is here.

What I did

I created an imaginary minimalist decluttering service, an idea that came to me in a flash.  It was meant as a parody at first, but I ended up paring back the words and leaving three options for users to choose from.

I researched some pricing table examples on Dribble but took most inspiration from other websites I like, e.g. Aesop. I wanted to find a compromise: what is readable is not usually the most alluring visually, and what is alluring visually isn’t always the most readable or usable. 

Lessons

Creating responsive divs is a challenge

I ended up with three imaginary services to choose from, not knowing this would be a challenges for responsiveness. Given the minimalist design and ample room to breathe between elements, resizing everything inside the box for smaller-than-desktop but bigger-than-mobile displays wasn’t an option. Deleting one wasn’t either ;)

It was stuck with an awkward in-between sizes scenario: for large displays, the 3 items would sit in a flex row. For mobile, they’d be a neat flex column. But in the middle...do I squish the content inside or push the items into a different layout? In a real life scenario, you wouldn’t cut a pricing scheme because the developer couldn’t figure out how to display 3 boxes, would you? Or...would you?

Turns out there aren’t great solutions for the awkward in-between: for example, the Washington Post narrows the boxes ever so slightly on their GDPR consent form and then forces the boxes into a column. 

My solution was to give the individual items a max-width, and push one down with flex-wrap. Given more time, I’d have designed the boxes differently, but at that point I’d already spent a lot of time figuring out their look and didn’t want to invest much further. Lesson learned. 

What I’d do differently

Different designs for multiple screen sizes. This is a recurring theme. I have a mental sketch of how I want things to look, but for these small projects I don’t lay things out in Figma or fancier design tools. It’s more time-consuming but fun to tweak as I go along for now. For something more complex I’d ensure there are appropriate designs for mobile vs. designs for desktop, and the content looks good in all of them. 

Introduce a sizing system. This is the first project that challenged me in terms of CSS, and I read 'Refactoring UI’ after, which made me realize how I could’ve made things more systematic and saved myself time.

Use SVG instead of PNG. I borrowed a PNG for the imaginary company logo, and really wanted to use SVG, but ended up in a rabbit hole trying to figure out how to resize and crop SVGs, which pushed this as a to do for my next project.

[blobpost]

Mini Project Retro: Building a Technical Documentation page with HTML & CSS

Following up on a previous post, I still have remaining freeCodeCamp HTML & CSS track projects. I decided to focus on the technical documentation page challenge. Like before, there were some user stories to guide it, an already-built example, and simple instructions to avoid using fancy libraries and frameworks. 

The end result is here.

What I did

I created a ‘React 101′ documentation page, trying to add some useful text but keeping it short. I’d learned from previous experience that content generation is the most time-consuming part with these exercises. Sure, I could paste something from MDN like in their example, but I wanted something of my own. 

I time boxed it to a 2 calendar days, which really meant around 8 hours of continuous work.

I researched in the form of asking my Twitter community what documentation sites they like, or if they know of good documentation generation tools.

I personally liked the Svelte and Stripe documentation for their layout, ease of reading and color schemes (I’m going through a purple or muted purple phase). I also enjoy documentation pages that come with a version history, which has more to do with their CMS and user experience than with the visual side of things, but it’s a nice touch. 

The community really liked documentation sites from Stripe, Netlify, Shopify (Polaris) and Prisma. Prisma was new to me and a highlight for the ease with which you could transition between the same documentation page, but for a different database systems (e.g. PostgreSQL, MongoDB, MySQL) or programming language applicable to your situation. For documentation generation tools or CMS, Kirby, Antora, Docusaurus and ReadTheDocs stood out. A few other mentions were mkdocs (a static site generator that's geared towards building project documentation). What was more intriguing was that ReadTheDocs had no pictures on their site, which seems like a missed opportunity. Kirby is also quite versatile. 

Lessons

Styling <pre> and <code> is a challenge, and there are few solutions out there (e.g. Prism)

Though the bulk of the challenge was designed to get you to wrestle with relative and absolute positioning, the other biggie I bumped into was styling code blocks without external help. It’s a non-trivial amount of effort to get code blocks to look presentable on a site, let alone nice. Not even Tumblr has a built-in way to display code. 

First, many CSS aspects went into this alone: how to display the code block, appropriate monospace font families, making the code block editable, wrapping and breaking words, dealing with overflow, number of tab spaces, etc. Whew! I tried many permutations until I landed on something I was happy with. 

Second, I learned that by using <pre> you get a line break before the text starts, and there’s no great CSS way to get rid of it. However, there’s a workaround to start the text on the same line as the <pre> tag.

Third, encoding symbols (<, >, &, etc) into HTML entities without special help means using a lot of &lt and &gt and such. I saw a workaround using a snippet of PHP but decided not to for this project. 

Not to mention all the other user preferences, like having line numbers (using JavaScript) and more. A good best practice article dates back to 2013 but is still relevant today. Unsurprisingly, there are several external solutions but the most popular one is Prism, a lightweight and configurable syntax highlighter (not the same Prisma mentioned before). It’d seem that Stripe uses it, and everyone loves Stripe documentation.

Use  <figure> and <figcaption> for ease of reading and accessibility

freeCodeCamp teaches this too; the <figure> element is primarily for diagrams and pictures but also works with <code>. It can optionally have a caption with <figcaption>. 

Not only that, the accessibility can be improved by adding some ARIA attributes on <pre>:  aria-labelledby to point to the <figcaption> (if there is one), and aria-describedby to point to the preceding text (if it describes the example).

Making code blocks editable gives users more control over the snippet 

I learned from the best practice article mentioned before that editable code blocks gain extra navigation and selection controls, like being able to click inside the code and use Ctrl+A to select it all or use Shift+Arrow to make partial text-selections with the keyboard to name a couple. 

Begin with the end in mind: mobile first, large devices later

This is a classic lesson that I carried over from other projects, though I omitted a clickable hamburger menu from this. I entertained a top-sticky, horizontally scrolling menu. But the more I looked into it, the more time this would have added and required more than HTML&CSS, which were the point of the exercise.

What I’d do differently

Add a hamburger menu toggle for mobile. I kept it simple and chose not to display the navbar on mobile since my page isn’t so long. 

Add line numbers to the code blocks. This was brought up in a best practice article, but felt it was outside the scope of this project to add that much JavaScript. Or...

Use a tool like Prism to style code blocks. It seems like a no-brainer, but I wanted to see how far I could get without it. 

Change the colors. I liked this combo but I’ll be the first to admit I’m not 100% sure how to mix things up in a more aesthetically pleasing way. 

[blobpost]

Skills Engineers Need for the Future of Work: A Summary

Original source

Advanced problem-solving skills and critical thinking

Assess the risks and rewards of new technology and its effect on cities, people and the environment

Keep people safe and consider ethics: more people will be involved with and affected by technology than ever before, and it is the job of the engineer to keep people safe (and speak up)

Untangle problems that will arise from the integration of new technology into existing businesses and processes

Analyze potential solutions to determine which is the ethical and effective choice, and avoid making decisions based on interests, biases and emotions, rather than the facts.

Behaviors:

Ask questions to gather relevant information

Identify biases and minimize their influence

Evaluate all available data relevant to the situation or problem

Ask for feedback and collaborate with those involved in the situations, including people with different backgrounds, perspectives and knowledge specialties

Generate a variety of possible solutions and determine the optimal implementation, given the desired consequences

Adaptability

Adapt to changes: new technologies, new markets, new processes and ways of doing things

Taking initiative: don’t wait to be told what to do. Evaluate problems and develop solutions quickly, without constant supervision and direction.

Behaviors: honing your curiosity and creativity, multi-disciplinary thinking, e.g. having an interest or expertise in different field(s)

Collaboration, communication and thoughtful self promotion 

Cross-functional collaboration and display of intercultural sensitivity;: with team mates and engineers/non-technical staff from other companies and organizations. Take in everyone’s contributions and analyze them to develop the best solution. Have a conflict resolution mindset. 

Have a network and tribe of advisors you can go to for personal growth: peers, managers, friends, family, therapists, etc.

Professional self promotion: high quality writing, speaking and ability to make videos or other materials

Ability to network, manage public relations 

Empathy and the “personal touch” as you need to manage distributed teams, with much of the interaction occurring digitally

[blobpost]

In Review: Week of February 3

Things I did

freeCodeCamp survey form in a CodePen (plus mini retro) 

A bunch of React component and props exercises: an envelope, a credit card, a demotivational poster. 

Thoughts

Much less frustration than before and started to enjoy the process. I like the freeform exercises without a given solution that I’m going through right now. They’re forcing me to get creative with my approaches. 

Things I learned (or refreshed knowledge of)

Technical:

Variables, scope and closure in JavaScript;

Layout with CSS, and positioning items;

How to write better CSS (from a few sources);

UX of forms and how to make forms accessible. 

Soft skills: 

Habits of highly effective developers and ten principles for growth as an engineer;

Got clarity on how to express my career change and values to other people;

Not a soft skill but finished an interesting book on the economic history of capital and job automation: The Technology Trap. 

Things I want to change (or do more of)

Learn more about styling beyond simple CSS once the freeCodeCamp projects are over;

More React practice;

Get a structure for my website once I have more projects under my belt;

Go back to CodeWars some time soon.

[blobpost]

Focus your efforts

I’m reading a book called A Smarter Way to Learn JavaScript after hearing about it on a podcast. 

It hit a painful nerve I bumped into while learning how to code. I’ll wake up with lofty ambitions, like learn and practice code for several hours a day on end. I feel we tend to glamorize the idea of sitting in a chair till your butt hurts but you get your ‘it works’ moment at the end. 

Well, the hard reality is that it’s not possible. The brain says no, for evolutionary reasons that are outside of our control, no matter how many hacks and nootropics one can throw at it. It just wasn’t made for that. The book called ‘A Mind for Numbers’ said so as well: your brain can only handle so much ‘focused learning’ before it can no longer see creative solutions to difficult problems. At that point, you’re like a hamster spinning on a treadmill. 

But this chapter from Mark Myers: “A Smarter Way to Learn JavaScript: The new approach that uses technology to cut your effort in half” nailed it for me and provided a process to follow:

Cognitive portion control

When they're doing hard-core learning, even strong-minded people get tired fast. You may be able to read a novel for two hours at a stretch, but when you're studying something new and complicated, it's a whole different ballgame. Studying new material for about ten minutes is the limit, before most learners start to fade.

But here's the good news: Even when you've entered the fatigue zone after ten minutes of studying, you've still got the mental wherewithal to practice for up to thirty minutes. Practice that's designed correctly takes less effort than studying, yet teaches you more. Reading a little and practicing a lot is the fastest way to learn. 

Study, practice, then rest

If you're intent on mastering the fundamentals of JavaScript, as opposed to just getting a feel for the language, work with this book and exercises in a 15-to-30-minute session, then take a break. Study a chapter for 5 to 10 minutes. Code for 10 to 20 minutes, practicing the lesson until you've coded everything correctly. Then take a walk.

(Quotes edited for conciseness).

[blobpost]

January 21, 2019

It’s been two months since I wrote here. The regular posts stopped working because the learning intensified, which is great for learning but not so much for the self discipline I had planned for myself. 

I recently came across some  inspirational posts about learning in public and getting into the habit of ‘creating learning exhaust’, which acted like a wake up call. So I’ll try a different pace, perhaps weekly. 

In the last 3 months: 

Things I’ve done

Learned basic JavaScript fundamentals, modern JavaScript and ES6. It took three months to get a basic grip on how the language evolved, what it’s good for, and modern usage conventions. It was a struggle to find resources that didn’t contradict each other on what was best, or were out of date by the time I read them. The bulk of this was via Tyler McGinnis and freeCodeCamp

Practiced up to 6kyu on CodeWars. The exercises were useful to get a feel for what the language could do and what its most used features would be. It wasn’t always easy to understand what a problem author wanted, but it was good practice for the real world where there won’t be detailed instructions. 

Created a document with all the things I learned along the way. It’s semi-private for now and contains just enough plain English knowledge of all the things I’ve had to learn how to do, e.g. use the command line, setup a shell, how JavaScript engines work, how to configure Webpack, using npm, etc. There was an added incentive to document this and share with my brother, who is also learning how to code for his graphic design university projects. I’ve yet to publish it because I don’t know enough to figure out what ‘my original take’ is, if any, and I’ve not yet covered all the resources available to me online.

Completed the freeCodeCamp Responsive Web Design Certification. This was a refresh on what happened in the world of HTML and CSS in the 12 years while I looked away. I have yet to complete all the final projects (3/5 remaining to build your own documentation site, product landing page, and form) but I plan to tackle them over a few weekends. 

Set up the most basic landing page on Github pages. I’ll probably change it a million times as I learn more, but it was a personal challenge to get something out there. There are mighty plans to update the CSS and learn how to use something like Bulma, but my priorities are with React for the next 3 months. 

Things I’ve learned

How to learn better. I quickly realized that many of my learning habits weren’t effective, and started examining where I was falling short and what to do about it. I read a book called ‘A Mind for Numbers’ by Barbara Oakley, which also underpins the Coursera ‘Learning how to learn’ course as it’s the same person behind it. Although I had a plan for learning and plenty of resources at my disposal, I didn’t make enough use of spaced repetition, flailed in a pool of easy-to-accomplish tasks that didn’t challenge me enough, and didn’t test myself often enough. That booked changed things, which leads me to another point: 

When to give up a course that isn’t working, and start a more appropriate one. I started with a series of highly recommended paid courses that went really well until I hit the React part. The mental leaps required to cover the material were too big for my unprepared mind, and not a day went by without wondering, “am I too dumb to understand this or what?” In the past I would’ve gone full on completionist, but for the sake of forward movement I concluded it was sadly too advanced for me at that moment in time. Luckily I wasn’t too far in when I swapped it in favor of a course with a clearer structure, spaced out lessons, and a teacher who made good use of learning techniques (i.e. lots of practice and spaced repetition). I liked this new teacher, and as soon as things started to click I looked forward to doing more, even the challenging parts. I now think it’s OK to not finish what you start if it doesn’t work out, or worse - makes you dislike the topic you were once so passionate about. Life’s too short. Alternatively, give yourself permission to come back to it later and see if it still makes sense to finish. 

You need role models. This was one of the big reasons why I stopped coding in high school. The web and technology in 2006 weren’t what they are today. No one I knew was interested in this area, and no one stood out in the community either. It was anonymous, made up of people I couldn’t relate to, or didn’t see myself learning from or being inspired by despite some inclination towards code and encouragement from teachers. At first I looked for role models on Twitter but the 140 character format didn’t work out; wisdom doesn’t work like that. Instead I found them via podcasts (e.g. Ladybug), blog posts in my interest area (Chris Ferdinandi while learning vanilla JS), as well as people whose career trajectories I admire. Tania Rascia was a name I came across when learning about higher order functions JavaScript, and I’m a self confessed fangirl. I like her style, writing, and no-nonsense approach to being a career-switching self-taught coder. 

In the upcoming 3 months:

The only thing I want to do is complete a React ‘bootcamp’ series and deepen my knowledge of JavaScript so I can get hired by mid-2020. The idea is to build a few apps of my own and see what it feels like to branch out into a language different to JavaScript. 

If you want to say something or share something, reach out to me @diemkay​ on Twitter. 

[dees-euphoria]