Susanna Codes

Problem Solving: Breaking Down Functions Into Smaller Functions And Writing Pseudocode: Reflecting on a call I haven’t watched back yet My boss and I did a recorded call on problem solving before my holiday; this one was specifically on solving a problem and on writing a function to solve the problem. Specifically it was about writing the pseudocode for a function to solve a problem. And then it would have been about writing the pseudocode for the three sub functions that would go inside of this main function or whatnot. Specifically; well first I want to say that I haven’t watched this back yet and I will not do so while I am on holiday. But I’m intimidated; the fact that it is a 45 minut call with follow along notes and lots of information seems to me that I will need a good 3-4 hour session on a Saturday morning one day to follow it back properly and take notes. But I want to try and go off of the back of what I remember and the few seconds I did watch back the other day. So my boss

Thinking A Bit Further About The Business Case It’s 7 am. I’m waiting by the fire for my first meditation and for my tea to cool down. I wanted to touch a little bit further on business logic (luckily here passion is encouraged and nobody judges me for who I am). The piece of work that caused us to address problem solving properly although it was always an issue was a big revision of a PR. It was a revision of a feature request. I delivered the feature request correctly. But we wanted to do something more. So I redid it quickly but I redid it too fast and in doing that apparently didn’t think enough about the wider problem.  I trust my senior with my life so this is feedback I’m willing to take. I didn’t think enough about: What are we taking in? From a business perspective, what are we taking in? I am keeping it vague but it’s a list of users. Or rather a list of account features that then allow us to identify the users What are we putting out? Again keeping it vague - the function do

Thinking About The Business Case First Okay so I did not expect to be writing on my break and least of all at this time. But my brain just does its own thing! I also want to add that nothing I write in this blog matters. Absolutely nothing. What matters is what I do at work. What matters is how I perform. And these are all posts to help me to consolidate what I do and do it better. So here’s a quick 5 am thought: when doing problem solving. I am struggling to define problems. When I take a new ticket it’s not obvious what the problem is.  But what is completely obvious to me now is the first step. To think about it from the business perspective. For example: I was changing the way we do views the other day right? From functions to classes. But what would’ve helped me is thinking about the purposes that views serve in the first place. They are our endpoints right? They are what we need to hit to make our code happen. When changing the views I wish I had started off with: “I have some en

Comme si je n’existais pas, elle est passee a cote de moi, sans un regard, reine de Saba, j’ai dit Aicha prends tout est pour toi When I was a teenager a Touareg band came to visit my school. I jammed with them. Them singing Aicha together was the most beautiful musical performance I will ever see. How do you even follow that? I care so much about my work. I care so much about what I do. There’s something that just keeps me pushing and keeps me drilling because I care so much. I care so much about what it is that I do.  I have been told to “take those cares and transform them into demonstrating my performance.” 🎭 but sometimes I don’t always know how to do that directly. Right now my biggest concern is problem solving. I was told that I struggle with solving problems on a smaller scale but the thing is: I need to learn on the big scale: once I learn something on the big scale it is easier for me to translate it to the smaller one. It’s like if you wanted me to consistently run 5K you

The Importance of Problem Solving in a Business Context I am writing this one and then I am off. BYE. Okay so basically; I received some interesting feedback the other day that solving LeetCode style problems is not equivalent to solving problems in a business context. Let me explain. I have solved my fair share of LeetCode style problems in my time.  But contriving three functions to help the Elder Wizards find their spot at the dining table isn’t equal to understanding why we take in a JSON payload (or don’t), or to why we make third party calls, or to why we want to return a USEFUL JSON response in our business logic (!!!). I am happy to take this on board. I always prefer real business problems to fake coding problems. Always always always. Always. But why am I failing to demonstrate this enough? I guess I get lost in the code. I get overwhelmed by the code. I tell myself lies like “I’m not a technical person.” But these are lies of course. I think the code is going to be so overwh

Writing a Problem-Solving To Do List Again After many many months the day of my holiday has finally arrived. Hooray! I am feeling much much better. I am going to have to take it easy but I am fine with that. I got told that it was “well-deserved”. Hooray! So before I go I would like to write up one more time what I think that my next steps are for improving my problem solving skills. Because more and more ideas just keep on coming into my head I need to ingrain a couple of ideas into my head. Think along the lines of my blog post last night “given input x, what are the steps necessary to return output y?” This needs to become second nature to me. Kind of like playing the piano - I don’t even have to think about it anymore. I just play  The other idea I have to ingrain in my head was around those three questions that changed my life. So:  What do I want this thing to do? What is it doing? What do I wanna TEST? Because your test is framed around what you want it to DO BECAUSE ONE THING I