Tim Holloway wrote:
Monica Shiralkar wrote:
However, when the old pro spends 5 hours thinking and planning and 2 hours coding whereas the new pro always look busy, the managers think that old pro has laid back attitude and is not doing that much hard work as rest of the team. This should ideally not happen but practically it happens often.
One of the biggest flaws in the human brain is its tendency to equate motion with productivity.
Given the world a choice between paying Brazil to let the Amazon forest basin sit undisturbed and operating as a global biological cleansing mechanism versus not paying and having Brazil clear-cut it down to another Sahara, it's very, very hard to get people to pay to "do nothing". To say nothing of in a more realistic model, too many people in Brazil wouldn't sit for leaving a resource unexploited where there are jobs and business it could generate in the short term as opposed to many generations.
So it is with software. Just about all of us have solved some of our stickiest problems not when we were "at work", but rather in bed at 3AM or in the shower. Sitting staring out the window isn't "working" and - my own biggest pet peeve - hours in chair is not productivity. Software isn't like hamburger where the more hours in the day you grind, the more software you get. Useful software, anyway. And even a hamburger grinder run overspeed outputs cooked meat, not actual hamburger.
COVID has done us a favor in that regard. It has demonstrated concretely that fighting your way through traffic to park in a chair at a desk for 8 hours or more a day isn't more essential to the economy than work-from-home in many cases.
Tim Holloway wrote:Ageism.
I first faced static about my age in 1989. Then again, that was the worst employer I've ever had, bar none.
I actually missed the CORBA fad, although ironically I worked on a CORBA project for someone several years after CORBA had died out. Poor guy.
The point that HR departments (well, one of many points, ) miss is that while you might not have been taught the latest shiny technology in school - and actually, I don't recall specific technological platforms being class studies anyhow - what you have learned over time is often more valuable. Unlike the so-called "real world", computer people do learn from history, and while that doesn't mean that each new technology is inevitably closer to perfection (I present the warts in Java for example), it does mean that you have examples from the older stuff that you can leverage. Including having learned what actually works and what doesn't.
The trick, of course, is to recognize what's special about the new platform and not blindly try to force it to behave just like what you're used to. I knew someone who got frustrated trying to write Pascal like it was COBOL, Python has a different mindset than Java, and you wouldn't believe the number of people who check into the JavaServer Faces forum with "solutions" that attempt to program JSF like they're used to programming raw servlets - JSF is an Inversion of Control architecture and many people have a hard time wrapping their heads around the idea that the framework automatically delivers stuff to you rather than making you write code to go out and get it. Or that JSF is based on POJOs and that very little well-written JSF code is actually JSF-specific.
Anyone who wants the good old days where you were the person who was responsible for the COBOL payroll program on the mainframe and that's all you did until the day you retired on a pension is out of luck. I figure I'm likely to end up sucking up a new technology no less often than every 24 months, if that. Fortunately I enjoy that sort of thing.
The real problem isn't in old dogs learning new tricks, it's that Hiring looks for cheaper people who won't object to being forced to work insane hours. And most people who aren't young anymore have had enough of that.
Chris Crawford wrote:
By the way, did you know that the 6502 opcode for loading a fixed byte into the accumulator is $A9? 😛
Simon Ritchie wrote:Hi everyone,
Next month I'll be starting in a new role as a mid-level Java developer with a successful startup. The architecture is a microservices design, which is something I've a couple of years experience in thanks to a similar role I once had with a large multinational. I'm keen to start well in the new role so I thought I'd ask some advice here.
What is the best way you've found to come up to speed on a new codebase? Are there any tips or recommendations? I've always found the first couple of months in a new role intimidating because, on top of all of the new technologies you've to become familiar with, you're also confronted with this massive codebase that's often difficult to understand.