Ask Slashdot: What's the Best Working Environment For a Developer?

New submitter Dorgendubal writes: I work for a company with more than a thousand developers and I'm participating in activities aimed at improving the work experience of developers. Our developers receive an ultrabook that is rather powerful but not really adapted for development (no admin rights, small storage capacity, restrictive security rules, etc.). They also have access to VDIs (more flexibility) but often complain of performance issues during certain hours of the day. Overall, developers want to have maximum autonomy, free choice of their tools (OS, IDE, etc.) and access to internal development environments (PaaS, GIT repositories, continuous delivery tools, etc.) . We recently had a presentation of VMWare on desktop and application virtualization (Workstation & Horizon), which is supposedly the future of the desktops. It sounds interesting on paper but I remain skeptical.

What is the best working environment for a developer, offering flexibility, performance and some level of free choice, without compromising security, compliance, licensing (etc.) requirements? I would like you to share your experiences on BYOD, desktop virtualization, etc. and the level of satisfaction of the developers.

Comments

Good Setup

[Murdoch5]

This would be my recommended list:

1) Give them the choice of OS, Linux or if they have to suffer, Windows / Mac.
2) Unlock the notebooks so they have absolute full control of them, that includes admin accounts.
3) Stop using Ultra-books, use high end notebooks with loads of Ram, good M2 / SSD Storage and high end processors.
4) Don't use any kind of virtual environment, they just have no performance to offer and should never be used in a desktop setting.
5) Open the development tools and let them use what they want.
5) Standardise to GIT for the SCM, as it's the only good SCM tool on the market.
6) Use good team communication tools.
7) Try to steer clear of Microsoft based tools, for instance TSF, it's a giant pile of steaming shit.
8) Allow BYOD.
9) Give every developer a multi head setup with good keyboards and mice, this never gets acknowledged, but a good Mechanical keyboard is essential.
10) Every developer should have a stand up desk, that can also covert to a sitting position.
11) All the developers should have isolated build servers, that they have near full control over, maybe not the root account, but damn near.
12) Don't allow IT to dictate how the computers for the developers are used.
13) Buy high quality chairs that are designed for long work sessions, they can be pricey but they're worth it.
14) Allow developers to have full flex time, so they don't have strict hours, they can work 8 hours over the course of the day.
15) Don't allow management to over plan meetings.


Basically treat the developers like the rockstars they are.

Make their computers less restrictive?

[djbckr]

If the ultrabook is sufficient, then why not have a configuration that is more setup to a developer's line of work? In our company (we have about 100 devs) we have a different setup than the rest of the company. All of our source code and build tools are on central servers that we must interact with, but we pretty much get to do whatever we want with our machines. Some choose Eclipse, some choose IntelliJ, some others use Perl or the language of their choice. Most are using Macs, but some of us (me included) use Linux exclusively - so long as we can get our work done. We all have root/admin access to our machines to put whatever tools we want in whatever configuration we need, and if we screw it up, it's (more-or-less) on us to fix it. Several good screw-ups and you are dinged for it.

Picking your post apart:

[guruevi]

I work for a company with more than a thousand developers
- Already, you're in the wrong venue. Unless you're a C-level executive, don't expect much change. You need white papers and golf clubs to change your company's policies, not /. comments.

and I'm participating in activities aimed at improving the work experience of developers
- You're an outside consultant tasked with reducing the workforce by improving productivity. Don't forget that when you deal with your developers.

Our developers receive an ultrabook
- A real developer can't work on an ultrabook
that is rather powerful
- It's an ultrabook, not powerful

but not really adapted for development (no admin rights, small storage capacity, restrictive security rules, etc.)
- Your company is treating your developers like sales and customer support. Are you sure you're dealing with developers and not glorified tech support? If you are dealing with developers, you will also see high turnover and rather little experience. You're probably dealing with a developer sweatshop, not a well-managed tech house, change the culture around hiring first before you call these people "developers".

- They also have access to VDIs (more flexibility)
Virtual desktops are for things that you require little interaction with or that can easily be destroyed, not for development.
- but often complain of performance issues during certain hours of the day
Well, what do you expect, again, you're treating developers like tech support, your company's priorities are wrong.

- Overall, developers want to have maximum autonomy, free choice of their tools (OS, IDE, etc.) and access to internal development environments (PaaS, GIT repositories, continuous delivery tools, etc.)
If they don't have those, they're not going to be very productive developers. If you have thousands of developers without even basic version management and build tools, you better quit now, the company is doomed.

  - We recently had a presentation of VMWare on desktop and application virtualization (Workstation & Horizon), which is supposedly the future of the desktops.
Who got to play golf? VMWare is well behind on the market and only survives through inertia and takeovers. It's the Microsoft/IBM of VM.

- It sounds interesting on paper but I remain skeptical.
Citrix did it better in the 2000s. It failed. For good reason.

- What is the best working environment for a developer, offering flexibility, performance and some level of free choice,
You answered your own question

- without compromising security, compliance, licensing (etc.) requirements
Recommend replacing management first. Compliance and licensing is a managerial thing and should be hardly required since the most powerful development tools are open source, for everything "necessary" that deals with evil business partners (Adobe, VMWare, Microsoft, ...) get a site license. Your developers should be smart enough to maintain their own security if they need admin rights, the ones that aren't can be weeded out immediately.

- I would like you to share your experiences on BYOD, desktop virtualization, etc. and the level of satisfaction of the developers.
BYOD: If your company is too cheap to provide the necessary machines then they get to deal with the headaches of BYOD.
Desktop Virtualization: Tried and failed in the previous dotcom bubbles.
Level of satisfaction is directly related to your management.

Re:Private Offices

[codeButcher]

Last night I read a bit about the Pomodoro technique and specifically what is said about distractions and how to avoid them. One view was that many websites (esp. social media) are geared to grab more and more attention to keep eyeballs on it longer (e.g. YouTube suggesting more similar videos, Facebook trying to serve up stories in your story line that they think will interest you, StackOverflow having all these very interesting questions from other StackExchange sites on the right - even Wikipedia that has hyperlinks to more interesting articles :-) ). And the one suggestion is to avoid such web browsing during your short rest periods, since they will inevitably lead to those rest periods becoming much longer...

Then it hit me: Open plan offices are social networks embodied in physical workplaces - long before social media even was a thing.

Re:Private Offices

[frank_adrian314159]

The best teams I've been on worked pretty closely with each other, and often identified bad ideas before they got too far.

The best teams I worked on had people having enough private space and time to think about the ideas enough so they figured out why the ideas were bad themselves and didn't bother others with them unless they were good ideas.