One year of coding – recommendations for beginners from a beginner

This month one year ago I started my three year long journey as a web development trainee/apprentice at visuellverstehen. I thought this would be a good opportunity to take stock and write about the most valuable lessons that I’ve learned so far and try to overcome my fear of writing. Since the first year of my apprenticeship was mainly about learning the basics of front-end development, this article focuses on this specific area. Most of this is old (but gold news) but I still hope that some of my fellow beginners might find my post useful. I think especially developers who are self-taught might profit from these tips. I’m also curious to hear from other apprentices and beginners as well as the grannies what they found to be valuable during their coding journey. So please share your thoughts!
But enough for the intro. Let’s start:

Know the basics

Knowing HTML, CSS and JavaScript really well is important for building a robust and clean website. The goal should always be to never channel the power of the duck. What also helps is to know how the web works. I am in the luxurious position to attend school twice a year for six weeks learning everything from hardware over networking to programming paradigms – it really changes the way you think about coding. And even before I went to school my instructor stressed the importance of knowing the basics. It seems a little bit too much for some, - you still just want to code, right ? - but it really helps in the long run. It helps with getting a general idea of what exactly you are doing, it helps with making more informed decisions, working with clients IT departments and of course with backend matters in general.

For people who are new to computer science, there is a crash course series providing a good overview of all the topics but you should definitely look further into them along the way.
Also if you don’t know how to use the terminal yet, use it! It’s so much fun and you can spare your computer from useless user interface waste.

Learn about coding principles

I love myself a SOLID DRY KISS. These are acronyms for some of the coding principles. Coding principles help you to follow some kind of guideline, instead of coding ahead with no structure. You don’t have to follow them religiously, sometimes you have to weigh them against each other but either way they help you sensitize yourself for writing (c)lean, understandable and code that’s easy to maintain.

Start with proper HTML

For every project I begin with laying down the structure of a project using plain HTML, not thinking about design and certainly no divs! Just semantic HTML. It requires a deeper engagement with a project's content to find the right HTML-tags(need help with section vs. article?) and you can easily validate your HTML after this step, which you should always do. But why should you really care about a good and solid semantic structure, when you could just mix and match and div it all away? First of all it might happen that the whole internet laughs at you. Secondly, semantic HTML helps with SEO. Thirdly, some HTML-Tags come with built-in functionalities like button or dialog, which you would otherwise have to add in later with JavaScripts, adding unnecessary loading time to your project as well as making your code more prone to errors. And last but not least, because …

Accessibility matters

Visually impaired users use assistive technology to navigate a webpage. Semantic HTML provides further information about the written content to these screen readers, that are conveyed visually for sighted users. For example is the written text a link, a button or part of a list?
When I delved into the topic of accessibility, I was surprised how unaccessible the web still is. It’s weird, considering that I (an abled user) spend up to 12 hours a day on the internet communicating, shopping, socializing, getting information, planning and working. 5 billion people around the world have a disability and most of us who are abled, will develop some form of disability in their lifetime due to illness, accidents and age.
I know diving into the topic can be overwhelming at first – I am still trying to figure out most basics myself – but if you start early and sensitize yourself for this topic you’ll save time in the long run. I emphasize this aspect because when you talk about accessibility, there is always the question of: who pays for it? But if applying accessible ways to provide content becomes a habit, it will take less and less time. Also accessibility should never be thought of as an add-on, I think it’s more a question of: is your page generally usable or not? I would suggest adding an accessibility step after every main step of the project: HTML, accessibility, CSS, accessibility, JavaScript, accessibility...

If you want to know more about this topic, I'd suggest watching this video about accessibility by Sara Soueidan, for more details on how to apply concrete measures in every front-end step, read the »accessibility in mind« series by Manuel Matuzović. I promise, you’ll know all of the important community members and their a11y content in no-time.

Structure your CSS

After I lay down the HTML foundation and add accessibility, I give away classnames. I use the BEM method to give my code structure, make it reusable and understandable for other devs. Only after this step, I start styling and finally adding the divs I need to translate the design.
I’m still unsure about CSS in many situations. That may be because programming languages feel much more structured. The answers on CSS issues I run into are often semi-satisfying or even confusing. But CSS has become much more structured in recent years with grid, flex, CSS variables and functions like clamp(), min() and max() etc. So I’d recommend learning how to use them consciously (there are even fun ways to learn grid and flex-box and CSS selectors. Here is a good talk about CSS functions).
Furthermore, applying the concepts of DRY and KISS helps your code to stay clean, readable, understandable and maintainable. For example, reduce to a maximum of 4 font-sizes to use throughout a project, even when the design might use more. Regarding larger widths, heights and spacing ask yourself: Why did you choose this sizing? Round up, round down. Did you match it by eye? If you did, try to refactor to get a clear understanding why you chose a certain sizing, or ask your designer for changes, e. g. the proportions of a SVG.

Fin.

That’s about it for now. I hope this was useful to some of you. I have yet to learn to apply them better myself and as I said, I’d love to hear from fellow developers what they find most valuable. The bottom line for me is: Structure and intention are so important to create a good product.
Lastly I have to say it was a year of ups and downs, but there were mostly ups thanks to my amazing instructor, my supportive colleagues and my lovely classmates. There is so much more to learn and I’m so excited for what is to come.