3 ms·

Can you talk more about your method for solving problems? That's normally where I get stuck.

100011_100001 4y ago
People get stuck solving problems for various reasons. For me, I think more clearly when I write. The primary benefit is that it stops having to mentally re-establish my logical premises to make sure my conclusions are sound. Anyway, the hardest part of writing code is starting. Why is that? A lot of times it's overwhelm, you see the task, it appears large and you don't know what to start. My solution is simple, I start writing the steps I need to take. This will be easier with an example. To not get stuck in weird debates let's pretend the ask is that I need to build a house extension for someone. I will start breaking that down, in bullet points. * Figure out location of the extension * Find out dimensions of the extension * Order wood and nails * Bring hammer on Monday to start At this point I might know what kind of wood I need, hell I might even need to buy bricks. But I have a semblance of steps. I can talk to the client and ask specific questions. As I go through my list I expand it or make it more focused as I go. Out of habit I also tend to mix thoughts and realizations in my bullet points. Then as I am going through the solution the following days I can see my thoughts expanding and increasing in specificity. There is another thing this does. If I find it hard to come up with a few bullet points it means the problem is too vague or I don't understand it well enough. Instinctually you will know if it's lack of knowledge or vague problems. If I lack knowledge I read about it or talk to an SME. Vague problems can be solved by talk to the Product Owner, Business Analyst or a client if it makes sense. Once I grasp the problem, get basic questions answered I go through my bullet list and refine it. That's when I try to design things. After I have a design I try to see if I'm making any assumptions. Personally I prefer to test any assumptions I have. I rather find out my assumption is false at the design phase than later. Granted sometimes things can get still trip me up, or give me a false positive. I don't spend a ton of time designing. If I can I will pitch my design to someone I consider smarter than me to see if they find holes. I prefer people that think more breadth first, because I think depth first. Their strengths is my weakness. Most of the time in the act of my pitch I will find assumptions I have made or I will realize that what I am saying is overly complex so it probably means I didn't design it well. So I iterate. Designing doesn't take me long most of the time. I have learned that I think better when I code than when I design. When I start coding I use a dirty version of TDD. Instead of write test, write code to pass test I follow a different pattern I write small parts of code that satisfy the most likely case and I write the first step of the most likely case. For example if I was writing a rock paper scissors game, the first part would be to to right the main method framework and print "welcome to rock paper scissors game". Then I run the code to see it's good. Next step would be to accept input. Test that. Then write the logic for determining what the CPU will throw. Test that. Then how to determine the winner. Test that. Then create the "you win/lose" message. Test that. Once that's working I'll start to worry about things such as, what happens is they press enter without any input. What if they miss type a word. I might decide that I would be easier to make it multiple choice, where a = rock. This is a simplified and contrived example. Sometimes I'll write things I consider easy in one go, but if I have doubts or I am starting to touch complex objects or logic I start testing more frequently. When I test I don't sit, I keep writing code while the test is running. I test excessively but it helps me to see unintended consequences quickly since my code to test cycle is short it's really easy to identify the source of my woes.

People get stuck solving problems for various reasons. For me, I think more clearly when I write. The primary benefit is that it stops having to mentally re-establish my logical premises to make sure my conclusions are sound. Anyway, the hardest part of writing code is starting. Why is that? A lot of times it's overwhelm, you see the task, it appears large and you don't know what to start. My solution is simple, I start writing the steps I need to take. This will be easier with an example. To not get stuck in weird debates let's pretend the ask is that I need to build a house extension for someone. I will start breaking that down, in bullet points. * Figure out location of the extension * Find out dimensions of the extension * Order wood and nails * Bring hammer on Monday to start At this point I might know what kind of wood I need, hell I might even need to buy bricks. But I have a semblance of steps. I can talk to the client and ask specific questions. As I go through my list I expand it or make it more focused as I go. Out of habit I also tend to mix thoughts and realizations in my bullet points. Then as I am going through the solution the following days I can see my thoughts expanding and increasing in specificity. There is another thing this does. If I find it hard to come up with a few bullet points it means the problem is too vague or I don't understand it well enough. Instinctually you will know if it's lack of knowledge or vague problems. If I lack knowledge I read about it or talk to an SME. Vague problems can be solved by talk to the Product Owner, Business Analyst or a client if it makes sense. Once I grasp the problem, get basic questions answered I go through my bullet list and refine it. That's when I try to design things. After I have a design I try to see if I'm making any assumptions. Personally I prefer to test any assumptions I have. I rather find out my assumption is false at the design phase than later. Granted sometimes things can get still trip me up, or give me a false positive. I don't spend a ton of time designing. If I can I will pitch my design to someone I consider smarter than me to see if they find holes. I prefer people that think more breadth first, because I think depth first. Their strengths is my weakness. Most of the time in the act of my pitch I will find assumptions I have made or I will realize that what I am saying is overly complex so it probably means I didn't design it well. So I iterate. Designing doesn't take me long most of the time. I have learned that I think better when I code than when I design. When I start coding I use a dirty version of TDD. Instead of write test, write code to pass test I follow a different pattern I write small parts of code that satisfy the most likely case and I write the first step of the most likely case. For example if I was writing a rock paper scissors game, the first part would be to to right the main method framework and print "welcome to rock paper scissors game". Then I run the code to see it's good. Next step would be to accept input. Test that. Then write the logic for determining what the CPU will throw. Test that. Then how to determine the winner. Test that. Then create the "you win/lose" message. Test that. Once that's working I'll start to worry about things such as, what happens is they press enter without any input. What if they miss type a word. I might decide that I would be easier to make it multiple choice, where a = rock. This is a simplified and contrived example. Sometimes I'll write things I consider easy in one go, but if I have doubts or I am starting to touch complex objects or logic I start testing more frequently. When I test I don't sit, I keep writing code while the test is running. I test excessively but it helps me to see unintended consequences quickly since my code to test cycle is short it's really easy to identify the source of my woes.