DEV Community: Flinn Burgess

The Immense Value of Deep Knowledge

Flinn Burgess — Mon, 16 Mar 2020 13:51:10 +0000

Quick – give me a technology which you are better at than anyone you know. The kind of deep knowledge that would allow you to ace any off-the-cuff quiz thrown your way.

If you’re anything like me, you probably can’t say that you truly are deeply knowledgable in anything. Like most people, my focus lies in the tools and methods that get my job done. Often these jobs require a lot of repetition, where unknown solutions are just a search or two away.

According to the authors of Apprenticeship Patterns, this is a problem. By developing only a superficial knowledge of a technology, you are setting yourself up for pain later down the line and building a product on shaky foundations. Blindly relying on quick-fix solutions results in potentially sloppy implementations using concepts you don’t fully understand.

Today’s post will look at some common symptoms of shallow knowledge, the value of nurturing a deep knowledge of your tools, and ways in which you can achieve it.

(This post is part of a series inspired by the book Apprenticeship Patterns. Find the rest of the series here.)

The benefits of deep knowledge

You may be wondering at this point if it’s really worth it. After all, you go to work every day and get the job done. Someone is already paying you, so is the extra effort for deep knowledge really worth it?

Here are some reasons why the investment is worth more than you might think:

You will become more self-reliant

Have you ever searched Google for an answer to a problem only to come up short? This is especially common with languages and tools that are still in their infancy; answers are naturally harder to come across.

For those with a shallow understanding, it can quickly start to feel like they’re bashing their head against a wall. Some respond by endlessly Googling for a solution they’ll never find. Others, if they have the opportunity, will go and ask someone on their team with a deeper knowledge.

If you are the one with that knowledge, then you don’t have to rely on anyone else. You will have a solid foundation of knowledge to help guide your search for a solution. You will be familiar with the standard library and the code’s documentation, such that navigating them won’t slow you down.

On top of this, you will be able to rely more on your own code. I have written insufficient tests because I didn’t know about the intricacies of the tools I was using. The scary thing is that I wasn’t even aware. It took someone with more knowledge pointing it out to me, or unexpected behaviour in my code.

If you understand your tools deeply, you will build systems that you can confidently say are high-quality and resilient.

People will trust you more

Despite common belief, developers are responsible for more than just typing out endless lines of code. Yes, it is a large part of what we do, but we are also responsible for communicating with the business about what we are doing, why, and how it is benefiting the company.

If you don’t deeply understand the tools that you are using, why should anyone trust you? While it’s absolutely fine to not have the answer to every question, people are going to respond to you a lot better if you can talk about something with confidence.

Why is this important? Because you are there to influence the technical implementation of a solution, not simply follow instructions. Your job is to deliver a high-quality product, and that can involve negotiation between businesspeople and other developers alike. Without being able to talk in detail about something with confidence, you are unlikely to change anyone’s mind.

You will create more opportunity

A lot of developers will accept a shallow understanding as “good enough” for their day job and leave it at that. This means that you set yourself apart by building a deep knowledge of something. This is especially helpful when applying for a new job or looking to progress in your current one.

Good luck is when opportunity meets preparation, while bad luck is when lack of preparation meets reality. - Eliyahu Goldratt

You will create other opportunities for yourself as well. You could try your hand at teaching others, or contribute to the community or code of an open source tool.

Why do we settle for shallow knowledge?

Most people would agree with the notion that having only a shallow knowledge of your tools and languages is not ideal. But if that’s the case then why is it true for so many of us? Why do we neglect to build up a deep understanding of the things we use on a daily basis?

The world won’t wait for us

The context on which the authors base their pattern describes problems that most developers will be able to relate to: tight deadlines, complexity, and the need for a broad set of skills. In a way, all three feed into one another; modern developers are often involved in full-stack development or DevOps, expected to know about front-end, back-end, infrastructure and a whole plethora of other subjects.

Each of these is as endlessly complex as you are willing to uncover, and gaining a genuinely deep understanding of every one would take years. Throw in that your boss needs the project done by next week, and you can figure out the rest.

Deep knowledge is hard

Regardless of whether we have the time and resources to gain a deep understanding of something, it’s really hard! It takes hundreds or thousands of hours of deliberate practice.

The key word there is “deliberate”. You could spend a few thousand hours retyping the same “Hello world!” implementation in Python, but I can guarantee that you won’t be a Python expert by the end of it. Knowing how to practice deliberately with your tools and techniques isn’t easy; it takes effort, planning, and discipline.

We’re often lazy

I don’t think this one takes much explanation. Sometimes we just want to do nothing, and this desire often overrules our rational mind telling us to practice.

Symptoms of a lack of deep knowledge

You may be reading this, thinking “this isn’t about me, I’m deeply knowledgable about all the tools that I use”. If that is truly the case then feel free to stop reading! Consider, though, that you might be experiencing the Dunning–Kruger effect, overestimating your own ability.

I’m sure there are endless symptoms of shallow knowledge, but here are some that I’ve come across.

Blind faith in Stack Overflow

Stack Overflow is an absolutely brilliant website that should be used by all developers. However, if you find yourself regularly copying and pasting code snippets without fully understanding what the solution entails or reading the explanations and comments, then you are settling for a shallow understanding.

Many developers often find themselves bouncing from one Stack Overflow thread to another trying out every vaguely similar solution, instead of using the lessons from each to synthesise their own. This is a passive approach to problem solving rather than the active approach required for deep knowledge.

Using print statements to figure out what code is doing

We’ve all done it. The Hail Mary of the desperate developer. Printing things like “GOT HERE” to the console can be a life-saver in a pinch. However, if you are regularly relying on such tactics to understand the code that you work with, it’s a sure sign that you need to spend some more time getting to know it. Most languages have debugging tools which make this process a lot more flexible and constructive.

Being inefficient with your tools

There are some incredibly powerful tools for developers out there. I’m constantly blown away by the capabilities of the IntelliJ IDE, for example. It seems a shame not to use such impressive tools to their full potential.

A little up-front learning could allow you to automate a lot of laborious text editing tasks. It could also mean that you rely less on your mouse/touch pad.

That may come across as a little pretentious, but a lot of small actions can add up over time.

What can you do to attain deep knowledge?

So you’ve dug deep, done some reflection and realised that maybe you don’t know your tools as deeply as you could; what can be done to fix it? Here are some suggestions from me:

Deliberate practice

The thing to do if you really want to get to know your tools is to use them repeatedly and conscientiously. We use our tools on a daily basis, but this is not enough to gain a deep knowledge of them. Repetition builds habits, which aren’t always good habits. If you use your tools without paying attention, you are unlikely to improve.

Instead, you should be reflecting on your use and knowledge of your tools while you use them. For every action you take, ask yourself if it is the most suitable for the situation.

Likewise, ask your colleagues for feedback on the ways that you use your tools. More experienced members of your team especially will be able to give clarity or share tips.

Constantly ask yourself, “what are the deficiencies?”. When you have identified them, figure out what steps you need to take to improve and fix them. Are you being lazy and neglecting to memorise a shortcut? Are you making blind assumptions about how an API works?

Use such discoveries to guide your learning, instead of mindlessly continuing. There is always room for improvement.

You could even consider putting yourself into manufactured situations. For example, I have toyed with the idea of trying an hour a week when I am not allowed to use the touchpad at all. This is a lot easier to try if you work alone, but in my case I have to find a willing pair first!

Read the documentation (RTFM)

This is one which I really struggle with. I absolutely hate reading documentation for libraries, APIs, languages, you name it. I find the process dense, and in some cases stressful when there is time pressure. It is truly my belief that reading documentation is an art form, just one I have yet to learn.

In all seriousness, it is quite likely that if you have a question about a tool or language that needs answering, there will be an answer somewhere in the documentation. This is not always the case, but knowing how to quickly find what you need in the documentation is a skill worth knowing. Reading the documentation for a product in more depth and being generally familiar with it is an important part of having deep knowledge.

Consider trying something like this: set yourself a project using a language you would like to learn more in-depth, and restrict yourself to using only official documentation or articles in order to get the project done. No quick fixes from Stack Overflow, no random blog posts. Official documentation only. This will force you to learn to read docs, and where they are lacking, will teach you how to investigate and explore your tools.

Read the source code

A similar approach that relies less on documentation, which could be wrong or out of date, is to read the source code if available. No matter what the docs say, if the code does something else then that is the truth of the matter.

Having a good knowledge of the standard library and implementation of your tools provides a reliable foundation on which you can build more in-depth, specialist knowledge.

Use debugging tools

This is an approach I have only recently come to appreciate. Unlike the print("GOT HERE") approach discussed above, using debugging tools allows you to get a real-time view into the way your programs work.

Reading the source code is easy enough to suggest, but the sheer size and complexity of some systems can make it impractical. Executing code with a debugger and stepping through one command at a time can really help to visualise the sequence of events a system produces and the interactions it has.

If nothing else, a debugger can provide you with questions you can use to expand your understanding. If you see some unknown, unusual object being called as part of a framework you are using, you can start to investigate what that object is/does, and start to build up a more substantial understanding.

Stay up to date with recent developments and issues

This is another one which I only recently came to appreciate, while a colleague and I were trying to figure out how to test something in the React framework using Enzyme. My more experienced colleague had a completely different way of approaching the problem.

After we had spent some time playing around with the code trying to get it to work, she started to look in the open issues section of the API’s GitHub page. Sure enough, before long we had found an issue which described the one that we were facing. Before that, I would never have thought to find out more about a tool by looking at the work being done to it.

This practice has several benefits. The first is that you start to get an appreciation of what is lacking in the tools that you are using. My colleague and I had simply assumed that because React behaved in a certain way then a testing utility like Enzyme would have the means to test it, but we were wrong. Deep knowledge can save you from tripping up on similar problems further down the line. It could even inform significant changes in the tools that you use.

The second benefit is that knowing what’s missing gives you an opportunity to contribute. There are few ways more effective to become knowledgable than contributing to the creation of a tool. Not only do you need a good understanding of how a system works if you want to change it, but it also gives you the opportunity to work and communicate with those who have been there from the start.

What are your thoughts?

Do you have a different definition for deep knowledge?

Do you know anyone who has deep knowledge of their tools? What effect does this have on the way they work?

Let me know in the comments below!

Being the Worst Means the Only Way Is Up

Flinn Burgess — Mon, 09 Mar 2020 12:28:56 +0000

(This post originally appeared on thetimelydeveloper.com)

How do you measure up against the other members of your team? Are you seen as a figure of authority that can be relied upon, consistently getting a lot done and teaching others to do the same? Or do you find yourself struggling on a daily basis to keep up with your talented colleagues, constantly being challenged by the work you do?

In their book Apprenticeship Patterns, authors Dave Hoover and Adewale Oshineye encourage readers to make the most of being the worst in a team. At first, this seems like a backwards notion; after all, who wants to be the worst at something? We are often taught to compete against each other and to try our hardest to be the best; by definition the opposite of being at the bottom.

Today’s article will discuss the topic of being the worst and what you can get out of it.

(This post is part of a series inspired by the book Apprenticeship Patterns. Find the rest of the series here.)

What does being the worst look like?

First let’s talk about what being the worst means in this context. The most important thing to keep in mind while reading this article is that being the worst does not necessarily mean being bad at something.

Unless you have only just started learning something, you are unlikely to be objectively bad at it. Once you have put some time and practice in, you will gradually become average or even skilled in the area.

Regardless of skill, there will always be an opportunity to be the worst in the team. The authors make the following suggestion:

"Surround yourself with developers who are better than you. Find a stronger team where you are the weakest member and have room to grow." - Be the Worst, Apprenticeship Patterns, D. Hoover & A. Oshineye

So, being the worst means being surrounded by people with more knowledge and experience than you. Even if you have, say, 10 years of experience working with C#, you can seek out people with more.

Remember as well that being the worst at everything is improbable, if not impossible; there will always be something that you are better at than your peers. You might not understand the ins and outs of infrastructure yet, but you could be a better presenter than your team’s Kubernetes expert.

A diverse team is a strong team, and you can be the worst at one skill while contributing to such diversity with another.

What are the benefits of being the worst?

The quote above encourages you to be the worst so that you have “room to grow”. I don’t think this is the best choice of words, because everyone has room for growth; there is no upper limit to personal growth in my opinion.

It creates opportunity

I think a better way of phrasing it is that you have more opportunity to grow. You will always have room to grow, but with fewer opportunities and resources it will be harder. Without the support of an experienced and challenging team, you must rely on yourself more. This naturally raises challenges when it comes to gathering useful feedback and assessing your own abilities in order to grow.

Being surrounded by those more experienced than you solves this problem. They have already been through what you’re going through and have collected the scars. They can give you solid advice on how to progress, and will work at a pace and level of understanding which will force you to grow.

I recently attended the birthday party of an old friend of mine who has become an accomplished pianist over his life. At the party, his dad gave a speech which included a part in which he described how my friend’s step-mother would know exactly how hard to push him and his boundaries such that he would rise to the challenge.

A good team provides you with the opportunity to do the same.

It forces you to challenge yourself

Consider what the opposite of being the worst looks like. You’re the most knowledgable and talented person on your team, and everyone comes to you for answers. You get through most days without much of a challenge and know that there’s no real pressure on you to grow.

Settling there in the comfort zone is the easy option, and lots of people choose to do it. On the other hand, confronting yourself and giving up on that comfort to jump into the deep end is a terrifying and character-building thing to do. If you can do it on a regular basis, you will learn more long-lasting lessons than you will by avoiding challenge.

It will teach you how to learn

Have you ever heard of Parkinson’s Law? It states that “work expands to fill the time available for its completion”. We can all relate to it; just think back to those late nights spent cramming for a school exam, or to the last project you worked on which pushed right up to its deadline.

I believe that a form of this law applies to learning in a team. That is, the slower the work pace of your team, the longer you will take to learn new things. To invert the idea, if your team works at a faster pace, then you will learn faster.

Don’t get me wrong, I’m not talking about faster typing and less thinking, or more lines of code per minute. What I’m saying is that if you are part of a team who know their tools and their language and how to work efficiently with them, then you will have to learn a lot in a short amount of time or else fall behind.

As the old saying goes, necessity is the mother of invention.

How do you stay the worst?

Perhaps by now I have convinced you of the value of being the worst in a team. You might be wondering, however, what practical ways there are for achieving it. The authors of Apprenticeship Patterns don’t go into too much detail about how you can do this, instead focusing on the benefits of the pattern. Here are some ideas I have on how you can go about it:

Look for unfamiliar work and teams within your organisation

A lot of organisations have more than a single team that you can have the opportunity to work on. If this is the case for you, see if you can find a team which is working with an unfamiliar tech stack and ask to join them. If, for example, you have been focussed on the backend or infrastructure side of a project, see if you could try working with the frontend team for a time.

There are also countless non-functional requirements in the world of software that it would be valuable to learn. Choose one which is new to you and start to learn from those around you who already know about it. Here are a few examples to get you started:

Accessibility
Security
Privacy
Durability

If you are a student, consider choosing a module which is completely different to anything you’ve tried before. Another approach for students is to ask a professor who specialises in an unfamiliar topic if you can volunteer to help them with their work/research.

Try out higher-level roles

This point goes against the spirit of Apprenticeship Patterns a little, since the book encourages readers to focus on personal growth and becoming a better developer rather than seeking to climb the promotional ladder. Regardless, I believe that there is no shame in looking for promotion if you see it as an opportunity for growth and challenge.

If you struggle to find teams in which you are the worst developer, promotion may give you the opportunity to be the worst in other ways. You might be an expert Python developer, but can you lead a team or manage stakeholder expectations? Are you able to direct the technical vision of a project from start to finish?

Promotion usually involves taking on new and challenging responsibilities, many of which you will initially be the worst at when compared with your peers.

Leave your company

Sometimes there’s nothing for it but to leave the job you currently work at, either because there are no opportunities to be the worst or you simply need a change in environment to inspire growth.

This might also make deliberately moving from a position of expertise and seniority to one in which you are the novice easier, since people will have fewer preconceptions about what you know.

Consider finding a company which is working on something completely new to you in terms of technology, industry, or problem domain.

My experiences being the worst

Being at the start of my career, I am lucky in that I have plenty of opportunities to be the worst and there is usually little expectation for me to be the best. When I consider the experiences I’ve had so far, however, there are two that stand out more than others; one bad, the other good.

The bad

The first experience happened when I was a graduate developer. I was put on a side-project as part of a development team made up of just myself and another grad. My team-mate was a brilliantly intelligent thinker and seemed to pick up an understanding of the technology and problem with ease.

I was the worst in this situation and didn’t have such an easy time. I struggled with trying to learn a language I had never seen before (Ruby) while also trying to keep up with the pace of my colleague. All in all it was a stressful and demoralising experience for me.

On reflection, I think this was primarily because the team was made up of two junior developers. Without a more senior team member to help guide my development, there was more pressure on me to provide that direction and challenge to myself, and I failed to rise to the occasion.

The good

More recently, I have been working on another side-project with another highly intelligent and talented colleague. Though we are at the same level of seniority, his depth and breadth of knowledge far exceeds my own. Compared to the first scenario, I feel as though I have grown a lot more both professionally and technically, and there are a few reasons for this.

First is that my colleague has many years more experience than me, and so is more prepared for supporting a junior team member. His depth of knowledge also means that he is often recommending and using concepts that are completely unfamiliar to me, exposing me to new approaches.

I also find that when we are pairing I tend to put more pressure on myself to work more efficiently, as I discussed above. While this can sometimes feel stressful and is by no means intended by my colleague, I think it is a vital part of the learning process for me. Without that pressure, synthetic or not, I may well make less of an effort to expand my skills and grow.

These two examples hopefully demonstrate the dangers and opportunities that this can provide.

Let me know your experiences!

Have you been in many situations in which you were the worst on your team? What did you learn from that experience?

Let me know in the comments below!

Using Feedback to Guide Growth

Flinn Burgess — Mon, 02 Mar 2020 07:52:09 +0000

(This post was originally published on thetimelydeveloper.com)

If I were to ask you how good a developer you are, do you think you’d be able to give me an accurate answer? Would your colleagues agree with your assessment or would it be skewed in your favour?

In their book Apprenticeship Patterns, Dave Hoover and Ade Oshineye encourage readers to “Create Feedback Loops” in order to mitigate against this bias we all have. Today’s post will explore the importance and benefits of feedback.

(This post is part of a series inspired by the book Apprenticeship Patterns. Find the rest of the series here.)

The Problem With Missing Feedback

Imagine for a moment that you wake up one day and, unbeknownst to you, are incapable of feeling pain. You climb out of bed, put on your jogging gear and go for a run. As you hit your stride you realise that it feels easier than usual and so you push yourself harder. Your breathing gets heavier but physically you feel okay so again you up your speed.

Having finished your usual route at a record pace, you sit down to take off your shoes only to find your feet bloody and torn. A day later your legs fail to support your weight.

We see a problem here; what seemed like a good thing to you at the time turned out to be significantly damaging. Without the physical feedback of pain, you kept going faster and harder until you broke yourself. Likewise, in your work, if you are lacking feedback or are oblivious to it then you will inevitably do damage to your career and your product.

As another example, imagine that your software had no tests, or that you simply never ran them. Would you be confident that after six months of active development you would have a well-functioning product? You may not have considered tests to be a form of feedback, but it is the most common that we developers use on a daily basis.

We are lucky in that pain is given to most of us for free. If we do something that is damaging to us, we almost immediately feel pain and learn not to repeat that action. We are not so lucky in the world of work, however. We must deliberately create our own feedback loops, as discussed in Apprenticeship Patterns, if we are to thrive in our careers.

Types of Feedback

In the field of systems thinking there are two main types of feedback.

Constructive feedback

Let’s jump back to the concept of pain for a moment. We don’t usually consider it as feedback, but pain is massively important to our well-being. Without it, we would often find ourselves in situations similar to the one described above. Pain, in such a case, is what regulates our actions to stay within safe limits. Pain is a type of balancing feedback.

When it comes to your career, balancing feedback usually comes in the form of constructive feedback. Constructive feedback is the kind which points to areas of potential improvement. People often link the term constructive feedback to negativity, but this is a mistake. If someone asks you to raise the volume of your voice during a presentation so that they can hear you more clearly, is that inherently negative? I don’t think it is, and yet this is a form of constructive feedback.

The focus of this post will be on constructive feedback, as I believe that it is the most important for the purpose of growth.

Reinforcing feedback

On the other side of the coin is reinforcing feedback, which is characterised by an increase in particular behaviours. Much like constructive feedback, we should be careful not to think of reinforcing feedback as inherently good. Consider the following:

A senior business person comes to you and asks you to finish a feature ASAP. They’re putting a lot of pressure on you to get it done, and so you start to take shortcuts with your work; a skipped test here, some tech debt there. Before long you’ve finished the feature and you show them the finished work. They’re absolutely elated and clap you on the back, telling you much how much they appreciate it and promising to return the favour at some point. You feel pretty good about yourself; it’s nice to get recognition from one of the higher-ups for once.

This is the kind of reinforcing feedback that you should avoid. To maintain your reputation as someone that gets things done quick, you will continue to be pressured to take shortcuts that will compromise the quality of your work.

Positive reinforcing feedback does exist however. When someone compliments the thoroughness of your testing strategy, or comments on how cleanly your code is written, they are providing positive reinforcing feedback. You should accept such feedback gladly and use it to identify your strengths. Likewise, you should provide it to others when you see them behaving in ways which are beneficial to themselves and the team.

Asking For Feedback

Okay, so you understand what types of feedback to expect, now it’s time to start thinking of how you can collect it in your own life. As I mentioned before, I’m going to be focusing on constructive feedback in this post since it is the most useful for coming up with ways you can improve.

In most cases, you are going to have to explicitly ask for feedback, for two reasons: people are busy, and giving feedback is hard. To expand on the first point, more often than not people are focused inward on themselves and what they are doing. As a result, they may not often be thinking of ways in which you could improve yourself or prioritising letting you know. Without prompting, most people will not actively look out for these details.

To the second point, giving constructive feedback can sometimes feel uncomfortable by its very nature, since the giver is pointing to areas in which you are perhaps not maximising your potential. Imagine, for example, that you have to tell the next developer you work with that their variable naming goes against all common conventions and makes their code difficult to read. I know I wouldn’t find it easy.

To make it as comfortable as possible for the feedback giver, show them that you are happy and open to listening to their suggestions. Let them know, implicitly or explicitly, that you won’t take anything personally and that you are asking with a genuine desire to grow.

Ask about specific areas of improvement

Being too general when asking for feedback can be a frustrating and confusing experience for the person giving it. Questions like “how do you think I’m doing” or even just “can I have some feedback please?” can often feel impossible to answer, since they are so broad. Most people do not have the time or patience to focus and comment on every aspect of your behaviour.

Instead, ask about specific things that you think you can improve upon. For example, you might ask a team member in what ways they think you could improve your explanation of technical concepts. This focus allows them to come up with more useful suggestions, since they aren’t left second-guessing the skills they think you might want to improve.

Ask open-ended questions

I know, this goes against what I just said in the previous point, but giving them the opportunity to give their own suggestions is important. If they are not given the opportunity to speak up, then many people will let things slide under the rug.

If you are asking for feedback verbally, then you can simply say something along the lines of “If you have any other feedback for me, just let me know and I’ll be happy to hear it”. When using a form to collect your feedback (discussed below), then you can simply ask an open-ended question with a text box input.

Use forms for added creativity

Collecting feedback face-to-face is incredibly important, since it allows you to ask for clarification immediately if needed and enables conversation. However, sometimes face-to-face feedback simply isn’t practical for any number of reasons. A useful alternative in this case is a tool like Google Forms.

There are several benefits to using tools like Forms. For example, it allows you to ask a specific set of questions, and gives the person being asked plenty of time to give well-thought-out answers.

Another major benefit in my opinion is that it gives you creative ways in which to ask questions. For example, I’ve seen people ask for a rating on a scale of 1 to 10 for specific areas, or agree/disagree statements with “Why do you think this?” follow-up questions. Approaches like this make the process easier for the person filling out the form, thus increasing your chances of getting a response.

Lead with your own self-assessment

This is an approach that I have experimented with occasionally. If you are asking about something that you think has been particularly frustrating for the other person, then lead with your own observations on the situation to make them feel better about contributing.

For example, let’s say that you are pairing with someone but you keep getting distracted by your phone because you are trying to resolve a maintenance issue with your landlord. You notice your pair getting visibly agitated with your behaviour, but they haven’t said anything.

In a situation like this, you might say something along the lines of “I’m aware that I haven’t been the best pair recently and have spent a lot of time distracted, would you agree?”. By doing this you are immediately making it known that you are aware of a potential problem and that you won’t be defensive while discussing it.

It’s important in situations like this that you genuinely believe what you are saying. You should never give a false opinion just to get a colleague to talk.

Speedback

A great way to enable and encourage feedback is to engage in what is called speedback. The concept is a simple one: apply the rules of speed dating to giving feedback. Your entire team sits in a room and splits into pairs. Each member of the pair has two minutes to give the other feedback on a given topics before switching roles. Once the four minutes are up, the pairs rotate. Rinse and repeat until you have shared feedback with every other member of the team.

Speedback is particularly effective because it reduces the stigma attached to giving feedback and creates an environment in which everyone should be open to giving and receiving it.

One downside of speedback is in its natural brevity. Two minutes isn’t usually enough to talk about any topic, and this includes feedback. Make sure that you note the things your colleagues are saying and follow up with them to gather more information.

The Benefits of Regular Feedback

Accurate self-assessment

Let’s face it, we all think we’re pretty great in general. Even if you regularly practice reflection, your estimation of yourself is likely skewed in your favour.

The authors of Apprenticeship Patterns note that when assessing your own ability, you only really have your less experienced self to compare to. In that light you will almost always look good.

Asking for someone else’s likely more objective opinion is a much more reliable metric of how you’re doing. This is especially true if the person you are asking is more senior, since they have already had the opportunity to learn what works and what doesn’t and can share it with you. This leads nicely onto my next point:

Learn from others’ experience

Asking for feedback opens the door to learning from others’ experience. Why go through all the same troubles as your colleagues?

Think of a problem that you’re dealing with at the moment. I guarantee you that someone you know is either going through the same or has already been through it. If this is true, you could do a lot worse than asking them how they dealt with the problem.

In this way, asking for feedback can save you a lot of unnecessary work.

Focus your efforts

What are your five biggest strengths and weaknesses? If you don’t know the answer to this question, especially your weaknesses, then how can you know how to effectively improve yourself?

You may think that you know the answer to the question and could write the list of ten items in a flash. But we’ve already seen that self-assessment can often be unreliable; if you showed that list to your colleagues, would they agree?

In order to improve yourself you need to know in which areas you have the most opportunity for improvement. Feedback can give you the answer.

Making the Most of Feedback

As with most things in life, information without action is mostly useless. Once you have collected feedback from your peers, you need to react in some way in order to grow.

It is important to remember however that you have no obligation to accept any and all feedback that you receive. If you fundamentally disagree with something then you can choose to ignore it. I would recommend that you at least consider each piece of feedback as containing an element of truth. Your peers are unlikely to mention something that is completely false.

Act on it

I haven’t delved into what makes for good feedback, but one property is that it is actionable. The information you have gathered should point towards specific improvements that you can make. It may also tell you how you should go about making those improvements. If it does, then go ahead and make the changes! If it doesn’t, then look for ways in which you can improve, either through personal research or by asking colleagues, then implement the changes.

Follow up

Once you have recorded your feedback and acted upon it, make sure that you follow up with each person that gave it to you. Your goal when acting on feedback is to grow as a person. Thinking that you have is not enough; you need some way of validating it, and who better to ask than the person who pointed it out to you in the first place?

My Turn

I hope this article has been helpful for you! It would be remiss of me to write a post on feedback only to neglect asking for it. Let me know in the comments below what you thought of the article and if it was useful to you.

Have you benefited in any major way from feedback in the past? Do you have any methods of collecting or using feedback that I haven’t discussed here?

Apprenticeship Patterns Review: Become a Better Developer

Flinn Burgess — Sun, 23 Feb 2020 16:43:01 +0000

(This post was originally published on thetimelydeveloper.com)

The world of software can be overwhelming at the best of times, even for those who have worked in the industry for several years. The rate at which you have to learn and absorb new information exceeds that of many other industries. Today’s book, Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, looks to guide you through many of the problems the fledgling developer is likely to face. Read on to find out whether this book is right for you.

Book overview

Apprenticeship Patterns sets out to teach you ways in which you can more effectively approach a software development career. It takes the concept of a pattern language and applies it to a job in the industry.

Each piece of advice is presented as a Context, Problem and Solution, and fall into one of five sections:

Learning to keep an open mind throughout your career
Maintaining your commitment over a long career
Assessing your own abilities accurately
Learning effectively
Choosing/finding learning materials

It is this pattern language approach that makes the book so appealing. A few spare minutes with the book could answer that one question that’s been bugging you or send you on a path you may never have otherwise considered. You would be hard-pressed not to find a couple of pages which are immediately applicable to your job.

The book is also really valuable thanks to its expression of common problems for beginners. While they bring passion and fresh perspective to the industry, newcomers also have a massive amount of pressure to learn and adapt. Not being able to fully conceptualise and express problems faced can be a frustrating experience. The apprenticeship patterns described in this book can help to put these issues into words.

If you find yourself struggling at the start of your career, or are lacking direction and need to know what to do next, then you could do a lot worse than read this book for ideas.

Who should read this book?

Beginners

The obvious answer is the one that the authors themselves give: industry newcomers. The barrier for entry to this book is virtually non-existent and this makes it ideal for those with little experience. If you are an industry novice or advanced beginner then you are likely to get a lot out of the book. There is one caveat, in that the novice might struggle to relate to the problems discussed due to a lack of first-hand experience.

Competent Developers

The authors also point out that more experienced developers could glean some new insight from the book. I think this is a little understated. It is very easy to find yourself settling into a comfortable routine or getting stuck in a rut, which I believe the structured approach in the book would help to solve.

Proficient Developers/Teachers

One potential audience that I think the authors fail to highlight are senior developers. As they point out several times, apprentices will eventually become journeymen, sharing their knowledge with the less experienced. This book would serve as a good refresher on what many junior developers are going through and what approaches might help them progress.

What questions could this book answer?

If you find yourself asking any of the following questions then you should consider reading this book:

What are the best techniques for continuously improving my craft?
How do I reach the level of competence of the developers that I look up to?
What does it mean to be a skilled developer?
What habits should I build to improve my day-to-day work?
Am I a bad developer for struggling at work?
What can I do to reignite and maintain my passion for a software career?

What should you know before reading?

This book is unlike many that I expect to write about on this blog, because it requires next to no prerequisite knowledge in order to get a lot of value out of it. Thanks to it being aimed at relative beginners, the content is easy to understand, and the authors’ analogy of craftsmanship should be understandable to most.

Complementary resources

See my mind map for a high-level visual overview of the book.

A key lesson from the book is in how to concentrate on becoming a great developer, rather than climbing the promotional ladder. This essay makes a similar case: we should learn for the sake of learning. Focus on your own knowledge and ability, and good things will come to you.

One piece of advice from the book is to learn concrete skills that will set you apart and serve you well over time. If you want to develop some foundational skills then check out this site.