Adventures in Coding

So I went to one of my fave fave fave mentors - one of my fave mentors ever - and I said I wanted to be better at writing code. 

That's actually what inspired this post! We had an amazing time.

But I wanted to talk a bit more about the process that I went through - and what I actually learned from it.

What We Did

We decided to build an endpoint in the style of the codebase I am working in at the moment. In fact it was in a branch of my main codebase - and it imitated the style of some of the other endpoints that I have in my codebase.

We did it there because - well I don't know because it was at my mentor's suggestion. 

But I thought that it was a brilliant suggestion so I jumped on it straight away.

Although I have built endpoints before, I still feel that I am fairly new to the backend - all my bootcamp projects, I owned the frontend. So it is very exciting to be in a mostly backend role - and I think I prefer it - and I still have a lot to learn in this domain!!!!

Writing Up a Ticket

We went through a pretty clear process of writing up an Asana ticket, and of creating technical requirements and acceptance criteria. I loved this.

I love software engineering tickets and I find they really help me to work. I love having a clear structured goal. I love structure and organisation.

I love clarity and direction.

I used to work in Product and back then we used to write tickets.

I also have written a fair few for myself as an Engineer of course.

What were the technical requirements in this mini project? Well basically we had two main technical instructions

1. Make sure that the endpoint gets all the data that we are asking for
2. Make sure the endpoint returns all of the requested data in JSON format

Like that, it was really helpful for me to learn. 😊😍

The thought process

So, what is the thought process of writing up an endpoint properly? Well we started off with looking at a pretty similar function to the one we were defining that had been written up just above in the codebase.

• Well actually, we first wrote up a url in the url patterns in urls.py inside of the app - we use Django
• Then we went to the views.py and we looked at a similar function
• We followed a similar naming convention (patterns!!!)
• We looked at the argument used in the above function
• We looked at the return type used in the above function (return types in functions are very important as they help other software engineers to know what to expect)
• We talked about CRUD methods - GET, PUT, POST, PATCH, DELETE - it turns out that people DO use PATCH after all in spite of what some people say.
• I keep on meaning to revise these so I know them off the top of my head. I need to do this some time.
• We talked about the client - the client could be a browser - it could also be someone who is using POSTMAN - or it could also be someone who is using a Python script to query something every single day ... 
• ...
• We then created a variable which is ultimately what would be returned

Okay let's stop there for a minute and think. So often in problem solving the very first thing to do is to create a variable which is ultimately what will be returned, your answer. Of course in leetcode style problems and in life there will be times when you don't need it. You can do a list comprehension or whatever. But both for simplicity and for readable I like to return a named variable.

Sometimes the complexity of the function necessitates it anyway as there are multiple steps.

So we named a variable - and then assigned it to objects.all() on the Model that we needed - this is driving me insane, I never understand objects.all() or any of the similar or related methods (objects.get()?). 

I probably need to research these along with GET requests etc. - the latter being again just so I know them off the top of my head more readily.

Finally, returning the thing

So we return our response - we place it inside of a dictionary as the value even though it is made up of mostly dictionaries itself or whatever (is it is a dictionary or a dictionary of dictionaries? I'm not sure) and then we wrap it all inside of a JsonResponse which is so frickin' cool - I LOVE Django!!! - and then we just give it a name inside of the first dictionary as a key which will give an indication as to what the returned data actually are.

What this means to me

The thing that never ceases to amaze me about code is how actually complicated writing a very small snippet of very good code can be.

In good code, every single word is meaningful

And that is like my previous technical lead in my last job - whom I loved working with dearly and I miss so so so much on a professional level, although I am glad he has been replaced by the unbelievably wonderful and absolutely phenomenal mentors who I have in my new job - often as a software engineer you only write one line of code in a day. But it has to be GOOD code.

It's beautiful, it's an art. I love it. Next steps:

Research objects.all() and similar methods and research request types.

p.s. sometimes I am afraid of looking stupid. A lot of people very much more senior than me read my posts.

But then I remember that I really want them to see is my passion and my enthusiasm and my love for what I do. And my dedication to my growth and to my journey. And hopefully, the fact that it will pay off over time. And that's enough.

PLUS, I just LOVE TO LEARN. And I love coding. FULL STOP. Need I say anymore? I love this picture.