9 ms·
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
by orev 4y ago
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?
- ThrowawayTestr 4y agoIdk, not having admin rights is super annoying.
- beeforpork 4y agoWell, 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'.
- thfuran 4y ago>less things to care about, more reason to leave at 5. What do you mean?
- mikewhy 4y agoIf 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.
- ornornor 4y agoEven 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.
- Xylakant 4y agoI 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.
- zamalek 4y ago> 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.
- dasil003 4y ago> 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".
- zamalek 4y agoI 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.
- deleted 4y ago[deleted]
- oriolid 4y ago> 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.
- closeparen 4y agoIt'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.