By my very nature I am a problem solver. I use my wide range of skills and knowledge to examine, hypothesis, research and implement solutions. I follow this process very naturally and often surprise myself at how effective I can be at solving problems.
As a part of following this process well, I find that it is important to use familiar tools and take my time. Sometimes this means moving the problem to the back of my mind and let my sub conscious mull it over. Many complex and hard problems have been solved while I was walking or in the shower. Making sure other people know of the problem can is also good as they can come up with a different solution or idea.
As a part of my professional development, I like to stay up to date with new technologies. I don't generally try everything but knowing that they exist could be useful for a specific problem or idea.
Software is a very open ended problem space both is scope and solutions. The most important thing that I do is to break the project down into sections.
In a lot of cases, if I have done that type of module before, I'll already have a good time estimate and maybe even some code. Reusing modules and code is good as it has already been proven and works.
With a new module, research is undertaken to understand all the nuances of the area. This has involved talking to the people that work in the area, thinking out loud what the team thinks is important and looking online for existing solutions.
Only once a module has been scoped and research is any design and development started. By this time, data structure have likely been created. Critical functions have also been worked through. Generally this is where a full quote is done and development time is scheduled.
Finally the implementation starts. Each module is built and tested. This is where my problem solving skills really shine as I think about not only the current module but also how this will affect future modules. Being able to think about the side effects of a decision is a really good tool in making good and flexible code.
While a lot of my work recently has involved software, I have tried to stay up to date with hardware and electronics. Some of my more recent projects have had a strong focus on electronics.
I follow a lot of the design principals from software into hardware. Breaking up the functionary into modules has proved really useful in the past. Making sure each section is tested individually has also saved a lot of time.
I am a big fan of ARM processors and with the Rust programming language having (bare metal) ARM support, I think that the way hardware is developed will change.
As well as ARM, I have also had a lot of work to do with 3G communications. This is an interesting area as while the task is simple, it can take a lot of effort to set a fairly generic message. Improving the software of these modules is one area where I would like to spend more time.
I am an avid woodworker. While I won't be making fine furniture any time soon, I really enjoy making things from wood.
Unlike software, I don't have that many tools and often make do. This makes it more of a challenge sometimes, but generally there is an alternate solution. Another challenge is the lack of a 'fulltime' workshop. I mange to fit mine in the 2-3m in front of my car in the garage.
It is quite nice to forget about everything and just concentrate on the job at hand.
Another way I destress is to build with Lego. One of the reasons that I like Lego is that the problem space is rather contained. There aren't infinite solutions and the constrants of working with limited pecies is rather satisfing.
It also happens that I am a world expert on the strength of Lego. You can find my paper here and also a reference in What If by Randall Munroe.