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

As much dev control as is practical

[Anonymous Coward]

BYOD followed by CYOD followed closely by a Linux laptop with sudo access. Development is a creative process, and every developer has their own set of tools and workflow productivity scripts and utilities that make their process work best for their mindset. Hiring a developer and than insisting that they use your management chosen laptop, with your management chosen OS, with your management chosen text editor and so on and so forth is like hiring a painter to make a portrait, but insisting they use your easel, your paints, your brushes and your canvas. Yes, it's possible to get good results like this, and yes some people will even do it, but ultimately it will cost you more, either in pay, time or resources.

Obviously some amount of standardization is necessary (version control, language etc) but as much as is practicable (even to the possibility of different IDEs), allow your developers to setup and control their personal dev environment however they want it.

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.

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.

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.

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

[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.

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

[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.