DEV Community: Vlad Dubrovskis

When you encounter hard to understand code

Vlad Dubrovskis — Sun, 20 Sep 2020 17:01:00 +0000

YouTube:

Trying something different on this occasion, some video content 😱🤞

Recently have rejoined a company where I have worked in the past and this reflects my experiences quite accurately 😁

Has something like this ever happen to you?

Introduction to Practical Test-Driven Development with JavaScript for beginners

Vlad Dubrovskis — Fri, 24 Apr 2020 12:18:44 +0000

The idea behind Test-Driven Development (TDD) is that you always write your tests first instead of leaving it until the end of a coding task.

It helps you to think and decide on how your piece of software will behave before you write it, which helps you stay laser-focused on the task at hand and not let the mind wander off and invent some big wonderful solution. Once you are done with your piece of software you are working on, the best part is you automatically have got some level of test coverage. Although this in itself is not an answer to all of the testing requirements your system may need, it provides quite a good starting point.

Test-Driven Development is a very powerful tool in the arsenal of a developer. We will try to learn and understand it using the basics of JavaScript without the world of NodeJS or npm.

Instead, we are going to use good plain JavaScript and something like JSBin

Test Driven Development: Why do it?

Quality

One of the main reasons to write tests is to increase the quality of the software you are writing. TDD makes you think about how the code can be used and how it should behave in different scenarios based on different inputs which should lead to a lower number of bugs in code.

Helps document code

Tests can be a great way to document an intent behind the code and will help new developers get on board with the code a lot faster as well as allow them to change it with confidence.

Helps produce cleaner code

As the tests are not an after-thought but more of a first-class citizen it becomes harder to over-engineer a solution and mix concerns. This is all due to the simplicity of the rules and focus.

Enables refactoring

When you have tests in place they give you confidence to change implementation details safe in the know that the tests will tell when you are about to break something.

Test Driven Development: What is it?

Test-Driven Development is a practice that helps you navigate a problem and come its solution using code.

The workflow is the following:

Write a test - Red (write an assertion that will fail)
Make it pass - Green (write some code to pass the assertion)
Refactor the code - Refactor (change the code you are testing without changing behaviour)
Repeat until done

You will often hear people refer to it as:

Red -> Green -> Refactor -> Repeat

It is that simple in its core. So to get our head into the right headspace let's dive into an example.

Test-Driven Development: Practice

Now we are going to dive into some practice, and the task at hand is the following:

Write a function that returns a sum of numbers passed to it

As we learned so far, the first thing we have to do is write a failing test. Just before we do that we need to understand what "test" means and how it works.

How the code is tested

So what happens when we run a test?

When a test is running, it will execute a piece of code, capture the output, and will verify that the output is equal to what it is expected to be.

When the result meets the expectation, it is marked as green or passing.

When the result does not meet the expectation, it fails and it is marked as red or failing.

The code that is testing our code needs to know 3 things:

Test description - to communicate intent
Expected result
Result of executing our code

And at the very basic level that is all there is to a test. Now to help us remember this we will write the test function that we will use going forward in this tutorial to test the code we will write.

Code to test code

function test(description, expectedResult, result)

Now we need to make that function tell us if our expectation matched the result or if it failed.

function test(description, expectedResult, result) {
  if(expectedResult === result) {
    console.log(`${description} passed`);
  } else {
    console.log(`${description} failed. Expected ${result} to be ${expectedResult}`);
  }
}

Check the test can fail

First, let's write something that is a "Red" or failing test:

test('result is 2', 2, 3);
// description: result is 2
// expectedResult: 2
// result: 3
// Output: result is 2 failed. Expected 3 to be 2

Test can succeed

Now let us write a "Green" or passing test:

test('result is 2', 2, 2);
// description: result is 2
// expectedResult: 2
// result: 2
// Output: result is 2 passed

As you can see we now have a simple test function that can validate if the result was what we expected it to be, and if it fails, also tells us what the outcome was meant to be.

Now that we have a function that can test our code, let's get back to our task at hand.

Test Driven Development Practice

As mentioned earlier the requirement we have is the following:

Write a function that returns a sum of numbers passed to it

First failing test: sum of 2 and 2

As per TDD rules, let's write our first failing test. Let's say because we need to return a sum of the numbers we are going to call our function sum

test('sum of following numbers: "2,2" is 4', 4, sum(2, 2));
// Output: Uncaught ReferenceError: sum is not defined

Make it pass

This is a great start, we have our first test and what it is telling us is that we are trying to call sum but it is not defined. Let's go and define it.

function sum() {}

If we try and run all of this code now the outcome will be different:

test('sum of following numbers: "2,2" is 4', 4, sum(2, 2));
// sum of following numbers: "2,2" is 4 failed. Expected undefined to be 4

At this point, you may be tempted to go ahead and implement the function parameters and add them up, but that is not what we are going to do.

What we need to do instead is to write the minimum amount of code to make the test pass. And at this point, the code does not have to be pretty.

So what we are going to do is update our function to just return 4:

function sum() { return 4; }

When we run our test now it will say the following

test('sum of following numbers: "2,2" is 4', 4, sum(2, 2));
// sum of following numbers: "2,2" is 4 passed

This is great, we have our test passing, but we are not done just yet. We know the code is only good to handle the sums where it comes to 4.

Next failing test: sum of 2 and 3

So let's write the next test where the result is something but 4.

test('sum of following numbers: "2,3" is 5', 5, sum(2, 2));
// output: sum of following numbers: "2,3" is 5 failed. Expected 4 to be 5

Making second test pass

We have a new failing test. Now in order to make this pass, we have to update the sum to take in some parameters and add them up for us.

function sum(number1, number2) { 
  return number1 + number2; 
}

Run the test again:

test('sum of following numbers: "2,3" is 5', 5, sum(2, 2));
// Output: sum of following numbers: "2,3" is 5 passed

Where are we so far

Wonderful! We have 2 passing tests now! The code we have written so far should look something like this.

function test(description, expectedResult, result) {
  if(expectedResult === result) {
    console.log(`${description} passed`);
  } else {
    console.log(`${description} failed. Expected ${result} to be ${expectedResult}`);
  }
}

function sum(number1, number2) { 
  return number1 + number2; 
}

test('sum of following numbers: "2,2" is 4', 4, sum(2, 2));
test('sum of following numbers: "2,3" is 5', 5, sum(2, 3));
// Output: sum of following numbers: "2,2" is 4 passed
// Output: sum of following numbers: "2,3" is 5 passed

You can play around with this code on JSBin: https://jsbin.com/yahubukane/edit?js,console

Next test: sum of more than two numbers

However, what happens if I pass more than two numbers? Remember we did not specify how many numbers we need to sum, we may need to sum more than two. With this said let's go ahead and write a test where we pass three numbers to the function.

test('sum of following numbers: "1,2,3" is 6', 6, sum(1, 2, 3));
// Output: sum of following numbers: "1,2,3" is 6 failed. Expected 3 to be 6

Working out how to access all function parameters

So how can we make the next piece work? The number of parameters can be anything, so passing a bunch of named arguments is not going to work. Well, you could add 100+ of them but that code would be quite hard to follow.
Luckily in JavaScript, a function has access to all the arguments that have been passed to it, even if they were not named (see Function arguments).

If you open that link and read, you will see that the arguments inside a function is an Array-like parameter that does not support any array methods or properties apart from length. As we can be sure we will need to iterate on the values in some form, a real array could be quite useful.
Luckily for us, there is a piece of code on that page that tells how to convert the arguments to a real Array.

const args = Array.prototype.slice.call(arguments);

Let's add this to our sum function and remove the named parameters:

function sum() { 
  const args = Array.prototype.slice.call(arguments);
  return args;  
}

If we run all our tests now we will see that they all fail:

test('sum of following numbers: "2,2" is 4', 4, sum(2, 2));
test('sum of following numbers: "2,3" is 5', 5, sum(2, 3));
test('sum of following numbers: "1,2,3" is 6', 6, sum(1, 2, 3));
// Output: sum of following numbers: "2,2" is 4 failed. Expected 2,2 to be 4
// Output: sum of following numbers: "2,3" is 5 failed. Expected 2,3 to be 5
// Output: sum of following numbers: "1,2,3" is 6 failed. Expected 1,2,3 to be 6

Now although we do not have the right result yet, we can see that we get back an array of parameters, which is a step in the right direction. What we need to do now is to find a way to sum up all numbers in an array.
As we have now converted our parameters to an array, we can use forEach to iterate.

Let's update our code:

function sum() { 
  let result = 0;
  const args = Array.prototype.slice.call(arguments);
  args.forEach(function(num) {
    result = result + num;
  });
  return result;  
}

Now let's run our tests one more time:

test('sum of following numbers: "2,2" is 4', 4, sum(2, 2));
test('sum of following numbers: "2,3" is 5', 5, sum(2, 3));
test('sum of following numbers: "1,2,3" is 6', 6, sum(1, 2, 3));
// Output: sum of following numbers: "2,2" is 4 passed
// Output: sum of following numbers: "2,3" is 5 passed
// Output: sum of following numbers: "1,2,3" is 6 passed

Testing edge cases

Now to be completely happy that we have done the right thing, let's try to add 2 more tests. One where we pass only a single number. And another one where we pass let's say... 7 numbers. Something that covers a case for a single number and a lot of numbers.

test('sum of following numbers: "1" is 1', 1, sum(1));
test('sum of following numbers: "1,2,3,4,5,6,7" is 28', 28, sum(1,2,3,4,5,6,7));
// Output: sum of following numbers: "1" is 1 passed
// Output: sum of following numbers: "1,2,3,4,5,6,7" is 28 passed

One more edge case we could test is what would happen if you would pass no numbers at all?
How would you do that? In theory, the total number of no numbers is equal to 0
So we can go ahead and write the following test:

test('sum of following numbers: "" is 0', 0, sum());
// Output: sum of following numbers: "" is 0 passed

Refactoring

Now comes the best part of Test-Driven Development. We have our function, we have our tests, but we want to update the code to use ES6 syntax like all the cool kids.
On the arguments documentation, it suggests that to access arguments in ES6 we can use rest parameters.
Let's go ahead and do that.

function sum(...args) { 
  let result = 0;
  args.forEach((num) => {
    result = result + num;
  });
  return result;  
}

Run all the tests:

test('sum of following numbers: "2,2" is 4', 4, sum(2, 2));
test('sum of following numbers: "2,3" is 5', 5, sum(2, 3));
test('sum of following numbers: "1,2,3" is 6', 6, sum(1, 2, 3));
test('sum of following numbers: "" is 0', 0, sum());
test('sum of following numbers: "1" is 1', 1, sum(1));
test('sum of following numbers: "1,2,3,4,5,6,7" is 28', 28, sum(1,2,3,4,5,6,7));
// Output: sum of following numbers: "2,2" is 4 passed
// Output: sum of following numbers: "2,3" is 5 passed
// Output: sum of following numbers: "1,2,3" is 6 passed
// Output: sum of following numbers: "" is 0 passed
// Output: sum of following numbers: "1" is 1 passed
// Output: sum of following numbers: "1,2,3,4,5,6,7" is 28 passed

All the tests are green! That was nice, we updated our code syntax and still know that the code behaves the same as before.

Now, finally, curiosity has taken over and we decide to turn to StackOverflow to tell us about how to sum numbers in an array in Javascript:

StackOverflow - How to find the sum of an array of numbers

Let's go ahead and update our function with the suggested answer implementation using Array.reduce
(Interesting that an example of summing numbers can be seen implemented here too: Function rest parameters)

const sum = (...args) => args.reduce(
  (accumulator, currentValue) => accumulator + currentValue, 0
);

And run tests one more time:

test('sum of following numbers: "2,2" is 4', 4, sum(2, 2));
test('sum of following numbers: "2,3" is 5', 5, sum(2, 3));
test('sum of following numbers: "1,2,3" is 6', 6, sum(1, 2, 3));
test('sum of following numbers: "" is 0', 0, sum());
test('sum of following numbers: "1" is 1', 1, sum(1));
test('sum of following numbers: "1,2,3,4,5,6,7" is 28', 28, sum(1,2,3,4,5,6,7));
// Output: sum of following numbers: "2,2" is 4 passed
// Output: sum of following numbers: "2,3" is 5 passed
// Output: sum of following numbers: "1,2,3" is 6 passed
// Output: sum of following numbers: "" is 0 passed
// Output: sum of following numbers: "1" is 1 passed
// Output: sum of following numbers: "1,2,3,4,5,6,7" is 28 passed

The final outcome of our exercise can be found here: https://jsbin.com/vakikudomu/1/edit?js,console

As you can see we can make changes to our code and be confident that it still works the way we intended it to in the first place.
Arguably the readability of the final example is not as good, but the main point here is that we can change code confidently!

Homework

Before we part:

Think of other examples that we may have missed.
Think about how you would approach a scenario where the inputs can contain letters or strings and not just numbers.

Caring for future developers

Vlad Dubrovskis — Mon, 06 Apr 2020 13:03:54 +0000

Picture this: You join a new team and you start to get to know the codebase. After some time you see some suggestions you would like to make to the system and some of the design principles make no sense at all.

You bring this up to your teammates and eventually get shot down with some generic phrases like, “it just works this way” or “we have looked at it before and it’s very difficult”. Maybe someone has implemented it a while ago, left the company and no one is brave enough to try and change it.

It seems like nobody quite knows why things are a certain way, but there is a reason.

Or in another scenario when you suggest improvements to the design people say that they have tried it already, it was hard, and it did not work so there’s no point wasting time on it again.

Have you ever found yourself in such situations? I would be surprised and somewhat jealous if you are a software developer and the answer is no.

Unfortunately, there is no easy way to get those historical answers. For the first scenario, your best bet is version control history, but even then trying to find answers may prove to be a challenge as this will depend on a number of factors. One of them being how well people communicated their intentions in their commit messages. Also, I have seen first-hand a migration of repository with all history lost.

There are plenty of things we can try and do to help our future self and future software engineers that will have to maintain the code we have written and systems we have designed. Let’s take a look.

Commit messages

Your commit messages are probably the most basic way to provide extra context as to why the code has changed and what you are trying to achieve with it. Most importantly, try to commit a little and often, which helps the reviewer understand the thinking process behind the change.

This is just an opinion but ideally, I would not squash my commits when merging pull requests. Mainly to have better historical reasoning as mentioned in the previous paragraph.

Most importantly try and make sure your commit messages are meaningful and useful. It is not an easy task and you may find it difficult at times, but like with most things the more you practice the easier it becomes.

Change-logs 

Change-logs are great as they provide history in one wonderful document. There are numerous ways to automate them. Ideally you want this automated but there is nothing wrong with doing it manually if it makes sense to your team. It is highly likely at some point someone will get fed up with the manual task and automate it anyway.

One of the techniques you could do is use something like Conventional Commits to help you automate the process. Even if initially developers may find it frustrating, I would suggest that this helps them write better commit messages as it enforces some guidelines in doing it.

Now you don’t have to use conventional commits or follow semantic versioning as there are other ways to achieve the same result. Having an easy to access human-readable document with some sort of versioning can prove to be very useful especially when it comes to supporting your application in production and you need to easily understand what changes are live in front of your users.

Documentation

You have to write documentation no matter your personal preferences, as the reason you do it is not for yourself but for other people. In the case with documentation, there are always at least two consumers of that documentation: The developers that may contribute to the codebase and may need some information around how the project is set up, and the consumers of your application or API.

Common topics to include in the documentation are things like: How to configure the application, what APIs does it provide, examples of how it can be configured, and most importantly examples of how can you test it if it’s relevant. The content and the shape your documentation will take will depend on the target reader, so you may need to provide two or more sets aimed at different audiences. Think how Facebook provides help pages for regular users and a whole separate site for developers. This of course all depends on the scale of your application.

Avoid putting low-level or implementation details in the documentation. Similarly to how you would not test implementation details in your tests as these can change and become obsolete.

Developer experience 

This is a somewhat hot topic that is coming up more often where people finally realise that developers are also human beings that have a need for a good experience when using all sorts of tools for their job.

When it comes to developer experience, documentation is a big part of it. However, an often overlooked way to provide a good developer experience is to help and navigate the developer on the right path using meaningful error messages, examples and links to other relevant pieces of information in those error messages.

For documentation, think about examples like BrowserStack or Sentry that provide snippets with your secrets embedded into them when you are logged in to the website, so all you have to do is copy and paste it across. This saves an action and has always put a smile on my face and made me notice that extra little help.

When it comes to errors or warnings, do not just leave cryptic messages and instead spend some effort and give suggestions as to why things may not be working. A good example is the React team that have done a really good job with these over the last few years.

Good user experience is something that is widely accepted as a given these days. When it comes to developers the experience they have using your platform, API, module or any other piece of software can make a huge difference and most importantly may make life easier for new developers that come to our industry.

Decision logs

Something I have started doing recently, over the course of the last few years, is write decision logs when we are choosing something that we think someone may question in the future. For example, what state management library or front-end framework to use and why.

You have to add a list of pros and cons for each of the options considered. Also if anything was not a consideration ideally have a part that explains why.

Crucially this document needs to have a date of when this was written so that future teams can easily understand why things were done and when. For example, some show stoppers may have been resolved by the time a new member of the team has joined and it makes sense to actually move to another state management or testing library.  In terms of where to keep this document I would suggest in your Wiki or your repository. Anything relating to specific code should live closer to it. Alternatively, you could have them in Confluence decision logs, it all depends on what works best for your team.

Diagrams

This may be a personal bias creeping in but I love diagrams. Nothing helps me understand how the system interacts better than pictures that explain how requests flow through your system.

Keep this someplace where you can version it so you can see the evolution of the system. Version numbers are good but things like dates are really important too.

Be kind to people who will be there after you

In summary, you have to create some sort of documentation and historical audit trail for future teams. As well as spend some effort in helping any developers who will be working on the code after you have long left the company. You may not witness this directly but I am sure it will make some developer pretty happy someday.

Now I am not suggesting for you to necessarily do all the things I have mentioned, as it may not always make sense due to the size of the project and other factors, but at least try and do some of them.  Unfortunately, there is little accountability in our industry. I have to work on some projects that were neglected and had to spend days and weeks working things out. Let’s try and be kinder to one another and to future developers.

My two parting thoughts that I think will help teach a little bit of empathy for those who have made decisions before us are:

“Always assume best intentions”

“Teams make decisions based on the best understanding they have at the time”

Cover photo by Juan Pablo Rodriguez

Continuous improvement and feedback loops

Vlad Dubrovskis — Mon, 09 Mar 2020 19:19:38 +0000

Do you ever wonder how anyone knows if what they are building is right, important or adds value to their customers? What about the companies that just starting, how do they know if what they will become will be a success? I don’t think anyone truly knows, or at least not at the beginning of the journey and even more so when you start doing something brand new. After all, if everything was that simple we would not know what “pivot” even means in the technology world.

So what is it that can help you understand your idea better and help and guide your way to success, or at least validate some of the assumptions and hypotheses you may have? In it’s purest form it’s quite simple:

“Build something - Measure it - Learn from it”

This feedback loop is the basic principle of how you can focus on the right things and course-correct as you move along. A lot of what we call agile boils down to it. You have to test your ideas out and get some quantified feedback that you can use to put forward a better idea or dismiss some of the other ones you may have had.

The problem is that this is a rather high-level feedback loop that does not provide us with much practical advice, and let’s be honest it’s not even groundbreaking.

However, if you start digging deeper into modern ways of working, you will find that there are a lot more types of feedback loops. What is more important is if you try and see the purpose they serve you may be able to advance them to serve you better.

So let’s have a look at the different types of feedback loops and how we can try and improve them, starting with the lowest level one.

Tests

Purpose: Code behaves as expected

Different types of tests give you different levels of feedback.

Unit - function behaves as expected
Integration - number of moving parts interacting and behaving as expected
End-to-end - the system as a whole is behaving as expected

How can we make it better?

As long as you are doing some sort of testing you are probably on the right track. Regardless of the level of tests you are writing remember to always test the behaviour and not implementation. If you test implementation this may stop you from refactoring effectively. How do you know if you are testing implementation? Do you have an assertion where a function has called another function with specific parameters? Try and avoid tests like this if possible.

When it comes to test-driven development on unit-level only, it is not a testing strategy, it is a tool that helps you stay laser-focused and navigate the problem in bite-sized chunks.

Speaking of higher-level tests, especially end-to-end tests it is a universal understanding that they are slow to run, but in modern-day technology, you can run them in parallel which can marginally reduce the run time and the feedback loop for you.

Finally, when you run your top-level tests, always run these against a deployed environment, ideally a copy of production or as close as possible. The main reason for this is if you skip certain steps in your infrastructure (for example API Gateway, some proxy or another part of infrastructure) you may let some bugs slip through that could have been avoided.

Your main aim is to have confidence that everything will work fine if your tests tell complete with no failures.

Standup

Purpose: This is how I and everyone else on the team is getting on with their current work

Daily progress feedback usually in the form of an early morning meeting to make sure that things are progressing along well without any issues or blockers.

How can we make it better?

Did you notice how this usually turns into a list of justifications for your existence on the team? If not I am truly happy for you.

The idea of talking about blockers and progress once a day is inefficient and I am pretty sure that the majority of people should and would raise those issues as soon as they occur. You can notify people of changes and progress during the day too without having to wait a whole night for it.

Refinement

Purpose: Purpose: Is the next set of stories in a good state and ready to be worked on

A refinement is usually happening on a scheduled basis to get together as a team or three amigos to refine a set of stories so they meet the definition of ready. This should allow the team to pick up the tickets and work on implementation.

How can we make it better?

Instead of scheduled refinement, get into the habit of doing it when needed with a few relevant people. Do the basics well, make sure it meets the definition of ready, that the required designs are linked, then let the teamwork out the details when they work on the feature. If someone has done a spike around some uncertainty help them create those stories and do not bring people that do not need to be there.
And remember: A story is a promise of a conversation, it should capture the problem, not the solution.

Demos

Purpose: Look what we have done and learned

Depending on how often you have your demos it is is a good opportunity to show off completed work and talk about the challenges and what you have learned. It creates group feedback and allows the sharing of experience that may help other teams learn along the way.

How can we make it better?

However often you do demos and how you approach them, there is always room for improvement. You can always demo smaller pieces even just with your product person or team as soon as you have done the feature. There is no need to wait a whole week as they may notice some flaws in it and provide immediate feedback.

Continuous Integration/Continuous Delivery/Continuous Deployment

Purpose: New code behaves and works with the rest of the system, code works in a deployed environment

Hopefully, the codebase is constantly changing, so you need to make sure the feature you have just completed does not break another feature or take the whole system down. If something does not work or the code has diverged it feeds back to the developer when things break and require their attention.

This makes sure the code behaves as expected in a deployed environment and is ready to be shipped to customers. If you are doing Continuous Delivery it may also provide feedback that the latest features are out for customers to enjoy.

How can we make it better?

A solid CI/CD pipeline requires a solid testing strategy for whatever that you are building. Following on the advice from the first section on tests, always think about how you can run the tests in a way that you prioritise the most important checkpoints first.
The order could be: Static analysis, unit tests, once the app or container is deployed hit a health-check endpoint, then end-to-end tests, etc. If the health check fails then there is no point in going further as something is wrong.

The more complex your system becomes the more tests you will have, and to have an efficient pipeline, you need to be able to run all sorts of tests fast. Keep track overtime on how long it takes to build, test and deploy. If the time is going up, have a look and review what is going on and see if you can drop some tests that may no longer be as valuable, or run more tests in parallel.

Finally, give continuous deployment a go. Until you have tried it you will not be able to fully appreciate how wonderful and liberating it is. Most importantly, having continuous delivery forces everyone to care about quality because to deploy on the merge of the code your quality and automation have to be solid.

Retrospective

Purpose: Team works

One of the more important feedback loops that highlight the team dynamics and shows how well everyone is doing together.

How can we make it better?

This is similar to demos in the sense that although the team should have a scheduled time for a collective reflection sometimes you should just raise issues as they occur. You may be able to resolve them before the retro even happens. If you wait weeks for a retrospective you may just forget something that may be truly important.

Customer

Purpose: Are your customers happy with the service and experience they receive?

Customer satisfaction feedback is a crucial feedback loop. When customers are not happy you need to address it and attempt to resolve the situation. I cannot stress this enough: You need to be able to speak to your customers and be able to have access to their feedback regularly.

How can we make it better?

Customer feedback is crucial! You may be lucky to have a good UX department that will do a great job and present findings on some weekly/bi-weekly schedule. However ask yourself - how accessible is all of the feedback that the company generates from users to anyone else within the company?

Is there a filter like a research team - do you need permission to access the raw research data? What happens if they make wrong assumptions? Try and make it easier for people to live and breathe the customer feedback. It should be accessible to everyone. People should be able to easily show interest and attend user interviews, review research outcomes and see direct user feedback. The latter can be implemented as a public Slack channel that has all of the feedback from the product automatically posted to it.

Velocity

Purpose: How quick team is going
This is feedback on how efficient your team is. It can also provide feedback on the team’s health. If the velocity drops there must be a reason: Impediments, people leaving, general low morale.

How can we make it better?

Every Scrum master’s dream is to quadruple the velocity of the team. Joking aside I think this metric is not useful. All it tells you in terms of numbers is how much work a team can do in an arbitrary amount of time.
What it does not tell you is what sort of value the team creates. What you should do instead is define and constantly measure better metrics that matter for each of the teams. An example of this can be: The amount of quality leads generated (that probably is better than just a sheer number).

Conclusion

The list of feedback loops could go on and you could include things like: Analytics, Monitoring tools, Log aggregators, etc. A lot of these are just patterns that I have noticed while working with some of the most performant teams in my career so far.

Remember that feedback loops are all around us and all too often we follow a recipe without questioning it. If you take a good look around and keep an eye open for opportunities to improve you may find some interesting ways of improving your team’s flow too.

Best of luck in your improvement and discovery endeavours and please do share your observations with me along the way.

How do you help your teams manage tech debt?

Vlad Dubrovskis — Sun, 23 Feb 2020 15:11:46 +0000

Does your team struggle with technical debt? Or are you always on top of it with the full support of the business?

Are you a leader/product person on the team? Do you help the team with keeping on top of things? Or does the tech debt take a back seat?

Tell me your stories/ideas and experiences.

One of the tips I have and use for teams that use estimation is the following:
If you know that there is tech debt that needs addressing as it has been slowing you down a lot, you can always increase your estimates to allow for that time. As in theory developers use estimates to communicate how long certain features will take, so use the tools available to you to communicate technical debt.

What is after being a senior developer?

Vlad Dubrovskis — Sun, 09 Feb 2020 16:05:41 +0000

Photo by Sara Kurfeß on Unsplash

I have been doing web development for the last... around 14 years. Have worked with a variety of technologies, companies, projects.

Last few years have been feeling that have reached some glass ceiling in being a developer and wanted to give it a go in more leadership position which I had a chance to do. Of course the challenges where different and at some point I have reverted back to being a developer as that is known and comfortable.

However now that I am back in developer shoes realise that I want to have a wider impact than just an individual contributor and to a degree all development works feels very much the same.

What was your path after being senior developer? Tech lead? Development manager? Head of engineering? Tell me about it and how you got there. Also any advice is appreciated.

I love tech, good practices and thing that makes me the happiest is when the teams work well together, achieving goals, shipping features, support and perform well together.

I need to think about some next steps in my career and feeling a little lost.

Switching career to software development

Vlad Dubrovskis — Thu, 30 Jan 2020 19:18:38 +0000

Cover image by Biao Xie on Unsplash

I originally wanted to get some extra input from wider audiences and reached out on Twitter, LinkedIn and even here. But did not get any extra replies.

Switching careers to Software Development

Vlad Dubrovskis ・ Jan 29 ・ 1 min read

#career #discuss #advice #switchingcareers

I am posting an article I published originally on my site - but it first came about as email to someone who asked me for that advice.
I believe this may help someone out there.

I am a software engineer working with web technologies for a good chunk of my life. Recently I have been approached for some advice about switching career to software development.

Firstly it is worth mentioning that the software world is vast: Web, mobile applications, data, AI, etc. this article is not aimed at providing advice on which specialty to go down, this is for you to decide personally.
The following advice is meant to be generic but is heavily influenced by my work with web development.

Persevere

This is probably the most important piece of advice.

When you start on this wonderful journey you may find yourself feeling silly, or not good enough, or that you just don't get it, this is just anxiety setting in. Remember this is a natural reaction to being outside of your comfort zone. I cannot tell you how many times I experienced this, feeling stupid until it clicks. Panic is over and life goes on. Some things that I would consider basic now would throw me into a child-like behaviour when I was first starting.

Just stick at it and it will become easier. You got this!

Different ways of learning to code

One of the things to consider is to look back and think about what learning approach works best for you.
Do you prefer being in a class environment or would you rather be on your own doing the research, watching videos and trying to write the code.

The ideal scenario is of course both. Having a teacher or mentor may aid the learning but you will have to put in the practice outside the class.

Class Environment

Classes may be more expensive but you reap the benefits when you are in a class with a teacher - some research into some local courses in your area may be beneficial.

Have a look at local colleges or even universities that offer courses that may last a year (my wife took one for her Masters degree when she decided to switch from the field of law).

You may find smaller courses that teach you the basics that may set you on the right path.

And of course there are Code Academies that promise to help you take the first steps in the software development world. It normally involves an intensive course followed by a project, then they help you find your first entry level job. I am not specifically advocating for this and you will have to do your own research - but I have worked with some very talented people that were graduates of such programmes (UK specifically).

The course you may choose will depend on your financial situation - even those courses that allow you to pay the fees once you find your first job - be careful and think hard before you commit. I was in a similar situation with my student loan. It wasn’t until the monthly repayments starting coming out that I realised what a large chunk of my pay check was being taken.

If you decide to go for a course, it is worth looking on LinkedIn or other similar platforms to find graduates of such courses and reach out to them. They will have been in a similar situation regarding their career so they may provide some useful insights.

Finally there are meet-ups that help people learn. One of such gatherings is CodeBar. Check out the events page to see if there is one near you or there may be alternatives with similar idea behind.

Online Courses

This section is useful regardless if you decide to go down the course path. As mentioned earlier, you will have to put in the effort and practice. As a developer, being able to learn and find the information online will come in handy in the long run.

The following is a list of resources I use to keep up with new trends and frameworks. Some have video courses aimed at different levels.

Egghead - web technologies - - a lot of courses on all things web. React, Vue, TypeScript, Node, etc.
Udemy - courses on all sorts of topics. They often have promotions on and may even have promo codes out there? If you are just getting into this - those codes may come in really useful.
A Cloud Guru - everything AWS and Cloud related -
Dev.To community
- Dev.To - Posts aimed at beginners
- Dev.to - Explain like I am five
FunFunFunction on Youtube
FreeCodeCamp
And many more out there on either YouTube or your favourite search engine.

Creating your own personal website

Creating your own website is perfect as you can write about what you learn on it and also test out any new skills you acquire. It will force you to learn how to: Buy a domain name, build a website, deploy, host a website and create content, amongst other things. This will also give you a chance to try out different hosting platforms.

When you have a website there is always a project on your hands. You will always find ways to make things better or opportunities to learn new techniques and try them out. It’s like a builder’s house - never finished.

Do not work for free or exposure

You will always come across people who will need a website or an app and will ask you to do something for a very low price or even free. They will promise that they know other people who they can introduce you to. Myself and my fellow peers never got introduced to anyone or benefited from this.

Exposure is tempting and it seems to makes sense, but always be reminded of this:

Source: The Oatmeal

Transferable skills from your previous career

This one is probably applicable further down the line when you’re looking for your first job in software development. Think about the skills you have from your previous career and work experience and see how they can be transferable. For example, if you worked in the service industry your people skills most likely deserve a medal. This can be a separate topic on its own but remember do not dismiss your previous experience.

The web development path

Finally if you choose to go down the web development path, my advice would be to learn the basics of this as it will help you grasp other development concepts. This is not a requirement but it helped me in my career. The basics are:

HTML
CSS
JavaScript - pure Javascript as opposed to frameworks like React etc. This will cover the basics: How to write simple logic, how to manipulate data, how to access and manipulate the DOM (Document Object Model - I know this sounds scary, but really once it clicks, it's not that bad) and how to get data from a server or submit a form.

After you get the basics from the above I’d then recommend learning JavaScript frameworks and libraries: React or Vue (these are most in demand)

And finally once you get a better grasp of all that, look into Web servers such as NodeJS (JavaScript for server side). Other languages are available, but if you already learning JavaScript this will help you with learning the concepts for server side development.

Final thoughts

Changing careers may seem daunting but there are more and more people taking the plunge and finding satisfaction in their new career in development. It gives you a chance to work for all sorts of industries, for example, publishing, streaming, journalism, sports, travel, fashion, property etc. Just make informed decisions based on your situation and your best way of learning. Persevere. You will get there!

Switching careers to Software Development

Vlad Dubrovskis — Wed, 29 Jan 2020 20:46:46 +0000

Recently I have been approached for some advice about switching career to software development.
I have come up with a list of suggestions, but thought it is worth tapping into collective thinking.

If someone would approach you, what would you say?

Where to start?
Which part of software industry to get to? Web, Apps, AI, Data?
What is a good starting point for each of those starting points?
What advice would you give to people thinking of changing their careers to software development?
Meet-ups for newbies?
Codebar? https://codebar.io/ Any alternatives or more meet ups with similar goals?
Coding academy? This is quite a big financial investment that may not be affordable by many
Mentorship?
University? College?
What else?

What would your advice be to someone who is coming from a different career? Anything goes.

Test Driven Development - not Unit Test Driven Development

Vlad Dubrovskis — Sat, 25 Jan 2020 19:42:45 +0000

A lot of us in software development would have heard of Test Driven Development. Some swear by it - some hate it and say it is fully unnecessary.

In my opinion people often attribute TDD to the following:

Write unit test -> Red -> Write code to make it pass -> Green -> Refactor

Now although this is one of the approaches that is very common I think the focus is too often given to the lowest level of testing: “unit”.

The practice is called Test Driven Development and not Unit Test Driven Development and a more accurate and common example of flow is:

Test case -> Red -> Write code -> Green -> Refactor

Unit tests are a wonderful technique in our toolbox to help us navigate the problem and keep us laser-focused, but it’s not an antidote to all coding problems. Sometimes in smaller pieces of software it is a lot more valuable and straight forward to write an Integration test first or even an end-to-end test.

Example: In AWS Lambda it is easier to have an end-to-end test that will not only test the result of the function but can catch any permission issues, this is a more likely scenario of something going wrong in AWS world :)

Of course you could argue that what I am describing is Acceptance Test Driven Development (ATDD) - and you would be right. But my main point I am trying to put across: Unit tests are useful when you break down bigger pieces of problem to help find a solution, but at some point the higher level tests are more useful - especially on smaller codebases. For example a small service.

To do Test Driven Development you don’t have to concentrate on “unit” as long as you understand the trade-offs that come with it, for example, less granular feedback of test cases and risk of over-engineering a solution.

One thing for sure: quality and tests are important. Make sure that whatever you do it helps you deploy your code with confidence.

My view on roadmaps

Vlad Dubrovskis — Sat, 18 Jan 2020 14:51:50 +0000

I have been a software developer for a good chunk of my life. And as I have progressed in my career and started working for bigger companies - trying to tackle bigger challenges - one thing that sprung into my world was roadmaps.

In the past I was one of the people who would always ask for and on some degree even advocate on getting a roadmap. Main reason was to understand what work was coming up - and often would get back a plan for next 12 months. Sometimes even longer.

How it usually goes

First - myself and the team would get excited - there is clarity,a plan - and sooo much work to do and so many challenges to face.

Yay! Roadmaps!

However about 2 months down the line it becomes apparent that the roadmap is hardly fit for purpose anymore - the world has moved on - priorities have changed.

Dammit! Why do you have to change?

This often would lead to very frustrated teams - which somehow made it feel a lot more annoying and a lot worse that it really was.

Today

These days I am not a big fan of roadmaps anymore. I believe if you want to be quite competitive and do the right thing - you cannot plan too far ahead. Just focus on the next most important thing.

You may be wondering how then the team aligns then on priorities - and I would suggest that team mission would serve you better than any roadmap.

At the end of each sprint/feature/goal - reflect on what you learn and see what is the next most important thing.

Why most roadmaps are not useful

In my opinion it is because majority of them are just Gantt charts under a mask. A lot of them have dates and expectations - and reality is that as soon as you slot something else in - all of your dates go out of the window.

Unfortunately the dates are never truly meaningful and things get pushed back further and further.

In more extreme cases you also end up moving your whole roadmap to your ticketing system and pollute backlog with stories that will never get implemented - or create a backlog that would take the team year(s) to complete. That in turn creates even more waste of time for the teams.

Is all is lost?

When I brought this subject up with colleagues and in my network - although few voices shared my concerns, one person has suggested to use something called "Now, Next, Later".

Now, Next, Later

As simple as it is named, the principles for what they are can be summarised in the following way:

Now

Tasks that need your attention right now. There may be quite a few items here, maybe a scope of larger feature spanning a number of weeks - but one thing sure - you have to work on it right now.

Tasks that may need some final refinement before they are ready to be move to the Now area.

Refined ideas and requirements that come from user and market research that you will be working on whenever things in Now are done. Or just think of these as tasks that need some final touches before they require immediate attention.

Later

This may be fresh ideas that need a lot more refinement - think of a fresh idea that needs some validation beforehand, maybe some research done ahead of time. Maybe they will never even make it to the Next bucket.

And that is it. It creates a wonderful flow that should be constantly changing.

Video explanation

One of the things that I been reminder recently is that different people may learn new information better if it is presented in a different format. So here is a short video I found explaining the concept:

One more tip

In conversation with my fellow colleagues a good point came up around dates and roadmaps that I thought is definitely worth sharing.

You might need a roadmap for things that you MUST do at a certain point such as:

legal requirements (example: cookie banner, GDPR changes)
maybe a feature is crucial to reach market before some big promotion for season sales
I struggle to think of more examples but hopefully you get the gist.

Final words

If you see or learn some amazing opportunity for your product - take it and run with it.

The software and product landscape is changing rapidly - you have to be able to move fast too.

The post originally published on my personal blog: Digital Roast - My view on Roadmaps

Simple truths: Sustainable pace

Vlad Dubrovskis — Sat, 11 Jan 2020 14:02:52 +0000

Feel like now we are in the first week of the year and the reality may be settling in after the holiday season - and maybe you like myself find yourself a little down.

You may also be a little disappointed with yourself - as you had great plans for this year and yet somehow managed to start failing in some of the goals you have set yourself.

One of the crucial pieces of advice I would give to anyone is - whatever you do, always think about how sustainable is the pace at which you are moving. This applies not only individuals - but to software teams too.

It is better to work out a pace that will last - rather than go all out and burn out after a few weeks or months.

And by all means - do dream big - just start with smaller, achievable, realistic steps.

Do you want to learn new language? Why not start by watching some video tutorials?

You want to write more blog posts? Start with writing one a month. Or just writing a paragraph every few days.

And most importantly - for anyone who needs to read/hear this: you can achieve your goals if you stick at it. I believe in you! :)

P.S. This was meant to be a very short piece of writing, no longer than 2 paragraphs wrong - but I got a little carried away :)

Cover Image Source: Photo by Hope House Press - Leather Diary Studio on Unsplash