Improving Skills at Work

  • Comments posted to this topic are about the item Improving Skills at Work

  • Can't tell you how often I've expressed interest in my company investing in developing those skills only to get a response akin to "that sounds great. So if you can just figure all that out, that'd be great."

    Executive Junior Cowboy Developer, Esq.[/url]

  • I'd figure it out with a proposal. I'll do this, company does that and we both benefit. It's worked well for me.

  • Steve, I agree with you 1000%. Where I work, we're experiencing a 30% vacancy rate. (The several reasons I won't go into now.) But there's culture here which is perpetuated both by the employer and employee. I've mentioned before that my employer doesn't invest in upskilling anyone in IT unless they must hold a certification for their job. But on the flip side the vast majority of employees do not want to improve their skills. There are a few exceptions, but I think it's less than 5 people and I'm one of them. I've been in this field for many years; I've worked in both the public and private sectors. Every IT shop (both operations and development) in all those places people were eager to learn and grow their knowledge and skills, with the single exception of where I currently work. It is so weird.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • What I've found is that a lot of employees have the proverbial 9-to-5- attitude and only want to improve their skills on the company nickel and on company time.

    And, if you consider that "new" technology is something that you don't know about, then the "Newest" thing people should hunker down and learn something that's brand new to them because a lot of them have been faking it for years... how to use SQL.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Most of my IT coworkers aren't even interested in improving their skills on the company nickel. They will only improve their skills if whatever old technology is permanently removed, so they have no choice but to learn something new. Under those circumstances they will complain very loudly. There are a few exceptions, but they're rare.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Rod at work wrote:

    Most of my IT coworkers aren't even interested in improving their skills on the company nickel. They will only improve their skills if whatever old technology is permanently removed, so they have no choice but to learn something new. Under those circumstances they will complain very loudly. There are a few exceptions, but they're rare.

    True dat.  Being "comfortable" is a very real thing.  Everything is working... change hasn't been mandated so folks don't know to what a change might be made.  We've also seen "gotta have it" languages and features die in their first release or shortly after.  If someone is comfortable with their job, the people they work with, and their pay, why study for a change that may not happen?  And, "hedging your bets" may not pay off.

    What grinds me a bit (a lot, actually) is people that applied to a job that requires good knowledge (like SQL) and they somehow passed themselves off as being good and then get others to do their job by posting beginner questions on a forum or worse, advanced questions that they have no hope of figuring out even if you give them a fully documented, coded answer and yet the applied for and got a job that requires such knowledge.  It's not just their fault, either.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Problem with learning on one's own [dt]ime is you can really only barely scrape the surface of all these techs going through books and training courses. The ecosystem is complicated enough that to really learn the stuff, you have to get your hands dirty and fail a lot at a real project. That's where it's critical companies invest in meeting those employees with the interest to learn half way.

    Executive Junior Cowboy Developer, Esq.[/url]

  • Jeff Moden wrote:

    What I've found is that a lot of employees have the proverbial 9-to-5- attitude and only want to improve their skills on the company nickel and on company time.

    And, if you consider that "new" technology is something that you don't know about, then the "Newest" thing people should hunker down and learn something that's brand new to them because a lot of them have been faking it for years... how to use SQL.

    I see this often as well. What's worse, I find many people don't even want to improve skills at work. These could be people just marking time and doing their job, could be people carrying the proverbial clipboard, or it could be old hands that think they know it all.

    I've been writing SQL queries since 1990. I still learn things by experimenting and trying new things. I get that my job gives me more flexibility, but I also think I've had the attitude that technology is cool and I should play with it regularly.

    I'm chastising myself slightly this year for not even starting the Advent of Code in SQL.

  • Xedni wrote:

    Problem with learning on one's own [dt]ime is you can really only barely scrape the surface of all these techs going through books and training courses. The ecosystem is complicated enough that to really learn the stuff, you have to get your hands dirty and fail a lot at a real project. That's where it's critical companies invest in meeting those employees with the interest to learn half way.

    Absolutely true.  I'll also say that having someone, that's actually good at it, show you the ropes and then the finer points is worth that person's weight in gold... especially if they get the "order of revelation" correct.

    This is especially true since the documentation and examples therein are frequently difficult to follow, insufficient or poor examples, and can be incorrect.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • @jeff Moden, I really like what you wrote in response to my comment! Being comfortable is a real thing, as you say. And I've been guilty of doing that, too. I've learned my lesson, though.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Steve Jones - SSC Editor wrote:

    Jeff Moden wrote:

    What I've found is that a lot of employees have the proverbial 9-to-5- attitude and only want to improve their skills on the company nickel and on company time.

    And, if you consider that "new" technology is something that you don't know about, then the "Newest" thing people should hunker down and learn something that's brand new to them because a lot of them have been faking it for years... how to use SQL.

    I see this often as well. What's worse, I find many people don't even want to improve skills at work. These could be people just marking time and doing their job, could be people carrying the proverbial clipboard, or it could be old hands that think they know it all.

    I've been writing SQL queries since 1990. I still learn things by experimenting and trying new things. I get that my job gives me more flexibility, but I also think I've had the attitude that technology is cool and I should play with it regularly.

    I'm chastising myself slightly this year for not even starting the Advent of Code in SQL.

    The Advent of Code is fun but I like the real life problems better.  For example, I was researching what some people thought about a certain couple of date topics and ran into one I didn't expect.  It's for the conversion of what people mistakenly refer to as "Julian Dates.  In this case, it was for the CYYDDD (YYDDD prior to 2000) format that J.D.Edwards uses.  Even a well know MVP got that one wrong and, OMG, the throws they go through.  I checked for that issue here on SSC and found a very old post where Lowell got it right and sweet and added my simplification to his good code.

    On that same subject, I didn't realize how few people actually know what INTEGER DIVISION is (Lowell certainly did).  I've also found that there are very few articles on the subject (part of which led me to write about the UNIX Timestamp conversions).  I'm starting to put together thoughts and code for an article on INTEGER DIVISION in temporal calculations.

    Again, the purpose in saying that is the real problems I run across on forums are my "Advent of Code" and they're almost as fun. 😀

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I am working to improve my skills in DevOps and/or cloud and my biggest challenge is this.... My day-to-day org is not very technically mature meaning my direct users mostly cobble data from text files to spreadsheets. Case in point, shifting to PowerBI  is a leap for them. For me to take on more cloud-oriented projects will ultimately mean that I would be the one solely supporting them (both the solutions and the required cloud infrastructure). There will be budget considerations if I were to propose adding more cloud services beyond what is currently in scope for this relational data mart.   In the long run, I don't know how much practical exposure I can obtain in my current role. Thoughts??

  • My uncle got into programming in the 1980s and as a COBOL programmer was in high demand in the mid to late 1990s due to the Y2K fix. Unfortunately he expected that demand would last forever and refused to learn any new tech. His company tried to send him on courses or to study for certifications - they tried to get him to grow, but he was comfortable in his rut. Eventually they let him go. He never worked in the industry again, and blamed "ageism".

    I learned a very important lesson from him. I've been in IT over 25 years now, and I'm always pushing myself to learn new things. You never know which "hot tech" of today could become a standard tomorrow.

  • kwebb wrote:

    I am working to improve my skills in DevOps and/or cloud and my biggest challenge is this.... My day-to-day org is not very technically mature meaning my direct users mostly cobble data from text files to spreadsheets. Case in point, shifting to PowerBI  is a leap for them. For me to take on more cloud-oriented projects will ultimately mean that I would be the one solely supporting them (both the solutions and the required cloud infrastructure). There will be budget considerations if I were to propose adding more cloud services beyond what is currently in scope for this relational data mart.   In the long run, I don't know how much practical exposure I can obtain in my current role. Thoughts??

    I am right there with you, kwebb, although that's not much comfort. It's nice to know I'm not the only one in this situation. Words of advice to offer you - not much. The best I can do is give you some of my sad tale.

    In March 2023 I'll have been in this job 8 years. The struggles I've faced were at first irritants but have recently escalated to major. So, just focusing upon the last few years I'll start with the beginning of the pandemic. We, like the rest of the world, realized that we'd have to do things remotely. The meant going to the cloud, which in our case was Azure. This had never been done at work before which I think was because no one in operations wanted to learn how, until then. After several online meetings with Microsoft, countless tweaks to router rules (on both sides) it all suddenly came to an end without being implemented. No explanation, it just stopped. I don't know if our Security team lacks the skills or what, but it was clear that something wasn't working, so we threw the towel in and left everything on-prem.

    Just like you, I've been working in and learning more about DevOps. As far as tools go, Azure DevOps Services (AzDO). During the pandemic we got into it in a small way. I had hopes of improving our software delivery, quality, etc. As you know, tools by themselves don't make for a successful DevOps adoption, so slowly this has failed as well. Some in upper management wanted us to go backwards to our on-prem TFS 2015 instance. None of the developers (including myself) want to do that. We had, so I thought, convinced management that the path forward is AzDO or possibly GitHub (GH). However, some meetings have occurred over the last 3 weeks, which I wasn't invited to, where management decided to go backwards to TFS 2015. Supposedly, the ultimate direction is to go to GH, but conveniently money for AzDO runs out at the end of this month, and new funds for going to GH will happen "sometime next year".

    None of this is good or encouraging. As Marley's ghost said when speaking with Scrooge, I've no comfort to give. I can't promise you'll be visited by ghosts whose visitations will help, but I will leave you with a tip and one last observation. If the majority of people you work with, have no desire to learn anything new, then there may be nothing you can do about where you are. As Carl Franklin of the podcast Dot Net Rocks says, if you can, change your company. If you can't, change your company.

    Last observation, we've been experiencing a lot of turnovers recently. One of the biggest positions to leave is the head of our Project Management Office. In an all-IT meeting, she said the most damning thing of all (although she backpedaled a little from the comment). She said that after working here for a few years, the issues we face and the unwillingness to change, lead her to decide to move on. She said that the changes required in culture are significant enough that it might require legislative action to fix. (We're a large state department, so this comment, although extreme is possible.)

    Kindest Regards, Rod Connect with me on LinkedIn.

Viewing 15 posts - 1 through 15 (of 32 total)

You must be logged in to reply to this topic. Login to reply