Tag: career

  • Experiment First

    Not too long ago, I had a sales engineer contact me about a script that a customer needed. It was similar to others we have for various Redgate tools, but also different enough that the customer needed help. In fact, I also needed some help.

    I asked a question on Twitter, mostly because I was busy and wanted to know if someone had solved the (partial) problem that I had. I got a number of responses, none of which were direct solutions, but many of them contained some hints. At the time, I filed these away because I didn’t have time to work on anything, but I knew that asking the question gave me a few starting places.

    A day later, I started to experiment, but ran into a few issues. The PoSh script wasn’t doing what I expected, which is always frustrating. I almost started to ask questions, but then I decided to work through the process. After all, I’d already interrupted friends on Twitter with my original question, and I ought to experiment a bit before I asked others to do my work for me.

    This was a script designed to find the latest files and build a restore. My first problem was that no data came back from the backup set. I double-checked my data, but didn’t see anything. I then set a variable for the parameter and another to get results. I started to get some information, which led me to review my work again. I realized I’d mis-typed something as a direct parameter, but had corrected it in the variable assignment. First lesson, really proofread carefully.

    The data I first got back didn’t quite make sense, so ran this through Get-Member. I didn’t find any property that looks like what I wanted, at least not intuitively. Rather than ask or post a question, I started just checking properties. Eventually I realized the data was there, but not under the name I’d have used or expected. Sometimes just digging through the properties and methods is the best way to learn.

    Lastly, with a bunch of data in my object, I needed the top 1 item. Stack Overflow helped point me in the right direction, and I solved my own issue by reading a few different things people had done. With a little research and experimentation, started off by a few questions of others, I had a script that I could give to a customer.

    While our management might expect us to know everything about our jobs, often they know this isn’t the case. Technology and platforms change quickly and expand widely to the point that few of us know everything about anything. What management and others really expect is that we can learn to solve our own problems, with some help from others, but also some ability to learn and experiment.

    At SQLServerCentral, we have great forums for SQL Server questions. Stack Overflow is a great spot for lots of general technology queries. Plenty of people are willing to help, but often with some sketch of a solution, expecting you to do some work to mock a scenario and then take answer and adapt them to your environment.

    There are lots of people in the world willing to help you, but they don’t want to do your job. Ask questions when you don’t know, but also plan to spend your own time experimenting and learning about how and why an answer might work. Before you post a followup question, be sure you experiment and see what you can teach yourself. You will likely learn something and maybe next time you’ll be the one answering a question for someone else.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Aging in Technology

    Every winter my wife flirts with the idea of returning to a corporate job and making more money. Winter is a slow time for horse training, and she gets bored and antsy. Horse training is physically hard, and as we talked about it last year, I said she should continue with horses for a few more years and then go back to a career later if she wanted.

    Her response was that it would be much harder at 60 than 50. Perhaps, but I think her success in the business world and a strong set of skills wouldn’t much matter, but I did get her point. I’ve had a few other people express similar concerns.

    I had a good friend that spent most of his career in IT. He left the military and found a job with a large telecommunications company in Denver. He worked there for decades, raising three kids similar in age to my own. We chatted often at Scouts about life, technology, and kids. He was laid off a few years back, and as someone trying to find a new job in technology over the age of 50, he struggled to even get interviews. He spent a couple years looking and then mostly gave up, moving to other types of work at a much lower pay.

    I wonder how many of you worry about employment as you get older. I know early in my career, it was the graybeards that were the most respected in the mainframe world. At some point, we started to look to the young hot shots working on PCs as the most respected technologists. I think we often look for younger, but not necessary young people when we hire. In fact, I spoke with someone recently that struggled to not discriminate against older people when they learned about ailments that a person might have.

    I read some great thoughts from Dr. Greg Low that got me thinking about this. After all, I’m getting older, and much closer to the end of my career than the beginning. I think that I’m more willing to learn than most. I preach this to many of you, the idea that we need to keep learning. I’m very lucky that I have a job that encourages and allows me to learn on a regular basis.

    I do think there is some ageism in the technology field. I also think there is a lot of pressure to reduce costs, so if you’re not providing a a lot of value as a worker, why not replace you with a cheaper individual that can do the same job? At least, plenty of management thinks that way. I also think lots of hiring people that are younger think that health and stamina are lower and older people (or women) and feel they can’t keep up.

    The cloud and automation are changing the way more and more us approach our jobs. We need to have strong soft skills, in addition to technological ones, and we need to prove we can solve problems, not perform tasks by rote. Those simple things are getting automated in more and more places. While I don’t think we’ll get to the point that we dramatically automate away most jobs, DBA or developer, but the bar for skill and talent is being raised, especially when you look for  a new job, so ensure you’re regularly raising your bar.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Priorities and Productivity

    Time is a resource for all of us, both at work and in our lives. As I get older, I think time might be the most valuable resource I have, the same amount each day, but an ever decreasing set in my life. As a result, I try to avoid wasting time and taking advantage of what I have when I can.

    At work, we often have more tasks than we can complete in any point in time. I have rarely been without work, though certainly there are slower times when deadlines aren’t providing pressure to get things done. For many of us, we can struggle to manage our work, especially without strong management to help us.

    There was an interesting blog from Trainline, from a technical worker that was promoted to manager and had a whole new set of tasks and responsibilities. He decided to adopt some of the same agile principles he used as a developer to manage his time. It’s an interesting read, and perhaps one that might help some of you better organize your own work.

    The principles of Lean Thinking and visualization are two of the items he used, along with building a Customer-Value map. You can read the basic descriptions, but to really understand how these concepts work, you will want to do more research and spend some time practicing the concepts. However, there are a couple of other techniques in the post that I think are worth pointing out.

    The idea that work has an effort and value you can use to help determine which tasks are worth tackling is important. I think sometimes we consider value without effort, but organizing tasks into grid is useful. There is also the concept of important v urgent tasks, and how these two may or may not be related. As I read about these, I realize that I often do this internally with my work.

    I know there are important things to do, many of which aren’t urgent. Finding time to get those done is useful, not only because they get off my plate, but the more often I can avoid creating urgency, the less stress I have. I also find that urgency can sometimes be my own fault for procrastinating a task.

    There are certainly many times when managers will prioritize work for us, but I often find for developers and DBAs, that we have a fair amount of autonomy. Many of us also have a known backlog of work. Developing some skill and techniques to manage your own workload will serve you well, and you might consider adopting some of the ideas in the post in your own career.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Searching for Answers Inside

    How easy is it for you to search your codebase, especially across projects, and find out if there are dependencies, similar code solutions, or even other incidents of similar problems? Do you feel comfortable that you can find out what you need to know across and throughout your organization?

    Or is it cumbersome for you and others?

    In the 2019 State of DevOps report, one of the important areas that designated high and elite performers was their likelihood to easily find internal information. Those users were more productive when using internal sources of information to find knowledge related to their work. They also know how to, and are able to use external sources as well. I certainly know that if I needed to write T-SQL everyday, having access to the SQLServerCentral forums would be invaluable for me, and I’m sure it is for many of you as well.

    I think one of the very hard things for inexperienced people in any organization to do is find information. So often knowledge is gained over time by employees that have spent significant amounts of time working on systems. No matter how much we might preach and mandate documenting things, many items won’t be written down. Over time, many of us internalize lots of information that might seem obvious and unimportant to us, but is necessary for more inexperienced people to succeed at different tasks. If you doubt this, just look at any DR test where someone tries to follow the directions written by experienced pros. They’ll fail almost every time because we don’t document every step.

    I’m not sure we should even try. I think the idea of trying to help others more easily find information is a better solution. Having tools to enable this can certainly help new people get up to speed quickly, as can group programming (or administration) efforts like pairing or mob style work. We might not easily ensure someone could pick up the pieces if no staff were around, we can make it easier for those that want to learn and succeed to seek out the knowledge they need.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.