I was thinking this morning about how once you understand that your technology choices have security, performance, and accessibility considerations you become a much more boring developer. Acknowledging those obligations can sort of strips the fun out of programming, but we’re better for it.

I decided to pull on that thread a little more and come up with a list of all the concerns you might have as an engineer/developer that ultimately compound to make you a boring, wet blanket of a person to be in meetings with.

  • Security - Make sure you’re not opening the door for hackers.
  • Privacy - Don’t leak personal information. Or don’t collect it in the first place.
  • Performance - Can the software work on low-end devices? Can you deliver the large bundle over bad internet? Those are your problems.
  • Inclusion/Accessibility - Are you allowing people the dignity to use your product? No? Oof. You should probably do that. Ideally because you are an ethical person, but also because it’s a legal liability.
  • Scalability - If a thousand people show up in the next minute, does your software still work? You have 100 users now, but how does it work for 1000? 1 million? 1 billion?
  • Maintenance - Ship a new feature? Great. Expect to spend at least 40% of cost/time to maintain a feature over its lifetime.
  • Testability - Did you write the code in a way that’s easy to test to make sure bugs don’t show up in production?
  • Deliverability/Distribution - How do people get or use your software?
  • Adoption/Onboarding - How do customers or partners use your software? How do they get familiar?
  • Documentation - Email and DMs is probably not the most efficient form on knowledge transfer.
  • Ecological - Does your app burn through GPUs in Iowa? What are you doing about that?
  • Financial/Cost - Servers and GPUs cost money, did you build this in such a way that it costs as little as possible to run?
  • Monetizability - Good idea but does it make money or cost money?
  • User feedback - What are customers or partners saying about this? Does that impact how or what you write?
  • Stakeholder feedback - Like user feedback but everyone freaks out like their job depends on solving the problem that day regardless if its a good idea or bad idea.
  • Organizational - How to get your co-workers onboard with the plan plays an outsized part in software engineering. Welcome to the world of office politics!
  • Staffability - There’s not a lot of Haskell developers out there. Or the inverse, people over-optimize on technologies that are “easy to hire for” and now you have a billion lines of Java in your application.
  • Support matrixes - For websites, of course we support major browsers and the latest 2 versions? Do we need to go back further? Weirdo browsers? Should we make native apps? Which ones? What devices/CPU architectures do we support there? Niche Linux distros? The list goes on.
  • Political - Some say “all tech is political”, and I tend to agree, but ask yourself: Did you put a politics inside the code? You did, didn’t you?
  • Geopolitical - Rare, but happens. See: Facebook Myanmar genocide
  • Localization/Internationalization - Uh-oh, your UI doesn’t work in German or Arabic. Also all your images and icons are offensive to a particular country’s monarch. Are you ready to cross the borders? Get ready for VAT tax tables, ughck.
  • SEO/Crawlability - Cool website you made, can robots get to it and index it? Now LLMs are coming and slurping up your content and traffic. Uh-oh!
  • Adjacent competitors - What your competitors are doing will always play a role in engineering. Looking better than them is good, being cheaper is good too, but one rule is the most important: never be slower. See: Platform adjacency theory
  • Throughput/Velocity - How fast can you and (more importantly) your team ship an idea from conception to production. What about turnaround times on bug reports?

If you ever ask a developer if an idea is possible and their brain lags out with a little loading spinner over their head, it might be this enormous pile of concerns they’re mulling over. That can be an issue, but I’d be more concerned about the developer that instantly says “Yes” to everything. And if you’re tired of developers saying “No” all the time, ask your developer about ways to put them in situations where they can say “Yes”.