I'm not lazy. I'm efficient.

Nate Clark




The Frustrated Developer Manifesto

Nate ClarkNate Clark

Somedays are like

TL;DR; Development shouldn't be this hard.


During my years as a developer I have noticed several inefficiencies in tech departments that just baffle me. I have also learned that I am not alone or even in the minority. Time and time again I've seen good engineers polish up their résumés because of these problems. This is what led me to writing a lengthy email to my boss to help address and hopefully resolve some of the major pain points of development. I would like to express that this list is based upon my own observations and is geared toward removing hurdles and returning developer focus to coding. Ya know, that stuff we were hired to do.

Developer Frustrations

The version control system should requires VPN to push/pull code or access web app ...but it shouldn't.

  1. For god's sake, leverage ssh keys.
  2. Requiring login creds for the web app is perfectly acceptible.
  3. Requiring VPN is an impediment to getting real work done.

All services should be public and require an auth token to access ...but they don't.

  1. Stop hiding behind IP restrictions or an internal network.
  2. Restricting services prevents rapid prototyping.

We should be using one chat client, one email client, one conference tool ...but we're not.

  1. How many communication clients does it take to screw in a light bulb?
  2. We all love having to hunt down the best way to contact someone right?
  3. Every employee should have access to all of the communication clients.
  4. We should use the best tool for instant messaging, email and conference calls.
  5. Where does it state these have to be part of the same software suite?
  6. Having more than one of these to talk to coworkers is like requiring employees to have 2 or more cell phones charged and on their person at all the times.

We should eliminate the need for VPN unless it is absolutely necessary ...but we're not.

  1. Why are VPNs still a thing? Seriously.

Deployments should be continuous, quick, and cloud based ...but they're not.

  1. One click deployments? Yes please.
  2. Continuous deployments? Yes please.
  3. Deploys should take seconds. Less than 5 minutes if tests are ran prior to push.
  4. Web app? Yes please. Provides visibility to build logs and overall deploy health.
  5. Codeship, Jenkins, Travis, Ansible, Docker are all modern tools that make this easy.

TDD (test driven development) should be a priority ...but it's not.

  1. Services absolutely should be.
  2. Code coverage is cake.
  3. The alternative is a unmanageable pile.

Production logs should be accessible ...but they're not.

  1. Again, behind a VPN is a garbage policy.
  2. Combing through file dumps make my skin crawl and my optometrist rich.

Logging should be outsourced ...but it isn't.

  1. Are we in the business of log consolidation and availability? No. Didn't think so. Then why are we reinventing a crappy wheel?
  2. We should leverage a logging service. Less responsibility, better uptime and reporting.

User/Account management and auth should be outsourced ...but they aren't.

  1. Did we all of the sudden become OWASP experts? No. Then why are we writing our own security layer? Again, reinventing the wheel.
  2. Convoluted account structures in Active Directory make for a nightmare to manage. Let's not forget a custom UI to manage it and a swiss cheese security service for all the applications to implement. Everytime we customize we cost the company thousands in development time.
  3. There are SaaS solutions out there that are cheap and easy. They are just as flexible but you get the added (constantly updated) security blanket and externally hosted management UI out of the box. Separation of concerns are good right?

Internal services should be stupid easy to integrate ...but they're not.

  1. RESTful please. SOAP has never tasted so bad.
  2. Postman collection and Swagger documentation should be requirements for deployment

Onboarding new hires shouldn't require multiple support tickets ...but it does.

  1. I understand that each new employee's access varies, but it doesn't mean I should have to send 2 or more tickets to various teams to get it all done.
  2. Who is more qualified to find the right people to fullfil an access request; HR or DevOps?
  3. What type of ticket; DevOps? Support? Service desk? Travel? I don't, nor should I know the difference between these. There should be one entry point that is funneled to right people. I am tired of getting responses from DevOps or the Service desk that say send the other a request for X, not Y, and Z.
  4. Wouldn't a document somewhere make erveryone's life easier if it spelled out where we go for each type of request? No. One inbox, one entry point, all the things get done in orderly fashion.

We should actively persue developer continued education (CE) ...but we're aren't.

  1. Passively encouraging CE is a losing game.
  2. Strongly encourage online coursework and conference attendance.
  3. Make it a core goal during the review cycle.

Cross-team code reviews should be common ...but they're not.

  1. A different set of eyes always sharpens my code
  2. Teams coding in a silo become complacent

Dev managers should give extra credit homework ...but they're not.

  1. Tons of innovation lie outside the confines of the 9-5 workplace
  2. Discovered something cool coding after work? Show and tell us for a free lunch.

We as a company should sponsor or provide monthly stipend for personal dev accounts ...but we're not.

  1. Github, Bitbucket, Codeship, Cloud9, Heroku, Docker, Ansible, etc are all great dev fertilizer.
  2. Extremely cheap compared to returns.

We should have quarterly company outings ...but we don't.

  1. No company outings = Is the company circling the drain? disorganized? uninvested in their people? Perception is reality.
  2. The grind will kill us. We need a breather.

We should mark off one day a month for developer skunk works projects ...but we never do.

  1. Dedicate weekly/monthly dev days to spur innovation
  2. Only project restriction is that it must be in the realm of tech development, don't force business related work because it defeats the purpose and stifles creativity.
  3. Any and everything from Docker to RaspberryPi to 3D printing.

We should be employing interns but right now isn't a good time ...but now never is.

  1. Some of the best developers I have had the pleasure of working with started out as interns.
  2. What better way to check your process, UI, documentation than throwing it at an inexperienced person?
  3. Dirty deeds done dirt cheap. In terms of salary, they are the cheapest available.

let netFrustrations = 0;  
let foundPositions = 0;  
while(developer.employedHere) {  
    netFrustrations = developer.doWork(inefficiencies, task);
    developer.frustrations += netFrustrations;

    if(developer.frustrations >= (developer.maxFrustrations * 0.90)) {
    else if(developer.frustrations >= developer.maxFrustrations) {
        foundPositions = developer.findOtherPositions();
        developer.employedHere = foundPositions.length === 0;

    // TODO: Reduce the total number of inefficiencies.
    // inefficiencies.reduce();

    inefficiencies.talkAboutReduce(); // HACK: Mock method until reduce() method is working. Doesn't actually reduce anything.
Nate Clark

Nate Clark