Lessons from a Necromancer

by moodyharsh 2016-09-23

What follows is a short summary of the lessons dispelled by Pieter Hintjens in his [blog](http://hintjens.com/blog:125). He has built zeromq used for distributed messaging and architected a thriving distributed open-source community around it.

If you stop executing Pieters’ Code, the ghosts in the machines might just sing back to its Necromancer. I suppose the code of a Great Programmer follows the Tao. It is everywhere but it is silent.

Here’s Pieter giving a neat little trick to manage issues.

I have abridged some sentences for brevity but you should really read the original [blog](http://hintjens.com/blog:125) post. As far as I know he is also one of the few Programmers who has ventured into non-fiction writing and his books and perspectives are absolutely absolutely insightful and painfully real.

  • Technology is a slave to personality. It doesn’t matter how good the design, when there are unresolved problems in the organization. People are the real challenge. From caring about technical designs to caring about people and the psychology that drives them make the difference between a working project and a failure.
  • Logic doesn’t apply, when people work on a pseudo-mystical belief.
  • You need to follow the money, and understand how it flows.
  • The more your clients pay you, the more they appreciate you and listen to what you say.
  • Psychology of sunk costs. “We’ve spent twenty million on our goddamn mainframe and goddamn you if you think we’re going to junk it just because you have this new fancy-wancy UNIX thingy.”
  • Self-interest of vendors. “Sure we can expand the main memory from 64MB to 128MB. It may be a little expensive, but mainframe memory is special! It’s better than that cheap, unreliable UNIX memory!”
  • Politicization of IT. “My departmental budget is $10M per year, and you’re talking about slashing that by half and yet adding 10x more users? Are you insane? You’re fired. I’ll find a consultant who agrees with me.”
  • Fear of the unknown. “Why would we use that ‘UNIX’ thingy? It’s just a large PC, totally unreliable. And anyhow, UNIX will never be widespread. No, we prefer our tried-and-tested mainframe architecture that runs real networks like SNA LU6.2!”
  • Separate acquisitions simply can work organically, unlike banks and Internet firms, where sending data around the organization is their core business.
  • You often don’t know what the real problem is until you get very close to it.
  • All business run on the assumption that theft will happen, if it can (mentioned off-handedly).
  • Killer whales attacking a young baleen whale. Politics.
  • Don’t try to fix existing organizations. Start new ones.
  • Identify the riskiest parts of your architecture and bring them under your full control.
  • Test everything in isolation.
  • Don’t expect random work from random vendors to magically work together.
  • Do not develop and test in your production environment.
  • When you use hardware and software that bends to your will, you can work significantly faster.
  • Sharing so-called “mutable” data between threads is a Really Bad Idea.
  • If you want to make truly massive systems, it’s worth understanding the transaction processing (TP) model.
  • Making systems more complex, to try to make them “reliable” will usually make them less reliable.
  • Fail-over automatically and recover manually.
  • When you are a technology company, use your own technology in your projects. Don’t accept client requirements that sabotage your own vision and future. It isn’t worth the short term gains.
  • You can do a lot with little, if you are creative.
  • The foundation for a good project is: a competent client who knows the business and has power of decision; a full-stack team that can deal with the work, at all technical levels; and a technical platform that is both dependable and tractable.
  • If you have the trust of your client, and s/he has real power, you have done half the work already.
  • When things go wrong that even marginally involve you, assume responsibility until you know where the real problem lies.
  • Never build closed source, period.
  • Be nice to people, even those who hurt you.
  • Patience.