DEV Community: Lauren Zugai

What Does "Learn to Code" Actually Mean?

Lauren Zugai — Tue, 06 Jul 2021 15:17:01 +0000

Over the years, the phrase "learn to code" has gained a lot of popularity, most notoriously as a sort of cheeky suggestion to throw at folks that aren't happy with their job. However, I can't count the number of times I've been approached personally for sincere advice on "learning computer coding" or the number of times I see something related asked about in a group on social media where I feel compelled to give advice. This post intends to shed some light on if this path is right for you, how to actually get started and how deep you may need to go, and to share some of my opinions around job prospects throughout the post.

Let's get some confusing terminology out of the way

A mini glossary for those new to software and web application terminologies:

front-end (FE): encompasses user interfaces and actions associated with user interactions with your software; in web applications, it's code that is ran by the web browser/client; the "presentation layer"
back-end (BE): encompasses what the user doesn't see like handling data storage and processing logic; in web applications, it's code that is ran by the server; the "data access layer"
full-stack (not typically an acronym): both the FE and BE, though it's common for a full-stack engineer to be stronger in one or the other

The following are my own hot takes/my opinions as some may disagree with my definitions, but they reflect what I've come to understand and describe how I will be using certain terms throughout this blog post:

web developer: someone that works on developing basic websites. HTML and CSS are required as well as typically basic JavaScript.
software: a very broad term to encapsulate applications, scripts, services, and programs that run and interact together on a device. Oftentimes it is the end product of the front-end and back-end pieces working and packaged together. "Software" can mean desktop software, mobile software, software for the web, and others.
web application: software that runs on a web server
software engineer: someone that develops software. Requires programming, working with data, making architectural decisions, and a much deeper understanding of a number of concepts depending on the nature of the software and the role while working on it. A software engineer for the web may refer to themselves as a programmer, web developer, software engineer, or some combination of these descriptors.

To give a brief history of my journey to help spotlight any biases I may have, I'm a full-stack software engineer currently working on web applications and I've always gravitated towards the front-end. I taught myself HTML and CSS around the age of 13, I went to college for IT and computer science, and then I attended a coding bootcamp after college because I struggled to get my foot in the door and knew there was more to learn. I've freelanced, I've worked my way up from an internship to staff level, and I've conducted and been part of dozens of interviews.

While I believe many different folks can gain some value out of this post, as you read, keep in mind that it's geared towards web development and web engineering, especially for those getting started in the front-end, and know that my personal experiences have influenced my perspective and opinions.

Is coding right for you?

First and foremost, coding is not for everyone. Stolen from TechCrunch's "Please don't learn to code", the article states (emphasis mine):

Don’t get me wrong; I do believe that engineering and programming are important skills. But only in the right context, and only for the type of person willing to put in the necessary blood, sweat and tears to succeed. The same could be said of many other skills. I would no more urge everyone to learn to program than I would urge everyone to learn to plumb.

... however, while an apt warning, it shouldn't serve to intimidate you. In fact, if you have any interest in learning, I believe it's worth putting in the time to explore because of the vast free resources available and otherwise, you'll never know; you could get lucky and fall in love with it or at the very least, find it interesting enough to pursue long-term in a career switch.

It's worth noting, though, that some people oversimplify and underestimate what it actually takes to make it in this industry - they mostly see dollar signs and think since you can "teach yourself," they just have to grin and bear through a couple hundred hours of learning before they're set when the reality of the journey is much longer and arduous. There is a lot of competition for these jobs and in my opinion, if money is your sole motivator, you're not going to make it very far in the industry.

Coding may be right for you if:

coding genuinely seems interesting to you
you can and are willing to make the time needed to learn
you enjoy learning and challenging yourself at work
you don't mind a 9-5 desk job and can stare at a screen all day
you communicate or can learn how to communicate well through written word
bonus: there's a particular software idea or site that you want to work on (makes it easier to learn!)

To conquer initial hurdles, the first two points probably carry the most weight. While you don't have to "love" coding (especially at first!) and consequently later, your job, to succeed in this industry, it can make an enormous difference in many ways. If you enjoy it at least somewhat, it'll make the journey feel less uphill, it can make solving bugs you run into exhilarating and carry you into the next thing, you may feel inspired to work late on a personal project because you're actually enjoying it, and excitement for software translates very well in job interviews. With that said, though, if you're just beginning this quest, do try to ask yourself periodically if this career path is right for you, but also keep in mind that initially, learning these things is probably not going to feel very "fun".

In fact, expect to feel overwhelmed because the amount of stuff out there is, well, overwhelming. Understand and try to not be discouraged by the fact that learning in the computer science and coding realm is an extremely layered experience. Concepts overlap and build on top of one another and you have to put in the time needed to gain the experience and familiarity with each layer. It does get easier, but it takes time. (By the way, the layers never stop growing. That's where the "you enjoy learning" point comes into play.)

It's nearly impossible to guestimate the number of hours you'll need to put in because it depends on how quickly you can learn, how you learn, what approach you take while learning, how relevant what you've learned pertains to the roles you're applying for, and even a little bit of luck around what jobs are available, who you know, and how competitive the market is. Since I attended a coding bootcamp after college and personally know some folks that were hired out of them without prior experience, it may be a good minimum baseline - my bootcamp was 13 weeks long at around 60-70 hours/week. If we take the lower end and estimate 80% of that time to account for breaks and other factors, we're still sitting at more than 620 hours for learning how to work on web applications with teachers working directly with us... and bootcamps serve as a good foundation and take you through a lot in a short period of time, but you barely scratch the surface. My bootcamp also had a dedicated resource to help with career outcomes and many did not go on to a dev job after completing it due to competition in the market. I mention this not to discourage, but to be transparent about the journey in front of you. However, if you prioritize success and truly want to succeed, you will.

Enough of your ranting, what and how should I learn?

You've probably seen this list before, but there's several ways to learn "how to code":

Teaching yourself
Attending a code bootcamp
Obtaining a related degree

While I won't get into the nitty gritty of the options as it could be worth a post of its own, my opinion is that you should try to teach yourself before attending a bootcamp or opting for a degree to make sure it's something you're truly interested in before shelling out the time and financial commitment. If you're in high school or college now and can earn a degree without going into much debt, I would still recommend a degree as I do believe a computer science or related degree is still valuable to obtain (plus, it can make you stand out), but I also think if you want to learn web applications, you'll have to work on side projects because from what I've seen, CS degrees don't tend to apply software engineering to the web very well. If you learn significantly better in a classroom setting but are struggling on your own, can afford it, and don't mind not receiving a degree for it, a bootcamp could be a solid choice for you. Though, based on my experience, you need to have some prior experience to excel in programs that fast-paced. The rest of this post will focus on teaching yourself.

No matter what method is right for you, at the core of it, you should be emphasizing project-based learning. There is nothing more dull and uninspiring than working through 100 isolated JavaScript problems where it's not only easy to hit a wall and feel frustrated or bored, but it's also easy to procrastinate and to allow doubt and sense of being overwhelmed creep in. While it's necessary to work through some problems or puzzles when you're learning the basics, project-based learning lets you gain experience with concepts and connect some of those dots together, allows you to work with certain libraries or frameworks directly, debug on a "real" project, and gives you projects for your resume.

One reason "teaching yourself" is so difficult is because you don't know what or how to learn. This is the happy path that I would suggest to get you to that first project:

Pick a path by selecting the language(s), libraries etc. that will lead you to the job you want (more on this next)
Learn the basics through free YouTube videos and other free sources like blog posts or MDN, try Codecademy, and/or a "basics" course on Udemy for around $10
- Note that you should not just watch videos or read docs. Get your environment set up and run exactly the same code that they are and/or work on isolated problems in something like replit. It may take you two hours to work through 20 minutes, but that just means you're doing it right. I like VSCode, by the way.
Take those basics and do something fun with them that will help you dive deeper into understanding the language, like using free resources to find a tutorial for building something that seems interesting, such as building out an entire web page with HTML and CSS and/or Wes Bos' 30 days of JS
Build something more complex, like using React for a to-do application and then hooking up a server to persist the data in a database like mongoDB, which will probably entail a lot more use of free resources or even another Udemy course to help you come up with an idea and fill in the gaps
Come up with your own project. Build and deploy it!

...But I still don't know what to pick🤔

Another disclaimer \o/ - tech stack choices tend to depend on the type of software being built, there's not a blanket stack that just works universally. With that being said, my suggestions are based on what I think will be the most straightforward for folks to start with, what I've enjoyed working with, and what I've seen in the industry. This is also pretty basic and non-expansive and I expect others may disagree with some of it.

If you're not really interested in programming but you think learning basic webdev seems interesting, know first and foremost that competition for the kind of jobs you want to go after is likely going to be tremendous and that you'll reach the pay ceiling fairly quickly. However, it can open the door for you if you're interested in front-end engineering, designing, or some sort of entry-level tech job, like a basic website admin or hybrid junior job where your responsibility is low but you wear a few different hats like content writing as well (though, there's much more direct things to study if you want to pursue designing or content writing). If this interests you, you can start with HTML and CSS and ease your way into SCSS and JavaScript.

If you're interested in front-end engineering, you'll want to know HTML and CSS basics. When you start working with front-end libraries or frameworks though, know that you basically don't write HTML or CSS anymore, you write things that get compiled into HTML and CSS (SCSS is great to have in your arsenal). I'd start with basic vanilla JS to understand how it works, and then move on to a front-end library like React to put it together. You'll also want to learn git/GitHub and basic terminal commands.

If you're interested in the back-end, you've got a lot more language options. If you think you may be interested in the full-stack or just working with JS on the server-side, I'd recommend learning JavaScript so you can learn one language and work with NodeJS and a web framework like ExpressJS. If you think working with data/data scientists or AI, or machine learning is interesting, you may want to consider learning Python. There are other completely valid languages to learn like PHP for Wordpress, which is common for freelance work, Ruby, Java, Go, C++, C#, or Rust depending on the kind of project you want to build and what platform you're building for (the web, mobile apps, a gaming console, etc.). Regardless, you'll also want to learn git/GitHub and terminal commands.

Some other things that would benefit you to read/learn about:

JSON, REST APIs, and CRUD apps; TypeScript (if interested in JS)
For the FE: best accessibility practices, best or common state management practices
For the BE: types of databases and choosing one to work with, authentication

To help you plan out your self-taught curriculum or if you're still not sure what you're interested in, try searching for jobs on Indeed or LinkedIn with various terms like "web developer," "back end engineer," "javascript engineer", or "UI developer," even other related jobs like "dev ops," "data analyst," "game developer," or "cyber security" to get an idea of what's out there in tech, and find job listings you'd love to be qualified for later. Make note of the tech and skills they're asking for as those patterns will help you make your own roadmap (or select a bootcamp).

Speaking of roadmaps, definitely check out this fantastic web developer roadmap. Though, be sure to check out their "Note to Beginners."

Although I've mentioned it several times in this post already, as one recommendation I will emphasize again, especially if you're still not sure what to pick, is to learn JavaScript. JS is incredibly versatile as it is used in the FE, can be used in the BE, and even has some cross-over with mobile apps with libraries like React Native and desktop apps with Electron. It can be a great first language to choose since you can do so many different things with it without having to juggle two languages at once.

Conclusion & Resources

While coding is not for everyone, if you love to learn and find the concept of it genuinely interesting, it may be something great and fruitful for you to pursue. Expect to dedicate a lot of time - probably significantly more than you think or plan to - to hone your craft. It can be intimidating and overwhelming, but try to remember that old saying about Rome not being built in a day. It can all begin for you by taking that first step and can be so, so worth it. ❤️

MDN - for learning and language references
replit - an in-browser IDE that you can use to isolate problems and learn language basics
Udemy or Codecademy - offers free or low cost deep-dive courses
codepen.io - practice your HTML, CSS, and JS in a sandbox, or browse codepens for inspiration
StackOverflow - a community you can go to find answers for specific questions or ask your own
FunFunFunction - a YouTube channel that does a fantastic job at explaining complex JS topics. Though they're one of my favorites, the channel is not currently active. Check out YouTube and other YT channels for other free tutorials
hackMD - I didn't go over Markdown (MD) files in this post, but MD is a lightweight markup language and the defacto standard for developer READMEs; HackMD is a nice tool worth sharing for document collaboration and to see how MD works

How to Break Down Software Engineering Projects, From an Engineer

Lauren Zugai — Thu, 24 Dec 2020 00:44:19 +0000

Intro

In one of my first days of my very first CS class, my classmates and I were asked to "write step-by-step directions on how to change a tire." After we were given some time to work on it individually, the professor (shoutout to Mr. B!) went on to explain that the steps we listed could be considered our "algorithm" for changing a tire which at the time, was a slightly intimidating word. We were told the exercise was designed to demystify the word and was meant as an intro into approaching problems we would run into while programming.

Together as a class, we began to break down the process together. We started listing what we deemed as larger tasks first on a whiteboard with plenty of space between list items, and as we progressed, more details were scrawled in-between these tasks and those tasks themselves became sets of bite-sized smaller tasks. I didn’t know it at the time, but lessons learned from this activity would later be scaled and modified into a process I’d use to break down entire projects many years later.

Note: while this post is applicable to projects of many sizes and requirements, it’s geared towards medium-to-large projects that necessitate some engineering effort in the UI.

Engineering must be set up for success long before breakdown begins

Prior to a project making it through the necessary rounds of scrutiny by project stakeholders, the engineer(s) that will be responsible for breaking down tasks should already be involved in the conversation. There’s certainly some wiggle room depending on the size of the project, but especially if the end-goal consists of multiple features and/or potentially complex changes spanning weeks to months of work, it’s important for at least one experienced engineer to be involved early on, even if sparingly, to help smooth out potential pain points or identify large problems with expectations, answer questions, and to ask clarifying questions early on that may identify additional work on the Product or UX/Design side that should be done before task breakdown should begin. In some cases, engineers may need to work through a spike at this stage to determine if and how a particular request will be do-able before committing to the idea.

Frequent communication between UX/Design and Engineering is increasingly important as user interface changes or additions are crafted out. Engineering should scrutinize the design not only from a level-of-effort and security standpoint, but from an accessibility-first mindset. Identifying accessibility issues and recommending accessible design preferences early on is imperative to preventing major a11y issues that could potentially call for design changes and/or refactoring later. In fact, accessibility can impact designs so significantly that in some cases, an outside accessibility expert should be consulted before designs are finalized. If you want your product to be accessible, a11y should never be an afterthought in the design phase and engineers must help uphold these standards.

As designs inch closer to completion (as well as during development), Engineering will likely need to work even closer with Design to account for various application states, some that Design may not be aware of should exist. The more Design can provide upfront, including not just all user experience flows, but more complex flows in mobile, tablet, desktop, and XL desktop viewports to establish design patterns across device sizes, error message expectations, form validation expectations, what every interaction with the UI will look like, and beyond, the more polished the end product will be before maintenance iterations, and the easier it will be to get a full picture of expectations before work breakdown begins.

Ready for Engineering... Psych, you've got more prework

At this point and depending on team size and the level of effort the project will require, it could be a good idea to share designs with the entire Engineering team to get the team on the same page, encourage additional feedback, and open the floor to fresh eyes to catch anything that’s been missed by those close to the project. Additionally, ensuring that front-end and back-end engineers are on the same page can save headaches later.

While final details are being worked out with Product and/or Design, or prior to depending on when certain requirements become solidified, it’s time to begin ironing out a plan of attack by maximizing the visibility of architectural and other major decisions to the rest of the team.

Architecture Decision Records (ADRs) aren’t for every team or every project. However, in my experience, they’re a fantastic way to weigh pros and cons of various decisions, outline why a specific direction was chosen, and receive and address peer feedback on impactful decisions from engineers that are not necessarily as close to the project at this stage. ADRs can be referenced months and years later when someone inevitably asks why something was done and what alternatives were considered.

Let the breakdown commence

Some software projects will reach this stage much more quickly than others because less prework and planning iterations are needed for smaller projects, while others are forced into planning with a greater level of uncertainty due to time restraints. Regardless, it’s time to begin breaking down the work into tasks that any engineer on the team can understand and work on.

Thinking back to the aforementioned tire changing exercise, you’ll start by listing large, sweeping tasks. This could be as crude as beginning with “back-end work” and “front-end work” but as details are added, smaller clusters of work within sweeping categories will become more apparent and clear. As it can be counter-intuitive to start filing issues before the plan is more solidified, I’ve found success in hacking away at breakdowns in a new document or note in small-to-medium projects, but have also graduated to a spreadsheet divided into sections for large projects.

Begin with a single-sentence summary of tasks which will later become the title of new issues. If it feels natural to add descriptions to tasks along the way that can definitely be beneficial in further aiding the full picture of work needed, but be aware that titles and descriptions will continue to evolve as the work continues to be broken down.

As progress is made in listing out tasks, it becomes increasingly important to ask yourself several questions.

1. Can this task be broken down into smaller pieces?

Most software engineering teams use some sort of scale to determine what the level of effort is for tasks. Your team should consider what would typically be considered “too large” to be a single task (on my team, it’s beyond a 5 pointer on the Fibonacci scale) and if during breakdown you would estimate a task as higher than that threshold, consider how it can be broken up further.

There can be rare exceptions to this rule because sometimes it just makes sense to do a larger task in one go, but generally speaking, look for ways to break up distinct pieces of functionality or simply separate building and styling UI components from making them functional/interactive. Tasks should ideally be straightforward and concise.

On the flip side, some very small teams that work together on small isolated projects or tasks can sometimes get away with hacking away at large tasks without taking time to break them down extensively, only to file follow-up issues on what is still remaining after a large chunk of work has been completed and reviewed. While atypical, this sort of impromptu workflow worked well on a team I’ve previously been on where each of us would work on separate, non-complex web pages.

2. Should I make the call on how a task should be done?

One of the most difficult aspects of breaking down large projects can be making this call. When you know there’s a series of tasks that need to be broken down to complete a piece of functionality, but how they’re broken down is dependent upon the approach laid out in the first one or two tickets and the solution isn’t obvious, you have a couple of options.

If there’s a lot of uncertainty with the project or it has potentially changing requirements, the best approach may be to file a placeholder ticket with some initial thoughts and a high estimation to encompass all of the work needed to make the decision and all follow up tasks. Then, as other work is completed and certainly before that ticket is next in line to begin engineering work on, the path and solution will likely be much clearer than it was before any engineering had started.

Another solution could be to make the call, file a ticket to implement what you’re thinking with details (if it seems warranted, a mini ADR write-up could help other engineers understand why you went with this approach), and send that ticket (or a description of the problem and your solution) around to get more sets of eyes on it. If other engineers don’t see any glaring problems and agree with your approach, it should be fairly safe to break down the remaining issues under the assumption this is the solution that will be used. If something changes, tickets can be adjusted later.

If other tasks are not necessarily dependent on the decision outcome of an issue but an outcome must be decided, such as “decide on a state management library” or “decide on our error-handling pattern,” an issue can be filed and can be considered a spike with clear instructions on how to close the ticket (with a comment, implementation, documentation, etc.).

3. Should I ask other engineers their opinion or set up a meeting to help flush out a set of tasks?

The engineer breaking down tasks should be able to rely on the expertise of their colleagues when needed. If you’re not strong in accessibility, it would be ideal to have someone with that domain of expertise help you review designs. If you know that l10n is important in your project but don’t know what the steps are to implement it in your project, consider setting up a meeting with someone that does to explain what you need and to help you break down those issues.

Knowing when to reach out for help can be a struggle for everyone, but not doing so when breaking down large projects can lead to a lot of wasted time - if you don’t know how to change a tire, you can’t break down how to. Your team is a quick ping or meeting away.

Write detailed task titles and descriptions, with limitations

Writing detailed descriptions will not only set whomever works on the task up for success, but will help minimize follow up tasks and ensure that other tasks dependent on this work will be unblocked. Descriptions should provide any context needed to understand what the ticket is asking, link to other related issues and link relevant documentation, and be clear on what is needed to close the issue. If the description is pretty lengthy, a TLDR with what’s needed to close the issue above the more detailed description will be appreciated by the pull request reviewer as well as by management when thumbing through what needs doing.

Generally speaking the more descriptive a task is the better, however, depending on the project, you may also not want to be too specific. If requirements are subject to change or one task wasn’t done exactly as expected, you ideally shouldn’t need to update the description of 5 others.

If your team uses Jira, be sure to take advantage of “issue links” such as “relates to,” “blocks,” “split to” etc. This can help with identifying priorities, leave breadcrumbs which can almost serve as project progress documentation, and help engineers find solutions to related problems which may help them with the current one.

Infrastructure work & documentation

If the project being broken down requires infrastructure work before beginning on main tasks, there will almost certainly be a cluster of issues involved in setting the project up (and an ADR or three, did I mention those yet?). Depending on the size of the project and what infrastructure work needs to be done, I’ve found that it can be more efficient to keep entire engineering team involvement more minimal at this point - 2 to 4 engineers seems to be the sweet spot to avoid code conflicts, keep up with incoming code changes, and establish and document patterns early. If you throw 10 engineers on 20 initial setup tasks, parallel work may be difficult to find and there may be too many cooks in the kitchen.

Throughout infrastructure work and into the meat of the project, one important factor often overlooked is documentation, documentation, documentation. It’s imperative to avoid tribal knowledge, to assist in understanding code later, and to minimize the ramp-up time of other engineers joining the project later, but it’s oftentimes skipped in favor of hacking away at another task.

If the culture around closing tickets on your team or project isn’t also updating documentation alongside architecture development (and ensuring this happens at code review time), at least consider filing tickets for needed documentation work and prioritize working on them as soon as possible, before new features stack up. While documentation can quickly become out-of-date, this can be mitigated by prioritizing it and requiring a documentation check when the foundation of a project is laid out and into early changes.

Sectioning work, identifying priorities, & finding parallel work

Highest priority tasks may not be as obvious as they may seem at first glance. Oftentimes, tasks are blocked by other tasks because clusters of work have a general order they have to be done in, building on top of each other as the work is completed.

Identifying this pattern and batching issues together based on what tasks unblock others can be a fantastic way to create user stories (or epics, or however you’ve chosen to aggregate tasks under umbrellas) to establish what sections of work can be done by engineering in parallel, allowing for maximum efficiency and minimal conflicts.

Once the tasks are divvied up into sections, those sections of work can then be prioritized by what must be completed first (infrastructure, perhaps authentication), what makes sense to complete next before beginning more isolated work (UI stub out or placeholder pages, routing, shared components that will be used in many sections), and then by feature/section priority set by project stakeholders or whatever cluster of work appears like it will take the longest, and finally by what can be completed towards the end of the project (localization, accessibility bugs, end-to-end tests).

If teams prefer a kanban board approach, or to visualize what a flat priority list would look like, the first few tasks of each top priority section would be at the top of the list. The first 10 tasks may consist of tasks that must be completed first in the user stories for feature A, B, and C.

While this approach may not ship high priority feature A in one sprint, it can ship feature A, B, and C in two sprints while leading to a sense of ownership for engineers working on sets of tasks and avoiding stepping on each other's toes.

Note that sections of work don’t necessarily have to be composed of issues that build on each other. It may make sense to put, for example, development of a common header, footer, and navigation into one section.

Maintenance & refactoring required

Unexpected tickets will inevitably be filed as projects are worked through. These may be quick follow ups, low priority bugs, missed tickets during planning, or needed refactors as patterns continue to emerge that make sense to complete before moving onto another section.

It can be difficult to predict when newly filed tickets will be considered higher priority than what was originally planned to do next, which makes padding timelines important to keep expectations realistic and code quality high.

Conclusion

Breaking down a project or set of features may seem intimidating, but beginning with high-level sections of tasks and working through the plan in an iterative process can do wonders.

Diving in head-first and finding what works for you and your team will only make you grow as an engineer. Seeing projects through fruition is immensely satisfying and I hope the next time the opportunity arises, you'll be inspired to break down that tire-changing process (er, I mean, software engineering work).