Development Environment Tips

Just Say No to "Developmestuction"
You need three environments: Devel, QA, and Production. Never mix them. Have separate hardware, separate databases, separate directory structures, separate everything. Development will be a bunch of sandboxes, as many as you have projects, and often living on developer workstations. QA will be running your Release Candidates for testers to bang on. Production will run nothing that hasn't gone through QA first

Be able to create new sandboxes with one clickWrite a script that installs all the dependencies, configures the database, sets the connection strings and so-on with just one or two clicks. You want to encourage your developers to spawn as many dev environments as they want, or else they'll recycle old environments when they get lazy, contaminating test results in the process

Never give anyone but developers read/write access to Devel resources
One day you'll wipe out the Devel or QA database to begin a new round of testing with a clean slate, and the next minute someone is paging you frantically because you forgot to change a connection string after deploying a program, and they've been writing production data to your test environment for months. Deny read/write access to Devel resources for any account that isn't for a developer, and you'll catch any configuration mistakes early

Do everything in your power to shorten the development cycleThe development cycle is: code -> compile -> run -> debug. If it takes an hour to compile, find a faster compiler or faster CPUs. If running it means spending twenty minutes setting up a test environment after each compile, then find a way to automate it and get that gap shortened to a few seconds. If attaching a debugger takes 10 clicks and a password, find a way to eliminate as much as you can. And for pete's sake, make it a priority. If you minimize the noise between when a developer thinks of a change and can see that change happening, then your projects will go orders of magnitude faster

Even one-man shops need source control management (SCM)
Source control should be seen as an extension of the programming language and the basic tools for organizing code. If you like #Regions and subroutines and organizing code into files and folders, then you'll appreciate the ability to organize code in time and variety, too

The road to QA goes through the SCMMake it a rule that all code that gets to the QA environment must have been checked-out from the SCM. Never copy files, commit them from Dev and then run an update or checkout on QA. This should also apply to compiled code: only deploy binaries that have been built from a clean check-out of the source from the SCM. This will guarantee that you didn't fail to check-in something important

Use an SCM that's good at merging
When it comes to managing changes an SCM either works by merging files, or merging changes. The ones that merge files (CVS, Subversion and others) are not as good as the ones that work by merging changes (GIT, Mercurial). Having the power to split codebases into different branches to explore new features and bugfixes, then merge them together into whatever fusions you need, is like having a command language for gene splicing

Don't think of branching as temporary
Try to give up the idea of a "main" trunk of code. At any time in the program's life your "trunk" could be woven out of any combination of branches you have at the time. Don't think of branches as temporary excursions that must be merged back in after the experiment or bugfix is complete, but as definitions of where the program could go

Use virtual machines for clean slates and hostile hosts
An easy way to create a testing or QA machine with a clean slate, whenever and as often as you like, is to prepare a virtual machine in Microsoft's Virtual PC or VMWare. Save the image in a repository and peel off a copy whenever you need it. Also, when you have a bug that only manifests on certain configurations of workstation or server, see if you can replicate that configuration in a virtual machine, then archive those images and make it part of your QA process to test against them all before each release

Case tracking is part of the specThere are three parts to the spec of any program: 1) the real requirements, 2) ponies, unicorns, and cup-holders, and 3) all of the stuff that everybody discovers during development. Case tracking systems (a.k.a. bug trackers) are used to fill in the third part, and if you don't have one then your spec will be incomplete

Automate documentationMany languages now support a way of building documentation based on properly formatted comments in the code. Sandcastle for .Net, POD for Perl, and so-on. Automate this so the documentation is built every time new code is checked in, and it will never be out of date

A Build Server is a sleep aidA Build Server is any machine that checks out newly committed code, tries to compile it, runs all your unit tests on it, and regenerates all the documentation from formatted comments in the code. The reason for having this is because programmers are too lazy to do those things themselves, but the real reason is to make it easy to go home on Friday and sleep easy the whole weekend, because you'll check-in all your last changes at 3pm and know you're good to go by 3:25

Visual Studio? Have a separate app.config for Debug and Release targetsOpen the .csproj or .vbproj files for editing in Notepad (they're XML), find the <PropertyGroup> tag where the condition is for the Debug configuration, and add a new child element that looks like this:<AppConfig>debug.app.config</AppConfig>Now copy app.config to a new file called debug.app.config, and make changes to your connection strings, addresses, directories, logging, etc, save and reload the project. This version will now be used whenever you build to the Debug configuration, while the original app.config will be used when you build to the Release configuration

Development Workplace Tips

Quiet is better than collaborativeThere is a hypothesis that making developers work in an open environment with no walls or cubicles will foster communication and creativity. This is true. However, it is an extremely expensive benefit, costing you more than half of your productivity. Developers will still communicate over Instant Messaging and email when they need control over their interruptions, and get together in meeting rooms when they want to brainstorm creative ideas and synchronize everyone's knowledge of the project

Buy doors, get a free programmerEvery programmer that you put into an office with a door that closes is like getting another programmer for free, because productivity can double when they can shut out distractions. It takes up to 15 minutes for a developer to get back into the flow after a single, 30-second interruption, so a few distractions per day can destroy an enormous amount of value

Buy twice as many pixels, get a free programmerAnother productivity doubler is to give them either two monitors, or really big monitors (27" and up). The reason it works so well for programmers is because one screen has a maximized IDE, and the other screen has a web browser with documentation in it. When debugging, the second screen is where the programmer will put the program so he can watch what's happening while stepping through wonky parts of the code. He will progress much faster than by alt-tabbing between windows, or tiling them so he can only see half of each

Cram as much RAM as you canIt'll be used to open multiple instances of the IDE and VMs for the project plus the libraries and services it relies on. You should minimize how often your developer has to shut down a program to free up enough resources to load something else he needs

Printed books are cheap monitorsYou still need to give programmers at least two monitors, but you can get a little bit more mileage by purchasing printed books. Give O'Reilly a decent fiscal quarter, because they're like really cheap third, fourth, fifth, and sixth monitors. Give programmers something to read on the toilet

You can never have too many whiteboardsConsider "whiteboard paint" or melamine sheets ($12 for an 8'x4' sheet at home improvement stores, glue them down with "Liquid Nails") to cover every square inch of programmer offices and brainstorming rooms. The reason you want to have a huge amount of whiteboard space is to discourage erasing, so ideas and objectives will keep tickling the developers brains every time they walk into the room or gaze off into space. Buy lots of different colors of markers, and never have more than one eraser per room

Keep the office in good repairFix broken windows, broken tiles, leaky pipes, busted A/C, drippy faucets, blown fuses and potholes in the parking lot. If the developers see and feel that their work environment is always kept in good repair, they will feel the pressure to keep their software bug-free and in good condition, too

Decorate tastefullyKeep some potted plants (watered and trimmed regularly), ditch the 70s wood paneling and carpet, buy some modern furniture and paint the walls. And as importantly as the quality would be the consistency: if you go for a modern look, then don't mix it in with classic-style furniture. Just like with keeping the office in good repair, these environmental cues will be reflected in the developers' work. Quality, consistency, and taste

Give flexibility, get flexibilityYour developers want to work flexible hours, even work from home sometimes, but it looks bad to the other departments who must show up at 8 and leave at 5:30. Who do these programmers think they are, showing up whenever they feel? Sleeping in when there's work to be done? A developer's productivity is a function of his brain activity, so he's working for you at 7:30am when he's in the shower, experiencing creative pause and realizing there's a faster, shorter, cheaper way to deliver the feature you want. Creativity does not start up at 9 and shut down at 5. Consequently, they want flexibility. If they're bushed in the morning after an all-nighter, let them come in at 11. In return, you'll create the conditions that let you execute new directions and exploit short-lived opportunities. Why? Because they will deliver better value at lower cost with code that can adapt to many different situations. The other departments will care less when the programmers give them tools that let them be flexible, too

Developer Retainment Tips

Just because it's worse elsewhere doesn't mean you won't lose your top talentOther companies may indeed force 45-50 hour work weeks plus weekends, cram them in elbow-to-elbow and give them health plans with a $3,500/year deductible, but it doesn't mean you can sit pretty with your lead developer grinning and taking it. There's four things a developer, like any other human being, wants from a job: competitive salary, comfortable environment, challenging work, and a future. If you keep filling vacancies at the top from outside the company, then the bright kids at the bottom will seek work elsewhere even if it pays the same but gives them a sense of having a career path. If you make them work in a closet with 4 other programmers and inadequate ventilation, they'll bolt for the first place that gives them an office with a window. If you hire a whiz-kid and make him edit Microsoft Access forms in Visual Basic, you won't see him after a few months. If they find another job that pays more but has longer hours and commute, they will take it because it'll make them feel like they're getting paid what they're worth.Of course, you could just hire H1B workers exclusively. That'll last until they get citizenship, or the other country's economy rises above ours

Hire a maid and a janitorHave someone clean the offices, empty the trash cans, replace the paper towels in the bathroom and vacuum the carpet. Have someone replace burned-out lights, empty water-cooler bottles and unclog the toilets. Nobody wants to work in a cesspool and they won't see it as their job to do basic janitorial work

Stock options are nice, but only if they're worth somethingIf your stock is traded in pink sheets, your employees won't see much value in their options. "Options" are not a magic word that can be used to retain staff and stop people from quitting, nor do they have much power in the beginning when they're still years away from maturity. However...

Tell them about your visionEven companies traded OTC can give employees the sense of having an investment if you share your plans and vision with them. They don't like doing the 9-to-5 working for a machine, but they'll put in more effort and longer hours if they know where the company is aimed for and feel like they're a key part of the plan. So tell them the plan. You don't have to whip-out ledgers and forecasts and numbers, just say "we want to be the leader in Market X, and here's how we plan to do it"

Listen to their ideas and give them credit when you implement themYour web developer is trying to tell you how to improve your search engine rankings by getting rid of IMG based text, but you ignore him. Then a year later you hire a fancy high-priced SEO firm who tell you exactly the same thing, and now you command your devs to use CSS and ditch the GIFs and PNGs. A month later you're wondering why he's handing in his two-weeks notice. Do not treat ideas as if they're only worth the salary or title of the guy who came up with them. It's okay to be dubious of ideas if they don't sound right to you, but if you hear them confirmed then just say something like, "I didn't fully appreciate your idea the first time I heard it, but now I do. Thank you."

Stupid, little things matter. Like candyM&Ms are cheap. So are cereal cups, buckets of pretzel sticks, coffee, tea, and fancy-ass sweeteners like Agave Nectar. Stock these in the break room and don't put them behind a vending machine's paywall, unless the prices on that machine are so low they barely cover cost. Get one of those K-Cup coffee machines and stock at least 10 flavors. Get a La Marzocco Linca espresso machine if you've got enough Metrosexuals on the payroll who really want it. Sure, what the hell. And you know what? It's cheaper than paying for another 30 days access to Dice.com and re-training the next shmuck

Employment Retainment Tips

Bosses work at a different abstraction layerNo matter how many intermediate bosses you have, the one who signs the paychecks doesn't care if your LAMP hosted SOA architecture with ACID transactions can handle 200k requests per second. Why are there even 200k requests per second when we only max out at 10k visits per minute? Your boss is a programmer of a different kind, but he or she works from a different abstraction layer with a different kind of API. You are supposed to expose a human API that converts requirements into results. It's okay if you need dependency injections--that's what a Project Manager is for--but returning low-level data structures and error codes to high-level processes will result in a system crash, and the system operator might respond by replacing the faulty component

Don't be passive aggressiveIf your boss asks for something that can't be done, then do three things: 1) explain why you don't think it'll work, then 2) give an honest attempt to solve the problem anyway, and 3) show them what your problems are. Even dim managers are capable of understanding that their desires can't be filled the way they want, and even though you may find it hard to express the problem in business terms (cost vs. return), they can do the calculation themselves if you help them understand. They're not afraid of failure, but they are frustrated by employees who don't give them the expertise, time and patience that they're paying you for. What an employer wants is an employee that can solve problems, especially the ones that don't seem to be solvable

Current earnings are not a guarantee of future growthThe company had a good year, but the bonus was lousy. Clearly they don't respect you, right? But meanwhile, in other parts of the universe, the stock market lost 40%, Iceland went bankrupt, unemployment rates went to double digits and the bailout is going to cost more money than has ever been minted. You're not stupid; you cut back on spending, paid off your credit card and started putting more dosh in the bank. Nor is your employer stupid. They know that even a good year now isn't a guarantee of good years in the future, and the best way to protect themselves against the unknown is to cut spending and stay lean. Unless you work for Goldman Sachs, that means a small bonus or no bonus. But don't burn your bridges because you think it isn't fair. Companies are living things that want to grow, and even if you have access to the sales database and can see what's being earned, you still don't have the full picture. If the company was genuinely miserly, they'd be stingy even when there wasn't another Great Depression on the horizon

Do not hide workSix months have passed since they assigned the project, and now the boss demands access to your dev environment to see what you've done. She finds: 2 tables, 1 page of code and a class called "paulaBean". You are so totally fired. This could have been avoided, however, if you didn't just let them see into the dev environment from the beginning, but you insisted on it with requests for feedback on work in progress. Now this won't help you if you're a genuine deadbeat who wants to milk it for as long as possible under the sword of Damocles, but the general practice will help make sure you never get into a situation where the employers expectations greatly exceed what you've been able to deliver. You want the boss to expect that there'd only be 2 tables and 1 page of code, and not fault you for it

Deal with frustrations constructivelyYou can't hide resentment forever, and eventually your boss will notice you're unhappy. Some bosses will talk to you to find out why, but others will just show you the door. Rather than seethe and grumble, take your concerns up the chain-of-command, showing why you have a problem and how you think it could be addressed. Never vent in the workplace and check your attitude at the door