After X Years

  • Comments posted to this topic are about the item After X Years

  • Good post and I agree.

    I'm 30 years old and while I do love to get going, failure to plan is planning to fail.

    However, about older programmers. It's not that uncommon that people stop to learn stop keeping up with the progress. Science has actually proven that it is slightly painful for our brains to learn so that might be a reason for it. I have however no statistics to back up my hypothesis.

    It would also seem like most people gets out of pure programming around their 40-50s. This too is only my own observation and has no statistical claim. However, since we humans after all are pack animals and when a few are doing something most does not it looks strange to us even if we dont want to admit it.

    What do you think?

  • omg do I interpret this correctly? you have programmed for X years and live in Manhattan close enough to CP to ride your bike there and around it? two of my absolute favourite things, programming and NYC, not necessarily the biking part. does life get any better? if only.

    when you specified the years and did the math, I realized that I've also been programming for 37 years. I never realized. well, it's not quite as simple as that and I'm not a real programmer anymore and programming comprises only part of my job and that, of a very rudimentary genre, but no need to elaborate, I just need to say that I LOVE programming, I do think it very creative and I soooo appreciate 'elegant' code; if you've ever had to maintain code written by a programmer who likens unto - well, I don't want to diss anybody in particular, who could pick? - let's just say, any of the recipients of the annual Razzies - you would have either given up in despair or buried yourself more deeply into the 'wonderful world of do whiles' - that's the only alliterative phrase I could come up with - with which I could come up - and as I say, programming, alas, is no longer my major responsibility and I'm waaaaay out of the mainstream and now only look on with envy and can't cleverly cite any of the latest terms but my soul is still there and if I could, I too would go on for many years and would never have gone into management even if anybody had ever asked me - which of course nobody ever did. Real programmers who program from the heart are a sadly under-appreciated lot. way more than enough said I'm sure.

    my congratulations and best wishes.

  • "I heard a great quote recently from Abraham Lincoln that I think applies. He said "If I had eight hours to chop down a tree, I'd spend six hours sharpening the ax."

    I totally agree, and I would add that I have seen way too many people in the past try to chop down the tree with a sharp Swiss Army Knife. You have to be using the right tools for the job as well as do the appropriate planning and architecting upfront.:-D

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • Or you could use heavy duty material to remove the tree (bulldozer, tractors, chainsaws...). The options keep growing.

  • Very well stated.

    I would go a step further and say that it would be really nice if higher level management understood and practiced this philosophy.

    The probability of survival is inversely proportional to the angle of arrival.

  • I've been programming/developing/engineering code for 27 years. At the start of my career, I worked with a gentleman in our development group who was doing some pretty mundane programming tasks. He had a PhD in Chemistry and had drifted into doing software development. Therein lay his problem: he really wasn't motivated enough to keep current and remain curious about the cutting edge technology. When layoff time came, he was one of the first to go.

    I took a good look at that situation and promised myself that I would never let that happen to me. If I ever lost interest in keeping up with emerging software techniques or learning new skills (like database programming), then it was time to change careers. This business requires that you keep your past fresh in your mind and embrace the future.

    I like TDD because it makes you think about what your expectations are of the code before you write it. You just can't dive in: you have to put some thought into it first. I find myself mapping out the various aspects of the problem up front, generally using a tool like MindManager, then I start developing my unit tests and the corresponding software. By the way, the mapping also helps with the CI end of things so I can deliver functional elements on a daily basis that are consumed by QA and other interested parties.

    Thanks for listening...

  • pardon my not-up-to-datedness, what's TDD?

  • Jo Pattyn (6/14/2012)


    Or you could use heavy duty material to remove the tree (bulldozer, tractors, chainsaws...). The options keep growing.

    Jo,

    Depending on the size of tree (job), correct. It's all about having the right tool(s) for the job at hand. I have seen far too many people struggle in the past unnecessarily. Managers and CIO's tend to still think in the "pocket knife" mind-set, simply because its the cheapest. 😀

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • TravisDBA (6/14/2012)


    "I heard a great quote recently from Abraham Lincoln that I think applies. He said "If I had eight hours to chop down a tree, I'd spend six hours sharpening the ax."

    I totally agree, and I would add that I have seen way too many people in the past try to chop down the tree with a sharp Swiss Army Knife. You have to be using the right tools for the job as well as do the appropriate planning and architecting upfront.:-D

    And I'd spend 15 minutes getting some dynamite, 10 minutes setting it up for safe use, less than a second blowing the tree's trunk, and then take the rest of the 8 hours off for goofing around on TreeStumpRemovalCentral.com. 😀

    (In other words, yeah, I've seen far too many doing exactly what you wrote. Or worse - SQL equivalent of chopping down a tree with a spoon or a water baloon.)

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • pardon my not-up-to-datedness, what's TDD?

    TDD and CI are Agile concepts/terms/practices:

    TDD = Test Driven Development

    CI = Continuous Integration

    They aren't silver bullets, but when done well, can really improve your software quality, production velocity and delivery capabilities.

  • j_e_o (6/14/2012)


    pardon my not-up-to-datedness, what's TDD?

    TDD and CI are Agile concepts/terms/practices:

    TDD = Test Driven Development

    CI = Continuous Integration

    They aren't silver bullets, but when done well, can really improve your software quality, production velocity and delivery capabilities.

    thanks, I'll google those and get daily dose of education sunshine - a day without learning is a day without sunshine. wine too.

  • Some good points made here. As usual, it isn't as open and shut as it might seem. Sometimes older workers have a lot to offer, sometimes they can be stuck in a rut and not open to new ideas. Sometimes younger workers are unwilling to listen to other ideas, sometimes they bring new ideas to the plate but are willing to work with a team to determine whether new designs are better or not. Both older and younger workers have pros and cons - none of us are perfect.

    Personally my preference is jump right in and start coding a bit to prove the concept, then stop and refine the design, then do the actual coding. You don't need a final design to start, although generally that will lead to some code being thrown out. What you gain is an understanding of what will have to be done to make it work, which in turn allows you to create a better design, which allows for a better written program, which results in success.

    For those who stick to design until it is complete and then start coding, they end up going through the entire cycle as well, with maybe fewer or greater iterations, but usually ending up the same way.

    The point is, you can't design in a bubble, you can't code in a bubble, but if you merge the two and let them play off each other, the end result is always far better.

    Dave

    Dave

  • IceDread (6/14/2012)


    However, about older programmers. It's not that uncommon that people stop to learn stop keeping up with the progress. Science has actually proven that it is slightly painful for our brains to learn so that might be a reason for it. I have however no statistics to back up my hypothesis.

    It would also seem like most people gets out of pure programming around their 40-50s. This too is only my own observation and has no statistical claim. However, since we humans after all are pack animals and when a few are doing something most does not it looks strange to us even if we dont want to admit it.

    What do you think?

    Well, as a programmer of 38 years I read 2 SQL newsletters per workday, plus I have 18 RSS feeds from SQL and LightSwitch blogs/sites. There's so much to keep learning and improving my craft, plus increasing value to my employer and keeping their costs down by what I learn. I hope I never stop learning - Excedrin in my pocket!

    I've bumped into the arcane notion that "we" must advance only via management several times. The first enabled me to propose becoming a contractor at the same desk after 3.5 years, which was gladly taken up for another 1.5 before I emigrated to the US from the UK. However, my first employer in the UK saw they were losing technical staff, so they invented a two-branch path, one into man/project management, the other into internal technical consultancy; the latter dealing with strategic technology issues as well as architecture and when needed some actual coding, plus they were an incredible fount of knowledge for questions about the why and wherefore of a system function. This actually worked well and retention/progress eventuated from this wisdom (early 1980's).

    One thing about "oldies" really encouraged me recently. At the Orange County, CA, SQL Saturday I spotted not a few grey-haired gentlemen, but the oldest must have well into his sixties and was there, attentively learning with the young-uns. Great to see. Kudos to him!

    Great post by Dave. Hope it gets the kind of visibility that brings down the walls ageing presents in the programming world.

  • djackson 22568 (6/14/2012)


    Personally my preference is jump right in and start coding a bit to prove the concept, then stop and refine the design, then do the actual coding. You don't need a final design to start, although generally that will lead to some code being thrown out.

    Very well said. I think younger programmers are more likely to not throw out code, or to just code the final design from the start.

    Older programmers might tend to the other extreme, spending too much time trying to get a perfect design, but I'd hope that their experience would lead them down your path. Knock together a simple concept, something you are willing, really willing, to throw away, and use that to start doing more detailed design.

    This is a great place where Powerpivot works well in the BI area.

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

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