DEV Community: Kalarani Lakshmanan

Crossing the chasm with Copilot

Kalarani Lakshmanan — Tue, 27 Jun 2023 14:41:17 +0000

I've observed a lot of folks (including me) struggle in our initial attempts to get copilot write the code we want. The common entry barrier in such cases, is "prompting".

With all the attention prompt engineering is getting in recent times, developers tend to think,

"How do I come up with the most effective prompt, that'd make copilot write the code that I have in mind?"

As it turns out, arriving at the right prompt, in itself, is an iterative process. So, you're ~~never going to get the prompt right in first place~~ always going to take a few attempts before copilot spits out the code you expected.

I think, we should simply take all this fuzz about prompt engineering (for copilot) out of our heads and just keep coding. Copilot will tag along with you. You don't have to think about the prompt that you'd need to write. Just focus on what you need to build.

I've found working with copilot in this mode more useful than prompting it to generate code, for two reasons:

1) When you prompt, copilot may generate a code that may not necessarily fit into your style of coding. Every developer has their own style of coding and it is as unique as their signature.
2) When you prompt, it takes significant amount of time in reviewing the code, since you are not yet in the coding mode. This is a subtle difference and takes a hit on developer experience.

Without prompting, It just feels like working with an invisible pair. Just that the pair often hogs the keyboard and completes the code before you could :) . It definitely made me go faster than I would've done it myself.

In this mode, you are always on the flow. You don't get into the prompt - review - accept / reject cycle. You keep churning the code out, copilot comes along with its suggestions, which you take less time to accept / reject since you are already neck deep into it.

In my opinion, while I was in the prompt - review - accept / reject cycle, copilot was taking a lot of focus away from the thing being built. Without prompting, copilot became a trusted ally and helped me build what I wanted, the product remained in the primary focus. And that's what a great tool does.

To sum it up, a tool doesn't need to do great things. It just need to do simple and useful things. In that aspect, I must admit that copilot is a really good tool to have in a dev's toolkit.

Paradigm shift: Immutability in Elixir

Kalarani Lakshmanan — Mon, 19 Jun 2023 04:31:47 +0000

I spent this weekend by writing an Elixir script to solve the Linear Regression problem. And then when I went on to implement Gradient descent to train the model, I hit a road block.

I came up with this code, which looked perfect to me, just that it didn't work. It didn't do what I expected this to do.

  def train_from(filename) do
    raw_dataset = read_dataset(filename)
    x = raw_dataset |> Enum.map(fn d -> elem(Integer.parse(Enum.at(d, 0)),0) end)
    y = raw_dataset |> Enum.map(fn d -> elem(Float.parse(Enum.at(d, 1)),0) end)
    training_dataset = %{x: x, y: y}
    w = 100
    b = 100

    for n <- 1..5 do
      IO.inspect("Iteration #{n}: #{w}, #{b}")
      [w, b] = gradient_descent_step(x, y, w, b)
      IO.inspect("End of Iteration #{n}: #{w}, #{b}")
    end

    IO.inspect("End values for w: #{w}, b: #{b}");
  end

It spit out this output.

"Iteration 1: 100, 100"
902964882.6662791
4514335.333331471
"Iteration 2: 100, 100"
902964882.6662791
4514335.333331471
"Iteration 3: 100, 100"
902964882.6662791
4514335.333331471
"Iteration 4: 100, 100"
902964882.6662791
4514335.333331471
"Iteration 5: 100, 100"
902964882.6662791
4514335.333331471
"End values for w: 100, b: 100"

I was expecting the value of w and b to be updated and passed on in each iteration. Even though, the gradient descent returned back new values for w and b, it wasn't carried forward to the next iteration.

Turned out, I missed an important aspect of Elixir, rather functional programming. It is

Immutability.

All variables are immutable. Ideally, they are constants. You can't change it once they are initialised.

If that is the case, how am I supposed to do multiple iterations and feed the outputs from the previous iteration to the next one?

This is where the paradigm shift from object oriented programming is required.

By forcing ourselves to deal with immutable variables and methods that ~~doesn't~~ shouldn't have any side effects, we can come up an alternative way to solve the problem. i.e., to use recursion for looping.

Epilogue:

My relationship with Elixir has always been on and off. Having spent a couple of years building websites in RoR, I've explored basics of elixir few years back. Recently I came across this blog from Sean Moriarity and that triggered my interest to try out elixir in the ML space.

For curious minds, Charles Scalfani wrote a series of blogposts that helps with the fundamentals of functional programming.

My experiments with Copilot

Kalarani Lakshmanan — Sun, 21 May 2023 05:39:28 +0000

I've been trying my hand at creating something with Copilot for the last two weeks. The one question that I set out to find an answer is,

"Can copilot really replace pair programming?"

I've spent a good amount time of my career crafting code and 80% of the time the code was co-created with my pair. So, there was an initial hesitation to try this out. But one fine day, I crossed the chasm and got started on my experiments with copilot.

Quick start

The way copilot responded to some of my initial few prompts was amazing. I was writing a simple calculator in three different languages. In a few minutes, I had the code and tests for my calculators in Java, Python and Elixir.

A (not so) complex problem

I encountered challenges when I prompted copilot to create a simple CRUD API in layered architecture.

Given the prompt to create an article controller, copilot suggested to do the CRUD for an article and then it stopped there. My initial reaction was,

"Dear copilot, I know that I'd need to have CRUD endpoints in a controller. Could you please write the code for the same?"

But then there was only silence from the other end. So, I gave up and started defining the controller and dependencies. At this point, copilot came along and offered some suggestions that were appropriate.

It failed me again though. Given the prompt to create an endpoint to create an Article, copilot went on to define an action in MVC style, whereas I was looking to create a REST API.

Lessons learnt

You need to get better at prompt engineering. Be able to break down the task at hand and give specific prompts to copilot. The more specific your prompt is, the more appropriate the code will be.
Copilot can get stuck at times, or produce incorrect code. In such cases, once you take a lead, copilot will be able to follow.
You need to really know what you are doing. In a new language / framework, it can easily (and quickly) lead you down the drain.

Testing time

Once I had the code in place, I went on to explore copilot's skills in writing tests. I must admit that, it was pretty impressive in this space. It was able to cover the happy path and error scenarios equally well.

Again, Copilot's is quick to pick up your coding style and write more tests in the same style.

While at it, I wanted to write a builder for my model and with just one line of prompt, copilot gave me the implementation of the builder class. This is a key improvement. If copilot is able to write code understanding the language of software developers, that would be a good improvement in this tooling.

Can copilot replace pair programming?

The verdict: Nope. Or at least, not yet.

Copilot doesn't know (or care) why you are doing something. It is highly focussed on the how. While pairing often you'd have to zoom out and look at the big picture to ensure you are on the right track. Copilot is very contextual and can help you with specific tasks, but cannot help you with doing the right thing. It helps you do the thing right.

There is still a long way to go. But the future seems promising. CopilotX is a good step in that direction.

Future experiments:

Can you drive design through TDD?
Can you just write the tests and let copilot write the code. You should be good as long as the tests are green.
Can copilot help you go deeper?
Once you decide on the technical architecture, can copilot write code to create the entire infrastructure?
(or)
For a ML problem, can copilot help you pick up, train and test the best model for the job?

Gradient Descent for XP practitioners

Kalarani Lakshmanan — Tue, 09 May 2023 12:35:33 +0000

What is Gradient Descent?

Gradient descent is an optimisation algorithm used in machine learning to deduce the optimal weights / parameters that incurs minimum cost for the model being trained.

A machine learning model needs to be trained on a dataset before it can start predicting. We can call training as done, if we have figured out the optimal values for its parameters. We can say the parameter values are optimal when the cost (difference between prediction and actual) is minimum. Gradient descent helps us find the optimal parameters for a model, given the training data and cost function.

How does it work?

It is suggested to start with a random value for parameters and gradually update them till minimum cost is achieved.

The rate at which the parameters are updated is called learning rate. It is important that the learning rate shouldn't be too large or small. If it is too large, the model takes bigger steps and may not converge towards the global minimum. On the other hand, if the learning rate is too small, it may take a long time to arrive at the global minimum.

The cost function acts as the feedback mechanism to guide the gradient descent towards global minimum. It is not expected to start at a perfect value for the parameters. We rely on the feedback mechanism and the iterative updation of parameters to guide us towards the optimal value for the parameters, in baby steps. Each iteration in the gradient descent is just the most confident step we could take in the right direction.

So, how does it relate to XP?

We can draw parallels to the Gradient descent from XP practices and principles. XP states that striving for perfection is the enemy of progress. You don't need a perfect place to start. Rather, it is important to start somewhere that is logical to the team and equip ourselves with the right feedback mechanisms so that we can confidently move towards the expected state.

When we say move, it implies taking baby steps, rather than huge leaps. Taking baby steps can help us the safety net to fail and learn, course correct ourselves when things go wrong.

In summary, Gradient descent and XP are similar at a fundamental level, even though they have completely different applications.

Continuous Improvement
Relying on Feedback mechanism
Importance of Iterations

Agile Maturity Assessment

Kalarani Lakshmanan — Thu, 04 May 2023 17:23:05 +0000

You cannot improve anything that you cannot measure.

For teams on a Agile transformation journey, they may want to know at how mature they are. While I'm not a fan of ranking teams based on their maturity index (or similar), I think, within the team such assessments can be good starting points to identify what they have to focus on. In such cases, I've found James Shore's agile maturity assessment to be a useful tool.

This is a self-assessment for a team on 5 different sections.

Thinking - Awareness of what you're doing, why you're doing
Collaborating - Software development is a team activity.
Releasing - Pushing the software to production.
Planning - Don't strive to plan everything upfront. Adapt it as you go.
Developing - Is not just coding. It is the art of crafting a well rounded software.

Each section has a few questions that carry different weights. Every team member needs to take this assessment individually and plot their score on a spider chart. A collective view of this, can provide immense insights for a team on where they stand. You can classify it into two buckets

Areas of improvement - a relatively low score in a particular section, from every member of the team is a clear indicator of an improvement area for the team.
Gaps in understanding - difference in scores for a particular section is a clear indicator of the gaps on how the team feels it is doing.

The team can then brainstorm and come up with action items for themselves.

As mentioned above, the individual scores in themselves are not valuable, whereas the collective view of the team is. Therefore, comparing teams based on these scores does not make sense as well. I strongly believe, the business outcomes should give us the right feedback on the transformation.

Demystifying XP Values, Principles & Practices

Kalarani Lakshmanan — Sun, 19 Feb 2023 14:59:10 +0000

For any team that wants to adopt XP, it is important to make sense of the values, principles and practices and how they are connected to each other. Though, this understanding will solidify itself over time, it can be challenging to the team to sustain till then. And many teams may not have the luxury of allowing themselves the required time. Here, I attempt to put my understanding from practising XP over my years in Thoughtworks into words, hoping it'd help someone who is looking for this.

An Analogy:

Imagine a child, that is learning to speak. Children usually start speaking and create grammatically correct sentences even before they understand the elements of grammar. At this point, they are simply replicating / mimicking what they hear others speak. But, as they grow, they start understanding what they speak. They are able to break it down and label things as nouns / verbs / adjectives / adverbs. They are able to understand the different voices in the sentence. Once they understand this, they'll play around with it. They'll be able to generate more sentences that mean the same. They become capable of expressing themselves creatively and in different forms and without taking much of cognitive load.

In the XP world:

I feel, it is the same with teams that want to practice XP. Often it is useful to start with the practices, since they are more concrete. For example, you can start doing TDD even before you could understand the values of doing so. You can write a test - see it fail (bleeding red) - write the code - and see it pass. These are tangible things. The practices are activities that helps us in our day jobs. We spend most of our time in such practices. It is a very good place to start. But, if we don't understand the values and principles behind them, we risk being dogmatic.

As the team matures, we need to look beyond practices and be able to look at a big picture, be able to pick & choose (or drop) what is appropriate for the given situation.

Consider a scenario to see how these different components come to play with each other. As a team, we've agreed to value Communication. Personally, I'm not a big fan of code commenting. However, there are people on my team who'd see code comments as documentation that accounts to communication. I'd suggest that we address this by adding tests, which is guided by the principle of Quality.

However, if the team publishes an API and if anyone in the world can consume it, then it becomes essential that we add documentation (which could be in the form of comments and using tools to generate docs out of it). Here the documentation is important since it is now guided by a couple of principles Humanity (for external devs who consume our APIs) and Redundancy (by having tests + docs).

The Golden circle of XP:

I relate the values, principles and practices to the golden circle. The practices (what we do) form the outer most circle. The principles (how we do) takes the inner circle. The values (why we do) goes into the core.

Lets say, As a team we decide to do TDD. Practising TDD would be hard, if we take a complex problem and attack it as a whole. We'd have to break it down to smaller pieces and attack one at a time - which essentially means we are taking Baby steps - which in turn reflects the fact that we value Simplicity.

Similarly, if we take another example - when the team decides to do pair programming. We could trace it to the value of Feedback in the lens of Redundancy.