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:
- Why is it Complex?
- Break it Down
- Research it
- Get Help
Why is it Complex?
The first thing I do is figure out why the problem is complex:
- Do I understand the business requirements? Review the business requirements with your users again and ensure you know what they want. When you understand the business requirements better, you may find the problem isn't so difficult
- Challenge the requirements. As a developer, I have more say in the design than I might realize. Complex problems tend to cost more to implement and support. They are often less performant and can lead to other issues down the road. Many times when I explain these factors and the business sees the dollar amount associated with them; then I can negotiate a more straightforward design
- Am I the right person to solve this problem? Leave your ego aside. It may be that a colleague is better qualified to do what you are attempting. There is no shame in bringing this up as long as you don't sound like you are just trying to avoid the problem
- Sometimes, it is just a complex problem, its time to get over it and figure out how to solve it 💪
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 🤪.
Break it Down
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:
- Detail the steps to map the data between the source and target
- Determine how to get the data from the source system
- Determine how you are going to transport the data to the target system
- Finally, decide how you will ingest the data in the target system
In the above example, I broke the requirements into four smaller tasks I can take on individually.
Walk Away 🚶
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!
Before Asking for Help
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.
Where to Get Help?
- I usually start with my co-workers. They are typically invested in the success of the same application or project and want it to succeed. You will come across people who are reluctant to help because they are hyper-competitive or are just plain grumpy. In my experience, these folks are the minority
- Next up is my developer community. As an Oracle APEX developer, I am lucky to be part of a fantastic developer community
- APEX developers (and the Oracle APEX development team) are active on Twitter using the hashtag #orclAPEX
- There is also a great community lead site called APEX World which every APEX developer should join. This site also has a Slack Channel where you can post questions
- Oracle produces Office Hours videos with information on new APEX releases and functionality
- Oracle hosts a Community Forum where you can post questions about APEX
- The folks at Oracle Development who build APEX are the best. Many of them come from the community and understand what developers need. They are also accommodating and respond to Tweeted questions regularly
- This may not be a popular opinion, but sometimes the manuals have the answer!
- Keep a database of code snippets, tips, and tricks. I use Obsidian which is an excellent tool for storing and organizing markdown
Share what you Learned
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!