Hacker News new | ask | show | jobs
by msg3 1807 days ago
We see this with Dyson claiming every few years that they can't find enough engineers -- translation -- we can't find enough engineers for the salary we want to pay them.
2 comments

I gather that Dyson does actually pay fairly well in the UK, the problem is the UK as a whole really doesn't pay engineers that well - and not just SWE, but chem-eng, civil-eng, mech-eng, and so on.

I'm British myself but I've been living in the US west-coast for the past 7.5 years because I get paid 2-3x more here for the exact same work (heck, even 4x if you don't count London).

The reasons for the disparity are as complex as they are legion - but I believe the size of the market you can sell to matters the most - and with the UK out of the EU the size of the effective market it can realistically sell to has shrunk considerably, so I don't see things getting better at all for the UK eng sector.

...secondarily, the UK is having the same problem the US is having with boomer-generation people still working and occupying senior positions... and housing... which limits opportunities for nominal upward mobility in younger professionals, which in-turn suppresses total-comp. This is especially a problem given the UK's entrenched business culture which I'm not personally a fan of.

A Quora answer from a UK based headhunter on this. He argues that if you are an engineer who wants to make money, you are best off going to Goldman Sachs.

https://qr.ae/pGP3SR

That does not say good things about the engineering culture in the UK.

> about the engineering culture in the UK.

I remember reading an article here on HN within the past year (lost the link, sorry) that ascribed it to traditional/establishment UK managerial thinking that all departments of a company, including engineering, are strictly subordinate to management. Consequently engineers of any level won't be involved in managerial discussions nor to set the direction of the company. Management wants people they can give orders to and won't have to listen to, and who they can sack if management's ideas fail, and keep the rewards for themselves (naturally). Of course the inherent problem with that approach is you lose-out on good ideas for the company's direction from engineering, and miss important early feedback.

Whereas my experience working here in the US, the west-coast, at least, is that eng is part of the decision-making processes at every level - though my experiences are necessarily limited as I only really have direct personal experiences with software-engineering companies - but I see that other west-coast companies do take their own SWEs seriously - take Nordstrom for example, they still run their own e-commerce division instead of just farming it out as other retailers would do - not to mention Amazon.

This is absolutely true. I worked at a large engineering organisation, I was a manager so I could literally list the salary boundaries for different experience levels. Now I work doing the exact same job but in a finance related company. I earn ~6x what I earned in the traditional engineering org. It's insane. Also, the quality of the engineers is no higher, and in some cases comically lower.

The exception to this are companies that pride themselves on their silicon valley culture (Google etc) although some of those still choose to take advantage of the cheap local market.

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.

> 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 :/

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"?
(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".

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.

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.

VB6 > TLA+
> 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.