How coding is like crocheting

At first glance, coding and crocheting appear to have little in common outside of both being words that start with the letter “C.” One is a process that allows us to build cutting-edge computer software, websites, games, and apps. The other is an allegedly old-fashioned craft, more often associated with grandmas in rocking chairs than anything high-tech.

But what if I told you that the two are more similar than you might think? Barbara Oakley, in her famed Learning How to Learn Coursera program, teaches us that the “chunks” of information we know from one concept can sometimes have surprising links to another idea we’re learning. In my case, I realized after finishing the first week of a software engineering course that crocheting and coding aren’t all that different when it comes to things like the language, the community, and the journey to a finished product.

Don’t believe me? Read on to see what I mean.

Coding and crocheting have mystifying lingo

When you look at code in a language you’re unfamiliar with, a lot of it seems like gibberish. You may not know right away what </div> or rgb() or JSON means, but once you become more acquainted with the syntax and terminology, the letters and symbols laid out in front of you start to make sense. With some study and practice, you can recognize which part of the document results in what output on a page.

Crocheting, like coding, has its own lexicon as well. Read any pattern on how to make a hat and you’ll see it’ll go something like “Ch 87. Ss in 1st ch to join. Ch 2. *[FPdc in next st, dc in next 2 sts]” – not so easy to decipher when you don’t know crochet lingo, but the function of each term becomes much clearer after learning some of the language.

Their communities are generous and supportive

Spend a bit of time on (the good side of) #techtwitter and you’ll see that there are tons of people in tech offering support to those who are new to coding or are trying to break into the field as engineers and developers. Many of these seasoned professionals volunteer their precious time to troubleshoot code, mentor juniors, and review portfolios. There are also endless free resources online for learning programming languages or building projects, shared openly by enthusiasts entirely out of generosity. I myself have enrolled in a full-stack web development training program for a total of $0.00 thanks to one very altruistic instructor, Leon Noel. This is all to say that plenty of folks who have a passion for coding also have a passion for giving, and often all they ask for in return is for you to pay it forward.

The same generosity can be seen in crocheting circles and the abundance of knowledge that crafters make available for anyone to access. Google “crochet basics” and you’ll find thousands of tutorials from experienced crocheters explaining everything there is to know about the art. There are also crafters who spend hours upon hours building, testing, and writing patterns that they then release for free, much like developers do with some of their code. In a way, crocheters have their own open-source databases of projects that they can enhance and customize to their needs.

You use similar methods for fixing mistakes

One of a crocheter’s worst nightmares is pausing to look at your work in progress only to realize that it’s a little wonky. Fixing a project that’s gone awry involves closely examining your stitches and pinpointing the row(s) in which you may have skipped a stitch, forgotten to change colors, or used the incorrect number of turning chains. Once you figure out where things went wrong, then you can get back on track to finishing your scarf, sweater, or what have you.

You don’t always get it right the first time when coding, either (in fact, I’d be really impressed – maybe even slightly suspicious – if you did). Just like with crochet, debugging your code calls for carefully inspecting what you’ve worked on and repairing existing errors. Gradually, you learn how to become patient and attentive to detail whether you’re working in VS Code or wielding a crochet hook.

You can create beautiful and functional things with just your hands and minimal tools

Give a crafter some yarn, a crochet hook, and time, and you’ll be amazed at what they can make: blankets, reusable market bags, board shorts, and even amigurumi. In the same vein, programmers can build a limitless array of products with only a computer, a text editor, and probably (highly likely) some caffeine. These two disciplines use minimal tools to construct something beautiful, useful, or often both. At the end of the day, coding and crocheting are different but analogous ways to be creative using your hands–just remember to be careful, because you can get carpal tunnel syndrome doing either activity!

You learn something new every day

Whether you’re a beginner at crochet or a crafter with 10 years of fiber art under your belt, there’s always a new technique to practice or a fresh project to undertake. Being a good crafter means you never stop working to improve your skill or expand your knowledge. The same can be said for coding: to become a great coder is to sign up to be a lifelong student. Engineers, developers, and programmers are constantly picking up new languages, frameworks, and technologies to keep themselves current in their fields. While this may seem daunting, it’s a big part of what keeps the work unique and exciting.

Have I convinced you that code and crochet are not as different as you may have thought? Did this make you think about unexpected links between your interests? I’d love to hear them!

Source link

Why Developers Should Care About Knowledge Sharing

Sharing knowledge usually comes as the last step of a process, or even worse, as something optional, that can be passed on if need be. This makes it easy to skip on this step if you feel you’re tired, or your team is busy. Developers are almost always creating new technologies and figuring out new solutions. Odds are, whatever knowledge you acquire won’t be available anywhere else. The time has come to remind everyone of the fundamental benefits of making whatever knowledge you’ve acquired available to your colleagues.

Why it helps you

Knowledge sharing is the second biggest problem software companies face. It affects everyone, so it also affects anyone. With the advent of remote work, this issue may become even more important. First of all, let’s appeal to our own self-interest. Sharing knowledge doesn’t only help our team, it actually helps those who are imparting the knowledge in more ways than one.

Let’s see:

  • You are advancing your own knowledge. By explaining what you’ve learnt to someone else, you are consolidating what you’ve learnt. You will retain it better, systematise it better, and, frankly, you’ll probably advance it by seeing it through others’ eyes. You will have to consider what you’re sharing and think twice about it. That reflection will bring with it valuable learning.
  • You will be receiving feedback. No developer is an island. We learn from others. By sharing what you’ve learnt, you will be receiving other people’s thoughts on the subject, which will surely advance your own understanding. Maybe they will even correct some aspect of it that you misunderstood.
  • You will help future you. If you learn something and just file it away in the caverns of a closed pull request, odds are you may not remember it fully whenever you bump into the same problem again. If you write it down, though, and teach it to others, it will be right there for you when you need it. It’s the easiest way to only solve problems once.
  • You will be advancing your career. Sharing knowledge and contributing to the team’s success does not go unnoticed. If when people are in trouble and seek solutions your name pops up all the time, everyone will take notice. This is how promotions happen.

Why it helps your team

But sharing isn’t just about oneself, now is it? There must be advantages for the whole team. Let’s see what they are.

  • It helps build team spirit. This may sound like a meaningless phrase, but it isn’t. What goes around comes around, and a team that is accustomed to helping each other will resort to helping each other naturally. Giving everyone a hand shouldn’t be contingent on someone being in trouble.
  • You will be saving everyone A LOT of time. How long did it take you to solve the problem? An hour? Two? A whole day? Whenever someone on your team runs into the exact same issue, they will (depending on skill level or just sheer instinct) take roughly the same amount of time. If there’s an explanation available, though, that everyone has knowledge of… Not so much.
  • You will be building a knowledge base. It may seem like just a small addition, but small additions build up. If your team develops a culture of sharing knowledge, they will inevitably create a repository that will become a cornerstone of success.

How to do it

So, are there any best practices, aside from simply gathering the team and telling them, or writing stuff down somewhere public, such as an internal Wiki?

We do have some ideas:

  • If you’re using Reviewpad, which you should, the Comments from the Past feature makes it so whenever someone touches code with comments, they’ll be able to see what was shared when that code was made. Forget about re-working the same problems, or going down avenues that somebody else already found out that don’t work.
  • Whenever a team member explains something to you, encourage them to document it. If it was useful to you, it will likely be useful to others.
  • Much in the same way, whenever someone asks you for help, document it.
  • Whenever you are the one who needs an explanation, avoid asking in private. Ask on a public forum, so everyone can read the discussion and take advantage of it.
  • Make it easily accessible. Your knowledge base needs to be freely and easily accessible to everyone, at all times. Developers don’t particularly like over complicated wikis, so it’s up to you to create this space.

One of the reasons why we are building Reviewpad is making knowledge sharing easier and more convenient to everyone involved.

Reviewpad is about communication as much as it is about reviews.

Are you ready to give it a go?

Source link

Ten Principles of Critique – DEV Community

Feedback. On the one hand, we live by it as programmers, designers, and software engineers. How can we improve if no one tells us? On the other hand, some feedback can leave us feeling devastated, often without a definite reason why it has affected us.

Critique is an especially tricky corner of communication, and it requires special care and attention to be effective.

As an author, I’ve been participating in professional critique groups for over 20 years. As an internship supervisor, I spend a significant amount of time reviewing code, proposals, and other work, particularly that of junior developers. In turn, I have been on the receiving end of many critiques and code reviews throughout that time, both good and bad. These are ten principles of critique I have found effective in maximizing the benefits of constructive criticism without discouraging the person behind the work.

So why bother with all this? Can’t people just learn to accept critique in any form? Not really. Even the thickest skinned person still has feelings. One may eventually build up an emotional callous — although that can lead to them being brusque and insensitive in turn — but in the meantime, time and energy is always spent processing the emotional quality of communication.

There are two benefits to the constructive criticism techniques herein:

  1. It saves developer hours otherwise wasted on debating and reiterating already established or otherwise irrelevant points.

  2. Because the emotional weight of the critique is decreased, the author can skip right to considering and responding to feedback, instead of trying to process and rationalize around their emotional response.

So, to that aim, here are ten principles of an effective critique.

When someone takes the time to share their work, whether it be prose, code, a proposal, an idea, or whatever it may be, they are being vulnerable. Assume their work is their best effort to identify and solve a problem. Be careful of dismissing or devaluing their work in your mind because of real or perceived lack of experience. Great code can come even from junior developers, and great prose even from novice authors.

When you’re going to respond to, act on, or critique something, your first step is to read it thoroughly. It is very tempting to skim — we’re all busy, after all! — but this ultimately wastes time when the author has to repeat what they already wrote. Furthermore, skimming is disrespectful to the author: they put real effort into the work, so you should expect to put in the time to read and understand. If you can’t spare the time, don’t comment.

Once you’ve read through the work, you’ll probably have already formed an opinion. That’s fine, but now you should read the work again. Check your own assumptions. See how many of your questions and concerns you can answer yourself.

Before critiquing, make an effort to see the problem and solution from the author’s perspective. Ask clarifying questions. Be careful that these initial inquiries are not a form of criticism! Your first few questions should be dedicated to understanding the author’s way of thinking. Bonus: these initial clarifying questions will often help the author self-identify flaws in their own work, which is always an ideal outcome.

It’s easy to launch into everything you disagree with about someone else’s work. Resist this urge! When you’re ready to give feedback, start by identifying something positive about the work you’re commenting on. This is important because, as objective as we humans like to pretend we are, we are all still emotional creatures underneath. Starting with a genuine, positive comment will frame your upcoming constructive criticism as improving work, rather than invalidating it.

Challenging assumptions and decisions is a normal part of constructive criticism, but these are often most effective in the form of questions the author can answer. For example, “Is there a reason you chose to use a singleton here instead of a class attribute?” is less threatening than “Singletons are terrible, use class attributes instead.”

Clearly identify to yourself what it would take for you to change your mind about the work you’re critiquing. This is especially important regarding proposals and ideas. Even if you feel certain, it’s always possible for you to be wrong! When a debate becomes protracted, that’s a particularly good time to enumerate to the author what it would take for you to change your position; you don’t have to wait for them to ask.

This one feels obvious to everyone, but it is so easy to lose sight of during a critique. Keep a check on yourself to direct all criticism towards the work, and not towards the person. This can be more subtle than it first appears. Before you submit a critical comment, re-read it to consider how you’d feel if you received that comment, especially if you were in the author’s position.

If your critique goes beyond a handful of minor “nitpicks”, be sure you find something else positive about the work to end your critique with. This is known as a “feedback sandwich”: when the first and last comment are both positive, it bolsters the constructive nature of your criticism, and helps prevent discouragement. (If your feedback is somewhat non-linear, e.g. a code review, you can just tuck an additional positive comment amidst the others.)

Once your comments have been addressed, and the work has earned your approval (in some measure), keep an eye on the feedback others are providing on the work. Be an advocate! Having to field criticism from multiple people alone is very discouraging. Be explicit about your approval of the work. Support the author’s work publicly to the scope you’ve approved it as they address additional feedback. Lend your own expanding understanding to the conversation. This is both encouraging to the author, and helpful to the other reviewers as they try and understand the work.

All that may feel like a lot, but with a little practice, constructive critique can become a nearly automatic habit.

Over time, these patterns build trust between individuals. It increases psychological safety, thereby inviting more participation. Feedback takes less time to process, and improvements can be made more rapidly. That’s something everyone benefits from.

After all, who doesn’t want their critiques taken seriously?

Source link

How to ask the Right Questions as a Junior Developer

Asking questions is literally the first piece of advice anyone gives to a brand new developer, and there is a good reason for this. I cannot emphasize the importance of utilizing your teammates as resources to help you learn. The whole point of working in a team is so that teammates can help each other out. If you aren’t constantly asking questions within the first couple of months on the job, you are not taking full advantage of the resources around you.

There is a caveat to this point that isn’t talked about enough: not only should you be asking plenty of questions, but they should also be the right questions. Before I go any further, I want to emphasize that I am not trying to scare anyone out of asking questions. I don’t mean you should be worrying about whether your question is a “stupid question” or not – it is perfectly acceptable to ask a “stupid question”. It is also perfectly acceptable to ask for help. Instead, I believe there are certain ways to phrase typical questions that can help better set you up for success. Let’s explore a few examples.

Don’t Ask: “Can you explain <insert business process here> to me?”

Do Ask: “Do you have any resources about <insert business process here> that can help me learn more about it?”

Chances are, there is some resource that already exists to explain the business process to you – and this resource likely will be a lot more thorough than the answer your teammate will have to come up with on the spot. If this resource still doesn’t help you understand everything you need to know, then you can ask follow-up questions for further clarification. You now also have a bookmarkable page that you can refer back to whenever you need a refresher. Win/win!

Don’t Ask: “What’s wrong with my code? Can you fix it?”

Do Ask: “I am having issues with my code, I have tried x, x, and x. Do you have some time to rubber duck this?”

It is normal to ask another team member for help on your code, this is another one of the whole points of working in a team. However, blindly asking for help is disadvantageous for both you and your teammate:

  • If you get into the habit of immediately asking for someone to fix your code as soon as it breaks, you’ll never gain the skills to debug complex problems on your own
  • From the teammate’s perspective, getting asked to “fix someone’s code” is a very frustrating experience. You then have to spend time understanding all the context of the code before you can even begin to debug.

The Do Ask question in this scenario does a few things:

  • By forcing yourself to wait until you’ve tried a few different approaches to your problem, you force yourself to think more critically. You might even stumble upon a solution and not even have to ask for help. This is the best way to learn!
  • If you don’t stumble across that solution, then at least you can tell your teammate what you have attempted before asking them for help. This reduces the amount of time your teammate has to spend debugging the problem, hopefully allowing them to figure out the issue even sooner.

Don’t Ask: “How do I do this task?”

Do Ask: “I am a bit confused about this task. Do you have any suggestions on how to get started?”

As an inexperienced engineer on a new team, one of the scariest things is getting assigned that first Jira Story and having no idea how to do it. Again, this is the point where I reiterate that I am not trying to discourage junior engineers from asking for help, I just think there is a better way to go about it than straight-up asking for help.

Say you ask “How do I do this task?”. Your teammate will then hop on a call with you and guide you step by step through the process. Or worse, they’ll do it for you while you watch. There is some value to this, but there is even more value if you are given the opportunity to attempt the task on your own before you reach this point. By asking the “Do you have any suggestions on how to get started?” line, you give yourself that opportunity. Your teammate can now start you on the right path, without accidentally doing all the work for you. If you still struggle, then it might be time for that step-by-step walkthrough. But make sure that you are the one doing the work, rather than them showing you by doing it themselves.

Asking questions is one of the scariest things you need to do as a new developer. None of these examples are meant to imply that you should be scared to ask questions – in fact, quite the opposite. They are meant to show you how you can make your questions even better and more useful for you. By thinking a little bit about how you communicate, you can gain way more out of a simple Slack DM. And you might even impress your teammates along the way.

If you liked this article and want to be notified when I publish another, consider subscribing to my mailing list.

Source link