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

Private Offices

[Anonymous Coward]

Start with that. The best hardware on the planet is useless if you can't think due to noise and interruptions.

Re:Private Offices

[quantaman]

Start with that. The best hardware on the planet is useless if you can't think due to noise and interruptions.

Or at least high cubicle walls. A developer's most valuable resource is their attention, and other humans are extremely good at demanding one's attention. Even the reflection of someone walking by behind me is enough to cause a momentary distraction and a dip in productivity. It's no mistake I do my best work when I'm the only one around, to optimize productivity give people the ability to cut off distractions.

Re:Private Offices

[TheLongshot]

I disagree. I think members of the same team should be located together, rather than isolated in private offices. That way, if you need to bounce an idea off of a teammate, all you need to do is to turn around and talk, rather than having to get up and look for them.

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

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

[Tukz]

"bouncing ideas"

This infuriates me more than it probably should.
I have a co-worker who constantly feels the need to bounce ideas off me while I am usually busy and very focused on something.

We've recently started a slackboard for just this exact issue. Post your shit there instead of interrupting everyone because you need to think out loud.

Re: Private Offices

[Entrope]

People don't notice the productivity hit when they're typing code that could basically be written in their sleep. Most programmers have worked on projects where they do need to concentrate.

For those whose coworkers are thinking hard, I would recommend writing down your questions and asking them in batches of three or so. This has a lot of benefits:

You'll be able to answer some fraction of your own questions, either just by thinking more or by exploring the surrounding problem more.

You'll get a clearer understanding of what was missing from the design (or code or your own knowledge), making it easier to understand how to improve it the next time around.

You'll practice clear communications.

You'll amortize the cost of interruptions, which your coworkers will appreciate.

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.

An open plan office

[Anonymous Coward]

With a no headphones rule.

Re:An open plan office

[Mr0bvious]

I second this - developers need to remove them selves from their environment and become engrossed in what they are doing.

No headphones? That's would be business suicide, any decent developer will likely move very quickly.

What's the most important thing for devs? IMO being surrounded by like minded devs who enjoy their work. All the fluffy stuff around the office is not going to do anything to keep good devs, we can buy our own fluffy feel good stuff we don't *need* it from our employers (although it is welcome).

Hardware choices? That's not about keeping devs happy, it's a economic decision. Get them the best hardware you can afford if it makes their job quicker/easier/etc. There's nothing more to it..

We have our own toys already, I don't give a hoot what hardware I use at work as long as I'm not slowed down or restricted by it. If I am, then you've failed as an business since you're costing yourself hours of waiting for each dev each week, not a smart move.

Sounds like they already answered this

[OhPlz]

If they want to pick their own tools, let them. I don't understand this fear of giving developers admin access to their machines. What do you think is going to happen if they get this supremely powerful level of access? If some are happy with VMs, let them use VMs. If some want to install, configure, and update their tools manually, let them. If it becomes a problem for a specific developer, steer them towards a VM instead. If you can't trust developers to maintain their system then you probably shouldn't be trusting them to write your company's code either.

It seems like our uber powerful dev machines are turning into expensive terminals and the ESX cloud is our new time sharing mainframe. Everything old is new again.

Re:Sounds like they already answered this

[geekmux]

If they want to pick their own tools, let them. I don't understand this fear of giving developers admin access to their machines. What do you think is going to happen if they get this supremely powerful level of access? If some are happy with VMs, let them use VMs. If some want to install, configure, and update their tools manually, let them. If it becomes a problem for a specific developer, steer them towards a VM instead. If you can't trust developers to maintain their system then you probably shouldn't be trusting them to write your company's code either.

From a security point of view, you've painted a fucking nightmare. Look at how the average user chooses passwords when given the complete freedom to use "123456". Update tools manually? That would be never, because maintaining security patches takes time and effort they don't want to be bothered with that. Give them local admin rights and they'll install any development tool they feel like using, including ones that may need to be licensed properly in order to be legal in a business or corporate environment. They would bitch about disk encryption slowing their system down, so of course let's disable/uninstall that, dismissing any concern of IP or weeks of work gone due to laptop theft or loss, which of course leads into the next issue of local storage, as they would bitch about network speeds being too slow when doing work across any wire, so all work will be stored locally with no backups, ready to fall victim to hardware failure.

There's a reason you hire competent IT professionals and developers, because the latter does not replace the former; has nothing to do with trust.

It seems like our uber powerful dev machines are turning into expensive terminals and the ESX cloud is our new time sharing mainframe. Everything old is new again.

Users suck at security. Always have. Nothing is new, other than the threat of compromise or data loss increasing year after year, and tools being rather necessary to counteract that threat. Risk mitigation is the name of the game today.

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.

Nothing virtual

[Trogre]

For development, where you need actual performance for reasonable build times, run nothing virtually nor remotely.

Grunty desktop PC, triple monitors, with local storage and frequent scripted rsync backups to a shared server.

Also pop tarts and Xena tapes.

No admin privileges!!?

[rayd75]

Are you freakin' kidding me? How is a developer supposed to develop software that "requires administrator privileges" if he or she can't write to arbitrary directories and / or registry keys during normal, post-installation use? While you're at it, you might as well require your developers to use a 1080p screen, thus restricting their interfaces to actually rendering correctly on the displays of 99% of their users! What's next? Requiring the end product to run in an amount of memory likely to be supported on a single-socket motherboard and asking that code manipulating a database not be executed on the database server itself!!? Wow, just wow.

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.

Exactly that

[Weaselmancer]

I'm out of mod points or I'd mod you up.

My two cents - we have an open office plan where I work. So I like to stay after hours and work. Why? Because the lights are off, I don't have to listen to people milling around me all the time having conversations about the weather or last Sunday's game. Just me and the work I have to do. No distractions. It's blissful.

I can get more done in 2 hours like that than the previous 8.

Re:Exactly that

[Xest]

Which is why as well as a quiet space, I also think a good environment for developers is one that supports flexible working. I start at 7:30 and finish at 4, because at least I can get about an hour and a half to two hours in of decent code first thing before the office gets too noisy. Some of the other devs prefer later starts and do 10 until 6:30. As long as everyone is in between 10 and 3 then that's ample time for collaboration.

You shouldn't have to work an extra 2 hours over to get your work done, you should be able to come in 2 hours later.

Developers need to be well slept, and able to focus - a quiet working area is only part the equation, not being forced to work extra hours because the working environment is shit is another part of it. Home working at least every now and again can also often help with this for some people.

Re:Exactly that

[jandersen]

Very valid points, of course; the whole idea of open plan is stupid in so many ways; just to take a thing like indoor climate: small offices for 1 or 2 people can have individual heating and aircon, so the ones that like it hot can have that without hearing complaints from those that prefer it cold. You might even have a windows that could open a little bit.

But just as important as the physical environment is the freedom to choose your tools. Developers are skilled workers - I hesitate to use the word 'engineer', I think it is overused and easily misconstrued; an engineer can be anything from the guy that used to shovel coal on a steam locomotive, to a highly academic civil engineer. We skilled workers know best which tools are suitable for our needs. Some people like to use highly complex IDEs with suspicious colour schemes (which remind me of my misspent youth in Soho's nightlife), others actually prefer vi and make scripts in xterm - both setups can be equally productive. Managers prove again and again that they have no clue about what is important for skilled workers; they seem to think we are sort of like sales people, but not as clever, and since sales people fall for glittery kitsch and think the word 'leader' means 'alpha male', that is what they try to serve up to us as well; hence Dilbert.

Rant's over - I have real work to do.

A wall of pixels

[DRichardHipp]

You want as many pixels on your screen as you can get. Dual-head is better. (Triple- or quad-head is better still). This follows from the simple observation that the more information you can see at one time, the faster you can work and the fewer mistakes you will make.

Remember that the pixel-width of your screen is more important that the physical width of your screen. The physical width should be sized so that it completely fills your field of vision when you are seated comfortably and ergonomically. Your goal should then be to put as many pixels inside that fixed physical width as you possibly can.

Avoid programming on laptops. You cannot work efficiently while looking through a soda-straw.

Beware of VDI

[lucm]

Remote virtual desktops are okay for basic use, but even on high-end infrastructure there's a tiny latency which is quite annoying when coding (unless you type real slow). It's not "in your face" but you can feel it and it makes the experience unpleasant.