Programming thread

  • 🔎 If you see an alert for analytics.usips.org, this is a self-hosted system I am running as a test. It is GDPR compliant and collects no invasive information.
  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
Software engineering and computer science are two separate but related fields. It is like comparing mechanical engineering and physics. Mechanical engineers can do a lot of physics, but they are not physicist.
Yes, he is right, and I think that's a problem in and of itself. I don't know, I don't think Google has the best job interview process ever but I feel like he wouldn't get a job were that not to be the case.
 
I'm sure mathematicians from antiquity imagined worlds of pure mathematical forms, not unlike the platonic ideal of software, but the unfortunate reality is that these worlds we've made allow early fools to damn everyone else. It's as if a shitty carpenter could fuck up the laws of physics for a plot of land and make it impossible to build a sink, but leave it possible to get most of the way there through fourteen special cases. All of this is madness.
That isn't what is happening.

What is happening is people are criticising the carpenter because he can't calculate the exact strength of the assembly; however, the assembly works perfectly fine for what it is intended for.
Almost all software is utterly worthless, or has negative value. Most CRUD programs would be best off as slots of a more general form filled in, yet that's how very little of it's implemented from the examples I've met.
The problem with a lot of CRUD stuff is there are specific bespoke business requirements that have to be added in that often cannot just be done as a generic form or form builder. Often trying to make something generic with a bunch of rules often leads to something known as the "inner platform effect".

I'd argue this is why most software is shit.
And you would be wrong. The incentives behind modern software are what create shit software.

i.e., "Show me the incentives, and I will show you the outcome."

We'll have to agree to disagree, because to me this is like a so-called astronomer knowing all about the different brands of telescopes yet knowing none of the constellations.
You like to come up with these analogies that don't describe the situation happening at all.

The whole point of the discussion essentially boils down to what actually makes a good software engineer/programmer and how you select them in an interview process.

Engineering is where you are given a set of requirements and are asked to solve a problem. The problem often doesn't involve any complex computer science problems. Much like most aerospace engineers aren't trying to build an SR-71 Blackbird, they are probably being asked to design something closer to the Piper Cub.

Google and other companies, IMO, select for that and have a process that selects for people that are about "playing the game". Google actually has a very poor track record of delivering new products outside of their Search, Maps and Gmail, and many of their most successful products/services are things that they acquired.
 
Last edited:
I don't need to be a chef to barbeque a decent burger. Sure, knowing the maillard reaction or basic cooking theory helps, but you really don't need to know that stuff.

Most software is burgers. Some software is fugu and will kill someone if you fuck it up.

I don't often cook fugu.
 
There is something fundamentally broken in modern education and industry if we are okay with people having issues with things that are extreme basic fundamentals of supposed field of expertise.

What is happening is people are criticising the carpenter because he can't calculate the exact strength of the assembly; however, the assembly works perfectly fine for what it is intended for.
No, it's more akin to carpenter who built a shed now going for construction work and being stunned that he have to measure instead of just eyeballing it, and nails have to hammered at certain angles instead of just in whatever combination that seems to do the job.

Engineering is where you are given a set of requirements and are asked to solve a problem. The problem often doesn't involve any complex computer science problems. Much like most aerospace engineers aren't trying to build an SR-71 Blackbird, they are probably being asked to design something closer to the Piper Cub.
I am sorry, comparing inverting binary tree to designing SR71 is silly. That's not a complex compsci problem, that's introductory one.
Also I would be pretty horrified if someone who designs piper cub wouldn't be able to calculate fatigue cycle of material, because um the wings worked so far.
 
A big problem with the Google-style interviews is that they seem excessively dependent on the particular jargon of computer science theory, which can differ from the jargon of everyday programmers. A famous example would be everyone's favorite flavor of linear search, where you always allocate the array to be one element larger than the data, so you can place a matching record at the end and then omit bounds checking during the search, since you're now guaranteed to find a match before walking off the end, and only need to check whether the match was a true positive or the false positive located at the end. In practice, this is usually called a "fence" because it enforces the boundary, but in the textbooks and academic journals it's called a "sentinel value".

(It actually seems worse than that, since I don't recall any of the algorithms-and-data-structures textbooks ever talking about the "inverse" of a binary tree and had to search for it. I thought it might be something like turning a tree-based mapping from keys of type K to values of type V into an inverse mapping from keys of type V to values of type K, but it apparently it just means transforming a tree into its own mirror image and is some leetcode nonsense.)
 
What does it have anything to do with comp-sci?

Software engineering and computer science are two separate but related fields. It is like comparing mechanical engineering and physics. Mechanical engineers can do a lot of physics, but they are not physicist.
imagine applying as an electrical engineer and telling the interviewer
>maxwells equation? never heard of them lol
>also what the hell is an "integral" lmao fuck off with that nerd shit
 
There is something fundamentally broken in modern education and industry if we are okay with people having issues with things that are extreme basic fundamentals of supposed field of expertise.
It isn't the field of expertise. Computer science is not software engineering.

I have never inverted a binary tree once in 20 years. It was never discussed at the university I went to. Many successful engineers that produce well-built reliable software said, when this discussion was occurring originally years ago, that they couldn't do it either in an interview situation.

I would argue it isn't fundamental. I have no idea why you and many others are pretending it is when it isn't used in industry outside of very specific use cases.
90% of the time, the most complex thing I use is a for loop FFS.
No, it's more akin to carpenter who built a shed now going for construction work and being stunned that he have to measure instead of just eyeballing it, and nails have to hammered at certain angles instead of just in whatever combination that seems to do the job.
This is why I don't like analogies: because people like yourself will continue to try to build a strawman via them.

The point being made is that you can build things very well using relatively simple tools and algorithms.
In fact, it is often preferable. Complexity is the enemy in any engineering endeavour.
am sorry, comparing inverting binary tree to designing SR71 is silly. That's not a complex compsci problem, that's introductory one.
You are deliberately misunderstanding what was being said. I was obviously not comparing those two.

I was comparing that often most engineers don't work on exotic projects.
Also I would be pretty horrified if someone who designs piper cub wouldn't be able to calculate fatigue cycle of material, because um the wings worked so far
The Piper Cub was designed/built in the 1930s and is/was made out of wood. I don't believe the fatigue of materials was considered until the mid-1950s.
Cathedrals that are still standing today were built before Newtonian physics was formulated.

Much of the engineering that people rely on every day is done via heuristics and guesswork, especially on simpler / well-understood problems.
I remember doing an assignment on the fluid / pressure dynamics in a system. One of the things I struggled with at the time was dealing with the unknowns.
What the assignment was supposed to teach you is that often you have to make assumptions on paper before testing in real life to find the real numbers. This was deliberately not revealed to us by the professor.
imagine applying as an electrical engineer and telling the interviewer
>maxwells equation? never heard of them lol
>also what the hell is an "integral" lmao fuck off with that nerd shit
Software engineers/programmers are not like traditional engineers, and I would equate myself more to something like a plumber, an electrician or a foreman.

The comparison I made was to show that while physics is involved in both mech eng and actual physics (the science), the levels of knowledge required between the two are vastly different.
 
Last edited:
A big problem with the Google-style interviews is that they seem excessively dependent on the particular jargon of computer science theory
We know there's a big problem with Google-style interviews, because Google by definition uses "Google-style interviews" and Elliot Fong-Jones passed them and got hired.
 
It isn't the field of expertise. Computer science is not software engineering.
Software engineering is applied computer science. Just like mechanical engineering is applied physics.

The point being made is that you can build things very well using relatively simple tools and algorithms.
In fact, it is often preferable, Complexity is the enemy in any engineering endeavour.
The Piper Cub was designed in the 1930s and is/was made out of wood. I don't believe the fatigue of materials was considered until the mid-1950s.
Sure you can, but there is a reason why nowadays you have engineering instead of people who just build things based on intuition.
The "simple" way means you either overbuilt, which is preferable, as the alternative is that building/machine fails in unexpected way.
And how many planes had to fall, how many buildings collapsed, before some standards were introduced?

Also my point is both Piper engineers, or more likely their modern equivalents, and modern equivalents of SR71 engineers should have similar knowledge base. Sure, the latter would spend more time optimizing and probably would have more experience with exotic materials, but as for fundamentals they all should have at least be taught the same physics beforehand.
Many successful engineers that produce well-built reliable software said, when this discussion was occurring originally years ago, that they couldn't do it either in an interview situation.
Yeah, but that's a sign that software engineering is still immature field. Just like aeronautical engineering was immature field in 30s.
It didn't stop them from developing planes that flew either. Just it used to be much more normal for them to drop from the sky.

Much of the engineering that people rely on every day is done via heuristics, especially on simpler / well-understood problems.
Of course, but we still expect for serious engineers to understand physics and first principles. The same way software engineers should have been trained in compsci, but primarily use optimized libraries.

There is also a place for coders and mechanics who might not necessarily understand physics that well behind what they are doing.
 
Software engineering is applied computer science. Just like mechanical engineering is applied physics.
I don't agree at all. I actually think of myself more like a plumber or an electrician. Sometimes I am like a foreman.

I think the two have very little to do with each other.
Sure you can, but there is a reason why nowadays you have engineering instead of people who just build things based on intuition.
People still build a lot of stuff based on intuition.

If I were you, I would take apart something that you use every day and examine how it works.
You will see all sorts of shortcuts, maybe even some "bodge wires". Mechanical parts can be understood by simply moving them.

Often things will be iteratively improved (often for cost reasons) and/or to address common failure points. Often this is done simply, e.g., "I need something there to stop the thing from moving too far; I will stick in a bumper."
The "simple" way means you either overbuilt, which is preferable, as the alternative is that building/machine fails in unexpected way.
Again, you misunderstand what is being said. Simple is fine for a good majority of requirements and is often preferable.

If someone tried doing some binary tree inversion in my codebase, they would need a very good reason for it to be there.
And how many planes had to fall, how many buildings collapsed, before some standards were introduced?
The vast majority of work as a software engineer isn't going to lead directly to someone's death.
Also my point is both Piper engineers, or more likely their modern equivalents, and modern equivalents of SR71 engineers should have similar knowledge base. Sure, the latter would spend more time optimizing and probably would have more experience with exotic materials, but as for fundamentals they all should have at least be taught the same physics beforehand.
Again, this is why I don't like analogies; people twist them to suit their argument. I shouldn't have started making them.

The point being made is that these sorts of questions asked don't accurately assess someone's skills at building software. In fact it often does the opposite.
An understanding of computer science is often not required at all to build good software. Knowing algorithms well enough to whiteboard them isn't a requirement to be able to build good software.
 
Last edited:
I think it's both true that to make apps nowadays you don't need to be a computer scientist, and that for most jobs being a computer scientist is being overprepared, however, this entire conversation started because a self taught mac user tried to get a job at Google as a programmer just because he made a popular app, and he's still fuming mad that he didn't get picked.

You can whine all you want about how modern app making has very little to do with CompSci, and how much the modern Google job interview template sucks, but at the end of the day, Google can be seen to be the gateway of the modern internet managing a lot of services that billions of people and companies use, so I wouldn't say it's at all unreasonable for them to screen modern app makers out in search for the most autistic of all autistic CompSci people. They need that kind of expertise, if the guy instead tried to go for a mid-level company he probably could've gotten a job.
 
however, this entire conversation started because a self taught mac user tried to get a job at Google as a programmer just because he made a popular app, and he's still fuming mad that he didn't get picked.
It is homebrew. I guarantee that half their engineers are using homebrew on their macs. I would be pissed to if I didn't get hired and a good portion of their engineers were using my product. It isn't just some fucking app like a fitness tracker.

BTW this has happened to me. I built a bunch of stuff for one department, go to interview later for a perm position in the same department (invited by them) and manager their didn't understand what I had done, even when describing products he managed.

It pisses you off because it doesn't make any sense.
Google can be seen to be the gateway of the modern internet managing a lot of services that billions of people and companies use, so I wouldn't say it's at all unreasonable for them to screen modern app makers out in search for the most autistic of all autistic CompSci people
Which is probably why they haven't released anything interesting in ages and often their new products are either clones of existing products or they buy stuff in.

You actually need a real diversity of talent and sometimes that is asshats that fly by their sears of their pants and just does stuff.
 
Last edited:
My interview anecdote: it was a while ago, and I was applying for a job at a company. They were nowhere near the size of FAGMAN but were still fairly large. I get given the technical challenge to make a linked list. I think “awesome, no way I fuck this up.”

Turns out, some people think a linked list is like a “circle”. With the first and last nodes having a pointer to each other. I had always made my linked lists with a sentinel node at the end, and no direct pointer from the last node to the first. I ended up not getting hired, even after discussing the solution with the interviewer and showing I could make the change.

It seemed to me that technical interviews are more about practicing telepathy than actually showing competence. I was very frustrated as I didn’t get the job because of differing ideas on what a linked list is.
 
I don't agree at all. I actually think of myself more like a plumber or an electrician. Sometimes I am like a foreman.
Well, I wouldn't call that engineering then.

It is homebrew. I guarantee that half their engineers are using homebrew on their macs. I would be pissed to if I didn't get hired and a good portion of their engineers were using my product. It isn't just some fucking app like a fitness tracker.
But were they hiring him for position of designer/product owner? Or for position of software engineering?
It's what he said himself is true, homebrew isn't implemented well. It's main appeal is that it has solved issue that was needed to be solved, not technical excellence.
Which is pretty cool, but not necessary a resume boon for getting job at google where your main job is to implement what you are told to.
 
The interview process is broken but if you’re e.g. a devops guy, you should be comfortable with operating system fundamentals. And if you don’t that’s a reasonable goal to have.

It is a problem that a lot of people in the field can barely speak English and thus can’t actually state the problem, but that is a different problem.

It seemed to me that technical interviews are more about practicing telepathy than actually showing competence. I was very frustrated as I didn’t get the job because of differing ideas on what a linked list is.
This has basically happened to me too. First one I remember was when I goal asked how I would find a “hole” in an array. Interviewer would not explain what he meant when I directly asked him, and it was like pulling teeth to figure out that he meant “if you have an array of n integers, from 1 to n, but one is negative, how do you find out which one is missing?” That’s pretty brainless if you took discrete math for computer science or whatever they call it these days—difference of n(n+1)/2 and sum(array)—but I have never heard anyone else explain it remotely like that.
 
Last edited:
Based Google filtering out the code monkey
 
I remember reading some guy whining about not getting a job at a certain company. He had been writing PHP for the entirety of his 3-4 year career and had even managed to get promoted to a senior level at some point.
Nigga did not even know what DNS is or how the binary search algorithm works.

Should such people even be allowed near computers?

Not only did he not know the basic things, but he also did not see anything bad about his lack of knowledge. These fucking people have no standards.
 
Well, I wouldn't call that engineering then.
I don't think many people actually understand what it is.

Software engineering isn't a traditional engineering discipline. Maybe it should be called something else, and thus why people are often called/call themselves "developers", "programmers" and "hackers".

I don't think of myself like an engineer. I definitely fit into the hacker/tinkerer category.
It's what he said himself is true, homebrew isn't implemented well. It's main appeal is that it has solved issue that was needed to be solved, not technical excellence.
It's implemented well enough for quite a number of people. Solving an issue is more important than technical excellence.

Often something that works well and solves an issue that is good enough is preferable to something well engineered.
This is often known as "worse is better". https://en.wikipedia.org/wiki/Worse_is_better

It is often used disparagingly, but there are benefits of getting your stuff out there and people using it, even if it isn't as well implemented as you would have liked.
Which is pretty cool, but not necessary a resume boon for getting job at google where your main job is to implement what you are told to.
The whole point of contention is that many people believe it should be a resume boon.
 
(It actually seems worse than that, since I don't recall any of the algorithms-and-data-structures textbooks ever talking about the "inverse" of a binary tree and had to search for it. I thought it might be something like turning a tree-based mapping from keys of type K to values of type V into an inverse mapping from keys of type V to values of type K, but it apparently it just means transforming a tree into its own mirror image and is some leetcode nonsense.)
I've heard about that guy and his Google adventure, but never looked into the details.

In passing, this tree inverting problem always sounded like some crazy fourth-dimension flipping thing, like what, are you supposed to make the leaves the root somehow, invert the relations or something weird. But it's actually just a stupid tree traversal gotcha puzzle, like if you do it recursively then they ask you "but what if the tree has 1000 trillion nodes, what about then think of the stack retard" and if you don't do it recursively they ask if you can't handle recursion. Cool beans

Fucking leetcode idiots memorizing each case instead of just figuring it out on the spot like a normal person, and acting like it's all some crazy esoteric wizard knowledge
 
His interview should have gone like this:

"Hi, I wrote brew.sh."
"Get the fuck out."
 
Back
Top Bottom