What do I do when I get Stuck?

Search for a command to run...

No comments yet. Be the first to comment.
Introduction One of the marquee features of APEX 26.1 was AI Interactive Reports. When I started testing this new feature, I was interested to see what was going on behind the scenes. In this post, I

Introduction One of the marquee features of APEX 26.1 is APEX AI Agents. APEX AI Agents allow you to use an LLM and your own PL/SQL and JS tools to perform actions on your data instead of just chattin

Introduction In my previous post, I looked at logging APEX AI Agent requests and responses with Request and Response handlers. Logging is the first step because it shows you what is actually moving th

Introduction Logging is one of the first things you need when building serious AI Agents. Without it, debugging quickly becomes guesswork. You can see the final answer, but not always why the model ch

Context management patterns from building agents in Oracle APEX

In their 4 Articles in 4 Weeks - Writeathon Week 2, Hashnode asked the question: "When you are stuck as a developer, what do you do?"
This is another post that is a little bit out of my tech-focused comfort zone, so bear with me. I do, however, feel well qualified to answer this question because I frequently get stuck!
This post will take you through my patent pending ๐ 7-step program for dealing with complex problems:
The first thing I do is figure out why the problem is complex:
Like it or not, getting stuck is an almost daily occurrence for developers. It can be scary, but it is something you need to get comfortable with and expect.
I will get stuck, and I will figure it out!
After a while, you will start to sense the challenging problems and begin to work through the process of dealing with them. Before you can deal with them, however, you need to recognize them and accept them. Apologies if this sounds like a post on mental health but it kind of is ๐คช.
Once I have accepted the problem is complex, I start to break it down into smaller parts. Like I would break a complex program into smaller functions and procedures. For example, if you are building an integration between two systems, you could break it down as follows:
In the above example, I broke the requirements into four smaller tasks I can take on individually.
Also, don't be afraid to take a break; walk away from the problem and return to it the next day. I often find that if I bear down on a problem for an hour or so and then drop it, things make a lot more sense when I return to it the next day. This post from Psychology Today explains the phenomenon well. You may need to take a break and return to the problem multiple times before it is completely clear.
Anyone in technology knows that Google is their friend. There are not many original problems; nine times out of ten, someone will have already solved yours.
I do have a note of caution when reviewing blog posts or Stack Overflow answers. Make sure you sense-check the solution. Just because someone wrote it does not make it the best solution. Try and find multiple articles that corroborate each other. Over time you will build up a list of bloggers that you trust.
Avoid โ๏ธ Copy and ๐ Paste without understanding what it is you are copying and pasting.
While researching, don't forget to look in the code base of your own company. Someone might have already solved this problem, but it might also have been someone in your own company. How embarrassing ๐ณ would it be if you spent days trying to solve a problem that the person two desks away had already solved?
After breaking the problem down and researching possible solutions, start iterating on the solution. Take the most challenging piece and build a Proof of Concept (POC). Build enough of the solution to be sure it will work (or not). This iterative approach allows you to cycle through several potential solutions before investing too much time on any one of them.
Once you have a working POC (and this bit is significant), make sure you go back and make the code production ready before it is deployed.
It is essential to know sooner rather than later when you need help. Don't let the problem drag on for weeks and weeks when you know in your heart that you will not be able to solve it yourself. Tell your manager when you are genuinely stuck. Most (reasonable) managers will understand and are happy that you let them know while they still have time to do something about it. Please do not approach your manager an hour before the deadline and tell them you are stuck!
Your helper will be much more likely to assist you if you lay out the problem and show them exactly how you tried to solve it. There is nothing worse than someone coming to you for help with a poorly defined problem, except maybe someone coming to you for help and they haven't even tried to solve it themselves.
You have just solved a challenging problem. It's time to kick back and celebrate. Not so fast. Now is the perfect time to write a blog post and share it with the community. Not only will it help others, but it will also help you. Writing about something I just learned helps engrain that knowledge and also helps to test it. I have written a blog post more than once, realized there was a better way to do something, and then snuck that improvement into the next Sprint.
OK, now you can celebrate!
Getting stuck as a developer is part of the job. Embrace the challenge and follow the process until you get past the problem. I would love to hear your tips for solving complex problems!