I would assume there is no one thing to put a finger on. But there are some signs one can take a note of. Generally speaking, to name a few:
- The ability and willingness of the management to invest time and resources into development of proper work processes and infrustructure (imagine having to code without version control in a team)
- Understanding that things aren't always done the moment they appear to be done
- Realization that many things are done to lower the cognitive load exclusively (why do we have to spend 20 hours refactoring the thing if it already works?)
- Understanding why it is important to lower the cognitive load
- And dozens more
These are merely signs, though. One can put 'dnd' signs on doors, but what difference does that make if the same people who introduce the signs still disturb the people behind the doors whenever they feel like it. (no pun intended, couldn't word it better)
It comes down to understanding the nuances, and mutual respect, I think?
> It comes down to understanding the nuances, and mutual respect, I think?
I think that's a great summary.
Look out for companies that try to manage what they don't understand. It can lead to the 'car mechanic phenomenon'. I call it that because it's like the feeling some get when they get the bill from the car mechanic. They can't fix it themselves, so how do they know if someone's pulling one over on them?
100%. The companies and programs I've been a part of that failed, this is why. I've been meetings and made what to most engineers would be a truism, and been told by leaders that didn't have even a basic understanding of what we were trying to make "you don't know that, that's not true". In similar situations in successful management lead to "ok, I trust you" and then success. If an organization spends too much of its valuable resources on internal mistrust and convincing people who don't know, it's doomed.
I had a friend interview at "Big Nameless Corp" a few years ago. He said when he saw that the engineers interviewing him all had Windows laptops, he knew immediately it wasn't an engineer-friendly culture. I always thought that was funny.
I try to stay pretty open, but I work on an org with a lot of windows developers. It’s kind of interesting how it’s a totally separate world and the windows devs have their own equivalents to dot files and stuff.
The problem is when they insisted that everyone else must use windows and Mac and Linux machines weren’t allowed.
It is not snobbery and you are taking it the wrong way.
It is more about having plenty of mature developer tools at your finger tips to get the job done with lots of automation. Also having source of everything allows you to check how something is architected and designed and also improves your own code.
It is very painful to work on Windows laptops when you don't have access to proper dev tools which is the case in most of the corporate setups where they want to uniformity of images to make administration easy.
WSL is a business checkmark used to keep engineers quiet. It's not a pleasant surrounding ecosystem and the implementation isn't as high fidelity is the real thing.
I've had a reasonably long career and worked at a number of companies at this point, and I've never seen this 'documentation' that engineers are supposedly producing.
I think a better metric is to ask why the documentation isn't better. Nobody is ever happy with their documentation, whether they have too little or too much. But if the engineers think it's because they're being pushed too hard and there's no slack time available to write docs? Red flag. They have explicitly considered the question and realized that the effort to write the docs, compounded by the need to keep them up to date and/or the cost of allowing them to be out of date, is not worth it in their particular situation? Good sign. They feel kind of bad and guilty about the state of the docs? Too normal to be much of a sign, but still positive.
These questions are ultimately just asking what the work culture is like, they don't really have anything to do with documentation. And in that sense they're good questions to ask during an interview. As you allude to though, I don't think you're going to get good information if you just ask surface level questions about docs.
The meat of the question is, "where do you go when don't know how to do a thing?".
The answer could potentially be "the docs", but that's not necessarily sufficient like you point out. However, you could ask follow-ups, e.g., whether the docs have multiple facets like user guides in addition to low-level API guides.
OTOH, where you go when don't know how to do something doesn't necessarily have to be the docs, and info here can still be valuable to understand. E.g., are questions typically discussed in public forums or is it discussed in private DMs? The former is typically a better signal in my experience.
Compare the quality in the documenation from lawyers and engineers in the company. True experts tend to be excellent communicators. SJ adequately described the short comings of Flash the phoneys pushed back against without merit.
We really have the opposite problem, there are lots of documentations but they are not exactly organized or all up to date. Much easier to fix than not having any of them I would guess.
