Domains, Architecture, and Design


The best programmers can take a complex problem, break it down into smaller pieces, solve each of those pieces, and then put everything back together to solve the initial problem.

Software is just a tool for solving domain problems. Since it’s needed in almost all domains, develop in one that interests you. If you understand a domain well and are passionate about it, you’ll be a much better, more motivated developer. You’ll also be exponentially more valuable and lucrative to companies hiring in your chosen domain.

Don’t let one domain pigeonhole you into one way of coding. An example would be a mobile developer who is mainly good at hooking together existing APIs but can't come up with a sane data representation. Don’t be a one-trick pony.

Plan your code away from the computer. It will help you build a clear mental model before you start. You use the same strategy in writing, because if you don’t have an outline, your content becomes a messy stream of consciousness.

“When you're stuck, write your program on paper. I'm serious. It's magic. This is standard practice in programming competitions. (I think it works because when you don't have to think about syntax you have more excess brain power to solve the actual problem.)”

“Compelling web apps tend to be the ones that use data in unexpected ways or in ways that solve everyday problems. Learn everything you can about data storage.”

As an architect, you can’t have blind spots in your understanding of your applications and their execution environments. You need to know how things work in the front end (UI), the back end, the data store, the OS, any virtualization layers, the hardware, the network, and the data center.

Please leave your message and contact
details in the form below