This makes me wonder what the actual rate of suicides are performed under influence compared to completely sober. I have a feeling the latter is extremely rare.
I think ageism is too overstated in tech industry. If graduates with zero experience can get work, then it doesn't make sense that senior software engineers should struggle in the job market.
Personally, I see the opposite with many job posts asking for minimum X years of experience. If a programmer with many years of expertise is jobless it says more about their personality and their ability to fit culturally speaking. Perhaps they're just applying for the wrong jobs, or use the wrong rhetoric etc.
Too many programmers are concerned with their skill level and less with their ability to communicate their potential. That's what it comes down to when everything is taken into consideration.
The reason 'ageism' is a thing is because many tech companies view labor costs > all.
Two people are applying for the same job. One is a guy with 2 decades experience in relevant technologies, the other is a fresh graduate who did an internship at a tech company. One of the big differences here are expectations. The experienced individual is going to demand substantially higher pay. They also are going to be less willing to live their job than a fresh grad due to a better understanding of the employer:employee relationship along with the fact that they likely also have more obligations outside of work, such as family. The fresh graduate is going to underestimate his own worth, be eager to please, and have fewer obligations as well as likely being more willing to put those aside for the job.
Because of this you're going to end up paying substantially more for the more experienced employee. How will that affect your product? It'd probably be good, but that's not a given. And even if it does result in a better product or a more efficient deployment time, how does that contrast against your increased labor costs? And this is all talking about things in terms of a meritocracy. In software, hype and marketing play a huge role in many product's success, meaning there's even less reason to optimize for the most capable teams.
As an aside this is also the reason for the huge push for getting [x into computer science]. It's great optics for public relations, but increase the labor pool and guess what happens to labor prices? Mega corporations such as Google and Apple are pushing upwards of 100,000 employees. Reduce average labor costs by 10,000 a year and that's well over a billion dollars of recurring profit per year - keeping in mind that when a company pays an employee e.g. $10,000 they end up paying substantially more than that in various compensation-scaling taxes and other disincentives.
As our capable labor market has exploded relative to the quantity of desirable jobs, many wages have stagnated. Tech is the exception. It's a field where demand is still in line with supply which keeps wages going up. This [1] is an archive link to Glassdoor's reporting on Google salaries. The inflation there is remarkable. In 2010 a senior software engineer made $125k. Today, 9 years later, they make $165k, a 32% increase. Inflation during that period has only increased by about 15%.
Parsing is a fairly simple and common activity with a huge background of research. Anything for which that is true in your field is something you should understand.
Parsing, databases, concurrency, floating point numbers, optimization, common data structures, regular expressions, networking, operating systems, recursion, complexity theory, etc., are all things you should understand to be considered a competent programmer.
The difference between parsing and everything else there is that every single program longer than 200 lines will need to take a string from somewhere and change it somehow. If you don't know how to parse a context free language you will write a a thing that accepts a recursively enumerable one and someone will make full use of every corner case you can't even imagine.
It's pretty funny that next to no one here will even understand what I'm saying.
I have written programs with thousands of lines that do nothing with strings at all, as have a great many other people. Parsing is simply not the universal requirement you claim it to be, and declaring that only real programmers can do it just makes you look arrogant and ignorant.
Did your programs take input? If you had studied parsing theory, you would know that "strings" do not mean ASCII/Unicode text strings, they mean sequences of symbols from a set. All communication protocols, any kind of input, can be described in terms of grammars, and that is important:
I have a computer science degree, and have studied parsing, compilers, etc. I have written many parsers for text and binary formats. I know exactly what I'm saying.
Not all programs need to take external input to be useful, and many or most of those that do can just use an existing library to read it, with no need to write a new parser. Writing parsers is simply not the universal programming requirement you people are trying to claim it to be.
You still don't understand what "input" means. Do your programs literally have all the data that they need to produce their output hard-coded into the source code? If not, they are taking input from somewhere.
I understand exactly what "input" means. Please stop assuming that I'm an idiot and that you're infallible.
Yes, all "data" is right there in the source code for the programs I'm talking about. (I do also write a lot of code that deals with external data, for which I write parsers or use existing ones.)
For example, I did some consulting for a company where I made a mathematical model of their physical product and simulated the static and dynamic behaviour of it in various situations. The model and situations are completely defined by a few parameters in the source code. There's no need for external input and definitely no need for any kind of parsing. Thousands of lines of code.
As a simpler example, the other day I helped a high school student write a program to do basic numerical integration. No external input needed.
I have university students who do an entire course on numerical methods without external input (partly because we're stuck in Matlab where IO and string processing are horrible). The few times they need to process a small amount of data it's just pasted into the code.
For part of my PhD I wrote programs over a thousand lines long to derive mathematical functions. No external input, and nothing that can even be called data.
Generative programs in general, for art, sound, video, etc. often have no external input. I have written many of these.
For another part of my PhD I wrote thousands of lines of code to reconstruct surfaces from point clouds. For real purposes it uses external data, but for testing and development it can simulate its own (so that the true answer is known).
Those are excellent examples. I was debating putting in a disclaimer about hard-coded numerical programs in Fortran or similar, but decided not to go into the detail I will write below, nor give you the benefit of the doubt.
Compound data types, and procedure argument lists, describe the grammar of the data that your programs operate on. That this data is in the source code and the parsing from text to intermediate representation is done by the compiler only offloads the first steps of the parsing. Obviously if you deal with simple data types like vectors and matrices there will not be a lot of grammar there. If you think about typing your program and more intricately structured data into a REPL, this becomes apparent (just because your compiler accepts something as valid input, may not give many guarantees about how your program will behave - this is the crux of type theory).
I am not sure how you can claim generative programming as a counter-example to needing to learn parsing theory. The entire field started out from formal language theory.
Perhaps "generative" was the wrong word. I just mean programs that generate things. For example, I make programs that generate illustrations and animations for teaching maths, programs that generate exam questions that have suitable properties (appropriate difficulty, answers that come out nicely, etc.), and so on (pretty pictures, music, fold patterns...), and few of them need any input data beyond the code itself.
I agree that the programs are doing work to assign meaning to the numbers and data structures etc. in the code and put them to use in context, though I wouldn't have called that part of the parsing myself. I think the grammar of my "input" data structures is usually pretty simple, as you suggest, and that more complicated source structures are likely to be kind of self-organised, e.g. involving dictionaries with meaningful keys or calls to class constructors. Complex data structures can then be built from the simpler source ones if needed.
>As a simpler example, the other day I helped a high school student write a program to do basic numerical integration. No external input needed.
So how are the functions fed into the integrator? The second you want your program to integrate more than the one function you hard coded it with you need a parser to understand what the function is and then translate it into the internal language representation. Something that is very far from trivial.
Sure, but for most purposes, that kind of generality is just not needed. I have hundreds of useful small to large programs that don't need any external input - it's all in the source code.
Besides, even if you want to take in a general function in this case, there's almost certainly no need to write a bespoke parser by hand. In fact, this student was able to handle that requirement just fine (he had this in there first, and we made the program more useful by taking it out):
It's hilarious when people are so wrong they don't even realize they are wrong. We have a whole generation of people who work as coders but don't understand the first thing about computers. And there are so many of them that they even manage to convince themselves they are right.
Parsing is the fundamental task of programming: taking information, performing a transformation on it, passing it along.
If you can't do it you might use computers but you're not programming.
Tuning DE solvers might take as much skill, or more, than getting context free string parsed, but it's not a skill that is used outside of numerical computing. DBAs aren't called programmers for a reason, but they are no less valuable for it.
The same applies for every niche skill that takes years to develop.
>The same applies for every niche skill that takes years to develop.
so you just defeated your own argument, instead of hyper-focusing on writing parser why not just say "years of experience" if that is what really matters?
I'm definitely not a slacker when it comes to jobs and I know I have real-world applicable skills. I've always pulled my weight and received great feedback, I agree with everything you said. I got hung up on the credentials because they're so important to everybody else, but actually it's only half (or less) the story.
Thanks for your perspective, you've given me a lot to think about.
Everyone else like who? Once you've been in the field for five or so years, no one cares about the college you went to - or more often whether you went to college at all.
Everyone else as in people who are in charge of hiring, don't misunderstand but many startup people are from privileged backgrounds who only hire people from the same alumnus as themselves.
Back in the early 2000s I worked for a telco. Telecom was having a pretty rough time following the dot com crash. They replaced the previous CTO with a CTO that had a financial background (would have been suitable for as a CFO). This blew my mind at the time. The explanation was simply he's going to be less persuaded by seniors managers arguing for projects on technical merit and more persuaded by the dollars and cents. Rightly or wrongly, it worked, they got out of trouble early and when the economy turned around he was swiftly replaced by a hacker CTO.
One previous CTO of mine frequently told us he hadn't written a line of code since the late 1970s, and even then he hadn't done much. He didn't know what an SSH key was, didn't know the difference between FTP and HTTP, and hadn't heard of MySQL (this was mid 2000s).
He had two excellent abilities: convincing the board to give more money to IT, and hiring good people to spend the money wisely.
My experience comports with the parent. Most "CTO"s or "CIO"s I've met have a weak or non-existent technical background. I worked closely with a CTO whose only direct technical experience was a couple of CAD classes he took at a community college.
Generally, a CTO's tech "qualifications" are more from having some general knowledge about the technology ecosystem (e.g., they've managed software people before, and they know what Microsoft SQL Server is) than from any hands-on experience.
They will often be the type that have always been interested in gadgetry and tech, but basically only enough to subscribe to WIRED (back when that was a thing people did) and observe the industry casually. Not enough to get involved in the process themselves.
CxO is a fundamentally non-technical job, so I don't know what people expect from "technical" occupants. Technical people do poorly because the role is almost entirely subsumed by "business" responsibilities; that is, closing sales, talking to media/making presentations at conferences, sitting in meetings with lawyers and investors, setting budgets, and so forth.
Let me ask you, what is a "technical" CTO supposed to do?
Well the point is to get you thinking, so I wouldn't say it's pointless. If you've thought deeply enough about it to decide it doesn't matter, you've probably already absorbed the lesson you were supposed to learn. Most koans are completely pointless or vague, but in order to figure that out you have to understand it, and at that point you've already grown.
My favorite popular quotes are the ones that are borrowed from Shakespeare but stripped of all context, so they're commonly read as meaning something completely different.
Read books, or essays, or at least the whole dang poem (the quoted "The Second Coming" is really short!). It's nearly impossible to pack any kind of meaningful insight into a couple sentences.
I find the opposite: most quotes are incredibly insightful and powerful, but wasted on people who can't act on them, and insist on vague and pointless lives.
Why would you call that a personal attack? It's my standard opinion on quotes. I used the same wording used to dismiss them to make the message stand out more.
To paraphrase Chesterton quotes have not been tried and found wanting. They have been tried, found hard to abide to, and been abandoned.
