[BiteCode_dev]

I'm not sure about that. I do see a lot more intellectual rigor in the older techies than in the ones from my generation. Just basic grammar illustrate that well.

And it makes sense, if you can't rely on automatic systems to do part of your work, you will be trained by your daily tasks to be a more powerful thinker.

If what the company do is hard, being ok will not cut it. You cannot google your way into innovation, you can't copy/paste architecture design, and your calculator won't save you from a logical mistake.

I'm personnally very adapted to agile envs with margin of errors and a lot of feedback loops. But a waterfall is more challenging, because I'm not born in it. And you don't use scrum to build the path to moon landing.

More than that, I arised in the "a good dev is lazy" period, where working smart, not hard was praised. But hitting 30, reality calls back: there are no shortcut to awesomeness, you will have to work hard. And not many engineers are ready to do so. The ones who do often create their company.

[DaiPlusPlus]

> I do see a lot more intellectual rigor in the older techies than in the ones from my generation.

My experience has been the opposite - though as this is based on observation it's obviously subjective - and opportunities for selection-bias are also present (i.e. how many of the last-generation that didn't get promoted-out of being a technical contributor was because they were more valuable to the company that way?)

Your remark about automated tooling is interesting - because I feel that modern tooling (TLA+, Z3, constraint-provers, and cutting-edge languages like Haskell, Idris, and so on) really do require almost a postgraduate-level of understanding of the CS theory involved - whereas if you look at _the SE scene_ in the 1970s and 1980s - or even the mid-1990s, the tooling certainly did require you to do more planning and reasoning ahead of time (VB6, lol) but I can't see the entire industry of the time doing their modelling and verification entirely by themselves: on the contrary (and based on the horror-inducing programming code I've seen) a lot of it was ad-hoc and trial-and-error - Visual Studio didn't get built-in support for unit-tests until 2008 (or 2005 if you had the expensive edition). Also consider that the old SE processes used back then (Waterfall, boxed software, slow-moving-and-big release cycles, etc) meant there was more room for less-rigorous folks in large software dev teams.

> and your calculator won't save you from a logical listake.

For that, you need a spell-checker!

UPDATE: Ah, you edited your post, which ruins the joke :/

[Pamar]

With all due respect, I think you are mixing apples and oranges here. "TLA+, Z3, constraint-provers, and cutting-edge languages like Haskell, Idris, and so on" is not exactly the bread and butter of IT work nowadays, so why do you think it is appropriate to compare it with "VB6, lol"?

[DaiPlusPlus]

(When you say "IT work" - are you referring to software-engineering work specifically - or "IT" in general? (I'm personally not a fan of "IT" as a term at all because it's unhelpfully vague[1]).

I wasn't comparing them directly like that.

My point is that in the 1990s if you used VB in production systems then you would effectively be forced into investing a lot of company resources - and mental effort - into all kinds of entirely disconnected approaches for formalising, proving and even testing your system. Whereas the state of the art for formalising SWE work today currently lies in tools like TLA+, Z3, and others and how it's significantly easier to map those formal models to our production program code back-and-forth (when written in more expressive and formal-friendly languages like Haskell, etc) than it was 20+ years ago.

Back then the sheer effort involved to perform even automated unit testing and integration testing of VB6 code, and other languages of a similar nature, was massive because, not least, the VB6 tooling completely lacked that functionality, and their lack of terse expressivity meant time spent just writing repetitive code with little value - and things were tenfold worse if you were using one of the myriad proprietary other 4GL languages of the time because most of those vendors swore-off any kind of interoperability or extension mechanism because they saw them as a threat to their business model (as a textbook example see Progress' utterly laughable defense of maintaining their position here: https://www.progress.com/tutorials/odbc/open-source-database despite their market-share shrinking and the company quickly pivoting away from their own database system and onto being a generic component/tooling vendor).

Even so, I'm not being ageist: VB6 wasn't state-of-the-art when it came out: Java is older and far better in that regard (VB6's type system is very anemic). I was singling out VB6 for criticism specifically because even back then it wasn't very good, it's just disappointing that so many people used it as the basis for production systems.

[1] Whenever UK friends and relatives refer to me as "working in IT in the 'states" I outright deny it: I really don't feel that I work in "IT".

[Pamar]

Whoa, a fellow PROGRESS user?!

Anyway, thanks for the answer. I am not sure I completely agree with you, but at least now your point is more clear.

[DaiPlusPlus]

I’m not a Progress user. Instead I get paid lots of money to help companies move-away from Progress to Postgres :)

(Which in practice just means figuring out how to get their bloody “SQL Broker” processes running then dumping everything over ODBC. In order to circumvent the arbitrary and unfair “Users/Connections” licensing restrictions I reversed Progress’ super-seeekrit program code to figure out how their license keys worked and made my own keygen in a weekend, that was fun - I got paid to do that too!). The fact it’s possible to slam out software within a few days while drunk-and/or-stoned (I don’t remember, lol) that undoes Progress’ entire business-model built-around vendor lock-in shows what a house-of-cards they’ve built for themselves.

[Pamar]

I would like to say I have a job for you but I am afraid that this kind of decisions is way above my pay grade.

Still... drop me a line in mailbox, maybe? (You can find my contacts in the profile).

[hwayne]

VB6 > TLA+

[jimnotgym]

> I do see a lot more intellectual rigor in the older techies than in the ones from my generation

I have a theory on this. An architect in private practice told me a couple of years ago how he was having trouble getting good junior architects, so was resorting to graduates. He felt his small practice was not the best place for a rigourous training. He recounted that in the past there was a giant pool of qualified and experienced staff coming from the councils, railways and public utilities. There was also a similar pool of state supported industry, Rolls Royce, BA etc. These positions took graduates (or even apprentices) and trained them up. These were also jobs for life with opportunity for progression and final salary pensions attached. Most of these have been squeezed out by 30 years of privatisation and The Cuts post 2008.

I personally worked at a company that had grown out of a government research agency some years before. The majority of employees were from that original batch of junior engineers transferring over, even filling roles like HR, Health and Safety, purchasing etc. I don't see how this could happen today.

I feel like in lusting after what Silicon Valley has, we have undone what we had with nothing to replace it.