Building solutions to problems is a part of an engineer's role. The challenge of solving a problem in the best interests of everyone comes with the job, and over the course of our careers we become unphased by what's expected of us as our experience grows.

Then we get those days when the bucket of experience is empty and we need to learn-and-solve in parallel (9/10 times using "T&G"... time and google). Most of the time the problems we try and solve have been solved before (that's not to say there's no room for improvement), the only problem is discovering this for yourself.

The classic problem

• A stakeholder needs a new piece of functionality or feature added with little-to-no compromise (justifiably of course).

  • The problem will involve using a proprietary library/framework ( - bonus points if the documentation is sparse/shoddy/outdated/invisible)
  • It involves writing a function or algorithm with particular traits
  • It's a common problem, but your stack/solution isn't. And by consequence, your solution won't be so common either.
  • It involves pushing the boundaries of a browser/device/library
  • Time/budget is of the essence

In summary:

YOU DON'T KNOW WHERE TO START

So it's time to estimate this "8 point, would be 3 if it wasn't for X" task, whip out the T&G and get solution searching.

Solution searching is a time-consuming process which can become a vicious-cycle of learn, attempt, fail, repeat. 80% of the exercise is research, and the other 20% is development. Sadly that 80% may be done in 5 minutes, 5 hours, or worse. When you're on a deadline, the unknown "timescale to success" can be stressful and lead to something I've coined "solution searching anxiety".

Venturing into the unknown also means having to be strategic in your research, every bad road to discovery costs you time and energy.

Solution searching

Discovery a potential solution consists of...

• Searching for an answer using a well constructed description
• Read a possible solution
• Read it again to digest it
• Try it out
• Read it again

All the while you're asking yourself...

• How does this solve my problem???

  • This solution is too long and doesn't sound like what I'm looking for, am I wasting time reading to the end?
• Is this best practice, am I following bad advice?
• Is this 'reinventing the wheel?'

• How do I change the example solution to solve my problem?

  • Can I actually change the example solution to solve my problem?

    • At what point do I start crafting my solution around my learnings?

    • Will the solution be overly complex, expensive, buggy or insecure?

      • Is there a better way to solve the problem that I just haven't found?

        • Should I hit the back button yet?

This is a sorry situation to get yourself into, but don't fret there are things you can do to get out of this painful practice.

Breath, Relax, Be Patient

Anxiously solving a problem will rarely solve the problem with a positive vibe. You'll usually 'succeed in a failing condition'. When you're going in circles, take a step back and chill.

Keep track of your failures

Make a note of EVERY failed attempt you've made so far (and why it failed). As humans we're quick to cast aside failures as progress, but it is progress (you know what doesn't work). Furthermore, other's can see where your attempts fell short and point out where you went wrong/what's left.

Timebox, don't estimate

If you already estimated the complexity or time it will take to solve your solution-less problem, you've lied and put yourself immediately under pressure. As far as any stakeholder is concerned, this problem to them is as complex as achieving Fusion is for Nuclear Physicists.

It's important to timebox these problems so as not to overly-invest in it (for everyone's benefit). If you're being pressured to give a deadline as an individual, then involve others in the estimation (you share the problem as a team), and if you're not getting the support of your engineering peers on the matter, then that's a different problem.

Pursue with caution, but stick to "a" solution

It's very easy to go with the first solution you find. But be sure to question its integrity and suitability. The first solution you find may be inefficient, hard to read, hard to extend buggy or insecure. It's also important not to fall into a cycle of indecisiveness and keep finding 'a better' solution.

A remedy to this conundrum is to discuss your findings with others and question a solution's usefulness as a group. If you're still unsure about a solution and have exhausted all means, roll with it. Pursue the solution and code defensively with modular code so the solution can be extended or replaced in the future.

Be humble and transparent, articulate the conundrum.

Never suffer in silence, keep others in the loop on your progress and articulate how far you've got so far. As engineers it's all so common to deny you're struggling to solve a problem, but you're not helping anyone (especially yourself). Talk to your team, explain the problem and explain what you've found so far so everyone is caught up on your progress (remember that your failures ARE progress).

Decompose the problem, and decompose again

Decomposition is a big part of problem solving. If you're searching for a solutions such as "build user management backend with python and react, deployed to a k8s cluster in AWS", you're trying to run at the speed of light before you can even walk!

Decomposition is the concept of really breaking down a problem to the core moving parts, then breaking those parts down again until you start to highlight core pieces. The more a more is broken down, the more you'll discover there are parts of the problem you can solve without automatically turning to the internet.

Share the responsibility

Pairing up with someone on the problem can help share the responsibility and insight. It gives opportunity to discuss your findings and review it's integrity and suitability for your own problem. Pairing up (or even pair programming) also means the context and knowledge is shared across individuals.

10% time / independent learning

There's no big secret, the foolproof way of avoid knowledge searching situations is to have the knowledge to being. That only comes with experience and thousands of hours of learning. As engineers we'll never stop learning as part of our careers, and it's important to make the time to learn.

Your company may be able to offer part of this with 10% time, which should be used valuably to benefit yourself (so you benefit others). But this will only get you so far, you have to make the time to learn on your own time (Bob Martin recommends 10 hours a week, but with personal work/life balance that isn't always a luxury).

Learn how to learn

No two humans are wired up the same, and we all have our ways to learn. Whether it's through academia or vocation, you have your own technique to grasping (and remembering concepts). When building your experience, you need to discover what works best for you. Maybe you have a photographic memory for reading, or maybe you're better doing practical courses, or maybe screencasts are more effective.

My advice is to experiment and reflect on your learning technique. Ask yourself if you're remembering what you've been taught, if you can independently repeat what you've learned, and if you've enjoyed the process. Once you've nailed those questions you've got learning technique for success.

Build a knowledgebase

The tech industry is a massive industry. It would take a lifetime to learn everything, and be impossible remember everything. So it's important to have a system for maintaining and reflect on your learnings.

Whether it's your personal textbook collection, hand-written notes, an extensive git account or a healthy pinterest, having your own system for easily tracking and referring back to can be a useful investment. Personally I use a OneNote and a bookmarking service to keep track of what I've learned and what I want to learn over time.

Learn how to search, know the terminology

Searching for solutions is only as effective as the person's ability to search. An ambiguous search term can yield poor results, and generate a false impression. What may appear as an undocumented problem, is in fact a common problem when searched for correctly.

The best way to improve your searching skills to learn the terminology around your problem. Design patterns, data structure algorithms, buzzwords are all useful keywords for searching out solutions. Spend the time learning the terms and understanding their purposes. It will not only help with searching out solutions, but also improve the way you communicate a problem with your peers ("speaking the same language").

Google isn't always your friend.

Google, GiHub and Stackoverlow don't hold all the answers to an engineers problems. All forms of media should be given equal treatment. Furthermore, these sources of knowledge have ulterior motives.

Google's business model is built upon ad-revenue, data and sponsored results, and two identical search terms may not yield the same results because user data is a factor. It's important to try alternative sources (book indexes/glossaries, dedicated blog/website search).

Talk about your learnings

Finally, don't keep what you've learned to yourself. The only way others avoid the same situation is to talk about what you've found. Whether it's as simple as an upvote on Stackoverflow, a tweet and a url, or a full writeup with example github repo. Being vocal about your learnings helps improve the discoverability of you

*Photo by Caio Resende from Pexels