Strengthening your Career

I often see people new in IT, asking for advice of where to focus on, what tools to use, how did you get started, extra. Of course this industry moves way too fast for most of any one specific thing to stay relevant beyond casual conversation, but there are a few generalities that help at all levels of your career.

Curiosity and Communication are often listed as primary strengths to kindle. Building self learning habits goes a long way to keeping up, as formalized education is just the starting point.

Share what you work on and explore, at least where it doesn’t interfere with any NDAs you are under. This can be on forums, communities, blog posts, and/or even static web pages(easier to secure 😉 I’ve done so for many years, and have had work and interesting opportunities come my way many times just from that sharing across all those venues. For example, I can be found in the Micro Focus community (basic skill test: find me there), sporadically on this and other blogs, I share some of my links, at conferences & user groups, and many other places all over. A fun thing that happens with such posting, is when your past posts answer your current question, i.e. you ask someone (colleague, vendor support, Google, etc..) a question and they come back with the answer you wrote years previously for a similar situation.

As this industry is constantly moving forward while building on the past, any of your shared learning, even of the basics, helps others understand. The more you are a part of others learning, the more good things will come your way.

As much of IT has a notable troubleshooting component, detective skills such as Critical Observation, Logical Reasoning, and Scientific Methodology all help making finding that simple root cause much easier to find.

A key tool for Observation is the ability to ‘see’ what is being communicated on the network through capturing the packets from and between systems. To that effect, maintain at least a basic packet capture & analysis proficiency. Even just knowing, when and how to grab a capture to get to someone who can better analyze it, puts you way ahead of those just guessing. WireShark is the big one to know, but be aware of the others. As an example, I have NirSoft‘s WhoIsConnectedSniffer running all the time by default just to maintain a situational awareness of the networks I am on. XArp and NetworkMiner are just another two I make regular use of.

So to grow and strengthen your skill sets and career

  • be curious,
  • read widely,
  • carefully explore,
  • and practice you communication skills by sharing what you learn.

Automation, a tool like all others.

Automating processes is a powerful tool that can sometime pay huge dividends. But other times it can be a time sink

I find it does take drilling on some people, that automation is not THE answer to everything (42 is that answer 😉 I have directly encountered “That process if fully automated, therefore it is perfect and doesn’t require a closer look” even when the environment has changed such that the automation needed adjusting to accommodate the new reality. Perfection is the ideal we strive for but can never meet, and that includes the things we create, but we still get those who don’t get that concept which makes things harder than they need to be.

My early packet analysis training drilled in “Auto configuration is evil!” because of all the problems that can happen with it. This was Truth #8 from Laura Chappell of Wireshark U back when she was still at Novell. Perhaps this is a bit extreme, but facing the extremes is how we find the middle ground.
Many adherents of the current wave of automation and orchestration in virtualization circles, do stray to the extreme and need some tempering. The majority of organizations are too small (under 100 work loads, which is most of my client base) to benefit from any of the orchestration systems currently being pushed.

During Randall Munroe’s book tour for “Thing Explainer”, he described how he contemplated programming the drawing of the lines for “Tree of Life”, but stopped when he realized it would likely take him a month or more to get it right, when it would take him just a couple afternoons of doing it the “old fashioned” way which is what he then did. Clearly this is something he has to watch for regularly that he created a chart for “should I automate it”

A teaser of an example, replacing the “dot” and “at” in many posted email addresses with the appropriate characters. This is a totally automate-able exercise that some people do embrace, but when is that ever an efficient use of time and other such resources? I handily resisted, how hard did you have to fight that urge?

So for automation, only do so when appropriate.

The Right Tool for the Job

We humans are both tool users and creatures of habit. As such we often get into habits of using certain tools for everything we think they might apply, but that can lead us to more problems along the way.  The classic example is someone who only knows a hammer, so they just smash everything, which certainly doesn’t help in cleaning the dishes.  Understanding the range of actions we could use a tool can lead us to damaging things we don’t want to damage. Learning the limits of a tool helps us avoid damaging what we are working on and helps guide us to finding other, more appropriate tools, i.e. don’t use the hammer for washing the dishes, use a small cloth or sponge instead.

In Information Technologies, it is even harder as there are so many different tools for us to use on a regular basis and this is where I see this become a big problem and challenge for many of us. We get from one extreme of “must reinstall it all from scratch” or “upgrade” as a solution to everything, to the other of always looking for the perfect tool for every instance of the same thing and therefor taking much longer than is needed for a task.  The challenges for us is to find that happy medium of reusing known tools where every they are best suited and only hunt for other tools we are working in the greyer areas, as well as knowing when to stop using a tool because the rest of the environment has evolved such that the old tool is now a detriment.

 

Or as a fellow Knowledge Partner Jim Henderson put it in a forum post 2012-07-05

“Repair tools by their nature tend to run with the ‘safeties’ off. So
checks to make sure that things are clean before an operation proceeds
don’t happen, and that can leave things in an inconsistent state that
then necessitates further cleanup. ndsrepair is not intended nor
designed for day-to-day administrative tasks.

Use repair tools to repair known issues. Use diagnostic tools to
diagnose issues. Use administrative tools to perform administrative
operations.

If an administrative tool reports a problem trying to do an operation,
then use the repair tools surgically to address the problem.

Look at it another way: If you have a car that’s working fine, you
wouldn’t start the engine by whacking some part of the engine with a
mallet. Only after doing proper diagnosis and determining (for example)
that the alternator was stuck would you whack it with a mallet before
taking it to a mechanic to be serviced.”

Fragments of thoughts often outrun writing

I’ve always been the deep thinker with lots of thoughts flowing in the old wetware in varying levels of scatter and focus. This is a place where such thoughts may appear from time to time. Sometimes with long gaps in between, other times with a burst of them back to back. The best way to follow is with an RSS reader, though I believe you can also point more transient tools such as twitter to it as well. The initial WordPress offer to send tweets on my behalf asked for a tighter connection than is wise.

Initial thoughts are to use this space for my IT related posts, as I do have other spaces for the rest of my Adventures in Chaos that is life.

 

Beware the silent types, as that silence lulls you to a false sense of security before the surprise you. I don’t usually mean to surprise people when I walk up to them, but somehow that keeps happening.