Balancing Learning

  • Comments posted to this topic are about the item Balancing Learning

  • Hmm, I've often found that those on the coal face perceive it as preferable career-wise to aggressively pursue the new strategy. This is often balanced by those responsible for guiding projects preferring to 'never take any chances'. Of course these are generalisations. I do know developers that cling to what they know and reluctantly learn anything new, this is not really what I'd expect in a decent dev though (maybe more in a banking sector than agency). Eventually however not taking chances means that you are way behind the current technology with no easy way to catch up.

    The answer in my career has often been to knock up prototypes of functionality in new tech or using new ideas to convince of the better way. It can be hard work but such extra effort has generally served me well. I am of course now (after 20 years toil) completely mental and find it hard to relate to people but you win some, lose some.

  • When it comes to leveraging a new feature or adopting a new technique, whether that happens tomorrow or months down the road also depends on if I'm currently working on new development or maintaining a legacy system with multiple team members. Whenever I start a new project; that's when I'll leverage something like a standardized naming convention or columnstore indexes for the first time.

    Some features like table compression or filtered indexes can offer an immediate improvement for a legacy database that's low risk and doesn't require coordination with other team members (just notification).

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • It is best too avoid too much new stuff at once. Be they techniques, tools, features or processes.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • I am the "newbie" in my group (I have worked here almost 3 years!). I have run into situations where I ask why a certain technique is used and not the new technique that I have read about. The answer is that they tried it 5 or 10 years ago and it was not good, or because of a bug in SQL Server...again 5 or 10 years ago.

    I use the new technique and make a case to show that it does work and that the old way is more cumbersome and inefficient. Of course not in a demeaning way, just showing the statistics that show the efficiency and that the code is more easily understandable.

  • Good article, Steve. Here's my $0.02 worth. I think adopting new technologies is more than whether or not you can add it, want to experiment with it, etc. Often its dependent upon your boss, what he/she wants and how fast. For example, I've been doing ASP.NET development for many years, but it's always the Web Forms stuff. I want to get into doing ASP.NET MVC. I've taken a couple of Pluralsight courses and now I'm ready to give it a shot. It would look good on my resume as well. I've discussed this with my current boss. She's not interested in my using MVC, because the other developer here doesn't know it. So, I'll do the project in MVC on the side, but I'll really be doing it in Web Forms because my boss has said that's what it's to be done in, due to the other developer not knowing MVC.

    (Sorry, I know this whole ASP.NET stuff is outside the scope of SQL, but I think it still relates.)

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Learning is a tricky balance.

    To get even moderately able at any new technique involves practice doing it, not simply reading. For this reason, I try to find a balance of trying out new techniques I learn, if not to solve a work problem, on my own time for my own skill development. But I also end up taking in a lot of information at a high level, but not learning the specifics because I simply do not have time to learn it, and will not have an opportunity to practice it.

    In those cases I work to learn enough to understand the concept and know the application, so that when an opportunity arises I can try it out.

    But even for the new techniques I could apply, there is still a battle to find the time to work with them. The developer/DBA is often a more scarce resource than CPU or memory or disk. So even if you know a new technique will be better, it is tricky to adopt if it will take you longer to develop and you have a lot on your plate. And it can be near impossible to apply this learning retroactively to things that have been implemented before.

    This is actually one of the more frustrating parts of incremental learning. You are constantly finding out how sub-optimal your old solution was, and rarely getting an opportunity to go back and fix it.

Viewing 7 posts - 1 through 6 (of 6 total)

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