Hacker News Reader

Comment by orev | Hacker News Reader

This list smacks of a developer prima donna mentality and if you think most of those rationale explanations are reasonable, you’re more likely to be a liability to the organization and not a team player. Companies have numerous goals, responsibilities, and compliance requirements that you don’t get to ignore or avoid simply because Steve Ballmer chanted about “developers” on stage that time.

What would you think about a business person who thought testing was a waste of time because it slows down releases? Or they don’t want to use an issue tracker because it just easier to tell you something in the hallway? Those thing slow them down, so why bother?

View on HN

> This list smacks of a developer prima donna mentality

The reality is that the market for good developers is so competitive that they could just walk out and find 10 other places with better answers to these questions.

> testing was a waste of time because it slows down releases?

Not a single question is anagolous to this. Developers want a fast CI process (and testing can be fast, given adequate time allocated to improving CI) because developers are happiest when they are productive. What type of business person would say "no" to employees who only want to be productive? Apparently, the majority. The problem is when micro-management ends up prioritizing tracking work over doing work. It might help to listen to people who are passionate about shipping product, instead of shipping metrics.

Although it is a software concept, these questions guage the degree of accidental vs. essential complexity within an org.

> The reality is that the market for good developers is so competitive that they could just walk out and find 10 other places with better answers to these questions.

Sure, but will that be a better place to work?

Ultimately there are many failure modes for software engineering teams, and grilling the interviewer with a series of highly-specific workflow questions is not likely to yield much insight. If the team is really as dysfunctional as the author fears, then you're not likely to get an answer that is on the same wavelength as you anyway.

You're better off asking things a little higher level and a little more open-ended and then reading between the lines. So for example, instead of:

> Does this team or any of the related teams have a person who actively rejects proposals to improve the code base?

You could ask:

> What are the biggest problems in the code base currently?

You can then engage in a dialogue and probe into details organically. This will yield much more fruit than asking a question to which the obvious answer is "no, of course not".

I definitely agree with your ideas. I aimed only the refute the concept of "developer prima donna."

Just like any codebase will forever contain some amount of accidental complexity, so will any org. It's all about whether it is being tackled or embraced. While these questions may not be perfect, accidental overcomplexity can (probably will) make your job miserable.

> Sure, but will that be a better place to work?

If an employer doesn't give developers local admin rights on their machines, I'm quite certain it's not going to be a better place to work for me.

The reality is that the market for good developers is so competitive that they could just walk out and find 10 other places with better answers to these questions.

That may have been the case in certain parts of the world for the past few years. The next year or two might bring some rude awakenings for mid-to-senior devs who are only a few years in and have never seen things any other way.

I was trying to work out how many of these questions a candidate could ask me - with the attitude implied by the tone and phrasing in the article - before I immediately terminated the interview and no-hired them. They might get away with one or two of the ones with reasonable underlying points with the benefit of the doubt about the attitude problem but I doubt they'd get past that. If they really can get hired at 10 other places instead then good for them but somehow I doubt that would actually be true for this kind of person. No-one wants a toxic prima donna on the team.

> reasonable underlying points with the benefit of the doubt about the attitude problem

So asking about CI times, code review process, admin rights, being able to run tests locally, and operating system choice would likely result in a terminated interview? I think the questions would be working perfectly in that scenario.

The point here isn't the questions. Asking questions on those topics in a mature and professional way would be absolutely fine. Asking a series of questions with an almost accusatory tone and evident my-way-or-the-high-way attitude would not and that is the concern many of us here appear to have with the linked article.

Idk, not having admin rights is super annoying.

Well, I kinda like it -- less things to care about, more reason to leave at 5.

But it's counterproductive for the company, and some experiments a developer may want to quickly do will never be done at all. It kills a lot of creativity. The same holds, of course, for restricting internet access so a dev might never find out whether an interesting looking github tool really is good (for doing productive work!). Also, the company probably wants their products to run on a diverse zoo of machines and OS versions prior to release.

So why a company would take away such access on dev machines is a mystery to me -- probably misguided (and futile) attempts to keep in 'control'.

>less things to care about, more reason to leave at 5.

What do you mean?

If it's not in your power to resolve an issue with your machine by the end of the work day, you should feel no pressure to stay late and fix it.

Even if it’s in my power to fix, why should I do this overtime?

Emergencies can happen where you need to stay an hour or two after EOD, but if it’s more than once a year I’m out, personally, local admin permissions or not.

I agree, but having them is also a huge liability. I’m always happy to have less privileges because it limits the damage I can accidentally cause. If someone competently manages my machine so that I can do my work without requiring root privileges, that works for me.

The actual question I’d be interested in is how do developer convenience and security stance balance against each other, and how are the inevitable conflicts resolved.

> What would you think about a business person who thought testing was a waste of time because it slows down releases? Or they don’t want to use an issue tracker because it just easier to tell you something in the hallway?

Massive red flags, take the job if you have to but keep looking and leave as soon as you can. I have actually worked for this business person, and wouldn't recommend the experience.

It's a matching process. If you as the employer feel this way, and the candidate feels these things are important, you're not right for each other. That's an appropriate thing to discover in an interview.

Personally, I work at an engineering-first company where management takes fairly seriously its task of providing us with a comfortable and productive environment. In this labor market, I wouldn't work somewhere that wanted me to be a "team player" about a shitty computer or micromanage my tasks. There are things to be a team player about, of course, but not the basic tools and structures for even beginning to get work done.

Reply on news.ycombinator.com