Hacker News Reader

So a couple of thoughts.

> Have you seen the personal blogs of devs today?

I don't know that this is a fair comparison, because side projects can and are often a way to explore ideas, understand tech, play around, etc. So I don't know that I'd agree that it's a great extrapolation to the way an engineer works based on side projects or a blog that may have different objectives.

I do agree with the sentiment though, that we want to be watching for indicators to how a team member approaches problems.

> the way it is because everyone thinks they're gonna be the next FAANG-sized company, and need to be able to write FAAANG-quality code and engineer FAANG-quality architecture from the start

I don't know it's fair to say everyone, but is something I agree companies, especially startups should filter for. When I acted as hiring manager, and was trying to build SRE as an example, I would remind candidates, and the team continuously that we're not google. So while we want to bring ideas and approaches in from what google has published as "SRE", we do need to consciously leave large parts out that are appropriate to our needs and stage of maturity.

I disagree that they go down the path they do because they think they’re going to be FAANG-sized, but rather it’s a case of cargo-culting, “we’ll use these tools/architectures because the best companies use them, therefore they must be the best tools/architectures.”

I don't even know if it's cargo culting as much as engineers using their day jobs as opportunities to learn marketable skills for job hopping.

Nearly ever new technology introduced at places I've worked was because someone was keen to get it onto their resume.

But why are the skills marketable, if no business needs them?

Why are companies hiring people who proudly put Overengineer as their job title on resume?

Clearly there are businesses that serve millions or billions of users, and have a serious need for engineers with experience with the tools to do so. Engineers seeking those jobs are then motivated to use those tools to engineer systems serving orders of magnitude fewer customers simply so they can claim that experience.

New and shiny > old and dull.

At least as far as marketing goes, when trying to hire young and hungry devs. More so at startups.

My old job was quite spread geographically and organizationally - lots of small offices with engineers that had more or less total freedom when it came to tooling. It was actually a gov. agency - so that might surprise someone, but it was one of those places that was transitioning to the digital age, and therefore, didn't really have much solid structure.

The various teams pretty much used the tools they wanted to solve the problems at hand - I think we had three different versioning control systems at play, and multiple different databases. Working with data across the organization was a total nightmare.

But we did have a common platform for communication, sharing stuff, and all that. I think we were around 250 devs. and engineers, and a survey shoved that we used over 20 different programming languages.

One thing I DO remember, was that some people in most teams were constantly pushing for the latest (as in 1-3 years old) tools. Someone's writing an API in Flask? No - screw that. FastAPI where it's at. Team x is still writing RESTful APIs? We're doing GraphQL. And that's how it went.

When some of these guys would end up in dev. blogs or being interviewed, they'd of course push the "See, we're not old and stuffy anymore. We've hired lots of young engineers, and right now we're using [trendy stack]"

I believe this might fall under "resume driven development"

I think your general point is true but the personal blogs of devs angle is maybe not the most illustrative one.

We tend to apply industrial strength tools to our personal projects because it's some combination of what we already know, or we're trying to learn or refine an unfamiliar skill.

If you just gave me a linux shell I would not be able to confidently provision a secure webserver for static hosting. But I do know how to write cloudformation and deploy it. Sure this is a personal moral weakness by the standards of HN whatever, but it's where my career has led me so these are the tools I have.

I don't think anyone using Jekyll or whatever for their blog is doing it because they use Jekyll at work.

> If you just gave me a linux shell I would not be able to confidently provision a secure webserver for static hosting. But I do know how to write cloudformation and deploy it. Sure this is a personal moral weakness by the standards of HN whatever, but it's where my career has led me so these are the tools I have.

I wouldn't say it's a moral weakness, maybe more of a failing of the tech education ecosystem. It seems bizarre to me that in software, we teach complex high-level things before we teach simple low-level things. Programming students learn very complex high level languages in year 1, and then maybe by year 3 or 4 learn assembly, or what a CPU register is, or how RAM and cache works. It's like teaching a carpenter how to build a high-rise apartment building before teaching them how to measure or use a hammer.

Well I didn't have any formal tech education, just what I picked up on the job and through my own curiosity.

But I mean you don't teach a car mechanic metallurgy and aerodynamics, except to the extent they'll need to apply that knowledge towards specific goals. At some point the discipline is mature enough that people genuinely don't need to, and can't, know every level of it from the ground up.

I think coding is approaching or already at the point where "cs/fundamentals of computation" should be a different degree from "professional software development."

side note: FAANG is an obsolete acronym according to The Economist, it's now Microsoft - Amazon - Meta - Apple - Alphabet, leading to the new acronym, MAMAA, which has the nice result that we can now talk about the outsized influence of Big MAMAA in the tech world.