AGILE IS DESIGNED TO CAUSE BURNOUT

A

In software development, Agile is the most popular form of project organization and Jira by Atlassian is the most common tool used to keep track of that organization. But two different ideas from two very different places and times have convinced me that Agile is the primary cause of developer burnout.

Continue Reading

YOU'RE NOT MISSING ANYTHING BY NOT WORKING AT A FAANG.

Y

I make it a habit to never respond directly on The Orange Site, but a recent post there caught my attention and I wanted to respond to the poor guy. He said that he was on his third startup since getting out of university, but he'd never worked at "a big company" and feared that he'd somehow made it to 30 (OMG!) without ever learning "the right way to do something."

So here's the scoop: While I've never been in a FAANG, I have been at four middling-large corporations, the ones with "real" HR personnel nicked from Microsoft or Amazon or Google and "real" programmers lured away from Netflix and Apple: AOL, F5 Networks, Isilon/EMC, and Splunk. I've also been at a half-dozen startups, and here's the basic truth:

There is no right way.

Every company, hell, every team, has to learn on their own how to move forward in their environment. This world changes fast when it comes to management and when it comes to deployment. In the past twenty years, on the front end I went from raw Javascript, to Prototype, jQuery, Backbone, React, and now NextJS, learning a new "how you do the front-end" framework every four years. On the back, I went from C to Perl, Python, Node, and now Go.

The only skill that hasn't changed in all that time is SQL. It's gotten richer and faster, but it's still pretty much SQL.

Continue Reading

TYPESCRIPT OR BE DAMNED

T

I recently had a chance to finish up a major refactor of the codebase for BFDLang (Bureaucratic Form Design Language), a hefty (and now Turing-complete) language for describing, well, bureacratic forms to web documents. I work at an insurance company, and BFDLang gives the administrative staff the power to describe a form in a spreadsheet and immediately see what it would look like as a web document; it's a powerful, in-house no-code solution for them backed by a ton of code, mostly written by myself and two junior developers. The refactor was huge, and complicated, and I couldn't have done it with JavaScript. TypeScript saved me weeks of work.

Continue Reading

APPLE IS A CREEP

A

Psychologists know what makes someone a creep. A "creep" is a person who makes you feel uncomfortable or vaguely threatened, but who you are obliged to be near for professional or social reasons. You don't like being around him or her, but you can't leave the room because your professional or social situation require that you be there.

By this definition, Apple is a creep.

Continue Reading

STILL GOT IT

S

Yesterday, after a long day of my day job, in which I spend all of my time either hacking in Typescript and React or doing a lot of dev-ops, I decided that I was finally gonna sit down and write a little Rust. I picked a project off my stack: "Rewrite the Unix locate program in Rust." The last time I had tried this, my brain didn't work at all.

Continue Reading

HTML TEMPLATES: NOT A NEW IDEA, DEFINITELY FASTER THAN ROLLING YOUR OWN

H

About fifteen years ago at a startup, I built a very data-heavy single page app for biologists to manage a map/reduce version of a gene sequencing engine, and because it was data heavy, it made use of templates to render much of the HTML. If you've ever been in this situation, you reach for a library.

With HTML Templates, you might not need a library. But I suspect you're going to want one.

Continue Reading

YOUR COMPANY NEEDS ONLY FIVE PROGRAMMING LANGUAGES, NO MORE, NO LESS

Y

If you've worked in this business for a long time, you've definitely encountered that mid-size company where every team has their own favorite language. And while this might work for awhile, it's a long-term disaster waiting to happen within your company. Eventually, every company that grows to a certain size and survives realizes that you need to clamp down and have at most four computer languages allowed inside your build process.

Four languages is the minimum every company needs, because every company needs the following:

  • A shell language for builds and runbooks
  • A script language for rapid development cycles and low-performance
  • A compiled language for performance and long-term deployment
  • A front-end language for user interfaces.

You need to decide up front which of these you're going to use, and stick with them. The reason is simple: if you limit the languages that are in use in your company's software projects, no project will be a mystery to anyone else. No one will have to deal with "Microservice X is failing, but only three people know how to fix it" problem. By restricting the list of languages your company uses, you guarantee portability of skills across the enterprise, and you provide a safety margin in case one of your core developers gets hit by a bus.

Continue Reading