DEV Community: Hibo

Tips to better contribute to a product team as a Junior Developer

Hibo — Mon, 21 Dec 2020 11:56:51 +0000

Over the past couple of weeks, my colleagues and I at Stairway have been working hard to improve our product process and become a more empowered and collaborative product team. I’ve recently read “Inspired: how to create tech products customers love” by Marty Cagan to help understand what a successful product team looks like.

If you’re a junior developer working in a product team who’d like to know how to make themselves more useful, here are the tips I feel will help you.

1. Learn about the product process and the responsibilities within the product team

As a Junior Developer with no prior technical background, product was one of the first terms I started hearing a lot of and it was very abstract to me. What is product? What do product managers do? What is their goal? Bring in other terms like “product discovery” into the mix and I realised that it was a very important area of the company that I had no real understanding of. I also didn’t think it really had much to do with my day to day role aside from working with the product manager to implement features and shape designs but I couldn’t have been more wrong.

An effective product team is one that works collaboratively to help the product manager to determine how to discover and build a product customers will love. And in order for you to effectively contribute to this team, it is crucial to understand what a successful and collaborative product team looks like (and likewise what it doesn’t look like). Ultimately, you need to learn about everyone’s role on the team and how your job helps them do their job.

That being said, here are some resources to help you get started:

Inspired by Marty Cagan. I cannot recommend this book enough. Although it is geared towards Product Managers, Marty dissects each role in the product team as well as what a correct product process looks like. View here.
Silicon Valley Product Group Blog. A blog sharing best practices around how to build innovative products customers love. View here.
Lenny Rachitsky Newsletter. This was recommended to me, it is a newsletter around product and growth, particularly useful if you are interested in working in product. The monthly email is free with the weekly emails requiring a paid subscription to access. View here.

2. Learn about your company vision and strategy

Once you have a good understanding of the product team, you should take the time to understand your company vision and strategy. I am sure you probably already have good knowledge of this but I would still advise that you revisit it. You’ll view it with a newfound perspective on how a product team and your role fits in with this wider goal.

3. Participate in the research phase of the product discovery process

Writing products comes from the deep understanding of the users needs combined with an equally deep understanding of what’s just now possible - Marty Cagan

The product discovery process is a hugely important part of the work of a product team. It involves studying users to understand which features or products to commit resources to and build. I won’t go into too much detail about it now but here is a useful article if you’d like to learn more.

Evidence gathering is an important part of evaluating whether a feature should be prioritised and built. However, developers typically aren’t as involved in this process as they could/should be. The work of a developer mostly involves evaluating features/designs being worked on by the wider product team and implementing features that are ready for development. Thus, product discovery happens before developers typically get involved.

However, engineers have a lot to contribute at this stage and so you need to play a bigger role in the initial stages of product discovery. More specifically, this involves keeping up with the latest data insights on users and also playing an active role in querying and analysing the data that you are collecting.

At Stairway, we use BigQuery, Metabase and Amplitude to query and analyse data which are then shared in slack channels and discussed in meetings. This helps us to have a clear sense of direction with feature development as well as brainstorm further lines of inquiry for research.

If your team conducts user testing sessions, join them and you will see the benefits it provides in helping you learn more about your users and the technological solutions that will make them love your product more.

4. Consider how analytics will be factored into every feature you work on

In order to be impactful for your users, the decisions of the team must be data-informed. And in order for decisions to be informed by data, data must be collected! And not just any data but the right data to answer the questions you are seeking to answer.

Are you involved with conversations around analytics and how they will be implemented into new features? Are you aware of the analytics that you are collecting for the features already in production? What more could you be collecting?

One thing I try to do when a new feature is being considered is to have a think about what analytics we would need to collect to evaluate the success of the feature.

Is it important to know how many unique users used the feature?
Are we interested in seeing if this increases the number of active users?
Are you conducting an A/B test and comparing one data set to another? What difference are you expecting to see?

Thinking in this way will help you to develop a data-driven mindset where decisions made are based on analytics and experiments and it will make a difference in your ability to conduct data analysis yourself. In terms of the goals of the wider product team, collecting the right analytics facilitates the crucial product discovery phase of the product process. As a junior developer, get involved in this!

5. Share your findings and ideas with the team regularly

An effective product team is one that is collaborative. Instead of thinking about the team as having strict roles that everyone is assigned to, roles should be a bit more flexible and involve discussions with other team members to contribute a fresh perspective.

Part of being more collaborative is knowledge sharing. This could involve sharing observations from data, user research or your own ideas you have to improve the product. At Stairway, one way we do this is by having a weekly show and tell session. Everyone discusses what they have been working on as well as any new insights and learnings they have discovered during the course of the week. We discuss everything from designs, to data, to new ideas for product and it works really well in facilitating collaborative decision making.

Sharing ideas and knowledge is particularly important for engineers as they are often the best source of ideas as they have the knowledge required to consider how user problems could be solved using technology. Engineers are aware of how the system works and how easily something can be achieved.

If you don’t have a culture of knowledge sharing in your team, try to implement it. You could make a slack channel (or another equivalent) where people post new insights they’ve found or anything they’ve been working on to get feedback. Working in this way will help facilitate continuous improvement which is an important ingredient to success in a product team.

6. Review and feedback on features as early as possible

Developers typically review designs and features when they have been fleshed out by the designer and product manager and even tested in some initial user testing sessions. However, developers can provide value much earlier in this process, even when features are just ideas and designs are just simple drawings. The main benefit of this is that it makes the design process and feedback delivery easier. Sharing goals and ideas early benefits the whole team in terms of time and effort and prevents any large changes to designs being made late in the design process.

If you are typically evaluating features at a later stage, discuss with your team to see if this is something that can be changed to bring the review process forward.

If you struggle to think about how to evaluate a feature, consider these four product risks:

Value risk (whether customers will buy it or users will choose to use it)
Usability risk (whether users can figure out how to use it)
Feasibility risk (whether our engineers can build what we need with the time, skills and technology we have)
Business viability risk (whether this solution also works for the various aspects of our business)

Whilst all risks should be considered when evaluating a feature, engineers should focus the majority of their attention on the feasibility risk, and take responsibility for it.

You can read more about the four risks here.

Thanks for reading this article. I hope it has helped you to understand how you can better contribute to a product team and think about new ways you can get involved in your team's work outside of development.

Demystifying common JavaScript jargon (part 1)

Hibo — Mon, 23 Nov 2020 08:47:37 +0000

Does your mind draw a blank when you see words like primitive, coercion, template literal etc...?

Are you tired of not knowing what these words mean (or equally forgetting what they mean)? Do you want to find out what these terms (and some more mean) in one convenient place? Welllllll, you've come across the right article 😁

I hope this can help to demystify these terms and help you finally get them into your head.

I'm a good 4 months into JS and I've never learnt these terms properly (at least in a way that gets them permanently into my head) so I'm writing this primarily to help me and so there will be terms I've missed. I'm happy to make this an ongoing series so if you'd like me to include anything don't hesitate to comment below with suggestions 😊

1) Primitives

A primitive is the simplest element in JavaScript. A useful analogy to help me remember is thinking of primitives as being similar to the concept of atoms. An atom is the smallest unit of matter and primitives are the simplest elements with which we can start building things in JS!

Primitives are not considered objects in JavaScript and they have no methods.

There are seven primitives: String, Number, Boolean, Undefined, Null, Symbol and now BigInt (new in ES2020).

I won't go into each of these primitives here but if you want to know more, head to this MDN page.

2) Declarative vs. Imperative

This one is still a bit hazy to me so I'm open to clarifications/corrections below if I've made a mistake but here goes!

JavaScript is a multi-paradigm language which means that you can use different styles of programming with the language (sneakily snuck in another term there 😉).

Two such styles of programming are declarative and imperative. If you're familiar with React, you will know that React takes a declarative approach. But what does that mean? Well, a declarative approach means that you write code that describes what you want, but not (for the most part) how to get it.

Here's an image I found on Google that is a good example:

Notice how in the declarative approach, the steps that JS takes to create the new array isn't really exposed. You don't see how the elements in the new array are assigned their values. Whereas, in the imperative approach you can see the underlying mechanism. It's clear exactly what is being done in a step by step fashion.

Well, that's the key difference. With a declarative approach, you take more of a hands-off approach where you describe what you want to achieve but now how to achieve it. With the imperative approach, you say exactly how it will be done.

3) Type coercion and conversion

Type coercion is when JS automatically converts from one type to another. A good example of when this happens is when you use operators.

You may be familiar with the common JS example of what happens when you try to add a string and a number.

const sum = '12' + 2
// returns '122'

The result is that the number is converted by JS to a string and the strings are then concatenated (or put together) (oh look at that another term 🤩).

I won't get into why JS converts the number to a string rather than converting the string to a number but if you want to learn more, look into operator precedence.

Type conversion is when you explicitly tell JS to convert from one type to another. An example of this is when you use functions like .toString() to convert a number to a string.

4) Dynamic Typing

When you assign a value to a variable, JS automatically determines the type of the value. It is important to keep in mind here that it is the type of the value that is automatically determined and not the variable. Variables don't have any type, they are just a label given to the value so we can retrieve the value from memory and use it.

5) ES5, ES6, ESWhaaaaa???

This one is a bit long to explain so bare with me! We'll have to take a little dive into the history of JS to explain this properly.

ECMA Script is the first official standard for JS. It was created to ensure there was a standardised use for the language. JS is the language that implements the standard.

JS used to be updated every few years. You have probably seen the update ES6 referred to everywhere and that is the 2015 update to the language. The ES6 update was the biggest JS update yet and why it is mentioned so often as it brought a ton of cool and frequently used features to JS (like arrow functions).

Since 2015, it was decided that there would be an update to JS every year and so now we have ES7 (2016), ES8 (2017), ES9 (2018), ES10 (2019) and this year ES11 (2020).

So, that's in the simplest terms all there is to ES___. They are just references to updates that have been made to JS. If you want to read more, you can find out about the history of JS here.

Ok, that's all for this first article! If you got to this point, thank you so much for reading and I hoped this helped you.

Now that I've reached the end, I think there is definitely an opportunity to make this a series (I have a couple of terms in mind already 👀) SO WATCH THIS SPACE!

A quick guide to Extreme Programming (XP)(Agile development)

Hibo — Tue, 04 Aug 2020 20:34:46 +0000

What is Extreme Programming?

A set of principles in agile software development that aims to help developers produce higher quality code.
It is said that the name comes from encouraging teams to perform these essential practises to the best of their ability, almost to the extreme.

When would you employ these principles?

XP and agile software development is typically applied in a team environment (although there is nothing suggesting you can’t apply some/all of these practises to your own individual processes).

Specific examples of when you should employ XP principles include:

When dynamically changing software requirements
When there is the potential for risks caused by fixed time projects using new technology
When you are part of a small, co-located extended development team
When the technology you are using allows for automated unit and functional tests

The five principles (or values as they are sometimes called) are:

Communication

This principle stresses the importance of communication to transfer knowledge from one team member to the rest of the team.

XP stresses that communication should, in the best case scenario, be face to face, with the aid of a white board or other drawing mechanism. This could be in the form of retrospectives and stand ups

Simplicity

This is all about addressing the requirements that you need to. Keep the design of the system as easy to maintain and support as possible.

In other words, you should keep in mind “What is the simplest thing that will work?”

Feedback

In order to identify areas for improvement and revise practises, both in the product and the team, constant feedback is necessary.

In this sense, feedback is though two support the simplicity principle and help keep your design as simple as possible.

Courage

This is all about having the confidence to raise issues to the team, try something else when something isn’t going right and accept and act on constructive feedback, even when it can be difficult.

Respect

Lastly, and in my opinion the most important one is respect. In order to do all of the above, you need to respect one another.

Respect your team members enough to:

Communicate with them
Give them feedback and accept the feedback you are given
Work together to design in the simplest way

I hope this was an informative guide to extreme programming in agile development.

Check out these links for more information:

The road to becoming a JavaScript pro #1: Asynchronicity

Hibo — Sun, 02 Aug 2020 13:09:11 +0000

Introduction

I have been feeling like my understanding of JavaScript has been shaky and so I have decided to write a series of blog posts to help me learn the concepts I have found tricky and solidify my knowledge.

I will be trying to avoid using language that makes it difficult to follow the article when paired with a concept that you don't fully understand yet. This is to make it as beginner friendly as possible. Think of this article as more of a starting point to learning more about asynchronicity.

I hope this is helpful to anyone who reads it but I'd also like to add that I am by no means an expert and so if there is anything incorrect, please correct me below 😊

Asynchronicity

In all programs, it is important to distinguish between what happens now and what happens later.

For example, if you have a website and you load a page of that website. A chunk of code from your program has been executed immediately to get that page to load and show what it needs to show. However, other chunks of code in your program have not been executed immediately as they could be waiting for events (e.g. a mouse click).

So, behaviour that is executed at the point in time in which the function is called synchronous behaviour.

Behaviour that is executed at a later point in time from when the function was called is asynchronous behaviour.

Another example of asynchronous behaviour is when you could be waiting for a response back after a event has occurred and a request has been made. For example:

when requesting data from a database or file system
when sending data across the network and waiting for a response

Why do you need to know about asynchronicity?

In JavaScript, chunks of code cannot be processed at the same time (i.e. in parallel). Everything happens one after the other. For this reason, Javascript is known as a single threaded language.

This is a problem for asynchronous actions as this will cause a program to stall and appear frozen whilst it's waiting for the asynchronous action to be fully performed.

Therefore, knowing about and accounting for asynchronous behaviour in your programs can help you make sure you are providing the best experiences for users of your program.

The event loop

To further understand asynchronicity, it is important to understand how the execution of chunks of code are handled in JavaScript.

As JavaScript is single threaded, it doesn't actually have any asynchronicity built into it. It performs functions in your program one at a time, at the moment in time when asked to by the event loop.

So what is the event loop exactly?

The event loop handles executing chunks of code in your program by invoking the JS engine. It is located in the hosting environment (e.g. a web browser) and you can think of it like a container storing a queue of actions to be performed by the JS engine. The actions at the top of queue get performed first and so on.

So, let's follow an example of the flow of what is happening in an asynchronous event.

Example asynchronous event: When sending data across the network and waiting for a response

Your JS program makes a fetch request for data to the server.
Whilst it's waiting for the response back, the JS engine tells the hosting environment to perform a callback function when the response is received.
When the hosting environment gets the response back from the server, it puts the callback function into the event loop to be performed.
When the callback function gets to the top of the queue in the event loop, the event loop passes it to the JS engine to be performed.

(Source: this flow was adapted from a description of the event loop by You Don't Know JS - found here)

Key takeaways

Asynchronicity refers to events that happen later in time and is an important concept to be considering when writing programs (in any language!).
The event loop determines the order in which the JS engine performs JS actions.

I think I will stop here for this article. The next article will deal more with how asynchronous events are handled in JS programs (e.g. callbacks, promises etc...).

Thanks for reading! 😁

TIL: the importance of knowing what your code does

Hibo — Mon, 27 Jul 2020 16:16:08 +0000

I am in the process of adding a scoreboard to the 'Run, Boris Run' game I developed for my final project (see here) which involves saving a persons score to a database.

Today I came across a strange error where the variables I was sending across to the backend were coming back as 'undefined'.

Upon investigating further with some print statements, I found that my request didn't have a body at all (so strange!!!!!).

I couldn't seem to figure out why my body was undefined and after some googling I came across something I had used before...

It seems I needed to import and use the Express Middleware body-parser. And this is a lovely explanation from Stack Overflow as to how it works:

body-parser extracts the entire body portion of an incoming request stream and exposes it on req.body as something easier to interface with. You don't need it per se, because you could do all of that yourself. However, it will most likely do what you want and save you the trouble.

In particular, I needed to make use of the bodyparser.json() method which parses the request data as JSON and exposes the resulting object on req.body.

I think it's a bit safe to say I took body parser for granted but I won't be forgetting it again anytime soon! This is also a lesson learned about making sure you understand what every imported library is doing and why you require it.

P.s. Here is the stack overflow explanation if you are interested.

ELI5: The git error - 'CRLF would be replaced by LF in...'

Hibo — Wed, 15 Jul 2020 10:12:45 +0000

It's happened a couple of times and the explanations on google I found weren't helping...

I would like to understand it once and for all!

Coding bootcamp final project: 'Run, Boris Run!' 🏃💨

Hibo — Fri, 03 Jul 2020 07:43:44 +0000

I AM OFFICIALLY A CODING BOOTCAMP GRAD WOOOO! 🥳

I learnt how to develop a 2d platform game in pure vanilla JavaScript as part of a my final bootcamp project at Makers Academy.

It's not perfect but I'm super proud of all I've accomplished with my team over the past two weeks.

You can play here if you're interested: https://run-boris-run.netlify.app

How to change the root folder of your Git repo

Hibo — Tue, 16 Jun 2020 17:48:51 +0000

Spoiler alert: this is not as daunting as it sounds 🙌

So today, I decided to change the root folder of my GitHub repository from the parent folder I had initially initialised the repository in, to a child folder in the same directory.

I almost didn't bother as I had flashbacks of past nightmare experiences changing things on git but I decided to give it a go and luckily it was much easier than I thought wooo!

I thought I would record this for my future benefit and yours.

The process

Essentially what you need to do is move the .git folder to the folder you want to be the root folder.

These are the steps I took in the command line (remember I am moving my .git one folder inwards - you will need to adjust the commands to your needs).

In the below example, $ represents a command line prompt which may look slightly different to yours.

Now without further ado, here are the steps:

Start by moving your .git file to the folder that you want to go to.
- $ mv .git
Then navigate to that folder.
- $ cd
Then add all the changes to the staging area. Git will detect these files as renamed versions of old files that were 'lost' and so no history will be lost.
- $ git add .
Commit all the changes with the -a command. The -a command stands for all. It tells the commit command to automatically stage files that have been modified and deleted whilst new files that you have not told Git about are not affected.
- $ git commit -a
Finally, push the changes to your repo. You might see a prompt that asks for a merge message and in this case you will need to follow the additional steps below.
- $ git push

Additional steps to add a merge message:

You may receive the following git merge error message:

Please enter a commit message to explain why this merge is necessary, especially if it merges an updated upstream into a topic branch

To solve this:

Press “i”
Write your merge message
Press the “esc” key.
Type “:wq”
Then press enter

You will then to git push again and you're done!

A beginners explanation of the Chicago & London approaches

Hibo — Sun, 14 Jun 2020 13:17:57 +0000

Author clarification: It has since been revealed to me that the Chicago school of thought is actually called the Detroit school. Please use this term for any future references.

I recently received feedback from a code review that my TDD approach may benefit from using the London school of thought approach vs. the Chicago school of thought approach. And my initial reaction was one of confusion...

There are different methods to approaching TDD tests? And what are the Chicago and London school approaches?

So, I decided to research these approaches over the weekend and share what I understood in case it is helpful for anyone out there.

Let’s start with the Chicago approach.

Chicago School of Thought TDD (Inside Out/Bottom Up/Classic)

This approach starts at the unit testing level and allows the developer to focus on one thing at a time. In particular, it focuses on filling in the detail for a particular feature, before moving onto the next.

An example of this approach came to mind when I was building a bowling scorecard program a couple weeks back.

I approached this project by testing and building a 'Game' class that focused on keeping track of the game (i.e. the frame and rolls a player was on, the game ending etc...) and then I moved onto testing and building the 'Scorecard' class that would calculate the score.

After all the unit testing was done, I moved onto feature testing and building the front-end interface where this information would be displayed to the player and ultimately where the player would play the game.

This is a Chicago approach to building the program as:

It focuses on building the program from the component/class level level upwards.
It focuses on state based testing, seeing through the testing of one class and its behaviour at a time.

London School of Thought TDD (Outside In /Top Down/ Mockist)

You might have guessed this but the London School of Thought is essentially the opposite of the Chicago approach.

This approach starts at the outer, feature layer of the program and slowly moves into testing the centre layer of the program (i.e. the unit tests for the components).

So rethinking my approach to the bowling scorecard program, I would start with feature tests, planning how the interface would look to the user and how the user would interact with it before moving onto the unit tests.

And admittedly, this is a little weird to me. Why would you start implementing feature tests without having any of the components you would need to create it (i.e. the game and scorecard objects)?

Well this is where mocking comes in which is a more crucial part of the London based approach (but still can be used in both!).

Let’s say my page would display the frame and roll the player was on, as well as the current score. In order to test that this information is displayed, I would need to mock the classes and return some test data that I would feature test is displayed on the web page.

For example, let’s say the page starts with a frame of 1, roll of 1 and score of 0. The player then rolls a 5 and I would want my web page to display that they are on their next roll with a score of 5. (i.e. Frame: 1, Roll: 2, Score: 5). And this is what I would feature test using mocks and stubs to return the fake data in place of the real data that I would receive had I implemented the classes and methods beforehand.

Once that feature test is done, I can unit test scorecard and game classes to replace those mocks and return real data.

The London School approach:

focuses on building the program from the outside, feature level moving into the inner level.
leaves the actual implementation of the classes until last

Ending remarks

I hope this article was useful to get an introduction to Chicago and London approaches to TDD. There is a lot that I haven’t mentioned here to keep it as simple as possible (and also as I'm still learning about the approaches), but I will leave some resources that I found useful along the way if you are interested in learning more: