Every problem is the same.
Rephrased: every problem can be solved in the same way.
Given any type of technical problem, there exists a finite and achievable set of actions you can perform to find the root cause of a problem. From there, you can eliminate or improve that problem.
This is true in any field. Yes, the list of steps might be too long for a single page. Or maybe there's multiple sets of problems, each with "sub-problems" or ancillary problems. But across all domains of IT, software, engineering, or non-tech fields, I believe that this is true.
I maintain that it's the philosophy of approach that matters the most. This isn’t the "I have a hammer, let’s find some nails" approach, but the "I have the world’s greatest toolbox, let’s see what’s going on" approach. You already know what that toolbox is, right?
(It’s your brain.)
By solidifying your general problem-solving skills, you’ll enable yourself to solve anything, and move beyond where you are now. Not just professionally, but in any aspect of your life. But hey, maybe you just want to get better at figuring out what happened to that SMTP server and why it’s suddenly gone silent.
Why You Should Trust Me
I don’t have extensive professional experience in this field.
In fact, I spent just under two years working as a "Technical Support Analyst." Really it was on-call software support. Before that, the longest I'd held a job was three or so months -- as IT helpdesk -- and before that, I spent a whole lot of time unemployed.
Five years ago I was unemployed with no real prospects, thinking of going back to school. Now I’m a professional software developer. In that time I taught myself how to code in several languages, I have helped start new products, I have worked on and improved enterprise-level applications. By certain measures I do consider myself successful.
Unlike most other people with any measure of success, I am completely aware of the role luck had to play in everything. However, it’s important to realize that luck wasn’t everything. Without my willingness and ability to tackle any problem head-on, and without my ability to teach myself new things, I would have never moved past first-level support.
So while I don’t have multiple years of varying levels of software support under my belt, I do believe I can share what worked for me and what continues to work: my philosophy of approach, my self-teaching abilities, and my attitude.
What You're Going To Get
Each week I'll deliver a new post covering a specific topic. I'll alternative between topics. This way I won't spend two months writing about one subject. We'll cover things like the OSI Model, or how to write a good defect report.
You may think, "That's too basic."
Well, you'd be surprised.
As of this post's publication, there isn't yet much written overall on the subject for this blog. Below, I'll outline the general concepts and topics I'm going to be covering. This is subject to change. But for now, consider it The Plan.
- How to Solve a Problem
- The OSI Layer Model
- "How to Solve It"
- The 5 Whys
- The Ishikawa Diagram
- Trusting Your Gut
- How to Write Documentation
- How to Write a Good Bug Report
- Customer Tickets
- Technical Documentation
- How to Be the Best
- Product Ownership
- Customer Advocacy
- You Are Who You’re With
- How to Teach Yourself
- Finding a Mentor
- Finding Good Resources
- Applied Learning
This article was updated on October 10, 2018