[jkaptur]

Just to give a different, concrete, perspective (and push a hot button HN issue), I've spent a fair amount of time working on extremely large web applications, and by far the #1 "WTF WTF WTF" thing that new hires say is "what do you mean you aren't using $TODAYS_HOT_JS_FRAMEWORK??"

Once you get away from "should we use version control" and into actually difficult software engineering questions, it's not clear how to balance a fresh perspective vs. an experienced (normalized? tainted?) view. I wish the article went into this more.

Like, how does the new hire (or anyone else) know the difference between "learning the complexity of the new system" and "internalizing/normalizing the deviance of this culture"?

[aidenn0]

> Like, how does the new hire (or anyone else) know the difference between "learning the complexity of the new system" and "internalizing/normalizing the deviance of this culture"?

If a new hire can't checkout, build, and test the software on the first day, then there is likely something either wrong with the hire or the infrastructure. A sufficiently old and arcane software system might take weeks before a new hire can make even a simple change, but that shouldn't impact those three items.

[Jtsummers]

Along with this "how long to spin up the new hire" issue, one of my first (if not the first) questions when trying to help people improve their processes related to software is:

> If the user/client asks you to make a small but not trivial change, how long would it take to update and deploy the program?

I have had answers ranging from "A couple hours" to "A year" (yes, they were serious). Most were in the 1-3 month range, though, which is pretty bad for a small change. It also makes it apparent why a bunch of changes get batched together whether reasonable or not. If a single small change, single large change, or collection of variable sized changes all take a few months to happen, might as well batch them all up. It becomes the norm for the team. "Of course it takes 3 months to change the order of items in a menu. Why would it ever be faster than that?"

[MikePlacid]

Not sure how speed of the change is related to batches. The “batch” is related to “due this week”, there never was a single item in this list. “Speed” is related to “due which week”, that depends mostly on the priority of the change, not on how easy it is.

Upd. And “change menu items order, fast” is a sign of a problem. We found Mac Cube in ski vacation rental home once. It ran MacOS 10.2 or something. All the menu items were in the places we expected them to be! You think carefully first, then you implement menu items order. Upper Apple -> About this Mac. We managed to break their network config in like 5 minutes!

[Jtsummers]

By running the exercise with a small change the constraints and behavior of the rest of the process get emphasized. As an example, in one team their test process was entirely manual and took a month. They ran that entire test suite for every release, whether the release should have affected the requirements being tested or not. Why? Mostly because they didn't know what changes in the release would affect what requirements, but that was another problem. This did encourage larger batch sizes though because if you have that large cost in your process and the cost is fixed regardless of batch size (100 changes or 1, you spend a month testing) you might as well batch more changes into the release. Having more releases means you incur this large fixed cost more often and overall reduces your throughput.

And I don't think I understand your update to your comment or you don't understand the point of that example from mine. It was illustrating the submission topic: normalization of deviance. Sure, you should think about where things should be but if a customer comes in and says, "Swap these two items" and you can't provide a working version with that single change for months then things have gone off the rails somewhere. I put it in quotes to reflect a statement like what I have heard from those teams I worked with. To them a long effort for a trivial change is normal, when it should be considered deviance.

EDIT: effect->affect. Always trips me up.

[MikePlacid]

> As an example, in one team their test process was entirely manual and took a month.

Ouch!

[aidenn0]

This is true, but there are cases where "months" makes sense. E.g. avionics, industrial, medical.

[Jtsummers]

That can extend the time, yes. I had a caveat about that but apparently edited it out before submitting. But that only explains or justifies the delays if there is value added. I work in aerospace and these were avionics and related systems. The bad ones did not have quality as a reason, though the good ones did. The bad processes were swamped with manual testing (which was non-comprehensive and error prone) or really tedious CM related activities (which was manual and error prone).

You can do a lot with good test automation, even in avionics. That cuts down a ton of the time and usually improves quality.

I'll also note, don't take my "deployed" too literally. I used that term because so many people here are working on server-based applications where that makes sense. Think "out the door". The exercise can only go as far as the team/org's reach. Deployed for avionics would mean more like, "At the flight test team". After that, it's up to someone else to schedule it and get it returned with issues or fielded.

Going beyond the team's reach without including those people (and thus making them part of the team, after a fashion) is guess work and opens up the blame-game. "It's all flight test's fault it takes a year to get out to the customer." Well, it takes you 9 months to get it to flight test and them 3 months to get done. So why does it take you 9 months? If you have a good reason (complex system, lots to test) then that's valid. If it's a simpler system, 9 months to get it to flight test is probably not justifiable.

[aidenn0]

I totally agree that "process" on its own doesn't justify long turnarounds. If you had one part of your code that was taking 2/3 of the run-time, it should get plenty of scrutiny, and the same is true of processes.

[charrondev]

For us the setup is:

- Install docker - Setup GitHub SSH credentials. - Pull the main repo. - Run a script that will pull down related repos, install dependencies, start up a bunch of docker containers, and then run health checks on the app. - setting interactive debugging takes a bit longer, but not too much more.

Unfortunately I’ve routinely dealt with our IT department being slow to give credentials to new employees or shipping them under provisioned or just incompatible systems. No you can’t give our new senior developer the same cheap crap laptop running an ancient version of windows on that you send to the junior marketing person doing cold calls all day.

[908B64B197]

> by far the #1 "WTF WTF WTF" thing that new hires say is "what do you mean you aren't using $TODAYS_HOT_JS_FRAMEWORK??"

To that speaks of the caliber of programmers hired. If all they have seen is $TODAYS_HOT_JS_FRAMEWORK and wrote nothing but a web app using $TODAYS_HOT_JS_FRAMEWORK they might not grasp the fundamentals that would make then realize that frameworks are just abstractions (and not that different from one another).

I don't think any software engineer would even ask that question, since the answer will almost always be "$TODAYS_HOT_JS_FRAMEWORK didn't exist when the project started, and it's not worth a re-write to port it over".

Now, that brings out a second important truth: a company can't attract and retain a wide range of different caliber employees. For instance, if a place still questions the usefulness of source control (perhaps because they consider git to be too complicated) there's no way they'll attract and retain top performers. So the culture will select people that agree that source control is a waste of time.

[blep_]

I do not understand how teams work without source control. I don't mean that (only) in the "WTF are you doing, I don't understand why you would do that" colloquial sense. I literally cannot conceive how they work.

Do people just... change files and then email the whole file to the other developers and hope nobody else was working on that file? Do they at least have patches?

[colomon]

First professional software development I did, we didn't even have hard drives or networking. Luckily I was the only developer and it wasn't a huge problem.

First place I worked with other people, we at least had hard drives. I don't think we had networking on the machines or version control. For sure there was only one or two machines in the office that could reach the Internet. Mostly only one person could work on a file at a time.

When we did get more employees, a LAN, and version control a few years on, the mid-1990s Microsoft version control software was such a piece of junk it mostly amounted to a formal digital system specifying who the one person who could work on a given file was...

[908B64B197]

I've seen people exchanging thumb drives.

No concept of a patch. They spent most of the afternoon and evening "performing the manual merge and stabilizing the release", meaning rebuilding and deleting lines until it compiled.

I wish I was kidding.

[Jtsummers]

Email would actually be better than what I have actually seen because it gives a pseudo-version control system, patches or no:

Shared drives and folders with concurrent edits. Sometimes they'd separate them into "mine/2023.02.14" and "yours/2022.12.10" but that wasn't much better. Actually, because people don't seem to grok lexicographical order, or how to write dates at all, the dates are normally 10-12-2022 and 2-14-2023, guess whether the first one was from October or December.

[BlueTemplar]

There are less complicated VCSes than git, so this sounds like a cop-out.

[josephg]

> it's not clear how to balance a fresh perspective vs. an experienced (normalized? tainted?) view.

Having a healthy, balanced view comes from enough experiences. Ideally from working in a bunch of places and seeing enough things go sideways, and correctly understanding and identifying the causal chain that led to failures.

Funnily enough its sort of like training an AI - you essentially need a lot of correctly labelled data to learn. Junior engineers don't have enough data points, and unfortunately some "senior engineers" I've worked with took (in my opinion) the wrong lessons from their experiences. (Eg the CTO who thinks version control is too complex.)

The interesting cases are when smart, experienced people disagree on what the best solution is. Should you keep your team small and smart or have a varied team with more mentorship and process? Is code review worth it in every case? What is the right amount of tests for your software? How often do we want to push to production?

When I was teaching programming my students would sometimes ask juicy questions. My favorites were the questions I could answer with "I'll tell you my opinion, but I've worked with people I look up to who think I'm wrong about this..."

[flappyeagle]

If "what do you mean you aren't using $TODAYS_HOT_JS_FRAMEWORK" is the first question they ask, then you can end their employment right then and there. Hire people whose "wtf" you take seriously.

[evilduck]

Both parties would feel like they're dodging a bullet.

People still griping about $TODAYS_HOT_JS_FRAMEWORK are clearly out of touch in 2023. It was funny commentary in 2013. It still rang a little true until around 2016. Now it's just an indicator you are the one not to be taken seriously.

It's React, Vue, or Angular and it's been that way for many years now.

[notduncansmith]

React underlies a lot of the “new hotness” like Next.js and Remix.run (I’m not sure if Vue, Angular, or Svelte have equivalents but I wouldn’t be surprised).

[Cthulhu_]

I still take those newer frameworks with a big grain of salt, but tbh, that's because of ignorance on the one hand, and fear of sunk cost on the other (e.g. spending time to invest in acquiring knowledge only for it to go obsolete).

Angular is still used in a surprising number of large companies my employer works for, so that, and React, and Vue are all solid investments IMO.

The other ones I think will only be used if one developer dares to take and sell the risk.

[whats_a_quasar]

There's a whole section about how to balance a fresh perspective, in "solutions". The best way is for an effective VP to hear the WTFs of new hires, apply engineering judgement, and make changes based on that signal. If management is not the ones creating the deviance, they ought to be able to tell what reactions are just unfamiliarity with the system and what are signs of something actually being broken. The article is arguing that most people ignore those weak signals by default, and ought to pay more attention to them, not that they're always reliable.

[jt2190]

Yes. From the article:

> “The thing that's really insidious here is that [once a person buys] into the WTF idea… they can spread it elsewhere for the duration of their career… Once people get convinced that some deviation is normal, they often get really invested in the idea.”

> [H]ow does the new hire (or anyone else) know the difference between "learning the complexity of the new system" and "internalizing/normalizing the deviance of this culture"?

The article implies that the new hire should pay close attention to the things that are incentivized, and those that are not.

[ReflectedImage]

That's not a "WTF". All front end developers trash their predecessors work and rewrite in the last framework. That just what they do.