Skip to main content

7 Things Development Managers Know in 2017

Here is a list of 7 things you need to know, in order to be a manager of software developers, within any significant modern company. See how many you already know.
  1. Beauty = Value
  2. Functionality = Quality
  3. Quantity = Usefulness
  4. Physical Labor = Knowledge
  5. Genetic Makeup = Technical Literacy
  6. Hype = Skill
  7. Results = Magic


  1. Beauty = Value
    • Technical competence is not necessary to judge software quality
    • Always attribute inherent value to software with a cosmetically appealing presentation
    • Applying hype makes software more valuable
    • If hype is present, so is the associated value
  2. Functionality = Quality
    • If it seems to work how it should, then it really does
    • People who have been doing it longer must be better at it
  3. Quantity = Usefulness
    • Usefulness can be measured by quantity of output
    • The more people working on software development, the faster it will get done
  4. Physical Labor = Knowledge
    • Expect workers to create a comprehensive, accurate, detailed plan before beginning any work
    • Expect workers to estimate the amount of time it will take, and with some degree of accuracy
  5. Genetic Makeup = Technical Literacy
    • Non-technical people cannot possibly become technically competent
    • Technical competence isn't necessarily beneficial for everybody
    • Workers do not deserve rewards to be based on their level of technical competence
    • It is not worthwhile for a non-technical stakeholder to try to acquire any level of accurate understanding in a technical subject
  6. Hype = Skill
    • Non-technical people are perfectly qualified to judge the value of a technical worker's experience
    • People who interview well are technically competent
    • Formal education is an indicator
  7. Results = Magic
    • Technical competence is not a necessity, before you can mandate implementation details

And now, for 4 bonus points:

  1. Activity = Progress
  2. Complexity = Security
  3. Policies = Enforcement
  4. Fiat = Fact
If you knew most of these things before reading this article, then congratulations! You are probably a manager of software developers or an executive at a significant company. If you knew all of them, you are probably a middle manager. If you didn't know any of these things, you are probably the opposite: you yourself are probably merely a software developer.

If you have somehow managed software developers without knowing these things, you are probably an exception. Be sure to leave a comment and explain how you did it.

Disclaimer: This content is not intended to indicate any specific individuals or companies. Any apparent similarities are strictly a coincidence.


Popular posts from this blog

Reality Checks to Demystify Buzzwords

As an IT insider, I feel I have something valuable to offer nontechnical people in terms of correcting misinformation. Here are a few simple tests for some popular buzzwords in tech. When evaluating a product or service, if you can honestly answer Yes to the reality check question, the buzzword probably truly applies. If the answer is No, it is probably fake. agile Does it make the developers happy? blockchain Does it cut out the middleman? cloud Does it automatically scale? microservice Does it only do one thing? object oriented Is it mostly made of interfaces? RESTful When requests arrive at a certain address, are they ready to use (without parsing)? unit test Does it prevent the tested code from touching anything outside itself?

The Importance of Direction

Which would you say is more important: getting somewhere faster, pushing something harder, or going the right direction? It should be obvious that no matter how much speed or power you use, that won't do any good if you're going the wrong direction. It could also be pointed out that early in a journey, even a small change in direction makes a big difference in where you end up. Therefore, we should make sure we have our direction correct, as the first priority.

How (Not) to Handle Different Exceptions

Came across this sample from a certain multi-billion-dollar company, purporting to show how to implement exception handling. I slightly changed a few cosmetic details to make it anonymous. try { // ... } catch (GeneralException e) { if (e instanceof SpecificExceptionA){ // ... } else if (e instanceof SpecificExceptionB){ // ... } } This is a true actual story--you can't make this stuff up. Yeah, I thought it was pretty hilarious; so I felt like I had to share it.