While not an official part of DevOps adoption, continuous learning will only strengthen any DevOps environment you implement.
Join the DZone community and get the full member experience.Join For Free
In case you can't tell from some of my blog posts, I'm a bit of an advocate for DevOps. I'm extremely fortunate in my employer, Redgate Software, that they are also huge advocates for DevOps. We not only teach it and promote it, and, oh yeah, make AWESOME tools for it, we practice DevOps in what we do.
However, this post is not about DevOps. Instead, I'm trying to leverage some of the concepts of DevOps, Continuous Integration and Continuous Deployment, to arrive at some ideas around learning that I want to share.
Yesterday I spent several hours getting the software Pi-Hole set up for my home network. Now, this software really doesn't take several hours to set up. The reason it took me that long is that I hadn't been keeping up with the software on my Raspberry Pi. So I spent quite a bit of time getting new versions of the OS and various other things set up. Also, I had to deal with the challenge of the location of my router, where I was going to put the Pi, and the fact that there weren't any monitors near there. So I'm futzing about with hardware, software, the network, cables, you name it. Hence, hours.
Why go to the trouble?
Well, first and foremost, because Pi-Hole has made the internet at home much faster. I mean it really works. So, there's that. However, more important to me was the act of learning how to do it.
I'm Not An Expert
I hate that term. I guess I shouldn't, but it's wrapped up around the imposter syndrome (which I suffer from constantly) and the emotional baggage that's associated. I'm not an expert. I just spend a lot of time learning. So the Pi-Hole experiment allowed me to spend a little time mucking about in an OS where I'm not as comfortable, Linux. I get reinforcement on how to use the good ole Super User Do command (
sudo) and a bunch more. However, I'm not a Linux expert. I'm just adding that knowledge to the bucket.
I've had a lifelong fascination with radio. Finally, a year ago, I got myself together and passed the test for Technician (KC1KCE is my call sign). I've spent the last year fooling around with a couple of handie-talkies and I put a quad-band FM radio into my beloved Jeep. I'm currently studying up in order to take the General exam so that I can move on to High Frequency (HF). I've already purchased the radio and I'm going to be spending lots of time on weekends and in the evenings getting it set up. However, I'm not a radio expert. I'm just learning this stuff.
I'm really not an expert. Instead, what I am, is a learner and a sharer. I learn something, I can't help but share it. My poor suffering family. Every time I get something new that excites me about SQL Server, radio, Linux, World War One, or whatever other learning passion I have, I share it with them. My wife is amazing at sounding just almost interested until I run out of steam and notice that she really doesn't care how the National Weather Service uses radio with reports from volunteers (I've made TWO in the last six months or so) to get more detailed information on storms. Yeah, I just bored the heck out of you, too, right?
So, it's not about being an expert. It's about learning and sharing. What I'm trying to share with you now is the concept that you, too, need to be learning. Further, it really doesn't have to be about things that are immediately applicable to work. I get it. Your organization is never going to the cloud. So what? Sign up for the free tier on one of the cloud services and learn about it anyway. Get a Raspberry Pi (they're cheap) and learn about a new OS. Better still, instead of installing the software like I did, grab a Pi-Hole Docker container. Yeah! You can set up Pi-Hole through a container.
The key is to continuously pick up more knowledge. You need to do this. The curse of IT people is that some of them stop learning. They get enough info to get the job. They learn how to do the job within the parameters defined by the organization. This takes maybe a year. Then, they stop learning. They don't explore new ways of getting things done, new versions of the OS, nothing. They work for the company for 10 years, doing the same thing, day in and day out. They're happy doing it. I'm not knocking this.
Then, they lose the job. The company went under and they're on the job market. Only now, they've got ten years of experience with SQL Server 2008. However, the jobs are advertising for SQL Server 2019 and Azure SQL Database. They get asked in an interview how to do a point in time restore. They've never even heard of what that is because they didn't ever need to do one. They get asked, and I absolutely ask this, "How do you go about learning new technologies and new methodologies?" and their answer is "I wait until my company sends me to a class" and our interview is largely over because this isn't someone I want on my team. I want the people who are going to add to their knowledge so that they add to the team's knowledge. Further, they know where to go to get help, because those are frequently the same places you go to get more learning on (SQL Server Central, SQLSkills, places like that, learning and help).
You work in technology. You should be continuously learning. It doesn't have to be hours a day. It doesn't have to be your entire weekend. You don't have to invest thousands of dollars. However, it's on you, to ensure your continued value to your current employer and your desirability to a future employer. No one else is going to do this for you. You have to do it for yourself. So, get out there and learn.
Speaking of learning and DevOps. I have a couple of paid events coming up where I'm going to spend all day talking about process, process development, communication, culture and tools, all in support of getting your database into a DevOps methodology. Let's get our learn on together:
Published at DZone with permission of Grant Fritchey, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.