53

A decade ago 800x600 was pretty much the standard resolution for devices and 5 sec response time was considered fast. Animations were minimal and websites were easier to read. Programmers debated around topics like which loop runs faster, i++ or ++i, while vs doWhile and so on. In general, we were closer to understanding what happens behind the browser curtain and how code needs to be organized to make it more maintainable.

Today the level of abstraction is much higher. I don't think devs can contemplate on the finer aspects of programming efficiency; they'd rather rely on a code library to do all the grunt work. With the explosion of devices and platforms, the focus has shifted from programming to assembling. Programmers need to know their tools first, then write code. The tool is expected to work well with a millisecond response time, not the programmer's code.

Moving forward, I think programming would be more about building higher abstraction utilities/libraries that are integrated by other tools, which is already happening. Marketing an App would become more important than the actual skill needed to develop it.

A bit far-fetched, but I think the future programmer would be a lot like a stock market analyst who has a bunch of windows in front, just observing data or algorithm patterns created by an AI engine and cherry-picking a specific combination of modules that might make the next big sensational app.

Comments
  • 7
    5 milli*sec
  • 10
    So sad but true.

    I think the programming job market has changed. To make money for living you need to know those fancy tools/toys. Your resume must be filled with trendy keywords. Nobody cares about your programming/problem solving skill anymore. So sad but true.
  • 9
    Very true.I once made small accelorometer based space Invaders type game in JavaScript and hosted it somewhere and I manually coded up EVERYTHING including collision detection.I showed this to my fellow compscience friends.They proceed to ask me why I wasted my time and why I didn't use a game framework.I always tell them it was for the fun of creating everything from scratch.
  • 8
    And then there's embedded where you still need an oscilloscope for software debugging. Looking at the disassembly is not uncommon when you want to know whether the compiler is really generating the expected code. People refrain from bloat because the next smaller chip is cheaper and needs less energy. You won't be using huge bloated libraries for anything even semi-serious because achieving code coverage during verification would be a show stopper.
  • 1
    @Bitkris IMO not because WASM just means that the same bloated stuff can run somewhat faster. The dev process will not change except for a final compilation stage in release mode.

    Theoretically, it could enable heavy client-side computations, but in a world where mobile internet usage has long surpassed desktop, nobody will do that because it drains the batteries.
  • 0
    This is what actually happens
  • 2
    Wow you said it very well. That's what I wanna say as well. But I could only say "going too fast" 😁 I'm that articulate.
  • 3
    Sounds like pandering to the false god of public opinion.

    Disgusting.
Add Comment