Hacker News Reader

Comment by baby | Hacker News Reader

What do you look at in engineering culture?

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.

If people have to enter time spent into any system then thats an no from me. Which means I cannot work for consulting companies :-).

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.

I don’t really see how that’s relevant given that WSL exists.

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.

Exactly. It is painful in Windows 10. Nothing beats running natively.

WSL in Windows 10 is almost useless. Also for embedded and people working on kernels etc it is really painful.

>"He said when he saw that the engineers interviewing him all had Windows laptops, he knew immediately it wasn't an engineer-friendly culture."

"Friend" should have his head examined. This kind of snobbery attitude does not do any good

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.

I work at a BigCorp. A sister team develops client software for Windows. Can you guess what kind of laptops the engineers have?

And how do you even "look" at it from the outside? Ask interviewers and they will always tell you that they have great culture, teamwork, etc

Easy,

Ask where the documentation is.

Ask how much input engineers have on what they are working on.

Ask how many meetings hours they average per day.

>Ask how much input engineers have on what they are working on.

This is the way. Ask this question of people working at a legacy company and they won't be able to meet your eyes.

Thank you. These are valuable pointers.

> Ask where the documentation is.

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.

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.

I feel like having too much doc is not really a problem :)

Welcome to health care. We produce a ton of documents that then disappear into a terrible document management system to never be found again.

I think existence of documentation is a poor metric, personally.

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.

Ask if I find a bug in the code, what's the process to getting it fixed? And about how long is that?

Respect for the craft and those that practice it.

Reply on news.ycombinator.com