/* MINDFIRE BLOG */

I'm about six months into my consulting position at Mindfire Technology, and I couldn't be happier with my co-workers. I've learned so much in this short time and have acquired an even greater hunger for learning by being around such great individuals. I've also found that being thrown into projects where you aren't quite familiar with the technologies or the domain is a surprisingly good way to learn, forcing myself to learn quickly and interact with co-workers to get the job done.

I've found insights into the interactions I have with co-workers and the process of resolving the projects themselves. I'm learning the questions I should be asking myself before I ask questions of others and the processes I should follow as I solve an algorithm, a debugging session, a project, or whatever it might be.

As for asking questions of others, I've found that there is often a clash between asking too soon and not soon enough. You want to have given it a fair shake, as to not bother a co-worker unnecessarily, but you also don't want to waste project time by not asking soon enough. Consider the time wisely.

Here are some hot points that may help in finding this sweet spot:

• Read the manual, the documents, the tutorials. Whatever it may be.  Be prepared to solve the problem, and in the case where you need help from others, be prepared to ask the questions.  You may need to think outside the box and outside your comfort zone. Understanding the domain/context/problem is exponentially better than haphazardly fumbling about.
• To get out of a rut: Google/Bing it. StackOverflow it. Github it. YouTube it. Perhaps even PluralSight or Udemy it. These are incredible resources, and they're right at our fingertips.
• Again, be prepared. Here are some thoughts on being prepared:
  • Make sure you understand the root of the problem, is possible, not just a guess.
  • Try not to bring a problem to someone without first having tried at least one solution.
  • Keep notes about the problem.
    • Think of areas you haven't looked at yet.
    • Write hot-points.
    • Write hot-areas.
    • What have you tried?
  • Debugging is your friend.  Stack Trace. Logging. Comments. 
  • Clean up the code by removing unnecessary comments, refactoring for clarity, and making sure you have good identifiers.
  • Commit to source control, or in some way back up, so that you and your coworker can change your code to your heart's content without worrying about irrevocably breaking your code.
  • If the IDE has a section for Breakpoints, clean that up and include only breakpoints related to the problem.
  • Maybe add a custom 'To Do' comment that you will always use wherever hot points are at. This makes it easy to clean up afterward with a system-wide search.
  • Before you get out of your seat or turn your chair around to ask the question, take a moment to 'talk to your rubber ducky'. Yes, this is a thing and I've actually found it quite helpful.  It's the process of talking to an inanimate object as though it were a live human being.  This often helps bring new insights to mind that may have soon popped up at the beginning of a question/answer session with a coworker.  This could save you from looking stupid by another coworker when you solve your own question 15 seconds in. By the way, my inanimate object is either a bobblehead Einstein or Gandalf, depending on how fantastical I feel at the time.

Time is very important in the workplace and doubly so for the development workplace with its inherent deployment deadlines.  Being able to discern the best route to attain the best use of time can provide great benefits for the team and the company.  I hope this article will help you have a better relationship with your time in order to develop and co-develop your projects in the most optimal way possible.